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

Хайп начался в 2021 году, когда Gartner написал: «К 2024 году 65% всех приложений будут созданы с использованием low-code технологий» — и это разлетелось по всем CIO-чатам.

Причина такого ажиотажа понятна: был ковид, нужно было срочно переводить всех на удаленку, у айтишников рук не хватало и дыры затыкали чем угодно. Эту задачу лоукод худо-бедно решал: быстренько что-то сваяли, запустили —и бизнес доволен. О том, что это придется поддерживать, развивать, совершенствовать никто не думал.

Однако, суета вокруг ковида давно прошла, а интерес к лоукоду по данным Google по-прежнему высок.

Источник: Google Trends
Источник: Google Trends

Это странно, потому что никак не коррелирует с реальным положением дел. Факты таковы, что к 2024 году только 15% предприятий используют платформы low-code для разработки критически важных приложений, признает тот же Gartner. Но тут же обещает, что уж к 2029 году этот показатель вырастет аж до 80%. Ага, верим! (См. здесь.)

Как я полюбил лоукод (и разлюбил)

Нет, я нисколько не против самой идеи лоукода, и действительно, есть кейсы, где этот подход работает. Вот, например, потоковое сканирование — четкий и понятный технологический процесс, который автоматизировать при помощи лоукода просто милое дело. Помните, была такая система — Kofax? — Практически идеальный инструмент для потокового сканирования. Там был жестко зашитый процесс: подготовка – сканирование – распознавание – валидация – верификация – генерация PDF – экспорт.

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

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

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

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

Но все сказанное не отрицает того, что лоукод это годная технология. Просто она должна знать свое место.

Лоукод — лукавый термин

Маркетологи быстро уловили разрыв между желаниями бизнеса и возможностями ИТ. В 2014 году аналитики Forrester дали этому разрыву обтекаемое название — low-code — и пообещали, что теперь системы можно будет собирать без программистов. Бизнес поверил — и это сработало.

Но что стоит за этим обещанием? Low-code не отменяет программирование, он просто меняет его форму. Когда вы, например, перетаскиваете блок «Отправить письмо», вы просто вызываете заранее написанную обёртку над SMTP-клиентом. Всё уже сделано — просто не вами. Но как только вы захотите немного отклониться от стандартного сценария, нужно писать свой код — только не в привычной IDE, а в каком-то фирменном редакторе.

Low-code прячет сложность, но не устраняет её. Архитектура и поведение системы предопределены платформой. Простота достигается за счёт потери гибкости, а конфигурирование порой сложнее программирования. Как только задача выходит за пределы конструктора — начинается борьба с системой, а не создание приложения.

Однако на рынке произошло настоящее чудо — чудо переобувания на лету. Вчерашние вендоры СЭД, BPM и CRM-систем, языков 4GL вдруг осознали себя лоукодерами и на рынке вдруг обнаружилось несметное количество лоукод-платформ. Естественно, они не изменились внутри, всего лишь поменяли свои лозунги.

Прадедушки нынешних лоукодов

Технически low-code строится на тех же основах, что и инструменты прошлых десятилетий: визуальное моделирование, шаблоны, конфигурирование вместо программирования, декларативный подход. Всё это мы уже видели в RAD-платформах 90-х, 4GL-языках, визуальных конструкторах, ERP-системах, DSL-фреймворках. Даже в Excel с макросами есть черты low-code.

То есть, Low code — это не новая технология. Это новая упаковка старой идеи. Вот несколько примеров, чтобы не быть голословным:

VisualAge — это серия визуальных сред разработки от IBM из 1990-х, позволявших собирать приложения с помощью перетаскивания компонентов и генерации кода, задолго до появления современных low-code платформ. Особенно известна версия VisualAge for Java, ставшая основой для будущей Eclipse IDE. Хотя VisualAge опережал своё время идеей визуального программирования, он был слишком тяжёлым и ориентированным на разработчиков, чтобы стать по-настоящему массовым решением.

Visual Basic появился в 1991 году как инструмент быстрой разработки приложений (RAD) от компании Microsoft. Слово «Visual» в названии отражает ключевую особенность платформы — визуальное проектирование пользовательских интерфейсов с помощью перетаскивания элементов (кнопок, полей ввода, списков) прямо на форму, что значительно упрощало создание интерфейсов по сравнению с традиционным программированием. Несмотря на удобство визуального дизайна, Visual Basic не является low-code платформой в современном понимании, потому что для реализации бизнес-логики и взаимодействия с приложением всё равно требовалось писать код на языке Visual Basic.

PowerBuilder — один из ветеранов мира быстрой разработки бизнес-приложений, родился в начале 90-х в Sybase и долгое время был мечтой корпоративных разработчиков. Это был мощный визуальный конструктор форм с собственным скриптовым языком, который позволял создавать сложные клиент-серверные приложения гораздо быстрее, чем писать всё с нуля. PowerBuilder до сих пор жив и поддерживается, хотя в эпоху облаков и low-code платформ уже не на острие прогресса, но для многих организаций — это надёжный рабочий инструмент с богатой историей.

Картинку сгенерил ChatGPT, но как живые! Примерно такими я их и помню. Кстати, коробка с VisualAge все еще валяется дома -- остатки склада. Теперь раритет!
Картинку сгенерил ChatGPT, но как живые! Примерно такими я их и помню. Кстати, коробка с VisualAge все еще валяется дома -- остатки склада. Теперь раритет!

Как мы видим, история лоукода началась задолго до того, как появился сам термин. VisualAge, Visual Basic, PowerBuilder — все они по-своему стремились упростить разработку, спрятать рутину за визуальными инструментами и сократить время до готового продукта. Но у каждого из них был предел: как только дело доходило до нестандартных требований, разработчику всё равно приходилось «нырять под капот».

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

Что, если совсем без кода?

Вслед за low-code поднялась новая волна — no-code, как более радикальная версия той же идеи. По сути, это один и тот же подход, просто доведённый до предела: никакого кода вообще, даже намёка на программирование. Только мышка, готовые блоки, визуальный редактор и мечта о том, что теперь бизнес сам себе сделает всё, что нужно.

Идея выглядит красиво: любой сотрудник сможет собрать рабочее приложение, автоматизировать процесс, сделать небольшую CRM. Реальность же — как обычно. Пока задача простая и линейная — типа собрать лендинг в Tilda, сделать опрос в Typeform или настроить интеграцию в Zapier — всё работает. Но стоит бизнес-процессу выйти за рамки конструктора — и начинается квест: API не хватает, логики не хватает, валидации нет и так далее. А главное — нет понимания, как это действительно работает.

No-code создаёт иллюзию освобождения от разработчиков. Но вместо того, чтобы не зависеть от них — вы просто зовёте их позже. Чтобы почистить, переписать или интегрировать то, что «мы тут сами нащёлкали». Это не устраняет технический долг — это копит его втихаря.

Low-code хотя бы честен: кода будет меньше, но он нужен. В no-code обещают, что не нужен вовсе. Только забывают уточнить, что не нужен до тех пор, пока вам не надо что-то настоящее: масштабируемость, контроль версий, тестирование, сложная логика, безопасность.

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

Парадокс Less Code

Думаю, не открою Америки, если скажу, что большинство разработчиков терпеть не могут лоукод и всё, что с ним связано. Это особенно забавно, ведь те же разработчики обожают инструменты, которые избавляют их от рутины и шаблонного кода, и охотно пользуются высокоуровневыми абстракциями, чтобы писать меньше кода вручную.

Впрочем, кода в больших проектах меньше не становится — ведь сложные вещи невозможно описать парой строк. Просто теперь разработчикам не нужно тратить время на однообразные задачи: библиотеки, умные IDE, фреймворки и, наконец, AI-ассистенты берут на себя всю рутину, позволяя сосредоточиться на действительно интересных задачах. Но о возможностях AI — в следующий раз.

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

А великий и ужасный Spring? Он действительно инкапсулирует сложность и забирает на себя контроль за управлением бинами, но взамен предлагает разработчику чёткие правила и богатый набор возможностей. Он говорит: «Я настрою за тебя окружение, подключу нужные компоненты, обеспечу транзакционность — просто опиши, что тебе нужно, а не как именно это должно работать».

Итак, современные инструменты делают все, чтобы разработчик меньше писал код и больше думал. То есть, именно их надо было по праву назвать low-code, но слово было уже занято. Пришлось как-то выкручиваться и придумали термин «Less Code», не столь прозрачный и звучный, но зато честный. Less code — это про экономию усилий без иллюзии, что код больше не нужен. Это про повышение уровня абстракции, автоматизацию рутинных действий и упор на выразительность. Разработчик по-прежнему пишет код, но делает это быстрее, чище и с помощью мощных инструментов: DSL, шаблонов, генераторов, аннотаций, умных IDE, так далее.

Фундаментальная разница между low-code и less code в том, что в первом случае вы действительно пишете немного кода, но все остальное — это для вас «черный ящик», это компоненты платформы, в которые нельзя заглянуть и что-то изменить; во втором случае — это все код, будь он написан вручную или сгенерирован какими-то инструментами. Даже сам фреймворк — это тоже код, который можно посмотреть и при необходимости модифицировать.

А потом просто компилируете и запускаете свое приложение, так же, как и «Hello, world!» В случае low-code приложение запускается в собственной runtime-среде, которую вы тоже не контролируете.

То есть, в отличие от low-code, less code не обещает, что любой сможет «собрать приложение за вечер». Он просто говорит: ты остаёшься программистом, но сэкономишь время на повторяемом. И это честная сделка — без обманчивых обещаний и без потери контроля.

Ирония в том, что настоящий прогресс разработки идёт именно по пути less code, а не low-code. Но рынок любит громкие названия, и low-code звучит более революционно. Хотя в реальности он скорее про смену упаковки, а не сути.

Заключение

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

1. Иллюзия простоты

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

2. Иллюзия "гражданских разработчиков"

Лоукод обещает, что справится любой — любой специалист может стать гражданским разработчиком . На деле — профессиональные разработчики всё равно приходят: позже, но по тревоге. Разбираться, чинить, переписывать. Теоретически можно наладить разделение труда между гражданскими и профессиональными разработчиками, но на практике такое встречается редко.

3. Иллюзия скорости

Лоукод уверяет, что все можно сделать быстро. Да, если сценарий типовой. Но в нестандартных задачах всё усложняется: конфигурации, ограничения платформы — всё это пожирает время. Думайте заранее о границах применимости лоукода, чтобы не завязнуть в проекте навечно.

4. Иллюзия низкой стоимости

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

5. Иллюзия универсальности

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

6. Иллюзия упрощения поддержки

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

7. Иллюзия революционности

Лоукод приходит как передовая технология. Однако, это старая идея под новым названием. RAD, 4GL, визуальные конструкторы — всё это уже было. Просто у лоукод маркетинг лучше.


Поэтому главный совет — не соблазняйтесь иллюзиями. Используйте low-code там, где он действительно уместен. А где нужна надёжность, масштаб и гибкость — лучше остаться на стороне профессиональных инструментов less code.

Подписывайтесь на наш телеграм-канал BPM Developers — про бизнес-процессы: новости, гайды, полезная информация и юмор.

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


  1. VitaminND
    17.06.2025 06:43

    Утащил в закладки - как раз пишу low-code IDE )))


    1. stas_makarov Автор
      17.06.2025 06:43

      А подробнее? Что за IDE?


    1. broderix
      17.06.2025 06:43

      Я тоже сначала воодушевился, но потом почитали лицензию https://openbpm.ru/license-agreement, чего и вам желаю.

      Итоговые рекомендации от GPT:
      - Для внутреннего использования – можно, но с риском прекращения лицензии.
      - Для коммерческого ПО – не подходит, так как запрещено распространение и модификация.
      - Для стартапов – опасно, так как нет гарантий долгосрочной поддержки.
      - Альтернатива – искать OpenSource-решения с разрешенной модификацией (MIT, Apache 2.0).

      Если планируется серьезный бизнес на базе OpenBPM – лучше связаться с правообладателем (ООО «Хоулмонт Самара») для переговоров о коммерческой лицензии.


      1. openbpm_pm
        17.06.2025 06:43

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


  1. Indemsys
    17.06.2025 06:43

    Уже месяц пишу в стиле telepathic-code с Claude.
    Забыл все спецификации языков. Telepathic-code не зажат в рамки спецификаций — только идеи и мысли. Не нужно знать ни нотаций, ни синтаксиса, ни правил и загружать себя ими. Это всё мелочи, с которыми справится достаточно развитый агент.

    Все low-code, no-code, Camunda — всего лишь неудачные приближения к telepathic-code.


    1. broderix
      17.06.2025 06:43

      А можно по-подробнее про telepathic-code?, оно не гуглится


      1. Ravius
        17.06.2025 06:43

        Telepathic-code"" likely refers to a concept of communicating ideas or instructions without traditional coding languages, potentially using a more direct, thought-based approach or a highly simplified, intuitive system

        Вайбкодер он, ловите вайбкодера.

        А вообще, на выходных loveable dev давал безлимитный доступ к моделькам.

        Я сделал такой вывод, что power bi и прочие дашьорды не нужны. Можно все на чистом react писать. (Ещё пару месяцев...и пару месяцев на принятие).

        Сидишь надиктовываешь. Я сложную визуализацию сделал на d3.вместо блоков - команды "хочу такой-то фильтр/график/граф". ...я добавил timeslider, что ни один low code не позволит.


  1. vfadeev_sam
    17.06.2025 06:43

    Да сдох он этот лоу-код уже. Кому в голову придет платить за кубики и стрелочки если LLM строчит за 3 копейки все, что захочешь. И нарисует тоже если нужно


  1. Gvargs
    17.06.2025 06:43

    Я не такой специалист как Вы и многие кто на Хабре,но напомню, что первый автомобиль ехал чуть быстрее человека-ходящего. Но с главной мыслью,что low code решение всех задач я абсолютно согласен, конечно это лукавство. Для решения прикладных бизнес задач вполне себе достаточный инструмент, а вот для ИТ задач конечно маловато будет.


  1. itGuevara
    17.06.2025 06:43

    DataExpress, VBA и масса иных разношёрстных систем, включая использование библиотек, которые снижают объем кода (начиная от jQuery) – все это «как бы» low code.

    Поэтому "что такое low code" – не совсем понятно. И анализ «какого-то» low code лучше проводить на конкретном его классе. Предложил такую классификацию:

    Исполняемый BPMN в Open Source Runa WFE (WfMS). Hello Calculator и немного классификации

    BPMN-LCNC: исполняемый BPMN – он уже по определению «low-code» (в простых случаях даже no-code, см. Hello Calculator). 

    Что жду от «условно» BPMN «no-code» (BPMN+) как следующего этапа развития «WFE system» (во главе с Camunda \ Flowable \ Activiti), а сейчас все исполняемые BPMN системы (BPMN - engine) – это совсем не про BP mgmt., а лишь про WF mgmt. (WfMS).

    1. Добавление в спецификацию языка моделирования данных (dataflow mgmt.), тогда workflow mgmt. (BPMN) + dataflow mgmt. = business process mgmt.

    2. Формализацию «языка диаграмм» бизнес-процессов и архитектур (Enterprise Architecture) на DSL (Domain-Specific Language, Предметно-ориентированный язык): в итоге получим Diagrams as Code, Architecture as Code, Business Process as Code и т.п. Как вариант RDF\OWL (Linked Data \ Semantic Web).

    3. Добавления языка запросов к схемам \ скрипту DSL (точнее хранилищу триплетов, квадов), например, SPARQL.

    4. Возможность моделирования на верхнем уровне (верхнеуровневые процессы).

    В итоге появится возможность моделировать как workflow, так и dataflow и получать фактически no-code (окошки UI рисовать будет нужно и привязывать к ним ранее определённые в репозитарии объекты данных). Это будет исполняемая модель не только по workflow, но и dataflow, плюс модель с полностью семантической формализацией и соответственно с возможностью использования семантических инструментов анализа: от SPARQL (иного языка запросов, но конечно не SQL) до semantic reasoner.  



  1. engin
    17.06.2025 06:43

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


    Не то что ненавидят, палят на кострах и предают анафеме.
    Что видно по опросам среди скрипт кодеров. Больше сказать в сообществах присутсвуют группы т.н. Швондеров, которые всячески выталкивают попытки инициировать диалог на такие темы.
    Даже если Вы создали свой умный IDE, красиво обернули его и выставили в магазине на полку в коробке, Вас все равно в таких кругах будут забрасывать тухлыми яйцами. Никакие демонстрации или бесплатные демо версии не спасают. Знаю, т.к. сам опекся в таких аудиториях. Как бы Вы честно не аргумеyтировали и не показывали работу, все это бесполезно, т.к. мышление большинства сложившихся скрипт кодеров инертно, даже если они и в тихаря просят что-то покодить в GPT.
    Полная противоположность в.с. это аудитория где люди сидят на идеях и обсуждают решения в алгоритмах и ищут приемлемые подходы. Так если здесь моя карма всегда выше полинтуса никогда не поднималась, намеки на продукт модераторами сразу уходили в бан, то к примеру на Reddit обсуждения только за сутки превышают 30К с активным интересом, вопросами, сравнениями и инженерными дискуссионными спорами.
    Единственно что да, народ нигде не любит когда автор применяет в качестве редактора своего текста GPT и с этим трудно пока обстоят дела, нужно стараться писать человеческим стилем с ошибками и недомолвками без чрезмерной вежливости и структурирования текста.;)


    1. stas_makarov Автор
      17.06.2025 06:43

      Вот только последний абзац не понял -- это в чей огород?
      Чатик я конечно спрашивал, но тут от него только историческая справка про VisualAge и прочих. Ну можно было по старинке из Вики скопипастить.
      А что насчет вежливости и структурирования -- наверно десять лет в ИТ-журналистике не прошли бесследно.


      1. engin
        17.06.2025 06:43

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

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

        Если модератор согласен с такой позицией, он в правилах сообщества просто укажет

        Запрещён синтез или имитация сообщений участников без явного указания на это

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

        Это правило действует вне зависимости от цели (шутка, демонстрация, стилизация) и защищает доверие в обсуждениях.

        Допустимо:

        • Использование синтетических примеров с указанием, что это не реальные участники;

        • Генерация образцов диалогов для иллюстрации идеи, с соответствующей пометкой.

        Недопустимо:

        • Публикация поддельных цитат без пометки;

        • Стилизованные "ответы" от имени реальных пользователей;

        • Смешивание реального диалога и искусственно созданного без разграничения.

        Нарушение этого правила может привести к удалению публикации и временной блокировке.

        Не панацея, но все же предпочтение здравому усмотрению админов.


        1. stas_makarov Автор
          17.06.2025 06:43

          Спасибо, конечно. Но далеко ушли от темы


          1. engin
            17.06.2025 06:43

            Не за что,как было сказано, в контекcте того, что Love Code, еще не для всех выглядит привычно. Особенно на классических IT-площадках, где правят бал pragmatic C++-чане и ментальные наследники Visual Studio.

            Опрос неплохо показывает реакцию data science-ориентированной публики, с оговоркой что более чем 50% юзеров отмахнулись читать после прочтения заголовка. По ходу публикация не отражает ситуацию покрытия полного спектра задач. Как правило все упирается в веб разработку. Мне, например, не хватило позиций, связанных с автоматизацией кодирования в прототипировании, по взаимодействию с железом. Всё, что выходит за рамки анализа данных — как будто не в счёт.

            Я уже просто плюнул и описал свой путь к собственной IDE (если что, блог на английском). Сейчас тестирую этот материал не вслепую, а среди профильных сообществ — инженеров, автоматчиков, разработчиков нестандартных систем. Там реакция куда продуктивнее, чем стрельба опросами по воробьям. Считаю это гораздо честнее и ближе к настоящему R&D.


            1. stas_makarov Автор
              17.06.2025 06:43

              Ну, у всех свои задачи.
              Буржуйскую мову трошки разумеем, в общем-то без костылей в виде чатика.
              так что было бы интересно читнуть.


              1. engin
                17.06.2025 06:43

                Отправил в ЛС