In 1968, the Communications of the ACM published a text of mine under the title «The goto statement considered harmful», which in later years would be most frequently referenced, regrettably, however, often by authors who had seen no more of it than its title, which became a cornerstone of my fame by becoming a template: we would see all sorts of articles under the title «X considered harmful» for almost any X, including one titled «Dijkstra considered harmful». But what had happened? I had submitted a paper under the title «A case against the goto statement», which, in order to speed up its publication, the editor had changed into a «letter to the Editor», and in the process he had given it a new title of his own invention! The editor was Niklaus Wirth.
Edsger Dijkstra, EWD1308
Это жжж (то есть цитата) неспроста. Думаю, что у маркетологов есть имя для приема, который использовал Вирт, и в итоге получил бомбу из заметки Дейкстры. Причем, бомба (как пишет сам Дейкстра) взорвалась в двух направлениях, одно направление – это собственно использование GO TO, а второе – рождение крылатого словосочетания: considered harmful.
Впрочем, предлагаю, не забегать вперед и не добавлять привычное завершение к заголовку «programming languages considered”, может быть там вовсе и не harmful.
Давайте подумаем, из чего и с помощью каких инструментов мы делаем программы. Это вопрос гораздо шире, чем вопрос: «на чем мы программируем», который подразумевает очевидный ответ. И как мы понимаем, очевидный ответ, вовсе не обязательно является верным.
Итак, с помощью каких инструментов мы делаем программы? Я говорю не «Hello, world», а о больших промышленных программах.
Естественно, с помощью билд систем (build automation systems), которые берут части будущей программы и обрабатывают разными инструментами до готовности.
Билд система собирает программу из
- исходных текстов из репозиториев (возможно написанных на разных языках программирования), переводя их по ходу построения в бинарный код.
- заранее скомпилированных библиотек (статических и динамических), которые могут быть написаны на разных языках программирования
- конфигурационных файлов
- различных ресурсов (иконки, картинки, аудио, видео)
и делает это в соответствии со скриптом сборки, как правило, с диким количеством разных настроек, команд условной компиляции и т.д.
В итоге получается готовая программа, которая идет на тестирование, а потом пользователям.
Итого, в процессе создания готовой программы используются (как минимум):
- Репозитории исходных текстов и ресурсов (их содержание) – SVN, Git и т.д.
- Программы извлечения текстов (ресурсов) из репозиториев
- Компиляторы
- Линкеры
- Системы тестирования
- Собственно, программный код билд системы
- Инструменты защиты программы (для коммерческих программ)
- Инструменты верификации
- Еще трекеры, инструменты поддержки процесса разработки, и все остальное, о чем я сейчас забыл….
Замечу, что при построении программы никто и ничего не программирует!
И, как правило, в компаниях средних и больших построением программы занимаются совсем не те люди, которые пишут программный код. Для этого есть причина. Настроить билд систему для того, чтобы она производила нужный результат обычно очень не просто. Если вспомнить слова Ломоносова, то глядя на скрипты билд системы трудно удержаться от восклицания «Oh mein Gott!» Тут без немецкого не обойтись!
Замечание. Построение готовой программы может быть упрощено до крайности, так что его не видно, как это было сделано в OS Excelsior iV [1] и Oberon System [2]. В обоих случаях использовалась динамическая загрузка модулей программы, опирающаяся на модули языков Модула-2 и Оберон. Впрочем, в Excelsior iV была возможность статической сборки для того, чтобы сделать дистрибутив.
Замечание: Для изготовления «Hello, world!» тоже используются построитель программ, обычно встроенный в среду разработки, так что тут разницы нет. Вот только для промышленной программы билд систему легче разглядеть, так как она ОГРОМНАЯ.
Весь предыдущий текст этого взгляда мне нужен был, чтобы читатель мог стряхнуть привычное (и ошибочное) понимание процесса разработки программ, как программирование на языке программирования.
А теперь совершенно привычный текст, который уживается у нас в головах с ошибочным:
Процесс создания программы можно разбить на несколько этапов (не по времени, а по совершаемым действиям):
- Проектирование: идея, требования, тех. задание, архитектура, подбор готовых библиотек и компонент
- Программирование тех частей программы, которых не было (кроме библиотек, готовых компонент, open source частей)
- Сборка готовой программы
- Поддержка программы
- Развитие программы: выпуск версий, обновлений, plugins
Теперь взглянем на использование языков программирования:
Этап 1 – нет (если и используются, то языки проектирования, код не войдет в готовую программу)
Этап 2 – да
Этап 3 – нет
Этап 4 – частично (исправление ошибок)
Этап 5 – частично (по сути, каждая версия или обновление включает в себя новую итерацию этапов 1-4)
Языки программирования используются менее чем в половине этапов разработки программы. И играют вспомогательную роль — позволяют подготовить части, из которых собирается готовая программа. На мой взгляд, роль языков программирования должна быть существенно уменьшена (а Карфаген должен быть разрушен). Но об этом позже.
Вернемся к незаконченному заголовку. Конечно же, его надо закончить словами: mostly harmless!
О, извините, Адамс попутал! При чем здесь harmless?
Конечно же, должно быть:
Programming languages considered mostly irrelevant!
Сейчас это еще не совсем так или совсем не так. Языки программирования должны уйти на вспомогательный уровень — уровень разработки частей, из которых собираются программы.
| [1] | http://www.kronos.ru/ |
| [2] | https://en.wikipedia.org/wiki/Oberon_(operating_system) |