ИНТЕНСИВНОЕ ПРОГРАММИРОВАНИЕ

Статья рассматривает состояние программирование через понятия «экстенсивный» и «интенсивный». На основе статистических данных, показывает «экстенсивный» характер современного программирования и описывает путь перехода к интенсивному программированию и его преимущества.

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

Попробуем посмотреть на программирование, под которым я здесь понимаю индустрию создания программ, через понятия «экстенсивный» и «интенсивный». Термины «экстенсивный» и «интенсивный» обычно относятся к экономическому росту.

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

Простыми словами, экстенсивный путь — развитие через увеличение ресурсов, интенсивный — через увеличение производительности при тех же ресурсах.

Развивается ли сейчас индустрия создания программ по экстенсивному или интенсивному пути развития?

Чтобы ответить на этот вопрос, надо определить, что производит программирование. Мое определение: результатом программирования являются программы, которые являются инструментами для решения человеческих задач. Текстовый редактор — инструмент для работы с документами, социальные сети — инструмент для общения, САПР для проектирования, АСУ для управления и повышения производительности и т.д.

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

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

Так в исследовании «How much computer code has been written?», написанной в 2020 году, оценивается число строк программного текста, написанного всеми программистами мира за год – дается оценка в 97 миллиардов (97,000,000,000).

Этот объем программного текста является результатом работы 26 миллионов программистов.

Столько программистов было по оценке IDC2 в 2022 году:

"The overall developer population in 2020 was 26.2 million and features 13.5 million full-time developers, 7.8 million part-time developers, and 4.9 million non-compensated developers. Because this data represents the number of developers as of January 1, 2020, the impact of COVID-19 on the worldwide developer population is not reflected in this quantification of the worldwide developer population."

При этом в 2014 году по статистике IDC3 было 11 миллионов professional software developers, и еще 7.5 миллионов hobbyist software developers, итого 18.5 миллионов.

Простая арифметика показывает, что за 6 лет количество программистов увеличилось на 7.7 миллионов, что дает прирост 1.28 миллионов в год.

Мы видим, что количество используемого ресурса (разработчиков) существенно растет. Растет ли при этом качество выдаваемой продукции опережающими темпами? Сильно в этом сомневаюсь.

Моя субъективная оценка: программирование в последние десятилетия развивается медленно. И это после бурного развития в первые 40-50 лет с появления этого вида деятельности. Мы используем почти те же технологии программирования, что и 30 лет назад. Увеличение эффективности за счет развития технологии практически отсутствует, речь может идти только о единицах процентов.

Замечу еще, что увеличение объема софта вовсе не означает, что добавляется новой (оригинальный, полезный) софт. Я не знаю, есть ли такая статистика, но я уверен, что большая часть якобы нового софта — это клоны уже существующего. Это может быть прямое копирование или переписывание существующего софта на другой язык программирования или адаптация его к новым условиям (новая ОС, новая VM, новое оборудование, и т.д.).

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

Увы, вывод неутешительный — почти весь «пар уходит в свисток». Думаю, что этот факт подтвердит любой профессионал, знающий, как трудно найти то, что можно использовать в своем проекте. В этой огромной горе произведенного софта, конечно же, есть жемчужины, но как их найти? И как приспособить к своим задачам?

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

Давайте подумаем, а как могло бы быть в мире победившего интенсивного программирования… Полагаю, что в том чудесном мире задача разработки программного кода начинается с поиска готового программного продукта. Если подходящий продукт есть, задача решена. Если нет, надо его построить. А для того, чтобы построить быстро и надежно, желательно максимально использовать гото- вые части (далее буду использовать более привычное слово «компонента»), которые можно взять из неких хранилищ, и добавить к программному продукту новые компоненты, сделанные специально для него.

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

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

Рассмотрим требования, которым должны удовлетворять те компоненты, которые могут быть многократно использованы:

1. независимость от исполняющей платформы
2. независимость от средств разработки, в том числе от языка программирования;
3. наличие спецификации и возможности формальной проверки соответствия компоненты спецификации;
4. и возможность гибкой настройки или подстройки.

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

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

Это может быть нечто вроде LLVM IR4 или Rust MIR5. Скорее второе, так как одним из присущих LLVM недостатков является то, что IR код сильно завязан на специфику конкретной платформы, для которой он построен (см. TargetMachine).

Промежуточный код позволяет достичь того, что заявляли разработчики Java в 1995 году – "write once, run anywhere", но без ограничений, накладываемых виртуальными машинами (VM). Промежуточный код перед выполнением транслируется или в код целевого компьютера или в код целевой VM.

Другими словами, у компоненты (в промежуточном коде) не должно быть жестких привязок к платформе, а именно:

• к аппаратной части платформы — к процессору, точнее к исполнителю

• и к программной платформе — к ОС и библиотечному окружению.

А это означает, что библиотечное окружение должно быть унифицировано, точнее должен быть унифицирован его API (SysAPI). И еще, не должно быть статической связи (статической линковки) с SysAPI.

Почему пишу про «жесткую» привязку? Потому что некоторая привязка должна быть, например, программу управления телескопом нет смысла запускать без телескопа. Или переформулируя для компоненты, без наличия API телескопа.

Таким образом для каждой компоненты может быть определено (в её спецификации) набор требований, из которых собирается набор требований программного продукта.

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

Смысл очевидный, компонента может быть использована в составе программного продукта, написанного на другом или на разных языках. Нужно обеспечить возможность сосуществования компонент, написанных на разных языках. Это, как минимум, унификация ABI (application binary interface). Но этого мало, компоненты должны использовать общие программные сервисы, например, сборщик мусора, обработку ошибок, логи и тому подобное. Иначе, в программной системе, состоящей из тысяч компо- нент, будет тысяча экземпляров сборщика мусора, и это убьет любой вычислитель. Замечу, что тысяча компонент, это нормальная ситуация для программы, сделанной в среде разработки Вир.

Эта мысль приводит нас к пониманию необходимости унификации среды исполнения (run-time system). И далее, возникает естественный вопрос — можно ли впрячь в одну телегу коня и трепетную лань? А точнее табун коней, оленей, ежей и ужей…

На мой взгляд нельзя, попытка сделать унифицированный run-time даже для малого набора современных языков программирования приводит к неподъемным монстрам, слишком эти языки разные. Единственный способ, на мой взгляд, это разработка нового семейства языков, которые изначально построены с требованием совместимости.

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

На мой взгляд, семейство должно включать языки, в таких категориях:

• язык, с ручным управлением памятью (типа Rust);

• язык с управлением памятью на основе ARC (automatic reference counter);

• язык со сборкой мусора;

• «скриптовый язык» с динамической типизацией и сборкой мусора.
  
  

Подробнее о семействе языков. Как я уже упоминал, языки должны быть совместимыми в смысле возможности исполнения в рам- ках гибридных программных систем. А для этого нужна унифицированная модульная среда исполнения, основанная на унифицированной системе типов. Пожалуй, именно эта часть интенсивного программирования проработана наиболее глубоко, см. мой доклад на Открытой конференции ИСП РАН им. В.П. Иванникова в 2021 году.

Спецификация нужна как «человеческая» – документация, так и формальная. Тут все достаточно очевидно, в том числе и проблемы, которые возникнут в реализации.

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