Сейчас я бы для скриптов и для конфигов использовал python. Язык простой и приятный, развивающийся, с нормальным сообществом и библиотеками, быстрее guile, встраивается не сильно хуже lua. Правда говорят, что luajit быстрее, но я не проверял.

Какие есть преимущества у scheme вместо питона в линуксах для самостоятельных скриптов?

никаких нет. Питон сейчас есть почти везде из коробки (считай, стал стандартом) с кучей биндингов к различным либам и пакетам. Лучше для халтурки в линуксах пока ничего нет.

Имеет ли смысл делать конфиги linux-only программы, написаной на си/pascale/др компилируемом языке, на scheme (подразумаваю использование guile) или лучше взять lua?

чё? Конфиги лучше делать через ini, json, xml, yaml и т.п.

быстрее guile

Не смешно

Конфиги лучше делать через ini, json, xml, yaml и т.п.

конфиги в json/xml/yaml? еще один шутник

Perl.

Схемку можно и компилировать (chicken, gambit), так что тут можно не особо нарпягаться.

ИМХО, что у схемы что на луа конфиг в любом случае будет понятен.

// добавь теги lisp, scheme и пр. подписчикам посыпятся уведомления

будь оригинален, возьми escript!

для самостоятельных скриптов

Для скриптов я бы взял perl.

Конфиги лучше делать через ini, json, xml, yaml и т.п.

Хочется взять, и уе... убедить.

Спасибо хоть, что не пишешь в интернеты когда тебе посрать хочется. Вообще обращайся, пожалуйста, со своими расстройствами к психиатру.

Какие есть преимущества у scheme вместо питона в линуксах

Guile одобрена Столлманом и the GNU Project. Что в переводе на русский значит «абсолютно неюзабельна для реального применения» (см. также https://www.gnu.org/software/hello/).

С другой стороны, в uim (который вполне юзабелен) юзается именно она. Но я не знаю, почему.

а также в в xbindkeys, lilypond, gnucash и других

15 мегов оперативы интерпретатор съедает сразу

4.5 на 64-битной системе

запускается чуть дольше

$ time guile -c '(quit)'
guile -c '(quit)'  0.01s user 0.00s system 88% cpu 0.017 total

$ time python -c 'quit()'
python -c 'quit()'  0.02s user 0.01s system 69% cpu 0.029 total

Какие есть преимущества у scheme вместо питона

полноценный функциональный язык

Имеет ли смысл делать конфиги linux-only программы, написаной на си/pascale/др компилируемом языке, на scheme (подразумаваю использование guile) или лучше взять lua?

зависит от, если для себя, и синтаксис лиспов ближе - однозначно бери guile, 2 версия, кстати, искаропки помимо scheme поддерживает ecmascript и elisp.

• если надо влезть в малую память, то юзай lua.
• если хочешь понятные скрипты на полноценном функциональном языке, то юзай guile.
• если хочешь чтобы юзеры чаще видели питонячий стектрейс, то юзай python

если хочешь чтобы юзеры чаще видели питонячий стектрейс, то юзай python

взоржаль

elk

нашёл в репозитарии ещё elk, запущеный интерпретатор ест на 30% меньше, чем lua :) так что по памяти, наверное, схема тоже подойдёт.

Для таких целей — луа

В интернетах сотни реализаций scheme, причём даже hello-world не на всех запускается,

Потому, что схема простая, как три копейки и наваять свою реализацию --- это даже не курсовая, это уровень лабораторки. Питон значительно сложнее.

по п1.: guile он-же scheme «стандартный» язык расширений gnu. Что как-бэ намекает :) Python просто мода.

по п2.: нельзя делать конфиги на интерпретируемых языках. Конфиг это не скрипт - это такая сущность которая всегда интерпретируется как само-в-себя, хоть и сложная, но еденица данных.

нравится синтаксис scheme - s-exprs во все поля :) иначе json,xml - да тыщи их, языков описания данных.

нельзя делать конфиги на интерпретируемых языках

но если очень хочется, то можно, и даже удобно

но если очень хочется, то можно, и даже удобно

если очень, то да..

но ТС обуреваем сомнениями :-)

Нет, скажи, ты действительно считаешь xml удобным для редактирования руками форматом?

Ну по крайней мере удобнее питона.

Нет, скажи, ты действительно считаешь xml удобным для редактирования руками форматом?

Зависит от задачи, может быть достаточно удобным по сравнению с другими альтернативами, особенно если правильно его готовить (т.е. использовать атрибуты атрибутами, а не текстом с разметкой...).

Но суть моего послания была немного в другом, что уже сказли ниже(выше)

нельзя делать конфиги на интерпретируемых языках

emacs? не, не слышал...

по п2.: нельзя делать конфиги на интерпретируемых языках. Конфиг это не скрипт - это такая сущность которая всегда интерпретируется как само-в-себя, хоть и сложная, но еденица данных.

почему это не скрипт? какая вообще разница между кодом и данным, это ж лисп ???

берём skribilo, пишем бложик в .skb (схемоподобном). ну или если больше нравится, в org-mode (прозрачно транслируется reader в схему).

компилируем в LaTeX/ConTeX=>pdf, lout=>ps, texinfo, html, выставляем в бложик.

ну или «из коробки» в xml или в свой велосипедный writer.

теперь, следи за руками:

1. org-mode разметку разбавляем babel, типа literate programming и reproducible research. в итоге, она генерируется из других скриптов, встроенных в babel сниппеты. в любом удобном формате, например, тот же org или s-exprs (дебаг в емаксе какой-то структуры).

2. прицепляем к org-mode что-то типа вики. но просто вики это тупой текст, а вот если «семантическая вики», то это получаются уже типизированные ссылки и атрибуты. статья вики = объект = сущность, атрибуты = свойства объекта, типизированные ссылки = отношения = свойства метаклассов (MOP во все поля, описания defmethod/defgeneric).

в итоге, получается «семантическая вики» на CLOS объектах. как база знаний, поначалу, то есть, неактивная.

3. на выходе, раз вики семантическая, она умеет опрашиваться через SPARQL запросы по онтологиям, и импортировать/экспортировать RDF тройки.

RDF тройки задают Объект/Субъект/Отношения или классы/метаклассы/родовые функции. получается такой лисп-3, кстати, ну если kernel лисп с fexpr-ами вместо макросов немного допилить, оно самое будет.

4. в итоге, православно пишутся агенты к такой семантической вики системе. в первом приближении, агентов можно запускать через org-mode babel сборку org-ов, во втором, нужна какая-то модель событий. она сама по себе может храниться в той же сема.вики.

5. поскольку в лиспах писать впадлу, придумаем входной язык — Controlled English ну как в Behaviour Driven Development, или вот ещё пример — Interactive Fiction языках типа Zork'a.

NLP парсер (упрощённого языка) парсит в субъект/объект/отношения Subject/Object/Verb, получается «почти язык».

6. прикручиваем нормальный ЕЯ через нормальный NLP парсер.

в итоге, такая распределённая семантическая вики на лиспе сама себя вычисляет, определяет модели взаимодействия агентов и внезапно — взаимодействует.

7. .... пишем нужных агентов, или задаём им правила самообучения ....

???

PROFIT!!!

это такая сущность которая всегда интерпретируется как само-в-себя

то есть, метаязык. а не

хоть и сложная, но еденица данных

можно и GNU emacs, в нём org-mode из коробки. но оно на долбанутом Elisp, а GuileEmacs всё никак не допилят.

можно TeXmacs поковырять веточкой, там Guile встроен (правда 1.8 а скрибле нужен 2.0+). там грамотное программирование проще прикручивается, да и вообще гуйня в нём красивее.

хотя да, можно взять SXemacs с нормальным FFI, но и с долбанутым Elisp-ом прикрутить через него Guile, и уже хренячить свою интеллектуально-агентскую сема.вики во все поля =)

например, для описания агентов любопытно было бы заюзать либо конечные автоматы из SWITCH-технологии в FSML (как eDSL для скрибли), либо ДРАКОН-схемы (и HTML5 редактор их через SVG, ну или конвертор из Dia), и тоже как eDSL типа dot-файлов графвиза.

для задания модели взаимодействия. такой бизнес-процесс типа. можно writer для скрибли прикрутить в BPML и какую-то Runa/WFE запускалку.

в итоге, править эти модельки через сема.вики, ну или из емакса в православной org-mode разметке. это поначалу, пока роботы не догадаются сами, как их писать.

потом эволюция роботов-агентов заработает.

Если психиаторы не прикроют лаочку раньше

по п2.: нельзя делать конфиги на интерпретируемых языках. Конфиг это >не скрипт - это такая сущность которая всегда интерпретируется как >само-в-себя, хоть и сложная, но еденица данных.

хм, что-то так категорично, что аж захотелось напомнить о save-tcl
в котором можно создать untrusted slave интерпретатор только с одной командой set, например ...

мне кстати тоже вспомнился tcl, чтобы в нём/им читать конфиг. Но есть нюансы :)

1) всё-таки конфиг по хорошему должен шариться между приложениями (как минимум конфигуратор/приложение) и тут либо все кому это надо должны включать в себя tcl, или лучше пусть уж конфиг останется в более-менее привычном формате описания данных.

2) tcl - контекстно зависим и автономно проверить конфиг на некорректность невозможно. Есть 100500 способов описать на tcl одно и то-же, что не совсем хорошо для описания конфигураций.

1) всё-таки конфиг по хорошему должен шариться между приложениями >(как минимум конфигуратор/приложение) и тут либо все кому это надо >должны включать в себя tcl, или лучше пусть уж конфиг останется в >более-менее привычном формате описания данных.

я понимаю куда ты клонишь ... xml и все такое ))
но ведь libxml2 и xslt больше самого tcl в разы
а какой прок от xml-фашизма в гноме2, пилите парсеры шура ccs в gnome3, ибо прогресс это ...

но, допустим, для какого-то там редактора парсить xml - вот за это надо убивайт сразу на месте.

2) tcl - контекстно зависим и автономно проверить конфиг на >некорректность невозможно.Есть 100500 способов описать на tcl одно >и то-же, что не совсем хорошо для описания конфигураций.

это тоже весьма спорно ))
например, с учетом расширений tcl
можно конфиги писать так:
http://mkextensions.sourceforge.net/mkGeneric13.htm
proc p { foo args } {
options opt $args -decreasing {-index *} {-color {red green blue} red}
parray opt
}

opt(-color) = green

так что ...

я понимаю куда ты клонишь ... xml и все такое ))

неа..я клоню что «конфигам-конфигово» :) когда делал мат.модели, в конфигах бывала толпа векторов/матриц и мыслей про xml даже не возникало. Просто для описания конфигураций/данных свой язык (со своими требованиями), и конкретный выбор зависит от области.

xml хорош тем что он прост как бревно и парсер xml по объёму кода меньше чем какой-нить TclEvalObjEx;

xml хорош тем что он прост как бревно и парсер xml по объёму кода >меньше чем какой-нить TclEvalObjEx;

ха ха, а прицепят libxml2 на 1,5 метра и к нему python-libxml2 на метр
классика библиотечного программирования ))

и конкретный выбор зависит от области.

не спорю )

ха ха, а прицепят libxml2 на 1,5 метра и к нему python-libxml2 на метр
классика библиотечного программирования ))

цеплять в приклад scheme с её накладными/проектными расходами и gc чтобы прочесть 1к структурированных данных тоже не комильфо :-)

когда делал мат.модели, в конфигах бывала толпа векторов/матриц и мыслей про xml даже не возникало.

а вот в COLLADA очень даже возникла. поэтому, если к этой колладе прикрутить ещё и сема.вики на лиспе, и вместо колладного DOM загрузку в метаклассы и MOP, то тут-то всё и заверте...

например, workflow 3d-гейм дизайнера можно так прикрутить.

или фабрику самособирающихся роботов с 3d принтерами наперевес..

ну к православному SGML же DSSSL прикрутили... именно на схеме.

ж;-) M-x doctor нас не догонит.

обмазываемся инкрементальными парсерами, переписываем ООБД GOODS Книжника с С++ на COS ну или хотя бы для прототипа на manardb , прикручиваем FUSE модуль, чтобы ходить в ООБД с вики с семками как себе домой (в итоге обрабатываем структурные объекты и их представления обычным ламповым sed, perl, m4 и т.п.), расшариваем всё это через torrent что-то наподобие BitSync, или gitfs.. и профит.

СЛАВА РОБОТАМ-АГЕНТАМ, ПОБЕДИТЕЛЯМ СОЦ-ДАРВИНИЗМ СОРЕВНОВАНИЯ!!

;-)

http://ldeniau.web.cern.ch/ldeniau/cos.html

танцпол продолжается.

C++ Object Model is a long paper (see object_model.html) started years ago which I unfortunately never finished (about 25% achieved), but is enough to understand the overall

гы, ещё один «ниасилил С++»

Object Oriented C - Simplified release is an oversimplified version of OOC-2.0 with about 300 sloc (ultra light!), which provides some very simple coding guidelines and programming techniques to allow C programmers to write object oriented program nearly as in Java.

внушаить!!!

Acknowledgment: I would like to thanks Ovidiu Achim who wrote the objects fast allocator, the testsuite of ooc-core, most of the code you may find in the ooc-std library and did the port of JUnit. And Florent Georges who did a partial port of JDBC (code in ooc-db).

резвятся парни

да, вместо скрибли в целях жалких предварительно-оптимизационных хаков можно в принципе мультимаркдаун (гитхаб) прикрутить, а тот же Emacs-muse не так чтобы уж очень сложно допиливается до того чего нужно.

правда, способ неправославный: теряем вкусняшку и мякотку, возможность смотреть через с-выражения на что угодно. зато тормозить вроде бы меньше должно.

Да ты же совсем ебанулся, лол