DeniZone: The future of X++

[fed]

Цитата:

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

Еще раз:

• Разработчики ядра Аксапты не хотят допиливать IntelliSense, отладчик и прочие средства для разработчиков, потому что все это уже есть в VS.
• Они не хотят доделывать тот же редактор кода самостоятельно, поэтому для AX6 взяли движок редактора из VS.
• Они не хотят самостоятельно бодаться с проблемами производительности нынешнего менеджера памяти в ядре, в которые они уперлись, потому что для их решения нужно пойти на фундаментальные изменения - отказ от детерминированной сброки мусора. А отличный менеджер памяти с недетерминированной сборкой мусора уже есть в CLR.

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

Если эти замечательные глубокомысленные люди знают КАК все это сделать с разумным уровнем гемора для внедренцев, причем в ближайшие лет 5, а не к моменту смерти осла из притчи - хотелось бы чтобы они все это ОЗВУЧИЛИ.

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

[Lemming]

Цитата:

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

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

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

Цитата:

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

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

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

p.s. Как красноглазик в данном вопросе , я за систему на едином и современном языке: С#, но только в случае если это действительно грозит снижением скорости разработки исключительно на период погружения в тонкости новой платформы и при сохранении существующего функционала.

[_scorp_]

Цитата:

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

C# не настолько сложный язык что бы читая код

Он не сложный, но возможностей "загнуть" там гораздо больше чем на X++. Вот например что здесь выведется на экран

class X<T>
    {
        public static void PrintTypes()
        {
            Console.WriteLine(typeof(T).FullName);
            Console.WriteLine(typeof(X<X<T>>).FullName);
        }
    }
    class App
    {
        static void Main()
        {
            X<int>.PrintTypes();
        }
    }

Или здесь

class Program
    {
        delegate int DelegateType(int valTypeParam, string refTypeParam,
          ref int refParam, out int outParam);

        static DelegateType GetMethod()
        {
            return delegate(int valTypeParam, string refTypeParam,
              ref int refParam, out int outParam)
            {
                System.Console.WriteLine("Hello valParam:{0} refTypeParam:{1}",
                  valTypeParam, refTypeParam);

                refParam++;
                outParam = 9;
                return valTypeParam;
            }; 
        }

        static void Main()
        {
            DelegateType delegateInstance = GetMethod();
            int refVar = 5;
            int outVar;
            int i = delegateInstance(1, "one", ref refVar, out outVar);
            int j = delegateInstance(2, "two", ref refVar, out outVar);
            System.Console.WriteLine("i:{0} j:{1} refVar:{2} outVar:{3}",
              i, j, refVar, outVar);
        }
    }

[Андре]

Цитата:

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]

Цитата:

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

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

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

Цитата:

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

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

Цитата:

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

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

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

Цитата:

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

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

[belugin]

Цитата:

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

Он не сложный, но возможностей "загнуть" там гораздо больше чем на X++. Вот например что здесь выведется на экран

            Console.WriteLine(typeof(X<X<T>>).FullName);

я как человек, который знаком с C# слабо, думал, что выведется X<X<int>>, вывелось
X`1[[X`1[[System.Int32, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]
], test, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null]]

Я так понимаю, что тут
1. полные именя типов
2. int32 подвергся боксингу
3. `1 означает "от одного аргумента"

Я прав? То есть проблема в реализации преобразования типа тип к строке?

Цитата:

Или здесь

class Program
    {
        delegate int DelegateType(int valTypeParam, string refTypeParam,
          ref int refParam, out int outParam);

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

У меня вывело

Hello valParam:1 refTypeParamne
Hello valParam:2 refTypeParam:two
i:1 j:2 refVar:7 outVar:9

вроде так и должно быть.

[belugin]

Цитата:

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

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

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

[Андре]

Цитата:

там не 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?

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

[_scorp_]

Цитата:

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

То есть проблема в реализации преобразования типа тип к строке?

Здесь на самом деле нет ни какой проблемы. Для generic-ов FullName выводиться по другому и в MSDN об этом говорится. В этих примерах нет никаких ребусов, я просто хотел сказать, что в X++ нет таких синтаксических конструкций и читать его следовательно легче (по крайней мере для меня).

Цитата:

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

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

Даже не знаю как это написать на X++. Тут нет ни generic-ов, ни делегатов, ни out параметров, ни значимых типов, которые можно передать по ссылке, да много чего нет... Но я с Вами согласен, что и на X++ можно намудрить, просто здесь для "мудрецов" больше возможностей

[belugin]

Цитата:

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

Здесь на самом деле нет ни какой проблемы. Для generic-ов FullName выводиться по другому и в MSDN об этом говорится. В этих примерах нет никаких ребусов, я просто хотел сказать, что в X++ нет таких синтаксических конструкций и читать его следовательно легче (по крайней мере для меня).

Мне легче читать

List<String> myFunction()

чем

List myFunction()
// (а теперь надо посмотреть где этот List создается и что в него можно запихать)

К тому же писать легче, если компилятор контроллирует.

Цитата:

Даже не знаю как это написать на X++. Тут нет ни generic-ов,

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

Цитата:

ни делегатов,

Observer pattern, в трешке был SysDelegate, си также http://blogs.msdn.com/x/archive/2007...-eventing.aspx

Цитата:

ни out параметров,

SysAnyType

Цитата:

ни значимых типов, которые можно передать по ссылке,

То же самое

Цитата:

да много чего нет... Но я с Вами согласен, что и на X++ можно намудрить, просто здесь для "мудрецов" больше возможностей

С моей точки зрения проще 1 раз выучить конструкции, чем потом 1000 раз сравнивать куски кода в которыхз все одинаково кроме одной строчки, чтобы понять чем они отличаются

[shogel]

В MSDN появился раздел "Отличия X++ от C# для чайников".

http://msdn.microsoft.com/en-us/library/cc967357.aspx

[gl00mie]

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

[MikeR]

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

[ibc]

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

[MikeR]

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

[Aleck]

Цитата:

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

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

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

[belugin]

Цитата:

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

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

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