DeniZone: The future of X++

[polygris]

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

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

[belugin]

Цитата:

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

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

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

[gl00mie]

Цитата:

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

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

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

Цитата:

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

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

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

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

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

[fed]

Цитата:

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

Еще раз:

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

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

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

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