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