• Убийца 1С на 1С
    0
    Ключевая разница там скорее в другом. В lsFusion единый поток выполнения (и он на сервере). Но при этом можно выполнять «клиентские» операции (например открывать форму, то есть грубо говоря &НаСервере обращаться к &НаКлиенте). Тут примеры есть.

    habr.com/ru/company/lsfusion/blog/468415/#controlflow
    habr.com/ru/company/lsfusion/blog/544982/#Controlflow

    Но клиентский код вообще имеет смысл выполнять только для всяких интеграций, сами данные и представления формы (model и view) обновляются реактивно автоматически платформой.
  • Убийца 1С на 1С
    0
    Что вы зациклились на этой нишевости? Это как раз 1С по сути нишевое ПО с их этими абстракциями документов и регистров. По сути это в основном финучет (собственно это хорошо видно, когда 1Сцы при обсуждение платформы спрашивают про расчет себестоимости, который к платформе никакого отношения). Да есть извращенцы, которые используют 1С для WMS, ЭДО, Розницы и даже CRM с банками, но это именно что исключение, подчеркивающее общее правило (так как на этих рынках 1С далеко не лидеры, и вообще ее обычно используют прицепом к бухгалтерии УТ).

    У lsFusion куда более широкий спектр применения (то есть не такая узкая песочница), по сути ее можно использовать везде где можно использовать SQL (то есть и для CRM, и для банков и всего остального).

    «сравнения, над которыми только плакать». Ну уж над многими комментами 1С разработчиков только смеяться можно :) Особенно когда они пытаются выйти чуть дальше за пределы своей песочницы.
  • Убийца 1С на 1С
    +1
    1С выпустила почти идеальную платформу для быстрой разработки небольших индивидуальных решений в короткие сроки и за мелкий прайс! Там все для этого, от декларативного интерфейса до мобильной платформы. Любой 1С программист понимает, что кучу мелких кейсов можно было бы закрыть просто на ходу, а решение получилось бы вполне годным, что бы его продавать.

    Но нет же — самой 1С это абсолютно не интересно. Ей подавай серьезный Энтерпрайз, с миллионными бюджетами. При том, что как раз для таких проектов платформа так себе — уже десятки статей как про чудовищную реализацию платформы в плане взаимодействия с сервером БД, коллективной разработки, синтаксиса и вот этого всего, так и про забагованность и тяжеловесность типовых конфигураций. НО денег все равно хочется поэтому продолжаем пилить КОРП-сектор на платформе для быстрого прототипирования — а куда деваться… (

    Очень во многом соглашусь. Но надо понимать, что для быстрого прототипирования это все же сейчас ближе к рынку так называемых no-code / low-code, аля airtable, mendix
    airtable.com
    mendix.com
    Этот рынок сейчас достаточно моден и активно развивается, но туда 1С было бы очень трудно влезть (так как там все заточено под пользовательскую разработку). Поэтому сейчас они действительно в какой-то странной полупозиции, ни нашим ни вашим.
  • Убийца 1С на 1С
    0
    Ну так посмотрите. Сильно удивитесь, но там в основном доработки именно последних типовых. И берут на фултайм в штат в отделы по 20 человек.
  • Убийца 1С на 1С
    0
    2+2=5 вы можете написать в любой технологии, это вопрос к конкретным решениям, а не к платформе. Скажем в MyCompany это не надо. А в ERP розницы например надо. (хотя я не специалист по этим решениям, просто догадка)

    В любом случае все начинает опять в срач скатываться, так что давайте закончим на этом.
  • Убийца 1С на 1С
    0
    Да, да, я в курсе. Просто люди очень заняты, чтобы приходить на дебаты перед избирателями. А не потому что им сказать нечего, или их просто размажут в очной дуэли.
  • Убийца 1С на 1С
    0
    Только тот же хедхантер с вами не согласен. 3000 вакансий программистов 1С в одной только Москве прямо кричит о том, что
    «массовая доработка» в 1С за последние 20 лет сильно прошла

    Раньше, там сколько было 30000 что ли?
  • Убийца 1С на 1С
    0
    Так в том то и дело, что речь о ФУНДАМЕНТАЛЬНЫХ преимуществах. НИШЕВЫЕ это вот как раз эта тонкая кастомизация клиента, о которой мы спорили выше / ниже, которая 99 процентам бизнес-приложений нафиг не нужна.
  • Убийца 1С на 1С
    0
    Я же написал для бизнес-приложений возможность доработки (проходимость в поле) куда важнее утилизации клиентского оборудования / гибкости клиентской «морды» (то есть красоты и разгона на прямом ровном асфальте до 200км/ч). Это вроде как очевидные вещи. Но если вам не очевидны, то спорить действительно не о чем.
  • Убийца 1С на 1С
    0
    Это что за ОЧЕНЬ специализированная и нишевая тема? FMCG розница — половина всей розницы (то есть четверть торговли)? WMS (не бухгалтерия конечно, но все же один из основных модулей у любого оптовика, логиста, торговой сети)?

    И опять-таки платформы бизнес-приложений во многом УНИВЕРСАЛЬНЫ, то есть на них можно писать любые модули (что FA, что SCM, что WMS, что Retail). Не пойму что за специализированную и нишевую тему вы имеете в виду?
  • Убийца 1С на 1С
    0
    но почему же эти гады всё ещё сидят на 1С)
    по факту

    Ну это как бы очевидно, большая клиентская база (привет КОБОЛу), бешеный принтер + большое количество разработчиков на консолидированном рынке. При таких вводных платформа может быть на порядки хуже и все равно многие будут продолжать сидеть на ней. Во всяком случае какое-то время.
    И ладно бы ваш продукт был хотя бы в той же «весовой» категории по функционалу

    Мы сейчас про платформу или решения? Потому как про платформу мимо. lsFusion умеет в РАЗЫ больше чем 1С (речь понятно не о всяких свистоперделках, а о фундаментальных вещах вроде той же распространенной сейчас реактивности). Точно также как электромобили умеют то, что бензиновые не умеют в принципе. Но опять-таки мы из пустого в порожнее переливаем. Реально было бы интересно почитать статью где описывались преимущества 1С перед другими платформами, в формате как в блоге у lsFusion, но к сожалению ничего такого нет.
  • Убийца 1С на 1С
    0
    Передача только нужных данных на сервер позволяет снять долю нагрузки с вычислительных мощностей, что скорее всего было сделано для работы «громоздких» решений типа КА и ЕРП. Так как масштабы данных и функций в вашем решении на порядки меньше, чем в 1С — естественно вам не знакомы эти проблемы

    Вы просто не представляете себе сложность решений у наших заказчиков. Там по 5 весьма сложных задач в день решается в течении 7 лет (причем есть большая общая кодовая база и типовая основа). И объемы террабайтные, а ОДНОВРЕМЕННЫХ пользователей уже больше 1к.

    Но дело не в том, во-первых:
    1) Вы определитесь для кого 1С, для сложных custom-made решений (но там кастомизация очень важна и увеличенная сложность доработки убьет теоретический выигрыш в железе на огромном количестве пользователей), или для небольших компаний, тогда тем более этот выигрыш не существенен.
    2) Я не совсем понял, вы собираетесь лучше утилизировать клиентские процессоры? Серьезно? Там даже с точки зрения теории массового обслуживания это глупо, не говоря уже о всяких потреблении энергии устройствами и т.п.
    То есть разделение и не разделение — это буквально 2 РАЗНЫХ подхода, каждый из который хорош в своей ситуации — но ваша статья составлена так, что это подаётся именно как неправильное решение

    Да, для БИЗНЕС-ПРИЛОЖЕНИЙ это глупое решение. В 99 процентов случаев. Почему написал выше, да и в самой статье было. Точно также как на тракторе на работу ездить или на ламборгини поле пахать. Хотя это тоже два разных подхода.
  • Убийца 1С на 1С
    0
    Как раз со 100 мелкими магазинчиками стоимость проекта обычно не такая большая, чтобы забить на лицензии.

    И в развивающихся экономиках где стоимость капитала достаточно высокая так просто забить на CAPEX'ы невозможно (точнее они генерируют достаточно значимые OPEX'ы).
  • Убийца 1С на 1С
    0
    Можно вообще решить «отраслевую» специфику парой доработанных документов

    Жалко мне заказчиков у которых «отраслевая специфика» решается парой доработанных документов. Потому как потому в таких случаев обычно количество персонала для работы с системой увеличивается в разы. Это бич сложных универсальных решений поставляемых «как есть» (ешьте что дают). Первой эту болезнь САП принесла, а теперь, учитывая что сложность решений растет, а платформа такая же монолитная и низкоуровневая ей и 1С заболела.
    Причем ломбарды довольно сильно «закручены» законами, поэтому не думаю, что разработки от «дяди Васи» будут выгоднее.

    Я может чего-то не понимаю, но там скорее всего как раз разработки от «дяди Васи» и работают, также как в FMCG от Астора, в WMS от Акселота и т.п. И так в очень большом количестве секторов.
  • Убийца 1С на 1С
    0
    А можно на примере?

    Вот скажем один из разделов:
    habr.com/ru/company/lsfusion/blog/468415/#visual
    Там преимущества и недостатки.

    Каких по вашему преимуществ там не хватает? И сам факт что весь мир давно ушел в Everything as a code вас не смущает?
  • Убийца 1С на 1С
    0
    1 — выставлять себя в выгодном свете и кидаться какахами — разное.

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

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

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

    В той статье сто раз задавался вопрос, укажите где конкретно автор не прав. В ответ было только «кидание какахами» как вы говорите (ну или вообще ответа не было).
    Одна половина «проблем» придумана и вами вообще не изучена в 1С, в другой половине вы рассматриваете 2 разных подхода, но ваш оказывается (по неведомой причине) более «правильный». Причем вы рассматриваете только негативные стороны выбора 1С, не затрагивая причины этого решения, что настолько несет однобокостью, что глазам больно

    Да ладно. Там как раз почти во всех разделах сказано почему так получилось скорее всего, и в том числе и плюсы обоих подходов есть.
    Особенно смешно, когда вы в одних вопросах пишете о том, что «наше решение упрощает работу разработчикам», то есть как бы жертвуете удобством пользователей — и это хорошо. И рядом же пишете о моментах, где вы делаете удобнее пользователям, слегка жертвуя удобством разработчиков — и это тоже хорошо. Чувствуете логику? Вот и я нет)

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

    Ну не знаю, по опыту на хабре как раз размахивание какахами очень не любят. А вот технические статьи с деталями наоборот. Гляньте ту же Почему не SQL или Почему не 1С. А вот от разработчиков 1С в комментах в лучшем случае именно это ваше размахивание какахами («автор не разобрался» и вообще «сперва добейся»).
  • Убийца 1С на 1С
    0
    Если так рассуждать, то им тогда скорее SaaS подойдет.

    Ну и опять-таки непонятно, что значит типовой? Возьмем скажем ломбард. Ему УТ никак не подойдет (точнее теоретически и обезьяну можно научить курить, но это будет скорее мучение чем работа). Ему нужно специализированное решение (плюс еще ломбарды отличаются друг от друга). А ломбарды бизнесы небольшие много не заплатят, поэтом если разработчику этого решения еще при этом (непонятно зачем) делиться с 1С, так прибыль вообще в ноль уйдет. Я так понимаю речь об этом.
  • Убийца 1С на 1С
    0
    Ну тогда мы о разных вещах разговариваем. Хотя я помню проекты, где мы у 1С выигрывали легко, так как у клиента было под 100 небольших магазинов, и там только лицензии на все эти магазины тянули в сумме очень прилично.
  • Убийца 1С на 1С
    0
    «типовую» конфигурацию найти замену можно по щелчку пальцев, а польстившись на дешевую начальную цену «нетленки» оказываешься заложником разработчика

    Серьезно? Вы сами хоть раз пробовали? Если типовая хотя бы лет 5 постоянно дорабатывалась (а это >80% всех клиентов чуть больше ларьков). По сложности, по большому один черт, что там в основе было, так как одна строка кода может создать проблем больше, чем полностью с нуля написанная программа.

    Хотя конечно вопрос тут больше к тому насколько высокоуровневая платформа. Понятно что если решение на Java или 1С написано, без наследования, типизации, со строковыми запросами, лапшекодом и т.п. это одно, а если на чем то более высокоуровневом, с полиморфизмом и т.п. — другое.
    Все риски оказываются только на стороне покупателя, который и деньги тратит, так еще и не контролирует процесс.

    Риски всегда на стороне покупателя. Еще раз, простой пример с электриком. Я два раза делал ремонт, два раза был недоволен электриком и оба раза мне каждый новый электрик, на которого я хотел сменить старого, мне говорил, что проще вам договориться со старым, так как я ни за что отвечать не буду. В итоге приходилось договариваться. И это «всего лишь» электрика, в бизнес-приложениях все еще хуже.
  • Убийца 1С на 1С
    0
    Вот интересно, откуда тогда столько вакансий 1С разработчиков В ШТАТ НА ПОЛНУЮ СТАВКУ (причем порой десяток человек), если в типовых «функционала столько, что клиенту есть еще куда расти». И откуда столько разработчиков? Может потому что разработчик / платформа это неотъемлемая часть любого решения, и типовая это не более чем полуфабрикат.
  • Убийца 1С на 1С
    0
    «мы как МС офис, только бесплатный, пусть и с несколько урезанными возможностями»

    Не понял, а что делать если у вас и опен-сорс и он лучше платных аналогов? Не говорить что и почему он лучше?
    а не «МС Офис хавно по вот этому списку придуманных нами причин

    «Придуманных нами» это по вашему мнению. А вот по разговорам с реальными разработчиками, их комментам и плюсам, а главное по мировому опыту используемому в других технологиях, проблемы более чем реальны. Хотя конечно тому, кто слаще брюквы ничего не ел…
    но мы больше будем обсирать МС офис, чем говорить о нашем продукте»

    Ну здравствуйте. Вот статья «Почему не 1С?» на которую вы явно намекаете. А вот статья "Почему lsFusion, а не 1С?", где пункт за пунктом рассказывается как эти проблемы решаются в «нашем продукте». И это касается всех статей. Собственно большинство рекламных материалов так и сделано, вот как у них, вот как у нас.
  • Убийца 1С на 1С
    +1
    З.Ы. я тоже был бы рад иметь десяток клиентов, которых мог бы каждый месяц стричь за каждый чих, а уйти к другому — значит все РАНЕЕ потраченные деньги превращаются в пыль и надо тратить заново.

    Я вам по секрету расскажу, что это касается в той или иной степени практически ЛЮБОЙ технологии. Тем более если технология позволяет низкоуровневая / императивная (аля 1С) и позволяет легко говнокодить.

    Более того, это касается не только программирования. Попробуйте сменить электрика по ходу стройки дома. А там все куда проще чем скажем в относительно сложном бизнес-приложении.

    Собственно на западе бизнес уже давно понял, что он выбирает себе ИТ-партнера а не ИТ-поставщика (почитайте любое интервью любой относительно крупной ИТ-компании).
  • Организация бизнес-логики корпоративных приложений. Какие возможны варианты?
    0
    Ну в lsFusion например это прозрачно. Вы задаете логику классов / наследования, свойств (полей) для классов, при этом вообще не парясь про таблицы. А дальше платформа сама уже решает (ну или администратор), все будет либо в таблице пользователь лежать и один join, либо все в разных и тогда несколько.

    Тут скорее вопрос, что в современном SQL нормально наследование / полиморфизм не поддерживаются. Но это проблема не ООП парадигмы, а конкретных SQL реализаций.
  • Организация бизнес-логики корпоративных приложений. Какие возможны варианты?
    0
    Но, если у нас наследование? И мы из базового класса должны вытащить набор полей

    А причем тут наследование? Из базового класса вытащить набор полей это про инкапсуляцию скорее.

    И причем тут хранимые процедуры? Это такая же императивщина как и обычные структурные языки, только что данные между сервером приложений и сервером БД чуть меньше гуляют. Но там такая же N+1 проблема есть, как и у Java, C#, Python.
  • Организация бизнес-логики корпоративных приложений. Какие возможны варианты?
    0
    Такое ощущение, что вы говорите больше про структурное программирование. А это не равно процедурному

    Так что вы тогда под процедурным понимаете? Абстрагирование? Так оно и в SQL есть, представления называется. И опять таки перпендикулярно во многом ООП. Хотя согласен, наверное термин структурное правильнее в данном случае.
    Чтож, в любом случае нужно максимально разделить бизнес-правила от логики хранения. Потому что бизнес-правила и безнес-логика и без того очень сложные и если их нагружать техническими деталями хранения (джойны, конвертации типов, условия фильтрации и обобщенные табличные выражения), то читать такой код сложнее

    Джойны, условия фильтрации содержат бизнес-логику (то есть essential complexity). Другое дело, что да SQL почему-то до сих пор завис на уровне таблиц, не поднявшись на уровень функций (почитайте ссылку выше, что я кидал) и поэтому привносит большую accidental complexity. Но в императивных языках с этим не сильно лучше.
    ООП в любом случае борется с такой сложностью очень хорошо

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

    Нет, как раз C#, Java очень императивные языки и там accidental complexity не сильно меньше чем в SQL. Если уж хотите уйти от императивности и «технических деталей» нужно идти в что-то куда более декларативное (аля того же lsFusion).
  • Организация бизнес-логики корпоративных приложений. Какие возможны варианты?
    0
    Т.е. у вас бизнес-логика более процедурная, либо более ООПшная

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

    То есть У вас вполне может быть логика очень активно использующая и наследование и полиморфизм и даже инкапсуляцию, при этом все это делать в комбинаторной парадигме (то есть высокоуровневых операторах аля SELECT… GROUP BY ...), а не процедурной (if'ах, циклах, переменных и вот этом вот всем). Например так в lsFusion делается.
  • Организация бизнес-логики корпоративных приложений. Какие возможны варианты?
    0
    Тут стоило бы определиться что понимается под объектно-ориентированной парадигмой? Потому как она состоит из де-факто двух перпендикулярных вещей (формально трех, но первые две друг без друга бессмысленны): наследования / полиморфизма и инкапсуляции.
    Впрочем обе эти вещи в свою очередь перпендикулярны разрыву между процедурным (императивным, value-level, Java, C#, Python) и комбинаторным (декларативным, function-level, SQL) программированием (тут в разделе Немного теории про этот разрыв подробнее). И у вас отлично может использоваться объектно-ориентированная парадигма вместе с комбинаторной (аля SQL), как это сделано в lsFusion, впрочем как и с процедурной.

    Так что противопоставлять объектно-ориентированную парадигму с процедурной это как-то глупо на мой взгляд. Правильнее говорить о противопоставлении процедурной (C, Java) и комбинаторной парадигм (SQL).
  • lsFusion vis 1С
    +1

    Git с их merge и rebase (а также поверх всего этого git flow, ну и github с его forkами, pull requestами и squash&merge). Это все как бы уже давно стандарт в мире разработки.

  • Зачем нам понадобился еще один язык программирования
    0

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


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

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

  • Зачем нам понадобился еще один язык программирования
    0
    Давайте. Как я предлагал, давайте сделаем надстройку над существующим языком, например, 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), что со временем им никак не помешало. И если пытаться натянуть что-то революционно новое на старое, получится ни рыба ни мясо. Хотя не спорю, что с маркетинговой точки зрения идти от старого куда проще.
  • Зачем нам понадобился еще один язык программирования
    0
    Я может быть неправ, но честно говоря гляди на пример из комментария сверху, не могу функциональщины под микроскопом разглядеть. Вложеные циклы и if-ы с брейками, это всё таки ближе к VB.

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

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

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

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


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

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


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

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


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

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

  • Зачем нам понадобился еще один язык программирования
    0
    Как ее кофнигурировать?

    Не совсем понял, что вы имеете ввиду? Если вы про настройки СУБД, то средствами самой СУБД. Но всю физмодель (таблицы и индексы) 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 плюс что то (например УМП, где обратите внимание на контроль отрицательных остатков) и увидите разницу.

  • Зачем нам понадобился еще один язык программирования
    0
    Посмотрел примеры кода на вашем языке, честно говоря не видно волшебства

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

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

    95% процентов абстракций lsFusion просто не лягут на синтаксис (а точнее логику) ни одного из известных языков. Уж очень сильно отличаются парадигмы. Да и даже если удалось бы, в чем выигрыш? Ну скажем .Net встроил linq в язык, и? Да, прикольно, но многие продолжают работать с запросами в строках и это точно не killer feature.
  • Salesforce Apex – как первый язык программирования. Плюсы и минусы
    0
    Кстати еще один вопрос, а как в SalesForce Apex с прикладными абстракциями вроде Ledger'ов? Они в языке, в виде стандартизированных библиотек или вообще на разработчике? И как с визуальным программированием этих и других прикладных абстракций? Конструкторами или кодом в основном все делается (имеется в виду на практике, а не в презенташках)?
  • Salesforce Apex – как первый язык программирования. Плюсы и минусы
    0
    А можно пример кода где-нибудь увидеть? Что-то вроде, при нажатии кнопки, проверить если инвойсе сумма больше 100, спросить у пользователя поручителя, проверить что у поручителя лимит не превышен, спросить у пользователя подтверждение, перевести инвойс в следующий статус.
  • Salesforce Apex – как первый язык программирования. Плюсы и минусы
    0
    А как, кстати в Apex workflow делается? В смысле если надо что-то считать на сервере, потом спросить пользователя, потом что-то в зависимости от его ответа опять считать на сервере, опять спросить пользователя и т.д. То есть существует разделение на клиент и сервер? Где клиентские действия (типа открытия формы или сообщения), можно выполнять только на клиенте (или другими словами с сервера обращаться к клиенту).
  • lsFusion vis 1С
    0
    «Wow! That's really retro.» © South park.

    Блокировки в системах контроля версий уже лет 20 не используются. И не только из-за git flow, а просто потому что это дико неудобно.
  • lsFusion vis 1С
    0
    Самый первый тезис — неверен.
    Я если честно не совсем понимаю какой именно тезис — первый. Но с аргументом что «А — неверно» спорить тяжело. Я думаю мы друг друга поняли. Вы считаете, что все эти технические фишки — «essential complexity», я — «accidental complexity». Но так как четких метрик для определения этих complexity нет, спорить с вами действительно бесполезно. Все равно каждый останется при своем.
  • lsFusion vis 1С
    0
    Но мы же не программисты ради того чтобы быть программисты. Наша цель решать задачи поставленные заказчиком. И если для решения этих задач, нам нужно заниматься какой-то технической ерундой (не имеющих прямого отношения к задаче), значит мы скорее всего плохие инструменты используем. То есть мне может лопата очень нравится, но строить дом я буду с использованием бульдозера.