Статья о Free Pascal и Lazarus

> А на фига в школах учить программирование. На хер оно кому там нужно. Я говорю в первую очередь об университетах. В школах нормальных учителей информатики нет.

Дело не только в учителях, а ещё и в учениках. Я благодарен за то, что у меня в школе была информатика на которой я изучил Паскаль и смог продвигаться дальше. Преподаватель там должен дать самые азы, кому дано - тот сам будет развиваться.

> Ну что тут все обсирают паскаль.

Я обычно, в такие дискуссии не влезаю, но вам скажу, если почитаете архивы за достаточно большой срок (и ещё talks прочешете), то убедитесь, что здесь "обсирают" всё. :) Небыло такого ЯП, который не обосрали бы на ЛОРе. Включая, но не ограничиваясь, C, C++, Python, Ruby, Lisp, Perl... ;-)

> Уважаемые эксперты-онанимузы, вы еще до кучи к паскалю и аду тогда уж обосрите.

А вы какую-нибудь новость про Ada запостите, сразу начнут обсирать. :)

А лучше про Delphi. Представляю, что тут начнется...

Например видел 4 курс, системные программисты, пишут какую-то олимпиадную задачу(на массивы) на дельфях... Один, самый продвинутый, на С# - как же, самый подходящий язык для указателей! :D

Кому нужны быдлоГУИ, юзают среду wxDev-C++. Не нужно - редактор_по_вкусу + mingw/dmc/... подойдут в 99,9% случаев. В линуксе есть Анюта, Глэйд...

Зачем вообще этот паскаль, коллекция могучих костылей, и жалкие пародии на великий фетиш быдлокодеров - поделия фирмы Инпрайз?

T это самораспечатывающаяся прога на лиспе при запуске выведет ту же T

> Мусье знает толк в извращениях :) Вменяемый человек никогда так писать не будет, если пишет он для людей.

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

> Про D убило отсутсвие static_cast

Это что такое?

> и const

http://www.digitalmars.com/d/final-const-invariant.html

> и это: D is a systems programming language.

Немножко врут. Язык с автоматической памятью по сути своей ориентирован только на прикладные задачи.

> При этом все надеюсь знаете, что любой отказ от const, volatile и тд упрощает систему на порядки (кибернетика однако) то есть язык может и проще, а вот выразительности меньше, нужен более мощный AI в компилере для вычитывания мыслей программиста.

Так они и гордятся мозговитостью компилятора. Меня там больше всего завораживает наворочанность шаблонов.

Прекратите навязывать мне свою веру. :-P

Паскаля не касалась рука Билла Гейца, поэтому наглые вендузятники даже на ЛОРе пытаются дискредитировать Паскаль своими жалкими, несостоятельными и беспощными претензиями.

;-)

> Паскаля не касалась рука Билла Гейца,

Наоборот, это рука Паскаля коснулась Билла Гейца. Андерс Хейлсберг, ведущий архитектор Turbo Pascal и Delphi, был нанят Микрософтом и разработал C#.

>Плевать на скорость компиляции, если скорость _работы_ ниже почти на треть. +1

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

>Компиляторы Pascal умеют быстро генерировать неэффективный код. Было бы позорищем, если бы они делали это медленно.

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

По поводу неэффективности кода-ничего подобного.

jme на обироне писана

>jme на обироне писана

Оберон -- это всё-таки не Паскаль (особенно ObjectPascal). Хотя и родственники.

>Компиляторы Pascal умеют быстро генерировать неэффективный код.

Я не фанат Паскаля, даже недолюбливаю его, но и когда другие пургу гонят - тоже не люблю: http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=...

> Я не фанат Паскаля, даже недолюбливаю его, но и когда другие пургу гонят - тоже не люблю: http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=.. .

o.O

просто как тузег грелку.. не ожидал. :D

>> Ну я пишу - работа такая. VoIP gateway H323/SIP/RTP, а что? До тех пор пока не появился @ это ещё был какой-то особенный язык, а после стал жалким подобием C++. Особенно умиляет что в книжках по ObjectPascal писали одно время - есть такая мол возможность в нашем мощном языке - УКАЗАТЛИ!!!, но вы ей луче не пользуйтесь. Долго смеялся.

Зря смеялся. Может и oberon говно, и modula?..

Когда-то давно, когда еще в ходу были ассемблеры и написание программ на них, некоторое количество народу матерно хаяло тасм, и особенно его идеал модель, за то что там была введена строгая типизация, которая не позволяла, например, занести значение 32битного регистра в ячейку памяти описаную как 16битное слово. И чтобы это сделать ассемблеру надо было явно и недвусмысленно обьяснить что ты знаешь что делаешь. Это резко уменьшало количество тупейших багов в программах, но зато давало больше писанины.

Так вот, люди, опускающие тут паскаль, за его стройный синтаксис и строгую типизацию как раз относятся к категории тех кто в свое время хаял tasm и возносил nasm/fasm.

PS: на дельфи можно совершенно спокойно написать kernel mode driver.

>Когда-то давно, когда еще в ходу были ассемблеры и написание программ на них, некоторое количество народу матерно хаяло тасм, и особенно его идеал модель, за то что там была введена строгая типизация, которая не позволяла, например, занести значение 32битного регистра в ячейку памяти описаную как 16битное слово. И чтобы это сделать ассемблеру надо было явно и недвусмысленно обьяснить что ты знаешь что делаешь.

А что, по-вашему в С можно напрямую присвоить int -> short?

>Так вот, люди, опускающие тут паскаль, за его стройный синтаксис и строгую типизацию как раз относятся к категории тех кто в свое время хаял tasm и возносил nasm/fasm.

Правило такое: либо ты не делаешь строгую типизацию, либо ты даешь возможность ее обойти (C-style cast), либо предоставляешь средства чтобы жить с ней и не копи-пейстить один и тот же код с теми же багами по 10 раз (templates & generics).

>Правило такое: либо ты не делаешь строгую типизацию, либо ты даешь возможность ее обойти (C-style cast)...

Вы не поверите, в Паскале, если очень приспичит, можно обойти строгую типизацию.

>>Правило такое: либо ты не делаешь строгую типизацию, либо ты даешь возможность ее обойти (C-style cast)...

>Вы не поверите, в Паскале, если очень приспичит, можно обойти строгую типизацию.

А зачем тогда она нужна если ее можно обойти? В С ее тоже надо обходить - неявных преобразований с потерей в С нет. Дискуссия идет по кругу. Можно пару старых постингов сюда запостьить и обсудить их еще раз.

>А зачем тогда она нужна если ее можно обойти?

Затем, что обходить её надо далеко не всегда. Зато можно отсечь кучу случайных ошибок.

>>А зачем тогда она нужна если ее можно обойти?

>Затем, что обходить её надо далеко не всегда. Зато можно отсечь кучу случайных ошибок.

Новичка, который попытается написать первую более-менее сложную программу только все это отпугнет и все. Я например невзлюбил Паскаль когда мне не удалось сделать на нем динамической таблицу эффективной замены для LZW, а в С я нашел необходимый функционал. С тех пор мне с Паскалем приходилось иметь дело, и даже успешные проекты были на Delphi, но не люблю я его до сих пор.

> Паскаля не касалась рука Билла Гейца

ч0рная рука Гейтса коснулась всего и вся: http://pascal.sources.ru/museum/msqp1.htm

Он попробовал и потом решил больше к этой какашке не прикасаться!

> Он попробовал и потом решил больше к этой какашке не прикасаться!

Нет, он просто, как и вы, ниасилил. Мозгофф не хватило...

А я вот D ниасилил. :( А Паскаль - с легкостью, бо второй курс уже... Мало того, преподы и говорят - на пас мозгофф меньше всего надо. Если его ниасилил - совсем уж не кодер, даже не быдло-.

Есть хоть учебники по D? Туторов мало, от спецификации толку мало. Обидно...

Цитата из знаметитого SICP'а:

---8<---
Алгол 60, который уже никогда не будет живым языком, продолжает жить в генах Scheme и Паскаля. Пожалуй, трудно найти две более разные культуры программирования, чем те, что образовались вокруг этих двух языков и используют их в качестве единой валюты. Паскаль служит для построения пирамид — впечатляющих, захватывающих статических структур, создаваемых армиями, которые укладывают на места тяжелые плиты. При помощи Лиспа порождаются организмы — впечатляющие, захватывающие динамические структуры, создаваемые командами, которые собирают их из мерцающих мириад более простых организмов. Организующие принципы в обоих случаях остаются одни и те же, за одним существенным исключением: программист, пишущий на Лиспе, располагает на порядок большей творческой свободой в том, что касается функций, которые он создает для использования другими.
---8<---

Ага, счазз...

Тока Делфи 2007 до Visual Basic 2008 еще писать и писать...

Да и вообще дни Делфи сочтены... Предсмертные судороги

>на пас мозгофф меньше всего надо.

Которые потом ты окончательно убьешь

A C# учить - мама по имени "Столлман" не позволяет?

>А что, по-вашему в С можно напрямую присвоить int -> short?

Вы когда-нибудь на Си программировали? Если да, то почему такие
вопросы? Если нет, то зачем в таком тоне?

balancer@balpc ~/work/programming/c $ cat assign.c 
#include <stdio.h>

int main()
{
        int i = 123456;
        char c = i;
        printf("%d\n", c);

        return 0;
}
balancer@balpc ~/work/programming/c $ gcc assign.c -o assign
balancer@balpc ~/work/programming/c $ ./assign 
64

balancer@balpc ~/work/programming/c $ gcc -v
Используются внутренние спецификации.
Целевая архитектура: i686-pc-linux-gnu
...
Модель многопотоковости: posix
gcc версия 4.1.2 20070214 (  (gdc 0.23, using dmd 1.007)) (Gentoo 4.1.2 p1.0.1)

> Туторов мало, от спецификации толку мало.

Сначала осиливаешь C. Потом читаешь умную книшку по ООП и осваиваешь какой-нибудь ЯВУ, со списками, ассоцмассивами и автоматической памятью.

После этого D осваивается сам собой.

>>А что, по-вашему в С можно напрямую присвоить int -> short?

>Вы когда-нибудь на Си программировали? Если да, то почему такие вопросы? Если нет, то зачем в таком тоне?

Тогда говно этот ваш gcc: MSVC++ такое не съест ни в С ни в С++ режиме. На gcc как-то прошел мимо этого.

> Модель многопотоковости: posix

Кто гцц русифицировл?!

> Цитата из знаметитого SICP'а

Всё это болтология и пустой трёп.

> за одним существенным исключением: программист, пишущий на Лиспе, располагает на порядок большей творческой свободой в том, что касается функций, которые он создает для использования другими.

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

> Да и вообще дни Делфи сочтены... Предсмертные судороги

А про Delphi здесь речь и не идёт. Но раз уж упомянули, да, возможно, Delphi и склеит ласты, вот только всем бы столько их клеить. Анонимусы лет 7 (если не больше) ей смерть пророчат. Всё никак не умрёт...

> A C# учить - мама по имени "Столлман" не позволяет?

Коллективный разум местных анонимусов. Скажут - былокодер, подстилка M$... ;-)

<<Тогда говно этот ваш gcc: MSVC++ такое не съест ни в С ни в С++ режиме. На gcc как-то прошел мимо этого.>>

Мимо чего?

...
int i = 123456;
char c = i;
...

эквивалентно

...
int i = 123456;
char c = (char)i;
...

это стандарт.
В операции присваивания значение правого операнда приводися
к типу левого (арифметического).
Любое целое приводится к любому знаковому целому и результат
не изменяется, если входит в диапазон знакового целого,
в противном случае результат зависит от реализации.

Древний юниксоид

<<<Тогда говно этот ваш gcc: MSVC++ такое не съест ни в С ни в С++ режиме. На gcc как-то прошел мимо этого.>>>

<
...
int i = 123456;
char c = i;
...

эквивалентно

...
int i = 123456;
char c = (char)i;

это стандарт. >

Нафиг такой стандарт. Все преобразования с потерей всегда должны
производиться явно. Надеюсь все же на -Wall & Trait warnings as errors.

<<Нафиг такой стандарт. Все преобразования с потерей всегда должны
производиться явно.>>

С _возможной_ потерей.
Высылайте ваши предложения в ISO (ANSI).

Древний юниксоид

>>Нафиг такой стандарт. Все преобразования с потерей всегда должны производиться явно. >С _возможной_ потерей. Высылайте ваши предложения в ISO (ANSI).

Ну тут получается необычная ситуация - код для MSVC++ будет собираться GCC, поскольку ГЦЦ проглотит явный кастинг к примеру int->short, а гцц-шный код не будет принят МСВЦ++ поскольку "This conversion requires explicit cast".

>Ну тут получается необычная ситуация - код для MSVC++ будет собираться GCC, поскольку ГЦЦ проглотит явный кастинг к примеру int->short, а гцц-шный код не будет принят МСВЦ++ поскольку "This conversion requires explicit cast".

То есть MSVC++ не поддерживает стандарт языка?

> > Уважаемые эксперты-онанимузы, вы еще до кучи к паскалю и аду тогда уж обосрите.

> А вы какую-нибудь новость про Ada запостите, сразу начнут обсирать. :)

Разница в том, что Паскаль-то обсирают по разным причинам, и всё смешивается в одно. Кому-то просто (бывают же такие) не нравятся begin-end. В этом случае им можно показать Objective-C 2.0, он очень похож на современный Паскаль, если вам, конечно, бегины с фигурными скобками глаза беленой не застилают : классовые методы, классовые объекты, свойства, интерфейсы. Это вообще единая тенденция для языков, "захваченных" одной компанией, будь то Borland, Apple или Microsoft. У них похожие пути развития, но отличные от таких языков, как C++, Ada и Eiffel.

Далее, Паскаль обсирается любителями C++, но не из-за begin-end'овой неТрушности, а из-за реального превосходства по возможностям, как то параметризация (вроде наконец появившаяся в D2007 ?) и стандартизованность (перегрузка операторов в FPC и D2006 очень отличается; в FPC она аналогична C++ и исторически появилась раньше, а в D2006 она аналогична Delphi.NET). В отличие от предыдущего пункта, этот номер с Адой не пройдёт, ибо Ада стоит по другую сторону C++ в соотношении возможностей :

Pascal < C++ < Ada

Когда Паскаль и Аду вот так группируют, кажется, что они рядом. Но на самом деле между ними такая пропасть, что достаточно места для C++ в промежутке, так что не стоит их группировать вообще. Только словами бросаться.

Наконец, есть гуру-Лисперы. Они, конечно, могут тоже сказануть чё-нить. Поскольку Лисп -- язык не системный, а Ада как системный язык очень хороша, лучше неё ещё в этом плане ничего не придумано, это свойство тоже стоит того, чтобы его ценить. Моя позиция по этому вопросу проста : "Better together!!!!!". Всё равно в те или иные продукты приходится встраивать скрипты. А если и не приходится, будет не лишним. Пусть лучше это будет Лисп, чем Питон. С Адой и Лиспом такое обстоятельство, что их открытие для себя люди характеризуют как нечто светлое, навсегда меняющее. "Welcome to enlightment" -- говорят про Аду. "Lisp is a red pill" -- говорят про Лисп. Фишка в том, что первые и вторые редко сочетаются в одном человеке, помимо того, что сами редко встречаются среди разработчиков. Возможно, нужно быть больше инженером, чтобы понять подвиг создателей Ады. Или больше программистом, чтобы понять превосходство Lisp. Реальные продукты требуют и того, и другого, так что хотелось бы видеть побольше на этой замечательной спайке.

> А вы какую-нибудь новость про Ada запостите

Собственно, стоит попробовать. Дождусь только появления gprbuild в общем доступе.

> А кто чего про Аду плохого говорил? Конечно язык очень узкий но с контролями такими что Pascal-ю не снилось. Но он же и не общего назначения, а Pascal общего.

И в каком месте Ада уже Паскаля? И с каких это пор Ада не общего назначения? Уж пообщее Паскаля наверное, если на одном и том же языке и Боинги летают, и мини-игры для Linux делаются.

> А чего там, под Адой удобно писать? Вот меня он напряг - испугался, много БУКВ. Вот в C++0x тоже будут программные потоки.

А всё остальное? Тоже будет, да? Ну-ну. Программных потоков в C++ дождались, фича 20летней давности.

В C++ при проектировании было заложено много необратимых решений, которые затем ведут к излишнему усложнению языка. В рамках C++ отказаться от них невозможно. А иногда возможно, но разработчикам влом. Ну, например, в Objective-C есть #pragma import, которая работает как #include, но не включает один и тот же .h более одного раза. Мелочь, которая делает язык ну чуть почище. И ведь в реализации-то несложная. (И даже в реализованном виде имеется -- Objective-C++) Но ведь не приняли же! Чего уж говорить о более серьёзных изменениях. C++ -- это корабль, с которого бегут крысы.

Так что вместо C++03=>C++0x нужно настраиваться на C++03=>Ada05.

> PS: на дельфи можно совершенно спокойно написать kernel mode driver.

А на Аде, которая местами ещё строже, их и пишут. Для WindRiver Realtime OS (потомок BSD). И модули ядра, и на голом железе.

>То есть MSVC++ не поддерживает стандарт языка?

Да, по ходу MS опять изобретает свои стандарты... Только, ИМХО, товарищ ошибается. Я, правда, на MSVC++ последний раз на 4.0 программировал, но тогда он работал совершенно по стандарту. Присвоение int'ов char'ам без кастинга - это очень, очень распространённое явление:

char c = fgetc(FILE);

Я сомневаюсь, чтобы в MS вдруг отказались от подобных конструкций, которыми пользуется туева хуча софта :)

>>Ну тут получается необычная ситуация - код для MSVC++ будет собираться GCC, поскольку ГЦЦ проглотит явный кастинг к примеру int->short, а гцц-шный код не будет принят МСВЦ++ поскольку "This conversion requires explicit cast".

>То есть MSVC++ не поддерживает стандарт языка?

Проектом MSVC++ руководит Герб Саттер, который является главным секретарем комитета ANSI/ISO по стандартизации и автором нескольких серьезных книжек по С/C++. В данном случае - по поводу неоходимости явного кастинга в ряду long long->long->int->short->char и double->float->any integer type я с MSVC++ полностью согласен.

>Присвоение int'ов char'ам без кастинга - это очень, очень распространённое явление: char c = fgetc(FILE);

На MSVC++ 8.0 нету даже неявной конверсии size_t->unsigned long при 32-битовой(!) компиляции.

> На MSVC++ 8.0 нету даже неявной конверсии size_t->unsigned long при 32-битовой(!) компиляции.

Выдумывать новые (мс-)стандарты как-то нехорошо, лучше б ограничились выдачей варнингов, как было в 7.х.

>> На MSVC++ 8.0 нету даже неявной конверсии size_t->unsigned long при 32-битовой(!) компиляции.

>Выдумывать новые (мс-)стандарты как-то нехорошо, лучше б ограничились выдачей варнингов, как было в 7.х.

Это что, как-то повлияет на возможность сборки MSVC - кода на gcc? По-моему нет, если использовать кроссплатформенные библиотеки то портируется без особых проблем. С другой стороны, Hardcore C++ такой как Loki и Blitz++ MSVC 7.1/8.0 тоже замечательно собирается.

>>> На MSVC++ 8.0 нету даже неявной конверсии size_t->unsigned long при 32-битовой(!) компиляции.

>> Выдумывать новые (мс-)стандарты как-то нехорошо, лучше б ограничились выдачей варнингов, как было в 7.х.

> Это что, как-то повлияет на возможность сборки MSVC - кода на gcc?

А что будет со сборкой под msvc не совсем профессионального кода, оттестированного под gcc? Помнится socket++ у меня на студии так и не собрался...

>На MSVC++ 8.0 нету даже неявной конверсии size_t->unsigned long при 32-битовой(!) компиляции.

То есть, если я правильно понимаю, то на MSVC++ 8.0 не будут собираться программы, традиционно использующие <stdio.h>? Ведь там в подавляющем большинстве примеров и, как следствие, кода кучи софта происходит именно присвоение char c = fgetc(fh);

...

Всё равно не верю :D