Delphi и ObjFPC такие разные
Модератор: Модераторы
Delphi и ObjFPC такие разные
Вас не настораживает, что делфи и фрипаскаль всё больше расходятся в разные стороны? Недавно взглянул на дженерики в делфе и удивился на сколько они отличаются от objfpc. Вот захотите вдруг скомпилить свою прогу, написанную на objfpc, на делфе и не получится. Придется доправлять код. Мне кажется, что разница - не есть хорошо. Вот был бы стандарт.
Это не сильно поможет. К примеру. Да, стандартный паскаль у Вас тоже не сразу скомпилится.
Тут дело в подходе.
Нужен не стандарт, а хорошая и документированная реализация с адекватными и простыми исходниками для ознакомления (при их наличии и стандарт можно написать, а все неоднозначности исправит ознакомление с исходниками).
В чем синтаксическая фишка Паскаля? В однопроходности при компиляции (разбил весь код по ";", построил дерево, собрал сгенерил объектники, собрал бинарники и радуйся).
Хорошую реализацию пока ещё никто не предложил... А пока все пишут "стандартную" реализацию, остальные пилят свои языки и расхваливают их...
Тут дело в подходе.
Нужен не стандарт, а хорошая и документированная реализация с адекватными и простыми исходниками для ознакомления (при их наличии и стандарт можно написать, а все неоднозначности исправит ознакомление с исходниками).
В чем синтаксическая фишка Паскаля? В однопроходности при компиляции (разбил весь код по ";", построил дерево, собрал сгенерил объектники, собрал бинарники и радуйся).
Хорошую реализацию пока ещё никто не предложил... А пока все пишут "стандартную" реализацию, остальные пилят свои языки и расхваливают их...
Последний раз редактировалось wavebvg 31.10.2014 11:07:24, всего редактировалось 1 раз.
Вас не настораживает, что делфи и фрипаскаль всё больше расходятся в разные стороны?
Настораживает. И что Вы предлагаете? Я предлагаю: пусть Embarcadero сделает синтаксис совместимым с ObjFpc :D
Это несколько напоминает линуксы с разными репозиториями и пакетными менеджерами. Хотя живут же как то. Просто тот же поиск инфы, как что реализовать, разобьётся на две категории - fpc и делфи. Будет неудобно. У разных юзеров будет разный несовмстимый код, хотя язык по идее один. Поделишься вот так исходниками библиотеки, а она пойдёт не у всех. Придётся писать несколько версий под разные компиляторы. В общем как то неприятно. Увеличение энтропии.
А зачем? Я пишу на паскале и не собираюсь использовать и писать что-то на делфи. Если делфисту будет нужен мой код, то портирование -- это уже его проблемы.
dedm0zaj писал(а): Вот захотите вдруг скомпилить свою прогу, написанную на objfpc, на делфе и не получится.
Если есть желание иметь компилируемый исходник на FPC и Delphi почему бы не пользоваться {$mode delphi}?
Хуже другое. FPC отстает от дельфей в плане реализации языковых конструкций. И это реальная проблема для желающих уйти с Delphi, но уже привыкших к её прелестям.
Хуже другое. FPC отстает от дельфей в плане реализации языковых конструкций. И это реальная проблема для желающих уйти с Delphi, но уже привыкших к её прелестям.
Эх, а ведь когда-то ситуация была обратной :(
Дож писал(а):Эх, а ведь когда-то ситуация была обратной
Я говорю даже не об отсутствии той или иной фичи, как то перегружаемые дефолтные свойства, анонимные методы или атрибуты, а о том, что даже поддерживаемые новшества поддерживаются лишь формально. Взять nested types. Фича доступная дельфийцам почти 10 лет, в FPC поддерживается, но результат реального использования печален. И примеров таких масса, причем не работают, казалось бы, элементарные вещи, например использование в директиве условной компиляции, размещенной в интерфейсной секции, константы декларированной в другом модуле. Или вот банальное приведение типа. Я понимаю, что все эти баги относятся к версии находящейся в разработке, а продукт бесплатный и ни кто ни кому не должен. Все это так. Но после такого опыта понимаешь, что как альтернативу Delphi, FPC можно рассматривать лишь в том случае, если речь идет о Delphi 7. Ну и чтобы совсем уж не офтопить... Вывод. Не стоит пугаться различий между Delphi и FPC т.к. на диалекте Delphi 7 можно писать одинаково и для того и для другого
dedm0zaj писал(а):Вас не настораживает, что делфи и фрипаскаль всё больше расходятся в разные стороны? Недавно взглянул на дженерики в делфе и удивился на сколько они отличаются от objfpc. Вот захотите вдруг скомпилить свою прогу, написанную на objfpc, на делфе и не получится. Придется доправлять код. Мне кажется, что разница - не есть хорошо. Вот был бы стандарт.
У меня есть сомнения, что целесообразно гнаться за совместимостью с Delphi. Поддержка на уровне Delphi 7 достаточна, ИМХО.
dedm0zaj писал(а):Недавно взглянул на дженерики в делфе и удивился на сколько они отличаются от objfpc.
Так пишите {$MODE DELPHIUNICODE}, собственно, при написании OBJFPC вы сознательно выбираете FPC-only.
Добавлено спустя 6 минут 4 секунды:
Mikhail писал(а):Поддержка на уровне Delphi 7 достаточна, ИМХО.
Это плохое имхо. Эмбаркадеро слегка упороты, но в основном правильные вещи делают. Хотя, правильные они лишь потому, что их тащат из C#. Однако без них паскаль можно отправлять в музей. С упомянутыми дженериками история такая была, их сделали в fpc и только потом в delphi. Причём, не так, как в fpc. Причём, правильно сделали, не так. Потому что сделали в разы прозрачнее описание. И сейчас в режиме совместимости с delphi её дженерики работают.
Спасибо Сергею Горелкину за отзывчивость 
pda писал(а):Хотя, правильные они лишь потому, что их тащат из C#.
Вот это-то и плохо. Именно поэтому мне не нравятся нововведения эмбаркадеры, включая поддержку юникода. Лучше бы делали совместимость FPC с стандартным си, чтобы типа можно было компилировать fpc исходники сишным компилятором.
pda писал(а):Это плохое имхо. Эмбаркадеро слегка упороты, но в основном правильные вещи делают. Хотя, правильные они лишь потому, что их тащат из C#. Однако без них паскаль можно отправлять в музей. С упомянутыми дженериками история такая была, их сделали в fpc и только потом в delphi. Причём, не так, как в fpc. Причём, правильно сделали, не так. Потому что сделали в разы прозрачнее описание. И сейчас в режиме совместимости с delphi её дженерики работают.
Плохо сделаны дженерики и в Delphi и в FreePascal. Здесь не нужно торопиться, нужно все тщательно обдумывать. Примерно полгода назад здесь уже было обсуждение будущего Pascal, многие согласились, что оно безрадостное.
да я бы сказал что не только будущее безрадостное, но и настоящее безрадостное
stanilar писал(а):Именно поэтому мне не нравятся нововведения эмбаркадеры, включая поддержку юникода.
Язык без уникода сейчас задаром никому не нужен. А то, как это реализовано в fpc, с постоянным перекодирование в utf8 и обратно - это вообще не дело.
stanilar писал(а):Лучше бы делали совместимость FPC с стандартным си, чтобы типа можно было компилировать fpc исходники сишным компилятором.
Даже боюсь спросить - как вы это видите...
Mikhail писал(а):Здесь не нужно торопиться, нужно все тщательно обдумывать.
Ну, вот вам аргумент "за" - подход "вы легко сможете пересесть с C# и получить на байткод, а бинарник для любой платформы (пока ещё нет, но они работают на этим)" не может не заинтересовать. Жаба конечно у эмбаркадеро тяжёлая, но с другой стороны у Xamarin цены как бы не более конские.