DeniZone: The future of X++

[Blog bot]

Источник: http://denizone.blogspot.com/2009/09/future-of-x.html
==============

During the summmer Microsoft announced that X++ based Web User Interface is discontinues in the next version of EP which hardly comes as a surprise - Dilip has some nice thoughs on the subject, and as he says this will allow developers to use Web 3.0 Framework.

On Channel 9 - "Dynamics Program Manager Peter Villadsen and Software Developer Gustavo Plancarte teach us about a new tool they've developed that translates X++ byte code into MSIL. We learn a lot of history along the way and gain insights into the process of taking X++ into the .NET age.

Microsoft Dynamics features a proprietary language called X++ (basically a superset of Java, with some strong data primitives added) and a complete stack (compiler, interpreter and debugger) that goes with it. The new feature Peter and team have developed is a tool to generate managed code from the X++ intermediate language produced by the X++ compiler. This will have profound impact on the performance of the business applications written in X++, and it very clearly points to where they'll be going in the next few releases of Dynamics Ax."

Watch the video here.

My thoughts on the subject - as I posted on Dilip's blog, is that X++ sooner than later will become the new COBOL; 'pure' X++ code and developers will never die completly due to the exsisting code-base already out there, which has to be maintained but when the full implementation of an intermedia langauge parser comes into exsistence .NET programmers will be able to code Dynamics AX customizations in e.g. Visual Studio. There are many blessings in X++ - Extended Data Types and it's function to name one - which does not exsist in other languages ( to my knowledge ) which newer generations of developers will probably not fanthom if the platform will be migrated completly to the .NET-platform.


The progress begs the question - what are the advantages in the migration from X++ to .NET? Hard to tell for a X++ 'evangelist' but one thing could be the that Microsoft wish to consolidate NAV and AX development to the .NET platform through the intermediate language and thus open ERP development to the many exsisting .NET developers. This will perhaps position Microsoft better in the ERP market versus e.g. SAP if in a few years all the .NET programmers will be able to develop ERP solutions?


The days where a X++ developer could get by with "only" SQL and X++ skills are soon to end. Already for ISVs to give customers the full advantage of their Dynamics AX 2009 investment, their competendencies has to include .NET programmers and Business Intelligence people (e.g. MDX, Reporting Services) on top of the traditional X++ and SQL teams. This will bring new challenges to ISVs and Dynamics AX team composition.
















Источник: http://denizone.blogspot.com/2009/09/future-of-x.html

[belugin]

Цитата:

Сообщение от Blog bot

There are many blessings in X++ - Extended Data Types and it's function to name one - which does not exsist in other languages ( to my knowledge ) which newer generations of developers will probably not fanthom if the platform will be migrated completly to the .NET-platform.

Тут, мне кажется, надо разделять X++ и MorphX - для X++ EDT - просто #typedef для примитивных типов + специализация стринга с размером. Не могу сказать сходу, можно ли это имитировать на C#.

Так как языки очень похожи и во многом C# кроет X++ как был овцу, то теоретически можно было бы конвертировать X++ на C# автоматически и забыть прор X++ вообще. (хотя бы в новых версиях)

[Logger]

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

[belugin]

Цитата:

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

Слишком уж много наработок.

В принципе наработки можно конвертировать в C# тоже

[Logger]

Цитата:

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

В принципе наработки можно конвертировать в C# тоже

Конечно можно, вопрос какой ценой и кто это оплатит. Если в один прекрасный день объявят что следующая версия аксапты выйдет на C# - число желающих обновиться упадет в разы. - Затраты очень велики. Вот если бы MS предложили какое нить решение приемлемое, то...

[mazzy]

Цитата:

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

Если в один прекрасный день объявят что следующая версия аксапты выйдет на C# - число желающих обновиться упадет в разы.

Ну... Если она объявит в ОДИН ДЕНЬ, то конечно.
А вот если скажет заранее, что будет через несколько лет (через несколько версий)
А потом подтвердит
А потом будет говорить о "возможно в следующей версии"
А потом будет говорить "в следующей версии"
ТО только очень далекий от Аксапты человек не будет об этом знать заранее.

А если знаешь заранее, то успеешь подготовится.
Хотя бы книжки изучить или с visual studio побаловаться. Не говоря уже о планировании текущих доработок...

[belugin]

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

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

Предупредив что в версии n+2, допустим, X++ уйдет.

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

[fed]

А что, интересно, будет с поддержкой слоев ? Они на нынешнюю версию ядра .net как перенесуться ? То что можно компилятор с X++ на .net написать - я верю. Более того - я такой компилятор даже видел Только вот чтобы поддержать слои, надо вероятно выпускать совсем новую версию ядра .net, причем с изменившейся логикой разрешения ссылок. И я не уверен что сотни тысяч C# программистов будут несказанно щасливы, что из за десяти тысяч программистов на X++, им пришлось переучиваться и переписывать все свои приложения...

[belugin]

Цитата:

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

А что, интересно, будет с поддержкой слоев ?

А мне кажется, что слои можно реализовать поверх .net

фактически слои - это аналог vendor branches в системах контроля версий. Соотвественно можно реализовать только в аксапте как часть IDE или даже просто как полезные стандартные vendor branches

Так даже удобней будет вместо sys и syp может быть ветка sys в которой метками пойдут все апдейты и легко будет отличить где RU1 RU2 RU3 и т.д.

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

[fed]

Неее - слои это не аналог и не замена системе контроля версий. Система контроля версий статически работает, а слои - динамически. Слои - это скорее замена (кривая кстати ) .net-овскому версионированию сборок. Вот если в светлом будущем слои заменят на какие-то гранулы или капсулы, подобные версиям сборок - вот тогда я в переход верю. Только боюсь что при достаточно монолитной архитектуре аксапты это ОЧЕНЬ непросто сделать будет.

[belugin]

Цитата:

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

версий статически работает, а слои - динамически.

Как выполнить версию метода класса которая находится на sys не снося исходник метода с syp?

Слои ИМХО работают на уровне исходников - это такой недоконтроль версий

UPD: вернее два в одном: vendor branches + версии сборок. да.

[fed]

Вообще - еще раз перечитал все эти дискуссии по поводу перехода на CLR и нашел только два довода в пользу того, почему это хорошо:
1. Не надо учить новый язык программирования для новых разработчиков. Эти наивные люди до сих пор думают что разработчики X++ используют только для создания новых форм и интеграции с внешними приложениями. Реально - X++ учиться за месяц, может - три. Все остальные годы уходят на изучение прикладной логики системы. Резюме - аргумент не катит.
2. Ускоряется работа сборщика мусора. Эээ. Возможно. А если в native code компилировать - она ведь еще бы сильнее выросла ? Чтож вы ребята на p-code остановились то ? Или дальше начальство не разрешило ? Да и кстати - в скольки процентах случаев узким местом в производительности становиться сборка мусора, а не время доступа к БД ?

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

[EVGL]

Думаю, что все дело в маркетинге. Каков будет выбор ИТ-директора, если ему предложат при прочих равных:

• систему, написанную на экзотическом языке 15-ти летней давности или
• систему, написанную на "прогрессивном" С#?

[fed]

Цитата:

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

Думаю, что все дело в маркетинге. Каков будет выбор ИТ-директора, если ему предложат при прочих равных:

• систему, написанную на экзотическом языке 15-ти летней давности или
• систему, написанную на "прогрессивном" С#?

Ты слишком высокого мнения о MBSовском глобальном маркетинге. Они по моему слишком плохо представляют как реально продажа происходит чтобы такую хитрую схему придумать. Думаю это просто красноглазики вытолкнули в народ идею насчет перехода на .net. Теперь соберут восторженные комменты чистых программистов и пойдут с ними просить увеличения финансирования. Которое можно получить только подрезав функциональщиков. В общем - явные признаки наступления, пардон, второй фазы проекта Green
А роль ИТ-Директора в выборе ERP-системы обычно очень мала, по крайней мере в России.

[AndyD]

Прошу пардону, сами мы не местные

А кто такие "красноглазики"?

[EVGL]

По манере выражения мыслей нетрудно понять, что fed недавно покинул Microsoft.
Спокойнее, спокойнее надо.

[fed]

Красноглазики
To EVGL. А я спокоен MS я действительно недавно покинул. По хорошему, спокойно. Просто и я и до прихода в MS всех этих краснооких любителей новых платформ мягко говоря не любил: Можешь почитать - Две любопытные заметки про Project Green и перспективы линии MS Dynamics или Microsoft Appoints Nadella to Lead Microsoft Business Solutions
Ну а то что у Microsoft маркетинг никакой - вполне официально признано отраслевыми аналитиками: Vendor Rating - Microsoft. Например: "Microsoft mostly delivers fragmented messages that are optimized by its BUs for specific buying centers and solutions. It's difficult for customers to identify a coherent, consistent, overall Microsoft marketing message and vision"

[belugin]

Цитата:

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

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

Потому, что это не так трудоемко. Проще сесть на идущий паровоз под названием .NET чтоб он в нейтив компилировал.

Цитата:

Или дальше начальство не разрешило ? Да и кстати - в скольки процентах случаев узким местом в производительности становиться сборка мусора, а не время доступа к БД ?

Cкажу по поводу 2009 - обход одной строчки присваивания ifом при подготовке релиза дал ощутимое ускорение разноски больших журналов.

Я сам был очень удивлен.

Цитата:

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

1. Я не думаю, что эта задача заняла большой процент от общего объема работ по следующим версиям AX

2. В будущем переход на C# и .NET, как мне кажется, позволит переложить красноглазую работу на тех красноглазиков, которые делают .NET

Хотя про политику и продажи тебе конечно виднее

[fed]

Во первых - не верю что разработать компилятор между двумя пи-кодами легче и быстрее, чем переделать систему сборки мусора в существующей системе.
Во вторых - то что они показали, это только прототип. Очень большой вопрос - сколько времени и средств займет его доведение до промышленного состояния. Так что еще очень большой вопрос - выгодна ли миграция на .net с точки зрения затрат на разработку.
В третьих - не знаю, обратил ли ты внимание, но они там мягко обошли вопрос многозвенной архитектуры и вообще рассуждали о том, что мол хорошо бы перейти на модель сервисов, при которой на каждом tier не хранится много контекстной информации. Я как-то слабо понимаю как это можно сделать не переписывая всерьез прикладной код...
Ну и наконец - в общем и в целом - на развитие продукта тратиться некая фиксированная сумма. И все что ушло на разработку ядра, не досталось прикладным разработчикам...

[belugin]

Цитата:

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

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

Если P-коды похожи, то мне кажется легче. Для С++ в принципе существует GC, который можно было бы интегрировать, но не знаю, насколько это лицензионно возможно.

Тут мне кажется, основной вопрос не в компиляторе а в преобразовании вызовов библиотек.

Цитата:

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

По этому поводу ничего не могу сказать - надо знать их трудозатраты и трудозатраты на разработку всей аксапты.

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

С третьей стороны, неизвестно, насколько гладко работает эта технология. Не хотелось бы сначала отлаживать код под X++ а потом выяснить, что для работы в скомпилированном виде под .,NET надо дополнительно отлаживать.

Но тут, насколько я понял, хотят X++ по семантике приблизить к .NET. См также вот этот пост

Вообще это можно сделать опциональной ускоряющей штукой типа ngen

Цитата:

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

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

Цитата:

Ну и наконец - в общем и в целом - на развитие продукта тратиться некая фиксированная сумма. И все что ушло на разработку ядра, не досталось прикладным разработчикам...

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

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