«Я хочу творить, а не быть следствием чужого творчества. Я хочу принадлежать к тем, кто создает смыслы, а не быть плодом этого смысла».

Представьте себе ситуацию. Скоро истекут сроки подачи документов в колледж. Очередная партия новичков изберет профессию, адепты которой постоянно задаются вопросом: «А нужны ли будут программисты через год... через пять лет... или через десять лет?». И хотя горячие дебаты на этот счет уже улеглись, в воздухе висит немой вопрос: не настанет ли час, когда крупные языковые модели, такие как ChatGPT, заменят нас на поприще написания кода. Неважно, кто ты — абитуриент, зависший в нерешительности перед выбором ВУЗа, или матерый кодер, я предлагаю тебе остановиться и кое-что переосмыслить. А поможет нам в этом деле... кукла Барби.

credit: Apple
credit: Apple

В начале прошлого года в нашей индустрии наступил период эсхатологического переосмысления. На рынок хлынули инструменты, вызывающие озвученные мной выше опасения. Так, летом OpenAI опубликовала обновление, сделавшее генерацию кода еще более качественной. Система Vercel v0, как утверждается, позволяет создавать готовый к работе React-код по одному только описанию его функциональности.

Однако по какой-то причине люди до сих пор с энтузиазмом изучают программирование. В начале прошлого года Code.org обнародовала предложение включить информатику в число обязательных предметов для получения аттестата о среднем образовании. В нескольких штатах это уже сделали. В поддержку этой инициативы существует немало удобных для ребенка инструментов изучения программирования: как минимум, это Scratch, Tynker и Hopscotch. В октябре специалисты лаборатории MIT Media Lab, занимающиеся программой Lifelong Kindergarten, запустили проект OctoStudio. С его помощью Scratch, в основе которого лежат готовые блоки кода, вместо браузера можно будет запустить на мобильном телефоне. Огромный шаг навстречу будущему поколению программистов. Фактически, идея о том, что «детям стоит научиться работать с кодом», наконец находит свое воплощение. Но сейчас, когда машины все лучше и лучше справляются с написанием кода, остается ли этот подход актуальным?

Независимо от сложившейся ситуации, я хотел бы дать вам совет. Если вы учитесь, работаете в сфере образования или занимаетесь повышением квалификации, я хочу предложить вам сделать паузу и подумать. Что, если бы вы не учились писать код? Что, если бы вместо того, чтобы учиться кодить, вы научились бы создавать модели?

Что такое модель?

Модель — это репрезентация отношений между двумя системами. А система — это набор элементов, которые связаны друг с другом. Имея на руках структуру модели, вы без труда найдете узлы и отношения в системе, которую она представляет. Модель как бы сообщает нам: «Вот эта штука происходит во-от отсюда». Или, как минимум, описывает ключевые компоненты систем.

В детстве мы вместе с отцом собирали модельки автомобилей. Маленькие пластмассовые машинки поддерживали символическую связь со своими полноразмерными собратьями путем сохранения общих черт. Как правило, это были цвета, базовые формы и относительные размеры внешних элементов. Глядя на модель, можно представить, понять и предсказать наличие тех же особенностей и в моделируемой системе. Если модель красного цвета, то и автомобиль, который она имитирует, тоже должен быть красным. Это определение справедливо для любого контекста, в котором мы используем слово «модель». Даже супермодели символически представляют, как должен выглядеть обычный или идеальный человек. (Существует ли моделируемая система в этом случае на самом деле — это уже другая проблема... но об этом мы поговорим чуть позже).

К счастью, чтобы освоить искусство моделирования чего-либо, не придется склеивать пальцы (как у Барби) или экспансивно худеть до эталонных параметров. Каждую секунду в течение каждого дня мы уже занимаемся моделированием. И с этим ничего нельзя поделать.

Наш мозг непрерывно строит модели

В основе разума лежит память, а память сама по себе является моделью. Когда определенная комбинация стимулов воздействует на наш организм, это приводит к активации множества нейронов, связанных между собой в единую сеть. Эти нейроны могут сближаться или отдаляться друг от друга, делая более вероятным срабатывание определенного маршрута в следующий раз, когда эти стимулы (или что-то достаточно похожее на них) окажутся в поле зрения наших органов чувств. Это сближение или отдаление происходит, по сути, механически, за счет выработки определенных гормонов. Они, в свою очередь, образуются по относительно детерминированной схеме в ответ на другие стимулы, как правило, на обретение какого-то желаемого внутреннего состояния (пища, репродуктивный процесс и т. д.). В своей книге Grasp Санджай Сарма называет это «фундаментом» когнитивной системы, который служит основой для некоторых подходов в психологии, таких как оперантное обусловливание.

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

Усложним задачу

В один прекрасный день первобытный человек сделал кое-что очень странное. Он начал придумывать другие модели, описывающие сеть отношений между различными внешними системами. Доподлинно неизвестно, зачем ему это понадобилось. Возможно, в целях улучшения коммуникации с соплеменниками. Грубое изображение медведя или другого хищника, которое вызывает нечто вроде эффекта присутствия, напрямую способствует выживанию. К тому же это не требует особых усилий. Визуального сходства с объектом как правило достаточно, чтобы в сознании другого человека «всплыла» аналогичная модель — при условии, что у него было достаточно сенсорного опыта, чтобы построить модель, соответствующую этим стимулам. Если мы оба видели медведя, и я покажу вам его фотографию, то, скорее всего, у вас возникнет чувство узнавания, которое воскресит в памяти характерные особенности, присущие всем виденным вами медведям: покрытый шерстью, коричневый, милый, и так далее. Но иногда нейроны могут повести себя не совсем так, как ожидалось. Изучением этого специфического явления занимается семантика.

В нашем мозге очень много нейронов. Потенциальное количество связей между ними применяется для оценки количества отдельных сетей или моделей, которые они могут поддерживать. Это грандиозная цифра. Поэтому рисовать картинку всякий раз, когда нужно показать кому-то свою модель, слишком утомительно. Так появилась письменность. (Да-да, это серьезное упрощение, мы вернемся к этому вопросу чуть позже). Возьмем, к примеру, следующий текст:

Быстрая рыжая лиса перепрыгивает через ленивую собаку.

Текст
Текст

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

Модель ситуации
Модель ситуации

Не знаю, что приходит вам на ум, когда вы читаете этот текст, но он должен был задействовать ряд моделей — то есть соответствующих нейронных связей, — относящихся к свойствам этих существ. Мы знаем, что существует определенная система. В ней есть два существа: собака и лиса. Лиса характеризуется следующими свойствами: она рыжая и быстрая, а собака, по-видимому, отличается ленью. Может показаться, что понятие «лень» выходит за рамки нашей модели, но на самом деле это не так. «Лень» — это символ, который мы присвоили опыту, изначально являющемуся сенсорным стимулом. Сюда входят ощущение раздражения, когда товарищ по команде проявляет недостаточно активности, представления о ленивых людях — обычно это синонимы слов «неряшливый» или «неопрятный», — и чувства, вызванные социальным гнетом и установкой, что «лень — это плохо».

То, что мы только что построили, Дэниел Уиллингем называет контекстной моделью, и это один из самых мощных навыков, выработанных человечеством. Мы взяли модель (комбинация нейронов, образовавшая описанную текстом систему), преобразовали ее в другую модель (символы в тексте выше) и использовали ее для создания еще одной модели (комбинации нейронов, представляющей ситуацию, которая существует в вашем сознании). Фух!

Испорченный телефон

Сказать, что все это невероятно сложный процесс, — не сказать ничего. А чем запутаннее система, тем выше вероятность, что с ней возникнут какие-либо проблемы. Например, у вас может быть совершенно другая модель, отражающая ваш опыт взаимодействия с пушистыми зверями. И если я покажу вам фотографию медведя, она может не содержать часть атрибутов медведей, которые присутствуют в моей модели. Если в ваших моделях по какой-то причине отсутствуют атрибуты, подразумевающие потенциальную опасность, у нас возникнут неприятности. С этой проблемой относительно легко справиться, если в основе наших моделей лежат сенсорные стимулы, полученные из непосредственного опыта. Все, что мне нужно будет сделать, это показать вам (надеюсь, с помощью видео на YouTube) примеры того, что случается с людьми, которые слишком близко подходят к медведям. В конце концов, семантика не так уж и сложна.

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

Мы только что сыграли в эту игру. Вы прочли предложение «быстрая рыжая лиса перепрыгивает через ленивую собаку». Однако у вас нет сенсорных стимулов для этой конкретной ситуации. Все, что у вас есть, — это коллекция моделей, связанных с каждым элементом сцены, так что объекты (собака и лиса), их свойства (лень, быстрота, рыжесть) и их взаимоотношения (прыжок, скорость, один «перепрыгивает» другого). Все это в комплексе строит в вашем сознании определенную модель существующей в тексте системы.

Но вот, в чем подвох: ни собаки, ни лисы никогда не существовало. Точно так же как нет корневых сенсорных стимулов, какой-то реальной, находящейся где-то во вселенной системы, которую описывает приведенная модель. Системы нет, а модель есть — и в вашем сознании, и в моем собственном. Видите, каков наш «испорченный телефон»? Мы способны смоделировать вещи, которых нет и не было никогда!

Строим более совершенные модели

Такие «фейковые» модели очень легко построить в среде, наполненной разнообразными словами и абстракциями. То есть, увы, в любой социальной среде. Люди уникальны, они уделяют огромное количество времени построению моделей несуществующих систем. В отличие от конкретной фотографии медведя, модели, которые мы только что описали, ничем не подкреплены. И, тем не менее, они вездесущи. Их можно встретить в сельском клубе, в религиозных или политических речах и даже в статьях на Medium (?).

Поскольку нам хочется, чтобы наши модели были как можно точнее (то есть соответствовали реальному миру и тому, что в нем можно испытать), мы изобрели способы создания устойчивых моделей, не подверженных «испорченному телефону». У нас даже есть целый язык, который включает в себя средства верификации — возможность взять модель, выйти в мир и убедиться, что она соответствует реальности. Этот язык — математика, и она издавна эффективно используется людьми для обмена поддающимися проверке моделями. Мы используем математику для описания отношений между элементами модели и утверждаем, что эти отношения сохранятся, если изучить фрагменты исходной системы. Однако у исходных систем все равно есть аспекты, которые сложно выразить средствами математики.

Например, любая система существует в реальном времени. То есть некоторые свойства объектов исходной системы будут меняться в зависимости от того, в какой момент времени мы их исследуем. Классический пример из физики — объект в свободном падении, где расстояние объекта от земли непрерывно меняется. Мы видим эти изменения наглядно, когда наблюдаем систему воочию. Однако при математическом описании взаимосвязи между землей и камнем созданные нами модели (пусть даже строгие) не способны отразить изменения, происходящие со временем, в интуитивно понятной форме.

Решение этой проблемы заключается в построении моделей, свойства которых меняются с течением времени. Мы проводим научные эксперименты с использованием репрезентативных образцов, испытываем автомобили и самолеты в аэродинамических трубах, строим масштабные модели зданий, двигателей и плотин. Все это делается при допущении, что поведение малых узлов, их свойства и взаимосвязи являются репрезентативными для целевой системы. Зачастую мы возводим подобные системы, чтобы донести до других людей информацию об устройстве Вселенной. Однако предполагаемое сходство этих систем с целевыми позволяет нам пойти еще дальше и совершать открытия в поведении целевой системы с помощью открытий, сделанных в поведении модели. В мире компьютеров можно легко найти модели такого рода: это симуляции.

Компьютерное ПО является средством моделирования par excellence. Оно поддерживает строгие, проверяемые взаимосвязи, присущие языку математики, и в то же время допускает, что компоненты могут развиваться, изменяться со временем и даже влиять на окружающую среду. Более того, благодаря своей детерминированной природе, каждая из этих моделей (гипотетически) воспроизводима, что позволяет преодолеть проблему «испорченного телефона!

Модели, молотки и гвозди

Не всякая система представляет собой гвоздь. Поэтому не каждую систему стоит моделировать при помощи молотка. Если вы не играете в испорченный телефон, имеете возможность проверить достоверность информации или ставки попросту невысоки, вполне подойдет некий эмоциональный способ моделирования. Его крайне сложно реализовать на сухом и прямолинейном «компьютерном» языке. Меж тем, он может показать себя даже эффективнее. По этой причине мы прибегаем к использованию совершенно разных типов символов — лично мне больше всего нравятся музыкальные. Типы моделей, которые мы создаем, столь же разнообразны, сколь и системы, которые мы с их помощью изображаем.

В своей книге The Model Thinker Скотт Э. Пейдж перечисляет целый ряд причин, по которым мы создаем модели. Как правило, тип создаваемой модели определяется результатом, которого мы стремимся достичь. Некоторые модели «хороши» только в узком диапазоне контекстов. В своей книге об алгоритмах Стив Скиенна приводит забавный, хотя и анекдотичный пример с теорией плоской Земли. Это не лучшая модель, если нужно предсказать движение звезд, ракет или спутников. Однако если речь идет о строительстве дома и анализе его будущей надежности... модель плоской Земли сработает просто на ура.

На самом деле, сфера алгоритмов, находящаяся на стыке математики и информатики, особенно интересна с точки зрения моделирования. Она содержит целые подборки потрясающих решений как обычных, так и нестандартных проблем. Это достигается за счет концентрации усилий на очень небольшом наборе обобщенных структур данных. Пусть вас не отпугивают термины вроде «обобщенные структуры данных». Это некие совокупности «узлов» с очень специфическими отношениями. Они «обобщены» в том смысле, что отдельные узлы не наделены рядом особых свойств. Это позволяет легко и свободно использовать их при составлении моделей определенных систем.

Цель ученого в области информатики — хорошо разбираться в методах моделирования и выбирать те, что подходят для решения конкретной задачи. Джордж Полиа в своей книге «Как решить проблему» называет этот процесс «проведением аналогии». Это не уникальная практика для компьютерных специалистов — Полиа был математиком. Говоря о теоретической физике, Ричард Фейнман однажды сказал, что «каждый хороший физик-теоретик знает шесть или семь различных теоретических представлений для одного и того же физического явления». Не знаю, как вы, но когда я услышал Фейнмана, говорящего о «теоретических представлениях», я понял, что фактически речь идет о «моделях».

Это выходит далеко за рамки технических дисциплин. На выборах кандидаты и партийные объединения применяют различные модели, описывающие население, его потенциальное поведение и поведение противников. Успех или неудача будут определяться, в частности, способностью кандидата оценить текущее состояние моделируемого процесса. А также навыком манипулирования смоделированной социальной системой. Социальные системы, кстати, моделировать чрезвычайно сложно — именно этот тезис Дэн Рокмор приводит в своем эссе для The New Yorker, подчеркивая предполагаемую несостоятельность средств моделирования в нетехнических дисциплинах.

Всё по полочкам

«Сложно» не значит «невозможно». И уж тем более, что не стоит даже попытаться. Моделирование возможно и неизбежно, с разной степенью строгости, в любой дисциплине. Разница между превозносимой надежностью моделей в естественных науках и высмеиваемой неадекватностью математических моделей в политологии заключается, если воспользоваться фразой Скиенны, в «масштабе». Я не имею в виду масштаб моделируемой вещи, я имею в виду масштаб самой модели. Чем ближе наша модель к реальной вещи, тем достовернее мы сможем взаимодействовать с ней, предсказывать ее поведение или манипулировать ею.

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

В социальных науках такое попросту невозможно. В человеческом мозге насчитывается около 86 миллиардов нейронов, поэтому наши ресурсы весьма обширны. Тем не менее, отсюда проистекает и ограничение для моделирования. В социальных науках изучаются системы, каждый элемент которых имеет в собственном мозге ровно столько же нейронов, сколько есть в распоряжении у исследователя. Это не оставляет возможности для полноценного моделирования человеческого поведения, не говоря уже о сложных взаимоотношениях и взаимодействиях людей друг с другом и окружающей средой. В любой модели человеческого поведения приходится поступаться астрономическим количеством деталей и нюансов. Просто-напросто невозможно создать идеально точную и при этом относительно компактную модель человеческого общества.

Однако это не означает, что социальные науки лишены моделирования как инструмента. Сообщества социологов и вирусологов на протяжении пандемии COVID-19 работали сообща, спасая жизни людей, несмотря на то, что их модели были неполными или в чем-то ошибочными.

Каждый день мы прибегаем к некоторым упрощениям — этаким моделям «плоской земли» — в таких дисциплинах, как социальные науки, трудовая динамика и медицина. При этом их использование обусловлено прагматической пользой — несмотря на все упущения и допущения. Как для строгого, так и для нестрогого моделирования справедливы слова Полиа об аналогии: «Было бы глупо не сомневаться в правдоподобности (вывода, сделанного на основе хорошей аналогии), но не менее глупо или даже еще глупее полное пренебрежение правдоподобными предположениями». Более простая цитата, приписываемая Джорджу Боксу, гласит: «Все модели ошибочны, но некоторые из них полезны».

Это справедливо для всего разнообразия моделей, особенно тех, что порождает наш собственный разум. Мы постоянно ошибаемся. Однако порой придуманные нами модели оказываются и впрямь полезны. В своей книге о моделировании Скотт Э. Пейдж предлагает придерживаться в жизни концепции «множества моделей». Поскольку всякая модель может оказаться неточной, нельзя использовать для всех возможных жизненных ситуаций одну и ту же модель. Необходимо сформировать собственную «библиотеку» проверенных, хорошо проработанных моделей на все случаи жизни. И применять ту или иную модель следует, опираясь на проблему и предполагаемый подход к ее разрешению.

В нашем арсенале метафорического моделирования должно быть как можно больше инструментов. Это касается любой сферы деятельности. Музыканты и композиторы оттачивают свое мастерство в работе со специфическими комбинациями символов, которые способны вызывать у людей общие эмоциональные воспоминания. Инженеры-программисты строят библиотеки моделей, опираясь на математические объекты и символы, характерные для компьютерного кода. Наша способность разрешать любые проблемы зависит от ширины и полноты арсенала моделей, подходящих для этой области. Поэтому важно время от времени пополнять этот арсенал.

Книжный магазин

Целью образования де-факто является расширение глубины и широты наших навыков моделирования (впрочем, это не касается систем образования, заранее расположенных к какой-то конкретной идеологии). Проблемы, с которыми мы сталкиваемся как отдельные личности и как целые сообщества, становятся все более сложными. Это приводит к росту спроса на системы образования, которые позволяют обзавестись более глубокими и разносторонними моделями. Пандемия COVID-19 и повсеместное внедрение генеративных ИИ прекрасно демонстрируют, что традиционные системы образования не справляются с поставленной задачей.

Когда я работал в Phenomena Learning, мы пытались решить эту проблему, создав систему моделирования, пригодную для применения в сфере образования. Основная цель Phenomena — помочь студентам «пополнить свой арсенал», создавая модели по различным темам STEM (комплекс отдельных, но при этом связанных друг с другом технических дисциплин в контексте описания образовательной политики учреждения либо учебной программы) и взаимодействуя с ними разными способами. Очень важно, что в число этих «способов» входит и код. Мы создали язык программирования на основе блоков, чтобы можно было разрабатывать строгие, императивные модели с минимальными ограничениями.

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

Особое внимание мы уделили наличию или отсутствию опыта у начинающих моделистов. Мы предпочли использовать блочный язык программирования вместо JavaScript, чтобы помочь неискушенным пользователям избежать синтаксических ошибок. Язык математического моделирования мы придумали для того, чтобы студенты могли брать формулы прямо со странички и в один клик приводить их в движение. Главное — сосредоточиться на модели, а не на средствах ее создания. Вовсе не обязательно владеть кодом в принципе. Наш софт поддерживает и более простые, статичные модели. Значительная часть нашей работы была связана с расширением библиотеки «компонентов», которые можно комбинировать как готовые строительные блоки.

Несмотря на то, что я уже ушел из Phenomena, моя работа на поприще создания моделей и не думает прекращаться. На своем нынешнем посту в Coursemojo я работаю над созданием системы, которая улучшает контекстную модель, описанную мной выше. Программа принимает текстовые модели, наподобие тех, что можно встретить в классах языковых школ, и помогает студентам строить более обширные и глубокие ментальные модели, используя разговорный интерфейс. Помимо образовательных контекстов, я много писал о The Brain Attic — гипотетической системе, которая позволяет связать друг с другом внешние модели из какой-то конкретной области с тем, чтобы подтвердить или опровергнуть их состоятельность.

Люди, которые создают смыслы

Собирать такую библиотеку, применять представления, входящие в нее, и совершенствовать их в процессе итеративного использования — это приятное и полезное занятие. Я не могу придумать лучшего обрамления для этого вывода, чем фраза Марго Робби (несправедливо обделенной Оскаром) из фильма «Барби». Помните цитату из начала статьи? Если вчитаться в нее как следует, мы увидим, как Барби, модель, порожденная разумом дизайнера, выражает желание оказаться среди людей, которые создают вещи, а не быть самой вещью (моделью).


Что же все это значит для будущих кодеров? Откровенно говоря, голое уметь писать код — это еще далеко не все. Код — это всего лишь инструмент, с помощью которого можно создавать мощные, динамичные модели. Поэтому совершенно неважно, что наше ремесло будет автоматизировано через какие-то 3-5 лет. Люди всегда будут нужны для создания обоснованных, строгих моделей, независимо от используемых инструментов и средств. Именно в этом контексте я часто рекомендую студентам, вчерашним выпускникам или людям, собирающимся войти в эту сферу, что им жизненно важно получить опыт за пределами сферы написания кода. Иными словами, неправильно хотеть быть только кодером — человеком, умеющим оперировать в специфической знаковой системе. Необходимо стремиться к тому, чтобы стать, например, «преподавателем, который умеет работать с кодом», или «специалистом по снабжению, который ориентируется в коде» — надеюсь, идею вы уловили. Фраза Барби о том, что она хочет «быть среди тех, кто создает смыслы» означает, что человеку, ступившему на путь технического образования, следует иметь намерение понимать моделируемые им системы.

Именно об этом я говорю, когда призываю «не учиться кодить» — код не должен быть самоцелью. Учитесь моделировать. Накапливайте опыт в построении четких границ между системой, которую вы пытаетесь отобразить, и ее окружением. Осознайте, какой тип среды вы используете для создания такого представления. Постарайтесь как можно яснее определить свои цели в процессе моделирования, будь то предсказание, передача информации или проведение эксперимента. Самое главное — научитесь строить проверяемые модели, различая обоснованные и измеримые и не обоснованные. Всего этого вы можете добиться, используя мощь императивных языков программирования. А может, этот путь не для вас, и вам подойдет что-то еще. Но какой бы способ моделирования вы ни выбрали, создавайте как можно больше моделей. Если каждый из нас будет пополнять свои библиотеки моделей, все наше общество научится решать проблем гораздо быстрее и лучше. А если повезет, вы даже встанете рядом с людьми, которые «создают смыслы, а не являются их плодом».

Комментарии (40)


  1. ImagineTables
    05.04.2024 16:13
    +26

    По-настоящему глубоко понимает даже высокоуровневые вопросы (например, архитектуру) только тот, кто сам временами пишет код. А из тех мест, где решения (такие как выбор инструментария) принимают менеджеры, которые код в глаза не видят, на основе рекламы и UML-диаграмм, лучше бежать куда глаза глядят.

    Впрочем, возможно я ошибаюсь: кукла Барби не может врать.


    1. WebPeople
      05.04.2024 16:13
      +6

      Вся суть статьи вот в этих цитатах от автора:

      "Детки, не учитесь кодить.Вместо этого освойте моделирование."

      "Всего этого вы можете добиться, используя мощь императивных языков программирования".

      Т.е. не учитесь кодить - учитесь моделировать, а для этого надо кодить! Ахаха))

      Или альтернатива: "А может, этот путь не для вас, и вам подойдет что-то еще".

      P.s. А вот декларативные языки, вероятно, получат новую жизнь с появлением ai. И будут не только в конфигах, html, sql и т.п. Это теперь ещё и промты-декларации. Декларируешь: "сферический конь в вакууме". В ответ сразу получаешь результат от нейросети.


      1. voldemar_d
        05.04.2024 16:13
        +9

        этот путь не для вас, и вам подойдет что-то еще

        Пельмени, тюльпаны, когтеточки...


        1. Boilerplate
          05.04.2024 16:13

          Всегда есть первый и второй пути вместо третьего...


      1. ImagineTables
        05.04.2024 16:13

        А вот декларативные языки, вероятно, получат новую жизнь с появлением ai.

        А декларативный код, что — не код?

        У меня в телефоне был контакт «Саша Линк». Когда мне надо было составить особо хитрый запрос на LINQ, я открывал мессенджер и писал: «Это Данила. Ай нид хелп».


    1. edogs
      05.04.2024 16:13

      По-настоящему глубоко понимает даже высокоуровневые вопросы (например, архитектуру) только тот, кто сам временами пишет код

      Когда мы начинали учить программирование, примерно это звучало как "по настоящему глубоко понимает С только тот, кто понимает ассемблер и осилил трехтомник Д. Кнута" (и это мы еще припозднились с входом в программирование, т.к. изначально это вроде как звучало "не понимаешь железо микропроцессоров - не лезь в программирование").

      Постепенно уровень того, что нужно "для глубокого понимания" превратился в "без понимания яваскрипт нет глубокого понимания ReactJS и неплохо бы подучить базовые алгоритмы".

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

      Невозможно (и не нужно) знать всё до самых низов. Моделирование, по большому счету, это просто еще один уровень выше. Те кто понимает более глубоко - конечно, нужны будут, но... сколько сейчас нужно тех, кто умеет в ассемблер, а сколько нужно тех, кто умеет в java ?


      1. ImagineTables
        05.04.2024 16:13
        +3

        Моделирование, по большому счету, это просто еще один уровень выше.

        Я с этим не соглашусь.

        Возьмём очень высокий уровень, например CSS. Хороший CSS'ник стоит дорого. (Только действительно хороший: тут, например, был ниндзя, который гонки написал на голом CSS. А ещё можно подписаться на codepen, они раз в неделю разные крутяки рассылают, там тоже попадаются ниндзи). Хотя с алгоритмами (в смысле Кнута, O() и т.п.) CSS'ник дел не имеет.

        А модельер-собеседник не нужен никому. И никакой т.н. «ИИ» это не изменит.

        Ну что может «намоделировать» человек в области оформления, если он не знает, как это конкретно устроено? Какую-то конкретную систему кодирования, а лучше много разных?


      1. Timbalut
        05.04.2024 16:13

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


  1. nv13
    05.04.2024 16:13
    +10

    Второе пришествие вижуал бейсика)) я долго не мог понять, что мне напоминает весь этот промоушен АИ, кодогенераторов и прочего, и вот именно прочитав начало статьи понял - 30 лет назад один математик-программист, пересев с ЕС и Меры с Камаком за персоналку под виндоуз именно так расписывал мне, молодому радиоинженеру, написавшему 2 курсовика на Фортране и пару штук на ассемблере, перспективы развития программирования. Не взлетело. И Дельфи не взлетело, и UML с разными средами проектирования за несусветные сотни тысяч долларов. HyperSignal, Cadance, Mentor Graphics - я больше чем уверен, что многие вообще не в курсе что это такое и какое отношение они имеют к производству ПО. И так же не уверен что они ещё продолжают тренды 20 летней давности в своих продуктах типа как нарисовать модельку, верифицировать, а потом сразу засунуть в пзу в какой нить железке типа телефона Филлипс.

    Нет, интересно конечно, надо изучать, пробовать.. но осадочек остаётся)


    1. SquareRootOfZero
      05.04.2024 16:13
      +2

      Дельфи-то тут при чём? Вполне себе традиционная среда вполне себе традиционной разработки на вполне себе традиционном языке программирования. Щас ещё, если адепты пробегут, напишут, что Дельфи живо и скоро выйдет очередной релиз.


      1. AllexIn
        05.04.2024 16:13

        Delphi назвать живым сложно, сильно нишевое стало.
        Но концепции дельфевые вполне себе живы, просто получили более удачные реализации в других инструментах. Так что уж как концепция Дельфи точно не умерло.


        1. SquareRootOfZero
          05.04.2024 16:13

          А какие там были концепции? Вопрос без подвоха, мне Delphi как-то не зашло и мимо прошло, хотя там, где прошла моя юность, оно было ну очень популярно, я в то время упарывался в Сишечку - в итоге, как будто, угадал, хотя мотивы у меня были на тот момент совершенно неадекватные, типа "фу, Паскаль, фу, бегин-енд, вот то ли дело фигурные скобки!" Видел иногда, как знакомые на этом Delphi формошлёпили - какие-то незнакомые ключевые слова замечал в языке, которых, вроде, не было в "классическом" вузовском Паскале, ну и редактор этих самых формочек выглядел куда развесистее, чем в моём Visual C++, где вся "визуальность", похоже, ушла в название.


          1. AllexIn
            05.04.2024 16:13
            +2

            Я вам прям список не дам, потому что Дельфи, к сожалению, давно не использую.
            Из очевидного - визуальный редактор UI.
            и IDE ассистанты, которые сейчас нормой для всех IDE стали. Но во времена когда они уже отлично работали в дельфи, в других IDE только кривые зачатки появлялись.
            Ну и C#, конечно.

            Еще override дико не хватало после дельфи в плюсах. К счастью его таки добавили позднее.


          1. alan008
            05.04.2024 16:13
            +2

            С# создан человеком, создавшим Delphi.

            Да и сам Delphi жив, но сейчас модно использовать "свободные языки", а Delphi проприетарный - проблема в основном в этом. Плюс закрытость большинства компонентов и отсюда отсутствие интероперабельности. Ну и Delphi это 99% разработка под десктопы, а сейчас это не модно , всем подавай микросервисы, фронт и бек, сервера приложений и прочее.


            1. vkni
              05.04.2024 16:13
              +2

              Это не мода, это простая страховка от рисков.


              1. themen2
                05.04.2024 16:13

                В чем страховка?


                1. vkni
                  05.04.2024 16:13

                  Если контора, которая поддерживает и продаёт используемый код разорится или по какой-то причине решит прекратить поддержку, его всё-таки как-то можно будет использовать в "аварийном режиме". Или даже развивать самим/с помощью подрядчиков.

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


            1. SquareRootOfZero
              05.04.2024 16:13

              Delphi, мне казалось, подвымер ещё в те времена, когда на Windows практически безальтернативной средой разработки на "свободном языке" C++ была Microsoft Visual С++ - очень "несвободная", закрытая и платная. Что там ещё-то было, а, Visual Basic - всё то же, только Basic вместо C++. Кривая ранняя Java, на которой всё выглядело, как будто пришло из какого-то не по-хорошему другого мира. Ну и где-то там слегка местами начинал прорезаться C#. Может, под Linux было больше "свободы", но на клиентскую разработку под него, по-моему, вообще никто всерьёз не смотрел. Как будто бы Delphi в смысле 'несвободы" на общем фоне совершенно ничем в худшую сторону не выделялся. За микросервисы не знаю, но, вроде, не вижу вокруг окончательного и всеобщего ухода в браузеры, как когда-то пророчили, так что разрабатывать гуй для десктопа так или иначе по-прежнему надо.


          1. DikSoft
            05.04.2024 16:13

            А какие там были концепции?

            Model Maker?

            + Явное желание помочь связать программу и модель данных на самых ранних этапах создания, не всегда удачно, вспомним ту же BDE, но идеи были весьма прогрессивные.


            1. IsKaropk
              05.04.2024 16:13
              +2

              В Delphi как-то пытались впихнуть MDD - Model Driving Development. Bold for Delphi это называлось. В Model Maker или в Rational Rose рисуешь бизнес-классы, потом по ним автоматически генерировалась схема базы данных и заготовка бизнес - приложения. Весьма заманчиво выглядело, я даже потратил довольно много времени на погружение. Все бы хорошо, но код Bold for Delphi был закрыт. Потом выяснилось, что на больших объемах всё адски тормозит, приходилось опускаться на нижний уровень, т.е. терялось все преимущество. Потом выявили ошибки, несовметимые с возможностью коммерческого применения. Чуть не загубили дорогой проект, помню. Потом, когда таки решились все переписать в "классической" форме, всё завелось и весьма быстро.


          1. nv13
            05.04.2024 16:13
            +1

            А мне Watcom нравился . Как я его make в MultiEdit затащил.. но ориентировался конечно на Borland)


      1. nv13
        05.04.2024 16:13
        +1

        Делфи отчасти позиционировался как визуалбейсик, только нормальный, со всей вытекающей отсюда ответственностью) Если серьёзно, не было конечно у него такого плейсмента как у вижуал бейсика, но попытки отвоевать нишу были.


      1. geher
        05.04.2024 16:13
        +1

        Щас ещё, если адепты пробегут, напишут, что Дельфи живо и скоро выйдет очередной релиз.

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


  1. ruomserg
    05.04.2024 16:13
    +30

    Давайте так - задача разработчика даже шире чем построение модели. Задача разработчика - это описание некоторого варианта будущего (реализуемого в рамках возможностей вычислительной системы), причем описание полное и непротиворечивое.

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

    Дальше - после того как у вас в голове есть вполне определенная картина будущего, необходимо ее полно и непротиворечиво описать (а при обнаружении неоднозначности или неполноты - скорректировать). Вот тут в дело вступают языки программирования. Потому что естественный язык позволяет легко совершить ошибку, так как его средства слишком выразительны. Язык программирования на порядки беднее естественного языка, и требует местами знатно извратиться чтобы выразить довольно простые концепции (такие как "одновременность"). Однако, бонусом вы получаете встроенную в язык однозначность, защищающую вас от свойственных естественным языкам расплывчатых и неоднозначных описаний.

    Поэтому - во-первых, надо уметь мыслить полно и непротиворечиво, а только во-вторых учить специальный язык программирования. Знание только языка программирования - ничего не дает. Работая со студентами, я регулярно видел людей, которые профессионально непригодны к программированию. Не потому что они не могут выучить Java или C++ - а потому что им нечего сказать на этом языке. Ну не родит голова достойные мысли, что с этим поделаешь ?!

    В этом смысле, я скептически отношусь к проектам типа визуальных сред программирования, поскольку они пытаются понизить порог входа не там, где он на самом деле есть. Понятно что программирование на ассемблере или в машинных кодах - это проблема. Но с изобретением фортрана и сонма других языков высокого уровня, этой проблемы больше нет. Снижая порог еще дальше - вы получите больше людей, которые задумчиво таскают мышкой по экрану управляющие блоки в надежде что случайно получится что-то дельное (годится для младших детей, познающих мир в формате экспериментов - но не годится для взрослых). Кроме того, картинки-пиктограммы всегда будут иметь более низкую информационную емкость, и сколько-то сложная программа (с которой еще можно как-то работать в текстовом виде) - в визуальной среде будет просто необозрима.

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

    Анекдот напоследок. Студент в СССР сдает историю КПСС, и делает это откровенно плохо. "Вы совершенно не думаете над своими ответами!" - укоряет его преподаватель. "Так Ленин же запретил!" - радостно заявляет студент. Преподаватель: "*#@&^#@ ??!". Студент: полное собрание сочинений, том такой-то, страница такая-то, абзац, последнее предложение на странице. Преподаватель достает с полки и открывает том сочинений вождя: "Было бы ошибкой думать...". (C) В.И.Ленин


    1. ValeryGL
      05.04.2024 16:13
      +3

      Можно этот комментарий сделать отдельным постом, чтобы я его в закладки смог положить? ;)


    1. garwall
      05.04.2024 16:13
      +7

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

      - - Эдсгер Вибе Дейкстра


    1. NutsUnderline
      05.04.2024 16:13

       сколько-то сложная программа (с которой еще можно как-то работать в текстовом виде) - в визуальной среде будет просто необозрима.

      на таких принципах промышленные контроллеры программируют и оно работает, мнооогие годы


      1. ruomserg
        05.04.2024 16:13
        +4

        А почему тогда все разработчики сред для этих самых "языков стандарта МЭК" делают кастомный блок, где можно записать текстом кусок программы ? И почему за исключением элементарных проектов (например, где жесткую релейную логику меняют на МК) - этими блоками активно пользуются ? И уж тогда совсем непонятно, почему нельзя просто всю программу сделать текстом, чтобы не тыкать мышкой в эти блоки и в них проваливаться ?

        Мне, например, за это гораздо больше нравились контроллеры серии I7xxx и pds-7xx от ICP-DAS. Не извращаешься с непонятными визуальными изысками, а вот тебе библиотека, и пиши на Borland C++ 3.1 как в славные 90-е годы на i386. :-) Мы себе забабахали как-бы эмулятор этой среды в Linux и всю логическую отладку с юнит-тестами и прочими плюшками делали там. А потом уже компилировали под железо. После полноценных CI-CD пайпланов и нормальной среды разработки - обратно ползти под Codesys - пытка...


        1. NutsUnderline
          05.04.2024 16:13

          Наверное тоже кто то запретил :) Уловно говоря "до" МЭК, ну или точнее вместо МЭК было виртуально соединение алгоритмических блоков, только не мышкой и красиво а на экранчике в 8 цифр, явно делали чтобы непрограммистам было понятнее

          Сейчас же без проблем ПЛК контроллеры на ардуино и прочих привычных языках программирования


  1. zergon321
    05.04.2024 16:13
    +7

    Моделирование - эта танчики клеить и гандамов собирать? Ну да, всяко интереснее, чем отлаживать перегонку джонсонов


  1. gun_dose
    05.04.2024 16:13
    +12

    Проблема современного IT в том, что многие стали путать программирование с написанием кода. Это заметно уже из посыла в заголовке, где моделирование противопоставляется программированию. На самом деле моделирование - это составная часть программирования. Чтобы написать программу, сперва нужно построить модель. Конечно вовсе необязательно использовать какие-то блок-схемы или редакторы моделей. Модель можно построить и в голове, но это будет именно модель и с неё всегда всё начинается. И если проект большой, то после придумывания модели следующий этап - это формализация требований к ней, донесение сути модели до других разработчиков и т.д. И только потом начинают писать код.

    Здесь же идёт противопоставление частного общему. То же самое, что сказать "Не учитесь водить машину, учитесь крутить руль". Но почему вообще так вышло? Как мы до этого докатились? Всё просто: спрос на услуги программрования несколько десятилетий назад превысил предложение, стали расти зарплаты и стало не хватать людей. Когда нехватка людей обострилась, включили конвейер обучения. И чтобы учить можно было практически любого, всю эту айтишку полностью разложили, формализовали, и начали всё это дело модульно преподавать на курсах для того, чтобы человек, не понимающий и не чувствующий программирование, мог овладеть определёнными навыками, чтобы быть в состоянии кодить отсюда и до обеда. Тот самый манки-кодинг. Очевидно именно это автор называет программированием.

    С одной стороны, не так уж плохо быть просто кодером без какого-то глобального понимания всех вещей: деньги платят нормальные, работёнка не пыльная, и если у тебя высокий уровень прилежности и ответственности, то ты легко станешь неотъемлемой частью любой команды. С другой стороны, таких непонимающих кодеров стало так много, что иногда доходит до абсурда, что разработчик смотрит разбор задачи на литкоде, чтобы отсортировать массив объектов по значению свойства. И отовсюду льются рассуждения, типа учи это, а вот это не учи, прочти четыре главы этой книги, чтобы стать мидлом и шесть, чтобы стать сеньором. А потом оказывается, что на собесе срезают талантливого самоучку из-за того, что он назвал только пять паттернов, а вместо него берут выпускника курсов, который вызубрил 20 паттернов. И всем плевать, что самоучка может своими словами в мельчайших подробностях разложить как работает та или иная реализация Dependency injection, а выпускник курсов будет смотреть в эту реализацию и не увидит там ни фабрик, ни синглтонов.

    Так вот, главная проблема современного IT в том, что кто-то решил, что программирование надо учить, а не понимать. И уровень разработчиков стали оценивать не по уровню понимания, а по количеству выученных тем. Что ж, если вы уже выучили паттерны и алгоритмы, попробуйте выучить ещё и моделирование.


  1. MainEditor0
    05.04.2024 16:13

    Хуанг тоже говорил не учить программирование... Советовал биологию, химию, финансы и сельское хозяйство.


  1. green_fenix
    05.04.2024 16:13
    +1

    В 3д моделирование тоже пойти можно, там вроде тоже неплохо платят


    1. funca
      05.04.2024 16:13

      Супермоделям, которых упоминает автор, думаю платят ещё больше. Вообще классный текст, с кучей отсылок к разным мемам. Правда мне кажется, что в переводе он неизбежно потерял часть шарма.


  1. DungeonLords
    05.04.2024 16:13

    Эти ваши нейросети даже GNU Autotools не могут на CMake перевести...


  1. pomponchik
    05.04.2024 16:13
    +1

    Учитесь строить модели

    Но:

    Ваш мозг уже строит модели

    Фух, я уж было подумал, что-то нужно делать.


  1. jura-49
    05.04.2024 16:13
    +1

    Для правдоподобности автору не плохо було посмотреть определение модели, хотя бы в Википедии. А потом, возможно, и статья была бы другая


  1. mad_god
    05.04.2024 16:13

    Не хватает только кейса, когда задаёшь параметры модели словами и нейросеть выдаёт тебе готовый файл модели.

    Даже не знаю, с какой стороны подступиться к этой задаче.

    Что такое модель?

    Модель состоит из...

    Модель принимает на вход...

    Модель выдаёт на выход...

    Модель подчиняется следующим правилам...

    Модель порождает...

    Модель влияет на...

    Сложно.


  1. zmiik
    05.04.2024 16:13

    Около века назад все человечество было в панике. Рабочих лешали хлеба машины. И чем дальше шел прогресс тем больше людей оставалось без работы. Однако никто не зрит в корень. Без работы оставались те, кто не захотел дружиться с машинами - они уходили в сторону. Без хорошей работы оставались те, кто просто изучал как машины работают и становились мало оплачиваемыми операторами.

    Однако остались на коне те, кто сохранили навыки обслуживания машин. Кто понимал как машина работает. Кто мог в любой момент починить машину. Кто мог заменить машину в критической ситуации. Такие люди стали получать в 2-3 раза больше чем получали. Так как работодатель лучше заплатит им чем откажется от машин.

    И даже сейчас на любом заводе есть главный инженер и пара его помощников с ЗП много выше чем у простого трудяги. Так как это повелители машин. Они не только знают что машина делает, но могут рассказать до шестерёнки как она это делает. А также устранить любой сбой в технологическом процессе

    Теперь смотрите. АИ пишет код и есть только моделеры и менеджмент. И вдруг код начинает работать не так как надо. Кто решит проблему? Моделер? Менеджер? Аналитик? Да черт то там. Только программер. Человек кто кодил руками. Только он способен будет управлять хаосом. Да, от этого человека будет требоваться понимание работы ИИ. Это должен быть крутой программист. Но и получать он будет больше чем сейчас в разы. Так что программисты будут нужны и через 100 лет. Но не в таком количестве. И зарабатывать такие будут больше.

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

    Я думаю все понимают каким станет размер глаз просто аналитика или менеджера, когда в один момент система начнет работать не так как нужно, а рядом нет того кто умеет читать и понимать код


  1. AnonimYYYs
    05.04.2024 16:13

    Если все начнут делать модели, кто будет писать инструмент работы с моделями? Писать так же через модели, делая обертку вокруг обертки? Я конечно понимаю, что вычислительных мощностей сейчас много, но не настолько же

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