Хаскельное
Sep. 14th, 2013 08:17 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
metaclasshttp://vit-r.livejournal.com/679524.html?thread=3691364#t3691364
решили на прошлой работе трое таки попробовать Хаскель, для неспешной задачи. генерация DDL, DML c скриптами SQL. Бились, бились, - но сделали, и был восторг! Потом, затянула обычная работа, через месяцок нужно было добавить кое-чего... и никто из троих не смог понять как оно работает, и как же добавить.
Звучит похоже на правду. Хотя у меня и F# и Clojure в подобных задачах живут и развиваются без проблем.
решили на прошлой работе трое таки попробовать Хаскель, для неспешной задачи. генерация DDL, DML c скриптами SQL. Бились, бились, - но сделали, и был восторг! Потом, затянула обычная работа, через месяцок нужно было добавить кое-чего... и никто из троих не смог понять как оно работает, и как же добавить.
Звучит похоже на правду. Хотя у меня и F# и Clojure в подобных задачах живут и развиваются без проблем.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2013-09-14 04:58 pm (UTC)no subject
Date: 2013-09-14 06:01 pm (UTC)no subject
Date: 2013-09-14 06:40 pm (UTC)Пересмотр кода перед компиляцией уменьшает количетво дефектов, пересмотр кода перед коммитом или отправкой на код ревю уменьшает еще, непрерывные интеграционные тесты еще уменьшают и тп.
ЯП вносят определенные ошибки, которые надо выявлять после разбора причин пропущенного дефекта. Дефекты, опять же, специфичны для предметной области - где-то деление на два вместо трех вполне пройдет. Опять же, здесь нет жесткого задания ЯП.
no subject
Date: 2013-09-14 06:49 pm (UTC)Насчёт предложенных практик я комментировать не буду, но имелось ввиду что-то более существенное.
no subject
Date: 2013-09-14 07:10 pm (UTC)"Более существенное" (видимо - подробное?) сильно зависит от проекта. Натурально.
no subject
Date: 2013-09-14 07:39 pm (UTC)P.S. Интересно, какими процессами пользуется http://corp.galois.com/about-us/ , пишущие вроде как сверхнадёжный софт, и пишущие его в основном на хаскелле.
no subject
Date: 2013-09-14 07:57 pm (UTC)Ну, например, построчная проверка заказчиком. :-D
Я с Хаскелем не работаю, так что не знаю, что там есть. Пока что на вопросы про сто процентное покрытие кода тестами и про графическое представление структуры программы вразумительных ответов я не получил.
А "вроде бы сверхнадёжный софт" - это сколько часов наработки на отказ и какая цена ошибки?
no subject
Date: 2013-09-14 08:25 pm (UTC)Про софт можно на сайте почитать и в списке заказчиков.
no subject
Date: 2013-09-14 08:28 pm (UTC)no subject
Date: 2013-09-14 08:34 pm (UTC)no subject
Date: 2013-09-14 08:37 pm (UTC)no subject
Date: 2013-09-14 08:46 pm (UTC)no subject
Date: 2013-09-14 09:02 pm (UTC)no subject
Date: 2013-09-14 09:10 pm (UTC)(no subject)
From:no subject
Date: 2013-09-16 10:19 am (UTC)(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2013-09-15 04:42 am (UTC)В Хаскеле, к примеру, не нужно ставить const перед ссылками на структуры, которые передаются в функции. И не нужно опасаться неявного приведения типов.
no subject
Date: 2013-09-16 03:58 pm (UTC)Да, они там называются "компилятор".
no subject
Date: 2013-09-16 06:04 pm (UTC)Т.е. нет. В отличие от компилятора, статический анализатор
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;;
Ну и тому подобные, формально верные конструкции, которые часто могут быть следствием опечатки.
И, хотя, Хаскел значительно лучше С, от подобных вещей он не защищает.
no subject
Date: 2013-09-16 07:24 pm (UTC)Хаскелл оказался защищён от таких ошибок гораздо хуже, чем с++ )))
no subject
Date: 2013-09-16 09:20 pm (UTC)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
no subject
Date: 2013-09-16 09:43 pm (UTC)Подобную же штуку можно криво-косо сделать на С++, только овчинка выделки не стоит. Из-за раздутия кода вы сделаете ещё пару ошибок и т.д. Ухудшите ясность.
Я не спорю, что проверки в Хаскелле значительно круче, чем проверки в С++. Но в любом языке остаётся круг ошибок, которые не являются достойными занесения в компилятор, но вполне известны и часто повторяемы.
no subject
Date: 2013-09-17 04:24 am (UTC)В Хаскеле я могу ограничить круг пропускаемых ошибок чрезвычайно малым числом. Библиотекой, не компилятором. Ну, и что, что в C++ так нельзя?
Насчет "как норму считать" - отдельной функцией, верифицированной. Как это делается в обычных библиотеках.
no subject
Date: 2013-09-17 01:21 pm (UTC)Со стат. анализатором наверняка можно будет ещё больше ограничить. Но пока, видимо, кол-во ошибок слишком мало по сравнению с конкурентными языками. Поэтому создание стат. анализатора для Хаскеля нерентабельно.
no subject
Date: 2013-09-17 01:47 pm (UTC)В зависимых типах вы можете ограничить себя так, как хотите и компилятор совершенно эквивалентен статическому анализатору.
no subject
Date: 2013-09-16 07:28 pm (UTC)http://hackage.haskell.org/package/hlint