Re: Стабильная система?
Артём Н. -> debian-russian@lists.debian.org @ Thu, 01 Oct 2015 18:36:54 +0300:
>> >> АН> Offtopic:
>> >> АН> А что кто-то реально использует Haskell?
>> >>
>> >> Да. И на данный момент я его считаю лучшим вариантом по соотношению
>> >> затрат на разработку и уверенности в результате, с БОЛЬШИМ отрывом от
>> >> конкурентов.
>> >>
>> АН> А, если не секрет, для разработки чего и, что важно, кем, а также для кого?
>>
>> В одном месте это часть разработки авиационных тренажеров.
АН> "Сухой" или МАНС?
Транзас-Авиация.
>> На хаскеле написан имитатор изрядно интеллектуального прибора, не имеющего не
>> только четкой модели, но и достаточной для имитации документации.
АН> Хм... Экспертная система? Нейронная сеть?
Нет, там навигационный компьютер с пищалками и перделками, плюс
отображение приборов (в выбранной системе единиц и с выбранным языком),
плюс морда от системы прицеливания.
>> Приходится много рефакторить, когда выясняется, что вот тут он ведет
>> себя совсем не так, как мы раньше думали. Хаскель спасает от дилеммы
>> "много молиться или писать тестов в разы больше, чем работающего кода".
>>
АН> Каким образом спасает?
АН> Разве для ФП не требуются тесты?
АН> В чём отличия.
В том, что для достижения того же (высокого) уровня уверенности в
работоспособности кода тестов требуется на порядок меньше. Не квадрат
от размера кода, а линейно.
А для достижения приемлемого уровня уверенности можно вообще без тестов
жить. У меня в том проекте за три года работы и минимум трех крупных
рефакторингах раза три-четыре вылезали ошибки типа "перепутал ветки then
и else" или "перепутал плюс с минусом". Остальное ловилось системой
типов на стадии компиляции и изредка - первым же ручным прогоном того
места, где менялась функциональность. Тестов у хреновины нет вообще.
Хреновина при этом оказывается одним из самых надежных мест в тренажере.
Тестов там вообще почти нет, надо сказать. Потому что работать они
начинают тогда, когда их квадрат от размера кода, а кода в проекте
много.
АН> По факту минуса два: мало людей на нём пишет и поймёт написанное
Мне хватает.
АН> и скорость выполнения всё-таки ниже C++ (но это не всегда минус).
У меня есть знакомый программист, который мерил. Зачастую сборка ghc
превосходит по скорости C, а C++ (если на нем пишут как на плюсах, а не
чисто как на C с чуть более удобным синтаксисом) так и как правило
(вероятно, потому что если писать как на плюсах, то будет довольно много
выделений памяти, которые по умолчанию защищены мутексами, а также из-за
неоптимизируемых разыменований виртуальных функций). В Глазго
оптимизировать тоже умеют, а иммутабельность и статическая типизация
открывают куда более широкие возможности для оптимизации.
Это он писал обработку мощного потока информации, на плюсах на имевшейся
технике уже требовавшую ручного тюнинга параллелизации.
>> Непосредственный заказчик - работодатель, а потребитель тренажера и
>> критик, если что-то работает не так, как в настоящей машине - летчик.
>> Это ответ на вопрос "для кого".
>>
АН> Вопрос был к тому, что вакансий на Haskell я не видел.
Так на Haskell не индусы пишут. В смысле, человека берут решать сложную
задачу, а на чем он ее решает - это уже его личное дело. Задача
сложная, "программист на XXX" ее не решит.
И я, когда ищу себе работу, тоже не ищу вакансии "программиста на YYY".
Потому что это вакансии для негров, у меня тупая монотонная работа плохо
получается. Я ищу вакансии разработчика ПО, где надо думать головой.
>> В другом месте веб-сервер, встраивающийся в существующий и без того
>> нетривиальный бизнес-процесс, и добавляющий еще своей нетривиальности.
>> Попытка сделать его на рельсах мне не понравилась - трогать страшно,
>> сейчас переписываю на yesod.
>>
АН> Любопытно уже хотя бы то, что он не умер и не остался эзотерическим языком,
АН> а вполне стабильно обрастает инфраструктурой...
АН> Плотно ФП руки не доходили заняться (на началах Lisp, это всё и закончилось).
В мире довольно много людей с развитым абстрактным мышлением. Для
программирования на хаскеле нужно именно оно, но если оно есть, то на
хаскеле намного удобнее, чем на альтернативах. ocaml еще рядом, и там
тоже инфраструктура есть, хотя вроде бы не такая богатая. Но он, как я
понимаю, похуже тем, что мутабельный.
Reply to: