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

[carrots]

Последнее время мне кажется, что больше всего спорят о том какой язык лучше или у какого есть будущее люди, которые ни одного языка не знают. В 2005 году я на паскале поставил точку, точнее на delphi, решил что теперь моим низкоуровневым языком программирования будет с++, тем более в то время в основном программировал сайты на javascript, php, sql, так что замена низкоуровневого языка не влекла за собой особых неприятностей. В 2010 я вновь подсел на уже на freepascal, оказалось, что этот язык очень удобен для разработки консольных, серверных приложений. В данном проекте, я использую одновременно на С#, С++, python, bash, freepascal, php, javascript, кроме того используются свои интерпретаторы. Зачем так много языков? Просто каждый из них более подходит для своих задач, сроки у нас сжаты так что приходится делать так как быстрее можно достичь поставленных целей. Очень часто люди удивляются, почему люди из нашей команды, которые программируют всю жизнь и хорошо владеют с++, используют паскаль. Скорее всего это связанно с комплексами образовавшимися в следствии того, что паскаль ассоциируется у людей с древним турбо-паскалем, который они учили в школе, и естественно, с неправильной стратегией развития делфи, после седьмой версии, и естественно модой. Я думаю что большинство просто не знают о реальных возможностях фрипаскаля. Java находится под крылом богатой корпорации, С# тоже, потому их есть кому пиарить, а freepascal имеет только плохую репутацию ставленую delphi и желающими убрать конкурента.
Я например перешел на fpc 2.7.1 и начал использовать его нововведения, и они мне нравятся. Freepascal на правильном пути и у него есть успешное будущее.

[SSerge]

imho, на сегодняшний день freepascal представляет собой набор плохо структурированных библиотек, содержащих огромное количество дублированных функций, 2/3 из которых - для исторической совместимости с ушедшими в историю компиляторами, 3/4 либо не документированы вообще, либо ограничены чем-то типа перечня функций в модуле, как работают - догадайся сам. Поддерживаемая идеология программирования - практически полная анархия, провоцирующая начинающих на использование например в объектном подходе вещей, в принципе не совместимых с объектно-ориентированным программированием, типа глобальных переменных, констант и работу с внутренним двоичным представлением объектов.

Минусы реализации:
- Отладчик. Очень большой минус.
- Строки и строковые операции. Для себя исследовал и выяснил, что увы. Скорость работы не подогнанного под компилятор кода, работающего со строками не только "заставляет ожидать лучшего", но скорее говорит о полной неэффективности. Бардак с кодировками, особенно с уникодом, работа с которым вообще приводит к резкой деградации производительности. Бардак с файловыми кодировками.
- Настоятельная необходимость помнить кучу ненужной дряни насчет того какой модуль с каким, в какой последовательности линкуется и т.д., постоянные перекрытия одинаково наименованных переменных и констант из разных модулей; при выходе на функции операционной системы - многочисленные костыльные конструкции и нетривиальные обходные маневры.

Дельфи говорите... Он, сц, стоит в два раза дороже той же VS и превратился х.з. во что. Один online only хелп уже доставляет.
Не удивлюсь, если у них "продажи растут" лишь за счет того, что кто-то _вынужден_ приобретать новые лицензии для покрытия истекших старых и потому что старые продукты не поддерживаются, ну и за счет принудительной легализации.

Для меня паскаль не дает ускорения кодинга. На C# получается быстрее. На C++ разработка получается чуть медленнее, но не настолько, чтобы это было заметно. Зато приходится вовсю пользовать perl, по чисто техническим причинам получающийся наиболее эффективным, несмотря на то, что формально подходя это чистая скриптовка с несуразным ситаксисом и плохо читаемыми текстами.

[Лекс Айрин]

SSerge, лично я отладчиком и не пользуюсь, ибо всегда можно добавить тестовый выход. Для понимания сути происходящего это зачастую хватает. С кодировками да, проблема.

Переписать, конечно, можно... но тогда очень многим придется переписывать свой код, что вредит идеологии. А учебник бы не помешал... но ведь можно вскрыть и сам код модуля.

[debi12345]

Строки и строковые операции. Для себя исследовал и выяснил, что увы. Скорость работы не подогнанного под компилятор кода, работающего со строками не только "заставляет ожидать лучшего", но скорее говорит о полной неэффективности. Бардак с кодировками, особенно с уникодом, работа с которым вообще приводит к резкой деградации производительности. Бардак с файловыми кодировками

??? В отличие от других языков, в FPС это хоть как то сделано. И даже не "как-то", а лучше некуда Также в библотеке есть версии строковых функций и для обычной кодировки, и для уникода.

[SSerge]

в FPС это хоть как то сделано.

В delphi сделано. В fpc можно сказать что не сделано никак. Ибо уникогдный компилятор незнамо когда выйдет в релиз, и если остановится на реализованном, то поддержка будет все равно неполной. Особенно что касается чтения файлов в разных кодировках.

[Mikhail]

Последнее время мне кажется, что больше всего спорят о том какой язык лучше

Здесь не спор, а обсуждение проблемы будущего "Паскаля". Конкретно спор только по одному пункту, пока, о наличии у Паскаля проблем. Некоторые отрицают наличие проблем, я не согласен с ними.

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

решил что теперь моим низкоуровневым языком программирования будет с++

Это ошибка, извините. Низкоуровневый язык это С, а те задаи которые сейчас решаются на С++ лучше решать на С# или Java.

Добавлено спустя 2 минуты 25 секунд:

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

Сообщение SSerge » 30.10.2013 07:00:37
imho, на сегодняшний день freepascal представляет собой набор плохо структурированных библиотек, содержащих огромное количество дублированных функций, 2/3 из которых - для исторической совместимости с ушедшими в историю компиляторами, 3/4 либо не документированы вообще, либо ограничены чем-то типа перечня функций в модуле, как работают - догадайся сам. Поддерживаемая идеология программирования - практически полная анархия

Абсолютно согласен! В Делфи и FreePascal размываются основные черты Паскаля дающие ему преимущество, а именно: логическая стройность и компактность.

Добавлено спустя 3 минуты 14 секунд:

Для меня паскаль не дает ускорения кодинга. На C# получается быстрее. На C++ разработка получается чуть медленнее, но не настолько, чтобы это было заметно.

А надежность?

В общем главная проблема развития Паскаля (FreePascal, Delphi), на данный момент, это попытка сделать из него еще один С++ ИМХО, разумеется. В итоге получаем недо С++, уступающий оригинальному почти во всем.

[debi12345]

Ибо уникогдный компилятор незнамо когда выйдет в релиз, и если остановится на реализованном, то поддержка будет все равно неполной. Особенно что касается чтения файлов в разных кодировках.

???
1) всегда писать исходники в UTF8-редакторе тогда не будет проблем переносимости между "осями" и 2) компилировать с опцией "-Fcutf8".

ПС: крайне удивлен претензиям к ФПЦ по части работы со строками, хотя тут ФПЦ несоменно впереди планеты всей

[mse]

In general, the main problem of the Pascal (FreePascal, Delphi), at the moment, it is an attempt to make him another C + + IMHO, of course. In the end, until we get C + +, second original in almost everything.

Exactly. Interesting that this discussion is on freepascal.ru at the same time as the development of an own compiler has been started because I don't trust in Free Pascal anymore.

[debi12345]

В Делфи и FreePascal размываются основные черты Паскаля дающие ему преимущество, а именно: логическая стройность и компактность.

Хм, никто не заставляет использовать дополнительные (к "чистому" Паскалю) фичи и библиотеки ФПЦ. Или проблема в том, что в соблазн вводит ?

Добавлено спустя 3 минуты 16 секунд:

the development of an own compiler has been started

Martin, are which things planned to be different in the started compiler ? Will it be an OBERON like ?

Добавлено спустя 3 минуты 44 секунды:

недо С++, уступающий оригинальному почти во всем

Пока вижу одну "уступку" - отсутствие множественного наслдедования сразу при определии класса. Однако как в Java - решается насделованием от интерфейсов (абстрактных классов, допускающих множестенное наследование).

[Mikhail]

Хм, никто не заставляет использовать дополнительные (к "чистому" Паскалю) фичи и библиотеки ФПЦ. Или проблема в том, что в соблазн вводит ?

Проблема в том что разные библиотеки (модули) делают разные люди и каждый пишет на своем подмножестве Free Pascal, а проблемы возникают на стыке. Такие же проблемы есть и в C++.

Добавлено спустя 2 минуты 38 секунд:

Пока вижу одну "уступку" - отсутствие множественного наслдедования сразу при определии класса. Однако как в Java - решается насделованием от интерфейсов (абстрактных классов, допускающих множестенное наследование).

Множественное наследование зло, ИМХО. Хорошо оно работает только на бумажных примерах.
Интерфейс это не абстрактный класс и он не наследуется а расширяется.. И да, "ООП" в Яве сделан лучше чем в С++.

[carrots]

Позвольте частично с вами не согласиться,

Это ошибка, извините. Низкоуровневый язык это С, а те задаи которые сейчас решаются на С++ лучше решать на С# или Java.

Не забывайте, сто C# и Java это что-то между интерпретируемыми языками и компилируемыми, которые исполняются виртуальной машиной, которая помимо того что тормозит ужасно еще и памятью управляет как душе угодно. В результате код страшно медленный, а ресурсов жрет не мерено.
Я недавно писал экспорт с unity3d мешей в файл с переводом всего в глобальные координаты и дополнительными подготовками. На С# код настолько долго исполнялся что нельзя было дождаться окончания. Пришлось переписать на с++, после чего скорость повысилась в сотни раз, скрипт исполнялся за секунду. Бывают такие случаи где Java и С# бессильны, как ты ими не крути. Конечно они удобны, и я больше программирую на С# чем на C++, но нельзя их сравнивать с такими языками как c++, fpc, D, C., 'это языки разных назначений и уровней.

В общем главная проблема развития Паскаля (FreePascal, Delphi), на данный момент, это попытка сделать из него еще один С++ ИМХО, разумеется. В итоге получаем недо С++, уступающий оригинальному почти во всем.

Мне наоборот кажется что в freepascal принципиально не хотят подрожать c++, даже встроить очевидно удобные вещи такие как объявление переменных в любом нужном месте, а в остальном скорее наоборот с++ стараются сделать вторым паскалем, а получается недопаскаль. Например в паскале появились проперти, хорошо, попытались их встроить в c++, borland по своему, microsoft по своему, qt по своему, толком ни у кого не получилось, а в gnu их вообще так и нет. For in или foreach появился в паскале, в qt попытались склонировать, что-то получилось, но далеко от того что сейчас в fpc, в fpc можно с помощью выложенных типов сделать чтоб оператор for in из генерика словаря возвращал запись с ключом, значением и индексом, с++ к этому еще расти и расти. Предлагают в стандарт 2014 c++ добавить динамические массивы, которые в паскале с незапамятных времен. С++ имеет строгую стандартизацию, что немного тоже притормаживает развитие, и такие сравнения можно продолжать долго...

[mse]

Martin, are which things planned to be different in the started compiler? Will it be an OBERON like?

In a first step more like the transition from C++ to D. -> reduce the number of language elements one has to learn, make it as simple but powerful as possible.
Also get back the lightning fast compiling speeds of Borland times and leave the dictates of Delphi compatibility. Later changes in basic syntax are possible too.

[Лекс Айрин]

даже встроить очевидно удобные вещи такие как объявление переменных в любом нужном месте,

Это сильно неудобная возможность для программиста. К тому же нарушающая основной принцип ООП -- разделение на интерфейсную часть и часть реализации.

[debi12345]

а в остальном скорее наоборот с++ стараются сделать вторым паскалем, а получается недопаскаль.

100%. Паскаль выступает в роли генератора синтаксических ништяков, С++ его постянно и безуспешно пытается догонять

Добавлено спустя 1 минуту:

Это сильно неудобная возможность для программиста

Но цикловые переменные бы не помешали.

[alexey38]

1) всегда писать исходники в UTF8-редакторе тогда не будет проблем переносимости между "осями" и 2) компилировать с опцией "-Fcutf8".

Проблемы уникодовских строк уже многократно обсуждались. Одна проблема Вами тут обозначена - это то, что компилятор использует кодировку файла с исходником программы как указание на то, в каком типе хранить строковые константы. Тип строковой константы должен определяться строго в опциях компилятора или в параметрах конкретного моделя. А вместо этого опция "-Fcutf8" указывает принудительно на кодировку самого файла, что опять же достаточно кривое решение.

Кроме того, в ФПС довольно криво реализованы автоматические преобразования кодировок, в отличие от Дельфей, где одновременно работая и с UnicodeString и c AnsiString не требуется в тексте программы писать вручную функции преобразования. Исторически дельфовские динамические строки, появившиеся достаточно давно (и на тот момент не имевших нормальных аналогов в других распространенных языках) были хороши тем, что в отличие от того же С/С++ их использование вообще не требовало ни каких головняков. Все всегда работало и без глюков. Даже Дельфовый переход с AnsiString на UnicodeString был достаточно безболезненным, где проблемы могли встречаться очень редко и только в том случае, если реализована была посимвольная (побайтовая) арифметика. В ФПС пошли в сторону некого универсализма с юниксовым уклоном - и все изначально стало плохо, еще со времен однобайтовых строк (AnsiString), когда непрерывно приходилось писать функции преобразования кодировок, вместо того, чтобы они выполнялись автоматически (что можно было сделать легко, если бы вначале хорошо подумали).