AXForum  
Вернуться   AXForum > Прочие обсуждения > Курилка
DAX
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 28.07.2019, 20:49   #21  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Цитата:
Сообщение от fed Посмотреть сообщение
В третьих - а ты вообще уверен что прогресс в средствах разработки - он реальный а не маркетинговый ? ... Да - наверное с generics, замыканиями и итераторами на уровне языка можно было бы писать код местами покрасивее и побыстрее, но особого прорыва это бы не произвело.
Продвинутые типы данных и средства автоматического рефакторинга это еще и уменьшение количества ошибок (как за счет контроля так и за счет большей понятности для читателя).

Хотя у меня есть некоторое ощущение регресса в с точки зрения простоты работы для прикладных программистов. Например простую форму для работы с базой данных сделать проще было на Delphi чем на C#, ориентация на сервисы заставляет думать в терминах сетевого взаимодействия а не предметной области и так далее.

Последний раз редактировалось belugin; 28.07.2019 в 20:55.
За это сообщение автора поблагодарили: Ace of Database (2).
Старый 28.07.2019, 21:24   #22  
Lemming is offline
Lemming
Участник
Аватар для Lemming
 
1,144 / 343 (14) ++++++
Регистрация: 20.04.2004
Адрес: Москва, Чайнатаун в Люблино
Записей в блоге: 10
Cool
Цитата:
Сообщение от belugin Посмотреть сообщение
Хотя у меня есть некоторое ощущение регресса в с точки зрения простоты работы для прикладных программистов. Например простую форму для работы с базой данных сделать проще было на Delphi чем на C#
В 3-й (а так же 4-й и 2009-й) аксапте простую форму тоже легко было сделать и те кто пришел из Delphi штамповали их "как горячие пирожки". Я насмотрелся форм, в которых вывод в Excel был прописан прям в методе clicked (или как там его, уже не помню) кнопки "Печать". Или когда люди упаковывали в статический метод всю бизнес-логику какого-нибудь процесса, а что бы навести в этих километрах кода хотя бы какую-то инкапсуляцию использовали локальные функции. Это реально бравые дельфи программисты. Вся суть этой простоты в аксапте ранних версий сыграла не последнюю роль в том, что ходили шуточки про 90% провальных внедрений. Но цель привлечь много программистов в новую на рынке систему за счет простоты - была достигнута!
За это сообщение автора поблагодарили: MikeR (5).
Старый 29.07.2019, 04:51   #23  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Картинка в тему
Нажмите на изображение для увеличения
Название: devsova.jpg
Просмотров: 138
Размер:	219.8 Кб
ID:	12360
За это сообщение автора поблагодарили: belugin (3), Lemming (5), twilight (1).
Старый 29.07.2019, 07:46   #24  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
макс, ты очень интересно формулируешь ответ
Цитата:
Сообщение от belugin Посмотреть сообщение
А еще есть гигантский модуль ...
А еще есть ....
попробуйте ...
"есть" - это разработчики в майкрософт сделали.
а попробовать ты предлагаешь нам в качестве доказательства что что-то невозможно сделать.

если невозможно, то нахрена майкрософт перевел в режим "есть"?

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

Цитата:
Сообщение от belugin Посмотреть сообщение
например, можно перенести код через буфер обмена и он с очень большой вероятностью заработает.
А может не заработает.
И что это доказывает?

Цитата:
Сообщение от belugin Посмотреть сообщение
Во-вторых, сейчас я вижу документацию по апгрейду.
а тогда - не было

Цитата:
Сообщение от belugin Посмотреть сообщение
Я думаю, что это твоя гипотеза, и ты не видел документов по данному вопросу? (Я почему уточняю - ты начал с того, что сослался на опыт работы в MS - поэтому читатели могли подумать, что ты знаешь это на 100% ).
конечно гипотеза.
по данному вопросу - это какому? что руководство поменялось?

Цитата:
Сообщение от belugin Посмотреть сообщение
для поддержки слоев!
а какая разница то ради чего?
я говорил о том, что решения вводятся в код и сразу же отменяются.
именно ввод-отмена и делает "все усложнилось на «бэкенде»"

каждая введенная и отмененная фича в моем списке вводилась ради чего-то. и для отмены также находились очень важные причины.

вопрос не в причинах. вопрос - почему приоритеты причин меняются.

Цитата:
Сообщение от belugin Посмотреть сообщение
Свои контролы делать можно см. "extensible controls" => клиентский код есть, только он не на X++ а на JavaScript
становится как-то смешно.
ты сейчас чего доказать то хочешь?

что выпиливание клиентского x++ - это было суперправильное решение, которое не отменят?
что x++ на клиенте не нужен, а нужен javaScript? тогда зачем вообще нужен X++ - оставили бы сразу javaScript

ну и так далее.
Макс, давай от охранительства вернемся к теме, пожалуйста.
тема: "Как вы думаете почему прогресс средств разработки в ERP отличается от общего прогресса по отрасли (ИТ) в целом?"

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

Цитата:
Сообщение от belugin Посмотреть сообщение
А если сделать его вторым равноправным языком (чтобы можно было бы формы делать и таблицы) или языки подключаемыми? Это можно сделать плавно и постепенно (например, сначала классы и таблицы, потом формы и т.д.) или вообще для начала добиться большей интероперабельности?
Можно и так:
сразу вопросы: если равноправных больше одного, то почему только два? может и SQL сделать полноправным? и javaScript для клиентского кода? где граница?
причем не граница возможностей производителя, а логически обоснованная граница?

что ты подразумеваешь под равноправностью языков? (у меня есть свои соображения, то я бы хотел твои рассуждения послушать)

мы видели много анонсов инноваций, которые умирали не появившись или сразу после ввода. можешь дать какую-то надежду, что будет несколько равноправных языков? причем разработка в условиях нескольких равноправных языков будет экономически целесообразна как для вендора, так и для потребителя.
__________________
полезное на axForum, github, vk, coub.
За это сообщение автора поблагодарили: Lemming (5).
Старый 29.07.2019, 08:58   #25  
axm2017 is offline
axm2017
Участник
 
1,747 / 292 (13) ++++++
Регистрация: 15.05.2017
Цитата:
Сообщение от Lemming Посмотреть сообщение
... Но цель привлечь много программистов в новую на рынке систему за счет простоты - была достигнута!
Цель подозреваю была не в новых программистах а в простоте, быстроте и легкости модификации системы под нужды предприятия.
Старый 29.07.2019, 09:19   #26  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от Lemming Посмотреть сообщение
В 3-й (а так же 4-й и 2009-й) аксапте простую форму тоже легко было сделать и те кто пришел из Delphi штамповали их "как горячие пирожки". Я насмотрелся форм, в которых вывод в Excel был прописан прям в методе clicked (или как там его, уже не помню) кнопки "Печать". Или когда люди упаковывали в статический метод всю бизнес-логику какого-нибудь процесса, а что бы навести в этих километрах кода хотя бы какую-то инкапсуляцию использовали локальные функции. Это реально бравые дельфи программисты. Вся суть этой простоты в аксапте ранних версий сыграла не последнюю роль в том, что ходили шуточки про 90% провальных внедрений. Но цель привлечь много программистов в новую на рынке систему за счет простоты - была достигнута!
Во первых - привлечение программистов в новую на рынке систему вызывается не простотой системой, а экономическими причинами. (То есть - соотношением между зарплатой, спросом, возможностью работать в качестве фрилансера и тп).
Во вторых - по моим собственным наблюдениям, эдак в 85% случаев кривое программирование было вызвано не тем, что программист плохой, а тем что "надо сделать к завтрашнему утру", "бюджета уже почти не осталось", "вот тут клиент посмотрел и попросил слегка изменить - это же 15 минут работы" и тп.
В третьих - по моим наблюдениям, реально плохие программисты, вооруженные голым фортраном, они не так опасны, как реально плохие программисты, вооруженные перегрузкой операций, итераторами, замыканиями и тд и тп.
За это сообщение автора поблагодарили: trud (1).
Старый 29.07.2019, 09:45   #27  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Цитата:
Сообщение от mazzy Посмотреть сообщение
макс, ты очень интересно формулируешь ответ

"есть" - это разработчики в майкрософт сделали.
В дамгард. Приложение - один большой модуль.

Цитата:
а попробовать ты предлагаешь нам в качестве доказательства что что-то невозможно сделать.
В качестве иллюстрации того, на что будет похож эквивалентный обратно совместимый C#.

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

Цитата:
где я такое говорил? приведи цитату и логический переход от цитаты к твоему утверждению.
блин.
"А потом... херакс! и ax7. полностью не совместимая. в которой продцедур апгрейда с предыдущих версий не предусматривалось."

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

Цитата:
А может не заработает.
И что это доказывает?
Что оно не полностью не совместимо. Вот с брейнфаком так не получится, он полностью несовместим.

Цитата:
а тогда - не было


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

Цитата:
а какая разница то ради чего?
Я думал, что кому-то может быть интересно, зачем.

Цитата:
становится как-то смешно.
ты сейчас чего доказать то хочешь?

что выпиливание клиентского x++ - это было суперправильное решение, которое не отменят?
что x++ на клиенте не нужен, а нужен javaScript?
JavaScript потому, что веб (не парить установкой клиента, очистками клиентских кешей и т.д.) - фиг знает, правильно или нет.

Цитата:
тогда зачем вообще нужен X++ - оставили бы сразу javaScript
Это то же самое что и переписать на C#.


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

Цитата:
с тем же выпиливанием клиентского x++... Как ты думаешь, "только серверный код" - это в русле общего прогресса по отрасли? если отличается, то почему и какой смысл в отличии? если отличается, то можно ли ожидать возврата к общему состоянию отрасли ИТ?
В веб языки фронтенда (JS, TS) обычно отличаются отличаются от языков бекенда (PHP, Java, etc) есть NodeJS но это мейнстрим.

Сейчас интересны попытки использховать WebAssembly (например blazor) но это не лишено недостатков. Например blazor призодится загружать сборки mono и это ощутимый penalty на старте. Там даже сделали режим когда все рендерится на сервере и посылается в таком виде клиенту.

Цитата:
Можно и так:
сразу вопросы: если равноправных больше одного, то почему только два? может и SQL сделать полноправным? и javaScript для клиентского кода? где граница?
причем не граница возможностей производителя, а логически обоснованная граница?
2 одновременно чтобы можно было плавно переходить от одного к другому. Для большего количества будет фрагментирована документация инструменты и т.д.

Цитата:
что ты подразумеваешь под равноправностью языков? (у меня есть свои соображения, то я бы хотел твои рассуждения послушать)
Можно написать модуль на X++ или C# с теми же возможностями и примерно с той же трудоемкостью, за исключением разницы в продуктивности языков как таковых.

Цитата:
мы видели много анонсов инноваций, которые умирали не появившись или сразу после ввода. можешь дать какую-то надежду, что будет несколько равноправных языков?
Не могу.
Старый 29.07.2019, 10:44   #28  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от belugin Посмотреть сообщение
В дамгард. Приложение - один большой модуль.

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

Цитата:
Сообщение от belugin Посмотреть сообщение
Возможно, нет стратегической цели перевести все на C#?
возможно?


Цитата:
Сообщение от belugin Посмотреть сообщение
Я так понял, что первое приложение раскрывается вторым, нет?
?!


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

Цитата:
Сообщение от belugin Посмотреть сообщение
Тогда вот тебе альтернативная гипотеза: поддержку апгрейда специально оставили на сладкое. Потому, что все сразу сделать нельзя.
?!?!!!
без комментариев. я думаю, что каждый читатель сможет сделать выводы сам.


Цитата:
Сообщение от belugin Посмотреть сообщение
Я не занимаюсь никаким охранительством - просто уточняю какие-то моменты
А можешь высказать свое мнение на исходный вопрос?

Цитата:
Сообщение от Lemming Посмотреть сообщение
Я пытаюсь понять: почему технологически ERP системы находятся так позади всего того прогресса, который мы сегодня видим в ИТ?
__________________
полезное на axForum, github, vk, coub.
Старый 29.07.2019, 12:49   #29  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Цитата:
Сообщение от mazzy Посмотреть сообщение

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

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

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

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

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


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

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

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

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

3. Иновации действительно есть но в других областях, дополнительная поддержка вебинтерфейса есть у систем про которые я знаю в той или иной форме, например.
Старый 29.07.2019, 13:35   #30  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от belugin Посмотреть сообщение
Дамгард НЕ добавил модели, в результате получился один большой модуль с циклическими ссылками внутри. Микрософт добавил модели и этим пользуется. Например платформа теперь отдельно.

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

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

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

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

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


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

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

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

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

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

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

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

Последний раз редактировалось mazzy; 29.07.2019 в 14:08.
Старый 29.07.2019, 14:09   #31  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от belugin Посмотреть сообщение
Дамгард НЕ добавил модели, в результате получился один большой модуль с циклическими ссылками внутри. Микрософт добавил модели и этим пользуется. Например платформа теперь отдельно.
А может один большой модуль с циклическими ссылками внутри есть отражение реальности предприятия, где все процессы зависят друг от друга и не могут быть разделены?
За это сообщение автора поблагодарили: apanko (4).
Старый 29.07.2019, 21:45   #32  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Цитата:
Сообщение от 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 и немного статической валидации от нее же.

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

В-общем, вот мои мысли, я на истину не претендую и конкретно кто и как принимает решения в этом вопросе не знаю.
Старый 29.07.2019, 21:54   #33  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Цитата:
Сообщение от fed Посмотреть сообщение
А может один большой модуль с циклическими ссылками внутри есть отражение реальности предприятия, где все процессы зависят друг от друга и не могут быть разделены?
Может и так. Это какая-то отдельная дискуссия.

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

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

см. также книжки DDD и Clean architecture
За это сообщение автора поблагодарили: S.Kuskov (2).
Старый 30.07.2019, 00:25   #34  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Цитата:
Сообщение от fed Посмотреть сообщение
А может один большой модуль с циклическими ссылками внутри есть отражение реальности предприятия, где все процессы зависят друг от друга и не могут быть разделены?
С учетом того, что некоторым клиентам удалось [путем невероятных трудозатрат] подключить внешнюю систему управления складом, включая синхронизацию остатков, то исходный конгломерат можно было с самого начала поделить на слабо связанные модули.

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

Последний раз редактировалось EVGL; 30.07.2019 в 00:27.
Старый 30.07.2019, 07:06   #35  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от belugin Посмотреть сообщение
(Типа, БУ не знает про Производство, производство не знает про БУ, есть модуль БУПроизводства, который знает обоих - подписывается на события в производстве и отображает их на БУ и наоборот, если где-то такое надо).
см. также книжки DDD и Clean architecture
Такие же концепции в реальной жизни не работают. т.е. за примерами далеко ходить не надо, возьмите совершенно новый код по разноске ГК в 2012, где точки расширения и делегаты расставлены в каждом методе, но при столкновении с реальной задачей корреспонденции в РФ проще оказалось удалить все проводки и заново их сформировать вместо подписок на события

Цитата:
Сообщение от belugin Посмотреть сообщение
Сделали события, более строгую рантайм семантику типов, var, объявления переменных в любом месте метода, internal, методы расширения, CoC, pre-post handlers и переписали полностью компилятор на C# чтобы было удобней делать дальнейшие улучшения.
Это все слабо относится к потребностям внедрения и поддержки. Ну т.е. незначительные удобства. Есть же сильные шаги назад
-Убрали перекрестные ссылки(убрали Read-Write к полям таблицы), не поддерживают их в ряде случаев и т.п.
-Удобство работы с метками, они не видны на объектах
-Убрали форму трассировки долгих запросов, где можно было увидеть стек трейс откуда идет запрос.
-Убрали возможность просмотреть зависимость методов которые вы меняете и методов которые меняются в очередном сервис паке
ну и т.д.
Т.е. если брать средства разработки, то единственное преимущество сейчас перед прошлой версией - это то, что код можно проще шарить и куда-то выкладывать, по многим остальным статьям, это шаг назад. Вот это не очень понятно почему происходит
Старый 30.07.2019, 08:18   #36  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Цитата:
Сообщение от trud Посмотреть сообщение
Такие же концепции в реальной жизни не работают.
Вы очень категоричны

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

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

Цитата:
Это все слабо относится к потребностям внедрения и поддержки. Ну т.е. незначительные удобства. Есть же сильные шаги назад
-Убрали перекрестные ссылки(убрали Read-Write к полям таблицы), не поддерживают их в ряде случаев и т.п.
...
А это уже не про циклические ссылки а про что? Cтало лучше или нет? Почему в ERP нет прогресса в отличие мейнстима?
Старый 30.07.2019, 08:33   #37  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от belugin Посмотреть сообщение
Почему в ERP нет прогресса в отличие мейнстима?
Ну надо начать с определения понятия прогресса.
Т.е. если подразумевать под этим бытовое - что на одну и туже задачу уходит меньше времени чем было раньше, то прогресса как-то особо то и не видится, все становится тежелее и дольше
Правда есть и обратный положительный момент этого - поскольку трудоемкость одних и тех же задач растет, растет и потребность в программистах, что довольно неплохо

Последний раз редактировалось trud; 30.07.2019 в 08:40.
Старый 30.07.2019, 09:05   #38  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Цитата:
Сообщение от trud Посмотреть сообщение
Ну надо начать с определения понятия прогресса.
Т.е. если подразумевать под этим бытовое - что на одну и туже задачу уходит меньше времени чем было раньше, то прогресса как-то особо то и не видится, все становится тяжелее и дольше
Это данные по каким системам?
Старый 30.07.2019, 09:27   #39  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Обсуждаем АХ
Старый 30.07.2019, 09:48   #40  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Цитата:
Сообщение от trud Посмотреть сообщение
Обсуждаем АХ
См первое сообщение

Вопрос еще более глобальный: почему вендоры не хотят менять эту ситуацию? Языку программирования 1С больше 10-ти лет, он никак не развивается. С глобальной точки зрения с этим языком им закрыт выход на мировой рынок! (Ну потому что Cobol II никому не нужен)
Теги
1c, abap, axapta, sap, xpp

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
О причинах неудачных внедрений ERP Poleax Курилка 4 11.09.2010 16:29
Встреча ИТ-специалистов в области ERP 18 декабря 2007 года George Nordic Курилка 15 19.12.2007 11:56
Почему медленно работают сложные ERP системы ;-) Dzemon Курилка 0 28.03.2007 11:27
На сколько оправдана концепция ОПП в средствах разработки ERP-систем? ibc Курилка 97 23.08.2006 15:54
Встреча ИТ-специалистов в области ERP-систем в г. Москва 12 августа 2005г. George Nordic Курилка 115 21.09.2005 10:17
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 15:10.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.