Артём Н. -> 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 нишевый по назначению, для программирования общего назначения на нем писать неудобно.
