Я имел в виду не фигурные скобки (они действительно ничем не хуже begin...end), а круглые в предложениях вида void (*fun_ptr)(int) = &fun. Их обилие напрямую связано с отсутствием ключевых слов для вида объявляемого идентификатора.
Соглашусь, в этом есть какое-то коварство. И если бы дело ограничивалось только Read и Write, было бы не так тяжко. Но таких процедур оказываются десятки. Конечно, хотелось бы видеть грамматику Паскаля сразу достаточно гибкой для того, чтобы списки аргументов Read и Write укладывались в эту грамматику и не торчали бы неудобными исключениями.
Коллега, я призываю не торопиться с выводами. На той кафедре, о которой идёт речь (а это вовсе не моя родная кафедра и курс веду не я), сейчас для некоторых лабораторных работ используются компиляторы Паскаля P5 и BeRo Tiny Pascal. Речь там вовсе не идёт о каких-то образцах для подражания. Студентам предлагается всего лишь вносить точечные изменения в готовый компилятор и наблюдать их эффект после «раскрутки» (bootstrap'а). Кто-то из студентов на курсовой может заняться и более масштабной задачей (например, была работа по портированию BeRo на Linux). Подробнее об этом можно прочесть тут. Там есть и примеры заданий. Если вы видите какие-либо недостатки XD Pascal в сравнении с BeRo, я с интересом вас выслушаю.
Вы отчего-то не задались вопросом, как именно построен учебный процесс и как именно предполагается применять компилятор, и почему-то спешите предложить компилятор C вместо Паскаля и, кажется, даже без самокомпиляции. Далее, вы неизвестно почему видите недостаток в том, что «для самых употребительных процедур, в том числе Read и Write, я сделал исключение и реализовал их нетипичными для грамматики языка». Однако эти процедуры в Паскале действительно нетипичны для грамматики (принимают любое количество любых аргументов) и действительно требуют реализации как особого случая, что я и сделал. Упрекать же за отсутствие поддержки множеств в любительском компиляторе, ей-богу, чрезмерно.
Увы, со многим вынужден согласиться. Однако вы говорите скорее о состоянии индустрии, чем о достоинствах языков как таковых. Я не думаю, что индустрия несёт высшую справедливость и всегда воздаёт языкам по их достоинствам. Тот же Паскаль сам по себе не имеет никаких неисправимых пороков, которые помешали бы ему при должном развитии сравняться по мощи с современным С++. Но для этого была бы нужна воля корпораций — не только сейчас, но и в прошлом. Стоило Паскалю в 80-х годах чуть опоздать с возможностями системного программирования, и вот уже все ключевые операционные системы написаны на C, а Паскаль вынужден вечно догонять.
Нет, не пробовал. Знаю только, что мой компилятор для DOS какие-то поляки портировали на Atari с процессором 6502. Сам немножко работал с Паскалем для 8051, но быстро забросил. Если уж такой компилятор и делать, то уже не игрушечный, а тогда придётся использовать LEX/YACC/ANTLR/LLVM и т.д.
Вряд ли по кругу, в лучшем случае — по спирали. Язык B был бестиповым в абсолютном смысле: любая переменная была целочисленным «машинным словом», и более ничем. Язык был как-то пригоден только для системного программирования. Никакие численные расчёты были на нём невозможны.
А какие возможности вы хотели бы видеть? Если мне не изменяет память, в Turbo Pascal была только процедура Sound, управляющая PC Speaker'ом. Если вам нужен именно он, то можете управлять им напрямую путём записи в системные порты. Для этого в XD Pascal, как и в Turbo Pascal, есть процедура OutP.
Думаю, не стоит винить C во всех бедах отрасли. В нём, безусловно, были прогрессивные черты (типа операции += или возможности передать в функцию массив произвольной длины, чего не было в Паскале). Однако C вырос из бестипового B, и отпечатки этого, к сожалению, видны до сих пор.
Возможно, все эти нововведения действительно нужны. Когда заходит речь о конкуренции в сфере профессионального программирования, приходится, видимо, поступаться простотой компилятора. Иначе, не имея всего перечисленного вами, Паскаль навсегда останется слабее С++ или чего-то подобного. Будет ли ваш язык «не совсем» Паскалем? Не знаю. Однако Бейсик до сих пор жив только потому, что он «не совсем» прежний Бейсик. Да даже и Delphi — это «не совсем» Паскаль от Никлауса Вирта. Язык должен эволюционировать — иначе он умирает. Паскаль, увы, оказался не в самых заботливых руках после смерти Borland.
Согласен. В обучении программированию первенство Паскаля может оспорить разве что Питон. Но здесь есть коварный вопрос: стоит ли сразу ставить ученика перед необходимостью объявлять переменные? Мой опыт программирования начинался с Бейсика, и переход к языкам с явной статической типизацией был мучителен. Есть риск, что с тем же столкнутся и взращенные на Питоне. К тому же, Питон местами совсем не очевиден. Как объяснить начинающему хитрости передачи аргументов в функцию? Как задать большой двумерный массив?
Да, это так. Однако в первых вариантах C такой возможности не было, она появилась позже. Ничто не мешает развивать в том же направлении Паскаль. Есть хороший пример Паскаля, в котором переменные объявляются именно там, где они нужны.
Совершенно верно, увлечён. Считаю, что это очень гармонично спроектированный, лёгкий для чтения и удобный для компиляции язык. Да, у раннего Паскаля было слишком много ограничений по сравнению с C, о чём красноречиво писал Керниган. Из-за этого, видимо, C сразу получил фору.
Однако Паскаль, как и всякий язык, требовалось развивать. Компания Borland внесла здесь огромный вклад, и уже в ранних Turbo Pascal все недостатки, описанные Керниганом, были устранены. Но, фактически став детищем Borland, Паскаль вместе с этой корпорацией и умер (увы, судьба языков слишком зависит от судьбы корпораций).
В результате чуть не половина языков из «первой десятки» тащат за собой наследие C, пытаясь с ним совладать. Вот, нам мой взгляд, недостатки C, которые так или иначе просвечивают и в его потомках и которые совершенно чужды Паскалю:
Отсутствие ключевых слов, обозначающих вид объявляемого идентификатора: function, var, type и т.д. Из-за этого начинается нездоровая игра со скобками, а читаемость программы резко ухудшается.
Сильная зависимость от препроцессора. Без него невозможно подключить внешний модуль или задать подлинную константу, не занимающую памяти.
Провалившаяся попытка отождествить массивы и указатели. Насколько я понимаю, сначала разработчики языка надеялись на полное отождествление. Однако как только пришлось допустить массивы в качестве полей структуры, тождество стало фикцией. В результате для двумерного массива A все величины A, &A, *A, A[0], &A[0] равны друг другу. Не абсурд ли это?
Неудобный оператор switch. Это вынужден был признать ещё Керниган.
Параллельное существование у структур «имени типа» и «тега типа». Как такое могло появиться, я вообще не представляю.
Я понимаю, что от многих этих недостатков пытаются уйти — если не в C++, то в каком-нибудь Go. Однако здесь мне остаётся присоединиться к одному меткому комментарию на Хабре:
Не понимаю, зачем индустрия хоронит Паскаль, а потом много раз изобретает его заново.
Слышал о ней. Милая вещица, как и её родной ассемблер FASM. Но уход от DOS мне был нужен не ради самого ухода, а ради того, чтобы хоть кому-то можно было показать работу откомпилированных программ. А KolibriOS пришлось бы прикладывать как довесок к каждой программе :)
Рад встретить союзника. Наработки где-нибудь выкладывали? Кстати, я присматривался и к Оберону, но смутило несколько обстоятельств: 1) он слишком мало распространён, для него не найти ни примеров, ни тестов, ни желающих в нём разбираться; 2) он слишком лаконичен (спасибо и за то, что вернули цикл FOR!); 3) ключевые слова непременно в верхнем регистре — ужасны.
Боюсь, у Embarcadero нет никакого подхода, кроме выжимания последних капель из плодов Borland, некогда очень сочных. Там не станут бороться с «маркетоидным мусором». Кроме этого мусора, ничего своего у них нет. Мне искренне жаль Borland. История их погибели стоила бы пера Шекспира.
Тогда предлагаю признать, что пример с Mars Climate Orbiter действительно крайне неудачный — хотя бы потому, что полностью вымышленный и притянутый за уши. Как следует из отчёта об аварии, две части ПО, между которыми возник конфликт единиц измерения, работали совершенно независимо на разных машинах и обменивались данными через файл. Так что костыли, предложенные автором, здесь неуместны.
Однако СИ навязали директивно во всём мире, кроме США и Мьянмы (странное соседство). Даже Англия ушла от футов и фунтов. А Австралия так намучилась с имперскими единицами, что теперь вообще ни в чём не отступает от СИ: мощность автомобилей у них в киловаттах, калорийность в килоджоулях, атмосферное давление в гектопаскалях.
Исправьте перевод: «фунт-сила-секунда», а не «фунт-сила в секунду»; «ньютон-секунда», а не «ньютон в секунду». В этих единицах измерения используется умножение, а не деление (ср. оригинал, где нет слова per).
По существу рассматриваемого случая: удивительно, насколько автор сосредоточен на громоздких программных костылях, однако ни слова не говорит о радикальном, очевидном и давно известном решении — повсеместном переходе на систему единиц СИ.
Как таковая, навигация комбайна по полю действительно намного проще, чем позволил бы автопилот Tesla — хотя бы потому, что в поле, в отличие от города, достаточно лишь GNSS+IMU и нет активного дорожного движения. Однако система обнаружения препятствий всё же нужна, и фактически она оказывается столь же сложной, сколь и для города. Весь вопрос в том, сколько девяток в показателе надёжности нам достаточно.
Что касается успехов Tesla, то они, без сомнения, огромны, но и тут нужно блюсти осторожность: последние громкие заявления о скором выходе автопилота «на улицы» были приурочены к «дню инвестора», проводимого в не самых радужных экономических обстоятельствах. Сам формат мероприятия требует повышенного градуса оптимизма докладчиков.
begin...end), а круглые в предложениях видаvoid (*fun_ptr)(int) = &fun. Их обилие напрямую связано с отсутствием ключевых слов для вида объявляемого идентификатора.ReadиWrite, было бы не так тяжко. Но таких процедур оказываются десятки. Конечно, хотелось бы видеть грамматику Паскаля сразу достаточно гибкой для того, чтобы списки аргументовReadиWriteукладывались в эту грамматику и не торчали бы неудобными исключениями.Вы отчего-то не задались вопросом, как именно построен учебный процесс и как именно предполагается применять компилятор, и почему-то спешите предложить компилятор C вместо Паскаля и, кажется, даже без самокомпиляции. Далее, вы неизвестно почему видите недостаток в том, что «для самых употребительных процедур, в том числе
ReadиWrite, я сделал исключение и реализовал их нетипичными для грамматики языка». Однако эти процедуры в Паскале действительно нетипичны для грамматики (принимают любое количество любых аргументов) и действительно требуют реализации как особого случая, что я и сделал. Упрекать же за отсутствие поддержки множеств в любительском компиляторе, ей-богу, чрезмерно.В общем, извините, я не принимаю ваших доводов.
Sound, управляющая PC Speaker'ом. Если вам нужен именно он, то можете управлять им напрямую путём записи в системные порты. Для этого в XD Pascal, как и в Turbo Pascal, есть процедураOutP.+=или возможности передать в функцию массив произвольной длины, чего не было в Паскале). Однако C вырос из бестипового B, и отпечатки этого, к сожалению, видны до сих пор.Однако Паскаль, как и всякий язык, требовалось развивать. Компания Borland внесла здесь огромный вклад, и уже в ранних Turbo Pascal все недостатки, описанные Керниганом, были устранены. Но, фактически став детищем Borland, Паскаль вместе с этой корпорацией и умер (увы, судьба языков слишком зависит от судьбы корпораций).
В результате чуть не половина языков из «первой десятки» тащат за собой наследие C, пытаясь с ним совладать. Вот, нам мой взгляд, недостатки C, которые так или иначе просвечивают и в его потомках и которые совершенно чужды Паскалю:
function,var,typeи т.д. Из-за этого начинается нездоровая игра со скобками, а читаемость программы резко ухудшается.Aвсе величиныA,&A,*A,A[0],&A[0]равны друг другу. Не абсурд ли это?switch. Это вынужден был признать ещё Керниган.Я понимаю, что от многих этих недостатков пытаются уйти — если не в C++, то в каком-нибудь Go. Однако здесь мне остаётся присоединиться к одному меткому комментарию на Хабре:
По существу рассматриваемого случая: удивительно, насколько автор сосредоточен на громоздких программных костылях, однако ни слова не говорит о радикальном, очевидном и давно известном решении — повсеместном переходе на систему единиц СИ.
Что касается успехов Tesla, то они, без сомнения, огромны, но и тут нужно блюсти осторожность: последние громкие заявления о скором выходе автопилота «на улицы» были приурочены к «дню инвестора», проводимого в не самых радужных экономических обстоятельствах. Сам формат мероприятия требует повышенного градуса оптимизма докладчиков.