LINUX.ORG.RU
ФорумTalks

Энтерпрайз ERP/CRM фо отомейшн оф ё сириоз бизнес

 , , ,


6

2

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

https://habr.com/en/post/447162/ - Не купитесь на ERP

Сразу скажу, что я не согласен с автором, но позиция интересна. Если слегка смягчить ее, то получится что-то такое: если на вашем предприятии бардак, то ERP за вас не сможет его организовать; если же вы навели порядок на своем предприятии, то ERP вам уже особо и не нужна.

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

Подход SAP в этом плане весьма остроумен с коммерческой точки зрения, потому что работы по сверхточному нанесению пользы сам SAP не выполняет, вместо этого клепая вот такие таблички на 240 столбцов:

https://www.sapdatasheet.org/abap/tabl/mara.html

Ну или просто позволяя вам выбрать из готового набора 110 000 (сто десять тысяч) табличек те, которые подойдут вашему бизнесу... или не подойдут. Остроумен с коммерческой точки зрения такой подход потому, что с позиции человека, который не разбирается в IT, то есть, типового клиента SAP, какой-нибудь SAP R/3 предоставляет собой крупную хорошо проработанную и проверенную систему, которая покрывает чуть ли не все на свете варианты бизнес-процессов предприятия. В такие моменты я люблю вспоминать покойного Дейкстру:

“Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.”

То есть, приходит менеджер, который отвечает за принятие решений, и спрашивает у продажника SAP: «у вас есть ${фичанейм} в системе? Насколько хорошо автоматизирует ${процесснейм} ваше решение?». Причем, говорить об этом до начала внедрения — это все равно, что спрашивать у женщины «вы можете родить мальчика или девочку? А мальчик будет гениальным?». Особенно если этой женщине 50 лет и ее маркетинговое преимущество — это что оба ее сына стали успешными учеными.

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

Пока что, из моего опыта разработки CRM/недо-ERP, мне видится, что одно из ключевых препятствий на пути заполнения данной ниши — это реляционные СУБД, которые используется к месту и не к месту — просто потому, что РСУБД есть готовые в большом количестве. Как правило, даже у достаточно конкретного клиента есть ни разу не конкретные требования по автоматизации, которые меняются день ото дня, вроде «мы узнали длину члена Василия Петровича — давайте сохраним эту информацию в CRM записи про Василия Петровича, в надежде, что со временем удастся собрать аналогичные сведения по другим клиентам и вывести кореляции». Происходит это не только из-за сиюминутных прихотей конкретного менеджера, но и из-за постепенной смены коньюктуры и технологий в фирме.

Реляционная же модель приводит к тому, что когда внезапно появляется необходимость сделать связь сущностей N-к-M вместо какой-нибудь 1-к-N, то приходится перекраивать базу верх ногами, создавая новую таблицу связей между сущностями и изменяя алгоритмы создания-чтения-обновления-удаления. А в случае перехода от 1-к-1 в N-к-M нужно создавать уже две дополнительные таблицы. У того же SAP по этому поводу из коробки для целой кучи атрибутов есть поддержка множественных связей, откуда и появилось астрономическое количество табличек — в реальности таблиц корневых сущностей там всего несколько сотен.

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

Есть много опенсорсных попыток писания ERP софта (например, Odoo, OpenERP, IDempiere/Compiere/Adempiere/Openbravo/metasfresh), но каждая из них, как правило, представляет собой одну и ту же попытку повторить SAP в мелком масштабе. У меня есть некоторые абстрактные зарисовки по этой теме, но, как показывает практика, публиковать их не имеет смысла, а пытаться сделать что-то конкретное прямо сейчас у меня тупо нет времени/желания, поскольку я работаю над релизом предыдущего незаконченного проекта питоньей многозадачности. Так что принимайте эстафету.

★★★★

Ответ на: комментарий от byko3y

У тебя есть очень простой выбор: выполнять заказ клиента или терять клиента. Если у клиента на всех клиентах и серверах стоит винда, а ты им говоришь «всё херня, давайте ставить линь» — ты теряешь клиента. Вот и вся история.

1) XAF поддерживает Шиндоуз.

2) Образно тебе предлагают участвовать в групповом корпоративном садомазо за деньги, но ты как дурачок «теряешь клиента». Какая печалька.

Вот и вся история. (с)

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 3)
Ответ на: комментарий от byko3y

Исходил сорцы вдоль и поперек. По крайней мере тех компонентов, с которыми работал. Я уже написал — это лапша и ООП головного мозга в терминальной стадии, которые выжили только благодаря огромному числу ресурсов, потраченных на разработку и тестирование. Толкнешь его не с той стороны — всё посыпется. Еще раз: я нашел порядка десяти багов за годы работы с DevExpress-ом. Это неизбежный результат чрезмерной сложности, и он был бы не сильно лучше даже если бы разрабы грамотно подошли к организации архитектуры, а не тупо «по книжкам», как они это сделали.

Нужны конкретные примеры с баг репортами, если они были паблик.

Сорцы какого компонента ты смотришь, с чем сравниваешь? Разговор ни о чем либо о том самом в ваккуме.

За все время использования DevExpress WinForms я встречал всего лишь одну багу, которую пофиксили в следующей версии, пока я еще даже не успел ее зарепортить, вероятно кто-то зарепортил раньше меня.

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 1)
Ответ на: комментарий от byko3y

А теперь разверни строчку «Source code» и посмотри, что сорцы к XAF ты получишь только за самую жирную подписку.

Не только, а еще и в DXperience.

XAF кстати присутствует только в самой дорогой, так что без разницы, в какой есть сорцы :)

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 1)
Ответ на: комментарий от byko3y

Несколько месяцев работы средненького провинциального кодера — это стоимость лицензии XAF.

Средненький кодер- СПЕЦИАЛИСТ (а не носитель названия кодер) - резидент РФ может найти средненькую удаленку за средненькие 100-150 тыр в мес. (как раз стоимость годовой подписки DevExpress) в РФ или, если повезет, то в разы больше в Калифорнии.

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

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

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

Обычный треугольник ресурсных зависимостей PM: при приемлемом

качестве либо медленно, но недорого - студни,

либо быстро, но дорого - специалисты.

https://hsto.org/getpro/habr/post_images/551/fc7/489/551fc74894f1205cd9b4b95a...

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 8)
Ответ на: комментарий от byko3y

Но внимание, зато в РФ много SAP R3, LOL

1С намного больше.

Не спорю, но если сравнивать XAF с 1С, то XAF намного более универсален, его лучше сравнивать с MS Access.

Из преимуществ у XAF есть true ЯП на DotNet с true ООП, которым можно расширять даже визуальные компоненты, интерфейс в ORM и возможность разрабатывать подключать при желании свои кастом ORM. Ессно в MS Access нет всего этого богатства, по крайне мере хорошо интегрированного из коробки.

Мне например XAF интересен в качестве GUIшных редакторов для настроек деплоя и админской скриптоты. ERP и 1С тут совсем перпендикулярны.

С боку к MS Access и даже вероятно к Libre Base можно приладить жалкое подобие через офисную автоматизацию, но даже близко не получится то, что есть в XAF, особенно по степени удобства, продуктивности, надежности, портабельности на Linux (для MS Access последних релизов со стандартной техподдержкой, которая без WINE) и т.п.

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

Вероятно 1C как и SAP R3 (хотя бы как платформу) можно было бы попытаться сравнить с Xafari? https://galaktika-soft.com/xafari

Готовых наработок вероятно больше всего для 1С и с практической точки зрения для мелко-средних компаний, которые сами не могут в разработку, лезти во что-то более сложное бессмысленно. Если только наоборот упрощать до облачного СКБ Контура типа Эльба и т.п.

https://e-kontur.ru/

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 15)
Ответ на: комментарий от sanyo1234

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

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

Которыми можно только *опу подтереть, если речь именно о usability и надежности и других различных критериях годности именно формошлепства

Добро пожаловать в разработку в 2021 году. Причем, так работает не только Россия, но и Европа, и штаты, и даже в Boeing так пишут софт.

byko3y ★★★★
() автор топика
Ответ на: комментарий от sanyo1234

Сорцы какого компонента ты смотришь, с чем сравниваешь? Разговор ни о чем либо о том самом в ваккуме

Конечно я не помню большую часть их. Есть возможность найти их в годовых залежах старого багтрекера, но это дофига времени и мало смысла. Я писал про их табличное представление (QUantumGrid) для отображения данных с SQL сервера. Он умеет не только «select * from», но и строит очень сложные запросы. В апстрим ничего не репортили, правда, половина багов уже была зарепорчена кем-то еще.

byko3y ★★★★
() автор топика
Ответ на: комментарий от sanyo1234

Средненький кодер- СПЕЦИАЛИСТ (а не носитель названия кодер) - резидент РФ может найти средненькую удаленку за средненькие 100-150 тыр в мес. (как раз стоимость годовой подписки DevExpress) в РФ или, если повезет, то в разы больше в Калифорнии

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

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

Да, и потому именно ему нужен XAF. Но дороговат он.

byko3y ★★★★
() автор топика
Ответ на: комментарий от sanyo1234

Мне например XAF интересен в качестве GUIшных редакторов для настроек деплоя и админской скриптоты

А, ну так бы сразу и сказал. ERP и 1С тут совсем ортогональны, хотя, я не совсем понимаю тогда, зачем тебе именно XAF нужен. ведь он метит на нишу 1C и MS Dynamics.

Вероятно 1C как и SAP R3 (хотя бы как платформу) можно было бы попытаться сравнить с Xafari? https://galaktika-soft.com/xafari

Да, это оно и есть.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

я не совсем понимаю тогда, зачем тебе именно XAF нужен. ведь он метит на нишу 1C и MS Dynamics.

XAF - это универсальный GUI конструктор. Причем тут ERP?

На базе него сделано расширение для EPR, например Xafari.

sanyo1234
()
Ответ на: комментарий от byko3y

Да, и потому именно ему нужен XAF. Но дороговат он.

Даже МРОТ - это больше одной лицензии в год, особено с учетом брутто. Притом, что XAF ускоряет формошлепство до 50 раз по отзывам на sql.ru. На сэкономленное время можно было бы предоставлять время для отдыха дома, что как раз превратило бы 1 МРОТ примерно в нижнерыночную ставку около $10/h брутто.

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 1)
Ответ на: комментарий от byko3y

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

Кто-то может еще и доплачивать будет за право посетить офис, даже анекдоты такие были про святые 90-ые :)

sanyo1234
()
Ответ на: комментарий от byko3y

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

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

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 2)
Ответ на: комментарий от byko3y

Добро пожаловать в разработку в 2021 году. Причем, так работает не только Россия, но и Европа, и штаты, и даже в Boeing так пишут софт.

https://ebanoe.it/2021/09/06/changes-in-it/

Из того, что где-то занимаются ерундой не следует, что так происходит везде.

sanyo1234
()
Ответ на: комментарий от byko3y

Конечно я не помню большую часть их. Есть возможность найти их в годовых залежах старого багтрекера, но это дофига времени и мало смысла. Я писал про их табличное представление (QUantumGrid) для отображения данных с SQL сервера. Он умеет не только «select * from», но и строит очень сложные запросы. В апстрим ничего не репортили, правда, половина багов уже была зарепорчена кем-то еще.

Можешь уточнить, что именно ты использовал?

DevExpress с какой подпиской? Линк на набор компонентов на их сайте.

Язык разработки Object Pascal с нативным таргетом или один из DotNet?

Был ли там XAF?

Был ли там Xafari?

Баги были в каком DotNet компоненте?

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 3)
Ответ на: комментарий от sanyo1234

XAF - это универсальный GUI конструктор. Причем тут ERP?
На базе него сделано расширение для EPR, например Xafari

Это не просто конструктор, это специализированный конструктор, который покрывает функции GUI с привязкой к данным. А это уже не просто «GUI конструктор». Термином «ERP» я называю вообще все типы софтин для учета и автоматизации предприятия.

byko3y ★★★★
() автор топика
Ответ на: комментарий от sanyo1234

В смысле глючное, которым ты пользовался?
Т.е. проблемы с Xafari, а виноват XAF?

Ты следишь на что отвечаешь? Ты спросил?

Вероятно 1C как и SAP R3 (хотя бы как платформу) можно было бы попытаться сравнить с Xafari?

Я ответил — да, это похожие продукты. Всё, больше я ничего не отвечал.

byko3y ★★★★
() автор топика
Ответ на: комментарий от sanyo1234

XAF ускоряет формошлепство до 50 раз по отзывам на sql.ru

Даже без XAF можно формошлепать. Тоже в 50 раз быстрее. Если тебе нужно формошлепать те приложения, под которые специализируются XAF — ради бога, я ж не запрещаю.

byko3y ★★★★
() автор топика
Ответ на: комментарий от sanyo1234

Кто-то может еще и доплачивать будет за право посетить офис, даже анекдоты такие были про святые 90-ые

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от sanyo1234

DevExpress с какой подпиской? Линк на набор компонентов на их сайте

Ты думаешь я помню? Не я ж подписку покупал.

Язык разработки Object Pascal с нативным таргетом или один из DotNet?

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

Был ли там XAF?
Был ли там Xafari?

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

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

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

sanyo1234
()
Ответ на: комментарий от byko3y

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

Это же вообще для Pascal, который под Native, ты издеваешься чтоли? Его не может быть в комплекте XAF, который для DotNet в отличии от Quantum. Код среднего кодера на DotNet стабильнее Паскаля на порядок просто by design.

Мы с тобой о разных вещах тогда говорим, получается.

Я в первую очередь про DevExpress WinForms for DotNet, он прекрасен и супер стабилен и bug free, по крайне мере в прошлых версиях. Думаю, сейчас он стал только лучше.

И во вторую про надстройку над ним - XAF.

Твой Delphi тут ни к селу, ни к городу, как говорится, вообще не в тему. Для Delphi у них нет никакого XAF, там делается все ручками долго и упорно в 50 раз медленнее, чем на XAF.

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 1)
Ответ на: комментарий от byko3y

Даже без XAF можно формошлепать. Тоже в 50 раз быстрее.

Почитай на досуге темку:

https://www.sql.ru/forum/1315922-a/ishhu-podrabotku-na-devexpress-xaf-na-2-4-...

Ты похоже вообще не понимаешь, о чем говоришь и что такое XAF.

Если тебе нужно формошлепать те приложения, под которые специализируются XAF — ради бога, я ж не запрещаю.

Еще бы ты запрещал, LOL :)

sanyo1234
()
Ответ на: комментарий от byko3y

Это не просто конструктор, это специализированный конструктор, который покрывает функции GUI с привязкой к данным. А это уже не просто «GUI конструктор».

Ты видел GUI без привязки к данным?

Даже xclock берет данные текущего времени из оси.

Термином «ERP» я называю вообще все типы софтин для учета и автоматизации предприятия.

Имеем истинный предикат: Если приложение ERP, то у него есть привязка к данным.

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

Т.е. если есть привязка к данным, то необязательно, приложение - ERP.

Хотя если под ERP понимать любые скрипты, например для деплоя игр для первоклассников в облачную среду предприятия, обслуживающее школы, то вероятно действительно все вокруг нас на компьютере предприятия - это ERP в твоей терминологии ...

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 4)
Ответ на: комментарий от byko3y

Ты думаешь я помню? Не я ж подписку покупал.

Какой смысл, твой пасквилянтский опыт с Quantum (который под нативный таргет, а не DotNet) тащить в дискуссию о DotNet XAF? Это совершенно разные вещи, очень слабо связанные между собой с точки зрения реализации, хотя внешне похожи, GUI там и там.

Сколько помню свои попытки использовать первые версии Delphi, там сама среда нередко валилась, не то что программы. Мне Object Pascal (реализация Free Pascal) интересен только своей портабильностью: https://wiki.freepascal.org/Platform_list

Т.е. на нем можно станцевать какой-нибудь CLI (а НЕ GUI), например для какой-нибудь редкой оси на редкой аппаратной архитектуре и при относительно простом знакомом еще со школы синтаксисе, т.е. легко и непринужденно: http://fkn.ktu10.com/?q=node/8368

Еще в 90-ые Microsoft VBA и VB6 были стабильнее Delphi примерно раз в 10 в зависимости от используемых в Delphi компонентов. VBA после Delphi был как глоток свежего воздуха по простоте и стабильности кодинга и отладки мелких наколеночных прог, к сожалению в VBA не было полного ООП с наследованием.

Так вот по твоим рассказам ничего не поменялось за 20 лет по крайне мере для кодинга GUI программ с относительно сложными компонентами на Delphi.

Есть реализации Object Pascal и для DotNet, вот их уже можно было бы пытаться применять совместно с XAF, но QuantumGrid тут рядом не валялся. Проблема не в ЯП Pascal, а в сложности написания вручную программ под нативный target.

Т.е. например в PascalABC ты бы уже не встретил тех багов из QuantumGrid, которые видел вероятно в Delphi. Потому что тебе бы пришлось использовать DevExpress Win вместо Quantum, только и всего.

https://www.devexpress.com/products/net/controls/winforms/

https://en.wikipedia.org/wiki/PascalABC.NET

Как для Буратино тебе объясняю азбуку :)

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 9)
Ответ на: комментарий от sanyo1234

Есть и более взрослые компиляторы Pascal для DotNet, например:

https://www.elementscompiler.com/elements/oxygene/

Он может самостоятельно докомпилировать DotNet программу даже в нативный target без зависимостей от DotNet runtime. Причем сохранив все преимущества более продуктивного и безглючного программирования для DotNet, он берет все сложности по переводу DotNet программы в нативный код на себя, вместо того, чтобы мучать твой мозг во время отладки и мозг собеседников на LOR-е при обсуждении твоих экспериенсов с DevExpress :)

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 3)
Ответ на: комментарий от sanyo1234

Код среднего кодера на DotNet стабильнее Паскаля на порядок просто by design

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

Я в первую очередь про DevExpress WinForms for DotNet, он прекрасен и супер стабилен и bug free, по крайне мере в прошлых версиях. Думаю, сейчас он стал только лучше

Прохладные истории, но сами разрабы с тобой не согласятся:

https://supportcenter.devexpress.com/ticket/list/?preset=8ef43cb9-dfb5-4a23-b...

320 багов за месяц. Они уже несколько лет не могут выпустить стабильный релиз своей лапши для .NET 5.0:

https://supportcenter.devexpress.com/ticket/details/t1011832/winforms-net-5-d...

При том, что пятерке уже 5 лет. Это к слову о тому, почему во всяких питонах и PHP так ръяно охраняют все нелогичности и просто баги реализации — потому что подобная лапша рассыпется так же, как рассыпался DevExpress.

Для Delphi у них нет никакого XAF, там делается все ручками долго и упорно в 50 раз медленнее, чем на XAF

Делается что? Кинуть на формочку табличку и настроить привязку к БД — это пару минут. Может ты еще расскажешь истории, как тебе XAF тапочки утром приносит к постели? В 50 раз быстрее.

byko3y ★★★★
() автор топика
Ответ на: комментарий от sanyo1234

Почитай на досуге темку:
https://www.sql.ru/forum/1315922-a/ishhu-podrabotku-na-devexpress-xaf-na-2-4-...
Ты похоже вообще не понимаешь, о чем говоришь и что такое XAF

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

И еще раз повторюсь, что для формошлепства DevExpress хорошо подходит — главное не пытаться использовать его в нестандартных и неоттестированных сценариев. Все-таки, тысячи закрытых багов чего-то, да стоят.

byko3y ★★★★
() автор топика
Ответ на: комментарий от sanyo1234

Ты видел GUI без привязки к данным?

Валом. По крайней мере без привязки к БД. Более того, я видел данные без привязки к GUI. И я видел отсутствие GUI с отсутствием БД. Ты так говоришь, будто в мире кроме аналогов 1С никто ничего и не пишет.

byko3y ★★★★
() автор топика
Ответ на: комментарий от sanyo1234

Какой смысл, твой пасквилянтский опыт с Quantum (который под нативный таргет, а не DotNet) тащить в дискуссию о DotNet XAF?

Такой, что компоненты под WinForms являются далекой, но копией аналогичных под VCL.

Сколько помню свои попытки использовать первые версии Delphi, там сама среда нередко валилась, не то что программы

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

Еще в 90-ые Microsoft VBA и VB6 были стабильнее Delphi примерно раз в 10 в зависимости от используемых в Delphi компонентов. VBA после Delphi был как глоток свежего воздуха по простоте и стабильности кодинга и отладки мелких наколеночных прог

Ты сравниваешь инструменты разных классов. Delphi корректнее было бы сравнивать с крестовым VS, и там уже не так всё однозначно. И при всём при этом Delphi одновременно претендовало на нишу VB. Конечно, претендовало плохенько, не спорю, но претендовало.

Проблема не в ЯП Pascal, а в сложности написания вручную программ под нативный target

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

Т.е. например в PascalABC ты бы уже не встретил тех багов из QuantumGrid, которые видел вероятно в Delphi. Потому что тебе бы пришлось использовать DevExpress Win вместо Quantum, только и всего

Там добрая половина была багами логики: не то состояние читается не в то время не тем кодом — а потому что синхронный код и рекурсии, которые крайне тяжело понять. Вообще, мой первый серьезный проект был в Google Summer of Code, и в нем вместо реализации основной функциональности я большую часть времени потратил на то, чтобы заставить правильно работать чужую спутанную лапшу из таких же точно рекурсивных вызовов. Я сидел, читал код, записывал огромные иерархии вызовов.

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

https://en.wikipedia.org/wiki/PascalABC.NET

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от sanyo1234

https://www.elementscompiler.com/elements/oxygene/
Он может самостоятельно докомпилировать DotNet программу даже в нативный target без зависимостей от DotNet runtime

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

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

Все таки если ты использовал VCL вариант DevExpress, то его IMHO некоректно сравнивать с DotNet WinForms.

И еще раз повторюсь, что для формошлепства DevExpress хорошо подходит — главное не пытаться использовать его в нестандартных и неоттестированных сценариев.

Все-таки, тысячи закрытых багов чего-то, да стоят.

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

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

sanyo1234
()
Ответ на: комментарий от byko3y

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

Лично для меня это и хорошо, вообще я не любитель low level, если только для навески EnigmaProtector.

sanyo1234
()
Ответ на: комментарий от byko3y

Семейство паскалеподобных языков отличается хорошим синтаксисом. намного лучшим, чем у C-подобных языков.

Именно поэтому мне нравится VB.NET больше, чем C#.

И надеюсь, в будущем понравится RemObjects Mercury, логотип которого ты видишь у меня на аватаре.

https://docs.elementscompiler.com/Mercury/LanguageExtensions/

Это развитие VB.NET за пределами Microsoft.

https://visualstudiomagazine.com/articles/2020/03/12/vb-in-net-5.aspx?m=1

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 2)
Ответ на: комментарий от byko3y

Валом. По крайней мере без привязки к БД.

Вот именно, но при этом все же обычно элементы GUI биндятся к тем или иным ДАННЫМ или хотя бы сами являются хранилищем данных (даже если они существуют только in-memory), что я и имел ввиду, пусть не из СУБД, - не суть важно.

Более того, я видел данные без привязки к GUI.

Кто про них не знает :) про эти горы байтов. Но если ты их ВИДЕЛ, то вероятно все же через GUI или хотя бы CLI+TUI ;)

И я видел отсутствие GUI с отсутствием БД.

И с отсутствием компьютера :)

Ты так говоришь, будто в мире кроме аналогов 1С никто ничего и не пишет.

Я вообще не имею опыта с 1С, мне тематика ERP неинтересна сама по себе, только в контексте обсуждения архитектуры доступа к данным, что можно применить там, где ERP ненужен.

sanyo1234
()
Ответ на: комментарий от byko3y

Они уже несколько лет не могут выпустить стабильный релиз своей лапши для .NET 5.0:

Я пользовался только для .NET Framework v4x, там было все норммально. Кстати и под WINE нормально работает, по крайне мере не самые последние версии.

При том, что пятерке уже 5 лет.

Именно релиз .NET 5 релизнули в конце 2020 года, если ты про .NET Core в целом, то этот фреймворк развивается очень быстро, со временем утрясется. Поддержка WinForms в Core появилась совсем недавно где-то в v3.x. И они вроде до сих пор допиливают дизайнеры WinForms Core для студии?

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

Ох уж этот питон, как он меня достал. Постоянно валится где-нибудь, даже в некоторых консольных утилитах, даже на Debian v9 stretch, который уже oldoldstable.

sanyo1234
()
Ответ на: комментарий от byko3y

Делается что? Кинуть на формочку табличку и настроить привязку к БД — это пару минут. Может ты еще расскажешь истории, как тебе XAF тапочки утром приносит к постели? В 50 раз быстрее.

Когда у тебя десятки табличек, и когда приходится регулярно менять модель данных, в XAF достаточно отредактировать в редакторе модели, остальное сделает автоматика.

А вручную без XAF нужно было бы отредактировать декларативную модел BL, поменять структуру таблиц в базе данных, подформошлепить GUI.

Если это происходит регулярно, то велика вероятность возникновения ошибки, если где-то ошибешься. Хотя некоторые используют различные генераторы типа DevArts ED и LLBLGen, но даже с ними IMHO остается достаточно много головняка как минимум по разработке и поддержке своих шаблонов для генерации, и много ли у кого есть шаблоны для генерации своего формошлепства? А значит опять без XAF пришлось бы формошлепить вручную.

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 3)
Ответ на: комментарий от byko3y

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

В мире DotNet памятью рулит сам Runtime, для формошлепства это намного удобнее, чем БДСМ на C++.

И для плюсов с Паскалем безусловно есть свои задачи, где как раз нужна работа с памятью напрямую (математика, 3D, оси и т.п), но навряд ли это про типовые офисные приложения, которые обычно просто шлют SQL запросы в базу и показывают их в GUI, которое если достаточно сложное, то без DotNet валится намного чаще, чем с ним.

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 1)
Ответ на: комментарий от byko3y

Такой, что компоненты под WinForms являются далекой, но копией аналогичных под VCL.

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

sanyo1234
()
Ответ на: комментарий от byko3y

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

Шиндоуз как бы вообще не эталон стабильности в мире осей, да и профилировщики есть другие, как и IDE.

sanyo1234
()
Ответ на: комментарий от byko3y

Ты сравниваешь инструменты разных классов. Delphi корректнее было бы сравнивать с крестовым VS, и там уже не так всё однозначно.

Это если нацеливаться на соответствующие задачи, то да.

А для моих задач GUI для деплоя, как и для большинства офисной кастом приложухи корректнее сравнивать Delphi и VC++ (если их еще кто-то использует для этого) именно с DotNet C# / VB.NET / Oxygene и т.п.

И при всём при этом Delphi одновременно претендовало на нишу VB. Конечно, претендовало плохенько, не спорю, но претендовало.

А мне-то как раз нужна именно такая ниша.

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 2)
Ответ на: комментарий от byko3y

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

IMHO даже ты на рутинных офисных задачах (если бы ты согласился на них) бы вероятно либо где-то налажал со временем больше, чем ты же на DotNet, либо кодил бы на своих плюсах или native Pascal дольше даже среднего индуса, скурпулезно высматривая слабые места кода. Такая работа с сорцами под нативные targets безусловно нужна, но только когда есть такая необходимость (3D / матан и т.п.), когда это НЕ мартышкин труд, а судя по твоему описанию твой уровень намного выше, чем кодинг офисных циклов по «select from».

Офисные циклы по кастомным «select from» при сравнении с кодингом 3D/осей/матана как раз и является мартышкиным трудом, а если на C++, то еще и усугублено несоответствием мощного инструмента относительно простой задаче (которая мартышкин труд).

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 3)
Ответ на: комментарий от sanyo1234

Все таки если ты использовал VCL вариант DevExpress, то его IMHO некоректно сравнивать с DotNet WinForms

Я понимаю, если бы ты еще так про WPF говорил. Но WinForms — это минимальная обертка над Win32, как и VCL. По этой причине с минимальными изменениями те же компоненты работают под обоими GUI либами.

Полистал хронологию баг репортов до самых поздних, которые вошли в выборку, они созданы примерно год назад, многие закрыты, незакрытые обычно с описанием того, что кастом разработчик что-то делает не так, как задумано в доке

То есть, тебя не смущает, что там багов больше, чем у ядра линя?

https://bugzilla.kernel.org/buglist.cgi?bug_status=ASSIGNED&bug_status=RE...

45 закрытых багов за 2 месяца. Против 400 багов у одного только DX WinForms. Знаешь почему? Потому что уровень ядерных кодеров и уровень ревью у ядра на две головы выше, чем в команде DevExpress. И, будучи написанным на Си, при сравнимых размерах ядро стабильнее DX, при том, что там валом многопоточного кода — а это самый тяжелый для написания код, потому что в случае какой-нибудь консурсной головоломки ты, как правило, можешь доказать правильность решения, а в случае многопоточного железозависимого кода доказать его корректность практически нереально.

byko3y ★★★★
() автор топика
Ответ на: комментарий от sanyo1234

И надеюсь, в будущем понравится RemObjects Mercury, логотип которого ты видишь у меня на аватаре
Это развитие VB.NET за пределами Microsoft

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от sanyo1234

Вот именно, но при этом все же обычно элементы GUI биндятся к тем или иным ДАННЫМ или хотя бы сами являются хранилищем данных (даже если они существуют только in-memory), что я и имел ввиду, пусть не из СУБД, - не суть важно

Если ты будешь опускаться до настолько банальных вещей, то я тебе напомню, что GUI компоненты сами являются данными, и вообще всё в компе является данными, и тогда твои тезисы перестают иметь смысл. Привязки же к БД — это вполне конкретные специфичные сложные вещи, которые я и имел в виду.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

45 закрытых багов за 2 месяца. Против 400 багов у одного только DX WinForms. Знаешь почему? Потому что уровень ядерных кодеров и уровень ревью у ядра на две головы выше, чем в команде DevExpress. И, будучи написанным на Си, при сравнимых размерах ядро стабильнее DX, при том, что там валом многопоточного кода — а это самый тяжелый для написания код, потому что в случае какой-нибудь консурсной головоломки ты, как правило, можешь доказать правильность решения, а в случае многопоточного железозависимого кода доказать его корректность практически нереально.

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

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 1)
Ответ на: комментарий от byko3y

Если ты будешь опускаться до настолько банальных вещей, то я тебе напомню, что GUI компоненты сами являются данными, и вообще всё в компе является данными, и тогда твои тезисы перестают иметь смысл. Привязки же к БД — это вполне конкретные специфичные сложные вещи, которые я и имел в виду.

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

Я по прежнему уверен, что есть приложения, которые не являются ERP, но при этом используют базы данных. Вот например: https://seodor.biz/

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 2)
Ответ на: комментарий от byko3y

Каким бы крутым язык бы не был — все равно самое близкое к CLR,

Что значит близкое? Как у Малдера со Скали «где-то рядом» ? :)

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

А это чьи слова:

Семейство паскалеподобных языков отличается хорошим синтаксисом. намного лучшим, чем у C-подобных языков.

???

IMHO для меня синтаксис VB.NET похож на смесь Паскаля с Сишными ништяками типа объявления переменной в любом месте кода.

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 2)
Ответ на: комментарий от byko3y

Я понимаю, если бы ты еще так про WPF говорил. Но WinForms — это минимальная обертка над Win32, как и VCL. По этой причине с минимальными изменениями те же компоненты работают под обоими GUI либами.

Питон - это тоже обертка над сишечнами либами, но массово приложуху и высокоуровневую скриптоту пишут на питоне, а не на сишке? (по крайне мере в рамках сравнения Python vs C и DotNet vs С/Delphi)

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.