Программирование — с∙ложно?

Нет.

MathML — до смешного серьёзная технология

Как и многое, связанное с XML, MathML впечатляет своим размахом. Настолько, что вызывает юмористический эффект.

Формула, отображаемая с помощью библиотеки MathJax-script $$ x = \frac{-b \pm \sqrt{b^2 - 4ac}}{2a} $$ и выражаемая на TeX уродливо, но всё ещё кратко как x = \frac{-b \pm \sqrt{b^2 - 4ac}}{2a}, в MathML превращается в чудесное:

HTML-гиперссылка с содержимым, равным адресу

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

<a href='https://wiki.oberon.org/ob/docu'>https://wiki.oberon.org/ob/docu</a>

Пример вреда шаблонного программирования и не только

Попался на глаза пример шаблонного кода на C++

template <typename T>
T tmax(T a, T b) {
    return b < a ? a : b;
}

Я сразу заметил неточность, которая возникнет при использовании дробных чисел

Структурное программирование не про запрет GOTO

Смотрит на вас как на GOTO.

Теорема Бёма — Якопини, которую часто называют теоремой про структурное программирование, на самом деле доказывает прямо противоположное тому, что ей приписывается. Она не доказывает достаточности структурного программирования, а наоборот, доказывает, что с помощью структурных операторов управления можно идеально воспроизводить любой неструктурный код, но сохраняя таким образом и все его отрицательные для человека свойства. Более подходящим названием для теоремы было бы «теорема про неструктурное программирование в структурных операторах».

Рассмотрим дикий бессмысленный пример неструктурного кода:

L0: Call0; IF Pred0 GOTO L2;
L1: Call1; IF Pred1 GOTO L3;
L2: Call2; IF Pred2 GOTO L3 ELSE GOTO L0;
L3: Call3; IF Pred3 GOTO L4 ELSE GOTO L1;

Вычисление чисел Фибоначчи без цикла

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

Бесконечная программа без цикла и рекурсии

Можно ли написать бесконечную программу без циклов и рекурсии?

Не нужно быть поваром

— Эта жратва никуда не годится. Как можно было так плохо приготовить?

— Почему плохо? Разве ты разбираешься в приготовлении еды?

— Не нужно быть поваром, чтобы понять, что овсянка — это отстой. Вот кукурузные хлопья в сахарной глазури из коробки — это класс! А это — тьфу. Так зачем же мучаться, да ещё и разглагольствовать, будто овсянка полезна и является прорывом в питании? Это очевидно противоречит истине и в высшей степени непрофессионально.

Каменный топор

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

— Но теперь у нас есть и другие, более совершенные инструменты: электродрели, отбойные и пневмо- молотки, станки.

— Хорошо, и что же вам мешает использовать их для создания каменных топоров?

Причины большей популярности внутренне посредственных систем

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

Дизайн, отделённый от воплощения — либо ложь, либо проблема

Главное. Можно сколь угодно просто формулировать сколь угодно сложно воплотимые задумки

Вы помните эти слова, приписываемые Форду?

Если бы я спросил людей, чего они хотят, они бы попросили более быструю лошадь

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

Но физика — эта подлая наука, как теоретическое воплощение фундаментальных свойств материи, это главнейший враг свободного полёта дизайнерской мысли. Физикой всё не исчерпывается, так как и «всего лишь» трудновоплотимость на практике может служить не меньшей преградой, чем невозможность. Известно множество примеров, когда разные авторы в короткий период независимо друг от друга приходили к схожим решениям, но только после того, как к этому подоспевали технические возможности, даже если эти возможности относились сугубо к информационным.

Недостатки языка ДРАКОН

ДРАКОН — является лучшим из известных мне языков блок-схем, имеющим свою область применимости. Тем не менее, язык не лишён недостатков, как присущих всем блок-схемам, так и характерных для него самого. Некоторые недостатки являются продолжением преимуществ, а другие могут и не являться таковыми в ряде областей.

Расширенные атрибуты файлов в GNU/Linux

Бывает удобно сохранить дополнительные данные о файле, не создавая явных файлов о файле. В ОС GNU это можно сделать для большинства файловых систем, включая ext4.

setfattr --name user.attrname --value value path-to-file
getfattr --name user.attrname path-to-file

Возможность используется нечасто, поэтому утилиты даже не включены в систему по умолчанию.

/usr/bin/sudo apt install attr

Атрибуты переносятся при использовании утилиты mv. Для cp нужно явно указывать --preserve=xattr. Проще всего в .bashrc создать alias для cp с этим ключём:

alias cp='cp --preserve=xattr'

Мышиная возня

В одной общей переписке появилась копия такого текста

об эксперименте над крысами

В 1950-х годах в Гарварде (США) профессор биологии Курт Рихтер провел серию экспериментов с целью найти биологический механизм, который заставляет нас двигаться к цели. Эксперимент получился довольно жестокий, хоть в нем и участвовали только грызуны (при этом, к тому времени накопилось уже достаточно исследований, показывающих, что в плане группового поведения у людей и крыс/мышей имеются очень схожие механизмы). И вот Рихтер собрал крыс — как домашних, так и диких, которых накануне поймали лаборанты. Ученый бросал их в вёдра, наполовину заполненные водой. Крысы — хорошие пловцы, но даже это им не помогло. В среднем они сдавались и тонули через 15 минут. Причём, разница между домашними и дикими крысами оказалась невелика. Домашние крысы продержались чуть дольше. Они пытались не просто барахтаться на поверхности, но и искали путь на дне и долбились в стенки. Дикие крысы же просто барахтались и почти сразу сдавались и шли на дно. Это было удивительно для ученого, ведь эти дикие крысы были такими агрессивными: они активно сопротивлялись когда их ловили и пытались выбраться из клетки. «Что убивает этих крыс? Почему столь свирепые, агрессивные, дикие крысы так быстро умирают при погружении в воду?», — написал ученый в журнале эксперимента. И добавил: «крысы находясь в ситуации, где у них нет никакой надежды — буквально сдаются». И тогда учёный решил исследовать фактор надежды: как он влияет, и влияет ли вообще? Исходя из новой задачи, во втором эксперименте Рихтер изменил условие: крыс снова кидали в ведро, но когда видели, что животное начинает сдаваться от усталости и истощения, они вытаскивали крысу ненадолго. А затем снова бросали их в воду. Как вы думаете, сколько держались крысы во второй попытке, с учётом того, что поначалу всё сдавались через примерно 15 минут? Еще 15 минут? Нет! 60 часов! ШЕСТЬДЕСЯТ часов! Вот такой был зафиксирован факт: обессиленная, истощенная крыса, которая в общем-то уже умирала, вдруг находила в себе сил ещё на 60 часов! То есть эта истощённая крыса после того, как получала надежду, была способна биться за свою жизнь в 240 раз больше чем было изначально! И вывод из такого фантастического изменения был один: именно фактор надежды играл тут ключевую роль. У крыс появлялась надежда, они начинали верить, что в итоге их спасут. Вывод из этого эксперимента был сделан однозначный: когда в ход вступает надежда, высвобождается просто гигантский потенциал энергии. Разумеется, на основании этого эксперимента развернулись дальнейшие исследования, которые показали, что успеха чаще добиваются не самые умные и талантливые, а те, кто верит в то, что может достичь цели. Рисует в воображении результаты успеха. Эта надежда плюс терпение, готовность вкладывать в силы и дают в сумме важный результат. Американский психолог Мартин Селигман, основоположник метода позитивной психологии, характеризовал человека с надеждой так: это такой человек, который объясняет неудачи временными и специфическими причинами. То есть они со временем уйдут, а результат останется, и человек с надеждой в него верит! А состояние беспомощности у такого человека также носит временный характер. Те же, кто не достигает цели, чаще концентрируются на негативных условиях, обстоятельствах, которые мешают им достичь цели. Им не хватает ресурса надежды, чтобы высвободились дополнительные силы для достижения успеха — т.е. те самые мощные силы, которые высвобождались у крыс в эксперименте Рихтера.

С пояснением, что это намёк для тех, кто понимает.

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

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

Пример из книги про автоматное программирование, оказавшийся трудным для верификации

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

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

Видеохостинг Odysee

Недавно стал на постоянной основе пользоваться видеохостингом Odysee, который, как мне показалось, является чуть ли не единственным претендентом, способным хоть как-то потягаться с Youtube по наполнению и пользовательским качествам. Возможно, что часть его относительного успеха обусловлена наличием возможности синхронизации с Youtube-каналами. Моя попытка синхронизации не удалась, поэтому не уверен, что дело в этом. Тем не менее, некоторая часть просматриваемых мною каналов на Youtube доступна и на Odysee. Поэтому легко сравнить популярность сервисов, и обычно соотношение количества подписок и просмотров составляет 4-е порядка. Впечатляет.

Нехватка программистов

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

Пожелания по программному обеспечению

1. Не стоит писать инструкции для человека, которые он должен выполнять на компьютере. Лучше создавать инструкции для компьютера, понятные человеку. Человек должен контролировать процесс, а не служить прокладкой между программами. Следует выбирать и создавайть ПО, которое позволяет это наилучшим образом.
2. Следует избегать подхода, когда программируемая сущность программы сначала старательно прячется, а затем с трудом и криво натягивается вновь, так как потребность в автоматизации остаётся практически всегда. Причина появления подхода закономерна - в основе разработки используются языки, являющиеся эзотерическими для нормальных пользователей.
3. Не нужно создавать новые платформы (пусть и под задачу и без именования платформой) под предлогом создания якобы платформонезависимого кода, которого не существует по определению. Следует создавать платформы, улучшающие или предоставляющие новые полезные качества, или не создавать вовсе.
4. Высокий уровень стандартности решения и его опоры на другие стандартные решения является преимуществом, поэтому для перевеса в пользу нестандартных они должны давать существенные улучшения.
5. Пользовательский интерфейс должен быть тонкой надстройкой над основным кодом. Желательно, чтобы он создавался из описания на уровне, близком к автоматическому.
6. Совместимость лучше обеспечивать не накоплением устаревших черт, а автоматическим переводом из устаревшего в новое и наоборот.
7. Программисты порой любят переусложнять. Простые решения лучше сложных кроме случаев, когда цели в необходимом качестве недостижимы в простом решении. Но совокупная оценка учитывает не только простоту результата, но и простоту пути к этому результату.

Список будет пополняться.