И снова у меня ответ на комментарий получился слишком длинным для комментария:) Что ж, пусть будет новая заметка.
ассемблер x86... 20 инструкций.... Сколько занял онбординг? Максимум несколько дней
... и ты уже можешь перекладывать данные по регистрам и выполнять арифметические/логические операции. Но где тут программирование? Чтобы написать элементарный ввод с консоли и вывод в неё надо изучить соответствующие функции ОС (BIOS). Нарисуешь квадратик на экране через несколько дней? Поработаешь с файлами? Ну поздравляю: ты ниндзя обучения! Таких один на тысячу. И это мы ещё не добрались до реальных программ, решающих реальные задачи. А если посмотреть на современные ассемблеры, то будьте‑нате: наборы команд, ядра, кэши, конвейеры, математические блоки, согласование скоростей разного железа — и всё ручками.
Следующая стадия, язык C
Люди придумали ЯВО не для того чтобы помучить новичков, а наоборот чтобы они могли себе позволить не знать ничего про иерархию прерываний и при этом получать реальное решение своих задач. «Ведь математику в школе учат все, так давайте сделаем программирование похожим не на электронику, а на математику. Тогда простые люди: инженеры, бухгалтеры и пр. смогут использовать компьютеры самостоятельно. Да, придётся привлечь крутых профессионалов по железу и ОС, создать компиляторы и средства разработки, но на каждого такого спеца придутся тысячи, которые всех этих сложностей не увидят, а будут писать простые команды, уделяя внимание лишь тому чтобы программа правильно работала с т.зр. их предметной области». Сложно внутри, зато просто снаружи.
Следующий C++, это уже ООП
Отлично, инженер пишет себе программки, которые даже примерно одинаково работают на рабочем PC и на домашней Amiga. Счастье? Пока нет.... Его программа работает в диалоговом режиме, надо ввести 100 значений, ни разу не ошибиться и в результате программа что‑то там посчитает. Или упадёт с ошибкой что инженера тоже устроит: он посмотрит стэк и выпишет себе нужные данные. Беда в том что пользоваться данной программой может только он. Чтобы её можно было передать другим людям требуется серьёзная доработка: надо придумать юзер‑интерфейс с удобными полями и валидацией вводимых данных, сделать обработку ошибок, создать дистрибутив чтобы пользователь мог поставить программу себе просто нажав несколько кнопок. Получается что всякого «сервисного» кода в программе получается чуть ли не больше чем «рабочего». А значит, инженер уже не осилит создание «нормальной» программы, ведь к него же и своя работа есть.
Ну хорошо, давайте у нас будут программисты, которые будут брать идеи и алгоритмы у биологов/социологов и превращать их в программы, которыми могут пользоваться все, а не только их авторы. Проблема: программистов мало. Вот тех ребят, которые на осциллографе смотрят результат работы компилятора — их мало. С другой стороны, зачем человеку знать работу конвейера чтобы наваять юзер‑интерфейс по готовым гайдам? А другой, кто получше шарит в математике, может написать предметную часть так чтобы она считала правильно, быстро и не падала. Давайте объясним ему особенности вычислений на компе, пусть для него это будет набором догм, это по‑любому быстрее чем объяснять работу АЛУ на разных архитектурах.
Ага, у нас уже есть эта парочка... А что это значит? А то что одну программу может писать несколько человек и она даже родится быстрее. А можно ли поставить ещё больше человек? Да так чтобы их можно было тасовать: сегодня он пишет бухгалтерию, а завтра каталог рецептов. Ведь если можно, то мы сможем открыть фирму «Софтварь чего изволите». Да и вообще, компами хочет пользоваться всё больше народа, требования растут, сложность растёт, написать программу вдвоём в реальные сроки уже никак. Надо придумать способ бить задачу на мелкие составляющие, раздавать кусочки сотне разработчиков, а потом надо чтобы это всё собралось и стало работать... Давайте создадим ООП.
Сложно? Очень! Но опять же внутри. Снаружи‑то: пишешь класс, который и программой‑то не является, а потом пишется сервис, который несколькими классами манипулирует. Вроде, на первый взгляд, разрозненные кусочки, но магия компилятора создаёт из них программу, которая работает как надо.
Может показаться что писать в парадигме ООП сложнее чем «просто так», но это только кажется. Да, простую программку можно написать и безо всяких классов, однако как только задача становится реальной, код разрастается до такой степени, что отладить его становится невозможно и ты просто должен побить его на куски, которые можно отладить по отдельности. И с ООП это сделать уже проще чем в «старой» парадигме с функциями и процедурами. Хоть это и требует определённой перестройки сознания.
реактивность
Отлично, благодаря ООП мы научились создавать сложные программы силами целого коллектива разработчиков. Однако, так же как компьютеры сначала стали а потом прекратили быть персональными, наши системы уже не ставятся на отдельные машины, мы предоставляем наш сервис как услугу и на наш сервер заходят сотни и тысячи человек и надо их как‑то обслуживать одновременно. И тут мы обнаруживаем что хотя к нам ломятся толпы, наш процессор как‑то не очень нагружен. Дело в том что он, зараза, очень быстрый, а вот другие части системы (периферия, сеть, диски) не очень. А ещё есть кране медленный пользователь. И что делать? Ну, давайте придумаем асинхронность. Пусть программа будет разбита на мельчайшие кусочки, мы будем закидывать данные в обработчики и, не дожидаясь пока он отработают, нагружать всё новые и новые. А когда обработчик досчитает, он нам как‑то сообщит и мы там как‑нибудь его результат объединим с другими и получим то что нам надо и гораздо быстрее.
Сложно? Крайне сложно! Требуется полная перестройка сознания... Или нет? Посмотрев на задачи, мы увидим что они часто типовые: множество одинаковых задач внутри что банка, что соцсеточки. Нууууу и... мы же уже умеем делать фреймворки, так давайте сделаем ещё один несколько. Уберём всю сложность под капот. Пусть программист пишет компоненты по определённым правилам, использует соответствующие типы данных и аннотации, а дальше уже наше (крутых спецов) дело чтобы всё это завелось как надо.
AWS и вот это всё
Спроектировать и построить современную систему сложно что на своих мощностях, что на облаке. Помимо тех плюсов облаков, которые перечислены на сайте любого сервиса, упрощение для разработчика состоит в том что сложность можно наращивать постепенно, на каждом этапе принимая решение как действовать дальше: переходить на своё или платить больше сервису.
Действуя в ситуации неопределённости (а сейчас большинство проектов стартует именно так), ты упрощаешь себе задачу в целом, стартуя на облаке. Даже не смотря на то что придётся изучить какие‑то иные подходы и решения.
В общем, резюме:)
Системы усложняются не потому что кот‑то хотел всех поставить рачком и доминировать. Задачи меняются — меняются инструменты. Меняется объём задач — меняются подходы к решению и опять инструменты.
А то что раньше каки‑то другие люди приходили в профессию — так раньше и трава была зеленее, и дефки жопастее, что ж теперь? Не надо сравнивать «тогда» и «теперь». Возьми любой энтерпрайз, которому 30 лет (ну ладно, не любой, я тоже читал про поиск программистов на Алголе). Он уже 3–4–5 раз переписан на новые технологии и не потому что людям делать нечего. Просто «тогда» задачи были такие что его можно было написать вчетвером на Паскале, и всё отлично работало. Но «сейчас», казалось бы, та же самая задача разрослась настолько что для решения менять надо всё: парадигмы, языки, инструменты, организацию труда, вообще всё!
И если, скажем, одну гостиницу ещё можно автоматизировать на Дельфи, то сеть уже вряд ли (или ну очень упороться надо). А внешний сервис, который работает с разными сетями, наверно, уже совсем нет.
Рассуждая о сложности, надо сопоставлять сопоставимое. Современное web‑приложение сложнее сделать чем 30 лет назад «программку с окошками»? Безусловно сложнее! Можно ли решить задачу web‑приложения той программкой? Ну... если и можно, то для разработчика это будет не проще, а сложнее. А то что это надо обеспечить гигагерцами и гигабайтами где‑то там под капотом, что ж не зря ж люди старались, создавали современные машины. Пусть машины работаю, а люди радуются что им удалось.
Комментарии (24)
excoder
19.06.2023 07:02+1Касаемо сложности. Я начинал со смеси Borland C и ассемблера, но сейчас с огромным удовольствием работаю в экосистеме Питона. Кажется, это ближе всего к тому, о чём мечтали. Где нужно присыпаем нативным кодом конечно. Но весь "клей" – только питон.
Веб-разработка: мое личное мнение – не туда (сам начинал с Ajax в IE-5...). Оно всё не предназначалось для этого. Экосистема компилируемого в вебпаки тайпскрипта или того хуже реактскрипта туда через тайпскрипт – это худшее что можно было придумать. Разработка для веба стала ригиднее нативной. Грубо говоря, от изменения в коде до результата на экране максимальное время сейчас в вебе, пока всё это богомерзие, подумать только! – скомпилируется. Это дичь. Притом что компилятор-то ненастоящий! Это всё бездны, бездны node_modules.
Wan-Derer Автор
19.06.2023 07:02У меня сейчас открыто несколько десятков вкладок в браузере и все они нужны: для работы, учёбы, "общего развития". И дело не в том что они открыты одновременно, я могу их закрыть и открывать по мере необходимости. Дело в том что мне нужно множество разных ресурсов. И что бы я делал если бы не было браузера? Да, часть ресурсов это "статическая" информация и её можно заменить книгами. Но это только часть, с остальными я должен взаимодействовать. И как это сделать? Поставить пару десятков приложений (плюс к тем что уже стоят)? Следить, обновлять и пр.?
Куда должен был пойти web кроме как в браузер как единый клиент и плюс-минус типовые UI?
Что касается бесконечных уровней абстракции, то спорить я не буду т.к. не спец, но вот пару приложений бэк+фронт делать приходилось. И на React, и на Angular. Да, когда создаёшь новый проект, в него накачивается бесчисленно модулей: пустой проект и уже 300 Мб. И дев-сервер подтормаживает (зато удобно: починил - посмотрел). Но потом-то я собираю проект и получаю всего несколько файлов HTLM-CSS-JS общим объёмом уже 300 кб, что неплохо для приложения на несколько экранов и кое-какой логикой. И какие там уровни абстракции? Исполняется единый JS под виртуалкой внутри браузера? Подключены только нужные модули, код получается относительно плоским: ну т.е. вряд ли программист написал был лучше без огромных усилий по оптимизации. Работает интерфейс достаточно быстро. Что ещё надо?
Не, иногда надо - работа с железом (RS-232 и пр.), а браузер совершенно справедливо огорожен от аппаратуры клиента. Ну тут уж либо писать десктоп, либо разворачивать клиент-сервер у себя - кто как умеет :)
excoder
19.06.2023 07:02+1Я согласен что в конце получается вроде как "тонкая штучка". Но вот сам процесс разработки. Очень тяжело, буквально чувство ожирения. У меня вроде как все среды, IDE для этих дел организованы, но всё равно по итогу у меня "время до результата" сильно лучше с С++ чем с вебом, изо всей этой webpack-канители. Это очень странная ситуация.
Wan-Derer Автор
19.06.2023 07:02Имеется в виду трудность переключения между языками: бэк - фронт - вёрстка? Да, это трудно, а главное результат не очень в тех местах где ты не специалист :)
Но справедливости ради, кодом описать UI тоже непросто, я пробовал на пример Java - тоже простыня текста и полная безнадёга :)
excoder
19.06.2023 07:02Я вот именно про описание UI кодом. Это очень тяжело, как по мне.
Может быть конечно есть люди, кому это как раз лучше всего.
Языки — это okay, но всё же в плане сохранения энергии, лучше если языков меньше.
me21
19.06.2023 07:02+1Есть такая штука NiceGUI. Строит интерфейс в браузере по описанию в Питоне. Обработчики событий в Питоне. События и обновления интерфейса передаются через вебсокет. У них сам вебсайт на этом построен. Посмотрите, вдруг для чего-то пригодится.
excoder
19.06.2023 07:02+1Прикольно! В целом, с питоном последние годы повеселее. Dash (+ любые существующие react-компоненты) очень неплох, абстрагирование противного web-слоя очень приятно. Dash очень важен тем, что его много, "не пропадёт". Также появилась возможность генерировать интерфейс в первом приближении в ChatGPT, который о нём в силу широкого распространения он хорошо знает. Это чрезвычайно удобно. Есть также ReactPy. Но всё это всё равно про декларативное определение интерфейса кодом...
excoder
Пишу веб-приложения, стараясь не трогать react, npm, webpack и вот это всё :) Dash/ReactPy спасают. А так да, я ума не приложу, как это раньше в Делфи я мог нащелкать за пять минут интерфейс, который сейчас делается чуть ли не месяцами в Вебах. Отказ от визуального программирования интерфейса – ну это же глупость какая-то. А из-за врождённой уродливости всего подхода нормальных визуальных средств, которые хотя бы поверх react работали – нет! И, извините конечно, но в VCL было абсолютно всё, что есть в мире react, и гораздо больше.
Wan-Derer Автор
Да, мне тоже не очень понятно почему визуальные средства разработки развиваются так медленно, а то и не развиваются вовсе.
forthuse
Как думаете, а подход WebUI взлетит?
Браузер в качестве View в десктопных проектах (WebUI)
Wan-Derer Автор
Этот подход летает уже давно. Для разных языков есть т.н. шаблонизаторы, позволяющие в HTML-разметку с помощью специального синтаксиса внедрять объекты языка. Бэк считает состояние объекта, а шаблонизатор рендерит его в HTML. Это позволяет вэб-программистам делать в т.ч. и квази-десктоп приложения. Почему квази - а потому что в комплекте полагается иметь web-сервер (обычно запускается вместе в бэком).
Это работает, но обычно только для маленьких приложений. Современные интерфейсы сложны и всегда есть желание поручить их отдельному человеку. Ну а у него есть React и зачем ему что-то другое? :)
Hardcoin
В вебе это постоянно пытаются сделать, но получается каждый раз плохо. Одна из проблем - адаптивность. На Дельфи её не было, поэтому и форму набросать быстрее.
Другая, ещё более важная - обмен с сервером. На Дельфи программа одна, общая, а в вебе есть разделение на клиент и сервер, из-за этого есть протоколы обмена и просто нельзя сделать, например, глобальную переменную, которая будет доступна везде. Данные нужно туда-сюда передать.
excoder
На мой взгляд, были и клиенты, и серверы, и всё делали в Delphi. Очень продвинутые писали истории, и толстые клиенты, и тонкие. У меня ощущение такое, что пришли "детки", имеющие перед глазами только Web как он есть, и наконструировали всё то что сейчас имеем.
Hasthur
А можете подсказать, какие проекты были/есть по этой теме? Мне тоже кажется, что ВПИ для веба - тема интересная и перспективная. И даже есть некоторое недоумение насчёт: "а почему этого до сих нет". Представление о сложностях есть, но хотелось бы в живую посмотреть, где такое не взлетело
excoder
Я уже начинаю думать, что это лобби веб-девов :) ведь если будут быстрые визуальные и общепринятые инструменты, кто же тогда будет трудиться в поте лица над кодопределенными интерфейсами? Точно не они. Рынок вырос, а сдувать его акторы не хотят.
Hardcoin
А каким образом можно запретить сделать бесплатный открытый инструмент? Вас что, разработчики открытого реакта в подворотне подловят и изобьют?
excoder
Там имхо надо всё снести и заново построить, чтобы удовлетворить сложность требований нормальным дизайном, а не тем что наворотили за последние 15 лет. (Ну подумайте сами: shadow dom – это вообще как? Нормально с точки зрения дизайна систем? Или давайте может быть ещё одну абстакцию поверх этих запилим?). Делать такой инструмент поверх того что уже есть – всю жизнь положить, а выхлоп не гарантирован.
Hardcoin
Поверх реакта не надо. Можно просто поверх html+javascript, что бы в браузере работало.
excoder
И опять придётся дом поверх дома. Дом-3 блин.
Hardcoin
Что ж, можно написать свой антибраузер.
SergeyPyankov
Если брать уже упомянутую Delphi, то она предлагает как минимум две библиотеки для этого:
excoder
Там есть такое. Но оно всё... ну такое. Альтернативное. :)
Hasthur
Звучит конспирологически :) Но с другой стороны - ситуация действительно странная... Даже с позиции фронтенда - это многолетнее жевание разномастных
кактусовфреймворков, которые полноценно в этом отношении мало кого устраивают. А на вопрос "почему так?" - вопрос встречный: "А какая альтернатива?". Темы кроссбраузерности, адаптивности вёрстки и кастомной вариативности контролов действительно непростые, но фундаментально разрешимые. Я и сам подумывал в эту сторону, вот и хотелось бы взглянуть на чьи-то попытки/результаты в этом направлении ) Ведь наверняка были жеHardcoin
Начать можно буквально с ms word, у которого было/есть сохранение в html, но хорошо работающим оно никогда не было.
Далее есть большое количество конструкторов сайтов. Хотя бы тильда. Они не получают большого распространения среди профессионалов не из-за заговора (нет у нас общемирового чата, где мы договариваемся не использовать такие редакторы ради сохранения зарплат), а из-за крайней ограниченности и не всегда хорошего результата. Как только появится проект, в котором сверстать можно будет быстрее (и так же по качеству), чем вручную, на него быстро все перейдут.