Комментарии 20
А как же так получилось что инструмент созданный традиционными методами и квалифицированными специалистами не способен решать свою единственную узкоспециализированную задачу, инструмент выявил совсем не те проблемы о которых говорится в статье.
React Native компилирует код в нативное приложение. Оно нативное без всяких оговорок, просто логика написана не на Java/Swift/C#, а на JS и поэтому есть известная разница в том, насколько проще писать обработку тяжелых данных. По размеру тоже вопрос: React Native не таскает с собой свою версию webkit, поэтому размер у него вполне небольшой.
А так спасибо за статью!
Как это? С какого момента RN стал компилировать в натив?
С самого начала там нативные компоненты используются, а JS для их позиционирования, управления + бизнес-логика.
А, ну так вызов нативной api-шной кнопки через bridge всё же не полность. нативное приложение.
Приложения под Android, написанные на Kotlin - тоже не полностью нативные?
А написанные на Java с использованием JNI?
Когда говорят про нативность, вопрос заключается прежде всего не в том, чтобы на Java/Swift писать, а в том, что интерфейс должен из нативных компонент состоять как противоположность подходу Adobe AIR / Apache Cordova / Flutter.
Причем хочу заметить, что приложения на том же Adobe AIR под iOS компилировались в LLVM-код и фактически был нативным приложением, но вот компоненты интерфейса собственные, поэтому никто приложения Adobe AIR под iOS не называл нативным.
Flutter хотя бы компилит в a-la натив, пусть и используя свой GUI-движок. Котлин тоже компилит в байт код, как и Java.
А RN делает код, который запускает web-view, который запускает JS run-time совместно с JIT, и у нас 1 гб для мессенджера. Супер!
Ну про 1 ГБ для простого приложения уже наверное преувеличили! Запустил свое приложение под react-native-windows и оно после старта потребляет 28 МБ.
Да и кто мешает Hermes использовать как JS engine?
Спасибо за статью! Реально не хватает таких отрезвляющих материалов.
No-code через призму маркетологов превращается в глазах собственника/инвестора в супер инструмент: дешевый и быстрый. И потом приходится разрушать радужные мечты, что со сделанным MVP вы не станете вторым Facebook или Телеграмм.
NoCode - как швейцарский нож: всё есть, компактно, симпатично, но все пользуются нормальными отвёртками, ножами и прочим инструментом.
У меня вопрос больше стратегический. Написали быстро прототип, используя кубики конструктора. Нужен свой кубик - ждём, пока его сделают, или сами пишем код. Получается, надо знать экосистему Конструктора, и заодно и Кодировать (например, js, css, html, react). Получается, чтобы развивать прототип, надо уметь кодить.
И давайте на чистоту, сами принципы программирования несложные: циклы, условные переходы, переменные-массивы-структуры. Ну заменили мы условие IF на визуальный кубик - мы же не упростили логику, она осталась. Так же как ORM не отменяет требований к знаниям того, как работает база данных и SQL.
Чем NoCode отличается от использования всяких фреймворков и UI китов? Точно так же набрали компонент и связываем их. Чуть сложнее на старте - гораздо гибче и производительнее в будущем.
Совершенно верно. Особенно проявляется "программистская" основа в конструкторах у которых имеется работа со сценариями. В сценарии под кубиками закамуфлированы практически все конструкции алгоритмических языков
Я сетую за будущую гибридизацию.
При разработке прикладных приложений. Сложное техническое (платформозависимое) программирование, а так же большая часть, условно, математического программирования должны уйти на второй план, или даже на третий план (пракктичнески за кулисы). Но я против полного отказа от программирования. Я считаю, что многим людям проще описывать задачи текстом, чем блок-схемами или чем-то подобным графически. Но - тут должен быть гибрид - можно создавать какие-то части в режиме No-Code, а какие-то текстом - и все должны друг в друга иметь возможность транслироваться (в обе стороны) - даже залихватски закрученный тестовый алгоритм (при этом ещё система должна анализировать его на возможность упрощения восприятия представления). А при анализе, условно, графического представления - отдельные его части можно было бы быстро переводить в текст и обратно.
Что до текста. То тут нужен современный очень выразительный ЯП с минимумом каких-то заковырок (поэтому JS не рассматривается, даже Python тут далёк от идеала) и максимум приближения к простому описанию логики, не заморочек целевой платформы.
И этот ЯП должен быть наполнен большим числом API (библиотек) для быстрого решения огромного набора типовых задач. Но ЯП должен быть очень универсальным и обобщённым так чтобы и решения были тоже универсальными и обобщёнными. И при этом ЯП должен стараться быть как можно менее многословным - скорее так - чтобы какую-то частную детализацию можно было бы описывать вне реализации алгоритмов её обработки, не спускаясь до этой детализации в этих алгоритмах (кроме конкретных постановок требований, критически важных для текущей реализации), а в остальном реализации должны стараться быть как можно более абстрактгными и обощёнными.
И ещё тут очень важно - чтобы это описание было практически 100% универсальным для реализации на разных платформах - так что тут никакой встроенной нативности быть не может!
Ну а сами инструкции ЯП должны быть очень простыми к освоению, близкими к набору слов из хотя бы официальной письменной речи, а в идеале в к разговорной.
Вообще тут хорошо бы интегрироваться с ChatGPT и даже голосовыми помощниками - чтобы они по устному описанию задачи генерировали простое алгоритмическое описание на таком ЯП. При это активно учитывали контекст разработки. Это один уровень магии.
А вот дальше уже должен быть второй уровень магии - это алгоритм должен обрабатываться ещё одним AI-ассистентом, так же являющимся глубоко в курсе контекста разработки - и он уже, по данному описанию, должен генерировать код на более платформенном языке - это может быть Java, C++, C#, да хоть JavaScript для WEB'а... и применять ту компонентою базу, которая доступна для целевой платформы. И этот генератор должен очень глубоко понимать суть транслируемого алгоритма и особенности целевой платформы - и сразу проводить первый этап оптимизации - переводя то, что красиво и просто написано в то, что учитывает нюансы целевой платформы и эффективно на ней работает. И тут может даже генерировать сразу несколько вариантов (потом будет выбран один, или будет переключение между ними).
На этом этапе хорошо бы учитывать и статистику использования предыдущей версии приложения (или какие-то ещё статистические срезы с данных целевой среды - для принятия тех или иных оптимизационных решений).
На третьем этапе - выполняется очередной магический обряд - с промежуточного высокоуровневого языка идёт компиляция в низкоуровневый ЯП целевой платформы. С проведение дополнительной глубокой оптимизации уже на системном уровне. Почему не сразу? Причины две:
Условная отладка и оптимизация - всё-таки если нужно будет разбираться в нюансах работы - делать это лучше видя более высокоуровневый код, чем близкий к машинному.
Эффективнее делать два разных оптимизатора, чем один. И подменять их проще независимо друг от друга. Да и именно низкоуровневый оптимизатор больше занят именно оптимизацией под конкретную системную платформу, чем высокоуровневый (который оптимизирует в основном лишь логику)
Ну и конце концов, при развёртывании под конкретную платформу и конкретную систему низкоуровневый код стремится компилироваться в машинный код - но за это уже отвечает исполнительная среда. Условно об исходных алгоритмах она ничего не знает. Но может располагать локальной статистикой и некоторыми исходными метаданными - и проводить редукцию итогового кода - выкидывая некоторые блоки и упрощая другие, или проводя необходимый инлайнинг или какую-то макрогенгерацию системного уровня.
Но и это ещё не все. Есть ещё один магический круг - это динамический анализ и динамическая оптимизация. Ей должен заниматься ещё один AI-ассистент. Он должен собирать/обновлять статистику использования приложения в конкретной среде, и проводить повторный анализ высокоуровневого кода (если он доступен, или направлять статистику туда, где код доступен); или, когда код не доступен, обращаться к метаданным разных вариантов скомпилированных реализаций (на промежуточном языке) - и на основе общего анализа переключаться между этими вариантами (или вносить какие-то доп ключи финальной компиляции - переключающих эту финальную компиляцию и поведение алгоритма).
Магия тут в том - что в результате код должен автоматически динамически изменяться под нюансы среды исполнения (которые тоже динамически могут меняться). Возможен и вариант параллельного выполнения разных версий кода в одной среде (но для разных сессий) - но это уже высший пилотаж, чтобы они друг другу не создавали проблем.
Но не всегда такие изменения возможны в полностью автоматическом виде - в ряде случаев на высоком уровне алгоритм нужно переделывать более тщательно - и система может только информировать разработчика о таких потребностях, и предложить ему варианты или стратегии перестройки алгоритма.
Само собой должен быть и бэкдор - для внесения специальных хинтов в алгоритмы, которые будут заставлять автогенерацию идти строго в одном направлении или даже применять готовые шаблоны низкоуровневого кода - для случаев, когда это вдруг будет нужно.
А нужно это может быть когда будет проводится, условно, сторонний аудит такой системы специалистами по глубокому анализу кода - которые буду вручную (я утрирую, у них будет полно специализированных средств) анализировать как сгенерированный код, так и статистку его использования и конечную среду - и если будут выявлены какие-то важные отклонения от оптимума - составлять план к их ликвидации (и тут возможностей может быть много от каких-либо настроек, до советов по изменяю исходных алгоритмом или специальных хинтах для их трансляции строго в заданном ключе).
Ну и последняя магия - это всё должно учитываться самообучающим AI и на следующих кругах генерации кода он должен принимать всё это к сведенью (и хинты, статистику и ручные изменения алгоритмов) - и при следящей генерации (на каком бы этапе они ни были) - помнить и учитывать эти знания.
Всё что я сказал про ЯП и алгоритмы 100% можно переложить на архитектуры хранения и обработки данных И на даже на UX/UI.
И ко всему этому так же автоматически обязательно должны строиться автотресты!
Итого - я не убираю 100% программирование - но выношу его на более высокий уровень, и во многих случаях делая его применение незначительным - и тут системы ChatGPT сыграют очень важную роль!
Но и труд программистов не исключается на 100% даже при таком подходе им найдётся работа! Но, безусловно меньше, чем сейчас.
Вот за таким подходом и есть будущее большинства прикладных разработок. Когда? Ну, скорее, ближе к концу нашего века этот процесс в прямом виде уже начнётся - а кульминация - это уже только в следующем веке. Но реальные подвижки в этом направлении формально начались уже сейчас и более явными они будут к середине XXI века
Комментарий достаточно большой и не совсем по теме статьи. Это скорее набросок отдельнй статьи "Какие должны быть конструкторы, что бы мифы превратить в реальность".
И теперь мои комментарии к этой потенциальной статье.
1) Относительно "гибридных" конструкторов. Они уже имеют устоявшееся название "low code". Да, языки программирования они используют, как правило, уже существующие. Например, React Native, javascript и пр.
2) Относительно нового языка программирования. Из контекста статьи (комментария) понятно, что речь идет об алгоритмическом (императивном) язуке программирования. Все языки имеют пять групп операторов: описание данных (в т.ч. объектов); выражения; условные операторы; операторы циклов; функции (методы). И вообщем эти операторы написаны на "разговорном" языке, или очень близко к нему. Да, некоторые языки более компактные, емкие. Но компактность языка и его выразительность незначительно влияют на размер кода. В коде больше места занимают названия переменных. В принципе, изучение языка программирования не продолжительное. Значительно больше времени уходит на изучение библиотек.
3) Если говорить о перспективном языке, то, по моему, нужно создавать декларативный язык для разработки мобильных приложений. В котором просто для каждого экрана нужно указать "ЧТО" он должен делать. Как известно, "ЧТО" нужно делать определяет UX дизайнер. Поэтому нужно на основе этого зыка разработать графический редактор для UX дизайнера. И для каждой платформы написать свой компилятор. Таким образом будет обеспечена нативность, высокая скорость создания приложений и хорошее качество.
Соглашусь с тем, что комментарий тянет на отдельную статью. И я не первый раз оставляю на хабре комментарии на данную тему - каждый раз заходя в глубь идеи с разных сторон. Просто идея весьма ёмкая и с наскока объять полноценную статью с минимальным числом белых пятен очень не просто. Статья обязательно должна содержать хотя бы примеры, иначе она будет совершенно не содержательной - пустой - и вот тут пока есть сложности, но с каждым подходом, подобным данному, я всё больше и больше формирую костяк возможных примеров. Самое главное - это как-то показать тот самый высокоуровневый ЯП будущего - на котором было бы удобно писать как людям, так и машинам. Вот сейчас как раз есть некое прозрение о том как должны выглядеть циклы:
ОФФтопик: Варианты цикла
REPEAT FROM 1 TO 100 {тело цикла}
REPEAT 1 TO 100 {тело цикла}
REPEAT TO 100 {тело цикла} //Это именно от 1 до 100
REPEAT 100 {тело цикла} //Это именно от 1 до 100
REPEAT 1..100 {тело цикла}
(1..100) -> {тело цикла}
REPEAT FROM SomeCollection {тело цикла}
(SomeCollection) -> {тело цикла}
REPEAT Index <- FROM 1 TO 100 {тело цикла}
REPEAT Index <- 1 TO 100 {тело цикла}
REPEAT Index <- TO 100 {тело цикла}
REPEAT Index <- 100 {тело цикла}
REPEAT Index <- 1..100 {тело цикла}
(Index <- 1..100) -> {тело цикла}
REPEAT Element <- FROM SomeCollection {тело цикла}
(Element <- SomeCollection) -> {тело цикла}
REPEAT Index FROM 1 TO 100 {тело цикла}
REPEAT Index 1 TO 100 {тело цикла}
REPEAT Index <- 1..100 {тело цикла}
REPEAT Element <- SomeCollection {тело цикла}
(Element <- SomeCollection) -> {тело цикла}
Всё это один и тот же цикл (ну разве что отдельно несколько примеров циклов итерацией по коллекции). Регистр символов значения не имеет (просто выделил большими буквами ключевые слова - да и то - это всего лишь должны быть встроенные макросы). Куча вариантов даёт свободу ввода, в т.ч. голосового. Из очень важных тут только операторы <- и -> это одни из очень немногих специфических операторов в ЯП, которые нужно будет выучить и строго понимать их применение - они ключевые - являются описанием направления потока (чаще всего данных, но это может быть и поток инструкций), всегда контекстно зависимы - вернее чаще всего они передаются в макроконтекст, который по полученному выражению строит свою реализацию. Некоторые ключевые слова тоже являются контекстно-зависимыми.
С условием так будет так (несколько примеров):
REPEAT WHILE Condition {}
WHILE Condition {}
REPEAT Index 1 TO 100 WHILE Condition {}
(Element <- SomeCollection WHILE Codtition) -> {тело цикла}
С коллекциями можно было бы ещё и фильтр задать:
(Element <- SomeCollection WHERE Codtition) -> {тело цикла}
(Element <- SomeCollection) -> WHERE Codtition -> {тело цикла}
И даже ветвление выборки и по разным вариантам обработки и/или даже с рапараллеиванием:
(Element <- SomeCollection) -> PARALLEL
{
WHERE Codtition1 -> {тело обработки1}
WHERE Codtition2 -> {тело обработки2}
ELSEWISE -> {тело обработки3 остальные}
}
Или просто распараллеливание:
(Element <- SomeCollection) -> PARALLEL threads=3 {тело обработки}
И т.д.
Идея статьи действительно есть, но пока пишу другую - но тоже, относительно темы Low-Code
И да - я сторонник именно Low-Code и скорее о нём написал свой комментарий, чем о No-Code. И в целом да я сетую за то, что в этой теме должны быть две стези: хороший конструктор для No Code и хороший ЯП для обязательного текстового представления (и возможность переключаться между двумя представлениями) т.е. ЯП не должен позволять такие синтаксические конструкции, которые нельзя будет легко представить в каком-либо схематическом виде. Ну и IDE тут должна быть хорошая - не только для конструктора, но и позволяющая легко писать код и производить его рефакторинг в текстовом виде, а так же предлагать активную помощь в авто создании алгоритмов, и их отладке.
Условно во второй части своего комментария я показал, что эти алгоритмы должны эффективно создаваться так же при голосовом вводе и через ChatGPT (голосовому вводу не важно в какой форме создаётся алгоритм: схематическом или текстовом, голосовые команды должны быть одинаковыми хотя, может быть ряд каких-то специфических команд для каждого режима). Ну а системам типа ChatGPT (с которыми тоже должна быть возможность голосового взаимодействия) безусловно важнее именно текстовое представление. И да - голосовое управления я скорее воспринимаю второй канал ввода алгоритма, скорее не основной, а параллельно используемый!
А в третьей части своего комментария выше я хотел показать, что даже генерируемый код можно подвергнуть тотальной оптимизации - если оптимизатор будет глубоко его анализировать и сверятся как с базой знаний так и с реальной статистикой, особенно взятой прямо с места фактического применения алгоритма. Более того - ещё и динамически её считывать и менять алгоритм, подстраивая под конкретные условия его эксплуатации. Практически не упомянут только ещё одного важного этапа магии - это проведение специальных тестов разных вариантов алгоритма - с целью статистического подбора наиболее оптимального. То есть генерация итоговой реализации изначально может идти разнонаправлено - выдавая разные сценарии оптимизации - а потом методом тестирования подбирать наиболее производительный (который позже может быть заменён на другой), а потом ещё и до оптимизировать его детали реализации. Тут главное, чтобы генерация не была противоречива исходной постановки. И AI генератор должен сам выявлять потенциально узкие места и задавать уточняющие вопросы у создателя данного алгоритма.
Вот такой я представляю концепцию Low-Code будущего - двигающуюся в направлении No Code. По голосовому описанию задачи - автогенерация множества реализаций, выбор через тестирование оптимальной - автооптимизация - и динамическое перекодирование при дальнейшем тестировании при эксплуатации.
Но компактность языка и его выразительность незначительно влияют на размер кода. В коде больше места занимают названия переменных. В принципе, изучение языка программирования не продолжительное. Значительно больше времени уходит на изучение библиотек.
Предлагая высокоуровневый ЯП, я скорее намекаю на две вещи:
Всё-таки, считаю, что такой ЯП должен быть достаточно выразительным для человеческого восприятия и прост в использовании неподготовленным человеком (но ознакомившися с базовой коротенькой инструкцией), готовым как для устного ввода, так и для прямого толкования AI анализатором, с цель глуубокого проникновения в смысл алгоритмов; Ну и ЯП должен легко конвертироваться из текста в схематичное представление и обратно.
Это должен быть некий обобщённый ЯП, который так же легко мог бы далее транслироваться в любые другие ЯП целевых исполнительных платформ. Поэтому он обязательно должен быть статически типизированным (но строгость тут может быть достаточно мягкой, понятно, что глубокое выведение типов тут должно быть во главу угла, как и абстрагирование тиров а-ля дженерики; но и авто генерация типов тоже должна быть, в т.ч. составных а-ля так
Пример автосгенеррированной реализации составного типа:
DEF func (a : Int) -> a < 0 ? "Строка" | 100 //Тут должен быть создан составной тип что-то типа
STRUCT func_ret_type
{
TypeValue : Type
Value1 : Int
Value2 : Sring
AsString -> MATCH TypeValue
{
Int -> Value1.ToString()
String -> Value2
_ -> throw Exeptions.UnsupportedType(TypeValue);
}
AsInt -> MATCH TypeValue
{
Int -> Value1
String -> try Int.Parse(Value2) expertion ""
_ -> throw Exeptions.UnsupportedType(TypeValue);
}
AsAny -> MATCH TypeValue
{
Int -> Value1.ToAny()
String -> Value2.ToAny()
_ -> throw Exeptions.UnsupportedType(TypeValue);
}
@ASSIGN -> MATCH @VALUE IS
{
Int -> DO { Value1 = @VALUE; TypeValue = Int.Type() }
String -> { Value2 = @VALUE; TypeValue = String.Type() }
_ -> throw Exeptions.UnsupportedType(@VALUE.Type());
}
}При компиляции в код целевой исполнительной среды это всё может ещё больше оптимизироваться, например могут появиться юнион области общей памяти - если целевая рантайм среда такое поддерживает
Значительно больше времени уходит на изучение библиотек.
Вот для этого и должен создаваться унифицированный ЯП - он должен впитывать в себя (в свой семантический набор и свой фреймворк) все, доступные ему, библиотеки для поддерживаемых платформ - и предлагать им единый API (по возможностей, хотя бы для самых популярных подзадач). А создатель алгоритма должен уметь чётко декларировать что он хочет сделать на данными или над их представлением - а уже AI ассистент должен подобрать подходящую реализацию для целевой платформы. Сам алгоритм на таком ЯП должен как можно больше абстрагироваться от конкретной реализации, но больше сосредотачиваться на простом описании того, что нужно сделать. При это, безусловно, должна быть поддержка хинтов - с указанием конкретной реализации.
Если говорить о перспективном языке, то, по моему, нужно создавать декларативный язык для разработки мобильных приложений.
То что декларативный ЯП - согласен на 100%, но он должен нести много черт императивного, функционального и логического стилей программирования - симбиоз!
Но почему только для мобильной платформы - это должен быть универсальный, кроссплатформенный ЯП, разработки прикладного приложения, причём сразу одновременно для клиентской и серверной части, и с глубокой интеграцией в архитектуру хранения данных, дизайна пользовательских представлений и функционала, и так же сразу с генерацией автотестов и документации.
Как известно, "ЧТО" нужно делать определяет UX дизайнер
Да - тут тоже всё должно создавать в декларативной форме (графичечски и в виде текстового представления) - наиболее близки к этом XAML интерфейсы - но, честно говоря, всё-равно ещё реально очень далеки от желаемой цели - но сама идея, на мой взгляд, плавильная
И носят скорее рекламный характер, чем реальные характеристики инструментов.
И нужно сказать что они попали в цель: высший менеджмент уже интересуется, сможет ли он обойтись без программистов после того как те напишут этоу загадочную "no-code" систему...
Спасибо за материал, прям то что мне было нужно.
Прежде всего, хочу отметить, что я с командой разрабатываем инструмент no‑code, и считаю, что no‑code платформа имеет хорошие перспективы своего развития.
@jura-49А что за no-code продукт разрабатываете?
Если будет интересно, то лучше пообщаться в телеграм @idedepro
Мифы no-code разработки