Pull to refresh

Comments 47

этот no-code не заменяет код – не реализует алгоритм, то есть, ветвления циклы и прочее

Никогда не слышал подобной претензии к nocode — это отражение какой-то странной картины мира. Не говоря уже о некорректном использовании понятия алгоритм.

Выглядит пост примерно так: сам придумал проблему, сам её решил.

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

Дадада, никакого кода, функции и формулы — это же не код, о чем вы.

Функции и формулы существуют вне языков программирования (ЯП), хотя не в каждом ЯП они реализованы одинаково и прям вот все. То есть, если я знаю что такое синус — SIN(), то мне не нужно учить особенности ЯП, чтобы его посчитать. Я ставлю привычную функцию и пишу привычные формулы.
То есть, если я знаю что такое синус — SIN(), то мне не нужно учить особенности ЯП, чтобы его посчитать.

Вы не поверите, я и в языках программирования не учу их особенности, чтобы посчитать синус, я просто пишу sin() или Math.Sin или еще что-нибудь аналогичное.


Я ставлю привычную функцию и пишу привычные формулы.

Вот особенно IF и IS NULL привычные математические функции, да.


Понимаете ли, говорить, что выражение ROUND(IF(ПТУ IS NULL, [СебестоимостьПредыдущая], ([СебестоимостьПредыдущая] * [ОстатокПредыдущий] + IF(Черновик IS NULL, - SUM(price), SUM(price))) / ([ОстатокПредыдущий] + IF(Черновик IS NULL, - SUM(qty), SUM(qty))), 2) — не программирование, это, знаете ли, маркетинговая уловка, и ничего более. Выглядит и пахнет оно как программирование, только с применимостью "хороших практик" как-то не очень.

Вы не поверите, я и в языках программирования не учу их особенности, чтобы посчитать синус, я просто пишу sin() или Math.Sin или еще что-нибудь аналогичное.

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

Неа.


(base) C:\repos> python
Python 3.8.3 (default, Jul  2 2020, 17:30:36) [MSC v.1916 64 bit (AMD64)] :: Anaconda, Inc. on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from math import *
>>> sin(3)
0.1411200080598672
>>>
Понимаете ли, говорить, что выражение ROUND(IF(ПТУ IS NULL, [СебестоимостьПредыдущая], ([СебестоимостьПредыдущая] * [ОстатокПредыдущий] + IF(Черновик IS NULL, — SUM(price), SUM(price))) / ([ОстатокПредыдущий] + IF(Черновик IS NULL, — SUM(qty), SUM(qty))), 2) — не программирование, это, знаете ли, маркетинговая уловка, и ничего более. Выглядит и пахнет оно как программирование, только с применимостью «хороших практик» как-то не очень.


Не программирование на языке программирования. Это формула, которую вы запросто можете встретить в ТЗ, например, которое пишет не программист.
Не программирование на языке программирования.

А какая разница, оно "на языке программирования" или на "другом языке программирования".


Это формула, которую вы запросто можете встретить в ТЗ, например, которое пишет не программист.

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

Формула и программа — разные вещи.
ТЗ пишут так, чтобы максимально точно донести мысль для разработчика. И псевдокод пишут в ТЗ, и формулы, и что угодно, что может сгодиться для цели.
Nocode применяется там, где и ТЗ толком нет, задача проговаривается устно и может несколько раз радикально поменяться по мере разработки и тестирования.

Про текстовый редактор совсем уж непонятна мысль.
Формула и программа — разные вещи.

То, что на ваших скриншотах — программа.


Компью́терная програ́мма — 1) комбинация компьютерных инструкций и данных, позволяющая аппаратному обеспечению вычислительной системы выполнять вычисления или функции управления (стандарт ISO/IEC/IEEE 24765:2010)

ТЗ пишут так, чтобы максимально точно донести мысль для разработчика

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


Про текстовый редактор совсем уж непонятна мысль.

В каких инструментах пишется и поддерживается формула, написанная в ТЗ? Доступно ли там версионирование? Статический анализ? Рефакторинг?

Если угодно, можно интерпретировать этот запрос (про который статья) как ТЗ или программу.

В простом случае — как раз в этом — формулы вбиваются и корректируются поэтапно — итеративно, по мере формулирования задачи о проводке, как вот в ролике.
В простом случае — как раз в этом — формулы вбиваются и корректируются поэтапно — итеративно, по мере формулирования задачи о проводке, как вот в ролике.

Они от этого меньше становятся программой? Программы тоже можно "вбивать и корректировать поэтапно".

Да, программа, я не спорю. Я говорю, что без кода на ЯП.

Ещё речь шла про скорость: в этом примере за 10 минут была сделана первая версия проводки, протестирована, внедрена и готова к использованию. Посмотрите то же в или покажите ваш пример, и там кода будет столько, что не меньше 10 минут только текст набивать будете.
Да, программа, я не спорю. Я говорю, что без кода на ЯП.

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


Ещё речь шла про скорость: в этом примере за 10 минут была сделана первая версия проводки, протестирована, внедрена и готова к использованию.

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

Ok, low-code поделка

Ну вот с этим спорить не буду. Low-code поделка.

Ага, а SQL-запросы — это практически текст на английском языке. Считалось что программисты будут не нужны, потому что SQL запрос сможет написать любой клерк.

Зачем нанимать программиста для создания отчётов если можно написать просто select name, amount from wares where wares.warehouse = «main»?
Зачем нанимать программиста для создания отчётов если можно написать просто select name, amount from wares where wares.warehouse = «main»?

Программиста нанимать следует затем, что он понимает что-то в архитектуре и может спроектировать систему, что недоступно и неинтересно пользователю. А отчеты создавать действительно может сам пользователь, и накликать его в визуальном редакторе несколько легче, чем писать SELECT… FROM… JOIN и задумываться как связать таблицы
накликать его (отчет) в визуальном редакторе несколько легче

Это, кстати, чистая правда — пользователю обычно и правда легче "накликать отчет в визуальном редакторе". Проблемы начинаются (как и вообще с разработкой ПО) позже, когда эти отчеты надо поддерживать.


Впрочем, пользователи с запросом "дайте нам SQL, нам так проще" мне тоже встречаются регулярно.

Сложности возникнут когда не хватит возможностей визуального редактора и придется руками разгребать (grep) сгенирированный код. Простой бухгалтер заплатит за следующую версию визуализатора.

Проблемы возникают в любой разработке, а no-code применяется для тестирования гипотез — чтобы что-то быстро собрать и проверить жизнеспособность идеи, а её воплощение в софте третьестепенно.
Для бухгалтеров есть свой софт, а тут речь идет про быстрые поделки, но в которых уже нужно больше, чем простая формочка с сохранением результата в таблице.
>применяется для тестирования гипотез
Тестировать новый интерфейс программы? MVC не рекомендует смешивать визуальное и цифровое, в данном построителе происходит такое смешение.
Тестировать новый интерфейс программы?

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

MVC не рекомендует смешивать визуальное и цифровое, в данном построителе происходит такое смешение.

Когда есть 2 дня времени и выбор стоит между Google tables, Python, Java, Excel, no-code и бесконечные фреймворки, то реально что-то сделать только в Google tables и no-code.
И тут уж не до MVC.
no-code применяется для тестирования гипотез — чтобы что-то быстро собрать и проверить жизнеспособность идеи, а её воплощение в софте третьестепенно [...] тут речь идет про быстрые поделки

Сравниваем с первым предложением статьи:


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

Кажется, первое процитированное высказывание подтверждает второе.

Сколько-нибудь серьезный продукт — с точки зрения функционала, а не соответствия постулатам MVC и хорошим практикам.
Статья по то, что No-code позволяет предоставить интерфейс, настроить процесс, делать вычисления, и меняться на ходу за приемлемое время.
Сколько-нибудь серьезный продукт — с точки зрения функционала, а не соответствия постулатам MVC и хорошим практикам.

"Быстрая поделка" <> "Серьезный продукт".


Статья по то, что No-code позволяет предоставить интерфейс, настроить процесс, делать вычисления, и меняться на ходу за приемлемое время.

(У вас не no-code, а low-code.)


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

«Быстрая поделка» <> «Серьезный продукт».

Абстрактно и бездоказательно.

Да, позволяет. С этим никто не спорит. Спорят обычно с постулатом «это можно использовать в продакшне наравне с системами, разработанными традиционным образом».


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

Ну как бы без формальных определений мы никуда не уйдем, а их никто не принесет. Поэтому придется жить с субъективными суждениями, да.


Не конкретно эту поделку, а вообще систему, сконфигурированную таким образом?

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


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

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

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

Вот сколько я работал с конструкторами (а это много) — никогда оно не было одинаково. Ни-ког-да.


Иными словами, когда поделка дорастет до масштабного применения, то настроить управление её изменениями будет достаточно тривиально, не сложнее, чем в обычном приложении. Неделя работы DevOps-парня и всё как обычно.

(Муа-ха-ха. Ну то есть мяу. Извините.)


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

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

Вы спросили:


А в чем проблема использовать в продакшне то, что сделано в конструкторе? Не конкретно эту поделку, а вообще систему, сконфигурированную таким образом?

Я вам ответил, с какими проблемами я в своем опыте сталкивался. С системами, лишенными этих проблем — не сталкивался.

Как называется система в которой сделали приложение описанное в статье?
Access в начале века был супер-программой, но в нём могли программировать только программисты. В облачной версии Microsoft уже не смог сделать подобный продукт — программисты в нём программировать не будут.

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

И вот люди применяют решения без кода, хоть зачастую на это просто больно смотреть:
www.notion.so/QuintaDB-Adalo-Integromat-647c4edfe5214d96b5073136078fd4e8
Access в начале века был супер-программой, но в нём могли программировать только программисты.

… а так же подростки типа меня, не имевшие никакого образования и опыта.


В облачной версии Microsoft уже не смог сделать подобный продукт

Power Fx — недостаточно "подобный продукт"?

Power Fx — недостаточно «подобный продукт»?

Даже близко нет.

Давайте проверим на fl.ru:

Никого нет даже с упоминанием этого инструмента:
image

Множество людей и сейчас знают MS Access:
image
Даже близко нет.
Давайте проверим на fl.ru:

А что вы "проверяете"?


Никого нет даже с упоминанием этого инструмента:

Для продукта, анонсированного в этом месяце, это не очень удивительно.

Я показываю, что на сегодня Power Fx — недостаточно «подобный продукт», его практически вообще никто не знает и его будущее неизвестно.

А вы подкидываете пруф, что MS тоже топит за no-code, как я понял.
Я показываю, что на сегодня Power Fx — недостаточно «подобный продукт»

Я не понимаю, как вы подобие определяете.


А вы подкидываете пруф, что MS тоже топит за no-code, как я понял.

Вы поняли неправильно.

Access был популярен, им пользовались многие люди, делали приложения. Он был пригоден. Power Fx пока неизвестно что и нужен ли кому будет.
А вы подкидываете пруф, что MS тоже топит за no-code, как я понял.

Вы поняли неправильно.

Точно, это не no-code и не low-code.
Позиционируется как low-code, но по сути новый птичий язык, разрабатывается с 2015 года и применим во всех Power-продуктах.
Excel — тоже вполне себе low-code система. Но что-то я не заметил, чтобы с его появлением вымер бухгалтерский, управленческий и прочий бизнес-софт. Наоборот, с него он начался. Это к Вашему голосованию, про перспективы low-code и шансы на вымирание традиционной разработки
Эксель сейчас закрывает дыры, которые не реализует ПО: обычно это какие-то особенности работы конкретных компаний, которые не предусмотрены в коробочных решениях и слишком дороги для написания при традиционной разработке. Часто эти требования меняются на лету, что трудно и дорого сопровождать.
В голосовании не сказано про вымирание традиционной разработки, а идет речь о жизнеспособности систем, которые будут закрывать эти дыры вместо экселя, более безопасно, удобно и с хорошей нагрузочной способностью. Да, они могут забрать на себя часть программистской работы — они её уже забрали. Голосование идет про ожидаемый масштаб этого процесса — как много смогут забрать low-code to no-code инструменты.
Only those users with full accounts are able to leave comments. Log in, please.