Написание на хаскеле не миниатюрных экспериментальных примеров, а чего-нить более-менее серьезного и в конкретные сроки оказалось не таким уж простым процессом. Кто бы мог подумать :)
Открытия:
- typechecker не спасает от семантических ошибок :) Черт, я в глубине души надеялся что если прога компилится, значит она работает правильно..
- возникновение косяков с размерностью типов в битовых операциях. Мне на интуитивном таком уровне казалось, что это проблема возникает в С из-за автоматических преобразований типов -- ан нет :)
- mutable массивы в хаскеле, языке без side effects и со строгой типизацией -- это такой космический хайтек.. :)
- "ленивость" вычислений все еще неиссякаемый источник сюрпризов для меня и в плане производительности, и в плане сообщений которые выводятся с помощью Debug.trace :)
- unit тесты это просто таки жизненная необходимость в хаскеле, и писать их намного легче и приятнее чем в C++.
to be continued, как говорится..
![[info]](http://stat.livejournal.com/img/userinfo.gif){kind=small}
6 comments:
> Черт, я в глубине души надеялся что если прога компилится, значит она работает правильно..
Ну, в определённом смысле так и есть. Тут есть два пути: либо исправить ошибки, либо попытаться понять, что именно программа делает правильно.
Да, к сожалению, никакой язык не умеет думать за программиста :)
А массивы и битовые операции -- это пожалуй то, в чем C является непревзойденным языком (по крайней мере в плане производительности кода). Хаскел для этого не предназначен. Для этого есть FFI :).
Еще возможные грабли:
- можно слишком сильно увлечься type class-ами, и тогда код будет похож (по сложности и несопровождаемости) на плюсовый template metaprogramming.
- можно обрадоваться удобству списков и кортежей, и с потрясающей скоростью плодить несопровождаемй код (типа foo :: ([(a,(b,[c]),d)],e,:)).
В целом, хаскел позволяет быстро писать относительно короткие и сопровождаемые программы. Но хаскел - это язык и им как и любым инструментом надо уметь пользоваться. Software engineering еще никто не отменял.
Не, кстати, с битовыми операциями проблема оч похожа на C -- для выражений иногда выводятся не те типы, которые хотелось..
А пик увлечения typeclass'ами я вроде уже пережил, любовь к перегрузке функций это, по-моему, такой синдром пост-C++ программера :)
Про синдром, это хорошо сказано :)
Я как-то даже type level physical values сделал. С одной стороны круто: кг*м/с^2 получается ньютон, и метры с килограммами не сложишь - компилер ругается. Можно хаскел для перевода единиц измерения использовать. Но только вот код, который получился... В некоторых местах сильно пугает :)
А вот насчет вывода не тех типов не понял. Можно какой-нить простенький пример?
>Можно какой-нить простенький пример?
Ну элементарные ошибки, когда в битовое выражение где-то закрадывается переменная с типом Word8, из него компилятор выводит не тот тип для результата, который я предполагал :)
(там в Data.Bits очень много функций типа a -> Int -> a)
Еще сложнее это обнаружить когда все эти битовые выражения были обернуты в fromIntegral на каком-то этапе..
Для битовых операций - лучше Erlang пользовать. Самое тру.
Post a Comment