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

Сайт bytecode.news опубликовал эссе-отклик на двухчастную серию Эндрю Орама для Linux Professional Institute о том, почему языки программирования появляются и исчезают. Орам делит языки на «бессмертные» (C, C++, JavaScript, с оговоркой насчёт Java), «уважаемо ушедшие на покой» (COBOL, FORTRAN, BASIC, Perl) и «несостоявшиеся» (Паскаль, Objective-C, PL/I, Ada, Tcl, с Ruby «на грани»). Ближе к концу серии Орам приводит цитату Саймона Пейтон-Джонса: принятие языка «очень слабо связано с его техническими достоинствами», по мнению автора эссе, именно эта фраза и есть весь смысл материала Орама, только зарытый слишком глубоко в текст.

Автор разворачивает тезис Пейтон-Джонса в рамку из трёх осей: программирование, это одновременно призвание (то, чем человек занимался бы и без зарплаты), искусство (то, что делают из любви и мастерства) и работа (повседневный труд, ради которого едят и спят под крышей). Сравнение с музыкантами: концерт кавер-версий, это работа, собственные вещи, искусство, а призвание, то, что вообще заставляет каждый день брать в руки инструмент. Язык гибнет, если хотя бы одна из трёх осей становится неоправданно трудной: стандартный Паскаль без нормального строкового типа и Tcl, не тянувший крупные программы, провалились как работа; Ada и PL/I, языки «по разнарядке», которые выбирали не сами программисты, а начальство, провалились как искусство; рынок труда для Perl ушёл к Python и не вернулся, а Haskell изначально ставил целью «избежать успеха любой ценой» и в этом преуспел, оба провалились как призвание.

Та же рамка объясняет исключения. JavaScript проваливается как искусство для большинства, кто на нём пишет, но выживает, потому что остаётся главным языком общего назначения для браузера. Objective-C был неудобен и как искусство, и как работа, но продержался пятнадцать лет, будучи единственной дверью в самую прибыльную экосистему разработчиков, рынок iOS и Mac; как только появился Swift, Objective-C «испарился» и сохраняется лишь тенью в своём потомке. COBOL держится потому, что заменить его дороже, чем терпеть: автор формулирует это как язык, который «работает на 100% времени и примерно на 1% доставляет удовольствие», и если замену когда-нибудь сделают дешёвой, COBOL, скорее всего, исчезнет. Ada выживает там, где режимы сертификации делают её практически незаменимой, но это, по словам автора, «постоянное уведомление о выселении», которое вступит в силу в тот день, когда появится альтернатива.

Отдельно, C++ и Rust, которые сложны и при этом процветают, что как будто противоречит всей схеме. Автор разводит два вида трудности: «трудность скрипки», точная, требовательная и выбранная сознательно, за неё есть отдача (на C++ соревнуются в компактном коде в стиле «code golf» ради спортивного азарта, про Rust пишут эссе о дне, когда наконец «щёлкнул» borrow checker, встроенная в язык проверка заимствований памяти); и «трение», трудность без смысла (бюрократия сертификации Ada, недостающие куски стандартного Паскаля, точный, но не создающий реальной структуры программы синтаксис COBOL), про день, когда «щёлкнула» бумажная работа Ada, никто эссе не пишет. С этой позиции Java не нуждается в такой же защите: она проще C++ и Rust и сейчас переживает подъём и по пользе, и по удовольствию, благодаря недавним улучшениям в упаковке и возможностях языка; впрочем, автор честно признаёт личную пристрастность, он сам работает в Java.

Финал возвращается к музыке. Современный семплер способен воспроизвести любую ноту и нюанс игры на скрипке, но заставить его сделать это, больше работы, чем просто сыграть на скрипке; возможности никогда не были вопросом, а код существует именно поэтому, как компактная спецификация поведения, которая дешевле, чем описание этого поведения прозой. Автор приводит личный пример: можно запрограммировать компьютер повторить его собственную игру на гитаре нота в ноту, получится точно, но совсем неинтересно, потому что сам процесс игры и был смыслом. Вывод: языки программирования проигрывают не тесты производительности, они теряют людей; они поднимаются, когда облегчают призвание, искусство и работу разом, и падают в тот день, когда что-то другое способно нести тот же вес, а единственный оставшийся вопрос звучит просто: «а весело ли это?»

В сносках автор уточняет ряд деталей. Коммерческая жизнь Паскаля не закончилась в учебных классах, она переехала в компанию Borland, где Turbo Pascal, а затем Delphi больше десяти лет доминировали в разработке под ПК; автор Turbo Pascal Андерс Хейлсберг позже создал Delphi, затем C#, затем TypeScript, а линия Никлауса Вирта пришла через Oberon в язык Go, через его ученика Роберта Грисемера. По мнению автора, Паскаль не столько «пал», сколько был «переработан»: некоторые языки побеждают влиянием, а не прямым использованием. Судьбу Perl автор связывает с тем, что Ларри Уолл «сдвигал ворота»: пользователи Perl два десятилетия ждали «Perl 6», пока тот не превратился в отдельный язык Raku, а виртуальная машина Parrot, которую строили под него, умерла в ожидании. Насчёт Haskell автор оговаривается, что был несправедлив: девиз языка был не «избегать успеха любой ценой», а «избегать успеха-любой-ценой», то есть Haskell отказывался жертвовать своими принципами дизайна ради популярности, а не сознательно проваливался. Отдельная сноска, про Java в браузере: сама Java там не работает, нужен рантайм вроде CheerpJ (JVM в браузере) или инструментарий компиляции в WebAssembly. Про Ada автор пишет, что язык мощный и обоснованно обязателен в ряде отраслей (безопасность, точность, доказуемость), но знакомые ему программисты на Ada описывают его как требование индустрии и указа, а не выбор; Rust, по его мнению, закрывает те же задачи по собственному желанию разработчиков, без директив о закупках, и постепенно отвоёвывает ту же нишу, хотя массовой замены пока не произошло ни для Ada, ни для COBOL, и сам автор называет это предположением. Последняя сноска, про семплер: электронная музыка во многом построена на попытках воспроизвести в аппаратуре техники человеческих рук (послекасание, X-Y-контроллеры, контроллеры дыхания, тактильные контроллеры, терменвоксы) ради того, что дешёвая гитара в руках среднего гитариста делает и так.

Ключевые факты

Эссе на bytecode.news отвечает на двухчастную серию Эндрю Орама (Linux Professional Institute) о том, почему языки программирования побеждают или гибнут, отталкиваясь от цитаты Саймона Пейтон-Джонса: успех языка «очень слабо связан с его техническими достоинствами».
Автор делит судьбу языка на три «оси», призвание, искусство и работу: язык гибнет, если хотя бы одна становится неоправданно трудной (Паскаль и Tcl, провал как работы; Ada и PL/I, провал как искусства, «языки по разнарядке»; Perl и Haskell, провал как призвания).
Различает два вида трудности: «трудность скрипки» со смыслом и отдачей (C++, Rust), и бессмысленное «трение» (бюрократия Ada, недостающие куски Паскаля, синтаксис COBOL); первая языку не вредит, второе, убивает.
Objective-C продержался пятнадцать лет как единственная дверь в экосистему iOS и Mac и «испарился», когда появился Swift; COBOL держится, потому что замена дороже 1%-ного удовольствия от него, «работает на 100% времени и на 1% доставляет удовольствие»; Ada держится похоже, но это, по словам автора, «постоянное уведомление о выселении».
Финал, сравнение с музыкой: семплер способен воспроизвести каждую ноту скрипки, но управлять им дороже, чем просто играть; вывод, языки программирования проигрывают не тесты производительности, а людей, потому что решает не «что мощнее», а «что веселее».

Почему это важно

Эссе даёт непривычный ответ на вечный технический спор «почему один язык живёт, а другой умирает»: не через бенчмарки и синтаксис, а через то, насколько язык остаётся посильным сразу как призвание, искусство и повседневная работа. Отправная точка, цитата Саймона Пейтон-Джонса о том, что принятие языка «очень слабо связано с его техническими достоинствами»; автор считает, что именно эта мысль объясняет всю историю языков программирования, от COBOL до Rust.

Кому это важно

Программистам и техническим руководителям, которые выбирают язык или стек для команды и продукта; людям, пишущим языки, библиотеки и инструменты разработки, рамка объясняет, почему техническое превосходство само по себе не гарантирует принятия. Полезно и тем, кто читает или пишет про историю языков программирования: материал прямо продолжает и переосмысляет серию Эндрю Орама.

Как это применить

При выборе языка для команды стоит спрашивать не только «насколько он технически мощнее», но и «легче ли на нём работать, творить и делать карьеру», то есть проверять все три оси, а не одну. Полезно также различать два вида сложности из эссе: трудность, за которую есть отдача (человек выбирает её сам и получает удовольствие или результат, как с C++ или Rust), и трудность-трение, которая просто добавляет бюрократии и не окупается ничем (как сертификационные требования Ada или недостающие возможности стандартного Паскаля).

Можно ли доверять

Это авторское эссе-мнение на bytecode.news, а не исследование: оно опирается на одну цитату из серии Эндрю Орама и на собственные наблюдения и примеры автора, без статистики или бенчмарков в подтверждение тезиса о слабой связи техники и принятия языка. Автор сам оговаривает свою пристрастность в оценке Java, поскольку работает в этой экосистеме, и признаёт, что часть выводов о Haskell в исходной формулировке была несправедливой.

Риски и подводные камни

Рамку «призвание, искусство, работа» легко подогнать под любой пример задним числом: граница между «трудностью со смыслом» (C++, Rust) и «трудностью-трением» (Ada, COBOL) у автора держится на личном ощущении, а не на измеримом критерии, так что для других языков и других программистов деление может выглядеть иначе. Материал не содержит ни дат публикации обеих серий Орама, ни рыночных данных, это стоит учитывать как ограничение источника, а не додумывать самостоятельно.

«Принятие языка очень слабо связано с его техническими достоинствами.»

— Саймон Пейтон-Джонс, в пересказе Эндрю Орама