«мы как МС офис, только бесплатный, пусть и с несколько урезанными возможностями»
Не понял, а что делать если у вас и опен-сорс и он лучше платных аналогов? Не говорить что и почему он лучше?
а не «МС Офис хавно по вот этому списку придуманных нами причин
«Придуманных нами» это по вашему мнению. А вот по разговорам с реальными разработчиками, их комментам и плюсам, а главное по мировому опыту используемому в других технологиях, проблемы более чем реальны. Хотя конечно тому, кто слаще брюквы ничего не ел…
но мы больше будем обсирать МС офис, чем говорить о нашем продукте»
Ну здравствуйте. Вот статья «Почему не 1С?» на которую вы явно намекаете. А вот статья "Почему lsFusion, а не 1С?", где пункт за пунктом рассказывается как эти проблемы решаются в «нашем продукте». И это касается всех статей. Собственно большинство рекламных материалов так и сделано, вот как у них, вот как у нас.
З.Ы. я тоже был бы рад иметь десяток клиентов, которых мог бы каждый месяц стричь за каждый чих, а уйти к другому — значит все РАНЕЕ потраченные деньги превращаются в пыль и надо тратить заново.
Я вам по секрету расскажу, что это касается в той или иной степени практически ЛЮБОЙ технологии. Тем более если технология позволяет низкоуровневая / императивная (аля 1С) и позволяет легко говнокодить.
Более того, это касается не только программирования. Попробуйте сменить электрика по ходу стройки дома. А там все куда проще чем скажем в относительно сложном бизнес-приложении.
Собственно на западе бизнес уже давно понял, что он выбирает себе ИТ-партнера а не ИТ-поставщика (почитайте любое интервью любой относительно крупной ИТ-компании).
Ну в lsFusion например это прозрачно. Вы задаете логику классов / наследования, свойств (полей) для классов, при этом вообще не парясь про таблицы. А дальше платформа сама уже решает (ну или администратор), все будет либо в таблице пользователь лежать и один join, либо все в разных и тогда несколько.
Тут скорее вопрос, что в современном SQL нормально наследование / полиморфизм не поддерживаются. Но это проблема не ООП парадигмы, а конкретных SQL реализаций.
Но, если у нас наследование? И мы из базового класса должны вытащить набор полей
А причем тут наследование? Из базового класса вытащить набор полей это про инкапсуляцию скорее.
И причем тут хранимые процедуры? Это такая же императивщина как и обычные структурные языки, только что данные между сервером приложений и сервером БД чуть меньше гуляют. Но там такая же N+1 проблема есть, как и у Java, C#, Python.
Такое ощущение, что вы говорите больше про структурное программирование. А это не равно процедурному
Так что вы тогда под процедурным понимаете? Абстрагирование? Так оно и в SQL есть, представления называется. И опять таки перпендикулярно во многом ООП. Хотя согласен, наверное термин структурное правильнее в данном случае.
Чтож, в любом случае нужно максимально разделить бизнес-правила от логики хранения. Потому что бизнес-правила и безнес-логика и без того очень сложные и если их нагружать техническими деталями хранения (джойны, конвертации типов, условия фильтрации и обобщенные табличные выражения), то читать такой код сложнее
Джойны, условия фильтрации содержат бизнес-логику (то есть essential complexity). Другое дело, что да SQL почему-то до сих пор завис на уровне таблиц, не поднявшись на уровень функций (почитайте ссылку выше, что я кидал) и поэтому привносит большую accidental complexity. Но в императивных языках с этим не сильно лучше.
ООП в любом случае борется с такой сложностью очень хорошо
ООП именно с сложностью из абзаца выше не борется от слова вообще. ООП (а именно наследование / полиморфизм) мощный инструмент в декомпозиции / модульности, тут не поспоришь, но он не про детали хранения / вычисления.
Вот в таком случае логика будет в чистом виде, без технических деталей…
Нет, как раз C#, Java очень императивные языки и там accidental complexity не сильно меньше чем в SQL. Если уж хотите уйти от императивности и «технических деталей» нужно идти в что-то куда более декларативное (аля того же lsFusion).
Т.е. у вас бизнес-логика более процедурная, либо более ООПшная
Нет. Это перпендикулярные понятия. Ну или у вас свое понимание процедурности.
То есть У вас вполне может быть логика очень активно использующая и наследование и полиморфизм и даже инкапсуляцию, при этом все это делать в комбинаторной парадигме (то есть высокоуровневых операторах аля SELECT… GROUP BY ...), а не процедурной (if'ах, циклах, переменных и вот этом вот всем). Например так в lsFusion делается.
Тут стоило бы определиться что понимается под объектно-ориентированной парадигмой? Потому как она состоит из де-факто двух перпендикулярных вещей (формально трех, но первые две друг без друга бессмысленны): наследования / полиморфизма и инкапсуляции.
Впрочем обе эти вещи в свою очередь перпендикулярны разрыву между процедурным (императивным, value-level, Java, C#, Python) и комбинаторным (декларативным, function-level, SQL) программированием (тут в разделе Немного теории про этот разрыв подробнее). И у вас отлично может использоваться объектно-ориентированная парадигма вместе с комбинаторной (аля SQL), как это сделано в lsFusion, впрочем как и с процедурной.
Так что противопоставлять объектно-ориентированную парадигму с процедурной это как-то глупо на мой взгляд. Правильнее говорить о противопоставлении процедурной (C, Java) и комбинаторной парадигм (SQL).
Git с их merge и rebase (а также поверх всего этого git flow, ну и github с его forkами, pull requestами и squash&merge). Это все как бы уже давно стандарт в мире разработки.
Люди без опыта ИТ или около ИТ опытом (администраторы). Это как минимум простой способ сделать первый шаг в ИТ, ну и лучше подходит для людей которым нравятся бизнес-приложения и общение с людьми (да такие есть)
Разработчики других высокоуровневых платформ вроде 1С и ПХП. Здесь все "высокоуровневее" на порядок.
Перфекционисты, так как по сути lsFusion это такая функциональщина и реактивность в абсолюте.
Инноваторы, тем кому нравится когда сильно не как все.
Опен-сорсеры, фанаты когда все должно быть опен-сорс, а lsFusion практически единственная опен-сорс платформа такого высокого уровня (то есть таким уровнем декларативности и например со встроенными планировщиком, политикой безопасности, интерпретатором, и вот этим вот всем).
Ну и есть естественно смеси всех этих кейсов (так как я на самом деле тут теплое с мягким смешал)
Давайте. Как я предлагал, давайте сделаем надстройку над существующим языком, например, 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), что со временем им никак не помешало. И если пытаться натянуть что-то революционно новое на старое, получится ни рыба ни мясо. Хотя не спорю, что с маркетинговой точки зрения идти от старого куда проще.
Я может быть неправ, но честно говоря гляди на пример из комментария сверху, не могу функциональщины под микроскопом разглядеть. Вложеные циклы и if-ы с брейками, это всё таки ближе к VB.
Дело не в циклах, а в их условиях. Но согласен, это наверное самый императивный пример, вы перейдите лучше в Try Online на вкладку Платформа. Там законченные (пусть и достаточно простые) логики без единой (!) строки императивного кода (скажем то же УМП). Хотя справедливости ради обычно распределение условно 80 на 20 (80 — декларативного, 20 — императивного кода).
Не пропущено, просто в чудеса не верю.
Ну мы старались делать все максимально законченным, с непересекающимися / непротиворечивыми абстракциями и как можно более стройной архитектурой. Насколько получилось время покажет.
Это как раз подтверждение что эта технология, это vendor-lock от маленькой компании. Возвращаемся к моему оригинальному комментарию.
Что не помешало ей по сути стать стандартом в отрасли и победить Eclipse с гораздо более сильной компанией стоящей за ней и гораздо большим комьюнити. ИМХО чисто потому, что у них продукт просто был лучше спроектирован (то есть даже не фундаментально лучше).
Не совсем понял с какого боку здесь VB, так как lsFusion это функциональщина возведённая в абсолют. Function-level программирование против value-level программирования (то есть архитектуры ноймана).
Описания классов как будто это таблица базы с constraints и т.п.? Ну это как раз то что можно реализовать своеё надстройкой над языком. И препроцессор может сгенерировать валидный код для подобного.
Вот честно не понимаю как и зачем. Программа на lsFusion состоит из очень большого числа различных маленьких правил (абстракций). Как это все натянуть на любой из существующих языков загадка. Так как принципиально другой подход.
Я не против того что вы свои язык делаете, на здоровье. Я в том что знания этого языка никуда не конвертируются, кроме как у очень ограниченного круга его пользователей. Можно надеяться что взлетит и всё случиться, но шансы очень низкие.
Ну про SQL, ООП (c++), Java, Fortran/C (структурное программирование) в свое время тоже так говорили. А по уровню paradigm shift (то есть новых идей) lsFusion им как минимум не уступает на мой взгляд. Но поживем увидим.
В документации выглядит хорошо, а в реальности будет художественный бег по граблям.
Здесь пропущено слово если :) Ну и в любом случае, скажем когда мы писали плагин IDEA мы фактически не обращались ни к вендору ни комьюнити (не факт что оно есть). Хотя ИМХО к архитектуре IDEA вопросов точно не меньше чем к 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 плюс что то (например УМП, где обратите внимание на контроль отрицательных остатков) и увидите разницу.
Посмотрел примеры кода на вашем языке, честно говоря не видно волшебства
Чисто для интереса, а можно пример чего то хотя бы близко похожего, с тем же уровнем декларативности и возможностями (скажем прозрачными материализациями, ограничениями, событиями, агрегациями и т.п.). Чтобы как в lsfusion.org/try можем было запустить (это например показывает уровень декларативности)
Для тех кто выбрал писать на нём видится большая проблема, это то что время на его изучение, это фактически выбрашенные в унитаз усилия. Шанс что это понадобится где-либо кроме двух с половиной конторах, стремиться к нулю.
Ну про SQL, функциональщину и т.п. тоже так в свое время говорили. В любом случае я знаю много людей, которые изучают, скажем, Haskell, а там вероятность использовать его на практике вообще в отрицательных величинах. Есть такая штука как просто профессиональный кругозор.
наверное имел бы смысл расширить один из известных языков своим синтаксисом и не мучать пользователей.
95% процентов абстракций lsFusion просто не лягут на синтаксис (а точнее логику) ни одного из известных языков. Уж очень сильно отличаются парадигмы. Да и даже если удалось бы, в чем выигрыш? Ну скажем .Net встроил linq в язык, и? Да, прикольно, но многие продолжают работать с запросами в строках и это точно не killer feature.
Кстати еще один вопрос, а как в SalesForce Apex с прикладными абстракциями вроде Ledger'ов? Они в языке, в виде стандартизированных библиотек или вообще на разработчике? И как с визуальным программированием этих и других прикладных абстракций? Конструкторами или кодом в основном все делается (имеется в виду на практике, а не в презенташках)?
А можно пример кода где-нибудь увидеть? Что-то вроде, при нажатии кнопки, проверить если инвойсе сумма больше 100, спросить у пользователя поручителя, проверить что у поручителя лимит не превышен, спросить у пользователя подтверждение, перевести инвойс в следующий статус.
А как, кстати в Apex workflow делается? В смысле если надо что-то считать на сервере, потом спросить пользователя, потом что-то в зависимости от его ответа опять считать на сервере, опять спросить пользователя и т.д. То есть существует разделение на клиент и сервер? Где клиентские действия (типа открытия формы или сообщения), можно выполнять только на клиенте (или другими словами с сервера обращаться к клиенту).
Я если честно не совсем понимаю какой именно тезис — первый. Но с аргументом что «А — неверно» спорить тяжело. Я думаю мы друг друга поняли. Вы считаете, что все эти технические фишки — «essential complexity», я — «accidental complexity». Но так как четких метрик для определения этих complexity нет, спорить с вами действительно бесполезно. Все равно каждый останется при своем.
Но мы же не программисты ради того чтобы быть программисты. Наша цель решать задачи поставленные заказчиком. И если для решения этих задач, нам нужно заниматься какой-то технической ерундой (не имеющих прямого отношения к задаче), значит мы скорее всего плохие инструменты используем. То есть мне может лопата очень нравится, но строить дом я буду с использованием бульдозера.
Не понял, а что делать если у вас и опен-сорс и он лучше платных аналогов? Не говорить что и почему он лучше?
«Придуманных нами» это по вашему мнению. А вот по разговорам с реальными разработчиками, их комментам и плюсам, а главное по мировому опыту используемому в других технологиях, проблемы более чем реальны. Хотя конечно тому, кто слаще брюквы ничего не ел…
Ну здравствуйте. Вот статья «Почему не 1С?» на которую вы явно намекаете. А вот статья "Почему lsFusion, а не 1С?", где пункт за пунктом рассказывается как эти проблемы решаются в «нашем продукте». И это касается всех статей. Собственно большинство рекламных материалов так и сделано, вот как у них, вот как у нас.
Я вам по секрету расскажу, что это касается в той или иной степени практически ЛЮБОЙ технологии. Тем более если технология позволяет низкоуровневая / императивная (аля 1С) и позволяет легко говнокодить.
Более того, это касается не только программирования. Попробуйте сменить электрика по ходу стройки дома. А там все куда проще чем скажем в относительно сложном бизнес-приложении.
Собственно на западе бизнес уже давно понял, что он выбирает себе ИТ-партнера а не ИТ-поставщика (почитайте любое интервью любой относительно крупной ИТ-компании).
Тут скорее вопрос, что в современном SQL нормально наследование / полиморфизм не поддерживаются. Но это проблема не ООП парадигмы, а конкретных SQL реализаций.
А причем тут наследование? Из базового класса вытащить набор полей это про инкапсуляцию скорее.
И причем тут хранимые процедуры? Это такая же императивщина как и обычные структурные языки, только что данные между сервером приложений и сервером БД чуть меньше гуляют. Но там такая же N+1 проблема есть, как и у Java, C#, Python.
Так что вы тогда под процедурным понимаете? Абстрагирование? Так оно и в SQL есть, представления называется. И опять таки перпендикулярно во многом ООП. Хотя согласен, наверное термин структурное правильнее в данном случае.
Джойны, условия фильтрации содержат бизнес-логику (то есть essential complexity). Другое дело, что да SQL почему-то до сих пор завис на уровне таблиц, не поднявшись на уровень функций (почитайте ссылку выше, что я кидал) и поэтому привносит большую accidental complexity. Но в императивных языках с этим не сильно лучше.
ООП именно с сложностью из абзаца выше не борется от слова вообще. ООП (а именно наследование / полиморфизм) мощный инструмент в декомпозиции / модульности, тут не поспоришь, но он не про детали хранения / вычисления.
Нет, как раз C#, Java очень императивные языки и там accidental complexity не сильно меньше чем в SQL. Если уж хотите уйти от императивности и «технических деталей» нужно идти в что-то куда более декларативное (аля того же lsFusion).
Нет. Это перпендикулярные понятия. Ну или у вас свое понимание процедурности.
То есть У вас вполне может быть логика очень активно использующая и наследование и полиморфизм и даже инкапсуляцию, при этом все это делать в комбинаторной парадигме (то есть высокоуровневых операторах аля SELECT… GROUP BY ...), а не процедурной (if'ах, циклах, переменных и вот этом вот всем). Например так в lsFusion делается.
Впрочем обе эти вещи в свою очередь перпендикулярны разрыву между процедурным (императивным, value-level, Java, C#, Python) и комбинаторным (декларативным, function-level, SQL) программированием (тут в разделе Немного теории про этот разрыв подробнее). И у вас отлично может использоваться объектно-ориентированная парадигма вместе с комбинаторной (аля SQL), как это сделано в lsFusion, впрочем как и с процедурной.
Так что противопоставлять объектно-ориентированную парадигму с процедурной это как-то глупо на мой взгляд. Правильнее говорить о противопоставлении процедурной (C, Java) и комбинаторной парадигм (SQL).
Git с их merge и rebase (а также поверх всего этого git flow, ну и github с его forkами, pull requestами и squash&merge). Это все как бы уже давно стандарт в мире разработки.
Ну на вскидку.
Ну и есть естественно смеси всех этих кейсов (так как я на самом деле тут теплое с мягким смешал)
Еще раз, нужно понимать что 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, поэтому ориентироваться логичнее было на него, что мы и делали.
Вы же понимаете, что в программировании знание парадигмы программирования важнее чем знание синтаксиса. Скажем у нас в свое время большинство людей обучались на Pascal, но после него очень легко переходили на Java или C или Python. Я собственно в свое время писал на C++, потом на Foxpro, сейчас на Java (у меня переход неделю занимал), периодически переходя на JavaScript, Groovy или Python. Выучить синтаксис это плевое дело. Выучиться парадигме (той же функциональщине) гораздо сложнее. Поэтому натягивать парадигму на чужой синтаксис дело неблагодарное (скажем те же LINQ с лямбдами то что вы предлагаете как замену GROUP SUM, а) более громоздкий, б) для человека не знакомого с функциональщиной гораздо более сложный для понимания).
Все новые языки / парадигмы / идеи в свое время делались с нуля (причем часто не пойми кем, скажем тот же Python), что со временем им никак не помешало. И если пытаться натянуть что-то революционно новое на старое, получится ни рыба ни мясо. Хотя не спорю, что с маркетинговой точки зрения идти от старого куда проще.
Дело не в циклах, а в их условиях. Но согласен, это наверное самый императивный пример, вы перейдите лучше в Try Online на вкладку Платформа. Там законченные (пусть и достаточно простые) логики без единой (!) строки императивного кода (скажем то же УМП). Хотя справедливости ради обычно распределение условно 80 на 20 (80 — декларативного, 20 — императивного кода).
Ну мы старались делать все максимально законченным, с непересекающимися / непротиворечивыми абстракциями и как можно более стройной архитектурой. Насколько получилось время покажет.
Что не помешало ей по сути стать стандартом в отрасли и победить Eclipse с гораздо более сильной компанией стоящей за ней и гораздо большим комьюнити. ИМХО чисто потому, что у них продукт просто был лучше спроектирован (то есть даже не фундаментально лучше).
Не совсем понял с какого боку здесь VB, так как lsFusion это функциональщина возведённая в абсолют. Function-level программирование против value-level программирования (то есть архитектуры ноймана).
Вот честно не понимаю как и зачем. Программа на lsFusion состоит из очень большого числа различных маленьких правил (абстракций). Как это все натянуть на любой из существующих языков загадка. Так как принципиально другой подход.
Ну про SQL, ООП (c++), Java, Fortran/C (структурное программирование) в свое время тоже так говорили. А по уровню paradigm shift (то есть новых идей) lsFusion им как минимум не уступает на мой взгляд. Но поживем увидим.
Здесь пропущено слово если :) Ну и в любом случае, скажем когда мы писали плагин IDEA мы фактически не обращались ни к вендору ни комьюнити (не факт что оно есть). Хотя ИМХО к архитектуре IDEA вопросов точно не меньше чем к lsFusion.
Не совсем понял, что вы имеете ввиду? Если вы про настройки СУБД, то средствами самой СУБД. Но всю физмодель (таблицы и индексы) lsFusion генерирует сама на более высоком уровне (где впрочем возможности администрирования не менее гибкие)
Нет, кастомизация очень гибкая и средствами lsFusion. Впрочем rendererы можно подменять любыми js компонентами если нужна тонкая настройка, но нужна она крайне редко на практике.
Платформа сама генерирует запросы (в частности группирует вычисления, что обеспечивает очень высокую декомпозицию, делает инкрементальные вычисления что обеспечивает очень высокую реактивность, умеет использовать материализации, что обеспечивает очень высокую производительность и т.п.). Поэтому поправлять запросы руками это весьма неблагодарный труд, и поэтому в lsFusion пришлось делать очень крутой оптимизатор запросов (см. статью Почему не SQL). Соответственно когда необходимо улучшить производительность это обычно делают изменением физической модели и рядом более высокоуровневых хинтов (типа надо материализовать изменения свойства или нет).
Как раз lsFusion гораздо лучше подходит именно для сложной логики именно благодаря очень высокой способности к декомпозиции (когда все разбивается на много маленьких правил, которые затем при выполнении автоматически объединяются платформой). Естественно речь идёт об архитектурно а не алгоритмически сложной логике. Алгоритмически сложной логики в информационных системах обычно хорошо если 5 процентов.
Нет. lsFusion именно что дообщает SQL из реляционной логики в обычную функциональную (полноценный язык программирования), и по сути тем самым реализует function level парадигму программирования (язык на ограниченном числе операторов и только чистыми функциями, о чем я писал выше). Хотя и императивщина в нем тоже есть но гораздо более высокоуровневая. То есть lsFusion смешивает парадигмы, а не сшивает (если брать вашу аналогию).
PS: возьмите любой пример из try online и попробуйте сделать на Oracle плюс что то (например УМП, где обратите внимание на контроль отрицательных остатков) и увидите разницу.
Чисто для интереса, а можно пример чего то хотя бы близко похожего, с тем же уровнем декларативности и возможностями (скажем прозрачными материализациями, ограничениями, событиями, агрегациями и т.п.). Чтобы как в lsfusion.org/try можем было запустить (это например показывает уровень декларативности)
Ну про SQL, функциональщину и т.п. тоже так в свое время говорили. В любом случае я знаю много людей, которые изучают, скажем, Haskell, а там вероятность использовать его на практике вообще в отрицательных величинах. Есть такая штука как просто профессиональный кругозор.
95% процентов абстракций lsFusion просто не лягут на синтаксис (а точнее логику) ни одного из известных языков. Уж очень сильно отличаются парадигмы. Да и даже если удалось бы, в чем выигрыш? Ну скажем .Net встроил linq в язык, и? Да, прикольно, но многие продолжают работать с запросами в строках и это точно не killer feature.
Блокировки в системах контроля версий уже лет 20 не используются. И не только из-за git flow, а просто потому что это дико неудобно.