Low-code поедает разработку
 Публичный пост
7 октября 2021  1533

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

Я CEO компании Loginom, которая много лет занимается созданием аналитической платформы, позволяющей проводить сложную аналитику бизнес-пользователям, то есть специалистам, не особо разбирающимся в программировании. Под сложной аналитикой я подразумеваю консолидацию, очистку данных, скоринг, прогнозирование и тому подобные задачи. Как недавно выяснилось, для этого подхода существует удачный термин — Low-code. Так как я занимаюсь анализом данных, то все описанное ниже рассматривается применительно к аналитике. Но практически то же самое можно сказать про любую разработку вообще.

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

Я более 20 лет занимаюсь продвинутой аналитикой и все это время у меня перед глазами показательный пример того, насколько могут не совпадать слова с действительностью. Любой, кто занимался анализом реальных данных знает, что 80% времени и сил уходит на очистку и подготовку данных. Качество данных — проблема номер один. Я не видел ни одного проекта, который опровергал бы это. Уверен, что у всех остальных ситуация аналогичная. Казалось бы, все должны постоянно говорить о качестве данных, вот она – главная боль любого клиента. Это должно быть темой номер один на любой конференции, но нет…

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

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

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

Первое, что необходимо четко понять и осознать – рынок меняют массовые технологии. В мире каждый год происходит огромное количество интересных прорывов в различных сферах: физика, химия, медицина, сельское хозяйство, архитектура, искусство и прочее. Однако, 4-ая промышленная революция, та самая, которая происходит у нас на глазах, связана с информационными технологиями.

Причина в том, что IT получило колоссальное распространение и проникло во все сферы. Это не нишевая технология, а самая массовая. Поэтому столь велико её влияние на всё, что происходит вокруг. Следствием огромного влияния IT на мир является и то, что топ 5 самых дорогих компаний Apple, Google, Microsoft, Amazon, Facebook – все из сферы IT. Только действительно массовые вещи перекраивают весь рынок.

Основное требование к массовой технологии – она должна быть простой в использовании и недорогой. Чем ниже планка, тем больше людей в состоянии её преодолеть. Ни одна сложная в применении технология никогда не станет массовой. Если для решений какой-то задачи можно воспользоваться несколькими технологиями, самая простая из них получит 80-90% всего рынка. По поводу «недорогой», думаю, что ничего дополнительно объяснять не надо. Очевидно, что дорогая технология не будет доступна широкому кругу пользователей.

После этого, я слышу сразу «Python – очень простой». Очень простой по сравнению с чем и для кого? По сравнению с C++ — он простой. Для людей, которые знают несколько языков программирования – он простой. Но это всё небольшая часть рынка. Для подавляющего большинства людей любой язык программирования – сложный.

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

Человеку из симфонического оркестра кажется, что все разбираются в классической музыке потому, что он только с такими и общается. Для того, чтобы понять реальную ситуацию, музыканту надо выйти на улицу, опросить сотню случайных людей относительно их знаний и убедиться, что 95% людей никогда в жизни не посещали ни одного симфонического концерта, а все их знания классики крутятся вокруг «Турецкого марша» и пару десятков подобных популярных классических мелодий, которые стали фактически попсой.

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

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

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

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

Люди записываются на курсы тысячами, но очень быстро остывают. Подавляющее большинство не выдерживают и месяца. Быстро выясняется, что для решения более или менее серьезных задач надо много чего знать (сюрприз!). При этом в рекламе курсов будут рассказывать, что всё проще некуда – пара строчек кода и ты специалист в машинном обучении. А по завершении ты сразу начнешь получать 200 000 руб., за тобой работодатели будут еще и бегать.

Ты, главное заплати 100 000 руб. за доступ к курсам и всё. Нет денег – ничего страшного, можно тут же оформить кредит. Всего-то 7 000 руб. в месяц, что отобьется за 2 дня работы.

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

И всё время повторяется один и то же шаблон. Да, можно быстро обучиться программированию для решения простых задач и делать всё по шаблону, типа загрузки данных или построения диаграммы, но это можно сделать и без всякого программирования раз в 5-6 быстрее. Вопрос – зачем учиться? При использовании Python можно погрузиться глубже и взяться за сложные задачи, но тогда про «быстро обучиться» надо забыть. Придется пускаться во все тяжкие.

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

Теперь вернемся к low-code и объяснению того, почему именно он станет самой массовой технологией будущего.

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

Т.е. вопрос стоит не таким образом «анализировать ли данные или нет?», вопрос – «как это делать?». Важно то, что это запрос массовый, касающийся практически всех компаний. Только в России нужны миллионы специалистов, аналогичная ситуация по всему миру. Рынок огромный, конечно, при условии, что удастся снизить порог входа на него.

Теперь необходимо понять несколько психологических моментов, оказывающих влияние на принятие решений людьми:

  1. Люди ленивые. Если будет несколько вариантов решения проблемы, то подавляющее большинство людей в первую очередь будут рассматривать самый простой вариант. Более сложные альтернативы они готовы рассматривать только в случае, если простой способ совершенно не устраивает. Более того, пользователи не гонятся за идеальными решениями. Если простой вариант решения более или менее закрывает проблему хотя бы наполовину, этого достаточно для того, чтобы пользователь остановил свой выбор на нем.
  2. У людей катастрофически нет свободного времени. Даже если пользователь не ленится и хочет приложить усилия, у него всегда будет проблема с выделением времени. Дело в том, что анализ данных не является смыслом жизни людей. У них есть сотни других проблем, которые претендуют на его свободное время. Может стоит больше времени уделить воспитанию детей, занятию спортом, здоровью, общению с друзьями, культуре, хобби и еще тысяче других дел? Большинство из нас хотели бы свободно говорить на английском. Это реально полезная штука, дающая много преимуществ, и как успехи? Продавцы курсов по обучению английскому говорят, то нужно всего-то выделять по часу в день в течение полугода. Многим ли удается выделить этому достаточно времени? А главное, многие ли свободно заговорили на английском после оплаты курсов?
  3. Люди нетерпеливы. Если какой-то результат нельзя получить достаточно быстро, у людей резко падает мотивация. Вариант, при котором можно получить хороший результаты, но через год – плохой. Приложить усилия на короткое время люди готовы, но долго ждать – нет. Именно поэтому через 1, максимум 2 месяца после начала изучения языка программирования, когда люди изучат простые вещи, 90% обучающихся прекращают занятия. Для того чтобы не отказаться и продолжать заниматься нужна очень сильная мотивация.

А теперь, для того, чтобы было более осознанное понимание того, как всё, описанное выше, влияет на развитие технологий, я приведу пример отрасли, где за последние 30 лет произошло несколько революций – это фотография.

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

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

Затем появились цифровые фотоаппараты и история повторилась – «цифра никогда не заменит пленку». Помните какое было разрешение у первых цифровых фотоаппаратов? Напомню – 1-2 мегапиксела – это очень мало. Но качество постепенно улучшалось и на рынке появлялось все больше цифровых камер. И тут выясняется, что никакие фотосалоны не нужны. Вставил SD-карту в компьютер и смотри фотки. Да, вначале качество было не очень, но получение снимков стало еще проще, чем с мыльницами.

Как только качество стало не таким уж отвратительным, началось активное вытеснение предыдущего массового товара – пленочных фотоаппаратов-мыльниц на цифровые камеры. Эта технология могла бы стать самой массовой, но не успела, т.к. подоспела очередная волна инноваций – фотоаппараты в телефонах.

И снова всё началось сначала – «как можно получить хорошую фотографию с такой оптикой – телефоны никогда не заменят нормальные цифровые камеры». Опять вначале качество фото на телефонах было ужасное, но оно постепенно улучшалось и когда достигло более или менее приемлемого уровня, выдавило технологию предыдущего поколения потому, что была еще удобнее. Выяснилось, что фотоаппарат всегда с тобой в кармане и даже SD-карта не нужна, всё автоматом улетает в облако. Сегодня 95% всех фотографий делаются на телефоны и сделать их может любой человек в любой момент.

Продажи фотоаппаратов всех мастей становятся незаметны на фоне продаж смартфонов. Источник

Этот пример я привел для того, чтобы все понимали, как технологии развиваются, какие проходят стадии и как продукты/услуги становятся массовыми:

  1. Новая технология вначале может выдавать менее качественные результаты, чем старая, но у неё всегда есть одно важное преимущество – она удобнее и/или дешевле. Новая технология делает продукт или услугу доступнее потому, что уменьшает сложность процесса или сильно снижает цену.
  2. Благодаря простоте и удобству, новой технологией начинают пользоваться всё больше людей, которые готовы вначале смириться с тем, что качество посредственное.
  3. Новая технология не стоит на месте, она становится всё лучше и постепенно доходит до такого состояния, что способна удовлетворить основные потребности клиентов. Это точка невозврата. В конце концов, она догоняет и перегоняет старую технологию.
  4. Старая технология не исчезает, она становится нишевой, отдавая почти весь рынок новой технологии.

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

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

Теперь проведу аналогию с анализом данных и low-code подходом:

  1. Кодирование на любом языке – это сложно для большинства людей. Поэтому до сих пор основной инструмент аналитиков – Excel. Никакой Python никогда его не столкнет с вершины. Да, люди будут прибегать к программированию и сейчас, но только если не будет никакой альтернативы. Массовому рынку нужно что-то более простое.
  2. Low-code намного проще в использовании. Достаточно показать как связываются несколько кубиков и уже можно решать задачи. Он сильно снижает планку и как следствие расширяет рынок потребителей в десятки и сотни раз. Даже если вначале это будут не самые сложные задачи – ничего страшного. Возможность получать результат после просмотра 5-ти минутного ролика – это убийственный аргумент.
  3. В данный момент low-code технология относительно молодая и какие-то вещи не способна сделать. Но это временное явление. Учтите, что тот же Python развивался 30 лет, прежде чем стал таким, как сейчас. Отсутствие чего-то важного в новой технологии – это просто детские болезни. Главное, что low-code проще, остальное со временем появится.
  4. Как только low-code будет более или менее нормально решать самые частые задачи произойдет резкое изменение ситуации и увеличение спроса. Ему для успеха даже не обязательно решать задачи на отлично, достаточно, чтобы они были решены на минимально удовлетворительном уровне. Массовый пользователь будет счастлив, т.к. он наконец-то сможет автоматизировать решение рутинных задач.
  5. Рынок не будет развиваться в сторону того, что все решат преодолевать трудности и перейдут на Python. Еще ни одна технология так не добивалась успеха. Поэтому ни одна сложная в применении технология не обходила по популярности простую. Всё будет развиваться с точностью до наоборот. Low-code постепенно будет наращивать возможности, пока не закроет основные задачи, а затем все чаще будет покрывать сложные задачи, отъедая рынок у Python. Кодирование останется, но для редких или очень сложных задач, которые нет резона реализовывать в low-code платформе.

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

Кстати, причина популярности Python по сравнению с другими языками программирования точно та же, что описана выше – он проще, а самая популярная среда для написания кода – Jupyter Notebook, который можно вообще не устанавливать, а открыть в браузере. Все потому, что самый простой язык и простая среда обязательно перетянут на свою сторону максимум сторонников. Но важно понимать, что Python простой не вообще, а в сравнении с другими языками программирования. Логическая ошибка заключается в том, что не принимается во внимание наличие альтернативных способов анализировать.

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

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

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

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

Представление о том, что low-code – это не прорывная технология, что она не способна совершить революцию возникает из-за нескольких когнитивных искажений:

  1. Слишком больший информационный шум вокруг Python, машинного обучения и прочего создает ощущение, что в будущем будет только он. Большое количество курсов говорит только о том, что пока есть хайп многие хотят заработать на продаже обучения, а не о том, что скоро все вокруг будут разработчиками. Поинтересуйтесь сколько из тех, кто заплатил за обучение дошел до конца и сколько их них решает реально сложные задачи, для которых, собственно, есть резон использовать язык программирования.
  2. Отставание в функционале от языков программирования текущей реализации low-code систем создает ощущение, что так будет всегда. При этом простота low-code – не считается важным свойством, а вот отсутствие реализации какого-то алгоритма воспринимается, как очень важный недостаток. Но это временное явление. Low-code системы по мере развития смогут решать всё более сложные задачи, а вот язык программирования как был сложен для большинства людей, так и останется.

Я не хочу сказать, что языки программирования исчезнут и всё можно будет закрыть при помощи low-code. Это не так. Всегда будут сложные и уникальные задачи, которые придется решать соответствующим инструментом. Ведь, хотя у каждого сейчас в кармане приличный фотоаппарат, встроенный в телефон, фотографы все равно остались.

Я хочу сказать, что область применения low-code продуктов будет расширяться и в первую очередь за счет привлечения к анализу данных тех, кто ранее использовал только Excel. Со временем эта технология станет доминирующей и под неё перестроится весь рынок.

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

Для подтверждения мысли о потенциале low-code приведу прогноз Gartner. Согласно ему в 2024 года 66% всего корпоративного софта будет разрабатываться с использованием low-code инструментов. В области аналитики произойдет тоже самое. 66% — это много, очень много. На самом деле данная цифра означает, что всё, что только можно реализовать при помощи low-code будет реализовано именно на нем.

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

Пример сценария обработки данных, реализованного в Loginom

Надо понимать, что детские болезни говорят не только о том, что технология еще не полностью удовлетворяет потребностям клиентов и то, что она находится на стадии роста. Это идеальное время для выхода на рынок. Именно поэтому low-code самое популярное слово у стартапов. Со временем, когда многие проблемы будут решены, уйдут не только детские болезни, но и рост. Того, кто к этому времени сможет стать лидером будет практически нереально подвинуть. Рынок будет занят. Придется придумывать новую технологию и опять проходить все стадии.

Вопрос не в том, какой подход победит и станет массовым – low-code или кодирование. Более простая в использовании технология всегда будет более массовой и точка. Вопрос в другом: какую low-code платформу станут использовать большинство людей.

И в заключение. Многие люди путают такие понятия, как изобретения и инновации. Изобретение – это создание чего-то нового, например, технологии, алгоритма, материала. А инновации – это внедрение изобретения в жизнь. Почему-то многие считают, что изобретение – это круто, а инновации – так… ерунда. Они видимо не осознают, что на слуху только те изобретения, которые стали инновациями.

Тот, что изобрел фотоматрицу, используемую в смартфонах – сделал интересную штуку, но революцию совершил не он, а Apple с iPhone и Google с Andriod. Они «всего лишь» сделали эту технологию массовой, а заодно создали целые отрасли экономики и изменили стиль жизни всего человечества. Интересно, много ли людей могут сказать, что до неузнаваемости изменили образ жизни миллиардов людей?

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

Связанные посты
121 комментарий 👇
Миша Гусаров, Инженегр-погромист 7 октября в 08:17

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

  Развернуть 1 комментарий

@dottedmag, Ага... Сейчас... Если что-то будет работать, то никто туда не полезет.

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

  Развернуть 1 комментарий

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

  Развернуть 1 комментарий

@loginom, просто вам придется платить x2/x3 и все.

  Развернуть 1 комментарий

@loginom, Когда будет работать — никто не полезет. А когда будет — придётся контрактовать того, что сможет разобраться.

Поскольку никто не захочет возиться с чужим кодом, то придётся переплачивать (и x3 здесь только нижняя граница).

  Развернуть 1 комментарий

@dottedmag, почему это переплачивать? Есть альтернатива - слабать на коленке новое, которое будет работать еще лет 10.

  Развернуть 1 комментарий

@loginom,

Попробуйте программиста заставить провести рефакторинг уже существующего кода. Он наверняка уволится.

Кому как. Для меня наоборот, когда надо рефакторинг, то это интересно. Потому что рефакторинг - суть построение архитектуры с учётом опыта.

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

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

Кстати, я уже говорил, что люблю рефакторить?

  Развернуть 1 комментарий

@dmitvitalii, +1
Удержать себя от рефакторинга порой крайне сложно.

  Развернуть 1 комментарий

@loginom, наоборот. Нормальный программист с радостью возьмётся за рефакторинг, потому что "какие-то мудаки понаписали, я сейчас покажу как нормально делать надо".
Рефакторинг, это

  • отсутствие чётких сроков и трудозатрат
  • бесконечная возможность чесать ЧСВ
  • тупо интересно, особенно если писали всё-таки не макаки.
  Развернуть 1 комментарий

@annmuor, Это все-таки не рефакторинг, а скорее желание выбросить и переписать все заново. Само собой, т.к. все кто писали до этого криворукие идиоты. :)

  Развернуть 1 комментарий

Разбудите меня через 100 лет и спросите, что происходит с low-code:

  • Вендоры затаскивают рекламу под видом аналитики
  • В красном уголке висит квадрат Gartner
  • В тематических сообществах стрекочут цикады
  • Визарды, где можно связывать блоки, вот-вот захватят мир
  Развернуть 1 комментарий

@antgnc, Разбудите меня через 100 лет и спросите, что с языками программирования и услышите, что новый язык проще, чем всё, что было ранее и что его может изучить любой человек за месяц.

Я это слышу уже лет 30. Так было с Фортран, Алгол, Паскаль, С, C++, C#, Java, Python. И каждый раз одно и то же. Казалось бы, каждый раз упрощали дальше некуда и каждый раз надо был придумывать новый язык, т.к. предыдущий, оказывается сложный (сюрприз!). Прочитайте. что писали про каждый из этих языков вначале.

Я постарался привести самый главный аргумент, что программирование - это сложно для подавляющего большинства людей - это средняя зарплата программистов. Если этим сможет заниматься каждый или на погружение требуется 1 месяц такая ситуация НИКОГДА бы не сложилась. Свободный рынок труда это исключает.

  Развернуть 1 комментарий

@loginom, ну вроде бы со всеми новыми языками, появившимися за последние лет 20, простота для не-разработчика никогда и не декларировалась как основное преимущество? И я бы не назвал языки из вашего списка упрощениями предыдущего (кроме, наверное, разделения C/non-C).

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

  Развернуть 1 комментарий

@nightlord189, Конечно не говорилось о простоте для НЕразработчика. Это же язык программирования, следовательно он предназначен для программистов.

Я хотел сказать о том, что упрощение (почти) всегда было основным драйвером появления нового языка.

Для примера, я ввел в Google запрос: "основные достоинства python". И что мы видим? "Во-первых, это понятный и простой язык программирования."

Ладно, поищу что говорят про другие языки, например "основные достоинства java". И что мы видим? "Язык Java прост для изучения".

Какой еще есть популярный язык? Давай поищем по фразе "основные достоинства JavaScript". Угадайте что мы увидим? А вот что: "несложность синтаксиса и рациональность, интуитивная понятность кода".

Интересно, есть ли не простые языки программирования?

  Развернуть 1 комментарий

@loginom, ну к слову я вижу относительно большое количество не-программистов которые успешно вертят данные питонов в юпитер ноутбуках.

  Развернуть 1 комментарий

@TiraelSedai, Естественно. Обязательно найдутся люди, которые начнут решать свои задачи кодированием. Собственно, так было всегда. Раньше они писали в Excel на VBA. Но таких всегда мало по сравнению с теми, кто предпочтут более простой инструмент.

Я говорил о том, куда будет двигаться основная масса потребителей. Посетите любую компанию вы увидите, что почти все, кто работает за компьютером активно применяют для анализа Excel. Они реально что-то считают, строят диаграммы. Это и есть массовый рынок. А сколько из них "вертят данные питонов"? В лучшем случае один из 50, а скорее один из 100.

Я, конечно, не говорю о чисто IT фирмах. Там большинство основных сотрудников пишут на каких-то языках, т.к. это и есть суть их работы.

  Развернуть 1 комментарий

@loginom, ну да, они все просты в изучении. И что?
Куча языков есть, где на простоту никто не смотрит. Rust, matlab, haskell, ocaml

  Развернуть 1 комментарий

@aovlllo, Это так, но только массовые продукты оказывают такое влияние, что перекраивают рынок. Всегда будут уникальные разработки, но они не являются определяющими. Это, если угодно, полигон для новых технологий.

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

  Развернуть 1 комментарий
Anatoly Shipitsin, Специалист по НЕХ 7 октября в 07:26

Ох. Сколько раз это уже рассказывалось за долгую историю программирования я уж не припомню. Но давайте напомню пару вещей

  • SQL был придуман как средство доставать данные без участия программистов самими пользователям. И где он сейчас? Ах да в требованиях у программистов и более того многие говорят он сложный и не понятный! Толи дело python!
  • UML и все прочее тоже в тот же тренд вело. Давайте накидаем кубиков, а потом сгенерим код!
  • Системы отчетности разного вида поверх SQL

Все в итоге приходит к тому что low-code или другая автоматизация в том или ином виде покрывает часть потребностей, но далеко не 100%. Как только у нас появляется специфическая хотелка, то все он не может у него лапки. Почему? Да просто очередную систему автоматизации писали люди и у них есть ограничения.

Так что по мне рынок low-code сильно перегрет и у нас просто есть недостаток гибкости автоматизированных систем. Более того он же порождает новых программистов.

Появилась tilda и тут же появились tilda программисты. Лень людей неистребима. Более того даже нейросети и ИИ не поможет как и наличие copilot того же

  Развернуть 1 комментарий

@norguhtar, И что тут опровергает идею? :) Каждая их таких вещей снижала планку и пользователей становилось больше. Никакая технология вообще не покрывает всех потребностей.

Развитие идет таким образом, что появляются инструменты, покрывающие типовые потребности и больше для таких вещей не используют кодирование. У компаний сейчас очень много задач, которые надо автоматизировать, например, просто собрать информацию из разных источников или рассчитать какие-то KPI. Это типовые кейсы применения low-code. Таких задач в любой компании тысячи. Кстати, именно или и завалены в основном IT департаменты.

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

  Развернуть 1 комментарий

@loginom, то что это никоим образом не подъедает разработку. Ее становится больше. Не происходит пользователи сами начали писать программу. Происходит пользователи организуют еще одно рабочее место и нанимают человека это делать.

  Развернуть 1 комментарий

@norguhtar, Программистов не хватает сейчас и не будет хватать никогда. Это факт который каждый подтверждается наблюдениями последние 30 лет. Не нравится low-code - нет вопросов, предложите другой способ обойтись без программистов или минимизировать их участие.

  Развернуть 1 комментарий

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

  Развернуть 1 комментарий

@norguhtar, да не, не переоценён. Просто у нас люди любят одним молотком и саморезы вкрутить и гвозди забить. Всё должно быть под ЦА, а не для всеобщего блага разом.

  Развернуть 1 комментарий

@yaroslav_miroshnikov, я привел пример с SQL. Это прям ярчайший пример такого low-code. А сейчас это просто инструмент программистов.

  Развернуть 1 комментарий

@norguhtar, Кстати, SQL - это классная штука. Программисты потому его и используют, что он проще. Т.е. идея как раз взлетела.

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

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

Но нет... Программист будет доказывать, что надо только кодировать. Есть же тысячи задач, которые требуют реально кодирования. Вот на них и надо тратить силы.

  Развернуть 1 комментарий

@loginom, как бы только вот внезапно SQL это вполне себе декларативный язык. Который в том числе отлично встраивается в другие среды. А вот весь low-code который я видел так не делает и чаще всего предлагает пользователю таскать квадратики и ставить стрелочки. Замыкая все на свою среду.

  Развернуть 1 комментарий

@norguhtar, да любой low-code или другой сервис, который якобы избавляет от программистов, не избавляет по факту нифига, а плодит низкокачественных специалистов заточенных на конкретные сервисы/технологии. Все эти low-code/nocode больше похожи на маркетинг и историю для продажи бизнесу, мол смотрите, вам не придется платить программистам 300кксек, можно сделать самому или попросить секретаршу

  Развернуть 1 комментарий

@ApoloSeR, все так :)

  Развернуть 1 комментарий

@norguhtar, Если не low-code, то тогда основным инструментом будет Excel. У компаний нет ни возможности, ни желания платить 300к программисту. Если только вы не Сбербанк.

Собственно, в этом убедиться легко. Ткните пальцев в любую компанию и просите, что они используют в качестве основного инструмента для анализу. 99% - это будет Excel.

А поводу низкокачественных программистов - это вы прям точно про питонистов. :) Я просмотрел сотни тестовых заданий аналитиков, сделанных на Python - это сущий ад.

По другому быть и не может. Если разработчиков будет в 5 раз больше, то их уровень будет в 10 раз ниже. С этим придется смириться.

  Развернуть 1 комментарий

@loginom, Excel между тем отличный инструмент и много чего позволяет делать. Более того мне не очень понятно что low-code ваше предлагаемое может делать лучше :)

  Развернуть 1 комментарий

@norguhtar, Excel действительно хорош, иначе им бы не пользовалось столько людей. У него есть 3 проблемы:

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

Приведу примеры того, что никак не сделать на Excel:

  1. Скоринговая система
  2. Очистка и разбор адресов
  3. Системы принятия решений для выдачи кредитов
  4. Process Mining

И еще вагон всего.

Тем, кто считает, что low-code - это ерунда надо посетить Loginom Day - https://day.loginom.ru/. Там клиенты будет рассказывать как решали задачи и запускали все это в прод.

  Развернуть 1 комментарий

@loginom, обрабатывает. Подключите базу access :) Сложную логику можно, но это будет VisualBasic и low code это назвать сложно. :) Все описанное вами делается не на low-code.

  Развернуть 1 комментарий

@norguhtar, low-code это просто один из способов решить задачу. Конечно же можно сделать и без него.

  Развернуть 1 комментарий

@loginom, проблема всех low-code систем они решают одну максимум две задачи и замкнуты на свои экосистемы. Интегрировать их с чем-то часто не тривиальная задача. Кто научитесь внятно интегрировать так и приходите.

Просто напомню что весь хайп NoSQL баз сдулся довольно быстро, как раз когда к людям кто их тащил начали приходить и просить аналитику и тут-то оказалось что в отличии от SQL приходится писать код.

  Развернуть 1 комментарий

@norguhtar, Интеграция бывает непростой, но это вопрос решаемый, варианты есть:

  1. Получить какие-то готовые интеграции от разработчика.
  2. Отдать это на откуп программисту, пусть один раз что-то напишет на Python, JavaScript или еще чем-то, а потом обернет в компонент.
  3. Интеграция с веб-сервисами обычно довольно проста, а это покрывает много кейсов.
  4. Сделать свой сценарий и обернуть в кубик, чтобы было проще повторно использовать.

Вот тут https://loginom.ru/blog/telegram-bot пример интеграции в чат-ботом. Никаких языков программирования не потребовалось.

Вот тут https://marketplace.loginom.ru/integrations интеграции с кучей сервисов. Все интеграции тоже превращены в повторно используемые кубики.

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

  Развернуть 1 комментарий

@loginom, Мда. Давайте внимательно посмотрим на SQL. Там есть интеграция в SQL каких-то кубиков? Нет. Еще раз low-code должен быт интегрируем во внешние системы и не замыкаться на свою среду. Если делать наоборот то толку довольно мало получается :) Вот ваш low-code что-то умеет делать. Например клининг данных. Как мне вклеить его к себе в проект? SQL взлетел в том числе за счет хорошего вклеивания в проекты.

  Развернуть 1 комментарий

@norguhtar, В low-code конечно есть интеграция. Это вообще не обсуждается.

Для понимания. Если речь идет про Loginom, то в нашей low-code платформе нет механизма ввода данных ВООБЩЕ. Т.е. мы обязаны хорошо интегрироваться. Данные откуда-то тянутся и куда-то выгружаются: БД, файлы, Excel (куда же без него), ODBC источники, веб-сервисы, 1С и прочее в этом же духе.

На этом и строятся всякие ETL-проекты.

  Развернуть 1 комментарий

@loginom, Еще раз любой low-code который замыкает сам на себя и берет данные сам из источников обречен, на узость применения. С тем же успехом вместо вашей системы я могу использовать crystal report :)

  Развернуть 1 комментарий

@norguhtar, Интересно, почему обречен? Куча продуктов загружают данные к себе, что-то с ними делают и затем показывают на экране или куда-то выгружают. Что тут не так?

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

У low-code есть проблемы, но по опыту могу сказать, что интеграция - это точно не проблема. Чаще всего её можно решить не выходя за рамки того, что позволяет платформа, иногда приходится вставлять код, но это не стоп-фактор.

  Развернуть 1 комментарий

@loginom, Он не решает глобальную проблему и не жрет никак разработку скорее наоборот. Замах на рубль а удар на пятак. Как продукт автоматизации да, но не более.

  Развернуть 1 комментарий

@norguhtar, Кстати, по поводу "новых программистов" Некоторые считают, что эти самые новые программисты - это такие же как старые. Мол, все равно их учить тому же.

Это не так. Уровень этих программистов ниже, намного ниже, чем тех, кто был лет 20 назад. Для того, чтобы писать действительно качественный и быстрый код надо понимать как работает компьютер на глубоком уровне. Интересно сколько процентов новых программистов, пишущих на Python знают ассемблер? Т.е. на самом деле понимают, что происходит внутри. Думаю, что 1-2%, и даже меньше.

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

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

  Развернуть 1 комментарий

@loginom, это работает только для простых задач. Как только задача становится хоть как-то сложнее то происходит ой. И да кстати говоря из-за этого же low-code не решает проблему. Все довольно просто, они точно так же в определенный момент начинают жрать ресурсы. Именно из-за того что люди не понимают как это работает :)

  Развернуть 1 комментарий

@norguhtar,

SQL был придуман как средство доставать данные без участия программистов самими пользователям. И где он сейчас?

Используется по назначению людьми, которые не умеют программировать. Да, я про аналитиков.

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

Так что, по моему мнению, SQL - это пямо образцовый пример low-code, его можно сразу в палату мер и весов тащить.

  Развернуть 1 комментарий

@Kroid, не понял момент про машиночитаемость. Да и ОРМы чёт непонятно при чем тут.

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

  Развернуть 1 комментарий

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

  Развернуть 1 комментарий

@skapral, ну вот представь, у тебя код приложения написан, к примеру, на ruby (или java, или любой другой ЯП). И в этом проекте есть много кусков, которые написаны, например, на python. Удобно ли это будет? Нет, потому что обычный программист не сможет нормально сгенерировать скрипт на python из под java (нет, ну сможет конечно, но явно какие-то более-менее простые случаи).

А теперь представь, что в проекте на ruby есть "код" на json или там yml, или html. Удобно ли манипулировать джейсоном из руби? Конечно да, никаких проблем.

Вот с SQL такая же история. Ты не можешь его распарсить. Ты не можешь сгенерировать из своего кода SQL-запрос произвольной сложности (нет, ну можешь конечно, но тебя за это ненавидеть будут буквально все). Вместо этого, в тяжелых случаях, по соседству будут куски кода на разных языках - один кусок на sql, другой кусок на каком-нибудь ruby.

  Развернуть 1 комментарий

@Kroid, LINQ в C# смотрит на вас с осуждением :)

  Развернуть 1 комментарий

@Kroid, GraalVM смотрит на вас с недоумением. Лично писал проект на джаве смешанной с джаваскриптом. Никаких проблем.
ОРМ пишут не потому, что SQL распарсить нельзя. А потому, что реляционная модель данных плохо мапится на объекты. Много конверторов писать приходится.

  Развернуть 1 комментарий

@Siarhei-r, не знаком с GraalVM. Это что-то вроде компилятора с разных языков в один байт код?

ОРМ пишут не потому, что SQL распарсить нельзя. А потому, что реляционная модель данных плохо мапится на объекты.

И не особо это в итоге и помогает, только в простейших случаях.

  Развернуть 1 комментарий

мне почему-то очень кажется что пост абсолютно рекламный. да и ответы автора в комментах тоже.

я против такого контента в общем.

  Развернуть 1 комментарий

@return_none, меня что-то очень зацепил этот комментарий, наверное потому, что я не люблю рекламу, с детства за адблок и всё такое, поэтому я решил написать простыню.

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

Может быть, это особо мерзкая реклама? Ставки на спорт, Raid Shadow Legends? Джинса, то есть ты не понимаешь что человеку это выгодно и думаешь что он от всей души, а на самом деле получает деньги? Да вроде бы тоже нет, вполне очевидно почему человек топит за low-code, он этим долгое время занимается.

Да, у человека чёткая позиция по этому вопросу, и она в основном противоречит большинству из клуба. Это, кстати, ещё одна причина почему если бы это была чистая реклама, она была бы довольно глупой: тут как бы анти-таргетинг целевой аудитории, "продавать" low-code толпе программистов?

Я считаю, что тут вполне нормальный пост с обсуждением, эдакий баттл с большим количеством серых зон. И не думаю, что Клуб бы выиграл от того, что в нём не было бы такого поста.

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

  Развернуть 1 комментарий

@TiraelSedai, хороший комментарий, но я не о том говорил.

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

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

  Развернуть 1 комментарий

@return_none, одно дело рекламный пост, а другое - пост с рекламой. Первое - плохо, второе - нормально.

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

  Развернуть 1 комментарий

Расскажу про low-code в своей области: Sitecore Experience Platform.
(Необходимое уточнение для дальнейшего понимания: если сильно упрощать, то Sitecore - это WordPress на стероидах.)

В Sitecore уже БОЛЕЕ 10 лет существует low-code подход для изменения поведения сайта под конкретного пользователя. Это называется Engagement Plans. Такой подход позволяет показывать пользователю определенную информацию на сайте, отправлять email, записывать/получать данные в CRM и т.д. в зависимости от его действий.

Все строится мышкой из предопределенных блоков(которые можно расширять).

Казалось бы - вот он low-code, которым должны пользоваться редакторы сайта. Но нет, почему-то этот подход не набирает популярности и им пользуются менее 10%(субъективная оценка, у меня нет реальных данных) сайтов на Sitecore. И в большинстве случаев автоматизацию на основе low-code строят сюрприз-сюрприз: разработчики.

Но почему???

  1. Чтобы разобраться и научиться какой-либо low-code системе тоже надо время. И это не просто, тоже требуется время и усилия. А ценность таких знаний в сравнении с знанием языка программирования намного ниже. И редакторы сайтов даже не хотят вникать. Зачем учить low-code, связанный с Sitecore, если завтра они будут работать на Adobe, Boxever (любой другой системе), где будет свой, совсем другой low-code.

  2. Всегда в low-code системе не хватает каких-то блочков. Или они есть, но работают не совсем так, как хотелось бы. Например есть синхронизация с Salesforce, а с другой CRM нет. Или не совпадает версия. И для написания блочков требуется программист.

Поэтому из моего опыта: low-code в современном виде - это всего-лишь штука для упрощения жизни разработчиков. Как будет дальше - посмотрим, но я отношусь скептически. Если за предыдущие десятки лет, которые low-code, no-code уже существует(но так не назывались, вспомним, например Delphi), то почему они должны поглотить мир разработки в ближайшее время?

  Развернуть 1 комментарий
Захар Кириллов, Амбассадор ЕРАМ в Клубе 10 октября в 11:31

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

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

Только вот путь будет весьма тернист и далеко не всем удасться его преодолеть:

  • бизнесы боятся вендор-лока, потому выбирают проверенный Эксель, а там где его возможностей недостаточно — напрограммировать свой велосипед;
  • бизнесы не хотят отдавать свои данные кому попало — одно дело загружать их в облако Ажура / Гугла / Амазона и совсем другое — доверить клиентские данные неизвестной компании, которая хз как будет с ними обращаться (продавать на сторону, утечка из-за внутреннего плохиша или взлома);
  • бизнесы очень прагматичные, потому они избегают вкладываться в изучение своими сотрудниками специализированных инструментов, лучше потратят деньги на курсы по Экселю или Питону.

Сегодня этих трёх факторов достаточно, чтобы не рассматривать лоу-код платформы от новых вендоров, когда проверенные вендоры бегут в сторону лоу-код семимильными шагами (взять хоты бы MS с его PowerPlarform — Power BI + PowerApps + Power Automate, а ещё есть Azure Logic Apps, Azure Cognitive Services). Туда же идут и ServiceNow, и Salesforce, SAP — которые есть в каждой третьей большой компании.

  Развернуть 1 комментарий

@zahhar, Это проблема любого нового вендора, желающего создать массовый продукт. Все слышат примерно одно и то же:

  1. То, что вы делаете никому не нужно, все так или иначе можно сделать уже имеющимися средствами
  2. Ну ладно, идея не совсем бестолковая, то вы не сможете продать, не сможете убедить клиентов сделать на вас ставку
  3. Ну ладно, вы что-то продали, но вас все равно сожрут большие компании

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

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

К счастью, есть достаточно сумасшедшие и упертые компании, готовые рискнуть, даже когда всё против них. Думаю, что оно того стоит, как бы это не было трудно. Будет что вспомнить на старости лет. :)

  Развернуть 1 комментарий

@loginom, совершенно очевидно, что в России есть место для примерно десятка своих лоу-код платформ, чтобы не использовать буржуйские. Я рассуждал не приминительно к вашей компании, а скорее про американский/европейский энтерпрайз-рынок.

  Развернуть 1 комментарий

@loginom, я думаю, тут речь про размах. На свою Теслу с домиком в Италии создатели инди-лоукод-платформ точно заработают, никаких сомнений. С другой стороны, на Теслу с домиком в Италии можно заработать и создав веб-студию, несмотря на то, что Wix и прочие аналоги Front Page сожрали кучу рынка. А вот что-то дисраптить уже поздновато – монополии уже в курсе всей этой темы.

  Развернуть 1 комментарий

Лично мне главной проблемой low-code или no-code является невозможность (или несоизмеримо большая сложность по сравнению с обычным кодом) тестирования и человеческого версионирования.

  Развернуть 1 комментарий

@TiraelSedai, Да есть такая проблема. Она со временем будет решена. Мне кажется, что это как раз относительно просто. Вот то, что действительно сложно - это получить diff, т.е. сравнивать разные версии. Тут придется головы поломать.

  Развернуть 1 комментарий

@TiraelSedai, в итоге опять появится еще один язык программирования гагага

  Развернуть 1 комментарий

@norguhtar, Ну, тогда все подряд называйте языком программирования. :)

  Развернуть 1 комментарий

@loginom, как только у вас появляется что-то где мы пишем инструкции это становится языком программирования :))

  Развернуть 1 комментарий

@norguhtar, ну да, мы ж образованные люди, Брукса читали. «Автоматическое программирование - это эвфемизм для языка программирования более высокого уровня».

  Развернуть 1 комментарий

@loginom, на самом деле, в иронии @norguhtar есть доля истины.

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

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

  Развернуть 1 комментарий

@skapral, есть вообщем довольная интересная штука node-red. Она как раз про low-code. И там да есть возможность прям налабать новый блок на js

  Развернуть 1 комментарий

@skapral, Не могу понять, почему считается, что программы пишутся на века. Огромное количество программ нужно для закрытия какой-то рутинной задачи. Куча программ, написанных 20 лет назад до сих пор используются и их никто не трогает.

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

Если это можно сделать за один день минут без погружения в изучение синтаксиса, то вы закроете 90% всех текущих задач. Это и есть цель - сбросить с себя рутину.

  Развернуть 1 комментарий

@loginom, я выше не делал никаких предположений о том, на какой срок пишутся системы. Это очень вариативная штука. Выше я лишь озвучил одну закономерность, которую я наблюдаю за всю историю развития языков и средств разработки: вопросы поддерживаемости звучат очень похоже для всех систем, где актуален реюз компонент в каком то виде. Интересный факт - корневые понятия поддерживаемости (cohesion и coupling) впервые появились (в книге structural design Ларри Константина) примерно три года спустя появления и популяризации первых процедурных языков (фортран и алгол), то есть первых языков, где появился реюз хоть чего то. До этого не прослеживается ничего подобного.

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

  Развернуть 1 комментарий

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

  Развернуть 1 комментарий

@dottedmag, вангую что тогда появятся рулы хорошего тона о том, как нельзя именовать блоки (переменные?), а следом и (код-)стайлинг какой нить. И первый шаг в сторону душного кодинга будет пройден. Всё уже было

  Развернуть 1 комментарий

@skapral, И тонны-тонны-тонны новых инструментов (для каждой платформы свои) для управления всей этой ботвой.

  Развернуть 1 комментарий

@dottedmag,
как же это знакомо)
Делали пайплайны для обработки биологических данных:

диаграмки в лучшых традициях No Code
диаграмки в лучшых традициях No Code

в итоге получился язык UWL - Ugene (это тул так называется) Workflow Language:

#@UGENE_WORKFLOW
workflow "Search sequences with profile HMM"{
read-sequence {
type:read-sequence;
name:"Read sequence";
merge-gap:10;
mode:0;
}
hmm2-read-profile {
type:hmm2-read-profile;
....

  Развернуть 1 комментарий

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

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

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

Но при этом я могу буквально за вечер написать нейросеть, которая будет распознавать, к примеру, есть ли машина на фотографии. Потому что сложная часть - сами нейросети, все эти алгоритмы - уже написана, от "программиста" по факту нужно лишь конфигурацию структуры этой сетки указать и предоставить набор данных для обучения. Для этого совершенно не нужно годами изучать статистику и программирование. Сверстать поверх неё ui - и будет типичный low-code.

И так во всём. Просто где-то есть хайп и целая толпа народу двигает прогресс в сторону упрощения инструментов, а где-то хайпа нет и прогресс там крайне медленный.

  Развернуть 1 комментарий

@Kroid, а можешь плиз поделиться такими решениями от «программиста»? Где можно самому написать нейронку настроив готовые элементы и дав материалы для обучения.

  Развернуть 1 комментарий

@Mkrukov, Да тот же TensorFlow, например: https://www.tensorflow.org/tutorials/quickstart/beginner

  Развернуть 1 комментарий

@Kroid, Спасибо, я просто нуб в этой теме. Как я понял этой библиотекой можно не только изображения распознавать.

  Развернуть 1 комментарий

@Mkrukov, PyTorch еще проще. Есть целый зоопарк предобученных моделей (torchvision.models)

  Развернуть 1 комментарий
Mikhail Kryukov, Изучаю Java, познаю мир, пишу в блог 7 октября в 16:10

Спасибо за статью, было интересно!

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

Вот за что зацепился глаз после прочтения:

  1. Про образовательные курсы. Люди не становятся программистами с 300 какосеками не из-за того, что курсы плохи, рынок их не возьмет, знания не соответствуют требованиям или везде вокруг наебалово. А по той же причине почему не дочитываются книги, не доигрываются игры, не доучиваются дисциплины, почему у телека с пивком полежать пизже, чем что-то менять в своей жизни. Тупо лень и отсутствие понимания — а нахуя я это изучаю?

Туда же про английский. Конкурентное преимущество — это круто, но абстрактно. А вот работать в Германии через год — это уже цель. Тоже и с кодингом, даже если чисто ради денег. Так что не инфобиз говно (книги тоже не каждая является шедевром, как и преподаватели, как и все вокруг вообще не идеально), не люди ленивы, а задачи ДЛЯ ЧЕГО нет. Как только задача появляется и внешнее давление повышается, то легко изучивается питон, английский и что бы то ни было. Если только нет сознательного решения забить болт и поднять лапки.

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

  2. Я согласен с автором, что упрощенные способы сделать что-либо будут активно внедряться массами. Но не надо забывать, что технологии и образ жизни простых смертных тоже меняется. А значит программисты как кодили, так и будут кодить, только более сложные вещи. Они эволюционируют вместе с остальным миром, новыми технологиями, новыми подходами.

30 лет назад писали только html + css для сайтов и табличная верстка была передовой. Потом появился CSS3 со всякими трансформациями и анимациями, подтянулись браузеры, стали внедрять JS для интерактива и бекенд для бизнес логики. Это и есть эволюция технологий. Если бы технологии так и остановились на html+css, то да, лоу код мог бы сильно ударить по кодерам. Но такого не происходит, все развивается.

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

Например, я орал, когда впервые увидел "конструктор", где css свойства были в виде кнопочек и разницы с кодингом обычным почти нет. Это тупо UI для CSS свойств, которые двигаешь ползунком или выбираешь из списка. Разницы тупо 0, напиши текстом или ползунки двигай. Сложность все равно для разработки такая же. Отсюда плавно переходим к пункту 4.

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

Например, в Unity давно есть визуальный скриптинг и прочие подобные решения. Но это все такой же кодинг, просто для миллениалов, кто хочет не в IDE писать командами, а квадратики двигать и связи создавать. Интуиция подсказывает, что при сложной логике такая визуализация будет напоминать паутину, а с текстовыми командами все же проще обращаться, но это не точно.

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

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

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

Далеко ходить не надо, Вастрик.Клуб на лоу-код фиг сделаешь. Есть прикольные механики, которые внедряет коммьюнити и пишет ручками.

Вывод такой, имхо:
Эволюция ли лоу-код? Да, однозначно и это круто.

Но заменит ли она обычных программистов? Нет, так как мир не стоит на месте и лоу-код всегда в роли догоняющих.

Лоу-код решения стоят на фундаменте, который выработался на передовой обычными программистами: как должно выглядеть окошко, какая логика чата, какая именно crm нужна, какие боты более удобны и т.п. Все это сначала пишут кодеры, а лоу-код только обрамляет готовые рабочие решения в некие паттерны.

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

  Развернуть 1 комментарий

@Mkrukov, Сложные вещи, конечно же будут кодиться. Вот и отлично. Разве кто-то против? Речь идет о том, что есть много задач, которые можно решить проще. Так почему это не сделать более простым способом?

Я в конце статьи постарался объяснить разницу между изобретениями и инновациями. Инновация - это не что-то уникальное, а что-то, что смогло стать массовым.

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

Если рассуждать в терминах где более передовые алгоритмы, то low-code отстает. Но дело в том, что он вообще не про передовые алгоритмы, а про то за сколько кликов можно настроить логику. Low-code не должен догонять по наворотам, он должен опережать в части простоты решения типовых задач.

  Развернуть 1 комментарий

@loginom,

есть много задач, которые можно решить проще. Так почему это не сделать более простым способом?

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

Сложные вещи, конечно же будут кодиться.

Это может быть не обязательно сложная вещь, а просто узкая задача, но которую никто не сделал. Как слепить из известного что-то свое, но под другим углом и вуаля — вот тебе стартап)

Low-code не должен догонять по наворотам, он должен опережать в части простоты решения типовых задач.

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

  Развернуть 1 комментарий

@Mkrukov, Работы программисты не лишатся. Это точно!

  Развернуть 1 комментарий

@Mkrukov, про Unity, кстати, еще более реальный пример - Unreal Engine 4-5 с блюпринтами во все поля. Вот это прям нормальный, доведенный до ума low-code, на котором можно относительно простой проект сделать, не трогая код вообще (поработал на нем какое-то время).

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

  Развернуть 1 комментарий

из статьи так и не понял в каком месте low code поедает разработку. в анализе данных? или в фоторграфии?

  Развернуть 1 комментарий

@fonbrot, в управлении дронами :)

  Развернуть 1 комментарий

@fonbrot, в экселе, я так понял

  Развернуть 1 комментарий

Low code решения радикально сократят время создания анимаций в unreal engine.
Low code решения:

  Развернуть 1 комментарий

@OlegShvann, Люди любят показывать такие примеры, как доказательство того, что технология плохая. Мол, на low-code можно сделать вот только такой спагетти-сценарий. Если имеется конструктор, то естественно, можно на нем собрать что-то отвратительное.

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

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

Любой инструмент, допускающий конструирование может порождать что угодно. Это обратная сторона гибкости. Low-code снижает планку входа, но это не значит, что голову надо вообще отключать.

  Развернуть 1 комментарий
Мокеев Егор, веб-разработчик 7 октября в 09:23

Не очень понятно как low-code борется со сложностью.
Либо это простая тулза с небольшим количеством опций, и тогда это к разработке не имеет отношения. Это просто конфигуратор.
Либо это тулза с большим количество опций и тогда это, скажем так, UI для SQL, который сложность никак не уменьшает.
Вот 1C - это про low-code? Мне кажется изначально таким задумывался, но время показало, что весь low-code превращается в винегрет, по сложности не уступающий коду

  Развернуть 1 комментарий

@zetamen, никак.

  Развернуть 1 комментарий

@zetamen, ща запилим крутой удобный инструмент и любая кухарка сможет управлять государством

  Развернуть 1 комментарий
Anton Golovanov, Специализируюсь на ARIS и иже с ним. Переучиваюсь на датасаентиста. 8 октября в 09:51

@loginom, мне кажется вы в начальной статье сами написали ответ, почему low code не искоренит традиционное программирование. Ответ прост - люди ленивы и им лень разбираться. Тех, кто хочет и может в чем-то разобраться было всегда меньше и они всегда ценились. Взять тот же Excel. Вот, положа руку на сердце, много вы видели продвинутых пользователей эксель вне вашей профессиональной среды? Тех, кто вышел за рамки "нарисовать табличку и посчитать автосумму". Я таких видел очень не много. Хотя казалось бы, ну что еще проще. Да многие даже в той же винде дальне необходимых функций, типа запустить рабочий софт/браузер/почту, не ушли. Просто потому что не надо.
То же самое будет и с low code ПО. Ну подвинет оно немного традиционные вещи с простых задач. Но там, где требования станут сложнее и надо будет тот же low code знать глубоко и разбираться, снова потребуются "специальные люди". Так что, появится только еще одно направление и все. Мне так кажется.

  Развернуть 1 комментарий

@Mangol, Конечно люди ленивы. Тут вопрос в другом.

Есть объективная потребность в анализе. Люди вынуждены анализировать не потому, что мечтают об этом а потому, что это необходимо для выживания бизнеса. Бизнес не может от этого отмахнуться или проигнорировать. Была бы возможность ни за что не стали бы непонятный дата сайнс огромные деньги с мутными перспективами отбить затраты.

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

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

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

  Развернуть 1 комментарий

@loginom, вы совершенно правы :) но то, что вы написали, не отменяет того что написал я. Давайте зайдем немного с другой стороны, не с ИТ. Анализ должен выполнять аналитик, т.е. человек, который в принципе понимает как это делать. А вот каким инструментом он для этого будет пользоваться, low code или пресловутым питон+юпитер - это по большому счету вопрос его личных предпочтений.
И вот тут мы как раз и утыкаемся в момент, который есть и при использовании low code и при использовании привычных методов - наличие этого самого аналитика, который вник, разобрался, получил навык и опыт. А в этом месте у нас ничего не изменилось - low code не наплодит бОльшее количество аналитиков. Он лишь создаст иллюзию (возможно) что это легко. Но, как я написал выше, эта иллюзия легко разрушится, как только решаемая задачка станет относительно сложной.

  Развернуть 1 комментарий

Robert C. Martin, The Clean Coder: A Code Of Conduct For Professional Programmers, 2011

UML/MDA

В начале 1990-х годов я очень надеялся, что отрасль автоматизированной разработки ПО кардинально изменит работу программиста. Заглядывая в будущее из этих бурных дней, я думал, что к сегодняшнему дню все уже будут программировать с диаграммами на более высоком уровне абстракции, а текстовый код останется в прошлом.
Как же я ошибался! Мои мечты не только не сбылись, но и любые попытки движения в этом направлении потерпели полный крах. Дело даже не в том, что не существует инструментов и систем, демонстрирующих потенциал такого подхода; просто эти инструменты толком не реализуют эту мечту и ими никто не хочет пользоваться.
Я мечтал, что разработчики избавятся от подробностей текстового кода и начнут строить системы на более высоком диаграммном уровне. В самых дерзких мечтах программисты вообще становились лишними. Архитекторы могли строить целые системы по диаграммам UML. Ядро системы — огромное, бесстрастное и равнодушное к бедам обычных программистов — преобразует диаграммы в исполняемый код. Так выглядела великая мечта модельно-ориентированной архитектуры (MDA, Model Driven Architecture).
К сожалению, у великой мечты имеется один крошечный изъян. MDA предполагает, что проблемы создает код. Однако код сам по себе не создает проблем и никогда не создавал. Проблема заключается в детализации.

Детализация

Программисты управляют подробностями. Да, именно этим мы и занимаемся. Мы описываем поведение системы в мельчайших подробностях. Для этой цели мы используем текстовые языки, потому что они чрезвычайно удобны (для примера возьмите хотя бы английский).
Какими же подробностями мы управляем?
Вы знаете, чем различаются два символа \n и \r? Первый, \n — перевод строки (line feed), а второй, \r — возврат каретки (carriage return). Что такое «каретка»?
В 1960-х и начале 1970-х годов основным устройством вывода для компьютеров был телетайп. Модель ASR33 была самой распространенной.
Устройство состояло из печатающей головки, которая могла печатать до 10 символов в секунду. Печатающая головка состояла из цилиндра, на котором были нанесены рельефные символы. Цилиндр поворачивался так, чтобы к бумаге был обращен правильный символ, после чего молоточек ударял по цилиндру и прижимал его к бумаге. Между цилиндром и бумагой проходила красящая лента, краска с которой переносилась на бумагу в виде символа.
Печатающая головка перемещалась на каретке. С каждым символом каретка сдвигалась на одну позицию вправо, вместе с ней смещалась и печатающая головка. Когда каретка доходила до конца 72-символьной строки, каретку приходилось возвращать в начало строки, отправляя символ возврата каретки (\r = 0x0D); без этого печатающая головка продолжала бы печатать символы в 72 столбце, и от многократной печати там появился бы черный прямоугольник.
Конечно, этого было недостаточно. Возврат каретки не приводил к смещению бумаги к следующей строке. Если бы после возврата каретки не передавался символ перевода строки (\n = 0x0A), то новая строка была бы напечатана поверх старой.
Итак, для телетайпа ASR33 строки должны были завершаться последовательностью «\r\n». Однако и здесь была необходима осторожность, потому что возврат каретки мог занять более 100 миллисекунд. Если ограничиться отправкой «\n\r», то следующий символ мог оказаться напечатанным во время обратного хода каретки, а в середине строки появился бы смазанный символ. Для надежности символы конца строки часто дополнялись одним или двумя символами «забой».
В 1970-е годы, когда телетайпы стали постепенно выходить из употребления, в операционных системах UNIX последовательность конца строки сократилась до \n. Однако другие операционные системы — например DOS — продолжали использовать обозначение \r\n.
Когда вам в последний раз попался текстовый файл, использующий «неправильное» обозначение? Я сталкиваюсь с этой проблемой не реже раза в год. Два идентичных файла с исходным кодом не сравниваются, а их контрольные суммы различаются, потому что в них используются
разные завершители строк. Текстовые редакторы некорректно переносят слова или разделяют строки двойным интервалом, потому что они интерпретируют \r\n как две строки. Некоторые программы понимают \r\n, но не распознают \n\r… И так далее.
Вот что я имею в виду под детализацией. Попробуйте-ка закодировать логику обработки завершителей строк на UML!

Без изменений и надежд

Движение MDA обещало, что использование диаграмм вместо кода позволит исключить из программирования большое количество второстепенных подробностей. До настоящего момента эти обещания не оправдались. Как оказалось, в коде не так уж много лишних подробностей, которые можно было бы исключить при помощи диаграмм. Более того, диаграммы тоже содержат свои второстепенные подробности. Они обладают своей грамматикой, синтаксисом, правилами и ограничениями. В конечном счете различия в уровне детализации оказываются незначительными.
Движение MDA обещало, что работа с диаграммами будет осуществляться на более высоком уровне абстракции, чем работа с кодом — подобно тому, как Java находится на более высоком уровне абстракции по сравнению с ассемблером. Но и эти обещания тоже не оправдались. Различия в уровне абстракции в лучшем случае незначительны.
В завершение представьте, что в один прекрасный день будет изобретен действительно полезный диаграммный язык. Но ведь рисовать диаграммы будут не архитекторы, а программисты. Диаграммы попросту станут новым кодом, и программистам придется «рисовать» этот код — ведь в конечном итоге все сводится к подробностям, а управлять ими приходится именно программистам.

  Развернуть 1 комментарий

Low-code: поедаем разработку с 1950 года.
1950 год: если программисты будут использовать вместо номеров мнемоники машинных команд, они не смогут писать компактный самомодифицирующийся код и использовать команды одновременно как константы. Средний уровень программиста падает всё ниже и ниже, стремительно опускаясь до ужасного!

  Развернуть 1 комментарий

@OlegShvann, О каких подробностях и деталях вообще идет речь? Мы все пользуемся кучей продуктов даже близко не погружаясь в детали и это никого не смущает.

Мы пользуемся интернетом, а многие ли вообще знакомы, например, с моделью OCI? Хоть раз кто-то опускался до понимания особенностей работы протоколов? Так можно пройтись абсолютно по всему.

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

Повышение уровня абстракции приводит к повышению производительности. Пусть и за счет отсутствия понимания деталей. Low-code это просто еще один уровень абстракции.

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

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

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

Надо опуститься на землю и понять простые вещи:

  1. Бизнесу нужно решение задачи здесь и сейчас
  2. То, что это будет плохо поддерживаться или вообще отвалится через 5 лет бизнес интересует крайне редко, т.к. не понятно будет ли жив бизнес лет через 5
  3. Платить много бизнес не хочет, да и не может, нормальный предприниматель будет стремиться сократить расходы
  4. Бизнесу важно, чтобы решение можно было быстро подстроить под постоянно меняющиеся обстоятельства
  5. Большая часть проблем, сжирающих львиную часть прибыли - довольно простые и их надо закрывать в первую очередь

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

  Развернуть 1 комментарий

Пример: Low-code поел Perl bare metal админов.

Ещё в 2016 преподаватель писал Pluggable Authentication Module начинал с #! /usr/bin/perl и рассказывал о важности поддержания ssh в безопасности. Теперь люди применяют Yaml на поднятый не ими облачный кластер.

Стали ли люди меньше знать о внутреннем устройстве демонов Linux? Да.
Пришлось ли переучиваться на новые более высокоуровневые технологии? Да.
Но востребованность кадров, зарплаты, количество занятых в этом людей выросли вместе с рынком.

  Развернуть 1 комментарий

@OlegShvann, Так именно взрывной рост востребованности в разработке вообще и анализе данных в частности проводит к росту популярности low-code. Рынок труда не поспевает за ростом спроса на решение этих задач. Тупо не хватает людей, способных решать задачи за более или менее вменяемые деньги.

  Развернуть 1 комментарий

@loginom, а вы изучали свою пользовательскую аудиторию — кто ваш основной пользователь, настраивающий все эти workflow и описывающие модели данных и правила?

Какой % среди них не-айтишников, а прямо вот бизнесовых людей?

  Развернуть 1 комментарий

@zahhar, Это долгая история и довольно интересная. Есть несколько сильно отличающихся групп с совершенно разными мотивами. Я постараюсь написать про это статью.

  Развернуть 1 комментарий

Low code это прекрасно. Сам пользуюсь squarespace для блога, bothelp для телеграм бота (хотя порывался написать сам). Если буду делать онлайн магазин, то только shopify.
На работе в кровавом тоже есть успешный low-code - Oracle Data integrator.

По сути AWS Lambda тоже в какой-то степени low-code - не надо писать конфиги оркестратора контейнеров и nginx.

Недавно читал АМА с создателем Usergravity - шаблоном для web saas. Так он пишет что такие шаблоны - это "low-code" для разработчиков. (вот тут есть мой список - много платных и успешных шаблонов https://github.com/smirnov-am/awesome-saas-boilerplates)

Короче считаю что за low-code будущее. Найти бы еще нишу не охваченную этим движением, чтобы занять самому

  Развернуть 1 комментарий

😱 Комментарий удален его автором...

  Развернуть 1 комментарий
Dmitry Vozzhaev, Протоукладчик 8 октября в 07:38

А вот ещё, 1993 год, люди ещё верят что можно программировать без программирования:

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

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

  Развернуть 1 комментарий

@dmitryv, Я не говорил про программирование без программирования. Речь идет скорее о проектировании без программирования. Это разные вещи.

Не могу понять, почему считается, что это невозможно, если это вот прямо сейчас работает в куче мест. Например, как сейчас выглядит любой ETL инструмент? Это визуальный workflow.

Посмотрите как выглядит любой ETL инструмент от какой угодно компании: Informatica, Oracle, SAS, да кто угодно. Трудно найти такой ETL инструмент, где не было бы хотя бы элементов low-code. Где-то это выражено в большей степени, где-то в меньшей, но есть везде.

  Развернуть 1 комментарий

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

  Развернуть 1 комментарий

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

  Развернуть 1 комментарий

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

  Развернуть 1 комментарий
Андрей Казакевич, Начинающий пи(пай)тонист 8 октября в 10:29

Пример с фотоиндустрией считаю не совсем корректным.
ИМХО, индустрия не столько изменилась, сколько многократно выросла за счет этих изменений.
Основные потребители фототехники до цифровой революции были проф-фотографы, рекламщики, газетчики, продавцы по каталогам и т.д. и. т.п. Этот рынок не исчез и, подозреваю, что не уменьшился, но там как ранее нужна была проф-техника так и сейчас. Мало кто из тех, кто работает на b-сектор использует телефоны для работы.
Сейчас в индустрии обработки информации дефицит "проф-фотографов". Если low-code сделает то, что сделала цифровизация с фото, то объем рынка вакансий разработчиков в худшем случае не измениться, т.к. в большинстве бизнес не будет делать "фото" на "телефон".

  Развернуть 1 комментарий

@twistby, Вакансий разработчиков не станет меньше в штуках. Просто увеличится доля тех, кто использует low-code. Изменятся пропорции.

Условно, сейчас все мы неожиданно стали фотографами и типовой "фотограф" (или как сказали бы истинные аналитики - "медианный фотограф" :) ) выглядит не как человек с фотокамерой, на груди, а как человек со смартфоном в руках.

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

Для того, чтобы аналитика изменила мир она должна стать ширпотребом. Low-code это движение в эту сторону. Как говорилось в "Формуле любви": "огонь тоже считался божественным, пока Прометей не выкрал его. Теперь мы кипятим на нем воду".

  Развернуть 1 комментарий

@loginom, некоторые вещи никогда не станут ширпотребом, просто потому, что они не несут никакой развлекательной составляющей для потребителей. И, по моему мнению, аналитика из их числа.

  Развернуть 1 комментарий

В аналитике, создании ботов/лендингов/магазинов low-code, наверное, хорош. И, возможно, в будущем он заменит ручное написание кода в каких-то, или даже в большинстве вещей. Возможно, еще ИИ и какое-нибудь голографическое управление руками подключится.

Но разработку это все равно не поест, просто снизится порог входа, возможно, зарплаты для младших и средних разрабов (а для старших - возрастут).

Всю эту лапшу и великолепие все равно надо будет сопровождать и пилить)

  Развернуть 1 комментарий

@nightlord189, программисты же сейчас особо не пишут ничего низкоуровневого. Пользуются готовыми библиотеками или фреймвоками. Никого не парит, что ты не тру-программист, если не разбираешься в управлении памятью.

Огромное количество задач закрывается при помощи скриптов. Какой-нибудь CD/CI чуть ли не полностью состоит из адской смеси скриптов и всё нормально. Это даже считается крутым. Когда я учился, никто и не подумал бы называть людей, который пишут скрипты программистами. Лично у меня таким языком был REXX. Уверен, сейчас мало кто вообще о нем знает.

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

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

  Развернуть 1 комментарий

@nightlord189, кажется, покрыть условные половину типичных крудов low code подходом можно. Если добавить триггеры в духе event sourcing'а, то даже легко кастомизировать. Грубо говоря, в какую-нибудь AlmostDynamoDB заливаешь схему данных, тебе дают в ответ crud апи чтобы дергать + как-то добавляешь обработчики с бизнес логикой. Думаю (пост не читал, сразу пиши) даже сейчас можно что-то такое из лямбд и какого-нибудь клаудстораджа. Звучит слегка крипово, но думаю для всяких не tech стартапов это прям хорошо бы работало.

  Развернуть 1 комментарий

Как-то в универе надо было сделать проект на Rational Rose + Delphi.
В первой набрасывалась модель, во второй программировали приложение с минимальным набором кода. По задумке должны были справится все пятикурсники.

На практике за весь поток справились мы с другом и неплохо на этом заработали. И это была относительно простая задача.

Как только в low-code нужно сделать чуть более сложную вещь, компетенции обычных людей падают до нуля и сразу.

И тут хорошо понимать текущие и будущие ограничения low-code платформы, чтобы планировать переход от "зависим от платформы" к "всё переписываем с нуля" и "зависим от разработчиков".

Для меня лучший пример low-code - это админка Django. Из коробки в декларативном стиле можно за 5 минут поднять админку (aka удобный CRUD к базе данных). А если не хватает функций, то берешь python и начинаешь писать код.

  Развернуть 1 комментарий
Оля Щаникова, Product Owner Команда Клуба 7 октября в 07:33

Прилинкую пост по теме https://vas3k.club/post/9759/

  Развернуть 1 комментарий
Yury Katkov, миддл формошлёп 7 октября в 07:59

А расскажи про очистку данных тулами! Я помню стотыщ лет назад использовал Google Refine, но это ж по сути был слегка более умный Эксель… а сейчас это каким-нить ML-ем делают?

  Развернуть 1 комментарий

@ganqqwerty, Очистка данных штука сложная и очень муторная. Как сделать её универсальной я не очень представляю. Можно автоматом прогнать кучу проверок, но там много подводных камней, т.к. само понятие что такое хорошие данные очень привязано к задаче.

На ML тут полагаться не стоит, т.к. все проблемы ML как раз из-за плохих данных :)

Можно резать задачи более узко, типа, очищать информацию какого-то вида. Например, адреса или телефоны. Это рабочая тема. Вот тут - https://marketplace.loginom.ru/solutions/ldq есть примеры.

  Развернуть 1 комментарий

@loginom, а вот подход когда мне надо почистить терабайт каких-то конкретных данных, и я сначала вручную чищу первый гигабайт, а потом скармливаю эти чистые данные как обучающий датасет - такое практикуется?

  Развернуть 1 комментарий

@ganqqwerty, Вполне. Это нормальная схема. Правда, я не знаю, что подразумевается под фразой "вручную чищу". Сомневаюсь, что можно глазками просмотреть такой массив.

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

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

  Развернуть 1 комментарий

@loginom, ну да, вручную - это всякими эвристиками и скриптами, типа как в open refine мы делали.

А как потом это верифицируется, как понять, что мы при очистке не внесли искажений в данные?

  Развернуть 1 комментарий

@ganqqwerty, Обычно делаются тесты. В случае ошибок - это наборы данных, в которых гарантированно есть как нормальные записи, так и с косяками. Прогоняем и сравниваем с эталоном. В самом простом случае это таблица с двумя колонками: исходные данные и подчищенные.

Кстати, когда вы очищаете, то гарантированно вносите искажения. Тут важно только, чтобы искажения соответствовали ожиданиям. Сделать тест - лучший способ это проверить.

  Развернуть 1 комментарий

😎

Автор поста открыл его для большого интернета, но комментирование и движухи доступны только участникам Клуба

Что вообще здесь происходит?


Войти  или  Вступить в Клуб