Как стать автором
Обновить

Комментарии 431

Фреймворки становятся лучше, языки немного умнее, но в основном мы делаем то же самое.

Не из того же самого уже достаточно давно есть Haskell
Если цель просто не делать тоже самое, то есть brainfuck. Чего уж там :)
В brainfuck-е ничего оригинального нет, он просто предельно примитивен. О нём бы давно забыли, если бы не матерное название. Настоящий «brain fuck» это именно Haskell.
вобщета brainfuck — это машина тьюринга(с парой лишних операций)
Настоящие brainfuck — это APL/K/J и FP.
Haskell вполне понятныя язык.
Сам то он понятный, мозг выносит от того что на нём пишут гранды. С продолжениями, расширениями языка и многоэтажными преобразователями типов. Например dsl-hdl-и на нём, ClaSH в частности. (Что характерно, Chisel почему-то пользуется большей популярностью).
Clash и Lava ориентированы на схемы с одним тактовым сигналом. Это делает их достаточно простыми, но не всегда применимыми. Модель Chisel ближе к обычным HDL, с процессами реагирующими на изменения сигналов.
Мне кажется, человеку со стороны, не знакомому с HDL, проще будет освоить Clash, но для иинженеров ил микроэлектронной индустрии Chisel понятнее и мощнее.
Да бог с ними, с клоками. Я вот это хотел на Clash переложить, и сразу упёрся в запрет рекурсивных описаний, а это для моей древовидной структуры очень нужно. Даже на SystemVerilog-е как-то получилось, а тут нет!
Функциональный стиль существует где-то с 1960-го года. Всё то же самое…

Как тут с кейс-сенситивностью (она же чуыствительность к регистру)? А то в примерах ключевые слова полностью заглавными, остальное — не очень заглавными, как-то неоднородно выглядит

Язык полностью CASE-sensitive, в том числе ключевые слова. И они именно большими буквами, так как много ключевых слов, и если бы они были маленькими, было бы невозможно использовать в именах кучу распространенных слов (например, sum, group, in и т.п.) Ну и в блокноте проще читать такой текст.
Ну то есть в результате половина кода будет набрана КАПСОМ. Это было понятно, когда сиквел только зарождался и не было подсветки кода, но зачем это делать сейчас?
Ключевые слова в языке пишутся большими буквами, потому что их много, и потому что часть из этих ключевых слов — это вполне обычные английские слова. Если сделать их маленькими буквами, то мы не сможем именовать элементы (классы, свойства, формы, и т.д.) в системе этими словами.

Другой вопрос, почему их так много. Начнем с инструкций языка, которые в основном являются объявлениями некоторых элементов системы, их относительно много, и эти объявления необходимо как-то синтаксически разделять. Разделены они по факту в основном ключевыми словами (CLASS, FORM, CONSTRAINT, etc), идущими в начале объявления. Кроме этого (и что более важно) свойства и действия у нас бывают разных типов и создаются с помощью операторов. Типов много, операторов соответственно тоже, их тоже нужно как-то синтаксически разделять. Можно разделять их, например, некими конструкциями из спецсимволов, как, например, разделяются между собой (и у нас естественно тоже) арифметические, логические, битовые операторы, а можно ключевыми словами. Мы выбрали второй вариант, который, как нам казалось, был более читаемым и понятным потенциальным разработчикам с не очень большим техническим бэкграундом (ну и проводил какие-то параллели с sql). Да, выглядит несколько олдово, но, как мне кажется, это дело привычки. Тем более с поддержкой IDE набирать этот код не так неудобно, как кажется на первый взгляд.
на всякий случай — я не минусую Ваши ответы. И в целом, как full time SQL разработчик, считаю инициативу очень полезной. К капсу я в основном «привязался» потому, что считаю, что SQL на самом деле лучший язык для работы с данными, но как все SQL-related языки программирования не развиваются с такой скоростью, как остальные ЯП. И неиспользование капса делает язык более читаемым -> более подходящим для, собственно, программирования.

В целом SQL как язык запросов довольно полный, но как язык программирования его можно было развить добавив возможностей, например, возможность работать с query как с first-class-citizen, то есть реально сделать тип данных query (что то наподобие C# iqueryable).
Но тогда и автодополнения не было. А сейчас можно писать код не нажимая ни shift ни caps lock, и при этом называть свойства sum. Меня если честно к примеру раздражает в java называть переменные aclass, благо в java ключевых слов — кот наплакал.

Но как я уже писал, видимо придется добавить режим с low-case ключевыми словами, раз это некоторых так раздражает.
Меня если честно к примеру раздражает в java называть переменные aclass

clazz же, ну!

Точно :)

А interface как правильно — interfaze?
Меня если честно к примеру раздражает в java называть переменные aclass, благо в java ключевых слов — кот наплакал

Я, честно, не понимаю, зачем называть переменную class.

А сейчас можно писать код не нажимая ни shift ни caps lock, и при этом называть свойства sum

Так проблемы с написанием кода нет, проблема у меня лично возникает с чтением кода. Код пишется 1 раз а читается миллион раз. И лично мне понимать код, наполовину написанный капсом, сложнее, чем код, написанный лоу кейсом.
Дело вкуса, мне и сейчас в последней SQL Server Management Studio, несмотря на подсветку и автоподстановку, удобно в запросах ключевые слова писать капсом, перечитывать и разбирать проще. (но писать полноценные приложения в таком стиле не стал бы)
Тут ключевые слова большими как SQL. А классы и свойства — как в Java классы и методы.
в sql ключевые слова можно любым регистром писать.
заглавными — не более, чем рекомендация.
Да, но тут так пришлось сделать, чтобы упрости грамматику. Иначе синтаксис в других местах был бы более сложный. К тому же, часто бывает лучше рекомендацию сделать обязательной, чтобы код был однотипным.
Какие проекты сейчас пишут с использованием данного языка и кто?
Тут есть часть решений, которые сейчас в продакшне.

Ключевой продукт на языке сейчас — это ERP (на нем сейчас работает около половины из ТОП-10 розничных сетей Беларуси, несколько заводов и оптовиков). Все компании из разных отраслей и размеров, благо модульность позволяет как из кубиков собирать решение и для маленького магазина секонд-хенд и для FMCG сети (в тексте статьи про это было)

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

Плюс всякие внутренние проекты вроде CRM и т.п.

Для всех этих проектов в основном используем людей indoor, причем практически все без минимального / с минимальным IT бэкграундом (это дает реально большое количество плюсов). Но есть ряд проектов, где доработки идут сторонними разработчиками (как заказчика так и третьих лиц)

Правда тут надо понимать, что мы специально тормозили процесс использования языка, чтобы сохранить максимальный контроль за кодовой базой. Это позволяло изменять язык не оглядываясь на обратную совместимость, даже несмотря что первые проекты начали внедряться 8 лет назад. Сейчас конечно, так уже не получится, но мы довели его как раз до того состояния, где функционал в основном будет добавляться, а не изменяться, поэтому и сделали первый long-term backward-compatibility релиз.
в глобальной перспективе lsFusion под силу полностью заменить ERP, RAD и SQL платформы, которые lsFusion превосходит по всем нефункциональным требованиям

Гм. Чтобы потеснить платформу, нужно предоставлять то, что делает платформа. ERP-платформа — это, в том числе, пользовательский интерфейс, механизмы безопасности и интеграции, и все это с учетом расширяемости и настройки, в идеале — конечным пользователем. А вы говорите именно о языке.

В этом языке есть в том числе и функции платформы (все что вы говорите). Это будет в следующих статьях. Хотя уже сейчас можете зайти на сайт и посмотреть / попробовать онлайн как это выглядит. Вся документация с примерами, how-to и т.п. есть.

Но платформа вся полностью language-based. Поэтому речь идет о ней как о языке. То есть как с Java говорим партия, подразумеваем ленин, говорим язык, подразумеваем платформа и наоборот.
В этом языке есть в том числе и функции платформы (все что вы говорите).

Хм. Я даже перечитал два раза, чтобы быть уверенным, что там это написано: "в языке есть [...] все, что вы говорите". То есть в языке есть механизмы интеграции.


Можно пример того, как в вашем языке (нет, не в библиотеке, нет, не в платформе) сделан REST API?


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

Я вот сходил по вашей ссылке на ERP, и первый попавшийся мне файл — он на Java. И, кстати, никакой документации, никаких примеров, никакого how to, вообще ничего.

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


А платформа — это когда у вас есть в системе сущность Country, и она доступна по униформному протоколу по адресу https://вашаерп/api/Countries, а если пользователь накатил на систему расширение, которое в это Country добавляет новое свойство ISOCode, то оно автоматически отобразилось в API (и да, у вас к этому всему сразу доступны машинно-читаемые описания, по которым можно сгенерить клиента на любом языке).


В вашем случае функция платформы ограничивается тем, что вы автоматически выставляете свойство из модуля по фиксированному HTTP-адресу. Вы не делаете автоматического преобразования тела (ни на вход, ни на выход), там нет возможности управлять заголовками и кодами, и так далее, далее, далее. Для высокоуровневого — слишком много кода, для низкоуровневого — слишком мало контроля.

В вашем случае функция платформы ограничивается тем, что вы автоматически выставляете свойство из модуля по фиксированному HTTP-адресу. Вы не делаете автоматического преобразования тела (ни на вход, ни на выход), там нет возможности управлять заголовками и кодами, и так далее, далее, далее. Для высокоуровневого — слишком много кода, для низкоуровневого — слишком мало контроля.


Там есть все функции по управлению заголовками и кодами причем в обе стороны. Например свойство headers (ЕМНИП) при обращении из внешней системы, и HEADERS clause в операторе EXTERNAL (в примерах добавим в ближайшее время), в обратную сторону все тоже самое с именем headersTo. И этого хватало, к примеру, для интеграции с ЭСЧФ (без единой строки Java кода), а поверьте там очень жесткая интеграция (один только правильный порядок тегов в XML чего стоит).

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

В примере нет. К сожалению, угадывать, что в системе есть, слишком сложно.


поверьте там очень жесткая интеграция (один только правильный порядок тегов в XML чего стоит).

Гм, это то, что любой уважающий себя кодогенератор делает прямо по XSD? Или вам XSD не дали?


На остальное ответил ниже.

Про машинно-читаемое описание? Про no-code операции для объявленных в системе бизнес-сущностей?


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

В примере нет. К сожалению, угадывать, что в системе есть, слишком сложно.

Забавно, но про пример с HEADERS мне писали 3 дня назад, но как-то не успели его добавить. Извиняюсь, лишим человека который писал How-to премии, договорились? :)
Гм, это то, что любой уважающий себя кодогенератор делает прямо по XSD? Или вам XSD не дали?

Я просто в качестве примера привел, что разработчики этого сервиса не сильно заморачивались простотой этого интерфейса, но например генерация headers для аутентификации делается средствами языка.
Про машинно-читаемое описание? Про no-code операции для объявленных в системе бизнес-сущностей?
Как бы окей, да, вы дали низкоуровневый механизм, вы говорите, что в нем есть все средства контроля над протоколом, я вам поверю. Этим механизмом вы соревнуетесь с кучей существующих сервисных фреймворков, и я не думаю, что вы победите. А чтобы играть на поле платформ, вам нужны решения, которые предоставляют API внешним потребителям без единой дополнительной строчки кода.

Про машинно-читаемое описание, честно говоря совсем не понимаю, что вы имеете ввиду.
No-code операции для объявленных в системе бизнес-сущностей, есть много в том числе такие, которых у других принципиально быть не может, например вы можете для ЛЮБОГО показателя на форме, в том числе вычисляемого (!) включить логирование. Да это наверное часть платформы, а не языка (тут да в коментарии ниже забыл добавить, что искать не language-based возможности кроме раздела управление)
Про машинно-читаемое описание, честно говоря совсем не понимаю, что вы имеете ввиду.

Я имею в виду приблизительно вот так: https://вашаерп/api/Countries?wsdl — получаем готовый WSDL, который можно скормить любому совместимому инструменту и получить готовый SOAP-клиент, аналогично для OpenAPI и REST-клиентов.


генерация headers для аутентификации делается средствами языка.

Если мы говорим про "написать на языке программирования формирование заголовков запроса", то удивительно, что вы вообще считаете нужным об этом упоминать. Вот если бы у вас средствами платформы было автоматическое обновление OAuth-токенов для систем, к которым вы обращаетесь (и автоматическая подстановка этих токенов в запросы) — это да, повод для гордости.


No-code операции для объявленных в системе бизнес-сущностей, есть много

Я пока про API говорил. Банальный автоматический REST (а лучше — OData или GraphQL) или SOAP API для всех бизнес-сущностей в системе.


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

… у других кого? Платформ? Ну, я бы не был на вашем месте так уверен, платформы разные бывают.

Я имею в виду приблизительно вот так: вашаерп/api/Countries?wsdl — получаем готовый WSL, который можно скормить любому совместимому инструменту и получить готовый SOAP-клиент, аналогично для OpenAPI и REST-клиентов.

Ну если честно, пока именно генерацию WSDL мы пока не делали. Тут важно что: интеграция в lsFusion разделена на две части, первое непосредственно обращение с передачей данных (как примитивов, так и XML и JSON) по сетевому протоколу, например, HTTP, а второе разбор переданных данных (чтение из XML, JSON в поля, свойства и т.п.). Соответственно за вторую часть (разбор данных) отвечают формы (это универсальный механизм и для отчетов и для экспортов/импортов и для интерактивных форм) и по сути они являются спецификацией для обмена. Да можно сделать конвертер Формы<->WSDL (а точнее генерацию формы по WSDL и наоборот), но в последнее время куда чаще сталкиваемся JSON Api, так что генерация формы по JSON пока актуальнее :) Но согласен задача важная хоть и не критичная, думаю сделаем в ближайшей версии (вот прямо сейчас начали :) )
Вот если бы у вас средствами платформы было автоматическое обновление OAuth-токенов для систем, к которым вы обращаетесь (и автоматическая подстановка этих токенов в запросы) — это да, повод для гордости.

Компилятор с универсальным predicate-pushdown (а не с частными случаями как в современных СУБД), пессимистичный cost-based планировщик (который не получает в середине плана 1 и сваливается в nested loop двух 10 тысячных таблиц), архитектура, в которой можно в любой момент откатить запрос \ транзакцию и начать ее заново, когда компилятор ошибся или произошел update conflict, и абсолютная реактивность везде (например материализации любых показателей в одно слово без ограничений) — это повод для гордости. А обновление OAuth-токен — это просто фича, которая в задачах ERP-платформ, с которых вы начали спор, не очень то нужна.
Я пока про API говорил. Банальный автоматический REST (а лучше — OData или GraphQL) или SOAP API для всех бизнес-сущностей в системе.

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

Для того чтобы это сделать нужно поддержать полную инкрементальность (реактивность) по данным, что является очень сложной архитектурной задачей (я в тексте статьи кидал ссылки, что у Oracle и Microsoft получилось в одном частном случае — обновляемых материализованных представлениях). Так что, если вы не уверены, приведите пример.
Соответственно за вторую часть (разбор данных) отвечают формы

И почему-то мне кажется, что все приведенные ради примеры — это не так, а совсем иначе.


А обновление OAuth-токен — это просто фича, которая в задачах ERP-платформ, с которых вы начали спор, не очень то нужна.

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


Для того чтобы это сделать нужно поддержать полную инкрементальность (реактивность) по данным

Я боюсь, что у вас может быть свое представление того, что считать "логгированием".


что является очень сложной архитектурной задачей

Паттерн Event Sourcing.

И почему-то мне кажется, что все приведенные ради примеры — это не так, а совсем иначе.

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

В этом смысле современный мир достаточно забавен. Платформы постоянно интегрируются с фейсбуками, а когда человек стоит в банке и выполняет какую-то простейшую операцию, при этом операторша такое ощущение набирает войну и мир, никого не волнует. Точнее не так, они считают что это криво, но что поделаешь. Так вот поделать можно много чего, просто в этом винигрете из ORM, SQL, Reporting systems, и т.п. тяжело что-то сделать. Даже с нуля.
Собственно вы несколько лет только интеграционными задачами занимались, а мы последние n-лет разгребали конюшни из Дельфи/Ораклов, Аксапт, 1Ск, Аксессов и кучу чего еще. И поверьте там все далеко не так хорошо, раз их владельцы решили их поменять.
Я боюсь, что у вас может быть свое представление того, что считать «логгированием».

Смотрите вы видите, на форме какой нибудь показатель, не знаю, например в скольки ассортиментных матрицах учавствует товар. Этот показатель считается каким-то сложным способом (как хватило фантазии разработчика, заказчика). На нижнем уровне это естественно должно выполняться в SQL потому как иначе в FMCG сети с их объемами все естественно ляжет (но это детали разработчик и пользователь этого не видят / не знают). И дальше пользователь решил, а давайте я его буду логировать. Он жмет правую кнопку и выбирает логировать. После этого он может нажать правую кнопку и просмотреть когда и кем это свойство изменялось (еще раз оно не хранится, а вычисляется, в том числе с импользованием десятка таблиц). Причем оно может изменяться в куче сценариев, товар перенесли между матрицами, матрицы перепривязали к другим матрицам и т.п. Все эти сценарии выполняют разные люди / написаны разными разработчиками, которые вообще не знают ни про какое логирование, ни про существование формы с этим показателем, ни даже о существовании самого показателя.

На самом деле, чтобы реализовать это эффективно, нужно сделать механизмы инкрементального обновления каждого типа оператора (скажем GROUP SUM, (+) и RECURSION инкрементируются очень хорошо, композиции так себе, PARTITION ORDER терпимо), затем нужен компилятор запросов с эффективным predicate push down (не колонка-колонка как в Oracle и MSSQL а в общем случае с UNION'ами, с группировкой внешнего контекста и т.п.), с материализацией подзапросов (все СУБД офигенные оптимисты и очень любят косячить со статистикой и estimate'ть 1 row, после чего nested loop может угрохать сервер), правильное разбиение логического условия на условие запроса и тип join'а (зачем SQL разделил логику отборов в типы JOIN'ов и WHERE, а просто не сделал скажем чтобы для FULL JOIN можно было писать WHERE IN JOIN a OR IN JOIN b — загадка), а это нужно делать с учетом статистики и там еще с десяток таких оптимизаций. И без каждой из этих оптимизаций никуда, проверено практикой и разборками с заказчиками. И вы не скажете разработчику сказать, ты не правильно сделал запрос, он вообще не в курсе, что такое SQL. И сделать так чтобы все это работало из коробки на больших объемах поверьте очень сложная задача. И именно на нее ушло целых 12 лет.
Платформы постоянно интегрируются с фейсбуками

Не с фейсбуками, а с е-коммерсом, складскими платформами, соседним CRM и еще миллионом вещей, которые бизнес использует для своей работы.


Собственно вы несколько лет только интеграционными задачами занимались, а мы последние n-лет разгребали конюшни из Дельфи/Ораклов, Аксапт, 1Ск, Аксессов и кучу чего еще.

Вы не одиноки в этом разгребании.


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

Гм. Вы только что ввели невозможный набор ограничений, потому что есть расчеты, которые невозможно (или избыточно сложно) сделать в SQL.


И сделать так чтобы все это работало из коробки на больших объемах поверьте очень сложная задача

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

Гм. Вы только что ввели невозможный набор ограничений, потому что есть расчеты, которые невозможно (или избыточно сложно) сделать в SQL.

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

Вот уже близко к сути подошли. Я понимаю, что не верите, я честно говоря сам по началу заходил к клиентам, и бродил по формам, просто наблюдая как все работает, понимая какая махина крутится внутри. Ощущение как на самолете летишь, как такая бандура из железа вообще может быть в воздухе :).
Явных ограничений нет, в некоторых случаях может потребоваться оптимизация производительности, но там как в самолете (не тот который индусами по 9 долларов в час, а в идеальном), каждый верхний оптимизатор подстраховывает нижний, поэтому такие случаи если и возникают то при стечении большого количества разных факторов.
То есть, к примеру, те же материализации разработчики расставляют по джедайски, IDE подсказывает приблизительную сложность (то есть как далеко до следующих материализованных показателей), а материализуем-ка это свойство. В том числе можно материализовать PARTITION и RECURSION (современные субд даже если в запросе подзапросы есть отказываются это делать, не говоря уже про такие сложные операторы, кстати забавно что RECURSION при этом на самом деле хорошо «инкрементится»).
В SQL да, а в более высокоуровневых операторах (группировка, разбиение и рекурсия) без проблем.

Вроде бы только что было ограничение "должно выполняться в SQL". Уже нет?


Явных ограничений нет

Ну то есть, какую бы операцию я не решил вызвать, будет работать, будет работать за предсказуемое время, и будут сохраняться все ранее сделанные гарантии — например, будут видны все изменения данного значения, безотносительно того, заходили ли люди на форму, и время/причина изменения?

Вроде бы только что было ограничение «должно выполняться в SQL». Уже нет?

Тут видимо мы не допоняли друг друга. SQL вообще полон по тьюрингу, на нем можно любое вычисление реализовать. Я думал что речь шла о том, что есть вычисления, которые на SQL просто сложно задавать (настолько что это «невозможно» сделать). Соответственно написал, что на более высокоуровневых операторах (которые во всяком случае функциями а не таблицами оперируют) это куда проще.

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

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

На самом деле там просто неявно создается свойство, событие и форма:
a(X x,Y y) = ...
logA = DATA (Session, X, Y) 
WHEN CHANGED(a(x,y)) DO
      logA(currentSession(), x, y) <- a(x,y);
FORM LogA
      OBJECTS x=X, y=Y PANEL
      OBJECTS s=Session
      PROPERTIES dateTime(s), user(s), logA(s,x,y)
;

Ну и на саму форму в которой включалось логирование неявно добавляется событие:
...
PROPERTIES a(x,y) ON SHORTCUT 'показать лог' {
     SHOW LogA OBJECTS x=x, y=y;
}
...

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

Но будет ли это эффективно?


Я думал что речь шла о том, что есть вычисления, которые на SQL просто сложно задавать

Нет, речь шла о том, что есть вычисления, которые на SQL делать неэффективно, а есть операции, которые вообще не вычисления.


Но выполняться естественно должно на SQL, иначе не вытянет по производительности.

Вы правда никогда не видели операций, которые быстрее делать не на SQL?


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

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

Нет, речь шла о том, что есть вычисления, которые на SQL делать неэффективно, а есть операции, которые вообще не вычисления.

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

Видел. Например задача коммивояжера. Но речь то не про такие операции, а про вычисления различных показателей в большинстве ИС / бизнес-приложений.
Эмм. Вот представьте себе, что у вас показатель рассчитывается внешней системой; вызов веб-сервиса, который отдает вам некое значение в зависимости от других показателей на форме, и этот веб-сервис — не чистая функция. Как вы будете показывать, от чего зависит текущее значение?

А я где-то писал про веб-сервис? Речь в примере шла только про данные внутри системы.
И практически все алгоритмически простые задачи решаются эффективно на SQL.

Вот, скажем, нахождение k ближних в n-мерном пространстве, да?


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

А, вот и пример того, о чем я говорил. Вы приняли некий набор ограничений, и он вам кажется совершенно естественным. Но у других бизнесов, внезапно, другие задачи. Например простая задача sentiment analysis для входящих, или простая задача выявления аномалий, или простая задача рекомендаций...


А я где-то писал про веб-сервис?

Я специально спрашивал: "какую бы операцию я не решил вызвать". Вызов веб-сервиса, вроде как, полновправная операция в вашем языке, мне это совсем недавно рассказывали.


Речь в примере шла только про данные внутри системы.

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

А, вот и пример того, о чем я говорил. Вы приняли некий набор ограничений, и он вам кажется совершенно естественным. Но у других бизнесов, внезапно, другие задачи. Например простая задача sentiment analysis для входящих, или простая задача выявления аномалий, или простая задача рекомендаций...

Ну на балалайке платформа тоже играть не умеет. Давайте так, например, в ERP-системах описанных задач штук 5. При этом «обычных» задач / показателей без вывертов тысяч 40. Тут не то что правило Парето нарушается, тут оно даже близко не стояло.
Я специально спрашивал: «какую бы операцию я не решил вызвать». Вызов веб-сервиса, вроде как, полновправная операция в вашем языке, мне это совсем недавно рассказывали.

Это логика действий, а речь опять таки шла о вычислениях. Но любых вычислениях, вообще любых. Понятно, что погоду она предсказывать не умеет, если вы это имеете ввиду под «разумными ограничениями», ok, пусть будет так. Хотя тут становится интересно, а ограничения в Oracle и MSSQL на материализованные обновляемые представления в статье — разумные?
Давайте так, например, в ERP-системах описанных задач штук 5.

… и эти 5 в какой-то момент могут стать market differentiator.


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

У вас было написано:


"Этот показатель считается каким-то сложным способом (как хватило фантазии разработчика, заказчика)."


И я явно переспросил: какую бы операцию. Вызов веб-сервиса для расчета чего-то в нынешнем мире — вполне себе сложный (даже не такой уж и сложный) способ расчета.


Но любых вычислениях, вообще любых.

Выше уже выяснили, что не любых. Forward propagation по нейронной сети для получения классификатора по тексту? Мне почему-то кажется, что нет.


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

… и эти 5 в какой-то момент могут стать market differentiator.

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

Помните в КВН очень старый номер детей лейтенанта Шмидта с «падлавил». Ок, вы опять выиграли :)
В этом и ирония, операторша пишущая трехтомник при выполнении простейшей операции и очереди в кассу банка людей мало волнуют. А вот интеграция с фейсбук — это market differentiator.

Ну, если не считать того, что я писал не про вещи типа интеграции с фейсбук, а про вещи типа "эскалируй на менеджера кейс, в котором клиент очевидно раздражен"...


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

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

Это потому, что буква «j» идет в английском раньше буквы «l». Вообще, там сейчас 323 файла Java (в основном legacy код, который появился до многих возможностей в самой платформе) и 2274 файла на lsFusion.
И, кстати, никакой документации, никаких примеров, никакого how to, вообще ничего

Просто ERP на ее базе — пока что коммерческий продукт. И это единственная в нем защита от несанкционированного распространения.
Не в ту ветку.
Можно пример того, как в вашем языке (нет, не в библиотеке, нет, не в платформе) сделан REST API?

Вот тут. Но это обращение к внешней системе. Что касается из внешней системы — любое действие можно вызвать из внешней системы при помощи http запроса. То есть фактически создание действия это и есть создание REST Api. Собственно у нас очень часто так и идет интеграция — создаем действие doSomething() {}, а тем кто интегрируется кидаем ссылку хттп://mysite.com/exec?action=doSomething. Хотя конечно если захотеть можно и тут придраться.
Я вот сходил по вашей ссылке на ERP, и первый попавшийся мне файл — он на Java

Ну как я уже писал первые проекты начали внедряться 8 лет назад, а механизмы интеграции появились года 3 назад. Честно говоря давно собирались их переделать, но тут решили не трогать то, что работает. А так, за последние 3 года в ERP хорошо если 500 строк кода на Java сделано, и то это работа с каким-то специфичным оборудованием, где уже есть готовые библиотеки.
И, кстати, никакой документации, никаких примеров, никакого how to, вообще ничего.

Документация, Примеры (в том числе в попробовать онлайн), How-to
любое действие можно вызвать из внешней системы при помощи http запроса

И это функция языка или платформы?


Хотя конечно если захотеть можно и тут придраться.

Да зачем придираться, достаточно одного простого пункта: как получить машинно-читаемое описание параметров и ответов вашего действия?

И это функция языка или платформы?

Давайте так, во-первых, прямо в языке есть функция интеграции (копия из документации по ссылке):

externalHTTP()  { 
    EXTERNAL HTTP GET 'https://www.cs.cmu.edu/~chuck/lennapg/len_std.jpg' TO exportFile; 
    open(exportFile()); 

    EXTERNAL HTTP 'http://tryonline.lsfusion.org/exec?action=getExamples' PARAMS JSONFILE('\{«mode»=1\}'TO exportFile; // фигурные скобки escape'ся так как используются в интернационализации
    IMPORT FROM exportFile() FIELDS () TEXT caption, TEXT code DO
        MESSAGE 'Example : ' + caption + ', code : ' + code;
        
    EXTERNAL HTTP 'http://tryonline.lsfusion.org/exec?action=doSomething&someprm=$1' BODYURL 'otherprm=$2&andonemore=$3' PARAMS 1,2,'3'// передает в BODY url-encoded второй и третий параметры
}
externalSQL ()  { 
    EXPORT TABLE FROM bc=barcode(Article a) WHERE name(a) LIKE '%Мясо%'// получаем все штрих-коды товаров с именем мясо
    EXTERNAL SQL 'jdbc:mysql://$1/test?user=root&password=' EXEC 'select price AS pc, articles.barcode AS brc from $2 x JOIN articles ON x.bc=articles.barcode' PARAMS 'localhost',exportFile() TO exportFile; // читаем цены для считанных штрих-кодов
    
    // для всех товаров с полученными штрих-кодами записываем цены
    LOCAL price = INTEGER (INTEGER);
    LOCAL barcode = STRING[30] (INTEGER);
    IMPORT FROM exportFile() TO price=pc,barcode=brc;
    FOR barcode(Article a) = barcode(INTEGER i) DO 
        price(a) <- price(i);
}

Во-вторых, еще раз это lsFusion это и язык и платформа. Точно так же как Java это и язык и платформа. Точнее даже не так, есть Java язык и Java платформа, точно так же есть и lsFusion язык и lsFusion платформа.
прямо в языке есть функция интеграции

… которая обеспечивает только вызовы наружу, но не входящие. Кстати, вы вообще разделяете язык и его стандартную библиотеку?


точно так же есть и lsFusion язык и lsFusion платформа.

Именно об этом я и говорю: чтобы заявлять "в глобальной перспективе lsFusion под силу полностью заменить ERP, RAD и SQL платформы", нужно говорить о платформе, а не о языке. А статья, насколько я ее смог прочитать, именно о языке.

… которая обеспечивает только вызовы наружу, но не входящие.

Да, но и средства интеграции прямо в языке тоже есть. Хотя ладно, немного глупый спор, будем считать, что вы выиграли :).
Кстати, вы вообще разделяете язык и его стандартную библиотеку?

Честно говоря, разделяли, первые лет 10. Но потом когда встал вопрос автоматизации всех процессов (а у нас почти все процессы автоматизированы до одной кнопки) возник вопрос целесообразности поддержки этой библиотеки отдельно. То есть для нее нужны отдельные версии, репозитарии, нужно постоянно переключаться между несколькими ветками и т.п… При этом выигрыш был непонятен, модульность обеспечивается другими средствами (REQUIRE модуль в заголовке), а экономить сто килобайт на сто мегабайтном файле смысла очень мало. Поэтому где-то 2 года назад решили долить большинство стандартных библиотек внутрь платформы, тем более что в платформе и так количество системных библиотек было сопоставимо с количеством этих стандартных библиотек.
Именно об этом я и говорю: чтобы заявлять «в глобальной перспективе lsFusion под силу полностью заменить ERP, RAD и SQL платформы», нужно говорить о платформе, а не о языке. А статья, насколько я ее смог прочитать, именно о языке.

Еще раз платформа практически полностью language-based. То что вы нашли одну фичу (обращение из внешней системы) не language-based, поздравляю, но вам очень повезет если найдете вторую (поверьте я участвовал в написании документации знаю о чем говорю). Плюс теоретически кто-то другой может запилить другую реализацию платформы построенной на этом языке, и что тогда? Вы же не придираетесь что Java как язык продвигают, а не как платформу.
Поэтому где-то 2 года назад решили долить большинство стандартных библиотек внутрь платформы, тем более что в платформе и так количество системных библиотек было сопоставимо с количеством этих стандартных библиотек.

Ну то есть единственный способ этим воспользоваться — это писать для одной платформы на одном языке. Хм.


Еще раз платформа практически полностью language-based.

Что вы понимаете под этим утверждением?


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

А мне, собственно, все равно, потому что я знаю про существование Kotlin и Scala. А учитывая, что сам я пишу в основном для .net, где это разделение еще сильнее, мне все равно дважды.

Ну то есть единственный способ этим воспользоваться — это писать для одной платформы на одном языке. Хм.

Не совсем понял, о чем речь. Нет, можно писать и на Java и на Kotlin, если сильно понадобится, что мы кстати и делаем, собственно ссылку вы сами приводили выше. Подключается проще некуда f = INTERNAL 'my.class.action' и используйте как обычное действие. Наоборот все чуть сложнее, но поверьте это все равно куда проще чем в условном ORM. Ну и если надо DI, то сам сервер можно подключать через Spring Beans, и наоборот если в той же виртуальной машине нужен мини Java сервер (вроде оборудования как вы видели), его можно через Spring Beans подключить к серверу приложений.
Что вы понимаете под этим утверждением?

То есть любая абстракция системы задается кодом на этом языке (кроме дизайна отчетов там — xml, ну в будущем кастомизацию дизайна форм на react'е скорее всего подключим там будет javascript/react.
А учитывая, что сам я пишу в основном для .net, где это разделение еще сильнее, мне все равно дважды.

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

… а вот это утверждение намного скучнее оригинального, потому что понятно, что платформы, написанные на (каком-то) языке, могут конкурировать с другими платформами. Вопрос в том, как писать будут.

Вот честно, хотел написать оригинальное утверждение, но тогда этот спор будет бесконечным. Просто сам язык (как и платформа) ну очень сильно отличается от всего, что есть сейчас на рынке (сейчас оставим вопрос в какую сторону, просто отличается). А мы спорим о терминологии. :(
Просто сам язык (как и платформа) ну очень сильно отличается от всего

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

>> Он гораздо лучше оптимизируется

Когда сочиняли Хаскель, именно так и думали. Но потом «что-то пошло не так (с)».

>> само слово “свойство” короче, чем «чистая функция», плюс не имеет ненужных ассоциаций.

Зря вы заменили привычные названия на вам приятный новояз. Это мешает тем, кто знает о чём речь. Хотя да, обычно продвижение языков начинают с полностью некомпетентной части разработчиков, что даёт большое количество участников, но если при этом заранее исключать грамотных участников — вы быстро выйдете из моды, ибо некомпетентная часть очень скоро перескочит на очередной «тренд».

>> SQL большинство из них недолюбливают, слишком уж там много магии под капотом

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

>> в глобальной перспективе lsFusion под силу полностью заменить ERP, RAD и SQL платформы

В целом наблюдаю картину стандартной эйфории из серии «мы строили, строили, и вот — построили!». Понятно, что в такие моменты возникает желание срочно слетать на Марс и именно на только что построенном Запорожце. И не беда, что к старому запору придётся прикрутить космическую ракету, ведь главное — как нам нравится наш великий замах!

Конструктивно же — выход «на рынок» с новым инструментом есть дело затратное. Затраты, обычно, мало кто считает. Поэтому мало кто реально выходит на рынок.

Большие конторы, у которых денег немеряно, обычно продумывают стратегию использования новых инструментов. Сначала они спрашивают себя — а что мы можем поиметь с вывода на рынок вот такой вот тулзы? И просто некие абстрактные толпы поклонников в данном случае им мало интересны. Потому что им нужно окупить затраты на вывод системы в массы. А теперь сравним с вами — что вы намереваетесь получить? Если ответ привычный «много денег», то возникает вопрос — как? Вы думали? Сильно подозреваю, что нет. Точнее «в общих чертах мне всё понятно» как раз на самом деле является ответом типа «не думал». Бывает ещё ответ «хочу увидеть рост популярности моего любимого зайчика (инструмента)». Но здесь возникает второй вопрос — а вы знаете, сколько денег стоит вывести инструмент в разряд «популярных»? Подозреваю, что ответ опять — нет.

Ладно, это всё лирика, так, на будущее, может вас заинтересует.

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

Новый язык должен дать нечто ранее не использованное в других языках. Ваша задача — указать это нечто и тем заманить массы в ваш лагерь. Из выше приведённого текста суть преимущества вашего языка не очевидна. В основе — функциональный подход, скрещенный с процедурным с надеждой на декларативность получившихся SQL-like конструкций. При этом основной нишей изначально была явно работа с БД, хотя в дальнейшем «Остапа понесло» и набор ниш быстро расширился. В целом получаем просто новый язык, который просто нравится автору, который считает, что создал нечто небывалое, а потому всем это будет интересно и все быстро станут это всё учить, использовать, ну и далее близится happy end.

Не хочу сильно бить по самолюбию, тем более, что вижу интересный подход, но тем не менее хочу повторить — сделать чудо в современных реалия сложно. И боюсь, у вас не получилось. Хотя если вы настаиваете — было бы неплохо понять преимущества, которые позволят, например, тем же разработчикам ERP, делать продукт быстрее, качественнее, дешевле и т.д.
было бы неплохо понять преимущества, которые позволят, например, тем же разработчикам ERP, делать продукт быстрее, качественнее, дешевле

А можно уточнить, при помощи каких платформ/технологий сейчас по-вашему можно быстро, качественно и дешево делать ERP продукты? Ну, чтобы было с чем сравнивать…
Для «по быстрому» — на тех, которые знает разработчик.

Для «качественно» — при помощи средств, позволяющих гибко оперировать абстракциями. Например — Java. Хотя и Java ещё есть куда расти.

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

Предположим разработчик ничего не знает, или хочет делать не «по быстрому», а надолго и всерьез.
Для «качественно» — при помощи средств, позволяющих гибко оперировать абстракциями. Например — Java. Хотя и Java ещё есть куда расти.

Вы всерьез предлагаете делать логику заказов/поставок/платежей на pure java? А еще же фронт надо будет писать.

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

Собственно мы сейчас и обсуждаем область — ERP системы. На данный момент, лидером в этой области (именно ERP-платформ) в РФ является 1С. Даже не касаясь всех его недостатков, у него как минимум есть один достаточно серьезный — он коммерческий. Предложите что-то другое, на чем можно делать продукт быстро, дешево и качественно.
И опять же речь идет не только о ERP. Допустим вам нужно написать какой-то простой процесс, но google docs уже недостаточно. Что Вы возьмете?
>> Вы всерьез предлагаете делать логику заказов/поставок/платежей на pure java?

Логика — это как раз pure язык ХХХ. То есть чистая логика (чистые алгоритмы) пишутся на чистых языках (без библиотек и прочего).

>> А еще же фронт надо будет писать.

Есть GWT.

>> Допустим вам нужно написать какой-то простой процесс

Простой обычно означает — надо дёшево и быстро. Поэтому просто использую то, что знаю.
Логика — это как раз pure язык ХХХ. То есть чистая логика (чистые алгоритмы) пишутся на чистых языках (без библиотек и прочего).

Хорошо, вот логика — есть миллион заказов, нужно посчитать их сумму. Как это сделать на pure языке XXX? Загрузите через ORM все в память? Или будет уже использовать не pure язык XXX, а pure язык YYY? Сколько в итоге языков надо знать, чтобы разработать простенькое приложение?
Как это сделать на pure языке XXX?

dbContext.Orders.Sum(o => o.Amount)

Это слишком простой случай. В более сложном на LINQ вы уже не сможете сделать. Но это и не важно. Приведите пример на не проприетарной технологии.
Это слишком простой случай.

Какой попросили.


В более сложном на LINQ вы уже не сможете сделать.

На LINQ — не смогу, смогу на чем-то другом.


Приведите пример на не проприетарной технологии.

А с чего бы вдруг такое ограничение?

LINQ как часть dotnet core выложена на гитхабе под MIT.

Вообще говоря .net полностью опенсорсный и с более либеральной лицензией, чем у вас. Процитированный код можно выполнить вообще без единой строчки закрытого кода, если запускать на Linux против опенсорсной ДБ типа постгри.

Прошу прощения, давно не следил за LINQ. Майкрософт действительно в последнее время стал значительно более открыт к общественности. Подскажите, пожалуйста, а как LINQ сейчас запустить с PostgreSQL и Linux? Кто поддерживает?

Entity Framework Core запускается на Linux из коробки и поддерживается Microsoft. Провайдер для PostgreSql поддерживается сообществом, но вполне продакшн-реди

А можно ссылку на провайдер для PostgreSQL. А то у меня Google выдает ссылку только на коммерческие, а также те, которые уже не поддерживаются.
Кроме того, а что насчет IDE? Есть какая-нибудь бесплатная IDE для разработки на LINQ?
Кроме того, а что насчет IDE? Есть какая-нибудь бесплатная IDE

VS Code.

быстро, качественно и дешево делать ERP продукты?

Вы же помните про "вычеркните одно" (а лучше два)?

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

Не одновременно. Ну не выйдет обмануть этот треугольник.

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

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

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

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

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


А маркетологи поставщиков всегда утверждают, что у них все три.

И врут. Не уподобляйтесь.

И врут. Не уподобляйтесь.

К сожалению, тогда проиграете. Много раз проходили. Вы говорите все честно, а конкуренты врут по-черному. В итоге заказчик выбирает конкурента, так как три больше двух.
Потом конечно матерится по-черному, но поезд ушел. У нас мало кто готов выбросить то, за что уже заплачены деньги.
К сожалению, тогда проиграете.

Или выиграете в долгосрочной репутационной перспективе. Это тоже работает.

>> выиграете в долгосрочной репутационной перспективе

Не могли бы вы представить примеры?

На мой взгляд репутации сегодня нет ни у кого. Хотя здесь можно поговорить о моём максимализме :)
Не могли бы вы представить примеры?

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


На мой взгляд репутации сегодня нет ни у кого.

Репутация есть у всех.

Зря вы заменили привычные названия на вам приятный новояз.

Там дело в том, что «чистая функция» — это функция. Она не подразумевает хранение значений, а свойство — подразумевает, то есть это может быть и поле и метод (а в современных языках такая штука называется именно свойство).
В целом наблюдаю картину стандартной эйфории из серии «мы строили, строили, и вот — построили!». Понятно, что в такие моменты возникает желание срочно слетать на Марс и именно на только что построенном Запорожце. И не беда, что к старому запору придётся прикрутить космическую ракету, ведь главное — как нам нравится наш великий замах!

Поверьте 12 лет разрабатывать что-то на голом энтузиазме или вере невозможно. Это можно за полгода склепать поделку, и пребывать в состоянии эйфории, но уже ко второму году это быстро проходит, дальше наступает холодный расчет. Особенно, когда вы работаете на самом жестком рынке — разработки информационных систем, где чтобы заставить сменить чужую систему вы должны доказать, что вы на несколько порядков лучше. Но как показала жизнь есть простой способ это сделать. Просто быть на несколько порядков лучше — когда вы можете набирать разработчиков с открытого рынка: людей без IT-образования, тем самым вы можете набирать в том числе лучших (иначе вы проиграете в споре за них крупным модным компаниям), когда эти люди могут делать по 5 задач в день, когда их можно свободно переключать между задачами из разных областей и т.д., тогда у вас остаются только два конкурента лень и жадность (даже глупость отступает на второй план). Поэтому, что касается вопроса про деньги, поверьте мы уже достаточно зарабатываем просто за счет того, что скажем на рынке FMCG-ритейла Беларуси (а это второй по деньгам сегмент после банков) у нас практически не осталось конкурентов (все выбирают либо между нами, либо остаться с тем что есть).

Но вообще я так понял вы до сайта не добрались, там всего три страницы, с ответами на все ваши вопросы.

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

В любом случае я не совсем понял ваш тезис:
a) Такой язык уже есть. Можно тогда пример хоть одного близко похожего.
б) У него нет преимуществ. Специально для этого мы сделали сайт из 3-х страниц, где есть краткие преимущества, подробные преимущества и их сравнение. Если вы считаете что каких-то преимуществ нет, они не существенны, что же, можем здесь подискутировать. Хотя да я знаю, что на Хабре не принято отсылать на сторонние сайты, так что если нет, давайте просто дождемся следующих статей прежде чем делать выводы.
>> Она не подразумевает хранение значений, а свойство — подразумевает

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

>> вы до сайта не добрались

Да, не посмотрел сразу. Но исправился :) Там в части «Разрабатывайте просто» такой аргумент «против всех»:

>> Одна парадигма. Один язык

Или вот такое (в «Разрабатывайте быстро»):

>> Завершенная ERP-система среднего уровня сложности всего в 25K строках кода

Здесь на самом деле «всё не так просто (с)». Один язык и одна парадигма появились начиная с машинных кодов. Да, машинные коды позволяют написать и OLTP и OLAP, но вы же понимаете, что реальность внесёт здесь некоторые коррективы.

Ну а размер «средней ERP» — это вообще нечто абсолютно произвольное. Под такое определение подойдёт, например, 1С-Управление, требующее для написания ноль строк, ибо «всё украдено до нас (с)». И вы, получается, опять в проигрыше.

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

Ну и в целом сам язык тоже не на пустом месте появился. Точнее — идея нового языка. Во введении вы его сравнили с SQL, и в целом очевидно, что раньше писали системы преимущественно на хранимых процедурах, так вот и покажите, что в сравнении с хранимками вы увидели вот такое-то преимущество, вот так-то облегчающее работу программиста. Хотя здесь стоит заметить, что хранимки — это обычно довольно убогий процедурный язык, не позволяющий гибко работать со сложными абстракциями, а потому даже небольшое повышение уровня абстракции языка даёт ту самую важную гибкость, ну и поэтому (весьма вероятно) вам понравилась идея нового языка. Только ведь в таком разрезе есть альтернатива — изучить другой, более мощный при работе с абстракциями язык. Вы сравнивали свой язык в этом отношении с более универсальными? И что вас не устроило? То есть, часто люди поддерживают нечто своё не потому, что оно лучше других вариантов, а просто потому, что оно понятнее этим людям, ведь они написали это нечто с нуля и знают много важных деталей, которые помогают им наращивать эффективность в отдельных местах. Только эти «отдельные места» быстро заканчиваются. То есть писать по шаблону формочки для ERP — это одно, а вот если потребуется усложнение алгоритма — здесь могут быть страшные засады.

В общем — я бы сказал, что хотелось бы увидеть некую теоретическую базу, показывающую, что вы действительно сдвинули с места ту или иную проблему программирования, а не, в общем-то, рекламные слова про «среднюю ERP».

Для примера — в функциональных языках привычной является функции типа fold, zip, которые агрегируют переданные в них данные, примерно как ваша конструкция GROUP, но отличие такое — эти функции можно написать самому, а не использовать библиотечные. То есть гибкость здесь в том, что не нужен новый язык для реализации важного алгоритма агрегирования данных. А у вас нужна новая конструкция, которую нельзя написать средствами языка. У вас гибкость, получается, заметно меньше.
Там в части «Разрабатывайте просто» такой аргумент «против всех»: "Одна парадигма. Один язык"

… что многие разработчики, кстати, сочтут недостатком.

В среде разработчиков вообще очень часто луддизм встречается. В этом случае простота в принципе недостатком считается.

Вопрос в том, простота ли это.

Ну а размер «средней ERP» — это вообще нечто абсолютно произвольное. Под такое определение подойдёт, например, 1С-Управление, требующее для написания ноль строк, ибо «всё украдено до нас (с)». И вы, получается, опять в проигрыше.

А вы вообще видели 1С-Управление торговлей и их код? Скачайте посмотрите. Там на порядок больше 25К строк кода, даже если не включать туда замаскированный в визуальное программирование код. Старое доброе процедурное програмирование с формированием SQL команд в строках.
Я бы рекомендовал вам, хотя бы примерно, вспомнить — а зачем вы придумали ту или иную фичу в вашем языке? И от этого вам станет яснее, какие конкретно преимущества вы ожидали, изобретая данный кусок языка. Ну а поняв, вы сможете указать другим — вот так вот делается быстрее потому что…

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

Так нет ни одного даже близко похожего языка. Еще раз, SQL — используется в полной мере, lsFusion — надстройка над ним. Как вы вообще представляете, вот разработчик пишет:
FOR selected(Item i) DO
price(i) < — price(i) + 1;
Выполнять это императивно очень неэффективно. Но это можно скомпилировать в:
price(Item i) < — price(i) + 1 WHERE selected(i); и выполнить одним UPDATE запросом.
При этом разработчик не в курсе ни про SQL ни про сервер БД ни про сервер приложений. Чист как лист. Какой язык вы сюда прикрутите? И это мы еще до логики представлений не дошли.
В общем — я бы сказал, что хотелось бы увидеть некую теоретическую базу, показывающую, что вы действительно сдвинули с места ту или иную проблему программирования, а не, в общем-то, рекламные слова про «среднюю ERP».

Собственно и в статье есть про теоретический базис, и на сайте есть 32 преимущества (со ссылками на документацию и how-to), и есть сравнение этих преимуществ со всем, что есть на рынке по каждому из этих 32 преимуществ, чего там еще не хватает?
Для примера — в функциональных языках привычной является функции типа fold, zip, которые агрегируют переданные в них данные, примерно как ваша конструкция GROUP, но отличие такое — эти функции можно написать самому, а не использовать библиотечные. То есть гибкость здесь в том, что не нужен новый язык для реализации важного алгоритма агрегирования данных. А у вас нужна новая конструкция, которую нельзя написать средствами языка. У вас гибкость, получается, заметно меньше.

А например, там еще есть GROUP LAST InvoiceDetail i ORDER number(i) BY invoice(i);
Которые на самом деле если есть индекс по number будет выполняться на SQL-сервере как SELECT LIMIT 1, а еще туда надо возможно предикат с invoice протолкнуть, чтобы субд не посчитал подзапрос для всей базы, а потом join'л. Как тут эти fold'ы и zip'ы помогут?
Как тут эти fold'ы и zip'ы помогут?

Через разбор дерева выражений. Дальше все то же самое.

Через разбор дерева выражений. Дальше все то же самое.

И чем тогда это лучше языка? С языком хотя бы completion проще прикрутить, да и язык читабельнее.

Собственно мы поначалу пытались, но реально порог вхождения сильно повышался. Люди, которые до этого в IT не были, реально не въезжали.
И чем тогда это лучше языка?

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


С языком хотя бы completion проще прикрутить, да и язык читабельнее.

Мне кажется, вы что-то другое понимаете под деревом выражений.


sum seq = seq |> fold ((acc, x) -> acc + x)


Вот то, что в скобках после fold — это дерево выражений, которое можно преобразовывать во что угодно по вашему вкусу. Хотите — преобразуете в SQL.

sum seq = seq |> fold ((acc, x) -> acc + x)


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

Это всего лишь вопрос привычки к синтаксису. Вот вам то же самое на чистом ванильном C# (там, правда, будет проблема со сложением, но мы сделаем вид, что ее нет): seq.Aggregate((acc, x) => acc.Plus(x))


Ну серьезно, для системных программистов допустим, но для прикладников

А "прикладники" пишут seq |> sum (ну или seq.Sum()), и у них все хорошо. До тех пор, пока им не надо написать какую-то вещь, которую вы на уровне базовой библиотеки не стали, и тогда они достают fold и пишут сложнее.


(Вообще, конечно, это весьма оскорбительное противопоставление)

То есть по вашему синтаксически:
seq.Aggregate((acc, x) => acc.Plus(x))

Лучше чем:
GROUP SUM seq(x)
Серьезно?

Да, привычнее, для большинства программистов работавших с функциональным программирования. но большинство «прикладников» пишут не seq |> sum, а на ABAP, 1C или на Delphi+Oracle/MSSQL. Во всяком случае на постсовке. И на западе ландшафт еще веселее, там всякие Cache, Progress и куча еще кого обитает и им такой синтаксис тоже не близок.

В любом случае та же группировка это вершина айсберга, с событиями, ограничениями и агрегациями что делать? И это еще до логики представлений не дошли.
То есть по вашему синтаксически: seq.Aggregate((acc, x) => acc.Plus(x))
Лучше чем: GROUP SUM seq(x)
Серьезно?

Нет, я этого не говорил нигде. Сравнивать надо seq.Sum() против GROUP SUM seq(x), и разница окажется исключительно вкусовой.


Нет, первое хорошо тем, что я могу написать


seq
.Aggregate(((sum, cnt), x) => (sum.Plus(x),cnt.Plus(1)))
.Select((sum, cnt) => sum/cnt)

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


с событиями, ограничениями и агрегациями что делать?

Разбираться по месту. Я отвечал на вопрос, как в случае использования ФВП решать проблемы оптимизации.

Разбираться по месту. Я отвечал на вопрос, как в случае использования ФВП решать проблемы оптимизации.

К сожалению, по моему опыту лида, «разбираться по месту» — это значит «иди к лиду/архитектору, пусть скажет как делать». А хочется, чтобы была четкая схема, по которой человек (не лид) сам знал как делать, не отвлекая более дорогих людей.
А хочется, чтобы была четкая схема, по которой человек (не лид) сам знал как делать, не отвлекая более дорогих людей.

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


Собственно, вопрос "ФВП против готовых агрегатов" — это тоже периода проектирования платформы, на этом промежутке еще нет людей, которые не "лиды/архитекторы".

Извините, но не очень понял — какой платформы? Можете все-таки примеры из жизни? То есть для разработки простенького бизнес-приложения, нужно сначала разработать платформу, а потом на ней само приложение?
Давайте может больше конкретики. Конкретные платформы, например.
Извините, но не очень понял — какой платформы?

Той самой, которая дает вам GROUP SUM.


То есть для разработки простенького бизнес-приложения, нужно сначала разработать платформу, а потом на ней само приложение?

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


Конкретные платформы, например.

Ваша, например. .NET, например.

Сравнивать нашу и .Net — это тоже самое, что сравнивать 1С и .Net. Как бы абсолютно разного уровня платформы для абсолютно разных разработчиков и целей. Вы согласны, что большинство 1С программистов вы не сможете переучить на .Net?
Назовите, пожалуйста, бесплатную высокоуровневую платформу (то есть где вам не надо заморачиваться общением клиента и сервера, сервера и базы данных) которую сможет освоить, грубо говоря, бизнес-аналитик?
Сравнивать нашу и .Net — это тоже самое, что сравнивать 1С и .Net.

А я их и не сравниваю. Вы просили привести пример платформы, чтобы было понятно, о чем я говорю, когда говорю о "разработке платформы" — вот вам пример. Не более того.


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

А почему, собственно?

Потому что именно это и является одним из преимуществ платформы lsFusion. Ее может освоить человек, который не может освоить .Net, так как она значительно проще. Это является конкурентным преимуществом. Разве нет?
Ее может освоить человек, который не может освоить .Net, так как она значительно проще.

Это утверждение, скажем так, нуждается в доказательстве. Но не суть.


Это является конкурентным преимуществом. Разве нет?

Да, простота в освоении является конкурентным преимуществом. Я с этим нигде не спорил. Я даже не спорю, что у lsFusion есть определенное количество преимуществ по сравнению с .NET.

Допустим, в lsFusion мне не нужно


заморачиваться общением клиента, сервера и базы данных.

Значит ли это также и то, что я не могу этим заморочиться, так как эти процессы не находятся вне моего контроля?

У вас есть определенные рычаги управления. Например, можно задавать каким образом логика будет отображаться в базу данных. Тут точно также, как вы не можете напрямую влиять на планы выполнения запросов в базе данных, но в некоторых можете давать hint'ы.

И в целом Вы конечно можете всегда напрямую обратиться к базе данных через EXTERNAL или из Java кода через JDBC и делать что хотите под свою ответственность.
У вас есть рычаги, но более высокоуровневые. Скажем в базе вы управляете материализацией свойств (определяете, что хотите хранить, а что хотите — вычислять), и раскладыванием их по таблицам (можете вообще все свойства в одну таблицу положить, а можете наоборот каждое свойство в отдельную) и индексами. Плюс есть хинты всякие, но они остались от древних времен, когда оптимизаторы не были настолько умными, поэтому мы их пока даже в документации не описывали, но может в будущем опишем (логика такая же как в хинтах СУБД)

Что контролировать в общении клиента и сервера у меня пока фантазии не хватает. Ну общаются и общаются. Все сделано так что максимум один round-trip, особо улучшать некуда. Есть пару мелких настроек с асинхронностью впрочем, но ничего особенного.

Ну и всегда Java в вашем распоряжении, на ней все что угодно реально бесшовно подключается во все стороны и смотрится как родное.
Нет, я этого не говорил нигде. Сравнивать надо seq.Sum() против GROUP SUM seq(x), и разница окажется исключительно вкусовой.

Ок, а как h(y) = GROUP SUM seq(x) IF g(x) = y будет выглядеть?
Нет, первое хорошо тем, что я могу написать

Ок, тут это будет выглядеть как:
(GROUP SUM seq(x))/(GROUP COUNT seq(x))
И хоть это не самый оптимальный пример для lsFusion, все равно проще. И выполняться он будет одним запросом / подзапросом (платформа их сольет в один).
Разбираться по месту. Я отвечал на вопрос, как в случае использования ФВП решать проблемы оптимизации.

Я имел ввиду с точки зрения синтаксиса, этих абстракций в других языках в принципе не существует.
Ок, а как h(y) = GROUP SUM seq(x) IF g(x) = y будет выглядеть?

h y seq = seq |> filter (x => g(x) == y) |> sum


Ок, тут это будет выглядеть как:

Угу. А теперь fold ((agg, x) => agg*x). Всегда будет операция, которую вы не предусмотрели.


этих абстракций в других языках в принципе не существует

Ограничения точно есть (см. design by contract). Остальное, если его нет, реализовывать как абстракцию платформы (у вас, в общем-то, тоже, не понятно, это функциональность языка или платформы).

h y seq = seq |> filter (x => g(x) == y) |> sum

А теперь возьмите человека «с улицы» и попробуйте ему объяснить это по сравнению с:
h(y) = GROUP SUM seq(x) IF g(x) = y
Вы очень сильно удивитесь.
Угу. А теперь fold ((agg, x) => agg*x). Всегда будет операция, которую вы не предусмотрели.

А как вы ее в SQL выполнять собрались?
Ограничения точно есть (см. design by contract). Остальное, если его нет, реализовывать как абстракцию платформы (у вас, в общем-то, тоже, не понятно, это функциональность языка или платформы).

Ограничения именно в виде, что заданная функция должна всегда должна возвращать NULL? Поймите в высокоуровневых абстракциях реально с языком проще. Это нормально, человек привык к языку, он его использует в каждодневной жизни в конце концов.
А теперь возьмите человека «с улицы» и попробуйте ему объяснить это по сравнению с:

Меня не очень интересуют люди с улицы. Точнее даже совсем не интересуют.


А как вы ее в SQL выполнять собрались?

Во-первых, не собирался, в этом и прелесть. Во-вторых, курсором.


Ограничения именно в виде, что заданная функция должна всегда должна возвращать NULL?

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

Меня не очень интересуют люди с улицы. Точнее даже совсем не интересуют.

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

Ну то есть все данные загоняем на сервер приложений и там вычисляем итерируясь по одному? У меня для вас плохие новости. Курсор тоже самое сделает на сервере БД, и думаете это сильно лучше?
Нет, ограничения в виде «данное условие всегда должно быть верно». Что, заметим, намного понятнее в терминах естественного языка.

Согласен. Но это когда у вас ровно одно значение, тогда можно ограничивать что условие всегда верно. Но когда у вас есть параметры у условия, то нельзя ограничивать, что для всех существующих параметров условие должно быть верно (так как количество всех возможных параметров бесконечно). Можно только ограничивать что ни для одного из существующих параметров данное условие не будет верно. Хотя к нашему спору про Language vs Library это имеет мало отношения.
Вам повезло, а если бы вам надо было сводить бюджет расхода с расходами и рисками, очень бы интересовало.

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


Ну то есть все данные загоняем на сервер приложений и там вычисляем итерируясь по одному?

Не все, а нужное поле. Не все, а батчами, которые влезают в память.


У меня для вас плохие новости.

У вас нет для меня новостей хуже, чем "этот расчет нужно выполнить". Его все равно нужно выполнить, вопрос только в том, как я его запишу.


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

Мне казалось, "ни для одного из существующих параметров данное условие не будет верно" превращается в "для всех существующих параметров условие будет верно" операцией отрицания.


Возьмем, чтобы далеко не ходить, ваш же пример:


CONSTRAINT hostTeam(Game team) = guestTeam(team)

Достаточно написать Invariant(hostTeam(Game team) != guestTeam(team)), все равно вам надо проверять "при изменении у игры команды хозяев или команды гостей [...] условие равенства этих команд".


Или я что-то упускаю?

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

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

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

Вообще говоря, не совсем. Дело в том, что NOT hostTeam(game)=guestTeam(game), это не тоже самое что hostTeam(game)!=guestTeam(game). Если у вас guestTeam(game) — NULL, то первое условие вернет TRUE так как hostTeam(game)=guestTeam(game) это NULL (все операторы сравнения возвращают NULL когда один из операндов NULL), а hostTeam(game)!=guestTeam(game) вернет NULL (по той же причине).
Фактически NOT hostTeam(game)=guestTeam(game) — TRUE для всех game которые не IS Game (например если в game передать Team). Тут конечно может возникнуть обманчивое впечатление, что раз задан класс параметра то NOT hostTeam(Game game) = guestTeam(game) должен проверять на то что game IS Game, но это не так. Фактически класс параметра это чисто фишка resolve'га (поиска свойства при парсинге) на сами вычисления он никак не влияет (собственно платформа кроме поиска этот класс никак не использует), то есть в lsFusion смешанная типизация — хочешь задавай класс хочешь нет (мы кстати первые лет 7 во всех проектах работали на неявной типизации, потом перешли на явную). Этот момент меня самого немного смущает, и возможно в будущих версиях мы все же сделаем что указание класса будет неявно добавлять IF game IS Game.
Ну значит ваши наниматели нашли «жирные» проекты, где заказчики готовы платить много и без особых претензий.

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


SQL по идее это может выполнить гораздо эффективнее.

Прекрасно. Напомню, что все началось с (вашего же!) вопроса "как это на SQL считать". Если может — будет посчитано на SQL.


все операторы сравнения возвращают NULL когда один из операндов NULL

Это у вас так. А в других языках совершенно не обязательно так.


Фактически NOT hostTeam(game)=guestTeam(game) — TRUE для всех game которые не IS Game

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

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

А вы вообще много языков знаете, где можно бегать по всем не NULL значениям функции? Это я к assertion'ам для функций с параметрами, а не просто для значений.
Только не надо приводить в пример приводить dbContext.table, потому что здесь уже я начну придираться, что это особенность платформы, а не языка.
А вы вообще много языков знаете, где можно бегать по всем не NULL значениям функции?

Я даже не знаю, что вы имеете в виду, что уж говорить о языках.


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

А смысл? Мы уже выяснили, что у вас это неразделимые вещи.

Я даже не знаю, что вы имеете в виду, что уж говорить о языках.

Ну допустим вы объявили f(a,b) в каком-то синтаксисе. Чтобы потом можно было сделать:
FOR f(a,b) DO
MESSAGE a + ',' + b + '->' + f(a,b);
А смысл? Мы уже выяснили, что у вас это неразделимые вещи.

Ну вы утверждали что в других языках есть похожие на ограничения абстракции. Я сказал что для этой абстракции нет аналогов в других языках, потому как для этой абстракции нужна операция итерации по всем не null значениям функции, а ее в других языках нет. И тут вы могли бы исхитриться и привести в пример dbContext.orders.Sum(). На что уже я бы возразил что это не часть языка.

Чтобы потом можно было сделать:
FOR f(a,b) DO
MESSAGE a + ',' + b + '->' + f(a,b);

Я, опять-таки, не понимаю, что это должно сделать (это, кстати, иллюстрация к понятности декларативного синтаксиса).


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

Для абстракции — не нужна, в том-то и дело. Для ее конкретной реализации — возможно.

Я, опять-таки, не понимаю, что это должно сделать (это, кстати, иллюстрация к понятности декларативного синтаксиса).

Пробежать по всем не NULL значениям. Ну то есть на реальных примерах.
FOR selected(team) DO
     MESSAGE 'You selected ' + name(team);
FOR invoice(invoiceDetail) = invoice DO
     MESSAGE 'This invoice detail '+invoiceDetail+'  is in ' + invoice;

Странно конечно, при обучении вот с чем с чем, а с пониманием итерации по всем значениям функции проблем не было. Не композиция конечно, но и не рекурсия.
Для абстракции — не нужна, в том-то и дело. Для ее конкретной реализации — возможно.

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

Вот есть функция f(x, y) = x+y, где x, y — целые числа. Множество ее значений — все целые числа, NULL там нет. Что такое "пробежать по всем значениям"?


FOR selected(team) DO
     MESSAGE 'You selected ' + name(team);

Если selected — это функция, возвращающая множество, то вы описали тривиальный итератор, которых в языках навалом. И?..


Странно конечно, при обучении вот с чем с чем, а с пониманием итерации по всем значениям функции проблем не было.

Это еще одна иллюстрация к вопросу о том, можно ли объективно определить простоту обучения чему-то.


А вы много знаете абстрактных языков, то есть без единой их реализации?

Вы первым начали разговор об абстракциях.

Вот есть функция f(x, y) = x+y, где x, y — целые числа. Множество ее значений — все целые числа, NULL там нет. Что такое «пробежать по всем значениям»?

В этом случае, платформа выдаст сообщение что количество значений бесконечно. Как и в случае скажем при итерации по sum:
sum(d) = GROUP SUM sum(invoice) IF date(invoice) < d;
FOR sum(d) DO // будет ошибка
MESSAGE 'D: ' + d;

Но при этом скажем
// пробежит во всем sku для которых определена последняя дата поставки
FOR sum(lastSuppliedDate(sku)) DO
MESSAGE 'Sum of all invoices before last supplied date for sku : ' + name(sku) + ' is : ' + sum(lastSuppliedDate(sku));

Можно кстати написать хитрее:
FOR s=sum(lastSuppliedDate(sku)) DO
MESSAGE 'Sum of all invoices before last supplied date for sku : ' + name(sku) + ' is : ' + s;

То есть если операцию теоретически можно выполнить она выполнится.
Если selected — это функция, возвращающая множество, то вы описали тривиальный итератор, которых в языках навалом. И?..

Нет selected это не функция возвращающая множество это обычная функция возвращающая значение, то есть например:
selected = DATA BOOLEAN (Team); // вводится
// вычисляется
selected (Team t) = countPlayers(t) > 5;

Вы первым начали разговор об абстракциях.

Ок, замените слово абстракция в этих предложениях на понятие или термин, и перечитайте заново.
В этом случае, платформа выдаст сообщение что количество значений бесконечно [...] Но при этом [...] пробежит во всем sku для которых определена последняя дата поставки

Вот я про это и говорю: я не понимаю, что вообще вы имеете в виду. Вот есть запись FOR f(x) DO. Что в ней такое x? Просто идентификатор, на который потом можно ссылаться? Или что?


Нет selected это не функция возвращающая множество это обычная функция возвращающая значение

Тогда извините, но значений у этой функции ровно два: true и false. Так что вы явно имеете в виду итерацию не по значениям функции, а по чему-то другому.


Ок, замените слово абстракция в этих предложениях на понятие или термин, и перечитайте заново.

А ничего не изменится. Для понятия "ограничение" (или "инвариант", что то же самое, судя по вашим описаниям) не нужна "операция итерации".

Тогда извините, но значений у этой функции ровно два: true и false. Так что вы явно имеете в виду итерацию не по значениям функции, а по чему-то другому.

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

Рассмотрим функцию f(x), где x — целое число. Как это сделать? Теперь возьмем x как строку. Что-то изменилось? Теперь возьмем x как пользовательский тип. Что-то изменилось?

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

Эм.


Пример №1: type Login: string. Простейший пользовательский тип (фактически, просто синоним), имеющий все поведение строки. Что будет, если "итерироваться по всем наборам аргументов" функции len(x), где x имеет тип Login?


Пример №2: type Coord {int x, int y}. Тоже очень простой пользовательский тип. Что будет, если "итерироваться по всем наборам аргументов" функции dist(x, y), где x и y имеют тип Coord?

Второй случай в lsfusion будет выглядеть так:
CLASS Coord;
x(Coord c) = DATA INTEGER(Coord);
y(Coord c) = DATA INTEGER(Coord);

dist(Coord x, Coord y) = ...;

Итерация пойдет по всем парам существующих объектов класса Coord для которых dist не NULL. То есть в нашем случае (если мы в dist просто берем евклидову норму) для тех объектов, для которых x и y установлены не в NULL.

По первому примеру не совсем получится один в один, потому что у нас нельзя наследовать пользовательские классы от встроенных (в нашей терминологии строковые типы — встроенные). У нас это будет класс Login + свойство, принимающее на вход объект этого класса и возвращающее строку. Ну и итерация пойдет по всем объектам класса Login, у которых это свойство задано (в предположении, что len — это вычисляемое свойство, возвращающее длину строки, если строка не NULL).
Итерация пойдет по всем парам существующих объектов класса Coord

Что такое "существующие объекты"? Почему можно итерироваться по всем "существующим объектам" для координат, но нельзя итерироваться по всем "существующим объектам" для целых чисел (хотя вторых меньше чем первых)?

Что такое «существующие объекты»?

Созданные ранее объекты класса. В статье есть немного информации по операторам NEW/DELETE. Грубо говоря, объект в нашем случае — это запись в таблице БД (а, например, DATA-свойства — поля). Итерироваться мы будем по лежащим в базе объектам класса Coord (и их конечное число). На пустой базе при первом старте системы их будет 0, к примеру.
Итерироваться мы будем по лежащим в базе объектам класса Coord

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


И тогда это все сводится к банальному map: db(Coord) |> map f (ну или Db<Coord>.Select(f), если вам трубы не нравятся). И это, да, достаточно тривиальный (по нынешним меркам) итератор.

Не ко всем объектам, а только к тем объектам, для которых свойство не равно NULL. И речь не только про одиночный объект, где все довольно тривиально, а про наборы (кортежи) объектов, если у свойства больше одного параметра. Да, и объекты при этом могут лежать в разных таблицах (иерархии классов). Тут Select будет уже не такой простой.
Не ко всем объектам, а только к тем объектам, для которых свойство не равно NULL.

Вы не поверите:


db(Coord) |> choose f

При этом если choose нет, его легко написать:


def choose f = map f >> filter Option.isSome

Тут Select будет уже не такой простой.

Вот ровно для этого и полезна композиция функций.


Но речь-то о том, что ничего принципиально невозможного, сложного или магического нет, не более чем синтаксический сахар.

Я понял, что сам увел обсуждение не в ту степь. Предлагаю пока забыть то, что я писал про записи в таблицах, это физическая модель, детали реализации. В lsfusion можно проитерироваться по всем объектам любого пользовательского класса. Можно ли, например, в C# проитерироваться по всем «живым» объектам, к примеру, класса System.IO.File?
Можно ли, например, в C# проитерироваться по всем «живым» объектам, к примеру, класса System.IO.File?

Нет, потому что там нет концепции "живого объекта" — в общем случае она бессмысленна: например, что конкретно понимать под "живым" объектом класса System.IO.File, и что будет служить identity этого объекта?


Однако, если речь идет об экземплярах конкретного подмножества типов (а у вас сделана именно такая оговорка), это несложно реализовать.

>> сам увел обсуждение не в ту степь

Ну почему же? Вы как раз наглядно показали корни вашей системы. Всё началось с активной работы с БД, далее вам захотелось «расширить и углубить (с)», ну и вы начали сочинять навороты вокруг стандартной реляционной модели, использующей под капотом довольно сложные алгоритмы для выполнения запросов и эффективного хранения данных на диске. В итоге получилась надстройка над SQL, которая в SQL же и конвертируется (как я понял). Отсюда все эти абстрактные заявления про «множество объектов» по которым что-то «пробегает». На самом же деле речь идёт о банальном выполнении селектов по таблицам, возможно in memory tables, но суть-то не меняется.

Вот начали бы вы описание языка именно с такой подачи — это простая настройка над БД, транслирующая наш псевдо-код в SQL выражения и работающая с данными из БД неявным образом. Далее же надо показать — зачем вы прячете от разработчика всё то, что получается в результате трансляции в селекты. Этим вы убиваете понимание происходящего, но что вы при этом добавляете? Мне это совершенно непонятно. Минус (огромный) вижу. Плюсы — сомнительны.
Ага, а SQL это простая настройка над машинным кодом транслирующая ваш псевдо-код в машинные инструкции. И зачем он прячет все эти машинные инструкции от разработчика, убивая понимание как это работает. Этим вы убиваете понимание происходящего ну и т.д.
Про работу SQL знают все, а про работу вашей платформы — ну человек 10 знают. Поэтому вы всё прячете, а SQL ничего не прячет. Просто сравните количество людей, сходу понимающих суть SQL и вашего языка.
Про работу SQL знают все

Издеваетесь? Вы вообще в курсе, что там под штук 40 разных типов узлов плана? Я уверен что даже вы их не знаете. Абсолютное большинство SQLем как большим черным ящиком пользуются.
Просто сравните количество людей, сходу понимающих суть SQL и вашего языка.

Я сравнивал, когда пытался людям из не IT в мониторе процессов объяснять, что что это за магическое заклинание, и что такое таблицы и JOIN'ы. Они смотрели на меня как баран на новые ворота, что за херню я им втираю.
>> Вы вообще в курсе, что там под штук 40 разных типов узлов плана?

Ну не надо так страшно пугать. Если встретились с незнакомым алгоритмом джойна — читаем доку и через пол-часика оптимизируем без проблем. Главное — общее понимание процесса.

>> Я сравнивал, когда пытался людям из не IT…

Ну вам всегда нужны уточнения типа «берём выборку из всё-таки хоть как-то причастных людей»?
Вот есть запись FOR f(x) DO. Что в ней такое x? Просто идентификатор, на который потом можно ссылаться? Или что?

Угадали. Параметр f, на который потом можно ссылаться.
Тогда извините, но значений у этой функции ровно два: true и false. Так что вы явно имеете в виду итерацию не по значениям функции, а по чему-то другому.

Да ровно два true и null. И в платформе можно проитерироваться по всем значениям, для которых эта функция true. А можно просто ее вызвать.
А ничего не изменится. Для понятия «ограничение» (или «инвариант», что то же самое, судя по вашим описаниям) не нужна «операция итерации».

Для реализации нужна. Для определения возможно и нет. Мы же это уже выяснили вроде.
И в платформе можно проитерироваться по всем значениям, для которых эта функция true.

Нельзя, если xint. Ну, если верить вашим словам.


Но самое важное уже обсудили выше: это ничем не отличается от применения функции к множеству, просто у вас это множество имплицитно и предоставляется платформой.


Для реализации нужна.

Для вашей реализации. Для других — не обязательна.

Нельзя, если x — int. Ну, если верить вашим словам.

Можно, там человек не совсем правильно выразился. На самом деле нужно чтобы множество было конечно.
То есть например вот такая штука работает:
iterate(i,from,to) = RECURSION i=from STEP i=$i+1 AND i<=to;
FOR iterate(i, 1, 5) DO
MESSAGE i;

Хотя здесь i — int;
В принципе я думаю в ближайших версиях сделаем, чтобы и эта штука работала:
FOR i >= 1 AND i <= 5 DO
MESSAGE i;

Для вашей реализации. Для других — не обязательна.

Я честно не знаю как это реализовывать без такой операции. Даже теоретически не представляю. Как только увижу такую реализацию, сразу признаю что не прав. Готов съесть то, что скажете.
Но самое важное уже обсудили выше: это ничем не отличается от применения функции к множеству, просто у вас это множество имплицитно и предоставляется платформой.

Ценю вашу тягу к формализмам, но жизнь на этом рынке заставила меня стать практиком и использовать более простые понятия. Быть ближе к людям так сказать. :)
Можно, там человек не совсем правильно выразился.

"В этом случае, платформа выдаст сообщение что количество значений бесконечно". Помните, кто это сказал?


Я честно не знаю как это реализовывать без такой операции. Даже теоретически не представляю.

Ну вы на Code Contracts посмотрите, например. Или, хотя бы, на CONSTRAINT в обычной РСУБД.


жизнь на этом рынке заставила меня стать практиком и использовать более простые понятия

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

«В этом случае, платформа выдаст сообщение что количество значений бесконечно». Помните, кто это сказал?

Да, но это не привязано к тому примитивный или объектный параметр. Точнее так с примитивным параметром количество значений может быть как конечным, так и бесконечным. С объектным кстати тоже NOT hostTeam(game) — TRUE на бесконечном множестве значений и FOR по нему выдаст ту же ошибку.
Ну вы на Code Contracts посмотрите, например. Или, хотя бы, на CONSTRAINT в обычной РСУБД.

Они только на первичные данные (поля) работают. CONSTRAINT на View нельзя повесить, как и Validation на любой метод.
Дадада, «бегать по всем значениям функции» — это намного более простое понятие, чем «вычислить значение функции для всех элементов множества». А главное, можно делать вид, что это уникальная возможность.

Ок, вычисление множества всех не NULL значений любой функции — уникальная возможность?
Они только на первичные данные (поля) работают.

Ну да. И что?


Ок, вычисление множества всех не NULL значений любой функции — уникальная возможность?

Смотря как оно сделано. Если перебором значений параметров, то это весьма тривиально. Если анализом кода — то интересно, но я все равно не думаю, что уникально.


А у вас как?

Ну да. И что?

То что они работают в одном небольшом частном случае вас не смущает.
Смотря как оно сделано. Если перебором значений параметров, то это весьма тривиально. Если анализом кода — то интересно, но я все равно не думаю, что уникально.

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

Нет, не смущает. Code Contracts работают в большем числе случаев.


Конечно не перебором, издеваетесь что ли?

Да нет, не издеваюсь.


Вот у вас есть функция f(x) = md5(x). Как именно вы определите множество ее значений?

Вот у вас есть функция f(x) = md5(x). Как именно вы определите множество ее значений?

Дискуссия идёт к вопросу о майнинге криптовалюты, но мы не про такие вычисления)

Ну то есть все-таки нет "вычисления множества всех не NULL значений любой функции".

Ну если запрограммируете это дело, то есть шанс завалить Золотого Тельца, мы не брались

Так все-таки, есть в lsFusion "вычисление множества всех не NULL значений любой функции", или нет?

Так все-таки, есть в lsFusion «вычисление множества всех не NULL значений любой функции», или нет?

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

Функция md5(x) — дискретная?

Функция md5(x) — дискретная?

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

Прекрасно. Из этого вытекает, что в lsFusion есть «вычисление множества всех не NULL значений» ее значений. Правильно?

Не вытекает, по причине отсутствия этой функции md5 (что там у нее внутри) в перечне реализованных.
Вот вам инструмент комбинаторного программирования, реализуете на нем нужную вам функцию, тогда получите результат. Перечень уже реализованных функций, есть в документации. А для ряда практических примеров мы опубликовали исходные коды разных приложений типа ERP, там тоже многое готово.
Не вытекает, по причине отсутствия этой функции md5 (что там у нее внутри) в перечне реализованных.

Эм. В вашей замечательной платформе нет простой хэш-функции? Никакой?


Ладно, а substring у вас есть?

Нет, не смущает. Code Contracts работают в большем числе случаев.

Но все равно по сути с field'ами. А первичных данных обычно хорошо если 5% в сложных системах.
Вот у вас есть функция f(x) = md5(x). Как именно вы определите множество ее значений?

Текст функции md5? Ну вы же помните, что она на том же языке написана? В смысле что lsFusion не телепат и не AI и не умеет бегать по функциям написанным на другом языке (тут не тот случай как в дне независимости где хакер к незнакомой системе за ночь вирус смог написать).
Но все равно по сути с field'ами.

Не обязательно.


Текст функции md5?

Вот вам псевдокод.

Не обязательно.

Ok, я написал:
f(a) {
int x = 0;
for(int i=0;i<5;i++)
x+= g(a, i);
return x;
}

Я могу валидатор повесить на f, что он всегда должен быть больше 0?
Вот вам псевдокод.

Ну вы же помните, что она на том же языке написана?

Но такой на lsFusion вполне инкрементит, чисто с виду его на группировках, рекурсиях не так сложно реализовать.
Я могу валидатор повесить на f, что он всегда должен быть больше 0?

Да.


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

Прекрасно. Так как же получить множество значений этой функции?

Я все-таки еще раз влезу. Уже целая куча сообщений в этой ветке из-за непонимания друг друга. Дело в том, что когда NitroJunkie написал «множество всех значений функции» имел он ввиду все-таки (если я не прав, то скажи) все то же множество всех наборов аргументов, для которых функция определена (ее значение от этих аргументов не равно NULL). Область определения функции, если угодно.
множество всех наборов аргументов, для которых функция определена (ее значение от этих аргументов не равно NULL)

Эгм. Давайте с конца.


ее значение от этих аргументов не равно NULL

В этом смысле функция md5 (как и любая хэш-функция вообще) очень проста: ее значение никогда не NULL. А теперь вернемся к вопросу: как будет вычисляться это самое "множество всех наборов"?


А теперь на шаг раньше.


для которых функция определена

А почему, собственно, функция считается неопределенной, если она возвращает NULL? Или это опять такое умолчание, принятое в lsFusion просто потому, что оно там принято?

Да.

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

Мне тут правильно подсказали, что я видимо не совсем правильно сформулировал, имеется ввиду множество значений параметров функции для которых она не null. Хотя множество значений при этом естественно тоже можно получить. В данном случае она не null для всех натуральных чисел. Хотя пример конечно дурацкий.
она будет определять что для какого то значения параметра f изменилось?

Вот когда этот "параметр" меняется, тогда и будет проверяться.


(Ну, я так предполагаю, конечно, я сам не работаю с контрактами, не привязанными к аггрегату, ибо смысла нет)


Мне тут правильно подсказали, что я видимо не совсем правильно сформулировал

Это не избавляет нас от вопроса как же.

Вот когда этот «параметр» меняется, тогда и будет проверяться

Как это параметр может меняться? Меняться только field'ы могут, или я что-то про c# не знаю.
Вы с ней не работали, а я даже не представляю как она теоретически может работать, но вы точно уверены что возможность есть.
Как это параметр может меняться?

Легко.


Меняться только field'ы могут, или я что-то про c# не знаю.

Изменение поля — изменение объекта, такая вот суровая боль в языках с мутабельностью.


я даже не представляю как она теоретически может работать

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

Изменение поля — изменение объекта, такая вот суровая боль в языках с мутабельностью.

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

А оно работает. Вешаете CONSTRAINT на вычисляемую функцию и он работает. Могу рассказать как, но это не очень тривиально.
Вообще любое поле изменяется, и все-все validator'ы запускаются?

Если вам нужны полные контракты — да, именно так.


(ну то есть на самом деле, я не удивлюсь, если там уже прикрутили трекинг зависимостей, благо анализ дерева есть, но гарантия остается неизменной)


А оно работает.

Вы пока так и не рассказали, как же вычисляется множество всех аргументов, для которых md5 не равно NULL.

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

Может еще все и в SQL умеет транслировать? Тогда я не удивлюсь, если она еще и мысли читать научилась.
Вы пока так и не рассказали, как же вычисляется множество всех аргументов, для которых md5 не равно NULL.

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

Нет, не умеет. Оно существует на том уровне платформы, где SQL не считается данностью.


Я вам больше того скажу, я последние полтора года SQL в своих задачах обычно вижу в формате "давайте перельем данные из РСУБД туда, где нам удобно с ними работать", и на этом его роль заканчивается.


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

На таком уровне это неуникальная возможность.


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

Нет, не умеет. Оно существует на том уровне платформы, где SQL не считается данностью.

Зашибись аргумент. То есть в жизни использоваться не может. То есть можно считать, что такой возможности нет. Так и запишем.
Я вам больше того скажу, я последние полтора года SQL в своих задачах обычно вижу в формате «давайте перельем данные из РСУБД туда, где нам удобно с ними работать», и на этом его роль заканчивается.

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

Будем формировать SQL запросы. Например как в задаче про 2*. Такой ответ устроит?
То есть в жизни использоваться не может.

Может. Жизнь не ограничивается SQL.


Ну это потому что вы с нормальными взрослыми бизнес-приложениями не сталкивались

Вы не знаете, с чем я сталкивался, а с чем — нет.


Будем формировать SQL запросы.

Ну то есть, в итоге, перебором множества аргументов. О чем и шла речь.

Вы не знаете, с чем я сталкивался, а с чем — нет.

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

Нет, как минимум, если там внутри композиции к примеру есть, будут индексы использоваться. А на самом деле там дохрена оптимизаторов, как у lsFusion сверху, так и у SQL внизу.
Ну это я сделал вывод по тому, что вы считаете что SQL это так, какая та маленькая часть IT.

Я этого не говорил.


Нет, как минимум, если там внутри композиции к примеру есть, будут индексы использоваться.

Это если они применимы. Дальше начинаются оговорки.

Вешаете CONSTRAINT на вычисляемую функцию и он работает.

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


Как в вашей системе выражается ограничение "пользователь не может иметь пароль, входящий в блеклист"?

CONSTRAINT password(User u) == password(BlackListItem item) MESSAGE 'пользователь не может иметь пароль, входящий в блеклист'

Этот констрейнт проверяется как-то иначе, нежели "при добавлении или изменении пароля пользователя проверить, есть ли такой пароль в блеклисте" (ну то есть в хорошем случае — индекс, в плохом случае — перебор)?


(ну и понятно, что симметрично для добавления пароля в блеклист)

Хотя нет, я на самом деле, не прав, «симметрично» нельзя — добавление пароля в блеклист должно происходить вне зависимости от того, есть ли такие пароли у пользователей, так что проверка должна быть односторонней. Так можно сделать?


(понятно, что в полном бизнес-сценарии еще есть «если после добавления пароля в блеклист выяснилось, что есть пользователи с таким паролем, нужно инициировать для них процедуру сброса пароля», но это явно не ограничениями делается)

Да, можно.
CONSTRAINT CHANGED(password(User u)) AND password(u) = password(BlackListItem item) MESSAGE 'пользователь не может иметь пароль, входящий в блеклист'
Можно наверное прикольнее:
CONSTRAINT p=CHANGED(password(User u)) AND p = password(BlackListItem item) MESSAGE 'пользователь не может иметь пароль, входящий в блеклист'
Но это уже синтаксические развлечения.

Кул. Вопрос "как проверяется этот констрейнт" остается.

Там все не так просто, но если совсем грубо на пальцах во втором случае при изменении password'а (например для нескольких пользователей), будет делаться SELECT JOIN таблицы изменений пароля с таблицей черного списка. Это если самый простой случай все первично. Понятно, что password может быть вычисляемым от других свойств, лежащих в разных таблицах и т.п., тогда запрос будет сложнее, но магия как раз в том, что тому кто делает этот CONSTRAINT фиолетово.

Ну то есть так и есть: для каждого измененного пароля мы перебираем (умнее или тупее) черный список.


магия как раз в том, что тому кто делает этот CONSTRAINT фиолетово.

Проблема этой магии в том, что одно (разумное!) изменение бизнес-требований делает эту операцию из O(k log n) (где k — число паролей для проверки, n — число паролей в черном списке), или даже немного лучше, если вы умеете делать "хорошие" индексы по строкам, в O(kn). Но это да, фиолетово.

Ну то есть так и есть: для каждого измененного пароля мы перебираем (умнее или тупее) черный список.

Нет это делается одним запросом с JOIN. Никакого FOR'а нет.
Проблема этой магии в том, что одно (разумное!) изменение бизнес-требований делает эту операцию из O(k log n) (где k — число паролей для проверки, n — число паролей в черном списке), или даже немного лучше, если вы умеете делать «хорошие» индексы по строкам, в O(kn). Но это да, фиолетово.

А добавив материализацию и индекс (в одно слово), если это вдруг понадобится, оно опять вернется в O(k log n). Но это уже проблема не разработчика, а платформы, или в крайнем случае «db-администратора» (который может быть один на весь проект). Но не разработчика, который про все эти ваши O вообще не знает и знать не обязан.

И там кстати не kn, k+n или k logn + n.
Нет это делается одним запросом с JOIN. Никакого FOR'а нет.

Эмм. Вы так говорите, как будто JOIN — это не перебор.


А добавив материализацию и индекс (в одно слово), если это вдруг понадобится, оно опять вернется в O(k log n)

Неа. Вы даже не спросили, какое изменение, а уже говорите, что его можно реализовать.


Но не разработчика, который про все эти ваши O вообще не знает и знать не обязан.

Это и беда. Он не знает, и пишет код, а код кладет систему.


И там кстати не kn, k+n или k logn + n.

Вы, повторюсь, еще не знаете, что за изменение, но уже уверенно говорите, чего оно стоит.

Эмм. Вы так говорите, как будто JOIN — это не перебор.

ну в общем случае не перебор, если, например, существует индекс. То есть я имею в виду, не перебор по обоим таблицам, по одной таблице всё равно пробежать придётся.

Но, конечно, все что сделано через джойн, можно написать императивно — можно написать цикл и в цикле перебор массива o(n*k), а можно написать цикл и в цикле поиск по хеш таблице, например (o(n*logk)
Я бы сказал, что в 95% случаев, если это перебор, то там явно нужен индекс

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

Не очень понятно, кого вы сейчас хотели показать профнепригодным — себя, если считаете, что fold/reduce есть удел «системных программистов», или своих разработчиков, которые по вашим словам не в состоянии понять этот псевдокод. Но кого-то точно хотели.

Еще раз у нас разработчики практически без IT-бэкграунда, они ни про функциональное программирование, ни про SQL не слышали (ну может кто-то слышал, но ни разу близко не подходили).

И как думаете какой синтаксис им будет очевиднее / удобнее? (я сейчас про пример с GROUP SUM seq(x) сверху)
И как думаете какой синтаксис им будет очевиднее / удобнее?

Тот, которому научат.

Вопрос в сложности и возможности этого обучения.

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

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

Этот эксперимент хоть сколько-нибудь валиден только в том случае, если у вас были одинаково способные преподаватели для обоих языков (и одинаковые все прочие условия, включая мотивацию).

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

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

И что за фактор? Одинаково способные преподаватели? Okm можно расширить тест до 5 условных преподавателей, обучающих 100 условных человек. Такой тест да сложнее провести, но это же не повод это не сделать это, хотя бы умозрительно. Но да результаты будут более субъективными.
И что за фактор? Одинаково способные преподаватели?

Именно.


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

Гм. Умозрительно? И как же мы будет выяснять, результаты чьего умозрительного теста более валидны, вашего или моего?


Но да результаты будут более субъективными.

Это ровно то, о чем я сказал раньше.

>> Там на порядок больше 25К строк кода

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

Трансляция в SQL, конечно, местами сокращает код, но это работает лишь до момента, когда потребуются усложнения в алгоритмах. Поэтому вторая часть «25к строк» — предметная область и её сложность. Они опять не заданы. Хотя есть намёк на тип «учётная система», для которой (особенно ради выигрыша в неких абстрактных соревнованиях, а не для реального предприятия) можно наваять ТЗ, предполагающее лишь примитивные селекты да апдейты, что наверняка хорошо ложится в ваш язык. Но если, внезапно, заказчику нужна сложная логика?

>> Фактически мы строили самолет в воздухе вместе с пассажирами

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

>> Выполнять это императивно очень неэффективно

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

>> Собственно и в статье есть про теоретический базис

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

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

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

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

Нет, именно 25к, которая работает на реальных предприятий. Причем преприятиях с претензиями. Большими претензиями. И там как раз фокус в том, что формируются не простые апдейты, а такие запросы, которые вы руками не сможете написать. Если интересно, откройте исходники ERP и посмотрите насколько там простая логика.
Это не самый удачный подход. Надо хотя бы иногда сажать самолёт и тщательно рассматривать все его составляющие. Ну и улучшать, включая крупные изменения, типа замены крыла на вертолётный винт. Заказчик будет против? Ну ладно, только тогда не стоит говорить о качестве.

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

Функциональное, логическое и императивное это как теплое, мягкое и квадратное. Но если говорить общими терминами то этот язык — это скорее комбинаторное, реактивное, логическое и событийное программирование. Функционального в нем как раз очень мало.
Да, кстати, декларативный стиль — это именно стиль.

Декларативный стиль — это метрика того насколько язык высокоуровневый. То есть на насколько сложных абстракциях он строится.
>> а таких задач в реальной жизни меньше 2%

Доказать сможете? Если доказательством опять будет ссылка на реализованный проект на вашем языке, то подскажу — вы встроили в платформу те встретившиеся алгоритмы, которые как раз и выходят за пределы базового набора примитивных действий, обычно идентифицируемого аббревиатурой CRUD. То есть «подшаманили» ради нужных расширений, а теперь некорректно заявляете об охвате 98% алгоритмов. В следующий раз (у следующего заказчика) вам придётся снова подшаманить, потом ещё и ещё. И окажется, то 98% — было явной натяжкой.

>> это скорее комбинаторное, реактивное, логическое и событийное программирование

А теперь было бы неплохо расшифровать приведённые термины. Мною использованы стандартные термины, вы же придумали свои, поэтому расшифровка необходима.

Хотя да, такой подход «сверху», пусть даже через доморощенные термины, я поддерживаю.

>> Декларативный стиль — это метрика того насколько язык высокоуровневый

Процедура «всё прекрасно» может быть написана почти на любом языке. Обратите внимание на силу декларативной метрики в данном примере.
Доказать сможете? Если доказательством опять будет ссылка на реализованный проект на вашем языке, то подскажу — вы встроили в платформу те встретившиеся алгоритмы, которые как раз и выходят за пределы базового набора примитивных действий, обычно идентифицируемого аббревиатурой CRUD. То есть «подшаманили» ради нужных расширений, а теперь некорректно заявляете об охвате 98% алгоритмов. В следующий раз (у следующего заказчика) вам придётся снова подшаманить, потом ещё и ещё. И окажется, то 98% — было явной натяжкой.

У нас больше 40 заказчиков из разных областей, разных размеров с оборотами под миллиард долларов полностью автоматизированных на этой платформе генерящих по 10 задач в день (!). И я вспомню штук 5 задач (вроде прогнозирования продаж). Все остальное эту куча разных формул, группировок, разбиений и т.п.
А теперь было бы неплохо расшифровать приведённые термины. Мною использованы стандартные термины, вы же придумали свои, поэтому расшифровка необходима.

Ага даже википедию отредактировал:
Комбинаторное, реактивное , событийное, логическое.
Процедура «всё прекрасно» может быть написана почти на любом языке. Обратите внимание на силу декларативной метрики в данном примере.

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

По модульности что-нибудь скажете? Как много зависимостей между модулями? Сколько лет приходится тратить на поддержку изменений в бизнес-процессах заказчика? Сколько человек поддерживают те 25к строк кода, которые работают на каком-то предприятии?
По модульности что-нибудь скажете? Как много зависимостей между модулями? Сколько лет приходится тратить на поддержку изменений в бизнес-процессах заказчика? Сколько человек поддерживают те 25к строк кода, которые работают на каком-то предприятии?

Цитирую статью:
Вообще, эти три механизма (агрегации, наследование и полиморфизм), а также события и расширения (о расширениях позже в статье о физической модели) позволяют достичь если не идеальной, то очень близкой к ней модульности. К примеру, сейчас ERP состоит из приблизительно 1100 модулей. Соответственно, из них можно выбрать любое подмножество модулей и собрать из этого подмножества решение, в котором будет ровно то, что нужно заказчику. Так, у нас у некоторых заказчиков работает только непродовольственная розница (около 50 модулей), у некоторых только производство и опт, а у некоторых практически все 1100 плюс еще 300 своих.

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

Там же можно увидеть коммиты, но это только ERP общая кодовая база, есть еще модули конкретных заказчиков они во внутренних репозитариях. Сейчас несколько десятков заказчиков, с общим оборотом наверное под несколько млрд долларов, среди них есть как крупняки, так и достаточно мелкие, хотя у нас средний чек повыше 1С, то есть все же в среднем не меньше 20-30 одновременных пользователей. Поддерживает и дорабатывает около 10 человек (около 30-40 задач доработки в день где-то генерится)
>> сейчас ERP состоит из приблизительно 1100 модулей

Масштаб понятен. А теперь ещё интереснее — как вы во всей этой тысяче ещё не запутались?

>> Поддерживает и дорабатывает около 10 человек

Вообще получается 10 человеко-месяцев каждый месяц убивается на обслуживание изменений. За 10 человеко-месяцев упоминавшуюся систему на 25к строк можно написать (ну почти, то есть без тестирования и прочего отягощающего, плюс эффективно разработку организовать). В итоге получаем, что месяца за два-три-ну-пусть-четыре доработки становятся равны по сложности разработке с нуля. И теперь вопрос — а где выигрыш? Новый язык и многия обещания предполагают огромное сокращение затрат, ведь так? Но тем не менее по трудозатратам систему переписывают полностью раз в несколько месяцев, при чём не реализуют все процессы заказчика с нуля, а лишь слегка подправляют. И вот это «слегка подправляют» равно переписыванию с нуля по затратам. Так в чём выигрыш? Где гигантские сокращения времени разработки, количества ошибок, жалоб пользователей и т.д.?
Масштаб понятен. А теперь ещё интереснее — как вы во всей этой тысяче ещё не запутались?

IDE практически со всеми возможности на базе IDEA (забавно кстати что про нее никто не спросил) творит чудеса. Графы модулей, классов, структура класса, да и просто IDEA'кий крутой поиск.

То есть нашел нужный функционал, написал REQUIRE. Не хватает функционала, создал еще один класс / агрегацию, добавил реализацию, доделал EXTEND'ы. Вообще ООП, а точнее полиморфизм / наследование плюс событийное программирование очень сильно недооценивают в разработке бизнес-приложений, при помощи них можно очень круто декомпозировать сложность и не давать растить технический долг, даже при схем херак-херак и в продакшн.
Вообще получается 10 человеко-месяцев каждый месяц убивается на обслуживание изменений.

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

Тут конечно можно начать волынку, что это неправильно, что best-practice и все дела. Но как сказал нам один из первых крупных заказчиков, я вот построил этот крупный бизнес сам с нуля, а ты сколько их построил, чтобы рассказывать мне как это делать. И если бы я не правильно работал, я бы этого не смог сделать. И он прав, если он будет работать как кто-то другой крупнее его, он просто проиграет ему, потому что он меньше. А процессы кого то меньше его точно нет смысла брать. В общем все эти best-practice — это «все беды от мяса». Продвигают те кто просто не умеет адаптироваться под заказчика и постоянно меняться вместе с ним.
>> То есть нашел нужный функционал, написал REQUIRE

Вот как это выглядит в Eclipse — я нажимаю ctrl+shift+o и мне предлагается список одинаковых названий классов из разных пакетов. Я выбираю — и всё, ничего искать не надо, тем более что-то писать. А если имя класса уникально — даже выбирать не надо.

В целом по модульности понятно — как у всех. То есть просто куча файлов, с которым (уж как умеет) разбирается IDE.

>> Вообще ООП, а точнее полиморфизм / наследование плюс событийное программирование очень сильно недооценивают в разработке бизнес-приложений

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

>> очень часто переделывают то что есть, потому что клиенты постоянно экспериментируют

Мне вспоминается обычное недовольство типа «вот здесь нет поля ХХХ» или «вот это система должна сама!». И выливается это всё в довольно простые действия по добавлению поля или выполнению простого расчёта с выводом результата. Большего от учётных систем редко требуют. Поэтому здесь скорее речь об организации процессов в разработке, в смысле производительность у вас, конечно, как у всех, и не зависит от инструмента (или слабо зависит), а доработки требуют 10 человек именно из-за неидеальности процессов. Хотя соглашусь — в больших конторах процессы ещё более страшные и там легко могут и 100 человек на ваши задачи посадить.
В итоге получаем, что месяца за два-три-ну-пусть-четыре доработки становятся равны по сложности разработке с нуля. И теперь вопрос — а где выигрыш?

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

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


А вообще есть хороший пример тут на блоге — Леруа Мерлин. У них IT-отдел 400 человек. И они обслуживают компанию с такими же оборотами как у наших клиентов. Но у нас их 40 разных, а у них один. И когда они тут описывают задачи, которые они героическими усилиями решает, это выглядит забавно, потому как у нас такие чуть ли каждый день решаются. И это 10 человек. Абсолютное большинство из которых, без сколько-нибудь значимого IT-бэкграунда.

Понятно что они еще и веб-сайт и еще что-то ведут, но при этом скажем у них и ERP-система и POS и скажем HR — сторонние. А мы у многих заказчиков и это закрываем.

Зато у них модные технологии.
Как уже отметили в комментариях — продажа не удалась, не видно чем этот неязык лучше, какие преимущества предоставляет. Разговоры мол наш бизнес успешен, а значит язык ого-го конечно чушь, успех бизнеса в последнюю очередь определяется технологиями — «кадры решают всё», тем более ничего не говорит успех на убогом постсовестком рынке где никто не хочет нормально работать.
На самом деле платформа для прикладного софта нужна, когда-то были Clipper/FoxPro которые удобно комбинировали возможности по созданию гуев с базой данных и какой-то логикой, сейчас нишу поглотили энтерпрайзные уродцы или узкоспециализованные решения.
Я бы вот хотел библиотеку для создания простых (без свистелок, просто функциональных) кроссплатформенных (включая веб) гуев.
Я бы вот хотел библиотеку для создания простых (без свистелок, просто функциональных) кроссплатформенных (включая веб) гуев.

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

Не надо только хаять постсоветский рынок. Мне доводилось видеть, как и что работает у западных компаний. Так вот там все местами в разы хуже, чем у нас. Почитайте хотя бы блог Лероя. От многих поставщиков приходят инвойсы в виде текстовых файлов, куда просто выгружены их отчеты. На вопросы «а дайте, пожалуйста, REST API, WS или что угодно», они вас откровенно игнорируют.
Бэкэнд и на питоне можно написать, может не так удобно как на специализированном DSL, но вполне приемлимо.
Но это будет медленнее и дороже, чем на специализированном DSL. Разве нет? Хотите устроим паралимпиаду по программированию? :)
Всё зависит от того как считать, надо учесть, что этот DSL надо изучать, что будет делаться при разработке первой системы и скажется на скорости, примерно за то же время, на условном питоне, в процессе разработки первой системы, будет подобран набор библиотек/практик и получится нечто вроде DSL, соответственно при разработке последующих систем разработка будет быстрее.
Думаю, что DSL может быть значительно эффективнее, только при очень узкой специализации, т.е. не DSL для ERP, а, например, DSL для платёжной системы, регистратора доменов и т.п., но до такого видимо пока ещё не доросли.
Тем не менее, большинство ERP-систем сейчас пишется на базе платформ с DSL (например, Axapta/SAP/1C и т.д.). Может потому, что все-таки так эффективнее?
Давайте по существу. Возьмем простое приложение. По ссылке есть краткое описание и ссылка на демку. Это небольшая CRM-система, которую мы разрабатывали под себя (есть своя специфика). Я снял данные с timetracking'а: на нее ушло 250 часов. Причем ее делал человек, который никогда ни на чем кроме lsFusion, не разрабатывал. Сколько времени уйдет у Вас на написание аналогичного функционала с использование python и front-end библиотеки по вашему выбору?
Мы же про серверную часть, я о том и говорю, что все такие АРМы на 99% состоят из гуя и отчётов, серверная часть там просто микроскопическая и на питоне её также быстро можно написать, а вот гуй это проблема с которой и начинался этот тред.
Бэкэндеры будут с Вами несогласны. Как минимум на сервере вам нужно будет реализовывать всю валидацию, обновление агрегаций в базе данных и прочее. А это большой кусок работы. Плюс, предположим вам нужно сделать окно по списку из 10.000 значений. Вы же не потянете их на клиента сразу? То есть нужно будет хитрое взаимодействие. Так вот все это высокоуровневые платформы берут на себя. Поэтому их и используют.
Для больше части задач есть хорошие библиотеки/подходы/стандарты, ну например, если юзать REST, то инструменты поддерживающие OpenAPI, вроде connexion возьмут на себя всю рутину по валидации, сериализации, парсингу параметров и т.д., останется только написать код который выполняет действие.
То есть Вы предлагаете собирать миллион различных библиотек, потом как-то их дружить друг с другом для того, чтобы решить простую с точки зрения пользователя задачу.
Так можно долго дискутировать, но ответьте, пожалуйста, на вопрос: сколько времени у Вас займет реализовать вышеописанную задачу?
Изначально все началось с того, что уже все давно написано. Так вот назовите мне, пожалуйста, все технологии, которые для реализации такой задачи использовать и сколько у Вас ориентировачно времени это займет.
Вы всё время уводите разговор в сторону, а ведь смысл моего изначального комментария был достаточно ясен и он не в том, что DSL не нужны, а в том, что данный пост никак не убеждает в ценности данного DSL.
Пока продажа не состоялась, видимо потому что выбрана неверная стратегия, нужно не справку по языку приводить, а показать на живом примере, разобранном по шагам, как сей язык позволяет решать задачи лучше аналогов, чтобы его преимущества стали оцевидны всем кто решает такой класс задач.
Все это будет, но в следующих статьях. Но, к сожалению, многие вещи можно оценить только после самостоятельного, относительного длительного использования. Но постараемся показать на примерах.
Это так, но чтобы человек стал тратить время на изучения какой-то никому не ведомой технологии его нужно убедить, что технология реально ценна, а аргументы вроде «мы же лидеры на рынке», «да все используют DSL, чем мы хуже», «у нас чистых функций нет, но мы их упомянем чтобы благодать хаскела снизошла на нас» только порятят впечатление.
Согласен. Но, даже если не касаться основных преимуществ, есть одна существенная — LGPL лицензия. Назовите, пожалуйста, высокоуровневую ERP-платформу, на которой сможет писать человек уровня 1С-программист с бесплатной лицензией?
Предположим человек — умный сотрудник (но не программист) некоторой компании, которому нужно решить какую-то внутреннюю задачу. С технологией по такой лицензии, он может быстро разобраться, и наклепать себе простенькое приложение и использовать его внутри компании. В противном случае ему как минимум придется идти согласовывать бюджет с руководством, объяснять зачем ему это надо, искать исполнителей и т.д. Скорее всего он этим заниматься не будет и просто забьет. А тут есть возможность.
Это конечно плюс, но не отменяет вышесказанного, пока не показаны преимущества можно считать что условный, тоже свободный, питон с условной Odoo лучше.
Я сейчас не про ERP и CRM. А просто про какую-то небольшую задачку. Возьмите к примеру Турнирная таблица. Как думаете, ее сможет написать обычный пользователь на питоне? Быстро научите его пользоваться самим питоном + каким-то фронтенд фрэймворком? А потом еще это все связывать и деплоить.
На мой взгляд проще чем вашему DSL
Возможно со старта и сложнее. Но зато на этом DSL можно делать очень сложные вещи гораздо проще. В следующих статьях мы это покажем на примерах.
Это была вводная статья, чтобы потом на нее ссылаться, если человек захочет изучить глубже.
Давайте так, у вас видимо сложилось ложное впечатление что это продающая статья. Нет. У нас было два варианта или делать первым преимущества (но тогда нас запинали бы за маркетинг буллшит), или техническое описание (тогда мы получили бы за отсутствие ценности). Это хабр и мы решили второй вариант, но потерпите скоро продающие статьи появятся. Хотя если не терпится есть сайт.
Тем не менее, большинство ERP-систем сейчас пишется на базе платформ с DSL (например, Axapta/SAP/1C и т.д.). Может потому, что все-таки так эффективнее?

То что кто-то что-то делает, ничего не доказывает, кто их там поймёт, вон Salesforce вообще древнюю джаву поломал и использует, да ещё и на рынке успешен.
Кстати, если отбросить веб в требованиях кросслатформенности, то есть интересный фреймворк для гуёв, но ввиду что веб сечас обычно нужен, а я от гуёв далёк не дошли руки попробовать.
Все комментарии не читал, поэтому возможно повторюсь.
Первый вопрос — зачем вы стали изобретать этот язык? Что не устраивало в текущих, как общего назначения, так и специализированных(ABAP, 1C, FoxPro, VBA)?
Но человека пишущего сейчас на ABAP'е вы совсем не заинтересовали и это не смотря на то, что ABAP — ужасен и нелогичен.
Из интересного увидел какое-то хитрое разделение между серверами приложений и БД, но фокус в том, что чем больше там магии — тем хуже, ибо в если что-то начинает внезапно тормозить, хотелось бы понимать что именно и какие пути решения есть. SQL тут кстати выступает плохим примером — мне встречались случаи, когда запрос работавший годами несколько миллисекунд вдруг стал работать несколько минут из-за изменения плана его выполнения. А так как запрос был простой, то пришлось взять бубен и подставлять натуральные костыли, чтобы вернуть все как было. А теперь представим, что мне еще ко всему этому сложно понять, где вообще код исполняется…

P.S. Собираетесь ли вы делать типовые решения и как хотите(или уже) решать проблему обновления типового, но кастомизированного кода?
Первый вопрос — зачем вы стали изобретать этот язык? Что не устраивало в текущих, как общего назначения, так и специализированных(ABAP, 1C, FoxPro, VBA)?

Тут преимущества и их сравнение с ABAP, 1C, Foxpro и VBA.
Из интересного увидел какое-то хитрое разделение между серверами приложений и БД, но фокус в том, что чем больше там магии — тем хуже, ибо в если что-то начинает внезапно тормозить, хотелось бы понимать что именно и какие пути решения есть

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

«Как я вас понимаю»©. Современные SQL-сервера это вообще один большой набор эвристик. Поэтому над ним есть компилятор запросов, которые делают проталкивание предикатов, материализацию подзапросов (когда что-то идет не так) и т.п.
P.S. Собираетесь ли вы делать типовые решения и как хотите(или уже) решать проблему обновления типового, но кастомизированного кода?

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