Радикальное упрощение программирования несовместимо со всеми нашими социальными институтами

Радикальное упрощение программирования несовместимо со всеми нашими социальными институтами. По крайней мере, такое упрощение потребует нарушения совместимости с тысячами существующих технологий. Это конечно немыслимо для современного Big Tech, ИТ-инвесторов и университетов, оборот которых составляет триллионы долларов, ведь зарабатываются они прежде всего на сложности разработки, которая очень сильно преувеличена. Но, весь мир работает на программном обеспечении, и изменение мира соответственно означает изменение программного обеспечения. Вообще, программирование — это сегодня самое узкое место на пути прогресса в науке и технике. Профессиональное программирование столь запутано, что недоступно даже учёным, для чего пришлось создавать отдельную касту "data scientists". А академикам приходится использовать Excel или нанимать программистов.

=

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

Так вот, важная болевая точка всех проектов мэйнстрима — это чрезмерное усложнённое сопровождение программного обеспечения. Классический (правда, уже бумерский) пример — проблема Y2K. Даже фильм в Голливуде тогда сняли на эту тему, как в полночь самолёты стали падать :) Напомню, проблема, что в софте 1980..1990-х годов на хранение года отводилось два разряда, из соображений экономии, что тогда было действительно немного актуально, и соответственно, при наступлении 2000-го года весь подобный софт должен был упасть.

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

=

Совершенно реально (по крайней мере, мне понятно как минимум теоретически и инженерно), как упростить сопровождение программного обеспечения в 100 раз. Упростить — в том смысле, что когда тимлид выкатывает список новых и достаточно сложных фич, они будут требовать линейного, а не экспоненциально растущего, времени на их реализацию, сколь бы большим не был текущий проект. И я думаю, что мы можем получить первые 10 раз, первый порядок выигрыша, совсем быстро: просто научив разработчиков думать о логике кода, отслеживать, какие утверждения делает каждый кусок кода, а затем добавить ограничения для них. В СильныхИдеях для курсантов подробно эти темы разбираю, и в этом месяце также запускаю формат hard work, где в дополнение к теории будем (принудительно) делать разные полезные задания по теме борьбы с проектной сложностью.

В случае с таймзонами например, можно было бы очень просто сделать хорошо известные вещи — обернуть таймзону в абстрактный интерфейс, и в результате, если потом захотят изменить/расширить её реализацию, то это займёт пять минут вместо десяти тысяч часов. Так что, усредняя, в случаях, когда это уж не так драматично, можно легко получить 10 раз, просто аккуратно следуя моему микро-курсу "Быстрая прокачка в ООП" (пройдя перед ним конечно треки по ООАП и "Как понять в программировании всё").

Остальные 10x возможно получить от инструментов. Так что когда у нас есть возможность посмотреть на любой кусок кода в проекте и быстро понять, для чего он был задуман (даже несмотря на то, что тут может быть более одного ответа), то далее мы должны иметь возможность сделать следующий шаг — создать инструменты, которые могли бы делать нечто подобное уже автоматически (визуализировать логику проекта например). А отсюда мы наконец подходим к итоговому шагу: созданию инструментов, которые будут корректно изменять системный дизайн проекта. Рефакторинг, только не на уровне кода, а на уровне той высокоуровневой логики, тех абстракций, которые в коде отсутствуют по определению.

=

В некотором ограниченном виде такие инструменты существуют. Это прежде всего проект Алана Кэя по метапрограммированию (тысячекратная компактность кода, о которой не раз раньше рассказывал). Но он был больше академическим, а на практике его последователи реализовывали схожие подходы, например, в одном из закрытых американских проектов по автоматизации тысячи химических заводов. В их АСУ ТП использовался очень устаревший язык, работавший напрямую с оборудованием, и на его макро-расширениях они и писали свои программы, из которого генерировался низкоуровневый код. А после того, как оборудование стало меняться, этот низкоуровневый код также изменился, что привело к тому, что все их макропрограммы стали неработоспособны, потому что доступа к исходникам компилятора этого устаревшего языка у них не было. А если бы и был, вряд ли их квалификации хватило бы на его развитие.

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

=

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

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

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

Это всё про "программы, которые пишут программы, которые пишут программы".

=

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

Это пока мечты, но они совершенно реалистичны.

Источник: vk.com

Комментарии: