Re: Стабильная система?
Как измеряется надёжность?
Количеством, гм, ВНЕЗАПНЫХ глюков в единицу времени.
Если серьёзно говорить об измерении, это не является показателем.
не исключена просто логическая ошибка в алгоритме, которую без тестов вы не
сможете отловить (да знаю, это очевидно).
Ну да, естественно. Вот это как раз обычно лечится ручным прогоном.
Либо вы несколько противоречите сами себе, либо кода не так много.
В таком случае, чтобы проверить все пути выполнения, вам надо выполнить столько же
операций, сколько выполнят тесты. Только вручную.
Кстати, в оригинальном приборе (который стоит в реальных вертолетах)
таки благополучно перепутали в одном месте плюс с минусом, и отловлено
это было (мной) на стенде при ручном прогоне.
Фактически, в данном случае стенд являлся тестом для реальной системы,
а реальная система тестом для стенда.
Тесты, кстати, могли и не поймать - написать тест, который это ловит, весьма нетривиально.
И вручную, простым прогоном без дополнительных данных, я так понимаю, вы тоже не поймали ошибку?
Вообще мне приходилось работать в режиме TDD, когда я не знал про
хаскель. Там, собственно, я и узнал на практике, что прекрасная в
теории идея TDD на практике выражается в квадратичном количестве тестов
и многочасовом их прогоне.
Да, я тоже это знаю.
Ну, по факту, странный "спор". По-моему, вы сами прекрасно знаете, что
без тестов никогда нельзя гарантированно сказать, что система не работает
на некотором подмножестве случаев после её изменения.
И тесты нужны. Хотя писать их лень и оверхед.
Позже, уже в Транзасе, мне коллеги рассказывали, что они изначально тоже
писали тесты, и автоматически прогоняли их каждое утро, когда приходили
на работу и запускали smalltalk. Профессиональных параноиков среди низ
не было, с количеством тестов они не перенапрягались, но все равно через
несколько месяцев прогон тестов стал занимать столько времени, что был
отключен.
Может проблема в Smalltalk?
Я представил себя на месте пилота (если это не тренажёр).
Наверное, если бы летал я, для себя я бы не стал отключать тесты...
Да, и может проблема не в тестах?
Если изменяется кусок, который сильно изолирован, так ли часто надо прогонять _все_ тесты?
Благодаря иммутабельности блокировки надо делать не на каждый чих, а
только при _явной_ операции записи, которых в иммутабельной парадигме
немного.
Всё-таки принципиально ничего не меняется, и для записи они нужны...
Но да, согласен, мало - меньший оверхед и меньше вероятность получить побочный эффект.
Выше изоляция - лучше, мне тоже нравится (а многопоточность нравится не особенно
по сравнению с многопроцессностью).
>> В смысле, человека берут решать сложную
>> задачу, а на чем он ее решает - это уже его личное дело.
>> Задача сложная, "программист на XXX" ее не решит.
АН> Как правило, всё-таки декларируют определённый язык.
АН> Решите вы задачу и уйдёте.
АН> А кто будет поддерживать ваш код затем?
Поскольку задача сложная, то поддерживать будет человек со сравнимым
интеллектом. Собственно, я не единственный сотрудник Транзаса,
способный поддерживать код на хаскеле.
Но есть ещё "умение разбираться в чужом коде".
Хотя, в данном случае, наверное Хаскелю будет плюс, в целом.
Сложно найти людей, которые с ним работают, чтобы поручить
им поддерживать кусочки задачи (не думаю, что интеллект измеряется знанием или незнанием
Haskell, я вот его не знаю, так что, я автоматически попадаю у вас в категорию "тупой"?).
Человеку со сравнимым интеллектом будет дешевле выучить хаскель и
разобраться в хаскельном коде, чем разобраться в коде того же
назначения, написанном на C++, который он, предположим, уже знает.
Вероятно. Это зависит от того, кем, как и с какой целью так написан C++ код.
Есть C++ код, в некоторой степени написанный для того, чтобы показать "какая крутая у меня квалификация".
А если учитывать, что "поддерживать" часто начинается с "рефакторить",
то тут преимущество хаскеля с его "как только после рефакторинга
скомпилировалось, то почти наверняка работает правильно" становится
заметным.
Странная поддержка...
Если задача простая, то ситуация, разумеется, иная.
На C++ любую задачу возможно решить сложно.
Я пробовал, довольно много. ООП как парадигма - это duck typing
Да не обязательно. Это выражение больше напоминает Python.
И всё вытекающее: нестрогую типизации прежде всего, прототипное "наследование" и т.п..
следствие, вышеупомянутое квадратичное количество тестов. Собственно,
это оно у хорошо примененной ООП квадратичное, у спагетти-кода оно
экспоненциальное.
И на хаскеле возможно так написать. :-\
А вот
функциональная парадигма с богатой системой типов позволяет поднять
удерживаемый в голове уровень сложности задачи на следующую ступень.
Разве не проще оперировать объектами в терминах какого-нибудь DSL?
Ещё тут рядом на Erlang пытались что-то делать, не пошло.
Некому это поддерживать.
Просто людей не найти, кто станет на этом писать.
У меня коллега уехал в Швецию как раз на позицию, где был нужен Erlang.
Идет.
Не именно потому он уехал в Швецию, что специалистов фиг найдёшь? :-)
Но насколько я его понял, Erlang нишевый по назначению, для
программирования общего назначения на нем писать неудобно.
Вполне универсальный язык, насколько я знаю.
Reply to: