Ну тащемта да.
Возможно, музыкант был грубияном, наркоманом и мерзким чуваком, но если музыка у него хорошая — разве нельзя признать, что она хорошая?
Рамблер большой, он делал плохие вещи, делал хорошие вещи, в нем работает куча людей.
Какой уровень взаимодействия с Рабмлером делает тебя соучастником наезда на автора NGinx?
Но, справедливости ради, rust все равно когнитивно сложнее.
Тогда лучше уж C# рекомендуйте
Zero cost abstractions — это про стоимость для производительности, а не для мозга.
4 типа указателей, 2 строки (Я про срез), на первых порах — войны с borrow checker-ом, операции над срезами
Да, ноды лучше проверяют инварианты и действительно ошибок может быть меньше.
Собственно в нодовых редакторах действительно можно проверять валидность всех входов выходов и сразу говорить, что что-то не так подключено или не имеет правильных вариантов.
Текстовый ввод полагается на широкий контекст слов (в которых возможны ошибки) все время, поэтому каждая операция его пересчитывает.
Но ноды сами по себе не решают эту проблему — они могут решать ее ограничением вариантов, тогда система не будет такой гибкой, как текст. Например, можно выбирать доступные команды из списка — невозможно ошибиться, но сам выбор команд будет довольно неудобным деревом с разной размерностью ветвей либо длинным списком.
Либо это будет текст — и с ним возможны те же проблемы в миниатюре, что и с текстом кода.
В целом, для компиляторов тоже можно делать AST для всех ранних строк и перестраивать его только для измененных. Обычно, конечно так не делают, а делают целиком для юнитов/классов/файлов/типов, но тоже, соответственно не перестраивают AST каждый раз целиком.
И в целом идея не бесполезна — даже современные текстовые языки можно тащить в эту сторону.
Второй аспект — некорректный AST
Можно ошибиться в тексте программы + программа будет невалидной во время непосредственно написания.
Но точно так же и ноды должны следить за своей корректностью и валидировать свои изменения (например, можно сделать ноду, но не добавить в нее связи — она тоже может быть в некорректном состоянии)
Получается аналог «компиляции» переносится на уровень нод — микрокомпиляции, микровалидации. Но они остаются.
Это Я понял)
Просто без связей линиями между нодами остаются точно такие же связи, как и в текстовых ЯП — по тексту и по именам функций.
Но да, Я понимаю, что можно сделать и линиями или еще как то, различными представлениями.
Еще не совсем понятно, почему текстовое представление сильно усложняет программный анализ.
В смысле конечно не придется заниматься парсингом в смысле интерпретации, но вместо него программа регулярно будет проводить ровно обратную операцию — интерпретацию ноды в человекопонятное состояние виджета и применение изменений виджета на ноду. Все остальные правила — проверка допустимых команд и переменных, валидация данных, останется +- такими же. Просто правила будут проверяться не на коде, а в рантайме на компонентах виджета. Либо не будут проверяться, и тогда их нужно либо проверять рантайм либо это грозит плохой выразительностью языка или UB
Как по мне простой парсинг текста проще, а сложность такой системы сопоставима с современными статистическими анализаторами кода, подсказками и прочим.
Да, пожалуй это комментарий не к вашему редактору.
К вашему редактору развернутый комментарий будет такой:
Ваши тезисы:
«Программисту приходится не просто раз за разом набирать одни и те же сочетания клавиш, но и следить за правильностью форматирования кода, иначе компьютер просто откажется понимать, что в коде написано. Один забытый символ »;" может выдать совершенно невнятные ошибки компиляции/интерпретации. Более того — использование текстового представления программы не просто ставит дополнительные требования к программированию, но и сильно ограничивает возможности программиста для эффективного написания и использования кода. Также текстовое представление информации сильно усложняет анализ этой информации программным способом."
Я вообще не вижу обозначения и решения этих проблем. Скорее важных вещи в вашей системе 2:
— это виртуальная машина с единым контекстом, время жизни которого больше времени компиляции
— это необычный редактор, демонстрирующий различные представления AST этой машины
Первая идея не нова — к ней восходит оригинальные работы по ООП, архитектура микросервисов, горячая перезагрузка во многих движках (та же unity) и диалоговые режимы работы интерпретаторов типа js или python. Это не самая плохая идея, она во многом удобна, но содержит и минусы — неопределенный стейт, проблемы с порчей данных, необходимость дополнительных валидаций либо проблемы, связанные с их отсутствием, и т.д. Эта функциональность не связана с программированием через текст.
Вторая идея — это необычное IDE для этой виртуальной машины со множественными представлениями и гибкой кастомизацией. Эта идея тоже так или иначе имеет отражение в виде расширений редактора для обычных IDE (типа экранов верстки), кастомных компонентов в той же Unity. Тут сложно сказать, насколько она удобна, не попробовав — что то может быть удобно, что-то нет, благо тут очень большой простор для кастомизаций. Пожалуй самое основное, что можно выделить, это расположение блоков отдельно в пространстве — в текстовых редакторах по сути есть один тип представления — вертикальный список. Он же согласуется с самой простой идеей выполнения кода — поочередное выполнение операций. Все остальные связи (нелинейное выполнение операций) все равно сделано через «виртуальные» связи — имена ссылок, переменных, функций, классов и т.д. Опять же — современные IDE содержат и вкладки, и деревья и другие представляния. В нодовых редакторах возможны множественные визуальные связи — соединительные линии. Это позволяет описывать более сложные flow
На ваших скриншотах нет вообще ни того, ни другого — связность есть только в пределах кода одной ноды, остальные ноды представляют собой несвязанные карточки различных представлений (то честь чисто символические виртуальные ссылки по именам)
В принципе, возможно, ваши ноды поддерживают другие полезности — например, динамическую группировку представлений — к примеру представление объекта как данных, как операций, как flow, как связей тех, кто его использует и т.д
Тут не видно.
Но главное, есть куча других утверждений, и не понятно, почему они верны и как предложенная система их решает.
Например про компактность — конечно, наверное не зря люди пишут более компактные языки с минималистичным синтаксисом и без точек с запятой — это может чуть сэкономить, хотя и очень минорно. Ваши сокращения тоже решают эту проблему для ключевых слов, как и подсказки для текстов в современных IDE.
Но основная проблема — это ошибки логики, именах переменных и функций и их быстрый поиск в широком контексте. Проблема в том, что программы пишутся не на условных функциях и нодах, они пишутся на специальном языке, который изобретается вместе с программой. И подсказки действий над нодами — это подсказки базовых операторов, в то время как у программиста проблемы с операторами этого языка.
Список допустимых команд сделает язык немного удобнее для непрограммиста, это как есть. Но собрав допустимые функции в список или дерево их не сделать проще в доступе — их слишком много. По сути команды на клавиатуре — это и есть дерево на 26+10 ветвей вложенности, в различных ветках которого есть все потенциальные команды мира, которые к тому же контекстно связаны с естественной речью. Это очень мощный механизм, который можно сделать проще, но врятли можно сделать быстрее/удобнее, чем печать + контекстные подсказки.
Ваша среда, ее конкретные реализации нод, может успешно решать (или не решать эти проблемы), но за счет конкретной реализации ноды, а не как часть системы. По сути каждая нода будет такой же мини-IDE
Непонятно, как ваша система решает другие проблемы из мира программирования — контракты, допустимые инварианты данных, ошибочные ситуации.
В общем выглядит любопытно, но нет понимания, чем это решит мои каждодневные проблемы.
Автоматически — с трудом представляю. Например, можно обучить нейросеть на основе основе примеров.
Но это не будет универсальным решением.
Даже среди двух программистов может быть 5 разных мнений, как декомпозировать 20 строчек кода, что уж говорить про универсальное решение.
Какие то случаи, например декомпозиция по линии model/view общепринятые, но всегда можно написать код, где это не очевидно.
Это занятие непосредственно связано с созданием контексного языка предметной области и решаемой задачей, соответственно типичные примеры можно найти только для хорошо проработанных областей. Для большинства новых областей создание языка предметной области — это и есть одна из основных задач программиста.
Я примерно про это говорил, когда обозначал проблему «борьбы со сложностью»
Дело в том, что масштабирование в обычных текстовых языках — это не уменьшение и увеличение текста, это масштабирование в пространстве абстракций — когда твоя программа состоит из 10 функций, каждая функция может быть открыта — внутри нее тоже 10 функций, внутри каждой — свои подфункции.
В каждый момент времени ты видишь ограниченный контекст и потому можешь его понять — и по кусочкам понять весь проект.
Но это не бесплатное свойство текста, ты прилагаешь усилия для получения возможности такого концептуального масштабирования — огранизуешь код в абстракции, функции, классы, подписываешь их, описываешь интерфейсы и контракты.
Типичные графические редакторы (Я не работал с редактором автора, очевидно) содержат очень куцые инструменты для такого абстрагирования, поэтому с ростом проекта становятся нечитаемыми, как легаси скрипты сборки.
Можно добавить инструменты — блоки для сокрытия, но представляю, как можно автоматизировать их определение. Собственно в фолде текстового кода есть четкие границы абстракций, которые прописываются явно.
Если же в результате этого мы приходим к тому, что у тебя все равно на экране с десяток элементов, а остальные долны быть схлопнуты — в чем преимущество?
Можно придумать неплохие инструменты, который выковыривают автоматически определенную область связанного графа — типа все кейсы использования класса
Но, опять же, ничего не мешает сделать так же для текста.
Я не то чтобы радикальный скептик, но проблемы видны, их нужно пытаться концептуально решать.
Легко говорить сейчас, что люди скептически относились к реактивной авиации во времена ее зарождения и были не правы. Винтовые самолеты реально летали быстрее. Это видно ретроспективно, а в той точке скепсис оправдан. Возможно эти проблемы решаемы, а возможно — просто никто не вспомнит, что это была перспективная технология.
Я пробовал.
У меня есть движок диалогов с переменными и тьюринг-полной логикой (можно делать узлы без текста с условиями, циклы и т.д.), пробовал чужие проекты с похожей функциональностью. Регулярно пользуюсь нодовыми редакторами для написания шейдеров эффектов. Пробовал аналог Blueprint для Unity (Bolt)
Отзывы такие — механизмы ограниченно применимы, но, кажется, решают не ту проблему.
Проблема сложности остается почти в том же виде, но инструменты к ее решению еще меньше.
Преимущество целиком видимого дерева ограничивается только небольшим объемом плоскости — в этом смысле эффективно написать можно только простую логику.
При развитии логики те же шейдеры становятся не читаемыми.
Можно оформлять визуальные скрипты в блоки логики, уделять внимание красоте, но это имеет ограниченное применение. В текстовом виде хорошо отработаны механизмы работы со сложностью — ты можешь увидеть и функциональное представление, и данные, у тебя есть стандартизированные блоки, подсказки и т.д)
Возможно, для визуального представления такие механизмы тоже можно придумать, но пока, видимо, они не изобретены, либо похожи на механизмы текстовых редакторов.
Единственный на самом деле мощный инструмент — собрать ветвь в функцию и вызывать по имени. По сути очень быстро переходишь на символические ссылки и точно так же, как с текстовым представлением. Начинаешь держать граф зависимостей больше в голове, потому что на экране он целиком не помещается, а перекрестных ссылок довольно много.
Проблемы со слиянием тоже имеются — но тут да, можно доточить инструменты, либо подобрать форматы хранения данных под слияние.
Еще важный момент — текст на самом деле плотнее, чем визуалы блоков и переходов между ними.
Как итого явное преимущество видно в специфических ситуациях:
— Если нужно визуальное представление (в шейдерах можно рисовать промежуточные фазы переходов, в диалогах — портреты говорящих персонажей, очень удобно) — пока это самый важный кейс
— Контекст ограничен
— Много ветвящихся переходов (но не слишком много, иначе проще использовать абстрагирование и символические ссылки)
Минусы соответственно
— Слабые смежные инструменты — инфраструктура лучше подходит под текст, с этим сталкиваешься как раз в смежных ситуациях типа git
— Не масштабируется — большие блоксхемы плохо читаемы, нужны все равно инструменты абстрагирования (например, делить при создании схему на блоки с одним входом и выходом и на большой блок схеме рисовать уже эти блоки — те же функции)
— Обычно блок схемы так или иначе используют собственно текст — названия функций, аргументы. При масштабировании это тоже не очень видно, и тоже часто выраждается просто в список инструкций.
В итоге Я не соглашусь с топик-кастером — реально не проблема в длине текстов и скорости набора, а читаемость работает немного не так.
Еще интересное замечание — редактор диалогов для голосовых ботов от Just AI имеет упрощенную и про версию
Упрощенная выглядит как редактор нод, а про версия — IDE со специальным языком.
Хотя описывается на этом языке тоже граф по факту.
Мне кажется, что в целом просто «звезды сошлись» — это неплохой язык, которому повезло оказаться в нужном месте в нужное время и он просто взлетел вместе с одним из своих трендов.
Основной аргумент — простота входа и работы. Динамическая типизация, мощные инструменты из коробки — если отложить неочевидный bash, это самый первый инструмент базовой обработки данных и скриптов автоматизации исторически. Аналитики пользовались питоном «еще когда это не было модным», программисты тоже используют его — даже если не основной язык, а как скриптовой или для автоматизации.
Поэтому когда тема начала взлетать — это оказался самый распространенный инструмент с нужными плюшками.
Мне кажется хорошая аналогия с js — язык со своими плюсами и минусами, но он пришелся на рост интернета и браузеров, где был ультимативным решением, и вырос с ними. А по мере роста пришли люди, которые по возможности начали его развивать и разрешать проблемы с ним, что улучшило язык.
Для простоты, учебный пример ведь.
Если делать по современному с ноля, придется объяснять и про конвейер, поэтому многие обвязки так и живут в парадигме фиксированного конвейера.
Программа случайным образом генерирует коэффициенты для исследования пространства. Для гонки на скорости я бы запустил несколько тысяч тестов и выбрал оптимальные коэффициенты.
Вроде к машинному обучению относятся не только нейросети, но и множество алгоритмов попроще, в частности эволюционные алгоритмы.
Тогда заголовок малость неверен.
Соглашусь по поводу связей — мне кажется, многие не осознают важность вменяемой общей архитектуры, и связи растут как придется.
Но, кажется, что есть еще случаи.
Во первых, небольшой рефакторинг нужен и при обычном добавлении новых фич (правило бойскаута) — как минимум для добавления или обобщения новой фичи и старых нужно менять старые.
Во вторых, есть хрупкий код — компонент, который имеет тенденцию к регулярному появлению багов. Часто эти вещи (хрупкость кода и количество связей) связаны — высокую сложность обеспечивает как раз сочетание нескольких ответственностей и, как следствие, большое количество связей. Если разделить этот код на модули в соответствии с ответственностью — одновременно и станет лучше и меньше связей.
Мне кажется, вы серьезно недооцениваете влияние старого софта.
Майкрософт держит громадный рынок именно потому, что она гарантирует выдающуюся совместимость (понятно, что не везде и всегда это удается).
Если она сделает так, что старый софт станет невалидным — поднимется гиганская волна, череда необновлений, поиска альтернатив и прочих исков, которые серьезно пошатнут ее позицию.
Поэтому MS конечно хочет свой стор и 30%, но именно как сервис, а не как монополию.
Если бы она могла монополию — она бы это сделала.
В реальном мире им нужно как раз таки предложить альтернативу маку, с которой не нужно слезать. И предложить множество хороших сервисов к своей платформе.
У гугла, кстати, тоже можно ставить сторонние сторы, и, скорее всего, гугл уже не сможет прикрыть эту дверку.
Если же они все захотят провернуть трюк эппла — тогда регуляторы придут ко всем.
Возможно, музыкант был грубияном, наркоманом и мерзким чуваком, но если музыка у него хорошая — разве нельзя признать, что она хорошая?
Рамблер большой, он делал плохие вещи, делал хорошие вещи, в нем работает куча людей.
Какой уровень взаимодействия с Рабмлером делает тебя соучастником наезда на автора NGinx?
Тогда лучше уж C# рекомендуйте
Zero cost abstractions — это про стоимость для производительности, а не для мозга.
4 типа указателей, 2 строки (Я про срез), на первых порах — войны с borrow checker-ом, операции над срезами
Собственно в нодовых редакторах действительно можно проверять валидность всех входов выходов и сразу говорить, что что-то не так подключено или не имеет правильных вариантов.
Текстовый ввод полагается на широкий контекст слов (в которых возможны ошибки) все время, поэтому каждая операция его пересчитывает.
Но ноды сами по себе не решают эту проблему — они могут решать ее ограничением вариантов, тогда система не будет такой гибкой, как текст. Например, можно выбирать доступные команды из списка — невозможно ошибиться, но сам выбор команд будет довольно неудобным деревом с разной размерностью ветвей либо длинным списком.
Либо это будет текст — и с ним возможны те же проблемы в миниатюре, что и с текстом кода.
В целом, для компиляторов тоже можно делать AST для всех ранних строк и перестраивать его только для измененных. Обычно, конечно так не делают, а делают целиком для юнитов/классов/файлов/типов, но тоже, соответственно не перестраивают AST каждый раз целиком.
И в целом идея не бесполезна — даже современные текстовые языки можно тащить в эту сторону.
Второй аспект — некорректный AST
Можно ошибиться в тексте программы + программа будет невалидной во время непосредственно написания.
Но точно так же и ноды должны следить за своей корректностью и валидировать свои изменения (например, можно сделать ноду, но не добавить в нее связи — она тоже может быть в некорректном состоянии)
Получается аналог «компиляции» переносится на уровень нод — микрокомпиляции, микровалидации. Но они остаются.
Просто без связей линиями между нодами остаются точно такие же связи, как и в текстовых ЯП — по тексту и по именам функций.
Но да, Я понимаю, что можно сделать и линиями или еще как то, различными представлениями.
В смысле конечно не придется заниматься парсингом в смысле интерпретации, но вместо него программа регулярно будет проводить ровно обратную операцию — интерпретацию ноды в человекопонятное состояние виджета и применение изменений виджета на ноду. Все остальные правила — проверка допустимых команд и переменных, валидация данных, останется +- такими же. Просто правила будут проверяться не на коде, а в рантайме на компонентах виджета. Либо не будут проверяться, и тогда их нужно либо проверять рантайм либо это грозит плохой выразительностью языка или UB
Как по мне простой парсинг текста проще, а сложность такой системы сопоставима с современными статистическими анализаторами кода, подсказками и прочим.
К вашему редактору развернутый комментарий будет такой:
Ваши тезисы:
«Программисту приходится не просто раз за разом набирать одни и те же сочетания клавиш, но и следить за правильностью форматирования кода, иначе компьютер просто откажется понимать, что в коде написано. Один забытый символ »;" может выдать совершенно невнятные ошибки компиляции/интерпретации. Более того — использование текстового представления программы не просто ставит дополнительные требования к программированию, но и сильно ограничивает возможности программиста для эффективного написания и использования кода. Также текстовое представление информации сильно усложняет анализ этой информации программным способом."
Я вообще не вижу обозначения и решения этих проблем. Скорее важных вещи в вашей системе 2:
— это виртуальная машина с единым контекстом, время жизни которого больше времени компиляции
— это необычный редактор, демонстрирующий различные представления AST этой машины
Первая идея не нова — к ней восходит оригинальные работы по ООП, архитектура микросервисов, горячая перезагрузка во многих движках (та же unity) и диалоговые режимы работы интерпретаторов типа js или python. Это не самая плохая идея, она во многом удобна, но содержит и минусы — неопределенный стейт, проблемы с порчей данных, необходимость дополнительных валидаций либо проблемы, связанные с их отсутствием, и т.д. Эта функциональность не связана с программированием через текст.
Вторая идея — это необычное IDE для этой виртуальной машины со множественными представлениями и гибкой кастомизацией. Эта идея тоже так или иначе имеет отражение в виде расширений редактора для обычных IDE (типа экранов верстки), кастомных компонентов в той же Unity. Тут сложно сказать, насколько она удобна, не попробовав — что то может быть удобно, что-то нет, благо тут очень большой простор для кастомизаций. Пожалуй самое основное, что можно выделить, это расположение блоков отдельно в пространстве — в текстовых редакторах по сути есть один тип представления — вертикальный список. Он же согласуется с самой простой идеей выполнения кода — поочередное выполнение операций. Все остальные связи (нелинейное выполнение операций) все равно сделано через «виртуальные» связи — имена ссылок, переменных, функций, классов и т.д. Опять же — современные IDE содержат и вкладки, и деревья и другие представляния. В нодовых редакторах возможны множественные визуальные связи — соединительные линии. Это позволяет описывать более сложные flow
На ваших скриншотах нет вообще ни того, ни другого — связность есть только в пределах кода одной ноды, остальные ноды представляют собой несвязанные карточки различных представлений (то честь чисто символические виртуальные ссылки по именам)
В принципе, возможно, ваши ноды поддерживают другие полезности — например, динамическую группировку представлений — к примеру представление объекта как данных, как операций, как flow, как связей тех, кто его использует и т.д
Тут не видно.
Но главное, есть куча других утверждений, и не понятно, почему они верны и как предложенная система их решает.
Например про компактность — конечно, наверное не зря люди пишут более компактные языки с минималистичным синтаксисом и без точек с запятой — это может чуть сэкономить, хотя и очень минорно. Ваши сокращения тоже решают эту проблему для ключевых слов, как и подсказки для текстов в современных IDE.
Но основная проблема — это ошибки логики, именах переменных и функций и их быстрый поиск в широком контексте. Проблема в том, что программы пишутся не на условных функциях и нодах, они пишутся на специальном языке, который изобретается вместе с программой. И подсказки действий над нодами — это подсказки базовых операторов, в то время как у программиста проблемы с операторами этого языка.
Список допустимых команд сделает язык немного удобнее для непрограммиста, это как есть. Но собрав допустимые функции в список или дерево их не сделать проще в доступе — их слишком много. По сути команды на клавиатуре — это и есть дерево на 26+10 ветвей вложенности, в различных ветках которого есть все потенциальные команды мира, которые к тому же контекстно связаны с естественной речью. Это очень мощный механизм, который можно сделать проще, но врятли можно сделать быстрее/удобнее, чем печать + контекстные подсказки.
Ваша среда, ее конкретные реализации нод, может успешно решать (или не решать эти проблемы), но за счет конкретной реализации ноды, а не как часть системы. По сути каждая нода будет такой же мини-IDE
Непонятно, как ваша система решает другие проблемы из мира программирования — контракты, допустимые инварианты данных, ошибочные ситуации.
В общем выглядит любопытно, но нет понимания, чем это решит мои каждодневные проблемы.
Но это не будет универсальным решением.
Даже среди двух программистов может быть 5 разных мнений, как декомпозировать 20 строчек кода, что уж говорить про универсальное решение.
Какие то случаи, например декомпозиция по линии model/view общепринятые, но всегда можно написать код, где это не очевидно.
Это занятие непосредственно связано с созданием контексного языка предметной области и решаемой задачей, соответственно типичные примеры можно найти только для хорошо проработанных областей. Для большинства новых областей создание языка предметной области — это и есть одна из основных задач программиста.
Дело в том, что масштабирование в обычных текстовых языках — это не уменьшение и увеличение текста, это масштабирование в пространстве абстракций — когда твоя программа состоит из 10 функций, каждая функция может быть открыта — внутри нее тоже 10 функций, внутри каждой — свои подфункции.
В каждый момент времени ты видишь ограниченный контекст и потому можешь его понять — и по кусочкам понять весь проект.
Но это не бесплатное свойство текста, ты прилагаешь усилия для получения возможности такого концептуального масштабирования — огранизуешь код в абстракции, функции, классы, подписываешь их, описываешь интерфейсы и контракты.
Типичные графические редакторы (Я не работал с редактором автора, очевидно) содержат очень куцые инструменты для такого абстрагирования, поэтому с ростом проекта становятся нечитаемыми, как легаси скрипты сборки.
Можно добавить инструменты — блоки для сокрытия, но представляю, как можно автоматизировать их определение. Собственно в фолде текстового кода есть четкие границы абстракций, которые прописываются явно.
Если же в результате этого мы приходим к тому, что у тебя все равно на экране с десяток элементов, а остальные долны быть схлопнуты — в чем преимущество?
Можно придумать неплохие инструменты, который выковыривают автоматически определенную область связанного графа — типа все кейсы использования класса
Но, опять же, ничего не мешает сделать так же для текста.
Я не то чтобы радикальный скептик, но проблемы видны, их нужно пытаться концептуально решать.
Легко говорить сейчас, что люди скептически относились к реактивной авиации во времена ее зарождения и были не правы. Винтовые самолеты реально летали быстрее. Это видно ретроспективно, а в той точке скепсис оправдан. Возможно эти проблемы решаемы, а возможно — просто никто не вспомнит, что это была перспективная технология.
У меня есть движок диалогов с переменными и тьюринг-полной логикой (можно делать узлы без текста с условиями, циклы и т.д.), пробовал чужие проекты с похожей функциональностью. Регулярно пользуюсь нодовыми редакторами для написания шейдеров эффектов. Пробовал аналог Blueprint для Unity (Bolt)
Отзывы такие — механизмы ограниченно применимы, но, кажется, решают не ту проблему.
Проблема сложности остается почти в том же виде, но инструменты к ее решению еще меньше.
Преимущество целиком видимого дерева ограничивается только небольшим объемом плоскости — в этом смысле эффективно написать можно только простую логику.
При развитии логики те же шейдеры становятся не читаемыми.
Можно оформлять визуальные скрипты в блоки логики, уделять внимание красоте, но это имеет ограниченное применение. В текстовом виде хорошо отработаны механизмы работы со сложностью — ты можешь увидеть и функциональное представление, и данные, у тебя есть стандартизированные блоки, подсказки и т.д)
Возможно, для визуального представления такие механизмы тоже можно придумать, но пока, видимо, они не изобретены, либо похожи на механизмы текстовых редакторов.
Единственный на самом деле мощный инструмент — собрать ветвь в функцию и вызывать по имени. По сути очень быстро переходишь на символические ссылки и точно так же, как с текстовым представлением. Начинаешь держать граф зависимостей больше в голове, потому что на экране он целиком не помещается, а перекрестных ссылок довольно много.
Проблемы со слиянием тоже имеются — но тут да, можно доточить инструменты, либо подобрать форматы хранения данных под слияние.
Еще важный момент — текст на самом деле плотнее, чем визуалы блоков и переходов между ними.
Как итого явное преимущество видно в специфических ситуациях:
— Если нужно визуальное представление (в шейдерах можно рисовать промежуточные фазы переходов, в диалогах — портреты говорящих персонажей, очень удобно) — пока это самый важный кейс
— Контекст ограничен
— Много ветвящихся переходов (но не слишком много, иначе проще использовать абстрагирование и символические ссылки)
Минусы соответственно
— Слабые смежные инструменты — инфраструктура лучше подходит под текст, с этим сталкиваешься как раз в смежных ситуациях типа git
— Не масштабируется — большие блоксхемы плохо читаемы, нужны все равно инструменты абстрагирования (например, делить при создании схему на блоки с одним входом и выходом и на большой блок схеме рисовать уже эти блоки — те же функции)
— Обычно блок схемы так или иначе используют собственно текст — названия функций, аргументы. При масштабировании это тоже не очень видно, и тоже часто выраждается просто в список инструкций.
В итоге Я не соглашусь с топик-кастером — реально не проблема в длине текстов и скорости набора, а читаемость работает немного не так.
Еще интересное замечание — редактор диалогов для голосовых ботов от Just AI имеет упрощенную и про версию
Упрощенная выглядит как редактор нод, а про версия — IDE со специальным языком.
Хотя описывается на этом языке тоже граф по факту.
Основной аргумент — простота входа и работы. Динамическая типизация, мощные инструменты из коробки — если отложить неочевидный bash, это самый первый инструмент базовой обработки данных и скриптов автоматизации исторически. Аналитики пользовались питоном «еще когда это не было модным», программисты тоже используют его — даже если не основной язык, а как скриптовой или для автоматизации.
Поэтому когда тема начала взлетать — это оказался самый распространенный инструмент с нужными плюшками.
Мне кажется хорошая аналогия с js — язык со своими плюсами и минусами, но он пришелся на рост интернета и браузеров, где был ультимативным решением, и вырос с ними. А по мере роста пришли люди, которые по возможности начали его развивать и разрешать проблемы с ним, что улучшило язык.
Если делать по современному с ноля, придется объяснять и про конвейер, поэтому многие обвязки так и живут в парадигме фиксированного конвейера.
Вроде к машинному обучению относятся не только нейросети, но и множество алгоритмов попроще, в частности эволюционные алгоритмы.
Тогда заголовок малость неверен.
Но, кажется, что есть еще случаи.
Во первых, небольшой рефакторинг нужен и при обычном добавлении новых фич (правило бойскаута) — как минимум для добавления или обобщения новой фичи и старых нужно менять старые.
Во вторых, есть хрупкий код — компонент, который имеет тенденцию к регулярному появлению багов. Часто эти вещи (хрупкость кода и количество связей) связаны — высокую сложность обеспечивает как раз сочетание нескольких ответственностей и, как следствие, большое количество связей. Если разделить этот код на модули в соответствии с ответственностью — одновременно и станет лучше и меньше связей.
Прекрасная статья, хотя и не простая.
Интересный стиль подачи.
Майкрософт держит громадный рынок именно потому, что она гарантирует выдающуюся совместимость (понятно, что не везде и всегда это удается).
Если она сделает так, что старый софт станет невалидным — поднимется гиганская волна, череда необновлений, поиска альтернатив и прочих исков, которые серьезно пошатнут ее позицию.
Поэтому MS конечно хочет свой стор и 30%, но именно как сервис, а не как монополию.
Если бы она могла монополию — она бы это сделала.
В реальном мире им нужно как раз таки предложить альтернативу маку, с которой не нужно слезать. И предложить множество хороших сервисов к своей платформе.
У гугла, кстати, тоже можно ставить сторонние сторы, и, скорее всего, гугл уже не сможет прикрыть эту дверку.
Если же они все захотят провернуть трюк эппла — тогда регуляторы придут ко всем.
Вот вам пример из Unity 3D — там есть коллайдер на основе шариков, кубиков (простые формы), а есть — на основе меша.
В нем можно использовать произвольный меш, но по умолчанию Unity умеет строить конвексы прямо из модели.
На картинке кораблик из моего проекта, можете использовать иллюстрацию.
drive.google.com/file/d/1by6wbx8YMIB6h6x8omtN43bTWi0-SRTe/view?usp=sharing
drive.google.com/file/d/1UNAuOjxsJsVQlCvJjSGXn47DSJMfHSJh/view?usp=sharing