Программируете ли вы на Паскале?

Чем тебе моя аватарка-то не угодила, организм? Между прочим, это авторская картинка от широко известного в узких кругах художника, которую он нарисовал лично для меня %)

Господи, буквально диагнозы по аватарке. Просто дно дна.

Не-а. Я дал свое примерное определение «мертвому языку» в плане программирования. Клоуну выше оно не понравилось. Я сказал, что он может считать как угодно, но у него сгорела жопа, и он стал ссылаться на словари.

Еще раз, кратко:

• Мое собственное определение из головы (не претендующее на истину, так-то)
• vs словарное определение для другой области.

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

Раст и Го взяли порядок слов в определении переменных из Паскаля, а не из Си. Это - толстый намёк на то, что разработчики Си просто ошиблись, когда создавали свой язык. Одного этого факта достаточно, чтобы студенты учили Паскаль, а не только плюсы.

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

Между прочим, это авторская картинка от широко известного в узких кругах художника, которую он нарисовал лично для меня

счастливец, узнаю кисть Матвея Говядина!

https://www.youtube.com/watch?v=7qrQP2B10iw

Это мешает читать Си на каждом шагу.

Кому мешает? Я хорошо С читаю, и всегда считал что у него потрясающий синтаксис, у С++ тоже очень неплохой.

Паскаль вот мне совсем не нравится, например тем что непонятно в if где ставить ;, или например такими приколами, валидный код:

b := ++a;

Считаю что его синтаксис очень сложен, у Go не лучше, есть где то есть var, где то нету, модули очень непонятно устроены, синтаксис методов и генериков так себе.

У синтаксиса С лишь один недостаток, в объявлении указателей, но не просто указателей, там все понятно, а в объявлении указателей на функции, и массивы. Но это обходится typedef. В С++ можно просто использовать std::function.

Ну я так и знал, что найдутся те, кто считает себя умнее меня, и вот соответственно, для них синтаксис Си прекрасен. Объективно, синтаксис Си читается из середины. Да, для случаев указателей и массивов, а что, их нет в программах? Когда-то меня тоже это забавляло. Читаешь код и для разминки ума всё время решаешь маленькие головоломки. Но на самом-то деле денег платят не за решение головоломок, а за решение «бизнес-задач», ну или «боевых задач», в зависимости от сезона человеческих страстей. Да, образовалась жирная прослойка решателей головоломок, которые научились получать деньги за чтение Си. Но на самом-то деле, пока ты решаешь головоломки, контекст решаемой задачи выпадает из головы, а в голове регистров мало и стираются они быстро. Поэтому тот, кто читает Си, при прочих равных должен быть тупее того, кто читает Паскаль, если они на самом деле изначально одинаково умны. У Паскаля, правда, begin..end в другом месте грабли подставляют - пока паскалист прочитает один begin, сишник прочитает уже пять фигурных скобок, ну или хотя бы две.

Но это обходится typedef

Когда ты сам пишешь - да. Когда читаешь чужой код - как повезёт.

Второй объективный недостаток Си - это то, что исходный текст программы нельзя прочитать. Он возникает только в момент компиляции и его надо уловить. Даже bear не улавливает ключи -D и не показывает их в среде разработки. Даже АК-ВС не улавливает. Всякие *tags, которые мне N лет назад тут советовали - вообще работают, если повезёт. Т.е. сидишь ты такой, лазаешь по модулям ядра линукса, и не знаешь, что означает вот это вот слово. И можно потратить немало времени, чтобы разобраться (я даже не знаю, как это вообще возможно сделать без bear - не разбирать же все Makefile по всему пути глазами?).

Это просто невообразимое дерьмище. На этом фоне Паскаль - просто сияет, как Солнце. Да что там Паскаль, я бы сказал, что даже JavaScript на этом фоне смотрится довольно бодро.

Поскольку из плюсов этот кошмар недовыкинули, это относится и к плюсам, но, может быть, меньше применяется. Поскольку я почти не читаю код на плюсах, я не в курсе. Однако #include там точно присутствует в товарных количествах.

Да, для случаев указателей и массивов, а что, их нет в программах?

Часто видишь указатели на функции которые принимают указатели на функции? Или динамическое выделение VLA массивов? Я нет. Обычно если указатель на функцию выступает в виде типа, то его делают через typedef, и все хорошо смотрится. В последний раз видел по моему в https://man7.org/linux/man-pages/man2/signal.2.html

Но на самом-то деле, пока ты решаешь головоломки

У Си очень читаемый синтаксис.

И можно потратить немало времени, чтобы разобраться

Скачай CLion, переход на определение Ctrl+B

На этом фоне Паскаль - просто сияет, как Солнце.

В паскале тоже есть препроцессор.

Да что там Паскаль, я бы сказал, что даже JavaScript на этом фоне смотрится довольно бодро.

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

Ну я так и знал, что найдутся те, кто считает себя умнее меня

Ты, видимо, считаешь себя каким-то гением, но это, очевидно, не так.

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

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

Второй объективный недостаток Си - это то, что исходный текст программы нельзя прочитать… Это просто невообразимое дерьмище. На этом фоне Паскаль - просто сияет, как Солнце.

Мне нравится, как ты сваливаешь всё в одну кучу и умалчиваешь о неудобных фактах. Начнем с того, что кодогенерация в Си существует не от хорошей жизни. Она решает проблему определения повторяющихся функций для разных типов (пресловутые min() и max(), например), и когда по нуждам какого-нибудь системного программирования требуется выполнить ряд повторяющихся действий с бойлерплейтами, которые не вынесешь в отдельную функцию. Например, вызвать с десяток чуть-чуть отличающихся ioctl() с одним if/goto error при ошибке.

Вообще, прежде чем начинать свое словоблудие, тебе стоило уточнить, о каком паскале идет речь. Потому что классический виртовский паскаль страдает от тех же проблем, что и Си, и решение для них там ровно то же самое - использовать сишный препроцессор с паскалем, лол. А вот во Free Pascal уже завезли собственный препроцессор со своим синтаксисом макросов, так что упс, теперь у нас и тут есть кодогенерация. При этом туда завезли еще и дженерики, так что это уже далеко не тот же самый виртовский паскаль.

Видишь, в чем проблема? Как только на языке начинают решать реальные задачи - он сразу обрастает кодогенерацией и прочими неприятными, но необходимыми вещами. Просто Си был изначально создан, как язык для системного программирования, а паскаль к этому пришлось адаптировать, без внятных преимуществ последнего. Что же касается плюсов, то там макросы не «недоотломали», а оставили для совместимости с сями, и для того, чтобы можно было использовать кодогенерацию при необходимости.

Паскаль вот мне совсем не нравится, например тем что непонятно в if где ставить ;, или например такими приколами, валидный код:

b := ++a;

А почему такой код должен быть невалидным? Возьмём, например -1 - всем понятно, минус 1, унарный минус. +1 - аналогично, хотя + можно было бы опустить - он просто ничего не делает.

• -1 - тоже можно, математически это -(-1) Точно также - -a. Равно и ++a - два раза показать, что выполняется унарный плюс. Который ничего не делает. Ну, чтобы до особо непонимающих (что?) дошло. Т.е., математически +(+a). Так тоже можно, НО ЗАЧЕМ? А то, что это ++ в С-подобных языках означает какой-то там инкремент - это проблема С-подобных языков и мозгов, ими испорченных. Или исправленных. В Паскале «++» не имеет подобного смысла даже близко. Там и if (a=0) then… можно делать без задней мысли, что а чему-то там присвоится - другой синтаксис. Так что можно и +a, и ++a, и даже +++a - всё валидно, и всё равно a.

Там и if (a=0) then… можно делать без задней мысли

Нельзя, -Werror не пропустит.

У синтаксиса С лишь один недостаток, в объявлении указателей, но не просто указателей, там все понятно, а в объявлении указателей на функции, и массивы.

C - язык с претензией на некоторую низкоуровневость. Ну, не ассемблер, конечно, но всё как в системе. А в системе память выделяют по определённому адресу. То есть, по указателю. И дальше этими указателями все живём. Или кое-что, по мелочи, можно определить статически. Кстати, в TP6-BP7 такое тоже начиналось, но начиная с первой Delphi решили, что засилие указателей - это в Паскале некрасиво, и перешли к «скрытым указателям», постепенно, кстати. Сначала классы, потом длинные строки, потом динамические массивы. По сути всё это указатели, но высокоуровневый язык работает с ними как будто бы и не совсем. Хотя в классах просто не надо писать ^, а во всём остальном - указатели, а вот строки уже отслеживаются.

-Werror в Паскале нет и не надо. В С есть, и может помочь от совсем тупых ошибок, но… Может периодически мешать компилировать код, в котором какую-то мелочёвку специально оставили «грязной» (но формально возможной), чтобы потом доделать. Ну и обилие ключей компиляции на все случаи жизни - не есть плюс.

Скачай CLion, переход на определение Ctrl+B

Оно не может быть правильным из-за -I и -D в командной строке компилятора, которые можно увидеть только при запуске сборочного скрипта, который может быть произвольным. Если проект создан в самом CLion, то возможно, что там как-то по-другому. Но мы не живём в мире, где все проекты созданы в CLion.

В паскале тоже есть препроцессор. Он там беднее и реже используется. В частности, он не используется для имитации модульности. Там uses, а у Сей в этом месте #include. Хотя ЕМНИП и там могут быть грабли из-за разной настройки директорий в среде и при сборке. Т.е. да, качественно там эта проблема в каком-то виде есть, а количественно я с ней никогда не сталкивался, в отличие от.

-Werror в Паскале нет и не надо.

{$WARN no_retval ERROR}

function noresult(): integer;
begin
end;

begin
  noresult;
end.                                    

Оно не может быть правильным из-за -I и -D в командной строке компилятора, которые можно увидеть только при запуске сборочного скрипта, который может быть произвольным.

Ну да, IDE его распознает, если там реально шелскрипт а не CMakeLists.txt, то она подменит ему компилятор, и узнает реальные флаги. А если CMakeLists.txt, то все автоматически импортнется как только папку откроешь.

Если проект создан в самом CLion, то возможно, что там как-то по-другому.

По моему CLion вообще не умеет создавать проекты, сейчас даже Visual Studio работает с CMake.

У Си очень читаемый синтаксис.

если всё так здорово, почему эту прекрасную идею построения синтаксиса определений не взяли ни в Rust, ни в Go, ни в Zig, ни в Kotlin? Как минимум 5 против одного считают, что синтаксис Си не такой уж и читаемый. Причём я-то ладно, моё мнение никого не интересует, а вот с остальными будет посложнее.

если всё так здорово, почему эту прекрасную идею построения синтаксиса определений не взяли ни в Rust, ни в Go, ни в Zig, ни в Kotlin?

Потому что это труднее реализуется, но если посмотреть на топ языков, то мы увидим Java, C#, C/C++. Непонятно зачем ты какую то маргинальщину приводишь в пример. Go, Kotlin - нормальные примеры, но в разработке Go принимал участие какой то паскалист.

Ну можно ещё набросать языков: VHDL, Transact-SQL, Pl/pgsql, Basic, Julia, Python. Ко всем к ним это относится в разной мере, где-то нет звёздочки, где-то я типов не нашёл. Почему столько разработчиков языков уклоняются от использования столь читаемого синтаксиса?

Да, и нужно учесть ещё годы их возникновения. В новых языках так не делают. И даже Котлин пошёл поперёк папочки.

А почему C#, Perl, Java, C, C++, D, Basic, Python, Scratch, Fortran, Cobol, Metaprog, Brainfuck отклоняются от идеального синтаксиса паскаля?

Metaprog

Перетолстил.

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

И эта фигня с невозможностью прочитать код - тоже имеет значение.

Я даже ещё не вспоминал про скорость компиляции. Дельфи просто с неимоверной скоростью компилирует, по сравнению даже с Qt.

Чем тебе Python не нормальный? Один из наиболее популярных языков в мире.

{$WARN no_retval ERROR}

Да, но это не -Werror. Некоторый аналог, но пишется-то по-другому. И да, не так нужно. Вот пример с отсутствием выходного значения. Пока программа дорабатывается, это может быть нормой, это уже на окончательной сборке надо.

Ничего это не труднее реализуется на фоне остального в компиляторе. Просто это не даёт никаких преимуществ, зато даёт недостатки. Т.е. это не нужно реализовывать, и создатели языков это понимают. Вот можешь сформулировать, чем порядок частей определения в Сях лучше, чем в Паскале? Каковы преимущества?

но в разработке Go принимал участие какой то паскалист

Ну из этого же не следует, что всё, взятое из Паскаля само по себе, без паскалистов, нежизнеспособно. Т.е. неясно, к чему этот аргумент вообще. Так посмотреть, Вирт везде своих агентов заслал. Почти везде.

Паскаль учебный язык, там вымораживают длинные слова procedure, function, begin. Да, к ним тоже можно привыкнуть, но они занимают место на экране зря. Да и сократить pointer до * выглядит почти не дурной идеей, когда оно не начинает с умножением конфликтовать. В голанге так и сделали. var a *int в Паскале писалось бы как var a: pointer to int. Паскаль всё же учебный язык, слишком многословный для проф. применения. Однако за счёт остальных качеств вполне себе вынес Си/++ из множества применений. В голанге синтаксис ужали до разумного предела и вроде бы не дальше, во всяком случае, лично я на грабли синтаксиса там ни разу не наступил, в отличие от того же Питона.

Наверное тем кто аппаратные фиговины проектирует надо. А так нет.

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

Бред, это не так работает вообще. Скажем есть LaTeX, у которого синтаксис жуткий по сравнению с сями. Но после 10 лет работы ты его читаешь не напрягаясь.

насколько хорошо учить студентов только дерьмовому языку, а не учить альтернативным? Ведь текущая рыночная коньюнктура - это не истина, а лишь преходящее.

Потому что эти студенты будут работать на плюсах а не на расте/обероне. ЯП это инструмент, освоение ЯП это самый простой этап.ю профессии числодробильщика. Если они захотят то сами, джаст-фор-фан, выучат любой другой ЯП. Какой смысл переводчиков с английского на русский учить санскоиту или хинди? С кем они будут говорить потом, если вокруг ни одного индуса? Я это раз дцать повторил, но Вы не слышите…:-(

Синтаксис плюсов является большой проблемой только в Вашем воспаленном воображении. Это видимо последствия ушиба отладчиком… Аппеляции типа - а вот в других ЯП по другому - бред. Я когда свой ЯП в молодости клепал взял вместо {} <>. И чего? А вот в Cuda и шарпах бол-мен сишный синтаксис.

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

Нет, здесь был разговор что фортран убьёт плюсы, а фортран это уже про HPC. И я не возьмусь обсуждать ЯП в контексте написания веббраузеров/СУБД/… - я там не специалист.

Ты уже написал, что можно считать плюсы умирающими ввиду произвольности понятия «мёртвый»

Я такого не писал, опять фантазируете.

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

Зато быстрый с т.з. разработки. Вообще читая Ваш поток сознания возникает вопрос - как с такой кашей в голове Вы работаете программистом?! Это ж редчайшая девиация, ТАК путать приоритеты и смещать акценты. Всё равно что при выборе авто делать основной акцент на цвете и считать себя автогонщиком при этом…

Сколько в общем объёме вычислений в мире приходится на HPC? 1-2% поди, на фоне тотального доминирования расчётов в специализированных средах вроде Matlab или R. А студенты после ВУЗа в большинстве своём пойдут не климатические модели обсчитывать, а заниматься какой-нибудь бизнес-аналитикой в Экселе. Так что я бы с такой категоричностью поосторожнее был. Мир сильно больше, чем Ваша отдельно взятая физическая кафедра.

как с такой кашей в голове Вы работаете программистом?!

Никак. Видно же, что он такой же диванный теоретик, как столяров. Иначе бы он понимал, зачем в сишке нужны макросы.

Ответа от него, как я понимаю, не будет, скорее всего поц отправил меня в игнор за НЕПРИЯТНОЕ.

Потому что эти студенты будут работать на плюсах

Бедные студенты. За что.

непонятно в if где ставить ;

Не нужно же,
точку с запятой, как в обычном человеческом языке, можно будет поставить в конце, завершив условный оператор. А иногда и не ставят вообще (перед else или end).

b := ++a;

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

Сколько в общем объёме вычислений в мире приходится на HPC?

Если по флопсам считать то сильно больше чем 1-2%, точно не скажу. Если по значимости то ещё больше - компутер/телефон с которого Вы пишете, электростанция вырабатывается ток, бензин в автомобиле и тд и тп - почти все что Вас окружает без HPC не было бы сделано.

на фоне тотального доминирования расчётов в специализированных средах вроде Matlab или R.

С чего Вы взяли?! На матлабе и R работают некоторые экспериментаторы и всякие социологи. Тотально доминируют расчеты в КБ/НИИ, и считают там на специализированных мультифмзичных программных комплексах которые сделаны именно на плюсах. Интерфейс пиотновский или свои гуй/DSL.

Мир сильно больше, чем Ваша отдельно взятая физическая кафедра.

Мир сильно больше чем та куцая картинка с матлабом/R которая у Вас в голове.

Почему бедные?! У студентов на всю жизнь появится высокооплачиваемое хобби и им ни дня не придётся работать в обычном понимании этого слова. Они, да простят меня верующие, уподобяься богам:-) Правда порог вхождения высокий, далеко не все справляются - но не плюсы тому виной…

В голанге так и сделали. var a *int в Паскале писалось бы как var a: pointer to int.

А писалось так:

var a: ↑ integer;

сократить pointer до * выглядит почти не дурной идеей, когда оно не начинает с умножением конфликтовать.

Использовать * для умножения – перфокарточная фортрановско-айбиэмовская привычка. Бухгалтерские машины 1950-1960-х не умели печатать обычные математические символы.

тем кто аппаратные фиговины проектирует надо

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

мы увидим Java, C#, C/C++.

А в современном с++ ( который не C/C++ из 1990-х ), можем увидеть что-то подобное:

#include <vector>

auto get_Vector() -> std::vector<std::vector<double>>
{
    return {};
}

Очень редко, исчезающе редко я бы сказал. В пересчёте на флопсы ПЛИС гораздо дороже обычного железа, а граф.ускорители дешевле, поэтому сейчас упор на GPU скорее.

ПЛИС юзают иногда там где важны системы реального времени, но это отдельный мир.

но в разработке Go принимал участие какой то паскалист.

«Какой-то паскалист» - это случайно не Брайан Керниган или Роб Пайк? :)

если посмотреть на топ языков, то мы увидим Java, C#, C/C++

Если посмотреть на топ TIOBE, то на первом месте мы увидим Python, в котором используются тайп хинты в стиле Паскаля. В питоне тип пишется после переменной, а не шиворот-навыворот, как в сишке.

def greeting(name: str) -> str:
    return 'Hello ' + name

Кроме уже упомянутых Rust, Go, Zig, Kotlin такой синтаксис объявления переменных используется в Swift и TypeScript. Ну то есть в ключевых мейнстримных языках, разработанных уже после 2000 года. Есть мнение, что именно новое поколение языков будет определять вектор развития последующих, а не древний хлам из 70-х.

Противоестественный сишный синтаксис объявления переменных например приводит к хорошо известным неоднозначностям в крестах:

template<class T> void f() { T::x * p; ... }

Здесь вообще непонятно, что означает T::x * p; - объявление переменной с именем p или умножение T::x на p. Чтобы разрешить эту неоднозначность, надо обмазываться костыльной дрисней typename. Ни в Rust, ни в Go такая неоднозначность невозможна по определению, хотя там тоже используется звездочка для указателей.

А в современном с++ ( который не C/C++ из 1990-х ), можем увидеть что-то подобное:

Кстати да, насколько я помню, разработчикам крестов пришлось костылить альтернативный синтаксис в С++11, когда они уперлись в ограничения ущербного сишного синтаксиса при использовании decltype в шаблонах:

template<typename T, typename U>
auto add(T t, U u) -> decltype(t + u)
{
    return t + u;
}

Если бы с самого начала синтаксис объявления переменных/функций сделали в Паскаль-стайле, а не шиворот-навыворот как в сишке, то таких проблем бы не было.

«Какой-то паскалист» - это случайно не Брайан Керниган

Злостные паскалисты Brian W. Kernighan и P. J. Plauger в своё время написали SOFTWARE TOOLS IN PASCAL.

https://seriouscomputerist.atariverse.com/media/pdf/book/Software%20Tools%20in%20Pascal.pdf

https://www.libex.ru/img/x/27/0f/a63e7.jpg

Ого, не знал. Всегда считал Кернигана злостным хейтером Паскаля, который его никогда толком не использовал. Стало быть, до написания статейки «Why Pascal is Not My Favorite Programming Language» он таки успел поработать с Паскалем.

В первой главе авторы тоже пишут:

Pascal in its pure form has a number of defects that make it hard to write programs well. The worst problem, at least from our perspective, is that the size of an array is part of its type, and so it is not possible to write general-purpose functions and procedures that will process arrays of different sizes at different times.

На момент написания этой книжки это было справедливое замечание.

Pascal, аккуратно cкопипастанный из Цюриха и портированный на BSD в середине 1970-х.

Funktion und Prozedure

https://www.tuhs.org/cgi-bin/utree.pl?file=1BSD/pcs/pascals.p

У студентов на всю жизнь появится высокооплачиваемое хобби и им ни дня не придётся работать в обычном понимании этого слова.

Варианты:
1. Ты капитан, сам определяешь задачи, их программируешь.
Ты выбираешь удобные, подходящие инструменты. С++ ты не выберешь хотя бы потому, что нет времени ждать полдня завершения компиляции.
1.1 Ты ещё не старик, но уже почти не работаешь.

2. Ты наёмник, free lancer. Ты берёшься за любую грязную работу, лишь бы платили, на любом языке, в любой стране. Перекати-поле. Любой язык подойдёт.

3. Ты подневольный работник и делаешь что велят. У тебя дедлайны, отчёты, стрессы и расстройство психики.
3.1 Ты бомж, живущий в подвале, потому что не получилось.

уподобляться богам:-)

Боги программируют мир на своём собственном языке.
Язык, который максимально приближен к естественному, не божественный, но ближе к божественному.
Паскаль - настолько естественен и интуитивно понятен, насколько естественен английский.

Скорее всего, это просто многоточие в литературном смысле (что там должно быть что-то ещё), и этот код не соберётся.

Чорд, ну как же красив код на Паскале (хотя форматирование в приведённом смысле так себе).