Хаскельное

[metaclass]

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

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

Comments

[metaclass.livejournal.com]

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

[dr-cha0s.livejournal.com]

А я не представляю как можно жить говоря только намёками. Наше общение напоминает анекдот:
— Приборы!
— Двести!
...
— Что двести?
— Что приборы?!

Собственно какие именно диаграммы интересны из не ФП мира? Их же мягко говоря... очень много.

[dr-cha0s.livejournal.com]

Rational Rose!

Вообще мне не интересно сейчас тюнить свои мелофон. Пусть уж дон скажет чего никто не знает как делать для хаскеля из диаграмм.

[metaclass.livejournal.com]

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

[thesz.livejournal.com]

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

[theiced.livejournal.com]

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

[vit-r.livejournal.com]

Почему?

[vit-r.livejournal.com]

Благородный дон готов на Хаскеле реализовать диаграмму классов с приватными параметрами?

[vit-r.livejournal.com]

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

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

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

[metaclass.livejournal.com]

В хаскеле не нужно (хоть и можно) реализовывать, во первых классы, во вторых, приватные параметры (поля?)

[berezovsky.livejournal.com]

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

[dr-cha0s.livejournal.com]

Она, внезапно, отвечает на вопрос "зачем?" ?

[thesz.livejournal.com]

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

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

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

[vit-r.livejournal.com]

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

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

[vit-r.livejournal.com]

Ох. Для тех, кто на танке, это был контрпример к предыдущему заявлению.

[vit-r.livejournal.com]

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

[thesz.livejournal.com]

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

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

[antilamer.livejournal.com]

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

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

[antilamer.livejournal.com]

Про то, что "никто" не заморачивается комментариями: это интересное заявление; какую методологию Вы бы предложили, чтобы это проверить?

[vit-r.livejournal.com]

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

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

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

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

[vit-r.livejournal.com]

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

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

Ну да, я вижу только то, что попадается в Интернете, и где-то в какой-то фирме внутри может быть что-то подобное. Но, следуя определению вакуума в физике, для меня это не существует.

[antilamer.livejournal.com]

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

[vit-r.livejournal.com]

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

[antilamer.livejournal.com]

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

[antilamer.livejournal.com]

> Когда я увижу отраслевой или хотя бы внутрифирменный стандарт
Странный критерий. Вот если thesz внедрит у себя в фирме такой стандарт, то возьмёте "никто" назад? :)

А почему не "когда я увижу проект на хаскелле с разумным количеством комментариев" ("разумным" = "не хуже, чем в среднем по индустрии в других языках")? Например, GHC или XMonad отлично прокомментированы.