Есть ли у Паскаля будущее?

[Mikhail]

Есть же LLVM, который не только оптимизацию даст, но и генератор кода для многих платформ.

Предлагаете компилятор писать на C++?

[Mirage]

На мой взгляд, снижение интереса к Паскалю происходит от отсутствия развития и репутации устаревшего языка.
По поводу развития поясню: Delphi развивается, но некоторые из означенных направлений пугают (ARC, например). В общем, EMBT дает понять, что производительность их не интересует. А в этом случае логичнее использовать JVM. У нее производительность не сильно хуже (далеко не так, как нам тут рассказывают).
FPC тоже развивается, но медленно по понятным причинам и неконсистентно, по непонятным.
Думаю для нативного языка есть две основных и обязательных цели для развития:
1. позволять писать низкоуровневый высокопроизводительный код, давая полный контроль над генерацией машинного кода. Вплоть до того, чтобы выдавать ошибку, если не удалось заинлайнить то, что указано.
2. позволять не погружаться в низкоуровневые дебри, когда это не требуется. Т.е. иметь высокоуровневые конструкции. Причем желательно не тормозящие на ровном месте. Тот же подсчет ссылок неплохая идея, если не делать это обязательным.
Остальное уже соотносится с этими двумя целями. Например развитие RTL, оптимизации и т.п.

С репутацией сложнее.
Думаю, тут и для Delphi и для FPC оптимальным является создание нового языка, на бинарном уровне обратно совместимого с текущим.
Т.е. новый язык с новым названием, свободный от тяжести совместимости с уже существующим кодом на уровне исходников, но могущий использовать при компиляции .ppu, или .dcu.
Тут уже проще будет добавить интересные современные языковые фичи, поддержку LLVM и многое другое. Не получив при этом перегруженный синтаксис.
Хотя для этого подумать хорошенько надо сперва.

Вот RemObjects, кстати, хорошее дело делают. Язык у них свежий, без груза обратной совместимости. Хотя многие нововведения спорны.
Если сделают поддержку генерации нативного кода, то можно будет всерьез рассматривать переход на Oxygen.

Добавлено спустя 6 минут 18 секунд:

Предлагаете компилятор писать на C++?

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

Как-то в FPC майллисте один С++ программист предложил свою помощь в адаптации FPC для LLVM, по каким-то своим причинам. Но его зачем-то убедили, что это слишком сложно, т.к. есть некоторая несовместимость между FPC и LLVM. Epic fail. Т.к. это необходимо. Даже до EMBT дошло. Думаю у Delphi такая несовместимость тоже была.

[Mikhail]

Разве поддержка LLVM обязывает компилятор на С++ писать? Это же бакенд, занимающийся оптимизацией и генерацией конечного кода.

У него есть Сишный api? Как их компоновать-то?

[carrots]

carrots, код в collections.pas просто чудовищен. Надеюсь, Вы его приложили в качестве иллюстрации того, как не надо делать.

Ха, вы еще не видели как у меня на с++ коды выглядят, можно исходки смело выкладывать, все равно никто ничего не разберет..

А если честно - там тест возможностей генерика в 2.7.1. Генерик для использования двумерных массивов через sharedmemory, список и словарь с for in как у C#, возвращающем ключ и значение одновременно. Ключевой момент именно в словаре.

Добавлено спустя 11 минут 42 секунды:
Зато они при использовании выглядят красиво и удобно

[sign]

А кто в курсе, будут в FPC helper`ы на простые типы расширять, как это есть в Delphi?
Типа

Код: Выделить всё

TDateHelper = record helper for TDate
public
  function ToMySQL: string; inline;
end;


[zub]

>>А кто в курсе, будут в FPC helper`ы на простые типы расширять, как это есть в Delphi?
быстрый способ узнать - пошерстить на багтрэкере или в списке рассылки, если этого еще нет, написать соответствующий фичреквест
оно? http://bugs.freepascal.org/view.php?id=23817

[carrots]

А кто в курсе, будут в FPC helper`ы на простые типы расширять, как это есть в Delphi?

Уже есть, работают, проверял, только в mode delphi, вроди. В mode objfpc лучше object использовать, от record ничем не отличается, только в него еще можно функции и проперти вписывать и хелперы клеить без проблем + компилятор сам решает когда его создать и освободить, и сборщика мусора не нужно, и работает быстро и оперативки не ост много.
Хотелось-бы хелперы для еще более простых типов, таких как string..

[zub]

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

[Vadim]

А что такое "неконсистентно" применительно к Паскалю?

[carrots]

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

Действительно компилятор для object не вызывает конструктор init автоматически, но это как-раз плюс в отличии от class, поскольку с ними можно работать как с record, и не тратить время на вызов конструктора, но в дополнение они хранят относящиеся к ним проперти и функции, что значительно упрощает их использование и упорядочивает библиотеки... Не понял в чем там может быть проблема.
http://wiki.freepascal.org/Programming_Using_Objects

[mse]

I started a Wiki page about MSElang, the future compiler for the MSEide+MSEgui project:
http://sourceforge.net/p/mseide-msegui/wiki/MSElang/
Please use the mailing list if you like to discuss the matter in English:
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

[Mikhail]

I started a Wiki page about MSElang, the future compiler for the MSEide+MSEgui project:
http://sourceforge.net/p/mseide-msegui/wiki/MSElang/
Please use the mailing list if you like to discuss the matter in English:
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

РБНФ уже разработана?

[debi12345]

РБНФ уже разработана?

Сперва (3..5 лет) интерпретатор типа Java (под своего рода виртуальную машину), затем - компиляторы в экзешники под разные платформы... Вылизывание на универсальном (плаптформо-независимом) уровне, затем тиражирование на платформы.

What will not be implemented
Macros.

Я бы наоборот расширил язык до C-ых "#define"-макросов. Иногда их не хватает.

[Mikhail]

Сперва (3..5 лет) интерпретатор типа Java (под своего рода виртуальную машину), затем - компиляторы в экзешники под разные платформы... Вылизывание на универсальном (плаптформо-независимом) уровне, затем тиражирование на платформы.

Я вообще-то о грамматике.

Я бы наоборот расширил язык до C-ых "#define"-макросов. Иногда их не хватает.

Вот этого как раз не нужно.

Вообще, лучше начать со списка требований.

[mse]

EBNF is already developed?

In a first step the syntax is the language currently used in MSEgui, a subset of Delphi 7/FPC 2.6.2.