Хаскел не сложнее Пролога. Но он
1) подкупает видимой схожестью прогамм с алголовскими
2) не прощает ошибок
В результате первого пункта начинающие решают ничего не читать, а "врубиться интуитивно", и у них даже что-то получается — многие программы на Хаскеле можно читать и писать так, как будто это call-by-value language, а не graph rewriting system.
Но при попытке написать что-нибудь большое и красивое сталкиваются с утечками и некомпилируемости программ ("борьба с тайпчекером").
Тогда они, по-прежнему уверенные, что всё просто, начинают читать статьи от таких же невежественных долбоебов, пытающихся объяснить на пальцах GRS, монадический ввод-вывод и систему типов. И получается у них "вычисления по требованию", "контейнеры-скафандрики", "лямбда-исчисление с нормальным порядком редукции", "списки экшенов", "значения с сайд-эффектами имеют тип IO" и прочая ересь и полуправда.
( http://nponeccop.livejournal.com/153019....
13 comments
recommend
bookmark
subscribe
утечки памяти в хаскеле?! нет пути :(
Утечки памяти и в джаве бывает, все зависит от степени кривизны рук.
но это же пиздец!
Да не умеешь писать программы — не берись, ёба!
хотел попрбовать осилить хаскель только потомучто програмки на нём выглядят упорото, и, считал ранее, что gc у них работают нормально, но теперь :(
Да причем тут gc?
Начинать программу с надеждой на gc — ебанатство в высшей степени.
скажи это лисперам
имеются в виду не утечки в смысле C, а избыточное количество промежуточных объектов в памяти. GC в GHC очень хороший, но не волшебный; оптимизируется многое, но не всё
Я думаю, можно, как в случае с жабой, создать острова.
острова?
Ну islands of isolation
плавающие острова в памяти! в лучших традициях каких-то там панков или еще каких романтиков
от проблемы это не избавит. если у тебя где-то ленивое рекурсивное вычисление, то пока оно не дойдёт до базы рекурсии, все промежуточные замыкания будут висеть в памяти: на них будут ссылки. собственно, утечки в смысле Haskell — это, как правило, ленивые вычисления над строгими данными или наоборот