[scheme]Шесть вопросов новобранца

и 7 Насколько опрометчиво будет устраивать числодробильню на схеме (например, решение дифуравнения методом итерации, где есть большой цикл и большие массивы) по сравнению с няшкой или фортраном

6) В ru-scheme.livejournal.com

3) Схема, как и Лисп - мультипарадигменный язык, а не функциональный. Она более склоняет программиста к использованию функционального подхода, но строгости того же хаскеля в ней нет. Это, в свою очередь, означает, что фишки типа referential transparency в схеме отсутствуют.

Строго говоря, Erlang, OCaml, F# тоже позволяют императивный подход (а Erlang, что бы там ни говорили, является не функциональным, а объектным языком), но в них императивщина, как правило, сложнее функциональщины. Haskell функционально чист, и позволяет делать неимоверно интересные вещи.

Ну, схема мне не очень понравилась. Очень жалею что начал серьезно изучать лисп именно с нее. С одной стороны куцая спецификация стандартных средств языка, с другой стороны разброд и шатание в стане схемеров из-за R6RS...

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

В схеме есть call-cc, также, напрочь выносит мозг, а полезность данной конструкции сомнительна.

Лисп не является языком общего назначения типа С, паскаля и т.п. Это важно понимать с самого начала. Нет, конечно, никто не запрещает его использовать именно таким образом... Но ведь и микроскопом можно гвозди забивать.

Самая главная фишка лиспа в том, что ты можешь программировать в терминах AST. Т.е. минуя синтаксические и грамматические ограничения любого языка, мы стоим дерево разбора. Притом, если мы хотим - отдаем его на разбор лиспу, если не хотим сами управляем каким образом его разбирать. Более того, мы можем сделать следующим образом: дерево А, которое генерирует дерево B, которое генерирует дерево X, из которого получаем конечный код (необязательно машинный, можем и исходник на LLVM или вообще на С). Такой подход называют метапрограммированием.

Второй важной фишкой лиспа является то, что в нем нет никакого различия между DSL и eDSL. Т.е. мы сначала разрабатываем eDSL, а если вдруг возникнет необходимость - прикручиваем ему более-менее пристойную "морду", а потом паресер -> AST. Но ведь на лиспе мы программируем в терминах AST, поэтому получается все тот же eDSL, который мы разработали. И вообще, разработка грамматики/парсера - дело скорее техническое, чем творческое.

А вот схема, к сожалению, частично променяла эти фишки на призрачный и экспериментальный ФП...

Чем-то типа стандарта являются RnRS, в которых не всё есть, существуют
SRFI, пачка которых обычно включена в большинство реализаций, и бывают
специфичные для больших реализаций библиотеки. Большая реализация это
PLT, Bigloo и Икарус. Спрашивай в comp.lang.scheme, как раз топиков
про ой-вей что же делать где же библиотеки для продакшена там
достаточно.

> только в 18 есть слово defmacro

Дефмакро это не по-схемовски, это негигиеничные макросы в стиле CL.

> Сколько будет весить скопмиленный хеллоуворлд (например) на схеме
> без зависимостей? Который мог бы выполняться на машине без схемы

4 мегабайта с помощью PLT под Юниксом, консольное приложение.

> В схеме есть call-cc, также, напрочь выносит мозг, а полезность данной конструкции сомнительна.

А вот это ты зря. Посмотри на SISCweb, хотя бы.

>Посмотри на SISCweb, хотя бы.

В _реальных_ приложениях под реальной нагрузкой? Нестабилен он слишком.

ИМХО задачи такого рода лучше решать с помощью конечных автоматов.

>>Haskell функционально чист, и позволяет делать неимоверно интересные вещи >>самый главный урок, который я вынес из хаскеля - ФП ради ФП не бывает

Народ, что ИМЕННО за Ъ-хацкел-онли неимоверно интерестные вещи??? И почему их нельзя делать на схеме?

Почему такие полярно-противоположные мнения о хацкеле

Честно признаюсь, начинал фапать хацкел, но понял, что маны не хватит. Может после схемы продолжу

>>Дефмакро это не по-схемовски, это негигиеничные макросы в стиле CL.

А что в ней на замену?

>>4 мегабайта с помощью PLT под Юниксом, консольное приложение.

Как-то это не нормально, мне кажется.. Коммон-лисп, же, вроде может делать чуть-ли не С-подобные бинарники. Почему в схеме 4 мегабайта?!1 Из-за функциональщины?

> В _реальных_ приложениях под реальной нагрузкой? Нестабилен он слишком.

В реальных, вполне. Нагрузка неплохая, всё уже года два как работает стабильно. Чему там ломаться то, оно тупое как паровоз.

> ИМХО задачи такого рода лучше решать с помощью конечных автоматов.

Реши. Так, чтоб кнопка "back" надёжно работала, ага. И чтоб этим можно было вообще пользоваться.

ЗЫ: в SISC кошерный define-macro работает.

> Народ, что ИМЕННО за Ъ-хацкел-онли неимоверно интерестные вещи??? И почему их нельзя делать на схеме?

Та же STM, например. Можно, в принципе, делать то же на нечистом языке (схема, камль...), только в результате у тебя ракеты будут запускаться несколько раз, когда не надо ни одного. Придётся в документации оговаривать "если ваш код может запустить ракеты, то производитель не несёт ответственности за то, сколько раз они будут запущены и в какой ситуации". А документацию всё равно прочитают уже после того, как Кремль снесут (хотя это, может, и хорошо).

>Народ, что ИМЕННО за Ъ-хацкел-онли неимоверно интерестные вещи??? И почему их нельзя делать на схеме?

А какие есть в схеме, которые нельзя делать на Хаскелле? Причем схема на хаскелле пишется в 500 строк за 2 дня. Пруфлинк:

http://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_Hours

А еще Хаскель быстр - а схема тормозная. А еще Хаскель бьет тебя по рукам на стадии компиляции. Такой Bondage & Discipline Language :) А еще он форсирует использование ФП парадигмы в гораздо большей степени.

> Причем схема на хаскелле пишется в 500 строк за 2 дня.

Только это получается тормозной интерпретатор. А вот компилятор Хаскелля на Схеме написать очень даже можно (и он, между прочим, есть).

> А еще Хаскель быстр - а схема тормозная.

Сравни stalin или даже bigloo с ghc. Будешь удивлён.

> А еще Хаскель бьет тебя по рукам на стадии компиляции.

У меня руки с нужной стороны пришиты.

Так что, пользуюсь и Haskell и Scheme, в зависимости от задачи.

> Сравни stalin или даже bigloo с ghc. Будешь удивлён.

Сравнил. bigloo быстрее PLT в среднем раза в 3-4, ghc быстрее PLT в среднем в 13 раз. Дурацкий "тест", но кое о чем говорит.

http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=ghc&am...

http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=bigloo

>>только в результате у тебя ракеты будут запускаться несколько раз

Вот здесь en.wikipedia.org/wiki/Software_transactional_memory эта ваша STM реализована на over than 9000 языках. В том числе и на хацкеле (что говорит о том, что STM не является частью хацкеля?) В чем подвох?

>>А еще Хаскель быстр - а схема тормозная.

Это далеко не всегда главный фактор и точно не относится понятию "неимоверно интерестные вещи", ня

Конечно, не является. Я где-то сказал обратное?

И я не говорил, что нельзя делать на других языках. Я говорил, что в результате получится такая вещь, которой нужно пользоваться с очень большой осторожностью. Бережно. А в Хаскеле она будет следить за этим сама.

Из той же статьи: On the other hand, the need to abort failed transactions also places limitations on the behavior of transactions: they cannot perform any operation that cannot be undone, including most I/O. Such limitations are typically overcome in practice by creating buffers that queue up the irreversible operations and perform them at a later time outside of any transaction. In Haskell, this limitation is enforced at compile time by the type system.

>Сравни stalin или даже bigloo с ghc. Будешь удивлён.

stalin адекватно сравнивать не с ghc, а с jhc - ибо он тоже делает Whole program optimization. По моим тестам он раза в 4 быстрее ghc и заметно меньше размер бинаря.

кто-нибудь встречал scheme на symbian или на MIDP платформе?

Выкинь схему, учи пистон. ФП там тоже есть. ;)

Пока пайтон не научится нормально оптимизировать хвостовую рекурсию, ему не стоит и пытаться называться функциональным языком.

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

>Коммон-лисп, же, вроде может делать чуть-ли не С-подобные бинарники.
Это мало какой коммон-лисп. Насколько я знаю, такое есть только в ECL и в коммерческих(LispWorks, AllegroCL)

Тот же SBCL executable создает путем дампа рантайма в файл. В итоге минимальный размер такого ~25мб.

Про scheme не слышал, зато из Коммонлиспов CLISP там запустить вполне реально :)
http://lemonodor.com/images/nokia-n800-clisp-s.jpg

>пистон
Выкинь эту поделку, возьми Common Lisp

Scheme это больше "учебный" язык.
Если тяготеешь к Лиспу, бери CL. У него и библиотек побольше, и макросы мощнее, и CLOS.

> Выкинь схему, учи пистон

Это не трендово :) Пусть даже в нем библиотеки стандартные, и для Симбы он есть - не не трендово, поцаны уважать не будут.

>Это не трендово
Шутить изволите?
Питон это самая что ни на есть попса.

>>Это не трендово

>Шутить изволите?

Яволь.

> Питон это самая что ни на есть попса.

Смотря с чем сравнивать - с Явой или с Haskell. А слово "трендово" в данном случае употреблено в значении "престижно, элитарно".

> А слово "трендово" в данном случае употреблено в значении "престижно, элитарно".

Дожили. Совершенно противоположные смыслы, блин.

>> А слово "трендово" в данном случае употреблено в значении "престижно, элитарно".

> Дожили. Совершенно противоположные смыслы, блин.

Почему же... в определенных кругах CL и Haskell являются модными и престижными. Другое дело, что "страшно узок круг этих людей" (c) %)

> (а Erlang, что бы там ни говорили, является не функциональным, а объектным языком)

хм... я конечно извеняюсь, а можно по-подробнее про объектный Erlang?

Уже все объяснили, все понял... если кому интересно, можете почитать например тут:

http://talklikeaduck.denhaven2.com/articles/2008/01/01/alan-kay-on-the-meanin...