![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
pozitronikПруфлинк.
Первая мысль - жуткое негодование. Уйти с изученной и хоть как-то поддерживаемой Delphi на опенсорсную среду с опенотсоснымсорсным компилятором? Это же сколько сил и времени потребуется на портирование в одиночку такого проекта как TC? Года два, думаю - т.е. среднее время меж выходами мажорных версий TC. При этом вряд ли появятся новые функции - на них просто времени не будет, и не факт, что не обнаружатся косяки в функциях старых. То есть как пользователя меня всё это здорово напрягает.
Но обдумав ситуацию, нашёл в ней немало хорошего.
Для начала я вспомнил, что TC пишется на второй версии Delphi, выпущенной в 1996 году (сейчас актуальна 14 версия). По сравнению с ней даже Lazarus - рай для разработчика. Эволюция языка за 14 лет даже в опенсорсной версии компилера должна предоставить множество удобных возможностей разработчику, и это очень хорошо.
По той же причине портирование на Lazarus будет не сложнее, чем портирование на новейшие версии Delphi.
В Lazarus уже сейчас есть поддержка x64-компилятора, и, думается, это одна из важнейших (если не единственная) причин портирования. В Delphi превью такого компилера обещают только в начале следующего года.
Но самое главное - код, так или иначе, будет частично переписываться, ведь обязательно всплывёт что-то, что портировать через копипаст не получится. Гислер, скорее всего, предпочтёт сохранить совместимость, так что получим неплохую оптимизацию по коду. К тому же всплывут моменты, которые, на первый взгляд, перенеслись в Lazarus, но при работе глючат - их тоже придётся оптимизировать.
Ну и если совсем углубиться в историю, можно вспомнить, что однажды TC уже переписывался с Turbo Pascal на тот же Object Pascal, что дало возможность создания 32-x битной версии. Конечно, тогда и объёмы работы были другие.
Мда, чувствую бета-тестерам прибавится работки.
Хотел бы я, кстати, посмотреть на код TC. Предположительно, Гислер не использует никакие компоненты (имеются в виду именно компоненты, а не чужой код), кроме стандартных и самописных (а что из современных компонентов вы сможете засунуть в древнюю среду разработки?), а это значит, что объёмы кода должны быть просто гигантские. Очень интересно, как это всё поддерживается, без современных-то средств рефакторинга и моделирования...
Первая мысль - жуткое негодование. Уйти с изученной и хоть как-то поддерживаемой Delphi на опенсорсную среду с опен
Но обдумав ситуацию, нашёл в ней немало хорошего.
Для начала я вспомнил, что TC пишется на второй версии Delphi, выпущенной в 1996 году (сейчас актуальна 14 версия). По сравнению с ней даже Lazarus - рай для разработчика. Эволюция языка за 14 лет даже в опенсорсной версии компилера должна предоставить множество удобных возможностей разработчику, и это очень хорошо.
По той же причине портирование на Lazarus будет не сложнее, чем портирование на новейшие версии Delphi.
В Lazarus уже сейчас есть поддержка x64-компилятора, и, думается, это одна из важнейших (если не единственная) причин портирования. В Delphi превью такого компилера обещают только в начале следующего года.
Но самое главное - код, так или иначе, будет частично переписываться, ведь обязательно всплывёт что-то, что портировать через копипаст не получится. Гислер, скорее всего, предпочтёт сохранить совместимость, так что получим неплохую оптимизацию по коду. К тому же всплывут моменты, которые, на первый взгляд, перенеслись в Lazarus, но при работе глючат - их тоже придётся оптимизировать.
Ну и если совсем углубиться в историю, можно вспомнить, что однажды TC уже переписывался с Turbo Pascal на тот же Object Pascal, что дало возможность создания 32-x битной версии. Конечно, тогда и объёмы работы были другие.
Мда, чувствую бета-тестерам прибавится работки.
Хотел бы я, кстати, посмотреть на код TC. Предположительно, Гислер не использует никакие компоненты (имеются в виду именно компоненты, а не чужой код), кроме стандартных и самописных (а что из современных компонентов вы сможете засунуть в древнюю среду разработки?), а это значит, что объёмы кода должны быть просто гигантские. Очень интересно, как это всё поддерживается, без современных-то средств рефакторинга и моделирования...
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2010-07-22 06:36 am (UTC)no subject
Date: 2010-08-23 10:19 am (UTC)А новость-то хорошая. Я уже почти полгода активно юзаю Лазарь и перетаскиваю на него свои проекты. Довольно приличный по объёму кода проект для работы с БД удалось портировать всего за месяц не слишком плотной работы (при том, что это был первый опыт такой работы). Большую часть времени отнял отлов багов - в Lazarus из-за кросс-платформенности очень многие функции, похожие на дельфийские, на деле работают немного иначе.
В общем, я рад за Total Commander. И кстати, порт на Lazarus принесёт не только 64-бита, но и новые платформы - Linux и MacOS.
no subject
Date: 2010-08-23 10:30 am (UTC)Но, интереса ради, попробовал перенести с дельфи один из самых сложных своих проектов - разрабатываемую пятый год систему контроля базовых станций - обломался в самом же начале. Оракловый компонент Лазаруса не захотел коннектиться к ораклу, ругаясь на отсутствие TNS (которые были корректно прописаны, и с которыми остальной софт вполне работал).
Плюс переписывание тонн компонентов, без которых никак...
В общем, хорош анцтрумент, но простоват.
no subject
Date: 2010-08-23 10:32 am (UTC)no subject
Date: 2010-08-23 10:31 am (UTC)...я в настоящее время портирую на Lazarus/Free Pascal, компоненты которого основаны на UTF-8. Я уже перенес все мои Unicode контролы на Laarus, это было очень легко. Теперь я изменяю OLE2-код под Lazarus...
no subject
Date: 2010-08-23 10:32 am (UTC)