Как вы думаете почему прогресс средств разработки в ERP отличается от общего прогресса по отрасли (ИТ) в целом?

[mazzy]

Цитата:

Сообщение от belugin

В дамгард. Приложение - один большой модуль.

а также дамгаард же добавил модели... и не довел разделение по моделям до конца, бросив большинство функционала в одном Suite
он! дамгаард. точно.

Цитата:

Сообщение от belugin

Возможно, нет стратегической цели перевести все на C#?

возможно?

Цитата:

Сообщение от belugin

Я так понял, что первое приложение раскрывается вторым, нет?

?!

Цитата:

Сообщение от belugin

Что оно не полностью не совместимо. Вот с брейнфаком так не получится, он полностью несовместим.

ты предлагаешь поговорить о степенях свежести осетрины?

Цитата:

Сообщение от belugin

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

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

Цитата:

Сообщение от belugin

Я не занимаюсь никаким охранительством - просто уточняю какие-то моменты

А можешь высказать свое мнение на исходный вопрос?

Цитата:

Сообщение от Lemming

Я пытаюсь понять: почему технологически ERP системы находятся так позади всего того прогресса, который мы сегодня видим в ИТ?

[belugin]

Цитата:

Сообщение от mazzy

а также дамгаард же добавил модели... и не довел разделение по моделям до конца, бросив большинство функционала в одном Suite
он! дамгаард. точно.

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

Цитата:

?!

1. Маззи: потом... херакс! и ax7. полностью не совместимая. в которой продцедур апгрейда с предыдущих версий не предусматривалось.

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

3. Маззи: где я такое говорил? приведи цитату и логический переход от цитаты к твоему утверждению.
блин.

4. Я: {привожу цитату}. Объясняю откуда сделал такой вывод. ( "полностью не совместимая. в которой продцедур апгрейда с предыдущих версий не предусматривалось" - я решил что второе предложение раскрывает значение первого "полностью не совместимая" потому что "предыдущих версий не предусматривалось")

Цитата:

ты предлагаешь поговорить о степенях свежести осетрины?

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

Цитата:

А можешь высказать свое мнение на исходный вопрос?

1. Чтобы сделать жирную ERP надо много времени, чтобы накопить функционал => большинство из них начали делать давно. Тогда не было языков общего назначения, которые были бы непроприетарны и поддерживали втроенный SQL (SQL/J кажется был проприетарный) => пришлось создавать свой язык, после чего накопилась большая кодовая база/обучающие материалы и прочее, которое надо переводить на новый язык. Кодовая база не расчитана на ограничения современных языков общего назначения (см модули).

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

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

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

[mazzy]

Цитата:

Сообщение от belugin

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

ход мысли понятен. каждый может сделать вывод сам.

Цитата:

Сообщение от belugin

1. Маззи: потом... херакс! и ax7. полностью не совместимая. в которой продцедур апгрейда с предыдущих версий не предусматривалось.

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

3. Маззи: где я такое говорил? приведи цитату и логический переход от цитаты к твоему утверждению.
блин.

4. Я: {привожу цитату}. Объясняю откуда сделал такой вывод. ( "полностью не совместимая. в которой продцедур апгрейда с предыдущих версий не предусматривалось" - я решил что второе предложение раскрывает значение первого "полностью не совместимая" потому что "предыдущих версий не предусматривалось")

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

Цитата:

Сообщение от belugin

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

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

Цитата:

Сообщение от belugin

1. Чтобы сделать жирную ERP надо много времени, чтобы накопить функционал => большинство из них начали делать давно. Тогда не было языков общего назначения, которые были бы непроприетарны и поддерживали втроенный SQL (SQL/J кажется был проприетарный) => пришлось создавать свой язык, после чего накопилась большая кодовая база/обучающие материалы и прочее, которое надо переводить на новый язык. Кодовая база не расчитана на ограничения современных языков общего назначения (см модули).

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

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

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

а вот скажи, Java - это софт более жирный, чем ERP или менее жирный?
например, в java платформу ввели таки и перегрузку, и генерики, и лямбды с замыканиями. И многопоточность и потокобезопасное программирование. И стримы вот сейчас моднючие. И библиотеки под это переписали.

а в Аксапте все еще java первого поколения.

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

[belugin]

Цитата:

Сообщение от mazzy

а вот скажи, Java - это софт более жирный, чем ERP или менее жирный?
например, в java платформу ввели таки и перегрузку, и генерики, и лямбды с замыканиями. И многопоточность и потокобезопасное программирование. И стримы вот сейчас моднючие. И библиотеки под это переписали.

Тут другой вопрос - Java все-таки делается обратно совместимой (все эти возможности это добавление). Т.е. клиенту не надо в типичном случае напускать на свой код конвертер, который будет многие if(x) превращать в if (TrueFalseHelper.ToBoolean(x)) и так далее. В случае конвертации X++ в C# код будет изменен будет получен неидеоматичный C#.

Для конверсии в IL в Ax2012 сделали так: ужесточили в X++ правила контроля за типами и исправили код там где новые правила нарушались, но все равно из-за разницы рантаймов остался код, который работает в X++ и не будет работать в CIL (т.е. CIL не полностью совместим с X++ в Ax2012, а X++ ax 2012 не полностью совместим c X++ в Ax2009).

Цитата:

а в Аксапте все еще java первого поколения.

Сделали события, более строгую рантайм семантику типов, var, объявления переменных в любом месте метода, internal, методы расширения, CoC, pre-post handlers и переписали полностью компилятор на C# чтобы было удобней делать дальнейшие улучшения.

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

Цитата:

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

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

Аксапта это не Java 1.0 это какой-то скриптовой рантайм (типа PHP или Javascript - с подобными представлениями о прекрасном) + синтаксис Java и немного статической валидации от нее же.

Еще раз презываю декомпилировать какой-нибудь собственный паблик класс и посмотреть сколько там всего (конечно, если специально писать конвертор, то можно наверное это сделать более читаемо на С#, но можно получить представление об объеме работы и возникающих задачах).

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

[fed]

Цитата:

Сообщение от belugin

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

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

[belugin]

Цитата:

Сообщение от fed

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

Может и так. Это какая-то отдельная дискуссия.

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

(Типа, БУ не знает про Производство, производство не знает про БУ, есть модуль БУПроизводства, который знает обоих - подписывается на события в производстве и отображает их на БУ и наоборот, если где-то такое надо).

см. также книжки DDD и Clean architecture

[trud]

Цитата:

Сообщение от belugin

(Типа, БУ не знает про Производство, производство не знает про БУ, есть модуль БУПроизводства, который знает обоих - подписывается на события в производстве и отображает их на БУ и наоборот, если где-то такое надо).
см. также книжки DDD и Clean architecture

Такие же концепции в реальной жизни не работают. т.е. за примерами далеко ходить не надо, возьмите совершенно новый код по разноске ГК в 2012, где точки расширения и делегаты расставлены в каждом методе, но при столкновении с реальной задачей корреспонденции в РФ проще оказалось удалить все проводки и заново их сформировать вместо подписок на события

Цитата:

Сообщение от belugin

Сделали события, более строгую рантайм семантику типов, var, объявления переменных в любом месте метода, internal, методы расширения, CoC, pre-post handlers и переписали полностью компилятор на C# чтобы было удобней делать дальнейшие улучшения.

Это все слабо относится к потребностям внедрения и поддержки. Ну т.е. незначительные удобства. Есть же сильные шаги назад
-Убрали перекрестные ссылки(убрали Read-Write к полям таблицы), не поддерживают их в ряде случаев и т.п.
-Удобство работы с метками, они не видны на объектах
-Убрали форму трассировки долгих запросов, где можно было увидеть стек трейс откуда идет запрос.
-Убрали возможность просмотреть зависимость методов которые вы меняете и методов которые меняются в очередном сервис паке
ну и т.д.
Т.е. если брать средства разработки, то единственное преимущество сейчас перед прошлой версией - это то, что код можно проще шарить и куда-то выкладывать, по многим остальным статьям, это шаг назад. Вот это не очень понятно почему происходит

[belugin]

Цитата:

Сообщение от trud

Такие же концепции в реальной жизни не работают.

Вы очень категоричны

Цитата:

Сообщение от trud

т.е. за примерами далеко ходить не надо, возьмите совершенно новый код по разноске ГК в 2012, где точки расширения и делегаты расставлены в каждом методе, но при столкновении с реальной задачей корреспонденции в РФ проще оказалось удалить все проводки и заново их сформировать вместо подписок на события

1. Нет ли там подписок на события?
2. Какие циклические зависимости это породило?
3. Можно ли было не удалять и заново сформировывать проводки?
4. Можно ли было устранить дублирование введением дополнительных фич в платформу, если да то каких?

Цитата:

Это все слабо относится к потребностям внедрения и поддержки. Ну т.е. незначительные удобства. Есть же сильные шаги назад
-Убрали перекрестные ссылки(убрали Read-Write к полям таблицы), не поддерживают их в ряде случаев и т.п.
...

А это уже не про циклические ссылки а про что? Cтало лучше или нет? Почему в ERP нет прогресса в отличие мейнстима?

[trud]

Цитата:

Сообщение от belugin

Почему в ERP нет прогресса в отличие мейнстима?

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

[EVGL]

Цитата:

Сообщение от fed

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

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

J.D. Edwards был построен по такой схеме еще 20 лет назад, см. https://docs.oracle.com/cd/E17984_01...config_mgr.htm, Master Business Function.
Поправка: 30 лет назад.