Thursday, December 07, 2006

Haskell In Action

Написание на хаскеле не миниатюрных экспериментальных примеров, а чего-нить более-менее серьезного и в конкретные сроки оказалось не таким уж простым процессом. Кто бы мог подумать :)

Открытия:

  • typechecker не спасает от семантических ошибок :) Черт, я в глубине души надеялся что если прога компилится, значит она работает правильно..
  • возникновение косяков с размерностью типов в битовых операциях. Мне на интуитивном таком уровне казалось, что это проблема возникает в С из-за автоматических преобразований типов -- ан нет :)
  • mutable массивы в хаскеле, языке без side effects и со строгой типизацией -- это такой космический хайтек.. :)
  • "ленивость" вычислений все еще неиссякаемый источник сюрпризов для меня и в плане производительности, и в плане сообщений которые выводятся с помощью Debug.trace :)
  • unit тесты это просто таки жизненная необходимость в хаскеле, и писать их намного легче и приятнее чем в C++.

to be continued, как говорится..

6 comments:

migmit said...

> Черт, я в глубине души надеялся что если прога компилится, значит она работает правильно..

Ну, в определённом смысле так и есть. Тут есть два пути: либо исправить ошибки, либо попытаться понять, что именно программа делает правильно.

Anonymous said...

Да, к сожалению, никакой язык не умеет думать за программиста :)

А массивы и битовые операции -- это пожалуй то, в чем C является непревзойденным языком (по крайней мере в плане производительности кода). Хаскел для этого не предназначен. Для этого есть FFI :).

Еще возможные грабли:
- можно слишком сильно увлечься type class-ами, и тогда код будет похож (по сложности и несопровождаемости) на плюсовый template metaprogramming.
- можно обрадоваться удобству списков и кортежей, и с потрясающей скоростью плодить несопровождаемй код (типа foo :: ([(a,(b,[c]),d)],e,:)).

В целом, хаскел позволяет быстро писать относительно короткие и сопровождаемые программы. Но хаскел - это язык и им как и любым инструментом надо уметь пользоваться. Software engineering еще никто не отменял.

lrrr said...

Не, кстати, с битовыми операциями проблема оч похожа на C -- для выражений иногда выводятся не те типы, которые хотелось..

А пик увлечения typeclass'ами я вроде уже пережил, любовь к перегрузке функций это, по-моему, такой синдром пост-C++ программера :)

Anonymous said...

Про синдром, это хорошо сказано :)

Я как-то даже type level physical values сделал. С одной стороны круто: кг*м/с^2 получается ньютон, и метры с килограммами не сложишь - компилер ругается. Можно хаскел для перевода единиц измерения использовать. Но только вот код, который получился... В некоторых местах сильно пугает :)

А вот насчет вывода не тех типов не понял. Можно какой-нить простенький пример?

lrrr said...

>Можно какой-нить простенький пример?
Ну элементарные ошибки, когда в битовое выражение где-то закрадывается переменная с типом Word8, из него компилятор выводит не тот тип для результата, который я предполагал :)
(там в Data.Bits очень много функций типа a -> Int -> a)

Еще сложнее это обнаружить когда все эти битовые выражения были обернуты в fromIntegral на каком-то этапе..

migmit said...

Для битовых операций - лучше Erlang пользовать. Самое тру.