"постоянно запущен и ждёт сообщения" - это не про высший порядок, это про разницу в семантике между функциями и компонентами (control-flow vs dataflow)
"компоненты не замена функциям высшего порядка" - компонент может объявить "зависимость" (абстрактный узел с неким интерфейсом) и тот, кто использует этот компонент (родительский узел) должен будет предоставить эту зависимость (реализацию интерфейса). это статическое внедрение зависимости
но как сообщения компоненты передавать нельзя, так что определенные ограничения есть
Я не то, чтобы решил их исключить, это просто вычислительная модель такова, что им нет места, потому что их место занимают другие вещи, которые работают иначе, решая ту же проблему
Функции, их вызовы и кол-стэк подразумевают что есть некий "поток исполнения" который движется от одной инструкции к другой, и что есть некий стэк вызовов. В dataflow все иначе - есть просто граф узлов, обменивающихся сообщениями, а каждое соединение конкурентно. То есть по умолчанию какого-то "порядка исполнения" тут нет (есть только порядок, в котором текут данные, и его то вы и программируете), а если он вам нужен, вам нужно использовать специальные языковые конструкции
Что касается функций высшего порядка - их место занимают компоненты. Компонент это почти то же самое что функции, но они инстанцируются (как классы) - то есть мы создаем их экземпляры перед использованием, а также инстансы этих компонентов (узлы) работают скорее как го/корутины, чем как под-программы (функции/процедуры) - каждый компонент как "сервер" с входными и выходными портами, он постоянно запущен и ждет сообщений, либо что-то делает, либо пишет сообщения. А соединения между узлами это буферизированные очереди
Спасибо за задачку, завел ишью и вернусь с решением
> несмотря на удобство pipe-оператора писать 100% кода только в этом стиле - это неудобно
Неудобно в control-flow языках, потому что они не созданы для этого - их вычислительная модель, основанная на вызовах функций и кол-стэке подразумевает четкий порядок исполнения, а dataflow работает иначе - вы описываете программу как граф для обмена сообщениями, каждое соединение работает параллельно (конкурентно, если точнее) остальным. Это совершенно иное, чем классическое ФП. И как вы теперь, возможно, понимаете - язык не "заточен под pipe operator", а pipe-operator просто отражает семантику dataflow
P.S - хочу заметить, что не совсем справедливо будет сравнивать читаемость динамического со статически-типизированным. Но в любом случае решение на Nevalang должно быть читаемым. Также хотел бы подметить, что Неваланг будет гибридным языком - с поддержкой визуального редактора, и наш текстовый синтаксис иногда может иметь компромиссные решения, для достижения конечной цели быть гибридом.
ЯП в альфе, мы ищем контрибьюторов в первую очередь, реальные задачи на нем пока решить тяжело. Но к концу 2025 все будет. Комментарий дельный, спасибо
Спасибо за комментарий. Вы не слышали о языке потому что он три года был в приватном репозитории, затем еще долго над ним велась работы, но без особой огласки и только недавно я начал заниматься его "маркетингом"
Из функционального тут неизменяемость данных + отсутствие ООПшных концепций таких как объекты-классы-методы-наследование + композиция и компоненты высшего порядка (как функции высшего порядка). Ближе всего это, наверно, к reactive functional programming, но с некоторыми особенностями
По поводу "-> тут 2000 элементов ->" - говнокодить можно на любом языке :) Тут как и везде есть абстракция (компоненты, пакеты). Большая программа будет структурирована соответствующим образом
Насчет того, что это DSL - это не так (хотя у нас есть мысли покрыть кое-какие юзкейсы в таком стиле). Это язык общего назначения. Что касается типизации - как раз самый сложный кусок в проекте это система типов и статический анализатор, так что когда вы соединяете вместе две штуки, все это тайп-чекается
Мы выбрали Go, потому что его конкурентная модель позволяет относительно легко реализовать многопоточную среду исполнения для языка. Все соединения между узлами конкурентны. Есть и другие причины, например, компиляция в машинный код или мощная стандартная библиотека
Язык будет гибридным и предполагается что вы будете его использовать в связке с визуальным редактором. Но синтаксис тоже должен быть читаемым, тут я соглашусь. Посмотрим, я надеюсь, что все получится
Было бы неплохо дать не только ссылку на репозиторий, а написать немного про язык для тех, кто о нем ничего не знает.
Это не статья, а новость (Хабр при публикации просит указать тип публикации) о том, что вышла новая версия (именно начиная с v0.30.2 я решил постить обновления на хабр). Но я соглашусь, что надо было начать именно с вводной статьи
> В частности, описать задачи, в которых программирование на основе узлов и пересылки сообщений выигрывает у чистого Go (или с чем вы сравниваете). Если выигрывает по наглядности\читаемости - нужны примеры листингов со сравнениями, если по производительности - бенчмарки, и т.д.
Согласен. Сравниваем в целом со всеми традиционными (control-flow) языками, но особенно с Go. И да, такие примеры действительно нужны. Что касается производительности - язык находится в альфа-версии, даже не все фичи еще готовы, так что о бенчмарках пока думать рано. Мы ищем early-adopters и контрибьюторов, в первую очередь. Спасибо за фидбек!
На самом деле 99 бутылок вполне потоковый - на старте создается поток из 99 сообщений и мы сразу его обрабатываем, одно за другим. Но я согласен, что нужны другие примеры. Учту
Есть мнение что компиляция от транспиляции отличается уровнем абстракции. Нева и Го, который она генерирует, на очень разных уровнях абстракции, в отличии от, например, TS->JS. Есть много языков которые компилируются в C. Или, вот, Gleam компилируется в Erlang (даже не в Beam IR)
Но у нас нет и не будет своего бэкенда для машинного языка, это правда
Это не статья, а новость (Хабр при публикации просит указать тип публикации) о том, что вышла новая версия. Только и всего. Но вы правы, пожалуй, в том, что стоило начать не с новости, а с более подробной статьи
в своем языке я как раз эту проблему решил, взяв из раста
?оператор :)го не идеален, но это (имхо, конечно же) лучшее, что есть (для веб-бэкенда, в большинстве случаев)
в точку!
ни один из языков, которые тут приводят в примеры, не является pure dataflow, это все control-flow с элементами dataflow
"постоянно запущен и ждёт сообщения" - это не про высший порядок, это про разницу в семантике между функциями и компонентами (control-flow vs dataflow)
"компоненты не замена функциям высшего порядка" - компонент может объявить "зависимость" (абстрактный узел с неким интерфейсом) и тот, кто использует этот компонент (родительский узел) должен будет предоставить эту зависимость (реализацию интерфейса). это статическое внедрение зависимости
но как сообщения компоненты передавать нельзя, так что определенные ограничения есть
Я не то, чтобы решил их исключить, это просто вычислительная модель такова, что им нет места, потому что их место занимают другие вещи, которые работают иначе, решая ту же проблему
Функции, их вызовы и кол-стэк подразумевают что есть некий "поток исполнения" который движется от одной инструкции к другой, и что есть некий стэк вызовов. В dataflow все иначе - есть просто граф узлов, обменивающихся сообщениями, а каждое соединение конкурентно. То есть по умолчанию какого-то "порядка исполнения" тут нет (есть только порядок, в котором текут данные, и его то вы и программируете), а если он вам нужен, вам нужно использовать специальные языковые конструкции
Что касается функций высшего порядка - их место занимают компоненты. Компонент это почти то же самое что функции, но они инстанцируются (как классы) - то есть мы создаем их экземпляры перед использованием, а также инстансы этих компонентов (узлы) работают скорее как го/корутины, чем как под-программы (функции/процедуры) - каждый компонент как "сервер" с входными и выходными портами, он постоянно запущен и ждет сообщений, либо что-то делает, либо пишет сообщения. А соединения между узлами это буферизированные очереди
Спасибо за задачку, завел ишью и вернусь с решением
> несмотря на удобство pipe-оператора писать 100% кода только в этом стиле - это неудобно
Неудобно в control-flow языках, потому что они не созданы для этого - их вычислительная модель, основанная на вызовах функций и кол-стэке подразумевает четкий порядок исполнения, а dataflow работает иначе - вы описываете программу как граф для обмена сообщениями, каждое соединение работает параллельно (конкурентно, если точнее) остальным. Это совершенно иное, чем классическое ФП. И как вы теперь, возможно, понимаете - язык не "заточен под pipe operator", а pipe-operator просто отражает семантику dataflow
P.S - хочу заметить, что не совсем справедливо будет сравнивать читаемость динамического со статически-типизированным. Но в любом случае решение на Nevalang должно быть читаемым. Также хотел бы подметить, что Неваланг будет гибридным языком - с поддержкой визуального редактора, и наш текстовый синтаксис иногда может иметь компромиссные решения, для достижения конечной цели быть гибридом.
ЯП в альфе, мы ищем контрибьюторов в первую очередь, реальные задачи на нем пока решить тяжело. Но к концу 2025 все будет. Комментарий дельный, спасибо
Полностью согласен :) Спасибо!
слыхал конечно)
Спасибо за комментарий. Вы не слышали о языке потому что он три года был в приватном репозитории, затем еще долго над ним велась работы, но без особой огласки и только недавно я начал заниматься его "маркетингом"
Из функционального тут неизменяемость данных + отсутствие ООПшных концепций таких как объекты-классы-методы-наследование + композиция и компоненты высшего порядка (как функции высшего порядка). Ближе всего это, наверно, к reactive functional programming, но с некоторыми особенностями
По поводу "-> тут 2000 элементов ->" - говнокодить можно на любом языке :) Тут как и везде есть абстракция (компоненты, пакеты). Большая программа будет структурирована соответствующим образом
Насчет того, что это DSL - это не так (хотя у нас есть мысли покрыть кое-какие юзкейсы в таком стиле). Это язык общего назначения. Что касается типизации - как раз самый сложный кусок в проекте это система типов и статический анализатор, так что когда вы соединяете вместе две штуки, все это тайп-чекается
Мы выбрали Go, потому что его конкурентная модель позволяет относительно легко реализовать многопоточную среду исполнения для языка. Все соединения между узлами конкурентны. Есть и другие причины, например, компиляция в машинный код или мощная стандартная библиотека
Запись со стрелочками это побочный эффект от потоко-ориентированной (dataflow/flow-based) парадигмы. Там разница именно в семантике в первую очередь
Язык будет гибридным и предполагается что вы будете его использовать в связке с визуальным редактором. Но синтаксис тоже должен быть читаемым, тут я соглашусь. Посмотрим, я надеюсь, что все получится
Это не статья, а новость (Хабр при публикации просит указать тип публикации) о том, что вышла новая версия (именно начиная с v0.30.2 я решил постить обновления на хабр). Но я соглашусь, что надо было начать именно с вводной статьи
> В частности, описать задачи, в которых программирование на основе узлов и пересылки сообщений выигрывает у чистого Go (или с чем вы сравниваете). Если выигрывает по наглядности\читаемости - нужны примеры листингов со сравнениями, если по производительности - бенчмарки, и т.д.
Согласен. Сравниваем в целом со всеми традиционными (control-flow) языками, но особенно с Go. И да, такие примеры действительно нужны. Что касается производительности - язык находится в альфа-версии, даже не все фичи еще готовы, так что о бенчмарках пока думать рано. Мы ищем early-adopters и контрибьюторов, в первую очередь. Спасибо за фидбек!
На самом деле 99 бутылок вполне потоковый - на старте создается поток из 99 сообщений и мы сразу его обрабатываем, одно за другим. Но я согласен, что нужны другие примеры. Учту
Есть мнение что компиляция от транспиляции отличается уровнем абстракции. Нева и Го, который она генерирует, на очень разных уровнях абстракции, в отличии от, например, TS->JS. Есть много языков которые компилируются в C. Или, вот, Gleam компилируется в Erlang (даже не в Beam IR)
Но у нас нет и не будет своего бэкенда для машинного языка, это правда
Это не статья, а новость (Хабр при публикации просит указать тип публикации) о том, что вышла новая версия. Только и всего. Но вы правы, пожалуй, в том, что стоило начать не с новости, а с более подробной статьи
Спасибо! Читаю ваш блог иногда, если б писал на кложе, обязательно купил бы книгу :)