Comments 50
По-настоящему глубоко понимает даже высокоуровневые вопросы (например, архитектуру) только тот, кто сам временами пишет код. А из тех мест, где решения (такие как выбор инструментария) принимают менеджеры, которые код в глаза не видят, на основе рекламы и UML-диаграмм, лучше бежать куда глаза глядят.
Впрочем, возможно я ошибаюсь: кукла Барби не может врать.
Вся суть статьи вот в этих цитатах от автора:
"Детки, не учитесь кодить.Вместо этого освойте моделирование."
"Всего этого вы можете добиться, используя мощь императивных языков программирования".
Т.е. не учитесь кодить - учитесь моделировать, а для этого надо кодить! Ахаха))
Или альтернатива: "А может, этот путь не для вас, и вам подойдет что-то еще".
P.s. А вот декларативные языки, вероятно, получат новую жизнь с появлением ai. И будут не только в конфигах, html, sql и т.п. Это теперь ещё и промты-декларации. Декларируешь: "сферический конь в вакууме". В ответ сразу получаешь результат от нейросети.
этот путь не для вас, и вам подойдет что-то еще
Пельмени, тюльпаны, когтеточки...
А вот декларативные языки, вероятно, получат новую жизнь с появлением ai.
А декларативный код, что — не код?
У меня в телефоне был контакт «Саша Линк». Когда мне надо было составить особо хитрый запрос на LINQ, я открывал мессенджер и писал: «Это Данила. Ай нид хелп».
По-настоящему глубоко понимает даже высокоуровневые вопросы (например, архитектуру) только тот, кто сам временами пишет код
Когда мы начинали учить программирование, примерно это звучало как "по настоящему глубоко понимает С только тот, кто понимает ассемблер и осилил трехтомник Д. Кнута" (и это мы еще припозднились с входом в программирование, т.к. изначально это вроде как звучало "не понимаешь железо микропроцессоров - не лезь в программирование").
Постепенно уровень того, что нужно "для глубокого понимания" превратился в "без понимания яваскрипт нет глубокого понимания ReactJS и неплохо бы подучить базовые алгоритмы".
А попутно выходят статьи "крутой сеньор не может накодить простой алгоритм" и многие соглашаются что "ему это и не надо задачи-то другие", при чем сеньор-то общепризнанный и комментируют тоже не идиоты.
Невозможно (и не нужно) знать всё до самых низов. Моделирование, по большому счету, это просто еще один уровень выше. Те кто понимает более глубоко - конечно, нужны будут, но... сколько сейчас нужно тех, кто умеет в ассемблер, а сколько нужно тех, кто умеет в java ?
Моделирование, по большому счету, это просто еще один уровень выше.
Я с этим не соглашусь.
Возьмём очень высокий уровень, например CSS. Хороший CSS'ник стоит дорого. (Только действительно хороший: тут, например, был ниндзя, который гонки написал на голом CSS. А ещё можно подписаться на codepen, они раз в неделю разные крутяки рассылают, там тоже попадаются ниндзи). Хотя с алгоритмами (в смысле Кнута, O() и т.п.) CSS'ник дел не имеет.
А модельер-собеседник не нужен никому. И никакой т.н. «ИИ» это не изменит.
Ну что может «намоделировать» человек в области оформления, если он не знает, как это конкретно устроено? Какую-то конкретную систему кодирования, а лучше много разных?
Так же не соглашусь с тем, что Ассемблеристы мало кому нужны
Если Ассемблеристы пойдут в разработку, то другие просто не смогут с ними конкурировать и не смогут работать. Но в тоже время нужны и другие программисты
Если человек пишет на Ассемблере его руками оторвут, потому что предложение такого уровня специалиста очень маленькое
Второе пришествие вижуал бейсика)) я долго не мог понять, что мне напоминает весь этот промоушен АИ, кодогенераторов и прочего, и вот именно прочитав начало статьи понял - 30 лет назад один математик-программист, пересев с ЕС и Меры с Камаком за персоналку под виндоуз именно так расписывал мне, молодому радиоинженеру, написавшему 2 курсовика на Фортране и пару штук на ассемблере, перспективы развития программирования. Не взлетело. И Дельфи не взлетело, и UML с разными средами проектирования за несусветные сотни тысяч долларов. HyperSignal, Cadance, Mentor Graphics - я больше чем уверен, что многие вообще не в курсе что это такое и какое отношение они имеют к производству ПО. И так же не уверен что они ещё продолжают тренды 20 летней давности в своих продуктах типа как нарисовать модельку, верифицировать, а потом сразу засунуть в пзу в какой нить железке типа телефона Филлипс.
Нет, интересно конечно, надо изучать, пробовать.. но осадочек остаётся)
Дельфи-то тут при чём? Вполне себе традиционная среда вполне себе традиционной разработки на вполне себе традиционном языке программирования. Щас ещё, если адепты пробегут, напишут, что Дельфи живо и скоро выйдет очередной релиз.
Delphi назвать живым сложно, сильно нишевое стало.
Но концепции дельфевые вполне себе живы, просто получили более удачные реализации в других инструментах. Так что уж как концепция Дельфи точно не умерло.
А какие там были концепции? Вопрос без подвоха, мне Delphi как-то не зашло и мимо прошло, хотя там, где прошла моя юность, оно было ну очень популярно, я в то время упарывался в Сишечку - в итоге, как будто, угадал, хотя мотивы у меня были на тот момент совершенно неадекватные, типа "фу, Паскаль, фу, бегин-енд, вот то ли дело фигурные скобки!" Видел иногда, как знакомые на этом Delphi формошлёпили - какие-то незнакомые ключевые слова замечал в языке, которых, вроде, не было в "классическом" вузовском Паскале, ну и редактор этих самых формочек выглядел куда развесистее, чем в моём Visual C++, где вся "визуальность", похоже, ушла в название.
Я вам прям список не дам, потому что Дельфи, к сожалению, давно не использую.
Из очевидного - визуальный редактор UI.
и IDE ассистанты, которые сейчас нормой для всех IDE стали. Но во времена когда они уже отлично работали в дельфи, в других IDE только кривые зачатки появлялись.
Ну и C#, конечно.
Еще override дико не хватало после дельфи в плюсах. К счастью его таки добавили позднее.
С# создан человеком, создавшим Delphi.
Да и сам Delphi жив, но сейчас модно использовать "свободные языки", а Delphi проприетарный - проблема в основном в этом. Плюс закрытость большинства компонентов и отсюда отсутствие интероперабельности. Ну и Delphi это 99% разработка под десктопы, а сейчас это не модно , всем подавай микросервисы, фронт и бек, сервера приложений и прочее.
Это не мода, это простая страховка от рисков.
В чем страховка?
Если контора, которая поддерживает и продаёт используемый код разорится или по какой-то причине решит прекратить поддержку, его всё-таки как-то можно будет использовать в "аварийном режиме". Или даже развивать самим/с помощью подрядчиков.
Поэтому крупняк так любит OSS. Да, когда есть разработчик - это прекрасно, но если разработчик по той или иной причине помре, процессы не останавливаются.
Delphi, мне казалось, подвымер ещё в те времена, когда на Windows практически безальтернативной средой разработки на "свободном языке" C++ была Microsoft Visual С++ - очень "несвободная", закрытая и платная. Что там ещё-то было, а, Visual Basic - всё то же, только Basic вместо C++. Кривая ранняя Java, на которой всё выглядело, как будто пришло из какого-то не по-хорошему другого мира. Ну и где-то там слегка местами начинал прорезаться C#. Может, под Linux было больше "свободы", но на клиентскую разработку под него, по-моему, вообще никто всерьёз не смотрел. Как будто бы Delphi в смысле 'несвободы" на общем фоне совершенно ничем в худшую сторону не выделялся. За микросервисы не знаю, но, вроде, не вижу вокруг окончательного и всеобщего ухода в браузеры, как когда-то пророчили, так что разрабатывать гуй для десктопа так или иначе по-прежнему надо.
Ну и Delphi это 99% разработка под десктопы, а сейчас это не модно , всем подавай микросервисы, фронт и бек, сервера приложений и прочее.
N-tier архитектура и хайлоад и раньше были. Микросервисы назывались компонентами (DCOM и иже с ним). Брокеры сообщений типа CORBA. Что относительно радикально изменилось с тех времён - веб-морда, могущая работать на любом компе без плясок с установкой дистрибутивов. Единственная причина почему тогда не взелтели микросервисы - тогда в разработке работали инженеры, которые оценивали плюсы и минусы решений. А не вчерашние продавцы пылесосов, которые оценивают за сколько смогут себя потом продать на собесах если прикрутят к телеге пятое модное колесо.
А какие там были концепции?
+ Явное желание помочь связать программу и модель данных на самых ранних этапах создания, не всегда удачно, вспомним ту же BDE, но идеи были весьма прогрессивные.
В Delphi как-то пытались впихнуть MDD - Model Driving Development. Bold for Delphi это называлось. В Model Maker или в Rational Rose рисуешь бизнес-классы, потом по ним автоматически генерировалась схема базы данных и заготовка бизнес - приложения. Весьма заманчиво выглядело, я даже потратил довольно много времени на погружение. Все бы хорошо, но код Bold for Delphi был закрыт. Потом выяснилось, что на больших объемах всё адски тормозит, приходилось опускаться на нижний уровень, т.е. терялось все преимущество. Потом выявили ошибки, несовметимые с возможностью коммерческого применения. Чуть не загубили дорогой проект, помню. Потом, когда таки решились все переписать в "классической" форме, всё завелось и весьма быстро.
А мне Watcom нравился . Как я его make в MultiEdit затащил.. но ориентировался конечно на Borland)
Одна из концепций Делфи остается только в Делфи. В C# она частично ещё используется, но только в WinForms. Это визуальные компоненты. Те, которые ставились непосредственно в саму среду разработки, которые могут работать даже в дизайнтам.
Например, из свежих из коробки в Делфи: можно визуально в дизайнтайм сделать запрос на REST сервер, распарсить полученный json в датасет и вывести его в таблицу (список и т.д.). А при клике по строке запустить проигрывание онлайн аудиопотока. И всё это всё ещё в дизайнтйам. Потом собираешь под нужную платформу и получаешь готовый плеер.
Это, типа, можно одному компоненту приказать сделать запрос, потом, глядя на строку ответа в его свойствах, менять туда-сюда код парсера и наблюдать, что и как при этом отображается в таблице?
Да, компоненты в Делфи - это тот же самый код, который мы пишем в своем приложении. Т.е. выполнять и делать он может что угодно. Выполнять, конечно будет сама среда. Изменять и создавать компоненты можно на живую в среде, достаточно просто перекомпилировать пакет компонента.
Например, компонент - 3D контекст. Т.е. 3D редактор. Компонент может знать, когда он находится в режиме дизайна, а когда нет. Мы можем отображать доп. элементы управления типа якорей или компаса для навигации и позволять перемещать объекты по сцене. А в режиме работы всё это скрывать.
Делфи отчасти позиционировался как визуалбейсик, только нормальный, со всей вытекающей отсюда ответственностью) Если серьёзно, не было конечно у него такого плейсмента как у вижуал бейсика, но попытки отвоевать нишу были.
Щас ещё, если адепты пробегут, напишут, что Дельфи живо и скоро выйдет очередной релиз.
Очередной релиз у них был недавно, так что нового придется подождать.
Давайте так - задача разработчика даже шире чем построение модели. Задача разработчика - это описание некоторого варианта будущего (реализуемого в рамках возможностей вычислительной системы), причем описание полное и непротиворечивое.
Соответственно, чтобы описать желаемое будущее, неплохо хотя бы для себя понимать - чего же мы хотим. И это - первое чему надо учиться разработчику (вообще-то говоря, всем людям следует этому учиться, но в большом количестве профессий вы можете иметь кашу в голове, и при этом сносно выполнять повседневные обязанности - но не в разработке!).
Дальше - после того как у вас в голове есть вполне определенная картина будущего, необходимо ее полно и непротиворечиво описать (а при обнаружении неоднозначности или неполноты - скорректировать). Вот тут в дело вступают языки программирования. Потому что естественный язык позволяет легко совершить ошибку, так как его средства слишком выразительны. Язык программирования на порядки беднее естественного языка, и требует местами знатно извратиться чтобы выразить довольно простые концепции (такие как "одновременность"). Однако, бонусом вы получаете встроенную в язык однозначность, защищающую вас от свойственных естественным языкам расплывчатых и неоднозначных описаний.
Поэтому - во-первых, надо уметь мыслить полно и непротиворечиво, а только во-вторых учить специальный язык программирования. Знание только языка программирования - ничего не дает. Работая со студентами, я регулярно видел людей, которые профессионально непригодны к программированию. Не потому что они не могут выучить Java или C++ - а потому что им нечего сказать на этом языке. Ну не родит голова достойные мысли, что с этим поделаешь ?!
В этом смысле, я скептически отношусь к проектам типа визуальных сред программирования, поскольку они пытаются понизить порог входа не там, где он на самом деле есть. Понятно что программирование на ассемблере или в машинных кодах - это проблема. Но с изобретением фортрана и сонма других языков высокого уровня, этой проблемы больше нет. Снижая порог еще дальше - вы получите больше людей, которые задумчиво таскают мышкой по экрану управляющие блоки в надежде что случайно получится что-то дельное (годится для младших детей, познающих мир в формате экспериментов - но не годится для взрослых). Кроме того, картинки-пиктограммы всегда будут иметь более низкую информационную емкость, и сколько-то сложная программа (с которой еще можно как-то работать в текстовом виде) - в визуальной среде будет просто необозрима.
Помогает ли изучение моделирования программировать ? Да - ровной в той же степени как изучение высшей математики или физики. Это сложная деятельность, которая требует определенной дисциплины мышления (и вообще умения думать). Если вы освоили это, то и программирование для вас не будет большой проблемой - всего лишь еще один язык на который надо перенести свои мысли.
Анекдот напоследок. Студент в СССР сдает историю КПСС, и делает это откровенно плохо. "Вы совершенно не думаете над своими ответами!" - укоряет его преподаватель. "Так Ленин же запретил!" - радостно заявляет студент. Преподаватель: "*#@&^#@ ??!". Студент: полное собрание сочинений, том такой-то, страница такая-то, абзац, последнее предложение на странице. Преподаватель достает с полки и открывает том сочинений вождя: "Было бы ошибкой думать...". (C) В.И.Ленин
Можно этот комментарий сделать отдельным постом, чтобы я его в закладки смог положить? ;)
Глубоко ошибается тот, кто думает, что изделиями программистов являются программы, которые они пишут. Программист обязан создавать заслуживающие
доверия решения и представлять их в форме убедительных доводов, а текст
написанной программы является лишь сопроводительным материалом, к
которому эти доказательства применимы.
- - Эдсгер Вибе Дейкстра
сколько-то сложная программа (с которой еще можно как-то работать в текстовом виде) - в визуальной среде будет просто необозрима.
на таких принципах промышленные контроллеры программируют и оно работает, мнооогие годы
А почему тогда все разработчики сред для этих самых "языков стандарта МЭК" делают кастомный блок, где можно записать текстом кусок программы ? И почему за исключением элементарных проектов (например, где жесткую релейную логику меняют на МК) - этими блоками активно пользуются ? И уж тогда совсем непонятно, почему нельзя просто всю программу сделать текстом, чтобы не тыкать мышкой в эти блоки и в них проваливаться ?
Мне, например, за это гораздо больше нравились контроллеры серии I7xxx и pds-7xx от ICP-DAS. Не извращаешься с непонятными визуальными изысками, а вот тебе библиотека, и пиши на Borland C++ 3.1 как в славные 90-е годы на i386. :-) Мы себе забабахали как-бы эмулятор этой среды в Linux и всю логическую отладку с юнит-тестами и прочими плюшками делали там. А потом уже компилировали под железо. После полноценных CI-CD пайпланов и нормальной среды разработки - обратно ползти под Codesys - пытка...
Наверное тоже кто то запретил :) Уловно говоря "до" МЭК, ну или точнее вместо МЭК было виртуально соединение алгоритмических блоков, только не мышкой и красиво а на экранчике в 8 цифр, явно делали чтобы непрограммистам было понятнее
Сейчас же без проблем ПЛК контроллеры на ардуино и прочих привычных языках программирования
Моделирование - эта танчики клеить и гандамов собирать? Ну да, всяко интереснее, чем отлаживать перегонку джонсонов
Проблема современного IT в том, что многие стали путать программирование с написанием кода. Это заметно уже из посыла в заголовке, где моделирование противопоставляется программированию. На самом деле моделирование - это составная часть программирования. Чтобы написать программу, сперва нужно построить модель. Конечно вовсе необязательно использовать какие-то блок-схемы или редакторы моделей. Модель можно построить и в голове, но это будет именно модель и с неё всегда всё начинается. И если проект большой, то после придумывания модели следующий этап - это формализация требований к ней, донесение сути модели до других разработчиков и т.д. И только потом начинают писать код.
Здесь же идёт противопоставление частного общему. То же самое, что сказать "Не учитесь водить машину, учитесь крутить руль". Но почему вообще так вышло? Как мы до этого докатились? Всё просто: спрос на услуги программрования несколько десятилетий назад превысил предложение, стали расти зарплаты и стало не хватать людей. Когда нехватка людей обострилась, включили конвейер обучения. И чтобы учить можно было практически любого, всю эту айтишку полностью разложили, формализовали, и начали всё это дело модульно преподавать на курсах для того, чтобы человек, не понимающий и не чувствующий программирование, мог овладеть определёнными навыками, чтобы быть в состоянии кодить отсюда и до обеда. Тот самый манки-кодинг. Очевидно именно это автор называет программированием.
С одной стороны, не так уж плохо быть просто кодером без какого-то глобального понимания всех вещей: деньги платят нормальные, работёнка не пыльная, и если у тебя высокий уровень прилежности и ответственности, то ты легко станешь неотъемлемой частью любой команды. С другой стороны, таких непонимающих кодеров стало так много, что иногда доходит до абсурда, что разработчик смотрит разбор задачи на литкоде, чтобы отсортировать массив объектов по значению свойства. И отовсюду льются рассуждения, типа учи это, а вот это не учи, прочти четыре главы этой книги, чтобы стать мидлом и шесть, чтобы стать сеньором. А потом оказывается, что на собесе срезают талантливого самоучку из-за того, что он назвал только пять паттернов, а вместо него берут выпускника курсов, который вызубрил 20 паттернов. И всем плевать, что самоучка может своими словами в мельчайших подробностях разложить как работает та или иная реализация Dependency injection, а выпускник курсов будет смотреть в эту реализацию и не увидит там ни фабрик, ни синглтонов.
Так вот, главная проблема современного IT в том, что кто-то решил, что программирование надо учить, а не понимать. И уровень разработчиков стали оценивать не по уровню понимания, а по количеству выученных тем. Что ж, если вы уже выучили паттерны и алгоритмы, попробуйте выучить ещё и моделирование.
Так вот, главная проблема современного IT в том, что кто-то решил, что программирование надо учить, а не понимать.
На хабре когда-то раскрывали причину этой темы. Если ооочень коротко, то была проблема нулевого года, всем очень срочно требовалось 100500 разработчиков переписать кучу говнокода. Спрос превысил предложение, программистами стали вчерашние водители, им стали платить как президентам. Потом когда кризис миновал - они все оказались на улице. Но так как "я же программистом работал!" , то они все пошли по компаниям в гуглы-шмуглы, устраиваться фейк-программистами. Чтобы отсеять такой откровенный мусор - разрабы с компаний стали придумывать заградительные условия, как же можно отфильтровать 3х-месячных программистов от нормальных прогеров. Вот и пошли в ход всё что смогли придумать: и спрашиваем чем A отличается от B, почему люки круглые, паттерны программирования итд. Так и живём...
Хуанг тоже говорил не учить программирование... Советовал биологию, химию, финансы и сельское хозяйство.
В 3д моделирование тоже пойти можно, там вроде тоже неплохо платят
Эти ваши нейросети даже GNU Autotools не могут на CMake перевести...
Учитесь строить модели
Но:
Ваш мозг уже строит модели
Фух, я уж было подумал, что-то нужно делать.
Для правдоподобности автору не плохо було посмотреть определение модели, хотя бы в Википедии. А потом, возможно, и статья была бы другая
Не хватает только кейса, когда задаёшь параметры модели словами и нейросеть выдаёт тебе готовый файл модели.
Даже не знаю, с какой стороны подступиться к этой задаче.
Что такое модель?
Модель состоит из...
Модель принимает на вход...
Модель выдаёт на выход...
Модель подчиняется следующим правилам...
Модель порождает...
Модель влияет на...
Сложно.
Около века назад все человечество было в панике. Рабочих лешали хлеба машины. И чем дальше шел прогресс тем больше людей оставалось без работы. Однако никто не зрит в корень. Без работы оставались те, кто не захотел дружиться с машинами - они уходили в сторону. Без хорошей работы оставались те, кто просто изучал как машины работают и становились мало оплачиваемыми операторами.
Однако остались на коне те, кто сохранили навыки обслуживания машин. Кто понимал как машина работает. Кто мог в любой момент починить машину. Кто мог заменить машину в критической ситуации. Такие люди стали получать в 2-3 раза больше чем получали. Так как работодатель лучше заплатит им чем откажется от машин.
И даже сейчас на любом заводе есть главный инженер и пара его помощников с ЗП много выше чем у простого трудяги. Так как это повелители машин. Они не только знают что машина делает, но могут рассказать до шестерёнки как она это делает. А также устранить любой сбой в технологическом процессе
Теперь смотрите. АИ пишет код и есть только моделеры и менеджмент. И вдруг код начинает работать не так как надо. Кто решит проблему? Моделер? Менеджер? Аналитик? Да черт то там. Только программер. Человек кто кодил руками. Только он способен будет управлять хаосом. Да, от этого человека будет требоваться понимание работы ИИ. Это должен быть крутой программист. Но и получать он будет больше чем сейчас в разы. Так что программисты будут нужны и через 100 лет. Но не в таком количестве. И зарабатывать такие будут больше.
Те кто не захотят дружиться с ИИ уйдут из ИТ. Те кто научатся только декларировать ИИ - будут операторами на малой ставке. А вот те кто будут в состоянии заменить ИИ в критической ситуации и понять что там ИИ нагородил - это будут те, кто соберёт сливки в новой ИИ революции.
Я думаю все понимают каким станет размер глаз просто аналитика или менеджера, когда в один момент система начнет работать не так как нужно, а рядом нет того кто умеет читать и понимать код
Если все начнут делать модели, кто будет писать инструмент работы с моделями? Писать так же через модели, делая обертку вокруг обертки? Я конечно понимаю, что вычислительных мощностей сейчас много, но не настолько же
Да и если мы утратим искусства низкоуровневой разработки, то в ту же секунду все пойдет по знакомому месту. Так что не нужно всем забывать про программирование, нормальные кодеры тоже нужны
Программировать, на самом деле, не так сложно. Действительно, хороший разработчик должен разбираться в архитектуре и связях, как минимум, текущего проекта. Но..., самое трудное, искать и находить ошибки, причины сбоев, не держания нагрузки, хотя всё по мануалу. И многое подобное. Пусть ИИ будет находить это и исправлять. Пусть легаси за минуту в нормальную систему превратит.)))
моделирование отличается от болтовни тем, что можно формально проверить модель на соответствие какимто критериям. а для этого модель нужно строить на какомто описательном языке, который поймёт так же и верифицирующий автомат... ой, помоему мы изобрели язык программирования
Детки, не учитесь кодить. Вместо этого освойте моделирование