В программировании присутствует гигантская проблема — настолько большая, что затмевает все остальные

В программировании присутствует гигантская проблема — настолько большая, что затмевает все остальные. И всё же это проблема, которую почти никто не хочет признавать, а тем более говорить о ней. Слона-то мы и не приметили :)

Почему? Потому что сложность разработки (во многом выдуманная и сильно преувеличенная) связана с тем, что человеку нужно выучить слишком много дерьма! Современный программист должен "овладеть" абсурдным количеством знаний. Если это всё распечатать, то получатся, наверное, сотни тысяч страниц документации. Это бесчеловечно: людям приходится впитывать умопомрачительные объемы информации, и при этом ещё и работать. Поэтому и процветают всевозможные "технические прикладные курсы по веб-фреймворкам", где удаётся получить некоторый минимум знаний за разумное время.

Готов поспорить, что по сравнению с другими инженерными дисциплинами программисты должны освоить по крайней мере в десять раз больше знаний, чтобы достичь хорошей компетентности. Это парадокс: нету ни одной другой инженерной профессии, куда бы можно было вот так войти через курсы "в профессию за 6 недель", без высшего образования — и при этом изучить и продолжать изучать надо очень-очень много всего в сравнении даже с университетским образованием. Поразительно, но такое изучение огромных объёмов "знаний" не нужно ни одной из сторон (кроме организаторов курсов :) — ни программистам, ни компаниям, выполняющим заказы. Уже стали вечными мемами темы, что на интервью вас дико гоняют по алгоритмам, а на работе вы немножечко кодите какой-то унылый зашквар из комбинации 98 библиотек и фреймворков.

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

=

Постоянно пишу о том, что инженерия — это прежде всего про чиселки; поэтому хорошо бы оценить эту проблему количественно. Так то на словах все голосуют за простоту, а затем берут и используют C++ )))

Что же делает современное программирование таким трудным? Как нам добиться наконец прогресса в ИТ и привлечь ответственных к ответственности? :)

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

Конечно, это несовершенная метрика. Драфт официального описания C++ занимает под 2000 страниц, и на одной такой средней странице содержится гораздо больше знаний, чем на средней странице руководства по Python. С другой стороны, регулярные выражения документированы очень точно и лаконично, несмотря на сложность их использования. А Роберт Харпер из CMU умещает формальное описание семантики языков программирования на единичных страничках.

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

Соответственно, если мы хотим оценить различные варианты архитектуры, проектирования, дизайна API, то хорошим способом прояснить ситуацию станет размышление о документировании каждого варианта для его пользователей (других программистов).

Всё, что делает такую документацию более короткой, и будет лучшим.

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

=

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

Достаточно очевидно, что самое эффективное на сегодня, что только мы можем сделать для улучшения программирования, это — сократить технический стек.

С самого первого дня, когда человек только начинает программировать, перед ним стремительно растёт стопка толстенных книг (на тысячи страниц каждая), которые ему предстоит изучить. Лучший и, возможно, единственный способ сделать программирование проще — это значительно снизить кривую обучения.

Я собираюсь нарушить самое священное табу в ИТ: чтобы уменьшить стек, нам придется выбросить из него прежде всего все эти ваши веб-фреймворки. Это 98% накладных расходов просто потому, что даже если, с одной стороны, некоторые вещи фреймворки позволяют немного упростить, то с другой стороны, они в силу своей "универсальности" тянут кучу накладных расходов, десятки промежуточных слоёв абстракций, и прочую легаси-ересь. Это буквально и есть стрельба из пушки по воробьям.

Я например запрограммировал мои учебные сервисы десятком простых скриптов на PHP, общим объёмом наверное всего на тысячу строк (внутри два микро-dsl ;), которые элементарно сопровождаются, элементарно переносятся, элементарно развиваются — и никаких фреймворков. Через эти сервисы за несколько лет прошло уже около 500 человек (из которых более половины я забанил за плохое усердие :), и не было ни одного сбоя.

Красивое, в тему: Лисп в 99 строках кода Си.

https://github.com/Robert-van-Engelen/tinylisp/blob/main/tinylisp.pdf

=

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

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

Нам нужно революционное мышление — в смысле идей, меняющих саму парадигму ИТ-мэйнстрима.

Программисты всего мира, развивайтесь прежде всего в математику и computer science!

Вам совершенно нечего терять, кроме гигабайтов документации.

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

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