Про ёжика в тумане, зазнайство, языки программирования и вериги

[vit_r]

Интересно наблюдать, как проповедники функционального подхода чуют расставленные ловушки и гордо в них не идут. Ещё интереснее, когда люди поддаются на троллинг.

Кинул под очередным религиозным призывом банальнейшую провокацию.

Я воспою хвалу монадам, как только увижу первый пример кода с человеческой обработкой ошибок.

(Почему это чистой воды провокация, написано ниже.)

После небольших препирательств _xacid_ оставил код. Это была тактическая ошибка. Потому что в ответе

...[всякая ажурная фигня]

val content = getURLContent("garbage") recover {
  case e: FileNotFoundException => Iterator("Requested page does not exist")
  case e: MalformedURLException => Iterator("Please make sure to enter a valid URL")
  case _ => Iterator("An unexpected error has occurred. We are so sorry!")
}

Конечно, это не обработка ошибок, а паника разных оттенков, и в нормальных случаях всё делается совсем не так, но интересно другое.

Что мы видим на картинке, если снять штукатурку и рассмотреть голую структуру?

switch error_type
  FileNotFoundException:
    "Requested page does not exist"
  MalformedURLException:
    "Please make sure to enter a valid URL"
  default:
    "An unexpected error has occurred. We are so sorry!"

То есть, пока пони какают незабудками, можно вывязывать ажурные конструкции. А как начинаются обосратушки, приходится или шагать дальше с гордо поднятой головой, не реагируя на запах и липкие штанишки (это в наше время называется «уровень качества, принятый в индустрии»), или всё-таки вызывать дядю Васю с совковой лопатой.

А иначе не получается.


Грубо говоря, обработка ошибок - это выбор альтернативных путей преобразования данных или реакций на входящие сигналы. Если, конечно, мы рассматриваем что-то существеннее падения на спину и дрыганья лапками или сообщений пользователю, которые можно смело начинать с обращения «Ей ты, козёл!».

Для адекватного выбора этих путей надо знать не только ошибку, но и контекст, в котором она произошла. Причём, разнесение контекста и обработки по разным местам кроме создания шарад чревато ещё и фатальной рассинхронизацией.

Пока мы передвигаемся в области определения математики и не заботимся о граничных случаях, контекст достаточно лёгкий. Но, чем больше столкновений с несовершенством мира, тем тяжелее он становится. И уже при достаточно небольшой нагрузке ажурные конструкции начинают уродливо выгибаться.

Практически, даже банальную рекурсию приходилось разворачивать в циклы после того, как она обрастала ветвлением на разных уровнях. Просто потому, что в плоской солидной структуре всё это выглядело гораздо лучше и логичнее.


Конечно, это не вся глубина открывающихся проблемы, а только лёгкий намёк. Математичность тянет за собой ещё много интересного.

Comments

[(Anonymous)]

Мсье, покажите теперь пожалста Ваш код

[cross-join.livejournal.com]

Да, рекурсия, обрастающая ветвлением должна быть немедленно изничтожена или переписана в смысле перепроектирования. Подтверждаю, как написавший много рекурсивных спусков - практически любой подвыперт означает хреновую грамматику или ошибку в ней.

P.S. Зачем-то ввязался в эпичный тред с гордыми своим невежеством добрыми людьми
http://vitus-wagner.livejournal.com/1124966.html?thread=38445414#t38445414

[vit-r.livejournal.com]

Всему своё время.

[vit-r.livejournal.com]

Это по нашим временам не "невежество", а "уровень экспертизы, принятый в индустрии"

[alll]

Кстати, а какие вообще наблюдаются best practices обработки "граничных случаев" в приличных местах?

[vit-r.livejournal.com]

А что можно сделать при выходе за границу допустимых значений? Это явно фатальная ошибка в логике программы, так что стандартная тактика - останов и, если возможно, попытка перезапуска, или самоликвидация, если нельзя.

Хотя, при массовой обработке можно перевести результат в ошибочное состояние, а потом его игнорировать.

А так, best people сейчас пишут монады в вебе, а туда, где обработка ошибок критична, попадают кто придётся.

[swamp-agr.livejournal.com]

Так это уже проходили.
Если рассматривать сферическую обработку ошибок в вакууме, то то на то и выходит.
Если брать во внимание контекст, то вся функциональщина неплохо разбирает классы ошибок по типам, всё это кушает и выплёвывает соответствующее стратегии поведение: пытаться преобразовывать, игнорировать или останавливать и возвращаться назад с указанием места и времени. А этот посыл относится в большей степени к ООП-погромистам, т.к. последние вообще с этой фишкой проброса ошибок вверх по стеку вызова снимают с себя ответственность и перекладывают её на других.

В моей последней софтинке покрыто множество граничных случаев и расписаны все кейсы. Видимо потому, что я не только погромировал, но ещё и собирал требования, делал анализ, генерировал тест-кейсы и данные для них. И внедрял в продакшн.

Да, путём проб и ошибок. Но это хацкель, пардон. В итоге команда заказчика, с которой пришлось взаимодействовать, не смогла написать интеграционный модуль для перегона структуры (таблиц) и данных с PostgreSQL на MySQL (ввиду изменившихся требований) за 2 недели, но хацкель с этим справился, рабочий код с чтением пользовательской конфигурации был написан за 2 часа.

[swamp-agr.livejournal.com]

Понятно, что отделив специалиста от предметной области и дав ему задание, можно прийти к интересным результатам. Интересным на один или два раза. Пока не надоест.

Потом проще дать человеку установку на погружение в контекст, делая поправки на его знание технологий и средств реализации.

А то так и получается, что драйверы под виртуальные роутеры или взаимодействие с Legacy кодом по TCP транспорту пишут люди, которые до этого писали биллинг под 1С.

[alll]

Совсем серьёзные вещи в произвольный момент останавливать как-то нехорошо, наверное. Ну там я не знаю, кардиоводитель или авиалайнер на взлёте-посадке. Впрочем там видимо больше на процедуры контроля качества стоит упирать.

[vit-r.livejournal.com]

Не надо сравнивать что-то с "не смогли", потому что проблема чаще всего лежит отнюдь не в ошибочном выборе технологий.

А преобразование структур - это математическая задача, где хорошо работают достоинства и можно не замечать недостатков. Преобразование данных - в большинстве случаев тоже. Проблемы начинаются, когда в одном столбце стоят '200' и '2o1' или при преобразовании типов возникают побочные эффекты.

Переборос ошибок в неизвестность - это не ООП, а общий тренд. Просто в процедурном подходе их игнорировали, а там, где появились исключения, как-бы обрабатывают.

[vit-r.livejournal.com]

Имеется ввиду контекст ошибки. Грубо говоря, попытка деления на ноль при обсчёте какого-то датчика может означать ошибку во входных данных, переход через порог точности, неправильные действия пользователя, ошибку в самой логике программы, разрыв соединения, по которому пришли данные, и т.п.

[vit-r.livejournal.com]

Естественно, там при тестировании проходят все варианты выхода за границу. Хотя, истребители при полёте над Мёртвым морем просто вырубали автопилот после попытки деления на ноль по высоте. Ариан просто взорвали. А в скоростных поездах у машиниста большая красная кнопка, перегружающая бортовой компьютер.

[alll]

Ариан взорвать ещё туда-сюда. Вот если б выяснилось, что кто-то Челленджер взорвал до отделения спасательного модуля - этот программист небось шибко бы прославился.

Со скоростными поездами несколько проще, кмк - там есть какая-никакая гарантия, что до следующего впереди поезда минимум N секунд, умеренно-худший случай - просто проехали мимо станции.

[vit-r.livejournal.com]

Насколько помню, в случае фатальной ошибки в поезде сразу же включается система экстренного торможения. Перезагрузка - это на случай, если какие-то функции зависли. Естественно, вручную её на ходу не делают, только во время полной остановки.

[alll]

То-есть в общем случае видимо надо запускать процедуру перехода в заведомо безопасное состояние с минимальными потерями. По возможности автономную вплоть до железа.

[anonim-legion.livejournal.com]

Ну и что это за столбец такой? Распознавали-распознавали, да не выраспознавали?

[anonim-legion.livejournal.com]

Не дождетесь.

[swamp-agr.livejournal.com]

Контекст ошибки, как и стратегия разрешения ошибки, уводят в сторону прописания соглашений на стадии написания дизайна проекта.

[vit-r.livejournal.com]

"Данные неизвестного происхождения". Может с документа не так считали, может какой-то студент писал формочку, забыл сделать проверку на числа.

Если софт достаточно зрелый, такого добра в данных набирается тонны.

[swamp-agr.livejournal.com]

Проблема чаще всего не в ФП.
Проблема чаще всего лежит отнюдь не в ошибочном выборе технологий.
Сообществу навязали тренд, народ съел.
Погромисты-функциональщики - не исключение. Соответственно, ФП не панацея, но и не корень всех зол.

[vit-r.livejournal.com]

Очень редко на стадии дизайна видны все возможные пути развития. Впрочем, дизайн всегда уточняется параллельно с разработкой.

[swamp-agr.livejournal.com]

Всё верно.
Если дизайн не актуализируется в процессе разработки, то происходят расхождения.
От этого со временем страдают все участники процесса, включая заказчика, которому бывает всё равно, что прописано в дизайне.

[gineer.livejournal.com]

но ФПшники какраз хотят доказать что панацея,
в смысле что "все остальное -- нинужна (тм)"

[vit-r.livejournal.com]

Честно говоря, такой же звездизм был у проповедников ООП. Особенно тех, кто учился по мутному Бучу, и без писания кода сразу перешёл в архитекторы.

[swamp-agr.livejournal.com]

"Все остальное" - это что?
Проясните, пожалуйста.

[gineer.livejournal.com]

Я не такой старый, чтобы застать "звездизм ООПешников" :)

И почему это Буч -- мутный? Может в ранних изданиях.
То что я читал, довольно неплохо, с исходниками.

[gineer.livejournal.com]

Ну вот такое ощущение от прочтения постов ФПшников...
что мол есть уже единственно правильный подход/язык
и все надо писать на нем
а все остальные -- тупые неосиляторы :)

[vit-r.livejournal.com]

У меня подозрение, что индустрия стояла в двух шагах от того, чтобы понять смысл ООП. Но всякие консультанты вроде Буча всё запутали, уйдя в технические мелочи и проглядев общую картину.

По крайней мере те, "математические основы", на которые все ссылались, никто так предъявить и не смог.

[gineer.livejournal.com]

Да уж... занятно.

У меня ощущение с точностью до наоборот.

[swamp-agr.livejournal.com]

Понятно.
Если рассуждать таким же образом, то я в офисе вижу и ощущаю ровно то же после замены ФП на ООП:

Ну вот такое ощущение от прочтения постов ООПшников...
что мол есть уже единственно правильный подход/язык [Java]
и все надо писать на нем
а все остальные -- тупые неосиляторы :)

Причём они заходят ещё дальше, называя тупыми неосиляторами своих коллег, которые не знакомы с версией Y фреймворка X.

Не думаю, что проблема в ФП.
Скорее, проблема в кадрах.

Оторвать ФП от контекста (задачи, предметной области) - получится сферический сеимгрупоидный конь в монадическом вакууме.

[gineer.livejournal.com]

Тут есть одна маленькая проблемка.

Если брать какой-то из мейнстримных языков,
то это подтверждается простым мысленным экспериментом -- представить что вот не стало Жабы, С, даже РНР...
сразу образуется зияющая дыра в виде отсутствия софта и важных
инструментов.
Что как бы подтверждает их нужность/важность.

Холивар это конечно не красиво, так же как и самолюбование,
но если оно имеет под собой некоторую базу...

А что бы случилось если бы не было Хаскеля?

А ведь... надо напомнить, что он не такой уж новый язык,
чтобы говорить "еще не успел развится, не успел занять нишу".
Наоборот, ФПшники напирают на то что "функциональный подход -- был уже давно".

Но вот на резонный напрашиваюзщийся вопрос "так где? так почему? так чем он лучше?"... почему-то получается сакраментальный ответ "чем грузины". :))

[swamp-agr.livejournal.com]

Мысленный эксперимент оторван от контекста, от реальности.
Если бы не было чего-то, то всё стало бы по-другому.
Просто иначе.

А так - имеем, что имеем. Вернуться в прошлое и изменить ситуацию для наслаждения последствиями в настоящий момент не представляется возможным.

[vit-r.livejournal.com]

То есть, наличие объективных причин благородный дон отрицает?

[swamp-agr.livejournal.com]

Благородный дон отрицает построение паралелльных реальностей, основываясь на "если бы ..., то ...". Это "если ..." не случилось в прошлом.

Благородный дон не отрицает наличие объективных причин.
Нет софта - это проблема, которую надо решать, например, делая рабочий софт.
Хотя и этого недостаточно, конечно.

[vit-r.livejournal.com]

Альтернативная история позволяет проверить фундаментальные принципы.

[swamp-agr.livejournal.com]

Иногда такие проверки бывают очень болезненными.

Прикол частичной амнезии в том, что ты не знаешь, что это за вспышка - реальное воспоминание или альтернативно созданное прошлое.

Со временем число таких расхождений накапливается, `фундаментальные принципы` начинают трещать. Анализ таких расхождений жёсткий, долгий и мучительный, потому что расхождения происходят в сознании. Личный опыт предлагает воздерживаться от альтернативных историй без жизненной необходимости ворошить прошлое.

[vit-r.livejournal.com]

Вообще-то, именно заявления функциональщиков требуют такой проверки. И оказывается, что в истории уже были такие попытки. И стабильно оказывались неудачными.

Отсюда можно начинать выводить фундаментальные принципы.

[swamp-agr.livejournal.com]

Заявить можно всё, что угодно.
Можно даже задать тренд.
Одних слов недостаточно, это понятно.
В соседней ветке обсуждения в таком же разрезе упоминалось и ООП.
И оттуда тоже можно начинать выводить фундаментальные принципы.

Есть фактические свидетельства того, что ФП упрощает жизнь, решая проблемы бизнеса конкретных людей и компаний. Да, их в среднем "по больнице" гораздо меньше. Это провал.

Для того, чтобы проверить утверждение о решении задач, мне пришлось решить проблему чужого бизнеса: недавно внедрил вундервафлю на Haskell, которая имеет API, спецификацию и чётко решает поставленную задачу. Как она будет жить в условиях изменяющегося бизнеса? Как возрастёт стоимость сопровождения? - Время покажет.

[gineer.livejournal.com]

С ООП связан такой момент.
Из личного опыта... но довольно воспроизводимый,
что его подходы, особенно что касается дизайна (паттерны, оптимизация) -- не совместимы с требованиями менеджмента.

Как минимум три пример такого у меня имеются:
с самой первой моей работы, где мои попытки что-то там ООПшное написать (в ГУИшном апликейшине, да),
были отвергнуты под предлогом "нам нада было чтобы ты ВОТ ЭТО написал, в процедурном стиле",

второй случай -- конфликт с контрагентом на тему понимания что такое делегат в С++, где оппонент явно с .НЕТным бэкграундом,

третий -- где сама возможность работы кончилась,
по причине того, что сделав удобную ООПшную обвязку задачи,
которая реально сильно урощала работу и исключала ошибки...
оказалось что мои услуги больше и не нужны... :)

то есть... получается...
что это не ООП плох,
это заказ от менеджеров такой -- на понятность и предсказуемость.
типа если сегодня тебе дали задачу нарисовать 1-ну формочку,
а завтра 2,
то надо чтобы сегодня оно потребовало 1 час, а завтра 2...
а не,
сегодня ты одну делаешь целый день,
завтра две -- за 5 минут,
а через месяц тратишь еще неделю на исправление ошибок и отладку. :))

[vit-r.livejournal.com]

Ну, пардон. Если мы про "заказ менеджмента" говорить начнём, окажется, что самое лучшее - это то, что позволяет строить домики из соломы, которые надо постоянно перестраивать, потому что их сдувает даже лёгким ветром.