Только Tcl/Tk! Только хардкор!

Нужно-нужно-нужно!!!

Школьник которому вдолбили, что делфи, де, круто, а потом ничего другого не осилил?

Если что - школьник, которому вдолбили, что делфи - это отстой, а реальные посоны пишут на Си/C#/нужное подставить, ничуть не лучше.

Другой синтаксис. А так то же самое.

Напомни - в VB сделали _обязательное_ объявление переменных, или он так и остался бейсиком, в котором можно ничего не объявлять, и умолчания рулят?

Теперь дельфи точно капец... wait... но оно же уже мертво!

дельфи не умирает!

Ох, да: а динозавры-хардкорники-паскалисты могут идтить пастись в сад. Или курить там бамбук - на выбор.

Я современный паскаль только недавно для себя открыл. Мне показалось что противники этого языка - в основном дураки.

Время компиляции больших проектов в C++ на порядки дольше. В FPC есть inline assembler для всех поддерживаемых архитектур. Никаких тебе include файлов, нет возни с makefile'ами. ООП есть с древних времён. Единственная альтернатива для gcc.

Все поддерживается кроме VCL. Новый UI фреймворк http://ru.wikipedia.org/wiki/FireMonkey

кстати, я никогда не задумывался, а есть ли в Linux упаковщики бинарей?

upx и есть обычный упаковщик из репозитория. В линуксе с ним возникает проблема с определением бинарём собственного пути - он запускается не с диска а из памяти. Если заранее это предусмотреть, то в программу нужно заложить возможность получения пути из коммандной строки - запускаешь скрипт, он вычисляет путь и передаёт его запускаемому им же бинарю.

ты привел пример для ОС Linux?

В линуксе бинари весят больше, в остальном всё так. Ещё можно снижать вес бинарей если компилить их со smartlink опциями - fpc file.pas -XX -CX

а как такие утилиты как ldd дружат с такими?

ldd их не понимает, они же заархивированы.

кстати, господа, а в чем цимес паскаля вообще? Какого преимущество перед С++ например

У меня в компании на сях пишет девушка двадцати двух лет от роду, без вышака. Пишет просто потому что ей это прикольно. И, да! - она замужем. И, да! - семья не страдает. И, нет! - она не специально отобрана!

C(не C++) в подмётки не годится FreePascal. Ну, GCC генерирует более эффективный машинный код, после многих лет оптимизации в корпорациях. Но это не столь необходимо как простота реализации и переносимость в условиях настоящего opensource.

имхо языковые конструкции проще, объявление в одном файле с реализацией, удобные свойства классов (property), вследствие чего повышается читабельность кода, ну и скорость компиляции. Но я вообще по плюсам не очень спец, больше читаю чем пишу. Ты лучше скажи: чем паскаль хуже?

если тут верить всем сообщениям, то буквально всё лучше, чем с(с++; кстати это разные языки...так на всякий случай), всё работает быстрее и пишется проще, да и вообще ...когда уже ядро на паскале(VB/Tcl/OCaml/List) перепишут ...

кстати, господа, а в чем цимес паскаля вообще? Какого преимущество перед С++ например

Первое что вспоминается это скорость компиляции паскаля, на ПОРЯДКИ быстрее C и C++. В случае паскаля пренебрегают временем компиляции, оно не берётся в расчёт так как в большинстве проектов компиляцию можно приравнять к времени запуска какого нибудь интерпретатора.

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

Нет include файлов. Нет необходимости в работе с makefile'ами.

И т.д.

а я откуда знаю. Я и спрашиваю чем оно лучше. Я паскаль видел последний раз в делфи 4 (редким ублюдтсвом, кстати, мне показался).

В VB6 объявления обязательны. Чтобы были не обязательны, нужна специальная директива. В VB.Net вообще обязательны.

Дельфи, насколько я помню, делался компанией Borland как средство быстрой разработки клиентов к различным СУБД, в первую очередь к Oracle. Своеобразная альтернатива жабе

Жаба (если ты про Java) и Delphi появились одновременно, в 1995 году. А вот историю о том, как Delphi 1 чуть не получила имя VBK (Visual Basic Killer), рассказывали сами сотрудники Borland.

до версии 6 (дальше уже не интересовался), были нативные компоненты для postgres и oracle без использования ODBC.

Oracle - да, DOA и ODAC. А компоненты для постгре начали появляться, по-моему, уже позднее (Zeos DBO развивался уже после Delphi 7).

Вообще, в Delphi был заложен гораздо более мощный потенциал, чем многие представляют. Строго типизированный язык, нативная компиляция, GUI-тулкит с высоким уровнем абстракции от ОС (VCL). Очень жаль, что Borland не потянула проект Kylix, архитектура VCL прямо напрашивалась на кроссплатформенное развитие. Очередной пример того, как из-за маркетоидов проиграли технари.

В принципе, имея современную Qt, уже почти не жалко. Вот только, в отличие от Объектного Паскаля, в C++ полностью отсутствует такая штука как модульность, встроенная в язык (не путать с костылями для имитации модульности в виде #include и namespace). И это в больших проектах порою сильно подбешивает.

Хотя и в Объектном Паскале модульность реализована не идеально. Близка к идеалу упомянутая выше «жаба». Но у неё свои тараканы.

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

Да. Точнее сказать - объектного паскаля (см. моё сообщение выше). Там есть встроенная модульность, а не просто раздельная компиляция.

Нет необходимости в работе с makefile'ами.

Но make, замечу, в старом турбо паскале была. И очень выручала, когда надо было собрать сложный проект.

если тут верить всем сообщениям, то буквально всё лучше, чем с(с++; кстати это разные языки...так на всякий случай), всё работает быстрее и пишется проще, да и вообще ...когда уже ядро на паскале(VB/Tcl/OCaml/List) перепишут ...

В Паскале есть проблемы, например, если хотите получить срез массива типа:

double[] y = x[10 .. 20];

Вроде бы нет множественного наследования, хотя его польза сомнительна.

Если серьёзно, никогда, никогда не предлагайте новичкам писать на C++. Если только это не специально отобранные люди с очень высоким интеллектом, без семьи и иных целей в жизни.

Люди с высоким интеллектом вряд ли выберут эту каку. Остальное верно. --КО.

Люди с высоким интеллектом вряд ли выберут эту каку.

Утешай себя, утешай, неосилятор :)))

Напрашивается продолжение:

- Идущие нахрен приветствуют тебя!

Интересно, это как-то сподвигнет Ghisler`а запилить Total Commander под Linux (?)

Не сподвигнет. Он всё жаловался на проблемы с переносимостью, а теперь, гад, запилил свой TC для Андроида, где менять явно надо больше, чем при переносе с винды на линукс. Что наводит на мысль, что всё это были отговорки...

Получение среза массива без копирования? Это где это такое? А вообще решается с помощью указателей

Вроде бы нет множественного наследования, хотя его польза сомнительна.

весьма сомнительна, но есть возможность реализовать с помощью интерфейсов.

В FPC есть inline assembler для всех поддерживаемых архитектур.

Кстати, вот это достоинство весьма сомнительное. Хороший стиль программирования требует выносить все архитектурно-зависимые части кода в отдельные файлы.

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

Как вы судно назовете...

Ну тогда ладно :)

И теперь, после такого более, чем 10-летнего приключения, Lazarus таки похоронят?

Так Лазарь же, воскрешенный друган Иисуса. Его наоборот похоронили 10 лет назад и потихоньку откапывают.

Получение среза массива без копирования? Это где это такое?

D2, Go, Python (применимо и к спискам, и к стандартным массивам, и к массивамиз numpy). Наверное, есть ещё.

То есть при получении среза, в питоне например, память не копируется? Если я изменю содержимое в срезе, то изменится содержимое исходного массива?

Но make, замечу, в старом турбо паскале была. И очень выручала, когда надо было собрать сложный проект.

Разве fpcmake не достаточно? Утилита которая понимая модульность паскаля генерирует готовый Makefile используя на входе простой INI файл.

То есть при получении среза, в питоне например, память не копируется? Если я изменю содержимое в срезе, то изменится содержимое исходного массива?

Не копируется. Именно так, изменится, хотя копирование тоже реализовать несложно.

В FPC есть inline assembler для всех поддерживаемых архитектур.

Кстати, вот это достоинство весьма сомнительное. Хороший стиль программирования требует выносить все архитектурно-зависимые части кода в отдельные файлы.

А можно использовать условную компиляцию. В Dlang тоже таким путём пошли. Думаю в ассемблере бывает полезно сверяться с реализацией для другой архитектуры в том же файле.

И вынести в другой файл ничего не мешает.

Поздравляю всех паскалеводов. :)

... а вшивый - о бане

Не копируется. Именно так, изменится, хотя копирование тоже реализовать несложно.

Python 2.7.3 (default, Aug 1 2012, 05:16:07)

[GCC 4.6.3] on linux2

Type «copyright», «credits» or «license()» for more information.

==== No Subprocess ====

a=[0]*5
b=a[1:3]
b[1]=1
b

[0, 1]

a

[0, 0, 0, 0, 0]

В FPC и Delphi это тоже есть, причем очень давно.

А какие у тебя параметры компилятора?

p.s. Недавно быстро сваял прогу - окно с меню и кнопкой закрыть,
скомпилировал, получилось около 200кб, что вполне сопоставимо с делфи.

Очень похоже, что модульность идеально реализована в Component Pascal, жаль, что язык не очень распространен.

Да там удачная концепция, как и в Модуле.

Согласен, но:

>>> from numpy import *
>>> a = ones(10)
>>> b = a[3:7]
>>> b[:] += 1
>>> print a
[ 1.  1.  1.  2.  2.  2.  2.  1.  1.  1.]

В FPC и Delphi это тоже есть, причем очень давно.

Как?

Потыкал его. Докинг окон все так же не работает, неудобно. Дженерики непонятно как использовать: TXmlNodeList = TList<TXmlNode>; Error: Specialization is only supported for generic types

TXmlNodeList = specialize TList<TXmlNode>; Error: Identifier not found «specialize»

generic TXmlNodeList = TList<TXmlNode>; Fatal: Syntax error, «=» expected but «identifier TXMLNODELIST» found

Скомпилил небольшую программу (одно окно, несколько контролов): XE2 - 1.4 Mb, Lazarus - 2.2 Mb/ Скорость исполнения примерно одинаковая

кстати, господа, а в чем цимес паскаля вообще? Какого преимущество перед С++ например

Ты честно признался, что не разбираешься в вопросе, вместо того, чтобы кричать об ущербности «паскаля». Поэтому я тебе отвечу.

Начнем с того, что в сраных крестах нет понятия модуля как единицы компиляции. Отсюда растут проблемы типа «объявлено где-то там; реализовано, хрен пойми где». Как следствие: херово работающий автокомплит в _любой_ IDE, и ужасно медленная компиляция. Суровые петушки щас скажут, что это мелочи, но мы-то знаем.

Дальше надо сделать уточнение, что мы говорим не о паскале, а о его современных диалектах (начиная хотя бы, с дельфи 5). Тот язык назывался Object Pascal или Delphi, и он же принят за основу в FPC. Для краткости далее современный паскаль = FP.

Так вот в FP гораздо более четкий, человекочитаемый и богатый синтаксис, чем в C++, но паскалененавистники обычно не знают синтаксиса за пределами «скобки против begin end». В FP гораздо более гибкое классовое наследование. Например, reintroduce только в последнем стандарте крестов из дельфи стырили. Так же, как и типизированные значения перечислений.

В крестах убогий RTTI, можно сказать, что его там просто нет по сравнению тем, что встроено в TObject. А в FP класс это еще и объект первого класса, AFAIR. То есть можно присвоить ссылку на класс переменной или передать в метод.

Ну а строки - важнейший тип данных в любых программах - различаются между крестами и FP, как земля и небо.

В общем, перечислять косяки крестов можно очень долго (http://yosefk.com/c fqa/index.html). Паскаль тоже не идеальный, но пипеца в нем меньше гораздо. А с учетом того, что в FP даже дженерики запилили, нужность крестов это исключительно вопрос legacy.

Нужность FP в продакшене тоже невелика - плохая репутация среди кодомакак и упущенное время. Хотя, кто знает? Может вторая волна популярности пойдет, ггг :)

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

Это потому, что дедушка Вирт сначала подумал, потом сделал. В случае с C поступили наоборот — слепили какашку из того что было, а потом стали репу чесать — а как же это распарсить?? В последствии C++ довёл синтаксис языка до маразма.

Паскаль, конечно, не идеал (на мой вкус синтаксис Модулы-2 поприятнее), но из C и Паскаля я бы выбрал Паскаль.

Давным-давно видел такое замечание: Половина книг, посвящённых C/C++ — советы как избежать типичных ошибок при программировании. Помните советы писать «if ( 1 == x )» вместо «if ( i == 1 )»? Если ошибёшься и вместо двух равно напишешь одно, то компилятор в первом случае выругается (левый операнд присваивания не может быть константой), а во-втором — нет. Конечно, сейчас это уже неактуально, так как приличные компиляторы выдают предупреждение на код «if ( x = 1 )», но сколько лет потребовалось для осознания? Сколько времени потратили программисты на набивание шишек и поиск подобных дурацких ошибок? А ведь могли бы потратить это время на что-нибудь более полезное…

Я современный паскаль только недавно для себя открыл. Мне показалось что противники этого языка - в основном дураки.

Ну, не дураки. Я бы сказал: необразованные люди.

Какая неочевидная «фича». На паскале можно реализовать что-то типа List.GetRange(List2, 4, 5), но мне такое ни разу не пригодилось. Да и вообще, сравнивать фичи синтаксиса компилируемого языка с интерпретируемым некорректно. Хотя классно было бы в паскале свитч по строкам иметь.

Хотя классно было бы в паскале свитч по строкам иметь.

Уже запилено, насколько я помню. :)

в общем, возрадуемся за релиз сей чудной IDE и библиотеки, ну а я пошел изучать Qt 5 beta1, всю ночь качалось по мопеду через деревенский интернет (EDGE), молился Столлману чтобы md5 совпало, все-таки Столлман существует - подсобил :P

Кстати, забавная привычка паскалистов - измерять всё в строках кода; наблюдаются определённые ассоциации с историями про индусов, которым якобы платят за число строк.

Весьма крупный OpenMW билдится за 3-4 минуты. Надо ли жертвовать многим ради того, чтобы полный ребилд за 30 секунд шёл? Или просто паскалистам больше нечего сказать? Так скажу - для справки чисто - что и в C++ той же скорости достигнуть несложно, достаточно написать либы столь же дубовые, как в паскале, не пересобирать их конечно же - так делают в паскале, и свой проект вместе с такими вот либами писать, используя pimpl и предварительные объявления.

FreePascal действительно используется в школах и немного в вузах, и это хорошо, прежде всего для преподавателей. Но зачем выдумывать нелепости про турбо-сборку или убер-удобства, которых нет? И да - сказки, будто бы паскаль лучше подходит для обучения, остаются сказками; он великолепен на начальном этапе, на нём легко показать реальную сложность программирования или обучить человека писать удобочитаемый код, а вот дальше он становится слишком простым и учит уже всё делать на «лишь бы у меня с грехом напополам работало» и не считать количество лишних сущностей и повторений.

А у них иного выхода нету, на паскале же всё «быстрее и проще реализуется».

Между прочим, одна из киллер-фич C++ - возможность легко прокидывать интерфейсы в другие языки; вот только паскалистам не понять, до идеи писать гибридные программы они ещё не дошли - в лучшем случае на метапрограммировании и domain-specific языках остановились.

Модульность это просто другой способ описания экспорта символов, в С для этого есть static. В паскале модуль имеет interface и его implementation. Все что объявлено в implementation это static. Поэтому не понимаю восторгов по поводу модульности.
Мне поначалу нравился борландовский объектный паскаль, например то что в нем можно было контролировать вызов конструктора базового класса. Но потом пошли всяческие сущности типа class которые отличались от object, что только добавило бардака.

упущенное время.

Алана Купера вам советую. А то так и будете на упущенное время жаловаться.

100% точный автокомплит в плюсах действительно не существовал до появления clang - что уж взять с людей, пытающихся написать языковой движок C++ на джаве. Правда, комплитеры до clang фейлились лишь на препроцессоре и делали это в угоду времени отзыва среды - но паскалисты в большинстве своём педанты, им лучше шалаш, чем хороший дом, но главное чтоб шалаш был сделан по всем правилам строительства шалашов, что изложены в книгах диванных теоретиков.

C++ сложнее для разбора, намного сложнее - сам Страуструп говорил, что книга дракона не раскрывает реальных проблем, возникающих при написании компиляторов, и привела к низкому качеству первых компиляторов C++. Но только школьник (по паспорту или в душе) может предположить, будто бы это чья-то ошибка. Комитет просто взял и отбросил вещи, важные лишь для академиков, в угоду вещам, важным для практики.