DeniZone: The future of X++

[gl00mie]

Цитата:

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

Вообще - еще раз перечитал все эти дискуссии по поводу перехода на CLR

В дополнение к этому можно еще раз послушать (или почитать), о чем говорится в исходной презентации.

Цитата:

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

и нашел только два довода в пользу того, почему это хорошо: 1. Не надо учить новый язык программирования для новых разработчиков. Эти наивные люди до сих пор думают что разработчики X++ используют только для создания новых форм и интеграции с внешними приложениями. Реально - X++ учиться за месяц, может - три. Все остальные годы уходят на изучение прикладной логики системы. Резюме - аргумент не катит.

Во-первых, Х++ учить все же дольше месяца-трех, потому что в нем очень много мелких "особенностей", совершенно неочевидных и непонятных для тех, кто до этого учил С++/C#/VB... Во-вторых, и об этом говорилось в исходной презентации, не каждый сторонний разработчик захочет вообще учить X++. Если человек хорошо знает тот же C# и .NET, если фанатеет от возможностей последних версий Visual Studio, может, сам пишет какие-нить шаблоны под T4, то его будет сложно уговорить изучить язык, который хоть и похож на Java, но все же довольно специфичен сам по себе и при этом используется в одной-едиственной системе (как правильно было замечено, функционал системы еще тоже придется изучать). Плюс к этому разработка ведется не в VS, где сейчас пишется практически всё - от сайтов и баз данных до драйверов устройст, а в собственной среде с весьма "недогадливым" по сравнению с VS intellisense'ом, с глюкавеньким отладчиком, не умеющим останавливаться на последней фигурной скобке метода, чтобы показать, какое именно значение тот вернет, или, тем более, показывать, что происходит в классах ядра, или ставить там точки останова ("все-таки где же эта [censored], которая выставляет allowEdit() на datasource'е?!"). Даже если писать код "сбоку" на том же C#, взаимодействуя с AX через Business Connector, то опять же, приходится дергать приложение фактически с использованием одного из инструментов отражения, без какой-либо поддержки intellisense, постоянно подсматривая числовые значения енумов либо дублируя их в своем коде - в общем, удовольствие то еще.
А в случае перехода на CLR, как отмечалось в той же презентации, новым разработчикам не надо будет месяц-три-шесть учить X++, который им больше нигде не пригодится. Вместо этого работодатели смогут говорить им: вы будете работать в привычной среде, использовать .NET, развиваться как разработчик C# (например) - плюс к этому еще и приобретете опыт разработки бизнес-приложений. Мне сложно прогнозировать, как это может отразиться на рынке труда программистов Axapta, но для работодателей определенный плюс в этом, мне кажется, есть. Кроме того, даже интеграция с приложением может упроститься за счет отказа от Business Connector и от работы с классами и таблицами через отражение. Вон, в презентации подцепили к проекту 64-мегабайтную сборку с кодом всех классов и таблиц приложения AX - и все они для разработчика стали, как на ладони, с поддержкой intellisence и всего прочего.

Цитата:

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

2. Ускоряется работа сборщика мусора. Эээ. Возможно. А если в native code компилировать - она ведь еще бы сильнее выросла ? Чтож вы ребята на p-code остановились-то?

Не знаю, как в 4-ке или в 2009-й изменился p-код, я не ковырял, а в 3-ке его реализация очень и очень простая: есть таблица из 256 возможных кодов (в общем случае каждому ключевому слову языка, такому как for, while, if, select, forceplaceholders и т.д. соответствует свое однобайтовое значение, плюс еще операторы и проч.), причем реально используются, может, сотни полторы значений, есть массив указателей на функции-обработчики отдельных кодов (неиспользуемым кодам в массиве указателей соответствует ссылка на один и тот же обработчик некорректного байт-кода). Соответственно, интерпретатор считывает байт p-кода, увеличивает "указатель команд" (по аналогии с EIP в x86), затем использует считанный код как индекс в массиве указателей на функции-обработчики и вызывает нужную функцию; та, в зависимости от реализуемой операции, извлекает из потока p-кода дополнительные аргументы, соответственно увеличивая "указатель команд", либо не делает этого, если аргументы не предусмотрены, и собственно делает что-то полезное. Да, есть витиеватый код поддержки "CQL" (так вроде в ядре именуется реализованное подмножество SQL), есть менеджер управления памятью, сборщик мусора, подсчет ссылок на объекты и т.д., но сама по себе стековая машина, обрабатываютщая p-код, выглядит довольно просто. Если бы пришлось компилировать код приложения в машинные инструкции, то мало того, что пришлось бы реализовывать на порядки более сложную логику работы компилятора, реализовывать в коде RTTI и проч., так еще и интерфейс между кодом приложения и сервисами ядра (поддержка CQL, управление памятью и проч.) усложнился бы весьма существенно. Я уже не говорю о том, что пришлось бы реализовывать полноценный отладчик с поддержкой выполнения машинного кода x86 (тут можно вспомнить применяемую компиляторами для оптимизации по скорости перегруппировку инструкций x86 для задействования нескольких конвейеров обработки команд в процессоре). Кроме того, это в любом случае не решило бы озвученную в презентации проблему с плохой масштабируемостью системы управления памятью, использующей детерминированную сборку мусора. В общем, слишком много сложностей с более чем весомыми затратами на реализацию и неопределенным выйгрышем в производительности. В презентации тоже звучали мысли на эту тему:

• Нам не следует самим нести все затраты, связанные с поддержкой и развитием всей инфраструктуры, когда есть такие отличные вещи, как .NET, и Visual Studio, и LINQ.
• На данный момент в нашем приложении появились опеределенные проблемы, связанные с тем, что разработчики начали использовать X++ так, как мы совершенно не расчитывали на момент разработки языка.
• Наша команда X++ довольно малочислена, и мы знали, что нам никогда бы не выделили финансирование на полное переписывание компилятора под создание управляемого кода, от начала до конца, поэтому мы решили пойти на небольшой компромис. Таким образом, весь стек инструментов разработки, который у нас есть и который использовался и тестировался на протяжении 15 лет, остается в полной неприкосновенности, в нем не меняется ни строчки исходного кода. Так что нам не нужно проводить обширное тестирование всего кода X++ во всем мире на совместимость с нашей разработкой.

Заметьте: "красноглазики" вовсе не просто так от нечего делать начали заниматься вопросами детерминированной сборки мусора в системе управления памятью AX. Возникла проблема с производительностью, в команду X++ поступил запрос разобраться в причине и как-то решить проблему. Они разобрались и выяснили, что все упирается систему управления памятью, которая начинает тормозить на очень большом количестве объектов в памяти. Решить собственными силами проблему не удалось - вот и попробовали задействовать в некотором смысле стороннее решение.

Цитата:

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

В общем - мое резюме: Красноглазики добрались до ядра Аксапты. Как и зачем она используется они слабо понимают, но явно присутствует желание за казенный счет попрограммировать чего-то большое и светлое, "для души"...

Ну, поживем - увидим. В любом случае, думаю, раньше AX "2013" это все в ядре не появится.