Евангелисты против оборотней

Название могло бы претендовать на B-movie, но на самом деле здесь пойдет речь о гораздо более приземленных вещах, а именно: о страстной и местами совершенно необоснованной любви программистов и прочих людей, пиарящих технологические решения к «серебряной пуле» — убеждению, что его решение имеет широчайшую область применения.

Программы — это частности

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

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

Разумеется, это всё в противопоставлении с нашей с вами объективной реальностью. Если код работает (про квантовые вычисления давайте здесь не будем) в наборе определенных дискретных состояний, даже если их очень-очень много, то реальный мир работает на бесконечном количестве состояний в определенных диапазонах. Или же в гораздо (на астрономические порядки) большем количестве дискретных состояний, если вы верите, что реальность имеет дискретную природу.

Ну и к чему всё это было?

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

К примеру, язык сигналов в игре Factorio — тьюринг-полный:

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

Но тем не менее, читая статьи о технологиях, я очень часто встречаюсь с тем, что пишущие их люди предпочитают твёрдо быть математиками и насмерть стоять на рубеже technically correct (the best worst kind of correct).

В теории, теория от практики не отличается

Зачем они так делают? Это отличный вопрос, и лично я встречался с двумя версиями: во-первых, некоторые достаточно честно понимают разницу между «возможно в теории» и «возможно на практике», но предпочитают игнорировать это в статьях совершенно намеренно, руководствуясь принципом «громе крикнешь — больше людей о тебе узнает». Правда, ирония тут в том, что этот принцип тоже не является серебряной пулей, и если сильно громко кричать без основания — большинство людей будут знать о тебе совсем не лестные вещи.

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

И было бы очень хорошо, если бы тезис статьи оставался бы не слишком важной теоретической проблемой, но вот увы, он очень сильно выливается в реальность. Из моего личного: не так давно я потратил больше одного рабочего дня на то, чтоб объяснить коллеге что удаление неиспользуемого кода в webpack (tree-shaking) — существует, но работает по довольно примитивным принципам, из-за чего область применения этой штуки довольно скромна, и на неё нельзя слепо полагаться без кучи дополнительных ухищрений и проверок (отличная статья, кстати, вот только я сам рыл этот материал задолго до неё). Можно, конечно бы, обвинить коллегу — но я и сам отлично помню вал статей и материалов на тему «теперь в webpack есть tree-shaking, банзай!», совершенно не освещавших всю скромность и примитивность реализации этого, а наоборот, задвигавших громкие тезисы о том, что вот теперь-то наши сборки станут маленькими и всё это — абсолютно автоматически за счёт «магии» вебпака.

Кто виноват и что делать?

Я, конечно, совсем не считаю, что глас вопиющего в пустыне (и даже на хабре) тут что-то сильно изменит, и в конце концов — есть достаточно большая доля тех, кто совершенно намеренно расширительно описывает область применения своих технологий, чтоб выглядеть привлекательнее. Но если кто-то делает это не нарочно — ОДУМАЙТЕС пожалуйста, подумайте над этим. Хотя бы осознайте, что если ваша программа или технология способна что-то делать — от этого и до того, чтоб с помощью вашей программы или технологии действительно можно было бы что-то делать на практике, особенно тем, кто не является автором — очень долгий путь. Осознайте, что если вы сделали что-то, что работает в конкретном случае на проекте конкретной тематики с конкретным списком проблем — это не даёт вам оснований автоматически полагать, что ваша технология будет полезна везде. Наконец, осознайте, что код «для своих» и код для всех — это две большие разницы, и если вы выложили код «для своих» в опенсорс — это не делает его автоматически кодом, полезным другим разработчикам.