Хаскельное

[metaclass]

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

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

Comments

[thesz.livejournal.com]

Методики уменьшения дефектов (любого рода) не имеют отношения к языку программирования.

[vit-r.livejournal.com]

Почему?

[thesz.livejournal.com]

Потому, что это практика уменьшения дефектов. Приемы ее работают вне зависимости от ЯП.

Пересмотр кода перед компиляцией уменьшает количетво дефектов, пересмотр кода перед коммитом или отправкой на код ревю уменьшает еще, непрерывные интеграционные тесты еще уменьшают и тп.

ЯП вносят определенные ошибки, которые надо выявлять после разбора причин пропущенного дефекта. Дефекты, опять же, специфичны для предметной области - где-то деление на два вместо трех вполне пройдет. Опять же, здесь нет жесткого задания ЯП.

[vit-r.livejournal.com]

Если мы говорим о железе, без конкретного языка не обойтись. То же будет, если требования по производительности или чему-то подобному.

Насчёт предложенных практик я комментировать не буду, но имелось ввиду что-то более существенное.

[thesz.livejournal.com]

О каком железе? Какие требования по производительности?

"Более существенное" (видимо - подробное?) сильно зависит от проекта. Натурально.

[antilamer.livejournal.com]

Какие Вы знаете элементы процессов разработки надёжного ПО на си, которые не применимы к хаскелю? (ну, кроме "наличия компилятора, сертифицированного государством")

P.S. Интересно, какими процессами пользуется http://corp.galois.com/about-us/ , пишущие вроде как сверхнадёжный софт, и пишущие его в основном на хаскелле.

[vit-r.livejournal.com]

которые не применимы к хаскелю?

Ну, например, построчная проверка заказчиком. :-D

Я с Хаскелем не работаю, так что не знаю, что там есть. Пока что на вопросы про сто процентное покрытие кода тестами и про графическое представление структуры программы вразумительных ответов я не получил.

А "вроде бы сверхнадёжный софт" - это сколько часов наработки на отказ и какая цена ошибки?

[antilamer.livejournal.com]

Coverage есть http://www.haskell.org/haskellwiki/Haskell_program_coverage#What_is_hpc.3F
Про софт можно на сайте почитать и в списке заказчиков.

[vit-r.livejournal.com]

Вопрос был не про "покрытие", а про "стопроцентное покрытие". Это вещи разные принципиально.

[antilamer.livejournal.com]

В чём разница?

[vit-r.livejournal.com]

В том же, в чём разница между надёжностью .99 и .999 - в сложности достижения.

[antilamer.livejournal.com]

Я не понимаю. Для хаскеля есть инструмент, позволяющий измерять покрытие. Хотим .999 - покрываем тестами, пока он не покажет .999. Где тут разница между хаскелем и си?

[vit-r.livejournal.com]

Измерять - это не проблема. Проблема - сделать. На си и си с крестами я 100% видел.

[antilamer.livejournal.com]

То есть вопрос не в языке и инструментарии, а в том, какие проекты на этом языке лично Вы видели?

[geniepro.livejournal.com]

библиотека SQLite, написанная на сях, имеет покрытие в 1084 строк тестов на каждую строку кода, но и это не спасает её от того, что время от времени в ней таки находятся баги...

[(Anonymous)]

Статические анализаторы кода для Хаскеля есть?

В Хаскеле, к примеру, не нужно ставить const перед ссылками на структуры, которые передаются в функции. И не нужно опасаться неявного приведения типов.

[thedeemon.livejournal.com]

>Статические анализаторы кода для Хаскеля есть?

Да, они там называются "компилятор".

[rdia.livejournal.com]

> Да, они там называются "компилятор".

Т.е. нет. В отличие от компилятора, статический анализатор

1. не ограничен во времени => может проводить более глубокую проверку кода.

2. имеет право на ошибку - предупреждения статического анализатора любой степени серьёзности могут быть ложными.

Поэтому статический анализатор может, в отличие от компилятора, ругнуться на условный код

let 2d_distance_from_origin {x : float; y : float; z : float} in
let x = p.x in
let y = p.z in
x^2 + x^2;;

Ну и тому подобные, формально верные конструкции, которые часто могут быть следствием опечатки.

И, хотя, Хаскел значительно лучше С, от подобных вещей он не защищает.

[geniepro.livejournal.com]

Был как-то тест, в котором в программы на разных языках вносили случайные опечатки, и смотрели, у кого компилятор больше таких ошибок обнаружит.
Хаскелл оказался защищён от таких ошибок гораздо хуже, чем с++ )))

[thesz.livejournal.com]

data X
data Y
data Z

data Coord c a = C a -- c - phantom type, does not add runtime overhead.
instance Num a => Num (Coord c a) where ... -- you cannot add Coord X Float and Coord Y Float
type Vec a = (Coord X a, Coord Y a, Coord Z a)
field :: XYZ b => Vec a -> b -> Coord b a
field = ...

f p = let x = field p X; y = field p Z in x*x + castFromY (y*y) -- compiler error

[rdia.livejournal.com]

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

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

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

[thesz.livejournal.com]

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

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

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

[rdia.livejournal.com]

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

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

[thesz.livejournal.com]

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

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

[geniepro.livejournal.com]

Есть что-то типа того:

http://hackage.haskell.org/package/hlint