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" это все в ядре не появится.

[fed]

Я пожалуй что расскажу об одной любопытной вещи. До того как я пришел на работу в MS (в конце 2006 года, буквально за две недели до моего первого рабочего дня в MS), меня знакомый затащил на встречу питерской группы .net users group. И там выступал и показывал свой продукт один мой будущий (на тот момент) коллега, который из Питера перебрался работать в датском центре разработки.
А показывал он очень простую вещь - редактор форм Аксапты внутри VS, редактор кода Аксапты внутри VS и, кажется, даже компилятор X++ внутри VS. На провокационные вопросы - типа "Сделаете ли вы X++ managed языком", этот товарищ не отвечал, с присказками "Не могу, типа NDA и все дела". Аксаптеров на этом мероприятии кроме меня не было, а разработчикам .net увиденное было тяжело осмыслить, так что все это прошло мало заметно.

Так что то что в ролике с Channel 9 было показано, я видел, без малого три года назад. Потом я про этот проект за два с половиной года работы в MS ничего не слышал, и в целом полагал что его похоронили.
И весь мой скептицизм по поводу перехода на .net вызван как раз тем, что если проект три года развивался, то непонятно почему за три года прогресс такой слабый (судя по тому что номер версии Аксапты, в которой это выйдет они не называют). Если проект три года был заморожен как неперспективный, то не очень понятно, почему они решили что у них в этот раз получиться...
Ну и кстати я всех этих восторгов по поводу среды VS не разделяю. Visual Studio - замечательная среда разработки БОЛЬШИХ проектов. Типа когда мы сначала проектируем иерархию классов, создаем файлы заголовков, разрабатываем сервисы, рисуем зависимости для компиляции, делаем публикацию в веб-сервисы и тп. А в Аксапте - 90% доработок - это пара строк в нужном методе. И как-то меня пугает мысль что мне для этого придется этот метод checkoutить из репозитария, править, checkinить, компилировать все приложение, деплоить серверные веб-сервисы, деплоить клиентское приложение и только после этого получать результат.

Я, если позволите, еще раз приведу услышанные аргументы перехода на .net:
1. Легкость обучения/доступность специалистов. Затраты на обучение действительно могут СЛЕГКА снизиться. Типа готовность специалиста будет наступать не через 18-25 месяцев, а эдак месяца на 2 раньше. Но это не принципиально.
2. Более совершенная среда разработки VS. Она более совершенная - но только для случая РАЗРАБОТКИ с ноля, а не быстрой доработки. Еще не известно в чем именно аксаптерские решения проще разрабатывать - в убогой но компактной среде разработки Аксапты или в богатой, но тяжелой среде разработки VS.
3. Оптимизация затрат на разработку среды исполнения X++. Возможно что это действительно так.А возможно - и нет. Как раз то что я спустя почти три года вижу примерно тот же прототип что и раньше, наводят меня на мысль что доработать прототип до промышленной системы довольно нелегко...

[belugin]

Цитата:

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

А показывал он очень простую вещь - редактор форм Аксапты внутри VS, редактор кода Аксапты внутри VS и, кажется, даже компилятор X++ внутри VS.
...
Так что то что в ролике с Channel 9 было показано, я видел, без малого три года назад.

И что же из этого было в ролике и нет ли чего-то в ролике, что не было на презентации

[polygris]

Полностью согласен с fed. Пусть Visual Studio остается тяжелой средой разработки для крупных разработок. А в аксе реально нужно править всего несколько строчек кода.
Лучше бы МС допилил бы Intellisense в редакторе, да добавил примочки для девелопера - например таких какие есть в виде плагинов к Tabax.

Не понимаю какую выгоду получит разработчик или покупатель от того что код будет компилится в .NET?

[fed]

Ну собственно я поэтому и написал, что поддержка С# - это фича предназначенная для поддержки продаж. Чтобы можно было клиентским айтишникам гордо сказать: Смотрите - ее можно программировать на C# ! Вашим разработчикам не придется переучиваться !
Ну а потом выясниться что все равно вся полезная логика написана на X++ и никто ее на C# переписывать не собирается. Соответственно - все равно придется X++ изучать.

Просто до того как я не позанимался слегка продажами, я не понимал что часть фич в программном продукте пишется не для внедрения, а для демонстрации во время продаж. Например, явно к этой категории относиться модуль Balanced Scorecard. Ну а глядишь в версии 7 еще и какое-нить Visual Studio Integration для этого напишут...

[mifi]

А для чего интересно еще пишутся фичи в программном продукте, если не для поддержки продаж? Мне известно только две модели зарабатывания денег на ПО - деньги от продаж и/или деньги от поддержки.
Просьба озвучить третью
И что плохого в том, что программисты C# получат классную интеграцию с АОT?

[_scorp_]

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

[fed]

Цитата:

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

А для чего интересно еще пишутся фичи в программном продукте, если не для поддержки продаж? Мне известно только две модели зарабатывания денег на ПО - деньги от продаж и/или деньги от поддержки.
Просьба озвучить третью
И что плохого в том, что программисты C# получат классную интеграцию с АОT?

Ну ты ведь знаешь как микрософт удоволетворенность продуктом замеряет ? И если удовлетворенность низкая, то какой-то службе может попасть по первое число Причем делает это Микрософт не из спортивного интереса и любви к пользователям, а потому что удволетворенность сейчас - это фактически долгосрочный прогноз выручки. Чем ниже удовлетворенность, тем больше шансов что клиент соскочит и годика через три будет выручку конкурентам приносить. Любые Sales Oriented Features - это создание ложных ожиданий от продукта. А ложные ожидания - низкая удовлетворенность. Низкая удовлетворенность - шансы того что клиент соскочит. Соответственно - любая sales feature - это попытка сорвать с клиента немножко денег СЕЙЧАС, в ущерб ДОЛГОСРОЧНЫМ перспективам получать с клиента деньги регулярно.

По поводу того, что программисты C# получат классную интеграцию с AOT. А рыночный спрос на это есть ? Я вот почти 9 лет аксапту внедряю, и как то мне это пока не понадобилось. А бабла микрософт на эту интеграцию не мало потратит. И есть шансы что какие-нибудь фичи, которые мне как внедренцу нужны - не будут реализованы из за этого. Это-то и злит в общем.
Если у Микрософта лишние деньги есть - так лучше бы попробовали поверх MS OLAP написать клиента нормального, бюджетирование и синтегрировали бы все это с Аксаптой например... От этого на проектах куда больше было бы пользы чем от этой интеграции с .net

[MikeR]

Спасибо, fed. Никто ранее не говорил, что придется деплоить целиком приложение. А как быть с AOS (передергивать) ? Или я чего не понял?

[mifi]

Цитата:

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

Ну ты ведь знаешь как микрософт удоволетворенность продуктом замеряет ? И если удовлетворенность низкая, то какой-то службе может попасть по первое число Причем делает это Микрософт не из спортивного интереса и любви к пользователям, а потому что удволетворенность сейчас - это фактически долгосрочный прогноз выручки. Чем ниже удовлетворенность, тем больше шансов что клиент соскочит и годика через три будет выручку конкурентам приносить. Любые Sales Oriented Features - это создание ложных ожиданий от продукта. А ложные ожидания - низкая удовлетворенность. Низкая удовлетворенность - шансы того что клиент соскочит. Соответственно - любая sales feature - это попытка сорвать с клиента немножко денег СЕЙЧАС, в ущерб ДОЛГОСРОЧНЫМ перспективам получать с клиента деньги регулярно.

По поводу того, что программисты C# получат классную интеграцию с AOT. А рыночный спрос на это есть ? Я вот почти 9 лет аксапту внедряю, и как то мне это пока не понадобилось. А бабла микрософт на эту интеграцию не мало потратит. И есть шансы что какие-нибудь фичи, которые мне как внедренцу нужны - не будут реализованы из за этого. Это-то и злит в общем.
Если у Микрософта лишние деньги есть - так лучше бы попробовали поверх MS OLAP написать клиента нормального, бюджетирование и синтегрировали бы все это с Аксаптой например... От этого на проектах куда больше было бы пользы чем от этой интеграции с .net

Вероятность что клиент соскочит - да, есть. Но при внедрении любой ERP системы это в 99% случае происходит по трем причинам - политика, политика, политика. А если система не содержит пару "sales oriented features" клиент соскочит намного раньше - во время тендера. И будет внедрять другую систему, в которой реальных проблем может быть еще больше.
По поводу того, кто сколько лет внедряет и кому оно понадобилось - тут нужно различать работу со стороны клиента и со стороны партнера. Клиентские разработчики в большинстве случаев клепают отчеты и делают всякую интеграцию. Зачем для решения этих задач знание X++, гораздо проще и дешевле нанять C# разработчика который все это ссделает в Visual Studio

[fed]

Цитата:

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

Вероятность что клиент соскочит - да, есть. Но при внедрении любой ERP системы это в 99% случае происходит по трем причинам - политика, политика, политика. А если система не содержит пару "sales oriented features" клиент соскочит намного раньше - во время тендера. И будет внедрять другую систему, в которой реальных проблем может быть еще больше.
По поводу того, кто сколько лет внедряет и кому оно понадобилось - тут нужно различать работу со стороны клиента и со стороны партнера. Клиентские разработчики в большинстве случаев клепают отчеты и делают всякую интеграцию. Зачем для решения этих задач знание X++, гораздо проще и дешевле нанять C# разработчика который все это ссделает в Visual Studio

Ну если уж уходить в политику - то мнение айтишников, обычно, является далеко не решающим при продаже. Так что в качестве sales oriented feature проще было бы, ну скажем сделать интеграцию с Bing Maps Она, правда, тоже реально бесполезна, но ее хотя бы директору по логистике можно показать. Так что если считать C# сейловым функционалом - то это не самое выгодное вложение денег. Затраты большие - а реальная польза - красноглазикам показать, которых все равно никто не спрашивает.

Ну а насчет клиентских программистов - дык уже счас можно отчеты на SSRS клепать и туда вставочки на C# писать. Правда чтобы человек без знания Аксапты смог сложный отчет написать (а простые ведь и без программинга можно на коленке нарисовать), то придется ему детальную спецификацию писать. Которую проще самому запрограммировать чем для другого написать

[mifi]

Цитата:

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

Ну если уж уходить в политику - то мнение айтишников, обычно, является далеко не решающим при продаже. Так что в качестве sales oriented feature проще было бы, ну скажем сделать интеграцию с Bing Maps Она, правда, тоже реально бесполезна, но ее хотя бы директору по логистике можно показать. Так что если считать C# сейловым функционалом - то это не самое выгодное вложение денег. Затраты большие - а реальная польза - красноглазикам показать, которых все равно никто не спрашивает.

Ну а насчет клиентских программистов - дык уже счас можно отчеты на SSRS клепать и туда вставочки на C# писать. Правда чтобы человек без знания Аксапты смог сложный отчет написать (а простые ведь и без программинга можно на коленке нарисовать), то придется ему детальную спецификацию писать. Которую проще самому запрограммировать чем для другого написать

"Обычно является далеко не решающим". Т.е. иногда оно-таки являются решающим? IT-директор - один из decision makerов,а уж какой у него удельный вес - определятся предприятием. На мой взгляд, кстати, на Западе этот вес намного выше.
И запросы на подобную фичу, насколько я себе представляю от зарубежных клиентов идут постоянно.
А что уж там является решающим фактором для России, того не запрограммируешь.
И кто сказал, что, к примеру, интеграции с Bing Maps в следующей версии не будет
Эти две фичи слишком разного размера, поэтому одна другой никак не мешает

[fed]

Цитата:

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

"Обычно является далеко не решающим". Т.е. иногда оно-таки являются решающим? IT-директор - один из decision makerов,а уж какой у него удельный вес - определятся предприятием. На мой взгляд, кстати, на Западе этот вес намного выше.
И запросы на подобную фичу, насколько я себе представляю от зарубежных клиентов идут постоянно.

Ну то что от клиентов идут запросы на бесполезные фичи, это наверное об уровне маркетинга продукта говорит. Заповедь маркетинга: "Создать у клиента потребность, а потом ее удволетворить". Дык может все-таки пытаться у клиента полезные для него потребности создавать (типа потребности в бюджетировании), а не пытаться создать потребность в перламутровых пуговицах ? Чтобы потом у клиента не возникало ощущение что ему перламутровые пуговицы на дырявом халате продали...

[belugin]

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

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

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

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

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

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

[belugin]

Цитата:

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

Пусть Visual Studio остается тяжелой средой разработки для крупных разработок.

По какой метрике VS2008 тяжелее Ax2009?

[belugin]

Цитата:

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

Любые Sales Oriented Features - это создание ложных ожиданий от продукта.

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

Почему так получилось, что про C# Татаринову был задан вопрос, а про бюджет - нет?

Кстати, ты знаешь про PowerPivot?

[fed]

Цитата:

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

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

[fed]

Цитата:

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

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

Почему так получилось, что про C# Татаринову был задан вопрос, а про бюджет - нет?

Кстати, ты знаешь про PowerPivot?

Про PowerPivot - не знаю, но посмотрю.
А про C# вопрос был задан, как я полагаю, потому что все (также как и я кстати) боятся гемора с переходом на C# и повторения истории проекта Green.

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

[gl00mie]

Цитата:

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

Пусть Visual Studio остается тяжелой средой разработки для крупных разработок. А в аксе реально нужно править всего несколько строчек кода.

Если вам в Аксапте нужно по работе править всего несколько строчек кода, то могу лишь порадоваться за вас - наверняка в опросе Как сильно модифицировано ваше приложение Аксапты? вы выбрали один из первых вариантов ответа.

Цитата:

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

Лучше бы МС допилил бы Intellisense в редакторе, да добавил примочки для девелопера - например таких какие есть в виде плагинов к Tabax.

Такое ощущение, что доводы членов команды X++, приведенные в обсуждаемом видео на channel9, вами не были восприняты Для верности я продублировал часть доводов в этой теме. Еще раз:

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

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

[belugin]

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

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

Цитата:

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

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

Цитата:

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

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

Цитата:

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

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

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

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