Хаскельное

[metaclass]

http://vit-r.livejournal.com/679524.html?thread=3691364#t3691364
решили на прошлой работе трое таки попробовать Хаскель, для неспешной задачи. генерация DDL, DML c скриптами SQL. Бились, бились, - но сделали, и был восторг! Потом, затянула обычная работа, через месяцок нужно было добавить кое-чего... и никто из троих не смог понять как оно работает, и как же добавить.

Звучит похоже на правду. Хотя у меня и F# и Clojure в подобных задачах живут и развиваются без проблем.

Comments

[rdia.livejournal.com]

Это, безусловно, классный приём, но что делать, если в 3-х местах не нужно складывать, а в 4-м нужно складывать координаты? Как норму считать - ещё пару вызовов вставить?

Подобную же штуку можно криво-косо сделать на С++, только овчинка выделки не стоит. Из-за раздутия кода вы сделаете ещё пару ошибок и т.д. Ухудшите ясность.

Я не спорю, что проверки в Хаскелле значительно круче, чем проверки в С++. Но в любом языке остаётся круг ошибок, которые не являются достойными занесения в компилятор, но вполне известны и часто повторяемы.

[thesz.livejournal.com]

Я потерял вашу мысль.

В Хаскеле я могу ограничить круг пропускаемых ошибок чрезвычайно малым числом. Библиотекой, не компилятором. Ну, и что, что в C++ так нельзя?

Насчет "как норму считать" - отдельной функцией, верифицированной. Как это делается в обычных библиотеках.

[rdia.livejournal.com]

> В Хаскеле я могу ограничить круг пропускаемых ошибок чрезвычайно малым числом.

Со стат. анализатором наверняка можно будет ещё больше ограничить. Но пока, видимо, кол-во ошибок слишком мало по сравнению с конкурентными языками. Поэтому создание стат. анализатора для Хаскеля нерентабельно.

[thesz.livejournal.com]

Вы про зависимые типы слышали? Хаскель движется в ту сторону.

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