Хаскельное

[metaclass]

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

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

Comments

[thesz.livejournal.com]

У меня к каждой функции высшего уровня по несколько строк комментариев. В каждом файле есть шапка с названием, назначением (одна и более строк) и копирайтом. Это нормальная практика, я ее ввел для себя после разбирательств с gcc.

Плохой код можно найти везде. Вы сравниваете код, который вы контролируете (с комментариями) и чей-то ещё. Контролируйте код на Хаскеле, все будет хорошо.

[vit-r.livejournal.com]

Я сравниваю код, который я вижу в разных проектах и от разных людей. Это раз.

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

[metaclass.livejournal.com]

А что за методики? И применяет ли их кто-нибудь на практике?

[vit-r.livejournal.com]

Ответ на последний вопрос - да! Применяют. Потому что много таких мест, где, если не будут применять, им не дадут бумажку, без которой они заказ в принципе не получат.

Насчёт же первого вопроса - их дофига. Сейчас вот вижу, как люди из Simulink код генерируют. Видел разные адаптации структурных методов. Видел самодельные. Хороший стандарт о том, как можно и нельзя делать софт - это толстый том с многими сотнями правил и разъяснений. Плюс есть тулы, которые позволяют проконтролировать всё, вплоть до значений регистров на целевой платформе.

[metaclass.livejournal.com]

А, это значит только с деньгами из тумбочки и бесконечными проектами работает.
У обычных софтовых контор ни времени ни бюджета не будет на то, чтобы епамские индусы этим стандартам следовали да тулы изучали.

[theiced.livejournal.com]

да не слушай ты - видно же что пидорас-попильщик.

[vit-r.livejournal.com]

Ну не то, чтобы из тумбочки, и не то, чтобы бесконечными, но на проект выделяется столько, сколько он стоит. Потому что цена ошибки на порядок выше любых методов её предотвращения.

И индусов там нет, по крайней мере в тех местах, где это работает. В одном месте даже дали индусам написать быстро и дёшево прототип, а потом его выкинули и сделали как положено.

Кстати, конторы тоже не "софтверные", а что-то реально производящие. Чаще всего, в железе.

[berezovsky.livejournal.com]

А в бетоне есть?

[vit-r.livejournal.com]

Мне переодически приходит рассылка с конференциями по аграрной информатике... Так что есть всё, но я отвечаю только за то, что видел.

[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]

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

[(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

[geniepro.livejournal.com]

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

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