inv2004 Alibek B.
Я бы не сказал, что оно искуственно,
но, например, у меня, это вызывает небольшой дискомфорт - программа верная и описана точно, но необходимость что-то, например, слогировать посередине вычислений вызывает анальную боль.

Если нет точного понимания, что именно пишешь, haskell рефакторить вставлять костыли в хаскель значительно более трудоёмно, чем другие языки с side-эффектами.

Alibek B.пропущено...

Нет, смысл я понял. Но как-то искуственно такой финт выглядит.
Как введение понятия "эфир" в свое время.

поправил.

а рефактроить как раз в разы проще и лучше. строгая типизация и контроль сайд эффектов, помогают не налажать, не допустить ошибок. и т д.

maytonZyK_BotaNну вот не скажи что эта отладка так уж нужна.
если язык функциональный. то можно тестировать работу каждой ф-и по отдельности(можно задействовать и юнит тестирование)

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

вот статья на тему, как программировать взаимодействие с внешним миром с помощью ФП.
з.ы. внешний мир здесь даже не обязателен, можно просто для моделирования данній подход применять:

подход назіваеться - реактивное программирование, сегодня на хабре заметил статью, решил тебе дать ссілку почитать:
http://habrahabr.ru/post/140719/

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

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

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

Division XЧем ваши хвалёные лиспы с хаскелями лучше ECMAScript 5 и Perl?

ну, если лисп - только макросами(которые не стоит недооценивать)

то рядом с хаскелем эти динамические язычки я и рядом не стоят.

Division XZyK_BotaN,

а можно по пунктам, чем хаскель лучше JS?

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

это совсем другое, и даже сравнивать трудно.

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

т.е. столько параметров, что даже фиг сравнишь эти языки.

а вот с лиспом, да - можно сравнивать и говорить - что лучше, а что хуже.

Division XZyK_BotaN,

Хорошо, с лиспом. Напомню, речь о ES5 (со всеми его map, filter, reduce, some, every и т.п.), который подерживается во всех современных браузерах и nodeJS.

ну я выше сказал - макросы.