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

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

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

В этом КМК одна из основных проблем. Представьте себя на месте человека, который только "вошёл в строительство", и не хочет глубоко заниматься вопросами проектирования планировки, заливки фундамента, возведения стен, внутренних работ, кровли, а хочет просто строить коттеджи. Чтобы что-то хорошо делать в любой сфере деятельности, надо вникать. Результаты "Фигак-фигак, и так сойдёт" можно посмотреть в незабвенном мультфильме "Вовка в тридевятом царстве".


EDIT: Как обычно, чукча не читатель. Подкорректирую. Вышесказанное остаётся в силе. Касательно вашей аналогии. "Вырыть яму на дачном участке" примерно соответствует "поднять простенький сервер для отдачи статики". И то, даже яму надо уметь копать. Как и поднимать простенький сервер. Множество языков существуют не просто так. Каждый из них выполняет определённую задачу. Представьте себе, что вместо отдельных молотка, плоскогубцев, дрели, шуруповёрта, кусачек, обжимных клещей у вас один универсальный Починятор. Если вы смогли покрыть свою предметную область одним языком — замечательно. Проблемы начнутся, когда вам понадобится сделать шаг за её пределы.

Вот да. КМК авторы идут ровно по тем-же граблям, что и создатели языка 1C (язык для не программистов, ага). А до этого создатели COBOL. В результате что для кобола, что для 1C, нужны специально обученные люди.

Скорее уж ABAP, SQL или Foxpro. Хотя прикол в том, что практически во всех продуктах сейчас есть свои языки или мини-диалекты. .Net начал LINQ встраивать в язык, React — JSX и т.п. В узкоспециализированных продуктах языков еще больше. Например в том же NSIS (самой популярной технологии для создания инсталляторов) свой язык, тот же Jenkins и Gradle использует Groovy (весьма редкий диалект Java), GrammarKit, JFlex и ANTLR (для создания парсеров и лексеров) имеют свои языки и т.п.

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

Популярность языка или монополия платформы в одной отдельно взятой стране?

НЛО прилетело и опубликовало эту надпись здесь
По-моему, все языки создавались «чтобы было просто писать» или «чтобы могли писать непрограммисты». И ни у кого не получилось.
Сейчас только у нас на фирме на lsFusion разрабатывают 20 человек. Ни один из них никогда не писал ни на Java, ни на Python, ни на C++, ни на любом другом классическом языке программирования. Пишут просто, только иногда конечно срабатывает «with great power comes great responsibility» и приходится немного оптимизировать.
так у них какая должность — разработчики lsFusion? Как на счет «простого бухгалтера» ??
Нет, кстати, у многих из них должность — «бизнес-аналитик». Но Вы же понимаете, что это не важно. Между программированием и настройкой/конфигурированием очень тонкая грань. Я в статье давал ссылку на другую нашу статью, где мой коллега это описывал.
Чтобы что-то хорошо делать в любой сфере деятельности, надо вникать

Абсолютно согласен. Но дело в том, что есть еще такое понятие как экономическая эффективность. И часто нужно делать не самым лучшим способом, а лучшим по соотношению цена/качество.

Классический пример: Макдональдс. С точки зрения еды — не самый лучший. Но тем не менее, он пользуется огромной популярностью и востребован на рынке.

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

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

Если вы смогли покрыть свою предметную область одним языком — замечательно

Именно это мы и старались сделать.

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

Да, именно так и есть. Но у нас и не было цели делать универсальный язык.
Разве что JavaScript похож на Java, но если мы возьмем более модный Python, то будет еще один совершенно новый синтаксис.


Разрешите вас покритиковать. Процитированное выше предложение — просто сказка… хм, намекающая на то, что под выбором «своего языка» таки не лежит каких-то особых исследований по теме.

3 наводящих вопроса:
1. Чем похожи Java и Javascript (за исключением букв «Java» в названии, конечно)?
2. Давно ли Python перешел в разряд «более модных»?
3. К чему вообще упоминание Python в контексте Javascript'а? Где точка пересечения, и как вы собираетесь JS Python'ом заменять?
Чем похожи Java и Javascript (за исключением букв «Java» в названии, конечно)?

Например, синтаксисом for'ов, if'ов. Вот цитата из википедии: «На JavaScript оказали влияние многие языки, при разработке была цель сделать язык похожим на Java».

Давно ли Python перешел в разряд «более модных»?

В те времена, когда я начинал программировать, мэйнстримом был C++, а Java был новым и модным. Про Python тогда никто не слышал. Так что он явно «моднее», чем Java.

3. К чему вообще упоминание Python в контексте Javascript'а? Где точка пересечения, и как вы собираетесь JS Python'ом заменять?

Python упоминался не в контексте JavaScriptа, а как замена Java на backend'е. При этом, на frontend вы же не можете писать на Python (браузер не умеет его выполнять). Так что Вам придется писать и на Python, и на JavaScript.
есть еще такое понятие как экономическая эффективность. И часто нужно делать не самым лучшим способом, а лучшим по соотношению цена/качество.

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

Сколько процентов выиграли?

Смотря в чем считать. Затраты давно отбили, и уже давно прибыль.
Стоп, давайте уточним разработка языка или парадигмы? Теоретически и SQL можно было сделать библиотекой и как-то натянуть на существующие синтаксисы. Но фокус SQL (как и lsFusion) что они фундаментально другие. Это function-level (не путать с functional) программирование, в противовес value-level программированию. То есть построенное на ограниченном множестве функций высших порядков (операторов, где при этом все функции чистые), а не на архитектуре ноймана (с состояниями, переменными, потоком выполнения и вот этим всем). Такая супер-функциональщина.

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

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

Мы сами это хорошо чувствуем, когда делаем собственные бизнес-приложения. Лично нам (в сфере решений для бизнеса) никогда не приходилось конкурировать с классическими технологиями (описанными в статье), так как они значительно уступают и по цене, и по срокам. В этой нише, в основном, работают 1С, Microsoft Dynamics, SAP, но там везде есть свои нюансы.
>> текущая ситуация, особенно на веб-фронте это дурдом

Сможете аргументировать?

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

Но в целом всё идёт вполне в правильном направлении. С высоты сотни лет истории этот период покажется моментальным взрывом и мгновенным нахождением правильных решений. Ну а с вашей узкой колокольни, видимо, процесс просто выглядит утомительно. Только не надо зависать в персональной колокольне навсегда.
Но в целом всё идёт вполне в правильном направлении


А можно уточнить, что это за такое «правильное направление»? Реально интересно. React / Angular? Или PHP что ли? :)

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

Тогда тоже коротко. Погуглите слово «конвергенция», возможо что-то поймёте.

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

В статье ведь по сути описан DSL. Слышал, такие вещи можно и на общеупотребительных языках (typescript, kotlin ) создавать. В любом случае вопрос, скорее, не в языке, а во фреймворке, который все эти высокоуровневые команды преобразует в исполняемый код.
Совершенно верно, это именно DSL и есть. И да, фреймворк гораздо важнее, чем язык.

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

Поддерживая предыдущего оратора хотелось бы добавить — почему вы так носитесь с этим "порогом вхождения"?
Неужели вместо привлечения профессионалов привлекательным комплектом инструментов лучше заниматься зазыванием малолетних долб как можно более непрофессиональных пользователей в как можно более товарных объемах?
Нет, ну понятно, что привлекать молодые таланты — дело важное и нужное. Но не до беспредела же. Или до?
В чем сила, брат? ©
PS. как пример первое, что мне приходит голову после прочтения реклама очередного вах! языка программирования — как туда прикрутить Qt, оттуда использовать LibreOffice, обращаться к Java-библиотекам и делать вызовы REST API или просто HTTP. Как вариант. Расширения возможностей.
И моя интуиция настойчиво шепчет, что гибкость/мощность продукта прямо пропорциональны порогу вхождения. Поэтому по каким-то критериям должен остаться кто-то один: или шашечки — или ехать.

Порог вхождения на самом деле ОЧЕНЬ мощная штука, вы ее недооцениваете.
Неужели вместо привлечения профессионалов привлекательным комплектом инструментов лучше заниматься зазыванием малолетних долб как можно более непрофессиональных пользователей в как можно более товарных объемах?

Лучше для кого? Если построить график, где по одной шкале будет уровень способностей, а по другой — количество людей с таким уровнем, то будет гипербола. Верно?

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

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

обращаться к Java-библиотекам и делать вызовы REST API или просто HTTP

В lsFusion есть такие возможности: подключение Java, обращение по HTTP, подключение JavaScript библиотек, и вообще отдельный фронт. И это будет еще развиваться.
Посмотрите в сторону языка Katahdin
Иногда программист хочет использовать один язык в рамках другого. Например, SQL используется повсеместно в рамках других языков, при этом код на SQL записывается в строках. Katahdin позволяет совместить основной язык с SQL, чтобы тот использовался как часть основного языка.

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

Идея интересная, но мне не очень понятно практическое применение.

Важно понимать, что язык — не самоцель. Как писалось выше, главное — фреймворк, для которого он используется. Язык, используемый в lsFusion, во время выполнения компилируется в SQL. Такое возможно только с узкоспециализированным DSL, а никак не с универсальным языком программирования.
такое возможно только с узкоспециализированным DSL

Так язык Katahdin как раз и предназначен для создания своих узкоспециализированных DSL
Таким образом, после объявления новой операции, она может быть использована дальше в программе. Katahdin не содержит специальных конструкций, которые не могут быть изменены (даже пробелы и ключевые слова не являются исключением). Если описать все конструкции какого-либо языка программирования подобным образом, то Katahdin превратится в интерпретатор этого языка. Таким образом, Katahdin может быть использован в качестве универсального интерпретатора.
Специфика lsFusion в том, что там в большинстве своем декларативная логика. Там нет последовательности выполнения, а при помощи языка описываются статические конструкции (которые затем используются для автоматического построения запросов, форм и т.д.). То есть там нет интерпретирования как такого. Не очень понятно, что с ними делать при помощи Katahdin, и чем это лучше, чем использование того же ANTLR для разбора декларативной логики.
НЛО прилетело и опубликовало эту надпись здесь
Вы видимо не до конца поняли целевую аудиторию разработчиков. lsFusion, поскольку имеет низкий порог вхождения, предназначен для людей, которые не хотят/не могут заниматься классическим «низкоуровневым» программированием.

Платформа нужна для людей, которые ближе к бизнес-анализу, и могут/хотят сами разрабатывать бизнес-приложения, контактируя напрямую с заказчиком, без привлечения классических программистов. Например, человек может взять бесплатную MyCompany и начать дорабатывать ее под конкретного клиента самостоятельно как фрилансер. И ему не нужны будут никакие конторы.

lsFusion — это бесплатная и открытая альтернатива 1С, а не классическим языкам программирования. Причем именно версиям до 8.3, когда 1С стала смещаться в сторону низкоуровневого программирования. Статья была написана для того, чтобы показать, почему обычному человеку тяжело начать разрабатывать бизнес-приложения, используя классические технологии.
НЛО прилетело и опубликовало эту надпись здесь
Посмотрел примеры кода на вашем языке, честно говоря не видно волшебства

Чисто для интереса, а можно пример чего то хотя бы близко похожего, с тем же уровнем декларативности и возможностями (скажем прозрачными материализациями, ограничениями, событиями, агрегациями и т.п.). Чтобы как в lsfusion.org/try можем было запустить (это например показывает уровень декларативности)
Для тех кто выбрал писать на нём видится большая проблема, это то что время на его изучение, это фактически выбрашенные в унитаз усилия. Шанс что это понадобится где-либо кроме двух с половиной конторах, стремиться к нулю.

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

95% процентов абстракций lsFusion просто не лягут на синтаксис (а точнее логику) ни одного из известных языков. Уж очень сильно отличаются парадигмы. Да и даже если удалось бы, в чем выигрыш? Ну скажем .Net встроил linq в язык, и? Да, прикольно, но многие продолжают работать с запросами в строках и это точно не killer feature.
НЛО прилетело и опубликовало эту надпись здесь
Выглядит как VB на стероидах

Не совсем понял с какого боку здесь VB, так как lsFusion это функциональщина возведённая в абсолют. Function-level программирование против value-level программирования (то есть архитектуры ноймана).


Описания классов как будто это таблица базы с constraints и т.п.? Ну это как раз то что можно реализовать своеё надстройкой над языком. И препроцессор может сгенерировать валидный код для подобного.

Вот честно не понимаю как и зачем. Программа на lsFusion состоит из очень большого числа различных маленьких правил (абстракций). Как это все натянуть на любой из существующих языков загадка. Так как принципиально другой подход.


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

Ну про SQL, ООП (c++), Java, Fortran/C (структурное программирование) в свое время тоже так говорили. А по уровню paradigm shift (то есть новых идей) lsFusion им как минимум не уступает на мой взгляд. Но поживем увидим.


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

Здесь пропущено слово если :) Ну и в любом случае, скажем когда мы писали плагин IDEA мы фактически не обращались ни к вендору ни комьюнити (не факт что оно есть). Хотя ИМХО к архитектуре IDEA вопросов точно не меньше чем к lsFusion.

НЛО прилетело и опубликовало эту надпись здесь
Я может быть неправ, но честно говоря гляди на пример из комментария сверху, не могу функциональщины под микроскопом разглядеть. Вложеные циклы и if-ы с брейками, это всё таки ближе к VB.

Дело не в циклах, а в их условиях. Но согласен, это наверное самый императивный пример, вы перейдите лучше в Try Online на вкладку Платформа. Там законченные (пусть и достаточно простые) логики без единой (!) строки императивного кода (скажем то же УМП). Хотя справедливости ради обычно распределение условно 80 на 20 (80 — декларативного, 20 — императивного кода).
Не пропущено, просто в чудеса не верю.

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

Что не помешало ей по сути стать стандартом в отрасли и победить Eclipse с гораздо более сильной компанией стоящей за ней и гораздо большим комьюнити. ИМХО чисто потому, что у них продукт просто был лучше спроектирован (то есть даже не фундаментально лучше).
Выглядит как VB на стероидах.

Приведенный выше пример — это как раз кусок императивного кода. Все же в lsfusion бОльшая часть кода — декларативна.


Смотрите, возвращаясь к исходной теме статьи, у lsfusion все же своя парадигма. Немного громкое слово, но мы используем его в документации. Можно назвать это концепцией. БОльшая часть кода — это по сути просто декларативное объявление неких сущностей (в терминологии lsfusion — свойств, действий, форм, классов, таблиц и т. д.).


Давайте представим, как будет выглядеть некая fluent interface реализация на каком-нибудь распространенном императивном языке (мы ведь не хотим учить новый язык). По факту получится библиотека, в которой будет куча конструирующего выше упомянутые сущности кода. В результате код, по крайней мере декларативная его часть, будет выглядеть примерно так:


createProperty(...)
createClass(...)
createProperty(...)
createProperty(...)
createForm(...)
createNavigatorElement(...)

Окажется, что знание языка не очень то помогает, потому что код то получается примитивный, но без знания парадигмы все равно ничего не понятно.
Что f(x) = GROUP ... в lsfusion, что f = createGroupProperty(...) в каком-нибудь языке одинаково непоняты без знания платформы. Более того, уверяю, что этот fluent interface будет довольно кривым и громоздким, а некоторые вещи возможно вообще не получится реализовать в том объеме, в котором это реализовано с DSL. Знакомый синтаксис языка оказывается вторичным. DSL же позволяет по возможности лаконично и максимально точно приблизиться к той концепции, которая им выражается. Да, императивную часть теоретически можно сделать понятней и богаче, но основная суть не в ней.


Другой вариант — это взять язык, используя возможности которого, можно попробовать добиться достаточной выразительности и функциональности, не выходя за его пределы. Но это какие языки? Lisp? Nemerle? выше вот Katahdin советовали… Но процент потенциальных пользователей платформы, которые знают что-нибудь из подобного, настолько несущественен, что не видно никакого смысла в их использовании. Конечно, это в контексте того, что для программирования на lsfusion есть среда разработки с достаточно взрослой поддержкой языка.


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

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

НЛО прилетело и опубликовало эту надпись здесь

Я пробовал сделать пример с турнирной таблицей на PHP. Примерно понял, о чем говорит автор, хотя он все равно преувеличивает. Суть в том, что в бизнес-логике на обычных языках программирования надо дублировать условия отнесения сущности к какому-то бизнес-правилу в запросах на произвольное количество строк и в коде для отдельной сущности. К примеру, у сущности есть метод isActive() { return this.status == StatusEnum.Active; }, а в запросах надо писать WHERE status == 'active' .... У них это описывается один раз одним правилом. Может в LINQ это попроще, да и на PHP не слишком сложно, просто на обычных языках бизнес-логика немного по-другому делается, а в том примере такие условия накручены друг на друга, один-в-один сложно перенести. Надо код примера подробно изучать, чтобы разобраться во взаимосвязях сущностей, а мне было лень этим заниматься. Если у вас есть время и желание, попробуйте сделать на C#, было бы интересно сравнить.

Давайте. Как я предлагал, давайте сделаем надстройку над существующим языком, например, c#. Делаем препроцессор который парсит файлы fsn и делает транспиляцию в c#.

Еще раз, нужно понимать что lsFusion для логики вычислений использует виртуальную машину сервера БД (SQL сервер), а не виртуальную машину сервера приложений (JVM или .Net). То есть прикладных объектов нет на сервере приложений ВООБЩЕ (если не считать редких случаев, когда изменение идет ровно для одного объекта, но это уже детали). То есть NoORM, YesSQL. Соответственно никакая транспиляция не возможна в принципе.

Все складывается на сервер БД (в те же временные таблицы), а потом строятся инкрементальные запросы, все запросы группируются, компилируются, оптимизируются, материализуются подзапросы и т.п. lsFusion это скорее надстройка над SQL чем над C# или Java. То есть от последних можно было взять только похожий синтаксис (что местами и делается).
Получается что мы используем один из широко распространнённых языков, стабильный, многоплатформенный, строгая типизация, с огромным количеством библиотек.

Стоп. Что-то вы все в кучу смешали. lsFusion написан на Java и позволяет бесшовно подключать любые Java-библиотеки (более того в lsFusion в некоторых местах можно делать вставки на Java прямо в коде, но только непонятно зачем, если удобнее это делать в отдельных .java файлах). То есть многоплатформенность и огромное количество библиотек есть из коробки.

Строгая типизация у lsFusion присутствует причем повсюду даже в логике представлений (которой у .Net нет вообще). Ну и про широко распространенных языков это максимум 5-10% разработчиков. Тот же SQL в этом плане гораздо более распространен, его используют все — и кто на Java пишет и на 1С и на PHP и на .Net, поэтому ориентироваться логичнее было на него, что мы и делали.
Плюс тысячи разработчиков которые его знают. И те кто будет использовать вашу платформу не будут боятся потратить время впустую, потому что 90% знаний можно будет переиспользовать.

Вы же понимаете, что в программировании знание парадигмы программирования важнее чем знание синтаксиса. Скажем у нас в свое время большинство людей обучались на Pascal, но после него очень легко переходили на Java или C или Python. Я собственно в свое время писал на C++, потом на Foxpro, сейчас на Java (у меня переход неделю занимал), периодически переходя на JavaScript, Groovy или Python. Выучить синтаксис это плевое дело. Выучиться парадигме (той же функциональщине) гораздо сложнее. Поэтому натягивать парадигму на чужой синтаксис дело неблагодарное (скажем те же LINQ с лямбдами то что вы предлагаете как замену GROUP SUM, а) более громоздкий, б) для человека не знакомого с функциональщиной гораздо более сложный для понимания).
И самое важное, если ваши идеи действительно чего-то стоят — то их потенциально увидит гораздо больше человек (на порядки). И может быть в будующем внедрят в язык, также как внедрили LINQ. Вот это будет успех, а так шансы на _большой_ успех сомнительны.

Все новые языки / парадигмы / идеи в свое время делались с нуля (причем часто не пойми кем, скажем тот же Python), что со временем им никак не помешало. И если пытаться натянуть что-то революционно новое на старое, получится ни рыба ни мясо. Хотя не спорю, что с маркетинговой точки зрения идти от старого куда проще.
Еще раз, нужно понимать что lsFusion для логики вычислений использует виртуальную машину сервера БД (SQL сервер), а не виртуальную машину сервера приложений (JVM или .Net). То есть прикладных объектов нет на сервере приложений ВООБЩЕ (если не считать редких случаев, когда изменение идет ровно для одного объекта, но это уже детали). То есть NoORM, YesSQL. Соответственно никакая транспиляция не возможна в принципе.

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

Давайте. Как я предлагал, давайте сделаем надстройку над существующим языком, например, c#. Делаем препроцессор который парсит файлы fsn и делает транспиляцию в c#.

В приведенном примере вы как-то лихо предположили, что классы и свойства lsfusion хорошо лягут на классы и свойства c#. В lsfusion у классов есть множественное наследование, нет инкапсуляции (в плане "объединения данных и методов работы с ними"), классы открыты, то есть в любом месте программы их можно расширить. У свойств, например, есть multiple-dispatch, то есть subtype полиморфизм по любому подмножеству параметров. А сверху этого всего есть еще модульность и логика пространств имен. Так просто отобразить это на c# классы у вас не получится.


Если брать, например, CONSTRAINT из lsfusion, то он работает не только для каких-то первичных данных, но и для произвольного выражения, а это выражение в свою очередь может вычисляться через сотни других свойств. И объявлен этот CONSTRAINT может быть в другом модуле. Как вы будете это протаскивать в c# код?


после транспиляции у нас получается чистый c# код

Хорошо, так а писать мы в этом случае на чем будем? На вот этой надстройке ведь, которая по сути тот же DSL, для которого изначально не будет никакой поддержки IDE. Но вообще даже об этом нужно говорить только тогда, когда вы придумаете, как lsfusion на тот же c# отобразить, чтобы это имело хоть какой-то смысл, а не было просто библиотекой со своим API, как я приводил выше.

JavaScript. На нем можно бекенд. На нем можно базу данных, для особых ценителей даже с нативной поддержкой JS — MongoDB. На нем можно протокол обмена — JSON. На нем можно фронтенд, для особых ценителей — не написав и строки на HTML или CSS, даже без JSX, прям на чистом JS. Если вам нужны мобильные приложения — есть несколько вариантов для вас. Если десктопные — тоже. Если в консоле как язык консоли — тоже. Если дистрибутив линукса где будет всё вертется вокруг JS — и такое есть. Если вы скажете что у нас есть кое-какие устройства на голом железе, то это уже было придумано аж в 2014 китайцами для некоторых их плат. При желании оно может быть и внутри блокчейна как Тьюринг-полные смарт-контракты. А теперь если вы скажете что проект большой и хочется типизации, интерфейсов и енумов — добро пожаловать в TypeScript.

А можете привести примеры тиражируемых бизнес-приложений, написаных полностью на JS, с возможностью расширения под конкретные требования клиента?

К сожалению, есть большая разница между «можно» и «удобно». И MongoDB — это не про бизнес-приложения. Там нужен ACID, если вы не хотите, чтобы у вас деньги в минус ушли.
Не взлетит.
Уже взлетело. Проект прибыльный. А вот на какую высоту — не столь принципиально. Мы просто хотим поделиться проектом с сообществом. Может кому-то будет интересно.
Я не про ваш бизнес план, прибыльными бывают еще и не такие проекты. Я про широкое распространение вашего ЯП.
Всё универсальное прекрасно. Тут в комментариях уже упоминали швейцарский нож. Скипнем, то что им непонятно, как пользоваться в реальной жизни. Тайга. Кухня. Ремонт. Пустыня. Охота. Рыбалка. Резьба. Яхта. Дайвинг. Монтаж.

Тут вот в чем прикол: у производителя универсальных швейцарских ножей Victorinox модельный ряд насчитывает сотни (!) разных моделей. Вот на этом вся универсальность и заканчивается. :-)
Скипнем, то что им непонятно, как пользоваться в реальной жизни

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

Тут вот в чем прикол: у производителя универсальных швейцарских ножей victorinox модельный ряд насчитывает сотни (!) разных моделей. Вот на этом вся универсальность и заканчивается. :-)

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

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

И? У нас тоже много разных решений на базе платформы. Какое это отношение имеет к универсальности?

Да никакого. Просто еще один, «15-ый стандарт» из картинки в самом начале. :-)

ps простите, промахнулся при ответе.
Не знаю, я не маркетолог. Дарить их, наверное, прикольно. А вы для чего-то другого их используете? Для чего?


Я, например, беру его в дорогу. И не раз меня выручал он, когда вдруг были нужны хоть какие-то ножницы или отвертка.

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

Да никакого. Просто еще один, «15-ый стандарт» из картинки в самом начале. :-)


Я картинку добавил только ради того, чтобы ее не добавили в комменты :) Повторюсь, что важен не язык, а сама технология. Аналогичных технологий, я, к сожалению, не знаю. Хотя конечно же есть решения, которые решают те же задачи, но по другому.
У нас с вами понятие «дорога» сильно разное. Если вам пакетик с чипсами в поезде надо открыть, колбаски порезать или винтик на селфи-палке/гопрошке подтянуть, то да — сгодится за неимением лучшего. На бОльшее этот инструмент не рассчитан. Попробуйте на сплаве им отрезать стальную проволку или закрутить обратно хоть какое-то крепление. А какой винт кстати, на креплении? Обычный, кретовый, торкс, шестигранник? А какого размера? А усилие выдержит или развалится вместе крепления «отвертки» к ножу?

Вы кажется, не очень понимаете, что такая «универсальность» — это просто маркетинговый ход. А иначе слона не продать.

Но ведь это все делают на смартфоне.

Кто все?.. «Все» в очередях за PS 5 стоят. Магазины завалены клавиатурами и джойстиками на любой вкус и цвет, а в интернете «все» офигаивают от цен на топовые видеокарты и что майнеры снова все скупили. У меня даже дети уже пару лет перестали играть на смартфонах, им там тупо играть не во что.

Мне кажется, что за универсальность вы принимаете совсем другое. Есть такая поговорка, «что на безрыбье — и рак рыба». Это не универсальность. ;-)

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

1. У вас под копотом вроде может быть любая СУБД? Как ее кофнигурировать? lsFusion разве это умеет?
2. Как кастомизировать интерфейс на lsFusion? Если ответ никак, то и про JS и CSS не надо говорить.
3. Как тюнить взаимодействие с БД(поправить план)? Если мне не изменяет память, у вас эта возможность не предоставлена.
4. Как описывать декларативно сложную бизнес логику? Например можно решать судоку на sql, но зачем?

Сложилось впечатление, что вы схлопнули Java/Python/eth + sql и выдаете это за инновационное решение. Не понял, чем это лучше Oracle PLSQL + apex например?

PS
Я говорил уже в комментариях к одной из прошлых статей, было бы классно рассмотреть примитивный проект решенный на Oracle + что-то и ваше решение на lsFusion. Сравнить преимущества и недостатки.
Как ее кофнигурировать?

Не совсем понял, что вы имеете ввиду? Если вы про настройки СУБД, то средствами самой СУБД. Но всю физмодель (таблицы и индексы) lsFusion генерирует сама на более высоком уровне (где впрочем возможности администрирования не менее гибкие)


Как кастомизировать интерфейс на lsFusion? Если ответ никак, то и про JS и CSS не надо говорить.

Нет, кастомизация очень гибкая и средствами lsFusion. Впрочем rendererы можно подменять любыми js компонентами если нужна тонкая настройка, но нужна она крайне редко на практике.


3. Как тюнить взаимодействие с БД(поправить план)? Если мне не изменяет память, у вас эта возможность не предоставлена.

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


4. Как описывать декларативно сложную бизнес логику? Например можно решать судоку на sql, но зачем?

Как раз lsFusion гораздо лучше подходит именно для сложной логики именно благодаря очень высокой способности к декомпозиции (когда все разбивается на много маленьких правил, которые затем при выполнении автоматически объединяются платформой). Естественно речь идёт об архитектурно а не алгоритмически сложной логике. Алгоритмически сложной логики в информационных системах обычно хорошо если 5 процентов.


Сложилось впечатление, что вы схлопнули Java/Python/eth + sql и выдаете это за инновационное решение. Не понял, чем это лучше Oracle PLSQL + apex например?

Нет. lsFusion именно что дообщает SQL из реляционной логики в обычную функциональную (полноценный язык программирования), и по сути тем самым реализует function level парадигму программирования (язык на ограниченном числе операторов и только чистыми функциями, о чем я писал выше). Хотя и императивщина в нем тоже есть но гораздо более высокоуровневая. То есть lsFusion смешивает парадигмы, а не сшивает (если брать вашу аналогию).


PS: возьмите любой пример из try online и попробуйте сделать на Oracle плюс что то (например УМП, где обратите внимание на контроль отрицательных остатков) и увидите разницу.

Не совсем понял, а кто целевая аудитория у данного проекта?

Та же, например, что и у платформы 1С.
Но представьте себя на месте человека, который только “вошел в ИТ”, и не хочет глубоко заниматься программированием, а просто хочет разрабатывать бизнес-приложения. Например, до этого он был бизнес-аналитиком, системным администратором или просто менеджером.

Они?

В том числе.

Ну на вскидку.


  1. Люди без опыта ИТ или около ИТ опытом (администраторы). Это как минимум простой способ сделать первый шаг в ИТ, ну и лучше подходит для людей которым нравятся бизнес-приложения и общение с людьми (да такие есть)
  2. Разработчики других высокоуровневых платформ вроде 1С и ПХП. Здесь все "высокоуровневее" на порядок.
  3. Перфекционисты, так как по сути lsFusion это такая функциональщина и реактивность в абсолюте.
  4. Инноваторы, тем кому нравится когда сильно не как все.
  5. Опен-сорсеры, фанаты когда все должно быть опен-сорс, а lsFusion практически единственная опен-сорс платформа такого высокого уровня (то есть таким уровнем декларативности и например со встроенными планировщиком, политикой безопасности, интерпретатором, и вот этим вот всем).

Ну и есть естественно смеси всех этих кейсов (так как я на самом деле тут теплое с мягким смешал)

Зарегистрируйтесь на Хабре , чтобы оставить комментарий