deks
Advanced Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Frodo_Torbins
Я так понял, что NextGen компилятор сейчас генерирует только ARM код. собственно, LLVM то и нужен был, чтобы генерировать байткод для ARM, так как ЭМРО было бы дорого сделать приличный компилятор еще и для ARM.
Беда в другом - сам по себе LLVM модульный. Но вот RAD Studio вообще не задействует его модульность. То есть, при переписывании ядра IDE с учетом возможностей LLVM все было бы прилично: парсер бы работал в фоне прямо в среде, а бэкэнд отрабатывал бы тоже фоном, а по нажатию кнопки Run только бы бандл приложения паковался б. Например, XCode который тот же LLVM использует - вообще ужастно быстрый, почти как/быстрее Delphi. Сложно сравнивать кто именно быстрее - в последнее время (года 3-4) у меня win живет в vm, а все ж не корректно сравнивать нативно выполняющийся xcode и код внутри vm.
По поводу FPC. Наверное, неплохое решение, кстати, есть даже IDE под OS X, но мне оно кажется менее элегантным, чем Oxygene. Поэтому у меня и подписка на оксиген 
По поводу "заюзать старый код". Я тут (года два назад) делал свои прикидки - а чего мне реально нужно тянуть в кросс-платформу? Для этого пару имевшихся проектов (я назвал их "экспериментальными") перешерстили на предмет, разложить "по кучкам" собственно логику приложения, вспомогательные UI-штуки (типа, главная форма с "браузером" формочек, кнопки back, history посещенных форм и тп), вспомогательные платформенно-зависимые штучки (типа, сохранение параметров конфигурации в ini/реестр), вспомогательные штуки для работы с сервисами (rest/собственные сервера приложений), компоненты (отчеты, парсеры всяких XML, JSON, Markdown, YAML, etc).
В общем, оценивая размер кучек пришли к невеселому выводу - большая часть кода она не к приложению относится. Само приложение - это процентов 10-15! Это такой "клей", который сторонние "крипичи" склеивает в некую конструкцию.
Потом глянули, как дела с "кирпичами" в Objective-C (да, были планы миграции/экспансии). Вы знаете, неплохо. Я бы сказал, что с библиотеками отдельных типов там ГОРАЗДО лучше чем в Дельфи. Беда в том, что это именно библиотеки, а не компоненты. Впрочем, особенной трагедии нету - терпимо, я по дизайнеру форм не особо скучаю. Благо значительная часть формочек все равно на лету делается, в коде. И библиотеки есть на любой вкус - и для сервисов, и визуальные компоненты всякие хитрые.
Есть некоторая беда с доступом к базам данных, особенно из iOS. Но все решается веб сервисом. Наверное, даже правильнее такие решать веб-сервисом и кэшированием на клиенте. А это лишний раз говорит о необходимости переделывания приложения под мобильный мир: нельзя вот как в десктопе держать постоянное "живое" подключение к БД. Да и какой админ вам даст выставить БД "в интернет".
Такая же беда с отчетами (reports) - ну нету их как класса под ObjC. Полностью испортило программистов под Cocoa возможность нативно делать PDF. Так что печать документов - ручками. Это не сложно, но визуального дизайнера как в FastReport не предвидится. Не понимаю, почему ушлые фастрепортовцы не сделают Objective-C библиотеку сабжа. Видимо, который год выпускают FR5!
В общем, к чему я это все? Нафиг не нужен "старый код". Хитрые куски алгоритмов перенести не проблема. А вся остальная обвязка делается "по месту". Да и Оксиген то нужен в основном из-за муторного синтаксиса ObjC)
|
