metaclass | Хаскельное

Хаскельное

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

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

Flat | Top-Level Comments Only

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

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

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

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

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

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

Edited 2013-09-14 19:45 (UTC)

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

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

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

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

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

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

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

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

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

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

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

Вопрос в том, что я не предстваляю, как то же самое сделать на Хаскеле. Вопросы к гурам дают ответы как по ссылке в другой ветке.

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

Тестами нелзя доказать отсутствие багов. По-моему, это азбука.

Да, и "покрытие 100%" - это не соотношение строк тестов к строкам кода, а доказательство, что в тестах проверятся каждая строка кода.

(no subject)

thedeemon.livejournal.com - 2013-09-16 15:56 (UTC) - Expand

(no subject)

metaclass.livejournal.com - 2013-09-16 16:10 (UTC) - Expand

(no subject)

thedeemon.livejournal.com - 2013-09-16 16:25 (UTC) - Expand

(no subject)

vit-r.livejournal.com - 2013-09-16 21:20 (UTC) - Expand

(no subject)

rdia.livejournal.com - 2013-09-16 18:07 (UTC) - Expand

(no subject)

vit-r.livejournal.com - 2013-09-16 21:31 (UTC) - Expand

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

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

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

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

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

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

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;;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Flat | Top-Level Comments Only