- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
count c l = length $ filter (c==) l
main = do
l <- getLine
let
f = count '(' l
s = count ')' l
in
print $ f s (f==s)-
Куча / Говнокод #10265
+115
Посоны, как смешивать монадический код и не монадический?
http://ideone.com/yRGDk
Чистый код let in не хочет в монду.Запостил:
HaskellGovno,
14 Мая 2012
Follow us!
Есть Text.Printf.printf - только не сказать, что безопасный.
Что? И тут крестопроблемы? Даже в хаскеле не безопасный printf? :(
> проблема, by design присущая printf
Ни чего не падает. Все безопасно. ЧЯДНТ?
Нет никакого неопределённого поведения. Просто получим исключение. Всё безопасно. А что там у хаскела? Небось память попортит?
лолчто?
http://hackage.haskell.org/package/safe -- примерно в этом смысле.
Так что Хаскель и тут в очередной раз соснул.
http://ideone.com/JoaZy
http://ideone.com/BH0pW
http://ideone.com/WQj1U
Лолчто? Код выше видел? Всё абсолютно типобезопасно. А хаскелюшачка эту типобезопасность не осилил, точнее осилил, но очень слабо на уровне амёбы.
Для этого есть "printf" не являющийся макросом, который все типы проверит в рантайме. Тут как бы по другому то нельзя.
> лучше уж реализовать свой DSL
Ты лучше реализуешь свой кривой говновелосипед с ошибками ради пары сформатированных строк? Не нужен.
Use another printf, Luke. ok.
> ради пары сформатированных строк
ради пары строк меня вполне устроит show и print, или, на в крайнем случае, "опасный" (лол какой опасный) printf
Вы хотите сказать, что использование костыля (макрос для, казалось бы, базовой функции) неким чудесным образом обеляет printf и превращает остальные языки в жалкую приставку для вашего ника? Не могу сказать, что ваши силлогизмы слишком радуют стройностью (если вам показалось, что это эвфемизм - вы не ошиблись).
Если вы решили, что опускаться до макросов - приемлемо, то уж кушайте и template haskell - http://www.haskell.org/haskellwiki/Template_Haskell#Printf .
Только не нужно мне сразу загонять телегу, что мол непортабельно[^1], и раз Хаскель - то нельзя пользоваться метапрограммированием, и поэтому нужно выбирать другой инструмент для этого. :-7
[^1]: риску предположить, что хаскель будет пораспространеннее D & Nemerle, так что GHC-гвозди здесь адекватны
http://ideone.com/dgCHU
Только не нужно мне говорить, что раз эта возможность есть, то я могу написать свой велосипед с квадратными колёсами и пользоваться им. Тем более в стандарте языка возможности использовать макросы нет. А использовать компиляторспецифик расширения {-# LANGUAGE TemplateHaskell #-} - убого.
> Тем более в стандарте языка возможности использовать макросы нет.
Вы так говорите, будто уже привели ссылочку на стандарт для Nemerle.
> {-# LANGUAGE TemplateHaskell #-} - убого.
А как вы определяете, что убого, а что нет. Не на слух случайно?
Рад за вас, что объемы ваших полушарий таки позволяют сидеть на двух стульях, принимая макросы, и одновременно, отвергая template haskell.
Зачем это копипастить, если там реализована убогая поделка без полной поддержки нормальных флагов форматирования, а среди поддерживаемых типов только s и d. Этот модуль даже не стоит того, чтобы обсуждать. Я и то бы лучше написал.
Если неплохо знаешь хаскель - то уж вбрасывай потоньше, чем let vs let ... in
Можно еше Printf-TH посмотреть.
Пиздец.
И не нужно тут printf.
Лол. Да ты похоже какой-то тугой. А что если я хочу вывести форматированный вывод с нужным числом знаком после запятой и вставив необходимые символы\слова, а не только пробелы как с unwords, между форматированными элементами? Да и вообще ты какой то говнокодер - 3 раза повторил show вместо одного.
do let ... ; ... --> let ... in do ... (вроде такая трансляция do-сахара)
Я бы мог понять, если бы in играло какую-то роль в этом различии (но, очевидно, оно никак на это не влияет) - на что влияет, я так и не понял - но больше всего похоже, что это какая-то внутренняя война Хаскелля самого с собой изза идиотического синтаксиса и чего-то там не срослось опять. Хз вобщем.
let ... in ... - выражение, но просто так выражение в do-синтаксис не адаптировать (там они должны иметь тип m a, где m-соотвествующая монада). С помощью подобной трасляции как раз это и получается (и let получается "урезанный" - область видимости нижележащая do-конструкция, соотвественно и "in" - избыточен).
Нафиг нужен вообще do блок, если с ним столько проблем? Нафиг нужно вкладывать столько смысла в пробельные элементы, если 100500 раз было наглядно доказано, что на whitespace код очень тяжело читается... но ежики, кактусы...
Хаскелль - безо всякой на то причины очень сложный синтаксически, и, в часнотси потому, что в нем разнообразия больше, чем в ПХП глобальных функций. И вообще язык на большую половину состоит из пиктограм, которы надо заучить наизусть - в ПХП хоть из названия функции как правило можно догадаться что она делает.
Есть такая вещь, как "путь наименьшего удивления". Т.е. например, let-in существует в HOPE, ML (и потомках), Miranda (собственно, Хаскелль ее наследник) - но ни в одном нету двух вариантов let и let-in. И человек, немного знакомый с другими языками естесственно удивится "разнообразию" и начнет искать причину, и еще больше удивится, когда окажется что причина - исключительно в идиотизме авторов.
Из всей этой группы языков, я первым познакомился с Эрлангом - там есть свои заморочки, как и везде, но после пары недель код на нем не вызывает удивления. Следующим был Хаскелль - для меня это до сих пор клинопись, только желания разбираться больше нет. CaML по сравнению выглядит прямо аж спасибо автору хочется сказать за то, что не похож на Хаскелл. Мне иногда проще найти доку по CaML и по ней попытатся угадать, что делает Хаскелль, чем понимать белеберду на самом Хаскелле.
А комментирую потому, что изза этой дряни к другим, хорошим языкам складывается предвзятое мнение (типа того же ML).
Хм.. а где еще (из юзабельных языков) pure core, то бишь чистые функции, отделены от остального кода?
Особенно, когда не остается никакого выхода, кроме как записывать большие структуры в файлы и при необходимости их оттуда читать. Или держать открытм сокет написаный на другом, вменяемом языке и его использовать для хранения. Про работу с базой данных лучше не заикаться даже. Это на столько криво реализовано, что плакать хочется.
https://secure.wikimedia.org/wikipedia/en/wiki/Referential_transparency_(computer_scien ce) :
This can help in proving correctness, simplifying an algorithm, assisting in modifying code without breaking it, or optimizing code by means of memoization, common subexpression elimination or parallelization.
> отсуствие нормальной возможности хранить состояние программы
Прямо-таки отсутствие? А как же (помимо чистой State-monad) : IORef / STRef / MVar / TVar или даже persistent с бэкендами в виде баз данных. Или они не нормальны, ибо подразумевают монадический доступ.
> и тем более простота в понимании
Срочно все в маши^Wplan9. Нельзя же все писать на одном уровне детализации, а значит и простоты. И должны же в CS быть ветки с теоретическим уклоном. Может вам еще и proof-assistant (Сoq / Agda / Epigram / whatever - о всех у меня весьма смутное представление) подавай, чтоб с полпинка можно было осилить.
> Про работу с базой данных лучше не заикаться даже.
Для относительно низкоуровнего доступа может и HDBC хватить. Если хочется чего-нибудь поприятнее - есть HaskellDB, но там template haskell и все сопутствующие прелести. А какие там особые проблемы, поделитесь для расширения кругозора (с бд-интерфейсами хаскеля я знаком поверхностно)?
> Срочно все [...] - Хаскелл очень сложен в понимании изза плохой структуры, не очевидный (не возможно понять что именно делает код, если не знать во что он превращается компиляторм / не попробовав запустить). С языками для доказательства теорем - Лисп, собственно, был пионерм в этой области в смысле символического исчисление. И был на столько лучше и универсальнее всякого говна типа Coq, но есть мудаки старперы, для которых их средневековые закорючки важнее универсальности и понятности.
пипец, правила преобразования do-блоков в монадические операторы просты до безобразия, их описание вместе с примерами и детальным объяснением занимают всего пару страниц в RWH. Ядро языка очень мало, почти все операторы (включая столь нелюбимые вами (.) и ($)) определены в терминах самого haskell.
Все эти закорючки - такой же дибилизм. Кстати, интересный момент, Хаскелль приподают в Японии примерно как Паскаль в странах бывшего союза - Японцам очевидно выучить еще сотню-другую пиктрограм - как раз плюнуть, для них это наверное типичное домашнее задание.
Я за свою жизнь выучил кучу идиотских никому не нужных символов и алфавитов - и когда очередной дибил предлагает выучить еще сотню "для удобства" хочется такого мордой об клавиатуру линотипной машины, пока алфавит, сука, не выучит.
Я начал изучать haskell сразу после прочтения SICP, и не имел опыта работы с функциональными языками, кроме разве что со Scheme.
Изучать начал по RWH. Проблем с синтаксисом у меня не было. Вообще. По мне всё выглядит логично и понятно, иначе бы я просто не смог осилить синтаксис в силу своей неспособности к заучиванию.
Математическая аналогия: абстрактная алгебра, теория категорий и топология довольно трудны для освоения из-за своей абстрактности, но они позволяют делать более общие выводы и находить закономерности, недоступные более "прикладным" разделам. Но это не означает, что более детальные и прикладные разделы не нужны, и уж тем более не означает, что все разделы нужно запихнуть в абстрактную алгебру.
Если набрать пехепешников и заставить их сразу писать на haskell, получим не красивый, быстрый и поддерживаемый код, а жесткое мясо с вермишелью.
Я (пока) не знаю erlang, поэтому ничего не могу сказать про удобство использования состояния в нём, но я на 95% уверен, что "хреновые" архитектурные решения, принятые в силу "отсутствия нормальной возможности хранить состояние" были скорее симптомами неосиляторства, чем ограниченности возможностей языка. В haskell, к примеру, есть реализация STM (вроде бы ничего лучше для хранения состояния в многопоточной среде ещё не придумали).
Из этого ровно ничего не следует.
Не хочу сорри, жуткий косяк
2. Таки я собрал YI, в принципе вещь удобная, с емаксовскими биндингами дружит. Правда, там нет аналога столь горячо любимого мной org-mode.
3. > которая должна реагировать на ввод настоящего пользователя
Вспомнилось по теме
Небось ~/.cabal под пол-гигабайта, тоже собирал, но почти не пользовался.
Монады пришли из ТК и, как и любая математическая абстракция, они работают вне зависимости от того, осведомлены ли вы об их присутствии или нет. А JS слегка соснёт из-за аппликативного порядка вычислений.
> ТК
Расшифруйте пожалуйста.
По мне так люди, которым нравится haskell ведут себя в этом споре гораздо достойнее. Во всяком случае, никто из них не создаёт ники наподобие ThisLanguageGovno или UserNameGovno. И не брызжет слюнями лучами ненависти.
Такое ощущение, что кто-то бьёт вас по голове, заставляя учить хаскелл. К чему эти бессмысленные холивары? Мне всё равно, нравится он вам или нет. Мне нравится, я нахожу в нём то, что ищу больше всего - новые идеи и подходы.
То что их придумали еще не значит, что они имеют какую-то практическую ценность. В контексте Хаскелля вся их практическая ценность - это "заставить" реальность соотвествовать убогой теории. А когда теория таки оказывается абсолютно нежизнеспособной, даже с костылями - то наконец-то здравый смысл побеждает, и используют unsafeIO или как его там.
Аггрессия изза того, что этот маразм подается как какое-то эзотерическое сакральное знание, прям, блин общество Рериха. И изза этого говна, другие, абсолютно непричасные к нему вещи гребут под одну гребенку. Представьте реакцую нормального человека - раз познакомившись с Хаскеллем, когда он услышит, что ML похож на него - сразу начнутся рвотные рефлексы. Хотя ML хороший для своей области (например, написание компиляторов) язык, и, например, Эрланг, если использовать его вместо того же ПХП - очень даже вполне мог бы оказаться к месту. (Эрланг феерическое говно для того, для чего его рекламируют - т.е. напсиание долгоработающих распределенных приложений, но для задач типа выполнил и закрылся - работает здорово, очень простой и понятный язык).
Вроде никто не говорит, что это нечно сакральное. Можно считать экпериментальным.
Откуда инфа? Почему так происходит? Можете рассказать подробнее?
Расскажите об этом Ericsson с их распределёнными системами. Я, кстати, писал на сишке SCCP сервер под OSE Delta для них. Вот уж где феерическое говно было.
На эту тему есть смысл почитать Питера Норвига и Стюарта Рассела про новые подходы к АИ. Не в том смысле, что есть какая-то глубинная связь между созданием сложных систем, а в том, что там есть определенные аналогии, и на пальцах показывается почему "идеальной, математически выверенной" программы в принципе не написать. Там был такой пример, когда человек переходит парковую аллею, и в то же время из авиалайнера пролетающего над парком падает багаж - и нет больше пешехода. Т.е. в реальном окружении предсказать все событя не представляется возможным, и пытаться добиться 100% корректности - это пытаться объять необъятное. Собственно, аргументация сводится к тому, что любая программа по определению работает в стохастическом окружении, где нельзя (и даже вредно) предполагать такую возможность как 100% осведомленность об окружении. Такая осведомленность возможна только в каких-то искуственно созданных оазисах, типа игры в шашки.
Прочитаю Programming Erlang Джо Армстронга, и мы вернёмся к этому разговору.
превращается в такую пытку, что в итоге на оптимальные решения забивают и пишут как удобнее, а не как лучше.
ejabberd как-то работает же, вроде никто не жалуется.
А работает - ну дык Фейсбук на ПХП - и работает, че там, даж норм работает, практически бесперебойно и вообще.
На самом деле, если бы другие процессы ВНЕЗАПНО увидели новые данные - было бы еще хуже. Это та же история, что и писать многопоточку на С без использования блокировок.
Мне кажется эта проблема общая, а не только ФЯ.
Пример:
A - какой-то элемент из списка B
Я не тестировал, и это скорее псевдо-код, но вполне верно описывает то же самое, что в каком-нибудь Яваскрипте выглядело бы примерно как
Вообще без какого-либо преувеличения. При чем код на Эрланге, будет плохо расширяемым потому, что слушателей изменения свойства еще как-то нужно будет добавлять.
А вот как с этим кодом связан пример на js я не понимаю ;( После выполнения foo.bar=200 все слушатели магическим образом узнают об этом?
на всех нодах, ага :) Наш собеседник, видимо, рассматривает случай, когда все живут в одном адресном пространстве и модифицируют там данные. А ведь всем давно известно, что конкуррентное программирование в таком стиле является таким суровым трешем, что монады со стрелками курят в сторонке.
В Яваскрипте слушатели не нужны - любая функция, которая захочет получить новое значение foo.bar просто к нему обратится и прочитает. Просто Эрланг этот этап еще не осилил, и нужно за него доделывать.
> Вместе с эвенотом посылать [...] - да, конечно, а вы в курсе, что это копирование по значению? Т.е. зафигачить в каждый процесс, которому нужно статус одного человека, или там фамилию его всю базу данных? Это афигеть какое изящное архитектурное решение! count(sql_querry("select * from users")) не напоминает?
И да, ваш подход с разделяемым состоянием является полной лажей при работе в распределённой неоднородной среде, на которую и нацелен erlang. А эффекты на страничках с его помощью делать никто и не собирался.
можно ещё
USER_CHANGED (field: "NAME", was: "Mark", become: "Markus")
Так что спасибо за попытку, но вам еще опыта не хватает советы давать.
Забавно слышать это от человека, ратующего за глобально разделяемое состояние. Это хоть как-то работает с STM при работе на нескольких ядрах, но map/reduce на этом не построишь. Ок, отложу текущую книжку и почитаю "Programming Erlang", всё равно давно собирался. Но что-то мне подсказывает, что инженеры Ericsson получше вас разбираются, какой язык им нужно использовать для построения сложных распределённых отказоустойчивых систем.
Глобальное состояние, один поток, нет блокировок - Redis. Быстрый как дьявол, но при масштабировании возникает много проблем, поэтому нормальный кластер мы увидим не скоро.
Глобальное состояние, много потоков с блокировками - жуткий треш, написать такое приложение правильно почти невозможно, нужно быть гуру и знать много магии и заклинаний. Типичная Java. Масштабируется, но нужно много рукописных штук.
Глобальное состояние, много потоков, STM - Clojure. Есть оверхед, но облегчает многопоточное программирование примерно так же, как GC облегчает обычный труд программиста. Масштабируется, но опять же только ручками.
Распределённое состояние, легковесные потоки (акторы) - Scala, Akka, Erlang. Надёжно, прекрасно масштабируется, но до определённого момента оверхед перекрывает преимущества. Руками писать не много, почти всё на себя берёт рантайм.
О каком распределенном состоянии идет речь? В Эрланге нет вообще никаких нормальных инструментов для инкапсуляции состояния - откуда такие мысли появляются? Кто-то написал рекламную статью? - ну так мало ли, чего там написано. Я уже одного такого доверчивого видел, год промучался, слава богу ушел - вспоминаю, как в страшном сне. Вроде и команда была не самая худшая, да и человек с опытом и все такое - сервер на Эрланге за год моего с ним знакомства может дней 5 проработал подряд максимум. А так, обычно, каждое утро были разборки почему всю ночь сервер лежал. Это уже прям до истерии доходило. Любой индус-старшекласник на Яве бы слепил то же самое, и работало бы с меньшими накладками.
ФП не приспособлены решать задачи в изменяющемся стохастическом окружении, либо они должны "жертвовать принципами" (нужными только фанатам), после чего выясняется, что кроме этих ненужных принципов, ничего там полезного и не было.
> Руками писать не много
имеется в виду для реализации именно масштабирования
Его написал человек, который был восновном ответсвенным за ЯваСркипт, а Питон видел впервые в жизни (использовался Twisted). Т.е. написал его "случайно" - ну попросили - сделал, типа работает. Я когда понял на сколько нашему Эрланговому серверу далеко до того, что было сделано в полпинка на Питоне - ржал до колик.
У Ericsson очень жёсткие требования к системам, и обработка сетевого трафика поднята на уровень state-of-art. Я видел всё это изнутри, и знаю, о чём говорю.
Failover с различными схемами репликации на случай выхода из строя аппаратуры, системы обновления ПО без остановки обслуживания, службы распределённых транзакций, real-time база данных.
Траффик не должен останавливаться ни на минуту. Если сгорает плата, активируется другая, причём клиент даже не потеряет соединения. Жёсткие требования к производительности, при добавлении фич performance degradation недопустим. На подготовку специалиста, не знающего системы, уходит 2-3 месяца.
Наш сервер был написан на C, хотя для работы нужно было знать архитектуру всей системы. И знаете, сервер мало чем отличается от программы на эрланге: бесконечный цикл, получающий сигнал, а дальше switch по номеру сигнала, извлечение аргументов и вызов нужного обработчика.
Процесс не должен хранить лишь минимум локального состояния, иначе при его падении репликант не сможет восстановить это состояние. Состояние хранится в отказоустойчивых контейнерах.
Реализация системы исполнителями, конечно, иногда хромает, но в плане архитектуры и требований к системе трудно предъявлять какие-то претензии.
И да, поток трафика так велик, что к моменту моего ухода заканчивалась разработка кластера из 72 серверов, способного прикидываться, в переводе на tcp/ip терминологию, одним хостом.
Если уж кто и понимает толк в распределённых отказоустойчивых системах, так это инженеры Ericsson (кстати, классные ребята).
А вы... вы ведь пишете на ActionScript, верно? :)
Возможно в среде, специально подготовленной для работы с Эрлангом, где все окружение подходит (например, сохранять нужные данные куда-нибудь отдельно от самой программы - дешево, типа как во встроенной базе данных, и получать их из хранилища, опять же дешево) можно приспособиться - но при том, что имелось в наличие - около 30 арендованых серверов с обычным набором ПО рассчинаным на веб разработку ничего такого не имелось. И в этой ситуации Эрланг не юзабельный по сравнению с чем угодно, именно потому, что сам данные хранить не умеет. Мы пытались как-то научить его работать с Memcached - потому что нам второре было нужнее, но ничего хорошего из этого не вышло.
Еще из "фактов" про язык - отладчик никакущий, сравним по убогости с каким-нибудь Firebug отладчиком или что-то такое. В порядке шутки - выполнение не останавливается в точке останова. Останавливается только процесс, который содержит точку останова. В такой ситуации отладить работу с сокетом - цирк да и только. Профайлера памяти нет в принципе, о том, что происходит в программе приходится догадываться используя инструменты общего характера (есть fprof но он меряет только скорость работы).
Т.е. для каких-то узко-специальных задач, при наличие очень специфических сопровождающих инструментов - возможно (но у менят таких даже быть не могло). Но как инструмент общего назначения - никак.
произвёл беглый обзор языка
вроде бы у каждого процесса в erlang есть "process dictionary" - внутренняя хэш-таблица процесса, выступающая в роли хранилища мутабельного состояния процесса.
Т.о., не разрешено лишь разделение данных между процессами (что вполне логично, учитывая проблемы, связанные с многопоточным программированием), а сам erlang довольно далёк от той чистоты, которую предлагает Haskell, и к которой у вас столько претензий.
Кстати, в последнее время замечаю за собой тенденцию передавать на вход методам интерфейса иммутабельные объекты, содержащие информацию, необходимую для работы сервиса. Фактически и получается строгая инкапсуляция и завуалированная передача сообщений.
Заметил это за собой давно.
Или вы может быть все-таки создаете свойство со ссылкой на подключение, и обращаетесь к этом свойству повторно, когда возникает такая необходимость? - вот последнее, это как раз то, что нет возможности сделать в Эрланге.
>Вместе с ивентом послать [...]
А почему нет? Структуры в эрланге иммутабельны, их пересылка бесплатна (мы заплатили при их "модификации").
Процессы в Эрланге - это "развод". Их очень дешево создавать, но как только приходит время их для чего-нибудь полезного использовать оказывается офигеть как дорого - сразу все желание пропадает.
Это не приводит к противоречиям как раз за счёт иммутабельности структур.
Пример - Data.Map из Haskell. При добавлении в таблицу новой пары ключ-значение происходит дублирование лишь небольшой, как правило, пренебрежимо малой части данных.
Так что печальные истории про пересоздание списков с нуля попахивают всё-же неосиляторством.
На эрланге пока не писал, но из моего опыта со Scala, где используется похожая модель акторов, следует, что каждый актор должен нести ответственность за свой функционал, и лавинообразное обновление данных при смене статуса выглядит подозрительно.
Но, разумеется, вашего проекта я не видел и могу чего-то не знать. В Scala всё же можно использовать мутабельные структуры при желании.
Актор - это, по сути, правильная интерпретация объекта в ООП: синхронно общается с другими объектами через очередь сообщений.
А jQuery это монада или нет? Хотя ясно что используется оно совсем не в хацкельных целях - для рассовой чистоты функций.
Но все же идея монад, как неких абстрактных стратегий для вычислений цепочек операндов вполне жизнеспобона
>Агрессия - признак баттхёрта.
Не всегда. Зачастую агрессия и треш используются умышленно, для увеселения публики.
Что можете посоветовать почитать по ним?
Вот кстати в Nemerle так и есть:
http://ideone.com/KEcLr
Синтаксический сахар это.
(И запись в виде отображения f: X -> Y -- находит свой образ в сигнатурах).
Так оно там изначально и появилось, только запись там немного другая
В Scala вон для каррирования сделали функции с несколькими наборами аргументов. По мне так запись в Haskell удобнее и нагляднее.
>Он изменил мой взгляд на мир.
А вот можно поподробней - какие именно там революционные идеи и концепции, которых больше нигде нету.
> которых больше нигде нету.
я не говорил, что этих идей и концепций нигде больше нету, они просто образуют суровый замес
Иммутабельность, чёткое разделение чистого кода и кода с побочными эффектами, концепция "всё - выражение", ленивость всех вычислений (ввод/вывод тоже ленивый, кстати), строгая статическая типизация (по началу реально удивляешься, когда программы работают сразу же после того, как начинают компилироваться), pattern-matching, внедрение математических концепций в язык, мощная и удобная система модулей. Type Classes меня тоже очень впечатлили (в clojure сделали аналоги - протоколы).
Не срача ради, но токмо в просвещения целях.
Так а вот что конкретно привлекло в языке и взорвало мозг? Или всё и сразу.
>В смысле монад - нет, ни разу, никто не мешает их реализовать в Яваскрипте
Нам нужно сделать асинхронный вызов. Найти например id человека, а потом сделать другой вызов - по этому id получить деталировку итд.
js-способ - вложенные друг в друга callbackи.
Монадический же подход - когда результат одного асинхронного вызова передается в другой, разворачивает и упрощает код.
Кстати, я вот не знал, что такое afaiu, а гугл - он все знает.
Haskell не исключает код с побочными эффектами (иначе его нельзя было бы использовать в принципе), он просто призывает программиста максимально отделять чистый код от кода с побочными эффектами (так, чтобы даже компилятор мог понять, где какой).
Ну не будем так категоричны. Например юниксовые утилиты типа sed, grep, tail вполне могут работать без побочных эффектов, принимая на stdin данные, и возвращая ответ в stdout. Так что код без побочных эффектов использовать можно, но, конечно, далеко не всегда.
А вообще да, архитектура "фильтры и потоки" функциональна по своей природе.
http://govnokod.ru/10265#comment138049
(а если присутствуют воинствующие любители лишпа - вообще задорно).
или Оберона-2, хотя-бы