Прощай, X++

[belugin]

Цитата:

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

X++ является только частью инструментария для программиста AX.
X++ не является независимым языком как тот же C++

Инструменты меняют, причем иногда части инструментов на более новые.

Цитата:

Поэтому если говорить о Блабе то это не X++ а сама система в целом.
Не как X++ vs С# а как Axapta 3.0 vs AX 2009 vs AX 2012 vs AX 2015.

Вам знакомо слово "декомпозиция"?

Цитата:

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

см. ниже ("статическая типизация")

Цитата:

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

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

Цитата:

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

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

Цитата:

А это уже нереально или просто опасно. "Грязные" но безопасные заплатки лучше в большинстве случаев.

Если они грязные, то как правило, небезопасные.

Цитата:

Комментарии в коде и осмысленные наименования намного эффективнее чем иной синтаксис или математическая чистота кода.

Как жаль что для X++ нет средств для безопасного переименования.
Как жаль, что в X++ нет пространст имен и подсистеме даже нельзя дать имя.

Цитата:

P.S. К чему это я => язык это только малая часть средств разработки, а его синтаксис это вообще дело вкуса но не более того.

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

Цитата:

Что вы хотите получить от С#? Безопасность превыше правил. Причем животное это AX а автомобиль это программист

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

Давайте про безопасность:

1. Безопасность - это статическая типизация
   в X++ нету дженериков, поэтому List, Map, Array, Set, container используются без уточнения типа, в результате соответствие типов не проверяется.
   Нельзя объявить Query<InventTrans> поэтому в самых важных для разработки ERP частях код не проверяется компилятором. select имеет совершенно нелогичную семантику и тоже не проверяется статически (присоединением exists join можно сломать запрос и компилятор ничего не скажет, можно не выбрать поле и его использовать и т.д.)
2. Безопасность это проверки - для X++ нет ничего похожего на CodeContracts
3. Безопасность - это легкость понимания - нельзя выделять куски select в отдельные функции - в результате копипаст и ошибки при модификации.
   
   Нет продвинутых средств поиска участков кода
   
   
   
   
4. Безопасность, это единый стиль - в X++ нет достаточно удобных средств для рефакторинга, проверки стиля кода.

[ax_mct]

Итак имеем как минимум две позиции.

Позиция 1. Замена X++ на более современный, "мощный", "строгий" язык необходима и полезна. Например на С#.
Наступит счастье для кодера так как типизация, лаконичные объявления, пространства имен и прочее. Прекрасный и красивый код.

Позиция 2. От замены X++ на С# программисту AX легче не станет так как в списке факторов язык на пятом месте.
Наступит проектный и технический кошмар для разработчиков так как в системе будет параллельное программирование и на X++ и на С# (вы же не полагаете что всю систему перепишут на С#? ).

На мой взгляд есть только единственный вариант - это оставить X++ с компиляцией в MSIL. С# для интеграций. То есть то что уже есть сейчас.

AX это система только для старших AX программистов. В умелых руках X++ проблем не составляет. А в неумелых и С# будет гранатой в руках дикаря.
При этом я понимаю недостатки X++ и уверен с С# но это про набор компромиссов в разрезе приоритетов а не про абстрактное сравнение языков.

Или вы все таки полагаете что все перепишут на С#? Я не против на самом деле, только это называется убить AX и сделать из всех купленных ERP одну общую MS ERP. Но это скорее всего уже не будет AX даже по названию.

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

И вообще, я не против С# и прочих типов, я против С# и математиков в AX

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

[ax_mct]

Не знаю как у вас но вот реальные условия работы программиста AX

http://www.youtube.com/watch?v=GofPvMpQ5cQ

А это про знание функционала AX

https://www.youtube.com/watch?v=k-hYbWs2dPg

Suicide in C Sharp

https://www.youtube.com/watch?v=xZg7_aTLqq0

[belugin]

Цитата:

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

(вы же не полагаете что всю систему перепишут на С#? ).

Я думаю, можно автоматически сконвертировать, включая все отступы и комментарии

Как-то странно - то вам все равно,из чего сделаны кирпичи, то от смены языка становится другая erp

[Logger]

Кстати, да.
Какие есть препятствия чтобы при переходе на очередную версию сконвертить X++ код в C# ?
Я тоже считаю что принципиально это ситуацию не изменит. Но и хуже от этого не будет.

[ax_mct]

Про кирпичи это я больше про то что зернышко для курицы менее важно чем сама курица несущая яйца. Чуть неидеальное зернышко или некрасивое - неважно, главное чтобы курочка не подавилось и не отравилось. Была здоровой и довольной.То есть чисто про то что важнее - зерно (код), курица ("Движок") или яйца (выходной функционал).

Хозяин курицы качество зерна определяет совсем по другому нежели те кто эти зернышки делает.
То есть чаще всего ни курица ни яйца ни хозяин даже не заметят разницы в форме или чистоте зерна.

Подешевле и без жучков - вот и все критерии. А те же функциональные жучки они в любом зерне независимо от качества зерен. Потому как со стороны приползают. Функциональной.

[ax_mct]

Цитата:

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

Кстати, да.
Какие есть препятствия чтобы при переходе на очередную версию сконвертить X++ код в C# ?
Я тоже считаю что принципиально это ситуацию не изменит. Но и хуже от этого не будет.

Сконвертить. Варианты.

1. В MSIL без доступа к коду для простых смертных? Типа объекты с API?
Так это уже не AX. Убить кормилицу и зомби поднять - вот это что.

2. Заменить скриптами весь исходный код с X++ на С# оставив при этом техническую архитектуру как есть?
Неплохой вариант. Но как с GUI? Недешево такое провернуть хотя для маркетинга будет сильная вещь при продажах. Но что это будет? Такой же открытый код, те же слои и АОT?
Дорого хотя и возможно. Давайте подумаем.
Сразу минус - наличие X++ это фактор помогающий качеству программирования так как в случае C# программировать будут случайные люди.
Сразу плюс - маркетинг.

3. ?

[ax_mct]

Насколько я знаком с идеологией .Net, а я с ней хорошо знаком хотя мог что-то уже и подзабыть,
самым логичным вариантом является X++.Net вначале и постепенное изменение Х++ для почти полной идентичности с C# и совместимости с IL типами.
"Разные синтаксисы-один язык". MSIL, CLR и Visual Studio - это их столпы, но не C#.

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

Достаточно ведь просто сказать что X++ мало чем отличается от C# и Java, добившись того же эффекта, чем действительно переписывать систему.

А в случае смены исходников и полного перехода на C# - AX скорее всего умрет слившись в одну систему с другими купленными ERP. Хорошо это или плохо - я не знаю. Просто на мой взгляд подобный ход в любом случае не будет косметическим и безобидным для той АХ которую мы знаем. Хотя тот же HTML5 интерфейс уже нечто с косой и злобными глазками

[gl00mie]

Вспоминается презентация 5-летней давности Channel9: Peter Villadsen and Gustavo Plancarte: X++ to MSIL

Цитата:

Peter Villadsen: Да, мы уже думали об этом. В частности, мы думали о том, чтобы генерировать из p-кода исходный код на C#, и нам это вполне под силу. И это дает нам возможность полностью отказаться от X++: давайте просто нажмем на кнопку и транслируем 98% имеющейся бизнес-логики в корректно работающий код на C#; затем мы можем посадить за работу армию программистов, и через месяц они доведут этот показатель до 100%, и тогда X++ уйдет в историю.

[Logger]

Цитата:

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

Сконвертить. Варианты.
...
2. Заменить скриптами весь исходный код с X++ на С# оставив при этом техническую архитектуру как есть?
Неплохой вариант. Но как с GUI? Недешево такое провернуть хотя для маркетинга будет сильная вещь при продажах. Но что это будет? Такой же открытый код, те же слои и АОT?
Дорого хотя и возможно. Давайте подумаем.
Сразу минус - наличие X++ это фактор помогающий качеству программирования так как в случае C# программировать будут случайные люди.
Сразу плюс - маркетинг.
...

Я имел в виду вариант 2.

[Logger]

Цитата:

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

Вспоминается презентация 5-летней давности Channel9: Peter Villadsen and Gustavo Plancarte: X++ to MSIL

Правда при таком подходе придется оставить движок форм, отчетов, query* классы и.т.п. Ну и пусть. Будет как библиотека.
Сразу от этого отказаться пожалуй действительно будет затратно.

Если честно то я пока не понимаю, почему в 2012-й оставили компиляцию в p-код. Почему бы всегда не компилить в IL, а не только для нужд пакетов и.т.п.

Это было для чего-то необходимо ?

[belugin]

Цитата:

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

СконвертитьНеплохой вариант. Но как с GUI?

Отличаете ли вы язык от графической библиотеки?
Можете ли представить, что когда говорим "заменить язык", мы говорим "заменить язык", а не "язык и графическую библиотеку"?

[belugin]

Цитата:

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

Если честно то я пока не понимаю, почему в 2012-й оставили компиляцию в p-код. Почему бы всегда не компилить в IL, а не только для нужд пакетов и.т.п.

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

[ax_mct]

Цитата:

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

Отличаете ли вы язык от графической библиотеки?
Можете ли представить, что когда говорим "заменить язык", мы говорим "заменить язык", а не "язык и графическую библиотеку"?

Я что-то пропустил? В AX есть графическая библиотека? AXGUI.dll (СОМ или Assembly)? Понятно что движок на C++ и там внутри много чего есть, но меня туда не пускали и как именно они это реализовали я просто не знаю. Насколько можно легко сделать пересадку органов я тоже не знаю, но знаю что всегда есть риск осложнений и в здравом уме на это просто так не идут.

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

А почему не режут? Почему X++ еще жив?

[belugin]

Цитата:

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

А в случае смены исходников и полного перехода на C# - AX скорее всего умрет слившись в одну систему с другими купленными ERP.

Какая-то непоследовательность у вас - то ли замена языка есть поворотный момент с точки зрения ERP, то ли это незначительная подробность реализации.

[Logger]

Цитата:

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

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

Можете подробнее раскрыть вопрос ?
Сейчас в общем то так и происходит. Байт код тащится на клиент. Отсюда появляются *.auc файлы на клиенте (в 3-ке были *.aoc файлы) в которых кешируется исполнимый p-код и, кстати, бывают проблемы с его обновлением.

Почему для .Net было не сделать также ? Были проблемы с "выдиранием" нужных кусков сборки и передачей их на клиент ?

[belugin]

Цитата:

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

как именно они это реализовали я просто не знаю.

Зачем тогда утверждать что-то об этом?

Цитата:

А почему не режут? Почему X++ еще жив?

Знал бы - не сказал

[belugin]

Цитата:

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

Почему для .Net было не сделать также ? Были проблемы с "выдиранием" нужных кусков сборки и передачей их на клиент ?

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

[fed]

Кстати, еще году в 2007, во время очередной дискуссии по поводу перевода на C#, я спрашивал - а как в .net поддержать технологию слоев ? Пока никто не ответил... (Теоретически можно как-то статически собирать набор сборок из разных версий одного и того же объекта при компиляции, но как-то уж больно геморно это, да и может обычным C#овцам поломать совместимость).

[ax_mct]

Цитата:

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

Какая-то непоследовательность у вас - то ли замена языка есть поворотный момент с точки зрения ERP, то ли это незначительная подробность реализации.

В рамках метода стиль и синтаксис - незначительная подробность реализации.
В рамках системы - серьезная трансплантация.

А непоследовательность конечно же есть у меня есть, у нас быдлокодеров иначе быть и не может. http://lurkmore.to/Быдлокодер
Нам не логика нужна а наша правда!