Прощай, X++

[Logger]

Я думаю вы обсуждаете маловажные вещи.
Гораздо важнее прикладной функционал которые создается на платформе DAX. Для удовлетворения нужд клиентов достаточно X++ в том виде как он есть на ax2009. Он не сдерживает развитие системы.
Вот если завтра MS подпрыгнет и выпустит мегаобновление, благодаря которому резко упадет необходимость в доработках - только настройки делай - вот это будет шаг вперед. Никто и не спросит - чего там у Аксапты под капотом, C#, X++ или Кобол.

[macklakov]

Цитата:

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

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

Вот в том и проблема, что с использованием CIL, WCF, WF и прочих делегатов, в AX понаваяли какое-то зашкаливающее количество глюков.
На той неделе попытался использовать стандартный импорт Bank Statement, сделанный через AIF. Это шедеврально. Там есть почти все, и XSLT и исполнение в CIL и делегаты и дизайн-патерны. Только вот работать с ним невозможно. И починить получается на порядок сложнее, чем написать с нуля свой импорт. По какой-то парадоксальной причине изысканность и обилие использовуемых инструментов ухудшило читаемость кода и его надежность.
Т.е. качество на уровне АвтоВАЗ традиционно, конечно. Свежеинстоллированную систему всегда нужно было чинить. Но вот в последней версии это гораздо сложнее делать стало. Может это просто совпадение. Но .Net в AX теперь прочно ассоциируется с глюками, которые крайне сложно отлаживать.

[fed]

Цитата:

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

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

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

И есть сильнейшее подозрение что MS этого не понимает... Хотя в маркетинге они много говорят о более низкой TCO чем у SAP, на практике - большая часть нового функционала в очередной версии не снижает, а увеличивает TCO. В результате мы рискуем получить через 3-4 версий Dynamics AXAP - в прикладном смысле тяжелый в настроке как SAP, но при этом со всеми глюками и рисками порожденными микрософтовской гонкой технологий.

[belugin]

Цитата:

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

Я думаю вы обсуждаете маловажные вещи.
Гораздо важнее прикладной функционал которые создается на платформе DAX.

Для удовлетворения нужд клиентов достаточно X++ в том виде как он есть на ax2009. Он не сдерживает развитие системы.

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

Зачем компании поддерживать 2 языка?

[Logger]

Цитата:

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

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

Зачем компании поддерживать 2 языка?

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

P.S.
Кстати, как вы думает почему X++ сохранили ?
Есть какие-то технологические ограничения ? (Про сборку мусора я выше писал предположение)

[ax_mct]

Цитата:

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

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

P.S.
Кстати, как вы думает почему X++ сохранили ?
Есть какие-то технологические ограничения ? (Про сборку мусора я выше писал предположение)

>>Кстати, как вы думает почему X++ сохранили ?
Большие затраты и неоправданные риски на замену шила на мыло.
Отсутствие какого-либо профита для продаж и для клиентов.
То есть обосновать необходимость замены языка программирования - невозможно.

При этом думаю что какие-то попытки были на уровне проектов/Proof Of Concept.
И если бы замена технически была легкой то была бы параллельная версия DAX на .NET. Но ее уже три года как нет после таких попыток - значит не один фунт изюма съесть.

[fed]

Цитата:

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

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

Зачем компании поддерживать 2 языка?

А что мне как клиенту или партнеру с экономии бабла MSом ? Может вы ценник снизите ?

[belugin]

Цитата:

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

А что мне как клиенту или партнеру с экономии бабла MSом ? Может вы ценник снизите ?

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

[macklakov]

Цитата:

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

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

Нет, не будет, т.к. язык учится максимум за месяц, а вот библиотеки и схема данных изучается годами. Ибо документации не было и нет. Но если раньше все было написано на более-менее читаемом самобытном языке, то сейчас огромное количество ниточек уходит в черные ящики интеграции. В результате, существующие специалисты были разжалованы в junior просто фактом выпуска 2012. А замещение в виде пакистанцев, радостно берущихся написать любой SSRS отчет и любую XSLT конвертацию, не сработало. Они смотрят в базу и ничего не понимают.

[belugin]

Цитата:

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

Нет, не будет, т.к. язык учится максимум за месяц, а вот библиотеки и схема данных изучается годами.

То есть месяц сэкономим? (кстати, глюки X++, дебагерра и профайлера включены в этот месяц ?)

Цитата:

Ибо документации не было и нет. Но если раньше все было написано на более-менее читаемом самобытном языке, то сейчас огромное количество ниточек уходит в черные ящики интеграции. В результате, существующие специалисты были разжалованы в junior просто фактом выпуска 2012. А замещение в виде пакистанцев, радостно берущихся написать любой SSRS отчет и любую XSLT конвертацию, не сработало. Они смотрят в базу и ничего не понимают.

При чем тут язык?

[macklakov]

Цитата:

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

То есть месяц сэкономим? (кстати, глюки X++ дебагерра и профайлера включены в этот месяц)

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

Цитата:

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

При чем тут язык?

При том, что .Net это бешенный зоопарк языков, с возможностью поставлять сборки без исходников. + огромное количество авто-генерированного кода.
Если бы продукт был стабильным, а докуметация адекватной, это бы не было проблемой. Но традиционно x++ исходники являются самой вменяемой документацией. В 2012-й читаемость кода и базы кардинально ухудшились. А глюков меньше не стало. И документация вменяемостью не блещет.
Пытать черный ящик занятие неблагодарное. А .net пока что превращает AX в огромный черный ящик, наполненный сломанными шестеренками и перегоревшими транзисторами

[macklakov]

Цитата:

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

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

Например на нормализацию данных? На запихивание кода в одну базу с данными, а потом выковыривание кода в отдельную базу? На создание принудительно глобальных справочников, а потом выпуск заплатки в виде "партиций"? Или на запихивание в AIF вещей, которым там не место? А может на привинчивание тысячи внешних компонент, которые экспоненциально мультиплицируют вероятность сбоев?