DeniZone: The future of X++

[belugin]

Цитата:

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

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

Если P-коды похожи, то мне кажется легче. Для С++ в принципе существует GC, который можно было бы интегрировать, но не знаю, насколько это лицензионно возможно.

Тут мне кажется, основной вопрос не в компиляторе а в преобразовании вызовов библиотек.

Цитата:

Во вторых - то что они показали, это только прототип. Очень большой вопрос - сколько времени и средств займет его доведение до промышленного состояния. Так что еще очень большой вопрос - выгодна ли миграция на .net с точки зрения затрат на разработку.

По этому поводу ничего не могу сказать - надо знать их трудозатраты и трудозатраты на разработку всей аксапты.

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

С третьей стороны, неизвестно, насколько гладко работает эта технология. Не хотелось бы сначала отлаживать код под X++ а потом выяснить, что для работы в скомпилированном виде под .,NET надо дополнительно отлаживать.

Но тут, насколько я понял, хотят X++ по семантике приблизить к .NET. См также вот этот пост

Вообще это можно сделать опциональной ускоряющей штукой типа ngen

Цитата:

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

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

Цитата:

Ну и наконец - в общем и в целом - на развитие продукта тратиться некая фиксированная сумма. И все что ушло на разработку ядра, не досталось прикладным разработчикам...

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

В общем, я считаю, что стратегически переход на .NET вещь правильная так как позволит меньше тратить на инструменты. Главное чтобы сам по себе переход был спланирован и реализован так чтобы не было сильного ущерба на каждом из этапов.