DeniZone: The future of X++

[belugin]

В этой ветке слились три фичи:
1. Генерация MSIL из X++ - о которой на channel 9
2. VS как IDE для Ax, о которой говорил Денис
3. Написание бизнес логики на .NET языках - про которую спрашивали у Татаринова.

По поводу последней могу сказать, что знакомые часто спрашивают, как сделать ту или иную техническую штуку на аксапте - скачать файл из интернета или там последить за папкой, что туда валится или еще что-нибудь. Сейчас, наиболее удобно послать их в MSDN, чтобы они посмотрели на код на C# и переписали его на аксапту. Теперь представьте, что ненадо ничего переписывать - если вы пишете фрагмент бизнес логики на С#, потом просто вставляете пример из MSDN и подправляете.

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

Или например, вас не устраивает быстродействие X++ и надо задействовать всю мощь ngen (а может, какие-то куски написать на C++\IL)

Или у вас есть уже готовая вычислительная библиотека на F# и вы хотите ее тесно интегрировать в приложение.

Вобщем, хорошая интеграция с возможностями .NET может быть полезна.

[fed]

Цитата:

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

В этой ветке слились три фичи:

По поводу последней могу сказать, что знакомые часто спрашивают, как сделать ту или иную техническую штуку на аксапте - скачать файл из интернета или там последить за папкой, что туда валится или еще что-нибудь. Сейчас, наиболее удобно послать их в MSDN, чтобы они посмотрели на код на C# и переписали его на аксапту. Теперь представьте, что ненадо ничего переписывать - если вы пишете фрагмент бизнес логики на С#, потом просто вставляете пример из MSDN и подправляете.

Дык для этого вроде бы вызов внешних сборок есть. Его конечно можно бы и получше интегировать, с этим соглашусь, но не очень понятно, зачем для этого внутри аксапты C# держать ?

Цитата:

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

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

Некий глобальный модуль на Аксапте, наверняка будет содержать кастомизации базовых классов, которые, если верить Татаринову, переписывать не будут. Так что придется всю логику на X++ писать. А если что-то совсем сбоку - дык может проще его отдельно на чем угодно написать и потом через AIF заинтегрировать ?

Цитата:

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

Или например, вас не устраивает быстродействие X++ и надо задействовать всю мощь ngen (а может, какие-то куски написать на C++\IL)

А чего такого в Аксапте можно написать чтобы ему вся мощь ngen понадобилась ? Дифуры решать ?

Цитата:

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

Или у вас есть уже готовая вычислительная библиотека на F# и вы хотите ее тесно интегрировать в приложение.

Вобщем, хорошая интеграция с возможностями .NET может быть полезна.

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

[belugin]

[QUOTE=fed;215508]Дык для этого вроде бы вызов внешних сборок есть. Его конечно можно бы и получше интегировать, с этим соглашусь, но не очень понятно, зачем для этого внутри аксапты C# держать ?
[QUOTE]

Внешние сборки они конечно хороши, но вот только того, как их хорошо интегрируешь, то получатся внутренние сборки.

Цитата:

Некий глобальный модуль на Аксапте, наверняка будет содержать кастомизации базовых классов, которые, если верить Татаринову, переписывать не будут. Так что придется всю логику на X++ писать. А если что-то совсем сбоку - дык может проще его отдельно на чем угодно написать и потом через AIF заинтегрировать ?

По моему, прозрачная работа с .NET гораздо проще чем интеграция через посредника AIF.

Цитата:

А чего такого в Аксапте можно написать чтобы ему вся мощь ngen понадобилась ? Дифуры решать ?

Пробовал ли ты измерить в процентах сколько аксапта проводит времени в X++ а сколько в SQL при разноске огромного журнала. Например, через TraceParser

Цитата:

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

Лично мне не хватало .NET больше при интеграции и мелких технических штуках, чем при реальных тяжелых вычислениях.

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

Кстати, а ты не мерял, что является узким местом, например, при закрытии скалада в 2009 - насколько грузится АОС, насколько SQL сервер?

[Андре]

Цитата:

belugin: Или например, вас не устраивает быстродействие X++ и надо задействовать всю мощь ngen (а может, какие-то куски написать на C++\IL)

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

Цитата:

gl00mie: А отличный менеджер памяти с недетерминированной сборкой мусора уже есть в CLR.

Ну, не такой уж он и отличный. Я его, правда, еще во времена первого фреймворка тестировал, может что-то изменилось, но тогда он очень сильно уступал java-вскому.

Цитата:

belugin: Но я знаю, например, что алгоритмы поиска оптимального расписания используются в ERP, я также читал, что они часто итеративны и вычислительно сложны.

Насколько я заметил, обычно для этого используют экспорт первичных данных из Axapta, обработка их в специализированном ПО и затягивание готового результата обратно. Экспорт/импорт не обязательно должен быть примитивным, на уровне текстовых файлов (хотя такой вариант встречается чаще всего), но и, например, на уровне Web-сервисов.

Цитата:

Lemming: Как я понял, с поверхностного ознакомления, C# не настолько сложный язык что бы читая код, каждый раз приходилось в нем разбираться

Я давно не слежу за развитием C#, но кажется в него включили lambda-функции, механизмы вывода типов (aka type inference), list comprehention (даже не возьмусь перевести) и еще какие-то элементы функционального программирования. А код написанный с использованием этих фич гарантированно выносит мозг у разработчиков, ранее не сталкивающихся с функциональными языками программирования.

Цитата:

Lemming: Завидую...читаешь код, например: ЗиК, Налоговых регистров, разноску по ГК, расчет спецификаций, закрытие склада, Обороток в любых модулях(RLedgerSheet*), даже в отладчике, все не так очевидно, что уж там просто исходники.

Боюсь даже представить реализацию этих алгоритмов на C#. Большие возможности языка при все тех же способностях разработчиков приводят только к более нечитаемому коду. Наверное именно по этому мне очень нравятся Scheme и Erlang с их ограниченным количеством конструкций.

[Lemming]

2 _scorp_

Можно было бы конечно попробовать открыть "студию" + google + пару книжек, а после попробовать ответить Вам что будет в результате работы приведенного кода(что выводится я смотрю на практике, ), но честно говоря, лень...В первом случае вы "намудрили" с обобщениями, во втором пытаетесь "напугать" делегатами, возвращаемыми параметрами и вообще страшным кодом. В обоих случаях давайте посмотрим на приведенные листинги с практической точки зрения: перепишите написанное на Х++, а там станет ясно, как часто нам придется сталкиваться с подобным.

upd: "Любопытство взяло свое", очень жду аналоги методов на Х++, но спасибо за ребус с refParam

2 Андре Думаю что проблема не в возможностях языка при реализации конкретных задач, проблема в выборе способа и механизмов реализации + документированность...Иными словами, можно было бы еще сильнее намудрить в приведенных мной примерах на том же х++.

p.s. Дискуссия рискует свернуть в сторону: "на С# не стоит писать бизнес-логику учетных систем", ибо язык создали слишком мудрый

[Андре]

Цитата:

p.s. Дискуссия рискует свернуть в сторону: "на С# не стоит писать бизнес-логику учетных систем", ибо язык создали слишком мудрый

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

Без обид, я сам разработчик Axapta, но специфика бизнеса способствует тому, что программировать ERP системы идут далеко не самые способные программисты (почему это происходит - отдельный разговор), а значит язык программирования должен быть максимально простым с минимум подвохов и синтаксических конструкций. Собственно, как я понимаю, по этому принципу и создавались X++, ABAP и язык программирования 1C.

[belugin]

Цитата:

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

upd: "Любопытство взяло свое", очень жду аналоги методов на Х++, но спасибо за ребус с refParam

А чо за ребус то - он два раза инкрементится и из 5 получается 7 - чего там не правильно то? Если вообще передача по ссылке, то это было и дельфи (или даже в паскале, который все учили в институте)...

[belugin]

Цитата:

Сообщение от Андре

Ну, не такой уж он и отличный. Я его, правда, еще во времена первого фреймворка тестировал, может что-то изменилось, но тогда он очень сильно уступал java-вскому.

Во-первых наверняка изменилось. Во-вторых, важнее насколько он быстрее X++

Цитата:

Я давно не слежу за развитием C#, но кажется в него включили lambda-функции, механизмы вывода типов (aka type inference), list comprehention (даже не возьмусь перевести) и еще какие-то элементы функционального программирования.

там не List comprehension, a есть linq - можно его условно считать monad comprehension. То, что у нас есть в аксапте втроенный relational table comprehension ведь не сильно затрудняет разработку? Я бы сказал даже, что облегчает.

Цитата:

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

... и с SQL запросами.

- как выносит мозг вывод типов?
- как выносит мозг LINQ?
- как выносят мозг лямбды? ('то те же функции только без имени)

Цитата:

Боюсь даже представить реализацию этих алгоритмов на C#. Большие возможности языка при все тех же способностях разработчиков приводят только к более нечитаемому коду. Наверное именно по этому мне очень нравятся Scheme и Erlang с их ограниченным количеством конструкций.

особенно просты
- макросы в схеме
- лямбды в схеме
- отсутствие вывода типов в схеме да и вообще статического контроля типов

[Андре]

Цитата:

там не List comprehension, a есть linq - можно его условно считать monad comprehension.

А вот это linq ?

IEnumerable<int> numbers = Enumerable.Range(0, 10);
var evens = from num in numbers where num % 2 == 0 select num;

То есть, что такая возможность есть я знаю, а вот к чему она там относится - нет.

Цитата:

То, что у нас есть в аксапте втроенный relational table comprehension ведь не сильно затрудняет разработку? Я бы сказал даже, что облегчает.

Э... а что это ?

Цитата:

как выносит мозг LINQ?

Так и выносит, стоит чуть отойти от стандартных демо-примеров. Тут даже достаточно примеров от _scorp_. И именно поэтому MS развивает F# как экспериментальный язык программирования, а Гвидо грозится выкинуть lambda-функции из Python.

Цитата:

особенно просты
- макросы в схеме

А ими, в общем то, особо и не рекомендуют пользоваться до тех пор пока можно обойтись без них. Зато разобравшись с ними один раз, можно создавать удобный для себя DSL.

Цитата:

- лямбды в схеме

А чем они неудобнее люмбд в haskell?

Сравни - Haskell:

map (\(number)-> 1 + number) [1, 2, 3, 4]

и Scheme:

(map (lambda (number)
       (+ 1 number))
     '(1 2 3 4))

На мой взгляд одно и то же. По моему сложны лямбды, как логическая конструкция (а также ее производные - например, замыкания), а уж поняв эту конструкцию можно применять ее в любом языке программирования. И в Scheme они ничуть не сложнее чем в Haskell.

[belugin]

Цитата:

Сообщение от Андре

А вот это linq ?

IEnumerable<int> numbers = Enumerable.Range(0, 10);
var evens = from num in numbers where num % 2 == 0 select num;

То есть, что такая возможность есть я знаю, а вот к чему она там относится - нет.

Ну оно не только к спискам относится, а вообще ко всему. Включая LINQ2SQL

Цитата:

Э... а что это ?

Я имел ввиду встроенный SQL

Цитата:

Так и выносит, стоит чуть отойти от стандартных демо-примеров. Тут даже достаточно примеров от _scorp_. И именно поэтому MS развивает F# как экспериментальный язык программирования, а Гвидо грозится выкинуть lambda-функции из Python.

что конкретно непонятно в первом и втором примере?

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

Он грозился, но не выкинул, как я помню. И list comprehension оставил.

Экспериментальный язык программирования в составе VS2010

Цитата:

А ими, в общем то, особо и не рекомендуют пользоваться до тех пор пока можно обойтись без них. Зато разобравшись с ними один раз, можно создавать удобный для себя DSL.

Ну возможность отстрелить себе ногу больше...

Цитата:

А чем они неудобнее люмбд в haskell?

Мы ж вроде признали что лямбды в нашем контексте - зло?

[gl00mie]

Появился он относительно давно, см. Dynamics AX 2009 - X++, C# Comparison - тема датирована февралем 2009-го. Правда, с тех пор, надо заметить, раздел был существенно расширен.

[MikeR]

Интересное мнение : Потом в тот же день он был в Microsoft. Когда он вошёл в комнату, все болтали, а потом началась встреча, и никаких дизайнеров не пришло вовсе. Вокруг сидели технари и каждый пытался подбросить свою идею при обсуждении дизайна. Это рецепт для катастрофы."

[ibc]

Если бы Apple стала делать ERP, как бы эта система она выглядела?

[MikeR]

Мое имхо:
1 Не стоит трогать X++. Да редактор напоминает богомерзкий блокнот, да нет solution explorer, да все уныло, да это было сделано, когда подавляющее число разработчиков ходило в детский сад и так далее. Но он работает! Его с лихвой хватит на те бизнес задачи, которые уже реализованы.
2 Бюджет, на мой взгляд, повторюсь еще раз, я бы пустил на расширение функционала, на красивый дизайн и удобство пользователя. Не видят пользователи окно редактора X++ и все тут.
3 Опустил бы цены на лицензии, как это было сделано с навиком.

[belugin]

Цитата:

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

Мое имхо:
1 Не стоит трогать X++. Да редактор напоминает богомерзкий блокнот, да нет solution explorer, да все уныло, да это было сделано, когда подавляющее число разработчиков ходило в детский сад и так далее. Но он работает! Его с лихвой хватит на те бизнес задачи, которые уже реализованы.

Редактор уже сделали - см видео с channel9. по-моему он довольно хорош.

Цитата:

2 я бы пустил на расширение функционала, на красивый дизайн и удобство пользователя. Не видят пользователи окно редактора X++ и все тут.

Редактор вряд ли сожрал существенную долю ресурсов. Остального - см список сессий тут

[Aleck]

Цитата:

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

Если бы Apple стала делать ERP, как бы эта система она выглядела?

Под IPad и IPhone уже есть заточенные под специфичные задачи (там где действительно уместен планшет) клиенты для SAP, выглядит очень красиво и удобно

[belugin]

Цитата:

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

Если бы Apple стала делать ERP, как бы эта система она выглядела?

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

[gl00mie]

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

Цитата:

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

Источник: http://blogs.msdn.com/b/mfp/archive/...-language.aspx
In Dynamics AX 2012 we are compiling X++ code to the CLR. At compile time we generate an XML representation of the pcode, which we can convert into IL. At run-time we will be executing the IL for batch jobs, service calls and RunAs constructs. (RunAs is a new method allowing you to request the X++ logic to be executed as IL.). Peter demonstrated how the performance characteristics are vastly different particular in situations with extremely many objects or extremely many methods calls.

[fed]

Цитата:

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

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

А еще реальностью стал (по моим источникам) геморрой с перезагрузкой откомпилированных сборок. То есть - либо рестарт боевого AOS, либо работа через Application Domain. Причем скорость второго режима, мягко говоря, бледно смотриться даже на фоне скорости старого интерпретатора.
Ооо - почитал твиттер Брендона:
1. Отладка на сервере возможна только через VS Debugger
2. Чтобы отлаживаться, придется включать App Domain с тормозами.
3. Если у тебя на сервере работает несколько разработчиков - опять таки только App Domain с hot-swapping.

Ооо - как новую систему полюбят все внедренцы ! Ведь теперь нельзя будет отлаживаться на боевом сервере. Придется мучительно допрашивать пользователей о том, что же они такого отмочили и потом пытаться воспроизвести на тестовом приложении. Разумеется с подъемом бэкапа БД.
Чуствую - после выхода 6ки, придется на полгодика разрешить мат на форуме...

[sukhanchik]

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