Цитата:
Сообщение от
fed
Во первых - не верю что разработать компилятор между двумя пи-кодами легче и быстрее, чем переделать систему сборки мусора в существующей системе.
Если P-коды похожи, то мне кажется легче. Для С++ в принципе существует GC, который можно было бы интегрировать, но не знаю, насколько это лицензионно возможно.
Тут мне кажется, основной вопрос не в компиляторе а в преобразовании вызовов библиотек.
Цитата:
Во вторых - то что они показали, это только прототип. Очень большой вопрос - сколько времени и средств займет его доведение до промышленного состояния. Так что еще очень большой вопрос - выгодна ли миграция на .net с точки зрения затрат на разработку.
По этому поводу ничего не могу сказать - надо знать их трудозатраты и трудозатраты на разработку всей аксапты.
С другой стороны, если бы это было сделано, то нам бы это сэкономило некоторое время потраченное на исследование и исправление проблемы с производительностью разноски больших журналов.
С третьей стороны, неизвестно, насколько гладко работает эта технология. Не хотелось бы сначала отлаживать код под X++ а потом выяснить, что для работы в скомпилированном виде под .,NET надо дополнительно отлаживать.
Но тут, насколько я понял, хотят X++ по семантике приблизить к .NET. См также
вот этот пост
Вообще это можно сделать опциональной ускоряющей штукой типа ngen
Цитата:
В третьих - не знаю, обратил ли ты внимание, но они там мягко обошли вопрос многозвенной архитектуры и вообще рассуждали о том, что мол хорошо бы перейти на модель сервисов, при которой на каждом tier не хранится много контекстной информации. Я как-то слабо понимаю как это можно сделать не переписывая всерьез прикладной код...
Мне вообще концепция вебсервисов кажется шагом назад - вместо того, чтобы думать о предметной области, строить некую объектную модель и заниматься производительностью только в случае проблем в саму модель сразу закладываются некоторые ограничения связанные с разделением по звеньям.
Цитата:
Ну и наконец - в общем и в целом - на развитие продукта тратиться некая фиксированная сумма. И все что ушло на разработку ядра, не досталось прикладным разработчикам...
Вопрос, какова доля этой суммы в общей структуре расходов и сколько времени, потраченного на оптимизацию, это может сэкономить прикладным программистам.
В общем, я считаю, что стратегически переход на .NET вещь правильная так как позволит меньше тратить на инструменты. Главное чтобы сам по себе переход был спланирован и реализован так чтобы не было сильного ущерба на каждом из этапов.