И снова у меня ответ на комментарий получился слишком длинным для комментария:) Что ж, пусть будет новая заметка.
ассемблер x86... 20 инструкций.... Сколько занял онбординг? Максимум несколько дней
... и ты уже можешь перекладывать данные по регистрам и выполнять арифметические/логические операции. Но где тут программирование? Чтобы написать элементарный ввод с консоли и вывод в неё надо изучить соответствующие функции ОС (BIOS). Нарисуешь квадратик на экране через несколько дней? Поработаешь с файлами? Ну поздравляю: ты ниндзя обучения! Таких один на тысячу. И это мы ещё не добрались до реальных программ, решающих реальные задачи. А если посмотреть на современные ассемблеры, то будьте‑нате: наборы команд, ядра, кэши, конвейеры, математические блоки, согласование скоростей разного железа — и всё ручками.
Следующая стадия, язык C
Люди придумали ЯВО не для того чтобы помучить новичков, а наоборот чтобы они могли себе позволить не знать ничего про иерархию прерываний и при этом получать реальное решение своих задач. «Ведь математику в школе учат все, так давайте сделаем программирование похожим не на электронику, а на математику. Тогда простые люди: инженеры, бухгалтеры и пр. смогут использовать компьютеры самостоятельно. Да, придётся привлечь крутых профессионалов по железу и ОС, создать компиляторы и средства разработки, но на каждого такого спеца придутся тысячи, которые всех этих сложностей не увидят, а будут писать простые команды, уделяя внимание лишь тому чтобы программа правильно работала с т.зр. их предметной области». Сложно внутри, зато просто снаружи.
Следующий C++, это уже ООП
Отлично, инженер пишет себе программки, которые даже примерно одинаково работают на рабочем PC и на домашней Amiga. Счастье? Пока нет.... Его программа работает в диалоговом режиме, надо ввести 100 значений, ни разу не ошибиться и в результате программа что‑то там посчитает. Или упадёт с ошибкой что инженера тоже устроит: он посмотрит стэк и выпишет себе нужные данные. Беда в том что пользоваться данной программой может только он. Чтобы её можно было передать другим людям требуется серьёзная доработка: надо придумать юзер‑интерфейс с удобными полями и валидацией вводимых данных, сделать обработку ошибок, создать дистрибутив чтобы пользователь мог поставить программу себе просто нажав несколько кнопок. Получается что всякого «сервисного» кода в программе получается чуть ли не больше чем «рабочего». А значит, инженер уже не осилит создание «нормальной» программы, ведь к него же и своя работа есть.
Ну хорошо, давайте у нас будут программисты, которые будут брать идеи и алгоритмы у биологов/социологов и превращать их в программы, которыми могут пользоваться все, а не только их авторы. Проблема: программистов мало. Вот тех ребят, которые на осциллографе смотрят результат работы компилятора — их мало. С другой стороны, зачем человеку знать работу конвейера чтобы наваять юзер‑интерфейс по готовым гайдам? А другой, кто получше шарит в математике, может написать предметную часть так чтобы она считала правильно, быстро и не падала. Давайте объясним ему особенности вычислений на компе, пусть для него это будет набором догм, это по‑любому быстрее чем объяснять работу АЛУ на разных архитектурах.
Ага, у нас уже есть эта парочка... А что это значит? А то что одну программу может писать несколько человек и она даже родится быстрее. А можно ли поставить ещё больше человек? Да так чтобы их можно было тасовать: сегодня он пишет бухгалтерию, а завтра каталог рецептов. Ведь если можно, то мы сможем открыть фирму «Софтварь чего изволите». Да и вообще, компами хочет пользоваться всё больше народа, требования растут, сложность растёт, написать программу вдвоём в реальные сроки уже никак. Надо придумать способ бить задачу на мелкие составляющие, раздавать кусочки сотне разработчиков, а потом надо чтобы это всё собралось и стало работать... Давайте создадим ООП.
Сложно? Очень! Но опять же внутри. Снаружи‑то: пишешь класс, который и программой‑то не является, а потом пишется сервис, который несколькими классами манипулирует. Вроде, на первый взгляд, разрозненные кусочки, но магия компилятора создаёт из них программу, которая работает как надо.
Может показаться что писать в парадигме ООП сложнее чем «просто так», но это только кажется. Да, простую программку можно написать и безо всяких классов, однако как только задача становится реальной, код разрастается до такой степени, что отладить его становится невозможно и ты просто должен побить его на куски, которые можно отладить по отдельности. И с ООП это сделать уже проще чем в «старой» парадигме с функциями и процедурами. Хоть это и требует определённой перестройки сознания.
реактивность
Отлично, благодаря ООП мы научились создавать сложные программы силами целого коллектива разработчиков. Однако, так же как компьютеры сначала стали а потом прекратили быть персональными, наши системы уже не ставятся на отдельные машины, мы предоставляем наш сервис как услугу и на наш сервер заходят сотни и тысячи человек и надо их как‑то обслуживать одновременно. И тут мы обнаруживаем что хотя к нам ломятся толпы, наш процессор как‑то не очень нагружен. Дело в том что он, зараза, очень быстрый, а вот другие части системы (периферия, сеть, диски) не очень. А ещё есть кране медленный пользователь. И что делать? Ну, давайте придумаем асинхронность. Пусть программа будет разбита на мельчайшие кусочки, мы будем закидывать данные в обработчики и, не дожидаясь пока он отработают, нагружать всё новые и новые. А когда обработчик досчитает, он нам как‑то сообщит и мы там как‑нибудь его результат объединим с другими и получим то что нам надо и гораздо быстрее.
Сложно? Крайне сложно! Требуется полная перестройка сознания... Или нет? Посмотрев на задачи, мы увидим что они часто типовые: множество одинаковых задач внутри что банка, что соцсеточки. Нууууу и... мы же уже умеем делать фреймворки, так давайте сделаем ещё один несколько. Уберём всю сложность под капот. Пусть программист пишет компоненты по определённым правилам, использует соответствующие типы данных и аннотации, а дальше уже наше (крутых спецов) дело чтобы всё это завелось как надо.
AWS и вот это всё
Спроектировать и построить современную систему сложно что на своих мощностях, что на облаке. Помимо тех плюсов облаков, которые перечислены на сайте любого сервиса, упрощение для разработчика состоит в том что сложность можно наращивать постепенно, на каждом этапе принимая решение как действовать дальше: переходить на своё или платить больше сервису.
Действуя в ситуации неопределённости (а сейчас большинство проектов стартует именно так), ты упрощаешь себе задачу в целом, стартуя на облаке. Даже не смотря на то что придётся изучить какие‑то иные подходы и решения.
В общем, резюме:)
Системы усложняются не потому что кот‑то хотел всех поставить рачком и доминировать. Задачи меняются — меняются инструменты. Меняется объём задач — меняются подходы к решению и опять инструменты.
А то что раньше каки‑то другие люди приходили в профессию — так раньше и трава была зеленее, и дефки жопастее, что ж теперь? Не надо сравнивать «тогда» и «теперь». Возьми любой энтерпрайз, которому 30 лет (ну ладно, не любой, я тоже читал про поиск программистов на Алголе). Он уже 3–4–5 раз переписан на новые технологии и не потому что людям делать нечего. Просто «тогда» задачи были такие что его можно было написать вчетвером на Паскале, и всё отлично работало. Но «сейчас», казалось бы, та же самая задача разрослась настолько что для решения менять надо всё: парадигмы, языки, инструменты, организацию труда, вообще всё!
И если, скажем, одну гостиницу ещё можно автоматизировать на Дельфи, то сеть уже вряд ли (или ну очень упороться надо). А внешний сервис, который работает с разными сетями, наверно, уже совсем нет.
Рассуждая о сложности, надо сопоставлять сопоставимое. Современное web‑приложение сложнее сделать чем 30 лет назад «программку с окошками»? Безусловно сложнее! Можно ли решить задачу web‑приложения той программкой? Ну... если и можно, то для разработчика это будет не проще, а сложнее. А то что это надо обеспечить гигагерцами и гигабайтами где‑то там под капотом, что ж не зря ж люди старались, создавали современные машины. Пусть машины работаю, а люди радуются что им удалось.