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

[Lemming]

Я сначала думал «набросить», но потом решил пояснить свою мысль. 10 лет назад все те, кто работает с системами Microsoft читали и мечтали про .NET Иногда на этом форуме возникали споры: что лучше X++ SQL или LINQ!? Все ждали Project Green и что вот вот все изменится.

Ничего кардинально не изменилось, кроме того что все усложнилось на «бэкенде» (я сейчас про внутренности системы). В AX2012 появилась компиляция в .NET CIL, при этом на «клиенте» остался p-code и все это хотя и работало, но работало несуразно и я сразу скажу, что у меня минимальный опыт с AX2012, но я прекрасно помню как весь CIL AOT в некоторых ситуациях ломался и все приходилось перестраивать.

Появилась D365FO. Там «убрали» клиент и оставили только сервер, на котором все уже теперь реально из Х++ компилируется в .NET CIL. Результаты можно почитать в соседней ветке про Ламоду, но смысл в том, что у нас до сих пор Х++, пускай и с атрибутами методов, но все тот же.

Мой вопрос вот в чем: от реальной аксапты которая все еще была в версии 2009 осталось очень мало, но при этом «мы» до сих пор используем Х++ созданный еще компанией Damgaard, причем скопированный с Java образца 1998 года и то не полностью. Почему? Что мешало Microsoft заменить все на C#? Legacy code? Ну может быть, но там уже даже в 2012-й все внутри бизнес-логики перепахали почти полностью!

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

Почему самый крутой гигант ERP - SAP до сих пор использует ABAP, при том что, несмотря на их «заигрывания» с Java, они так полностью на нее и не перешли. Хотя у них даже свой Java EE Application Server есть.

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

[imir]

Язык не шарп, потому что в шарпе нет t-sql, а в шарпе много лишнего для ide dax.
Говоря про прогресс - компилятор это как раз шаг назад, частично из-за него ушли на расширения. МС должен был давно купить, украсть, изобрести заново гибридный режим исполнения кода, как у явы.

[belugin]

Цитата:

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

Язык не шарп, потому что в шарпе нет t-sql, а в шарпе много лишнего для ide dax.
Говоря про прогресс - компилятор это как раз шаг назад,

В каком смысле?

Цитата:

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

Tiered compilation заново изобрели в .NET Core 2.1 если вы про него.

[trud]

Цитата:

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

Появилась D365FO. Там «убрали» клиент и оставили только сервер, на котором все уже теперь реально из Х++ компилируется в .NET

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

Цитата:

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

Мой вопрос вот в чем: от реальной аксапты которая все еще была в версии 2009 осталось очень мало, но при этом «мы» до сих пор используем Х++ созданный еще компанией Damgaard, причем скопированный с Java образца 1998 года и то не полностью. Почему? Что мешало Microsoft заменить все на C#? Legacy code? Ну может быть, но там уже даже в 2012-й все внутри бизнес-логики перепахали почти полностью!

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

[mazzy]

Цитата:

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

Думаю банально в МС нет людей уровня тех кто разрабатывал АХ изначально.

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

Цитата:

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

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

Нет конечно
народу важно соотношение цена/качество в целом по продукту.

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

[trud]

Цитата:

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

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

Немного неправильно выразился, скорее не люди, а связка "люди+руководители+мотивация+процессы."
т.е. пусть даже есть отличные архитекторы, которые отлично описывают как решить актуальные проблемы -- и далее это все отправляется на кодирование и реализацию в Индию, и мы имеем что имеем. - думаю так было с модулем дата-менеджемент
ну или с ER - почему Docentric выпускает такие статьи https://ax.docentric.com/are-configu...5fo-reporting/ а не разработчики Microsoft(типа мы проанализировали проблемы, существующие решения на рынке и хотим предложить бомбу )

[mazzy]

Цитата:

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

Немного неправильно выразился, скорее не люди, а связка "люди+руководители+мотивация+процессы."

в такой формулировке согласен.

Цитата:

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

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

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

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

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

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

=====
Добавил, чтобы не казалось, что это проблема локализации:

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

Цитата:

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

ну или с ER - почему Docentric выпускает такие статьи https://ax.docentric.com/are-configu...5fo-reporting/ а не разработчики Microsoft(типа мы проанализировали проблемы, существующие решения на рынке и хотим предложить бомбу )

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

============
и да, я совсем забыл об одной вещи:
внутри мс царил стиль "куда эти пользователи от нас денутся?". иногда перерастающий в совершенно неприличное "конкуренты? что это такое? да там в углу на коврике"
Зачем экс-глава Microsoft в России создает ERP и CRM на базе 1С: интервью гендиректора World Class Николая Прянишникова
прям советский союз какой-то.

и ладно бы наши такой стиль диктовали... было бы понятно что делать.

[mazzy]

Цитата:

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

от реальной аксапты которая все еще была в версии 2009 осталось очень мало

на самом деле - очень много. особенно в части бизнес-логики. и заложенных в бизнес-логику принципов.

Цитата:

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

но при этом «мы» до сих пор используем Х++ созданный еще компанией Damgaard, причем скопированный с Java образца 1998 года и то не полностью. Почему? Что мешало Microsoft заменить все на C#?

когда я работал в майкрософт, то видел внутренний документ,
в котором взвешенно оценивались последствия и необходимые усилия перевода аксапты на c#. Документ был написан в духе "не нарушить совместимость".

прежде всего по разному обрабатываются строки с ограниченной длиной.
в C# все строки бесконечной длины, а в X++ сроки с edt всегда тримятся и обрезаются.
в результате констркуции типа AccountNum+AccountName могут дать разный результат в C# и в X++

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

Ну и пресловутые ключевые слова select, update_recordset и т.п. По ним в документы были очень любопытные предложения.

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

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

А все почему? А руководство поменялось.

Цитата:

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

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

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

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

другое дело, что например в X++ вполне можно было бы задействовать и перегрузку методов и генерики. Но пока команда занимается другими вещами - делает из открытой системы закрытую с плагинами и точками расширения (кстати, тоже холивар давно минувших дней) и переводит исходный код из хранилища aod/utilElements в файлы (тоже очень древняя тема).

===========
Во-вторых - а почему так происходит?

Не почему позади фронтира (это то как раз понятно), а почему так лоскутно и усложненно? ("все усложнилось на «бэкенде»")

помимо компиляции в CIL можно вспомнить:
* роле ориентированный интерфейс
* ListPage
* корпоративный портал (привнес web объекты в AOT, выкинут)
* корпоративный портал на SharePoint (привнес DataSet объекты, выкинут)
* OLAP (те же Data sets, выкинуто)
* Partitions (выкинуты)
* виртуальные компании выпилили поскольку не разобрались как с ними работать во внешних системах
* наследование таблиц (введено и выпилено в следующем сервис-паке)
* Permissions в коде на сервере, будь они не ладны
* отчеты на Reporting Service и соглашение о dataContracts
* новая и улучшенная схема размещения контролов в ax2012
* SysOperationProgress и пресловутый фрейворк, который все не может заменить
* подзадачи в пакетном сервере
* "суперэффективное" хранение кода в SQL базе было выпилено и заменено на "традиционное" хранение кода в файлах (но при этом почему-то как xml, му-ха-ха)
* полностью прибили клиентский код в ax7 (может и вернут: людям надо работать с оформлением формы, людям надо создавать свои контролы на форме, людям надо работать с оборудованием клиентского компьютера, см Retail)
* закрыли код и ввели расширения. Но при этом не хватило умений добавить точки расширения в длиннющие методы на несколько сотен строк (а такая технология есть конечно. например, весь движок этого форума построен на плагинах)
* перевели в ажур, но для этого отобрали админский доступ к СВОЕЙ базе данных и возможность отладки в Проде

и так далее.

поэтому нельзя сказать, что совсем ничего не делается. делается. активность зашкаливает.

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

причина по моему - система работы руководителей в крупных корпорациях.
руководитель назначается на некоторый период. как правило на 1 (один) финансовый год.

причем в современных реалиях этот период заведомо меньше, чем время, необходимое для реально полезного изменения системы. так, ax7 была явно переходной системой. да и ax8 концептуально готовой не назовешь.

понятно, что перевод с X++ на C# - это огромный проект, который за один финансовый год точно не выполнить.

также можно вспомнить проект Electronic Reporting (ER), который длится уже несколько финансовых лет. И опять же нельзя сказать, что он готов к конкуренции с уже существующими на рынке решениями.

Что делать руководителю, у которого мандат на 1 год и задачи длительностью в 3-5 его мандатов?
А выбирать "киллер-фичи", которые хотя бы предположительно можно сделать за 1 год. См. список выше.
Сделал? ну хоть KPI какие-нибудь выполнил? молодец! А что дальше? Дальше он пойдет по карьерной лестнице на другую должность.
Ась? Что-что? Пользователи? вот же, они получили такую замечательную киллер-фичу. Радуйтесь.

Причем, что я вынес для себя лично во время работы в МС.
в МС дураков нет. Все всё понимают. И рядовые сотрудники, и руководители.
Но сделать ничего не могут. Причем когда я там был, то уже рядовые сотрудники уже и не пытались что-то с этим сделать.

=============
В вопросе звучал 1С.
В 1С на самом деле то же самое. Там конечно Нуралиев Б. и Нуралиев С. гораздо ближе к земле, поэтому не настолько запущено. Но и там есть руководители. Да их сроки не настолько жесткие как в МС. Но в принципе то же самое.

Про САП. Там, насколько я понимаю, все сильно жестче со сроками и KPI, чем в Майкрософт. Наружу проявляется в том, что директора российского подразделения меняются в последнее время чаще чем раз в год

что с этим делать - хз.

[belugin]

Цитата:

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

Документ был написан в духе "не нарушить совместимость".

А еще есть гигантский модуль под названием "ApplicationSuite" который при генерации IL приходится разбивать на netmodule и для конвертации в C# пришлось бы рейфакторить на подмодули, разруливать перекрестные ссылки и так далее.

А еще есть всякие extensibility фичи типа подписки на начало и завершения любого метода. В-общем, попробуйте взять любой свой модуль, написанный на X++ и декомпилировать в C# - посмотрите на что был бы похож эквивалентный код.

Цитата:

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

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

Во-вторых, сейчас я вижу документацию по апгрейду.

В-третьих, обратная совместимость нужна для своего собственного application suite (соответственно трата сил и порождение большего количества глюков)

Цитата:

А все почему? А руководство поменялось.

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

Цитата:

* "суперэффективное" хранение кода в SQL базе было выпилено и заменено на "традиционное" хранение кода в файлах (но при этом почему-то как xml, му-ха-ха)

для поддержки слоев!

Цитата:

* полностью прибили клиентский код в ax7 (может и вернут: людям надо работать с оформлением формы, людям надо создавать свои контролы на форме, людям надо работать с оборудованием клиентского компьютера, см Retail)

Свои контролы делать можно см. "extensible controls" => клиентский код есть, только он не на X++ а на JavaScript

Цитата:

понятно, что перевод с X++ на C# - это огромный проект, который за один финансовый год точно не выполнить.

А если сделать его вторым равноправным языком (чтобы можно было бы формы делать и таблицы) или языки подключаемыми? Это можно сделать плавно и постепенно (например, сначала классы и таблицы, потом формы и т.д.) или вообще для начала добиться большей интероперабельности?

[mazzy]

макс, ты очень интересно формулируешь ответ

Цитата:

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

А еще есть гигантский модуль ...
А еще есть ....
попробуйте ...

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

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

Цитата:

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

Ну отсутствие процедуры апгрейда не означает что она полностью несовместима

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

Цитата:

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

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

А может не заработает.
И что это доказывает?

Цитата:

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

Во-вторых, сейчас я вижу документацию по апгрейду.

а тогда - не было

Цитата:

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

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

конечно гипотеза.
по данному вопросу - это какому? что руководство поменялось?

Цитата:

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

для поддержки слоев!

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

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

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

Цитата:

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

Свои контролы делать можно см. "extensible controls" => клиентский код есть, только он не на X++ а на JavaScript

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

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

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

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

Цитата:

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

А если сделать его вторым равноправным языком (чтобы можно было бы формы делать и таблицы) или языки подключаемыми? Это можно сделать плавно и постепенно (например, сначала классы и таблицы, потом формы и т.д.) или вообще для начала добиться большей интероперабельности?

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

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

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

[belugin]

Цитата:

Сообщение от 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# с теми же возможностями и примерно с той же трудоемкостью, за исключением разницы в продуктивности языков как таковых.

Цитата:

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

Не могу.

[mazzy]

Цитата:

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

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

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

Цитата:

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

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

возможно?

Цитата:

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

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

?!

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

[Logger]

2 mazzy. Извини за занудство, но с усечением строк они дали задний ход, как и с наследованием табличек.
mfp: X++ in AX7: String truncation

[mazzy]

Цитата:

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

2 mazzy. Извини за занудство, но с усечением строк они дали задний ход, как и с наследованием табличек.
mfp: X++ in AX7: String truncation

да-да. как в анекдоте: и соли нелись, и денег потратили
и возможность перейти на C# потеряли

[fed]

Я чуть-чуть дополню и немного не соглашусь с mazzy,
Во первых в DAX2012 радикально изменились главная книга, конфигуратор продукции и ресурсное планирование. Добавился новый модуль упраления складом. Все остальное что изменилось и добавилось - это маркетинговые фичи очень ограниченного применения. При этом - только новая ГК принципиально не совместима с аксаптой по идеологии (и вообще кривой кусок дерьма). Все остальное - совместимо на уровне идеологии как раз. Так что я бы сказал что в DAX2012 - 85% кода совместима с аксаптой по идеологии, и процентов 70 - просто совместимо.
Во вторых - на уровне топ-менеджмента в MS, нормальный срок сидения на должности - это лет 5. Да - есть годовые результаты и метрики, но по моему впечатлению, чтобы тебя слили, надо зафакапить два годовых плана подряд. На уровне среднего менеджмента - горизонт планирования - года два -три. Там подход - запилить killing featue->промаркетить себя хорошенько->Уйти в другое подразделение с повышением - работает в полный рост. Именно этому подходу обязаны своим существованием наследование таблиц, SysOperation, новая ГК и распределения, методология SureStep.
В третьих - а ты вообще уверен что прогресс в средствах разработки - он реальный а не маркетинговый ? То есть - с точки зрения enterprise, последняя технология, которая реально окупала свое внедрение была трехзвенка, внедренная аж 20 лет назад. Все что было после - это были попытки (пусть и успешные) выдать все новые и новые поколения весьма нишевых технологий за очередную технологическую панацею. Со средствами разработки, картина примерно аналогичная. Да - наверное с generics, замыканиями и итераторами на уровне языка можно было бы писать код местами покрасивее и побыстрее, но особого прорыва это бы не произвело.

[mazzy]

Цитата:

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

Я чуть-чуть дополню и немного не соглашусь с mazzy,

ура!

Цитата:

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

Во первых в DAX2012 радикально изменились главная книга, конфигуратор продукции и ресурсное планирование. Добавился новый модуль упраления складом. Все остальное что изменилось и добавилось - это маркетинговые фичи очень ограниченного применения.

согласен про функционал.
не согласен про платформу.

убрали старые отчеты и добавили Reporting Service именно в 2012

добавили в платформу пре- пост- EventHandler'ы и делегаты именно в 2012, а уже потом в акс7 эти инструменты стали использоваться в полный рост в экстеншенах. и уже сильно потом случился code seal и перевод всех модификаций в... пре- и пост- обработчики. понятно, что потом техника и реализация этих инструментов изменилась. но появились то они в 2012. это значит, решение по ним было принято еще раньше.

Опять же компиляция в CIL появилась именно в 2012. пусть и в режиме опции.

Цитата:

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

Так что я бы сказал что в DAX2012 - 85% кода совместима с аксаптой по идеологии, и процентов 70 - просто совместимо.

согласен.

Цитата:

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

Во вторых - на уровне топ-менеджмента в MS, нормальный срок сидения на должности - это лет 5. Да - есть годовые результаты и метрики, но по моему впечатлению, чтобы тебя слили, надо зафакапить два годовых плана подряд. На уровне среднего менеджмента - горизонт планирования - года два -три. Там подход запилить killing featue->промаркетить себя хорошенько->Уйти в другое подразделение с повышением работает в полный рост. Именно этому подходу обязаны своим существованием наследование таблиц, SysOperation, новая ГК и распределения, методология SureStep.

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

но тут могу сильно ошибаться.

мне кажется, что можно отделить период Кирилла Татаринова и период Сатьи Наделы. Где-то между произошли очень сильные изменения.

Цитата:

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

В третьих - а ты вообще уверен что прогресс в средствах разработки - он реальный а не маркетинговый ?

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

Цитата:

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

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

дело не в красоте и быстроте.
дело в стоимости разработки и поддержки.

покопавшись в Котлине, я точно уверен, что генерики уменьшают стоимость разработки библиотеки и стоимость изучения библиотек.

я точно уверен, что перегрузка методов уменьшает стоимость программирования.
просто ломает возвращаться в джаву первого поколения (X++), попрограммировав в других языках. в той же java 8

абсолютно точно уверен насчет итераторов. уменьшают стоимость разработки. даже в X++
https://github.com/mazzy-ax/SysEnumerators

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

но тут важно что - использовать библиотеки .net без генериков и перегрузки методов - очень муторно. не говоря уже об обратном - использование классов Аксапты из .net приложения.

в общем, на мой взгляд, стоимость разработки снизилась бы существенно, если бы просто начали использовать C# или довели X++ до текущего развития C#.
Совместимость они жеж все равно потеряли в ax7

[belugin]

Цитата:

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

В третьих - а ты вообще уверен что прогресс в средствах разработки - он реальный а не маркетинговый ? ... Да - наверное с generics, замыканиями и итераторами на уровне языка можно было бы писать код местами покрасивее и побыстрее, но особого прорыва это бы не произвело.

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

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

[Lemming]

Цитата:

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

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

В 3-й (а так же 4-й и 2009-й) аксапте простую форму тоже легко было сделать и те кто пришел из Delphi штамповали их "как горячие пирожки". Я насмотрелся форм, в которых вывод в Excel был прописан прям в методе clicked (или как там его, уже не помню) кнопки "Печать". Или когда люди упаковывали в статический метод всю бизнес-логику какого-нибудь процесса, а что бы навести в этих километрах кода хотя бы какую-то инкапсуляцию использовали локальные функции. Это реально бравые дельфи программисты. Вся суть этой простоты в аксапте ранних версий сыграла не последнюю роль в том, что ходили шуточки про 90% провальных внедрений. Но цель привлечь много программистов в новую на рынке систему за счет простоты - была достигнута!

[axm2017]

Цитата:

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

... Но цель привлечь много программистов в новую на рынке систему за счет простоты - была достигнута!

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

[fed]

Цитата:

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

В 3-й (а так же 4-й и 2009-й) аксапте простую форму тоже легко было сделать и те кто пришел из Delphi штамповали их "как горячие пирожки". Я насмотрелся форм, в которых вывод в Excel был прописан прям в методе clicked (или как там его, уже не помню) кнопки "Печать". Или когда люди упаковывали в статический метод всю бизнес-логику какого-нибудь процесса, а что бы навести в этих километрах кода хотя бы какую-то инкапсуляцию использовали локальные функции. Это реально бравые дельфи программисты. Вся суть этой простоты в аксапте ранних версий сыграла не последнюю роль в том, что ходили шуточки про 90% провальных внедрений. Но цель привлечь много программистов в новую на рынке систему за счет простоты - была достигнута!

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