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