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

[vit_r]

Замечаете ли вы странности в следующем ряду?
'127'
'238'
'301'
'11Z'
'281'
'109'
'118'

Да, среди цифр затесалась буква 'Z', очень похожая на двойку.

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

Каждый раз читая посты ivan_gandhi, orleanz и других восхищённых проповедников функционального программирования, думаю: «Выглядит-то оно замечательно. Но что останется от этой красоты, после того, как туда вставить хотя бы банальную трассировку?»

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

Это не та, которая сообщает пользователю «Вася, ты дурак! А ну-ка быстро исправь бяку!»

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

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

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

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

Welcome to the real world, товарищи математики!

Comments

[swamp-agr.livejournal.com]

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

Для примера, в офисе приходится генерировать 560 LoC в ходе реализации какой-то фичи. Дома идентичный функционал обыгрывается с помощью ФП (Haskell) в 25 LoC. Код ФП пишется тяжелее, но читается легче. Пространственно-временнные замеры показывают, что ФП не уступает по времени/ресурсам мейнстриму.

[rudakov.livejournal.com]

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

[vit-r.livejournal.com]

С их помощью можно обыграть ситуацию с Z и другими "левыми" символами с лёгкостью, ещё даже легче, чем мейнстримные технологии

Нет такого "всего", чего бы нельзя было сделать теоретически. А на практике получается жопа.

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

[swamp-agr.livejournal.com]

Про практику и говорю.
Субъективный опыт показывает следующее:
* Java, Perl, C++, PHP, C#: быстрая реализация -> баги, каверзные баги, race condition, многочасовая отладка.
* J, Haskell: тяжелая реализация -> ни одного падения, ни одного зависания, ни одной ошибки, все сообщения о невалидных входных данных читаемы, понятны.

Конечно, понимаю, что опыта - шишек набито - мало для суждения.
Возможно, через пять лет буду рассуждать иначе. Но сейчас так.

[metaclass.livejournal.com]

Нет, на практике с ФП получается сильно легче, особенно вот в таких случаях.
Заворачиваем в тип
"ХорошиеДанные(int) | ПлохиеДанные (строка)" и протаскиваем его до того места, где есть хоть что-нибудь или кто-нибудь, способное разобраться и сконвертировать это в настоящий int

[thedeemon.livejournal.com]

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

Если это можно сформулировать четко и непротиворечиво, получится все та же математика. Не вижу противоречия с реальным миром.

Больше логики и непротиворечивости - больше математики, меньше багов.
Меньше логики и непротиворечивости - меньше математики, больше багов.

[vit-r.livejournal.com]

Если это можно было бы сформулировать четко и непротиворечиво, мир был бы гораздо лучше.

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

Больше логики и непротиворечивости - больше математики, меньше багов.
Меньше логики и непротиворечивости - меньше математики, больше багов.

Этак можно тысячу багов заменить одним: "Программа не работает"

[vit-r.livejournal.com]

Я уже написал, что "протаскивать" придётся в другую страну в организацию, с ИТ мало чего общего имеющую.

Это не мелкая обозримая компания, это энтерпрайз, где маленький отдел где-то по размерам с такую компанию.

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

[vit-r.livejournal.com]

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

Кстати, у меня на Perl и C++ не выполняется условие "баги, каверзные баги, race condition, многочасовая отладка". Что я делаю не так?

[vit-r.livejournal.com]

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

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

Логи - это просто из серии "забыть"

[metaclass.livejournal.com]

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

[vit-r.livejournal.com]

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

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

Развивать новую теорию - занятие интересное, но ресурсов на это никогда нет.

К тому же, математика - это просто форма выражения. Если человек рассуждает внятно, он может описать это в любом виде. Если в голове туман, математика добавляет только наукообразность.

[perdakot.livejournal.com]

variant<int, string>
Алгебраический тип данных же.

[metaclass.livejournal.com]

ну, это он и есть :)

[vit-r.livejournal.com]

Нафиг он нужен, если там явно результат ошибки OCR?

[vit-r.livejournal.com]

Это замечательное решение, но оно не от той задачи.

[anonim-legion.livejournal.com]

Вам в копилку ехидства:

-------
Есть технологии из разряда "Берешь и делаешь", а есть технологии из разряда "Человечество осуществило посадку зонда на комету, но так и не научилось выравнивать блоки с помощью CSS".
-------

[anonim-legion.livejournal.com]

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

Трассировка как раз монадами и реализуется.

Логи люди таки читают. Умение читать журнал системых событий винды сильно облегчает жизнь.

И так далее...

[thedeemon.livejournal.com]

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

То, что где-то по организационным причинам нельзя использовать языки А и Б, а можно только COBOL, скажем, не мешает другим людям в других ситуациях те языки использовать с успехом.

[vit-r.livejournal.com]

При посадке на комету а) не закрепились гарпуны и б) не сработали прижимные двигатели (если бы скальной стенки не было бы, он мог бы вообще улететь мимо кометы), в результате чего в) зонд вместо полярной области оказался в тени гор, что снижает период его освещённости до 90 минут.

Так что с зондами тоже всё в порядке.

[vit-r.livejournal.com]

Мало ли, что на заборе написано.

Я знаю языки, где процентов 80 красивых штучек просто не используется. В большинстве серьёзных контор есть стандарты, где стоит "За попытки вот такие красивости изобразить - вызов на ковёр с докладом, почему не получается с делать по-человечески, а вот за такое - канделябром по башке сразу"

И бьют. Причём, больно.

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

[vit-r.livejournal.com]

Стёрто.

Во-первых, личные наезды.

Во-вторых, не по делу.

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

[vit-r.livejournal.com]

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

Тем более, что в больших системах данные приходят откуда угодно, хоть из Ексел-таблицы секретарши.

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

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

[thedeemon.livejournal.com]

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

[anonim-legion.livejournal.com]

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

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