Здравствуйте, AVC, Вы писали:

AVC>Вместе с тем, не могу согласиться с выводом автора о семантической идентичности современных языков программирования. (Могу предположить, что и мои оппоненты — поклонники Си++ — также не согласятся с этим выводом, но имея в виду другие особенности языков. )
AVC>Практика же (создание многоязычного компилятора "Странник") по первому впечатлению выглядит "подогнанной" под теорию: судя по информации о компиляторе, из языков просто изымались "необщие" конструкции.

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

AVC>Но это вовсе не лишает эксперимент интереса. Стоит ознакомиться с компилятором поближе.

AVC>Все же, ИМХО, синтаксис Си имеет ряд действительно "плохих" черт: слишком большое число уровней и неочевидность приоритетов операций; легко сделать опечатку (те же грабли = и ==) и т.д.
AVC>В Паскале-подобном синтаксисе (и еще в большей степени в синтаксисе Модулы-2 и Оберона) с этим обстоит значительно лучше.
AVC>Вот Vlad2 утверждает, что и в отношении := можно опечататься.
AVC>Сомневаюсь, чтобы он представил хотя бы один пример, даже "высосанный из пальца".

ИМХО (и не только моё), операции присваивания в этих языках далеки от "человеческого" представления.
Для примера, возьмём записанный словами алгоритм: "Прибавить X к Y и поместить результат в Z".
Как это выглядит сейчас:
Z = X + Y // с точки зрения математика, это уравнение!
Z := X + Y // это можно трактовать как "В Z помещяется сумма X и Y"
Немного не по-русски звучит .
А теперь, сравним с таким:
X + Y => Z
Такая запись в точности соответствует поставленной задаче, кроме того, она читается последовательно слева направо. В классической записи нам приходится "запоминать" куда же сохранится разультат, а потом "вспоминать", когда мы дошли до конца выражения. Следствием этого является и усложнение синтаксического анализатора в компиляторе.

AVC>Вместе с тем, если бы все различие между языками сводилось к особенностям синтаксиса Си и Паскаля, оно не заслуживало бы слишком долгого обсуждения.

На мой взгляд, различия между ними берут истоки в причинах создания. С создавался как развитый компилятор ассемблера PDP. Понять этот язык я смог буквально за пару дней после изучения этого ассемблера; у меня не вызывает удивление наличае операторов ++ и подобного. Паскаль же создавался как отвлечённый от железа язык для обучения — то есть, *как бы* понятный неподготовленному. А теперь риторический вопрос: есть ли разница в мышлении человека и логике работы машины? Что бы понять С, достаточно понять эту машину, а что с Паскалем? На нём же мы не можем использовать обычный человеческий язык, как бы мы не хотели — есть жёсткие рамки того, что язык всё-таки компютерный. И вот в этом месте начинается замкнутый круг: с одной стороны, нужно понимать принципы функционирования машины, с другой — философия языка от этого ограждает. В этом плане языки основанные на виртуальных машинах как бы шаг вперёд — понимать нужно уже эту самую абстрактную машину, что проще. Можно сколько угодно говорить о пользе абстракций, но самое интересное — все эти слова говорят люди прекрасно понимающие, что за абстракциями стоит. Именно поэтому они и могут извлечь из абстракций пользу .

Здравствуйте, AVC, Вы писали:

AVC>

AVC>                                        Си++    Java    Oberon
AVC>Модульность и раздельная компиляция     Нет     Да     Да
AVC>Шаблоны                                 Да      Нет    Нет
AVC>Сборка мусора                           Нет     Да     Да
AVC>Деструкторы                             Да      Нет    Нет
AVC>Объединения (union)                     Да      Нет    Нет
AVC>Многомерные открытые массивы            Нет     Да     Да
AVC>Наследование                            Мн.     Од.    Од.
AVC>Оператор goto                           Да      Нет    Нет

AVC>

AVC>ИМХО, Си++ и близко не ночевал здесь.

Ну во первых, ты сам предложил отвлечься от синтаксических особенностей. Только почему то получилось, что ты отвлекся от тех синтаксических особенностей, которые одинаковы у C++ и Java, но оставил те, по которым они отличаются. Чтобы восстановить справделивость, мы вычеркиваем эти пункты:

                                        Си++    Java    Oberon
Шаблоны                                 Да      Нет Нет
Многомерные открытые массивы            Нет     Да  Да
Оператор goto                       Да      Нет Нет

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

                                        Си++        Java    Oberon    C#
Модульность и раздельная компиляция     Нет         Да      Да        Да
Сборка мусора                           Нет         Да      Да        Да
Наследование                            Мн.         Од.     Од.       Од.
Виртуальная машина                      Нет         Да      Нет       Да
Отражение                               Нет         Да        Нет       Да
Доступ к регистрам и памяти             Да          Нет     Да        Да

Ну как, всё еще уверен, кто там от кого произошел?

Здравствуйте, AVC, Вы писали:

AVC>Так же как у дельфина, у Java/C# предок (Оберон) внешне непохож.

А ты работал с их исходниками, чтобы иметь возможность судить об их внутреннем сходстве?

AVC wrote:

> На страничке
> http://alexcheremkhin.boom.ru/oberon.htm
> я сделал жалкую попытку их перечислить (далеко не полностью) в таблице.
> На всякий случай повторюсь.
>
> Си++ Java Oberon
>Модульность и раздельная компиляция Нет Да Да
>Шаблоны Да Нет Нет
>Сборка мусора Нет Да Да
>Деструкторы Да Нет Нет
>Объединения (union) Да Нет Нет
>Многомерные открытые массивы Нет Да Да
>Наследование Мн. Од. Од.
>Оператор goto Да Нет Нет
>
> ИМХО, Си++ и близко не ночевал здесь.

1. С++ — модульный и может раздельно компилироваться. Смотри, например,
Boost.Plugin.
2. Сборка мусора в С++ тоже возможна — смотрите Boehm-GC.
3. Многомерные массивы в С++ возможны — смотрите Boost.Multi_Array.

Ну и что, что это все реализовано библиотеками? Это лишь показывает
модульность дизайна С++

Так что С++ выигрывает по всем статьям.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Дарней, Вы писали:

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

Разумеется. Однако, чтобы увидеть, что общего и в чем различия между акулой и дельфином, необходимо их вскрыть и внимательно изучить. Кто знает, может, выяснится, что Ява — это доведенный до ума Оберон.

Д>Это называется "конвергенция"

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

Жаль, что из-за взаимного фанатизма у нас это до сих пор получается плохо.

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

В данном случае, imho, реакция вызвана не тем, что написано в отзыве о лекции, а тем, кто его написал.

Здравствуйте, Дарней, Вы писали:


Д> Си++ Java Oberon C#
Д>Доступ к регистрам и памяти Да Нет Да Да

Это к каким таким регистрам доступ. Если байт код не ориентирован виртуальную стековую машину ??????
Да и унсейв не приветствуется.

Здравствуйте, Дарней, Вы писали:

Д>

                                        Си++        Java    Oberon    C#
Отражение                               Нет         Да        Нет       Да

Нельзя сказать что в Oberon совсем нет reflection. Иногда есть, и зависит это от реализации конкретной Оберон-системы. Например, в BlackBox оно доступно посредством модуля Meta.

Здравствуйте, AVC, Вы писали:

AVC>И правда — очень интересный сборник статей. Одна статья Кернигана о Паскале чего стоит!

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

AVC>Согласен, что спокойное и объективное сравнение языков программирования было бы интересным и, возможно, полезным.

Безусловно. Вопрос, как достичь объективности.

AVC>(Конечно, я имею в виду не споры о том, что лучше — } или END, а рассмотрение именно несущих конструкций.)

К синтаксическим особенностям все равно придется обращаться — встречают по одежке. Лично мне, например, не нравится написание служебных слов заглавными буквами. Вот почему.

Автор: Privalov
Дата: 09.08.05

AVC>Жаль, что из-за взаимного фанатизма у нас это до сих пор получается плохо.

Эта проблема тоже решается. Было бы желание.

Здравствуйте, AVC, Вы писали:

AVC>>>Добавьте сюда лекции Франца, которые он читал на эти темы в Sun в 1994 году (за год до выхода Java).

E>>Эти лекции можно было бы приплести, если бы не Green Project (см. Re[10]: Kylix и написание WebServices

Автор: eao197
Дата: 15.08.05

).

AVC>Евгений,
AVC>насколько я понимаю, ты хочешь сказать, что раз работа над Star7 была закончена в 1992 году, то влияние ETH здесь было несущественным.

Нет, Алексей, я хотел сказать другое, но об этом ниже.

AVC>Мне, увы, пока неизвестно о языке, на котором создавался Star7 (также как и о том, был ли на самом деле создан и какие именно решения были заложены в его основу; говорю об этом потому что в свое время Sun была поймана на "жульничестве", связанном с компиляторами Java, поэтому особого доверия у меня к ним нет), но очень странно, что информация о проекте, завершенном в 1992 году, сопровождается ссылкой на спецификацию языка от 1994 года.

Когда-то давно, в одной из первых переводных книжек по Java я прочитал историю возникновения Java. Поскольку это было давно, то в памяти у меня отложилось следующее (предупреждаю сразу, что с памятью у меня не важно, поэтому могу приврать). Грослинг участвовал в проекте по созанию ПО для какого-то умного девайса. Изначально они хотели сделать интерпритируемый вариант C++, чтобы упростить разработку ПО на C++, но быстро поняли, что это безнадежная затея. Поэтому они решили выкинуть из C++ все проблемные части (указатели, препроцессор, множественное наследование) и добавить туда лучшее, что было на данный момент (сборку мусора, компиляцию в байт-код). В результате у них получился компактный язык Oak, на котором этот девайс был запрограммирован. К сожалению, на момент завершения работ весь проект считался в Sun проваленным. Но, Грослинг со товарищи был настолько уверен в своем языке, что они сделали презентацию о нем самому Биллу Джою. Именно Джой оценил перспективы языка и дал добро на его развитие. Я думаю, что полную историю этого дела будет знать Зверек Харьковский. В частности, здесь он привел интересную цитату: Re[15]: Джоэл снова зажигает

Автор: Зверёк Харьковский
Дата: 05.09.05

. Я думаю, что она согласуется с тем, что мне запомнилось.

Что же касается ссылки на спецификацию языка, то в истории проекта Green так прямо и сказано:

For the technical historians in the crowd, here's a copy of the Oak 0.2 manual. It dates from a while after the completion of Green, but it's the oldest manual I've found. It's the last manual I wrote (mostly).

Т.е. человек хотел бы найти самую первую спецификацию, но нашел только эту. Да и я сам по себе знаю, что когда язык развивается и активно используется, то писать спецификации некогда. Вот например, у меня, первая стабильная версия SObjectizer вышла в 2002 году, а его описание в виде SObjectizer Book я смог дописать только через два года. Имхо, тоже самое было и со спецификацией Oak и Java.

AVC>Что касается, лекций Франца о динамической кодогенерации. Обращаю твое внимание на то, что решение о переориентации Oak на Интернет было "внезапно" (как "озарение") принято в 1994 году.
AVC>Напомню также, что язык Оберон был представлен "широкой публике" в 1988 году, незадолго до завершения работ по созданию одноименной операционной системы, и в том же году Оберон (и ОС, и язык) начали использоваться в качестве учебного материала в ETH. Соответственно, ни принципиальные решения, ни исходные тексты системы никогда не скрывались и были широко доступны.

Теперь о том, к чему я вел. А к тому, что, имхо, на момент прочтения лекции Францем Oak/Java были уже в таком стабильном состоянии, что менять что-то в них под влиянием Oberon, C++, Eiffel, Smalltalk, Perl или еще чего-нибудь было бы уже просто не реально. Насколько я помню, разговоры про Java начались в середине 1995, а в 1996 он уже был широко доступен. И, что самое важное, в нем был продвинутый JDK с AWT. И вокруг Java была очень сильная маркетинговая шумиха. Чтобы получить все это в 1995-1996 году нужно было весь 1994 пахать как проклятым, не отрываясь от клавиатуры, для создания JDK и портирования его на Solaris и Windows. Поэтому лекция Франца наверняка была с большим вниманием выслушена, какие-то идеи, вероятно, были приняты на заметку. Но кардинально повлиять на развитие Java на тот момент лекция Франца физически не могла. В этом я убежден.

Еще хотелось бы сказать пару слов о мнении Вирта, что Java это испорченный Oberon, а Oberon -- это предтеча Java. Не могу с этим согласиться по следующим причинам.

Во-первых, Вирт смотрит на мир глазами ученого-исследователя, а не практика. А для исследователя важно знать, что что-то уже было сделано. И если это что-то кем-то было повторено, то для науки это уже не интересно. Вот покорили Эверест -- это да, событие. Смогли значиться. А то, что кто-то в очередной раз забрался на Эверест, но по самому сложнейшему маршруту, там где никто еще не ходил, да еще в четыре раза быстрее, чем все остальные -- то это уже не важно. Важно, что это повторение. К сожалению, я с таким академическим подходом столкнулся в аспирантуре: приношу готовую объектную базу и текст диссертации о ней, а мне говорять -- "А наука-то здесь где? Новизна научная? Это все уже было, ты не сделал ничего нового, иди кури дальше." И что, это правильный подход? С точки зрения науки -- может быть. А когда реальную программу нужно делать, да за реальные совсем маленькие белорусские зайчики, то что толку, что уже давно есть Objectivity, Versant, FastObjects или ObjectStore? В таких условиях можно считать, что их вообще нет. Так и с Виртовским Oberon-ом. Да, сделал Вирт Oberon и ОС на его основе. С точки зрения науки это может быть и был шаг вперед. Но с точки зрения практики -- это еще вопрос. А у Java другая ситуация -- с точки зрения науки это повторение давно пройденого материала. Но вот с точки зрения практики это был просто сумашедший прорыв, который, имхо, очень сильно изменил индустрию ПО.

Во-вторых, если взглянуть на Oberon, то в нем так же не будет найдено много действительно революционных вещей. Сборка мусора -- да была уже давно. Раздельная компиляция? Была. Промежуточный байт-код. Байт-код уже давно был в Smalltalk. Опять же, не историк я, но думаю, что практически все это уже было. Имхо, достоинство Oberon-а в том, что он это удачно и эффективно сочетал. Но вернемся к Java. Я думаю, что Грослинг был знаком с множеством языков, парадигм и концепций, что позволило ему сделать такой удачный язык, как Java. Но вот в том, что Oberon был здесь доминирующим языком я сильно сомневаюсь. Скорее доминирующим был как раз C++, раз уж его Грослинг изначально собрался переделывать. И доказательством этого как раз является C-шный синтаксис Java. Поскольку синтаксис языка (как бытие) определяет сознание. Чего только стоит наличие секции var в паскале-подобных языках и ее отсутствие в C-подобных. Или принцип Java, что класс -- это файл, а пакет -- это каталог, разве это есть в Oberon? Так что, имхо, Oberon определенно оказал влияние на Java. Но вот степень этого влияния на Java, имхо, сильно преувеличивается Виртом со своими подвижниками.

AVC>А вообще, очень рад тебя слышать.

Взаимно!

Здравствуйте, Privalov, Вы писали:

P>В данном случае, imho, реакция вызвана не тем, что написано в отзыве о лекции, а тем, кто его написал.

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

Здравствуйте, Serginio1, Вы писали:

S> Это к каким таким регистрам доступ. Если байт код не ориентирован виртуальную стековую машину ??????

Пардон — C# я уже после дописал. Доступа к регистрам там вроде бы и правда нет, даже через unsafe.

S> Да и унсейв не приветствуется.

тем не менее, он есть.

Здравствуйте, Дарней, Вы писали:

Д>Здравствуйте, Serginio1, Вы писали:

S>> Это к каким таким регистрам доступ. Если байт код не ориентирован виртуальную стековую машину ??????

Д>Пардон — C# я уже после дописал. Доступа к регистрам там вроде бы и правда нет, даже через unsafe.

S>> Да и унсейв не приветствуется.

Д>тем не менее, он есть.
При этом Сергей Губанов утверждал, что в Обероне существует возможность доступа как к регистрам так и памяти. Так что ...

Здравствуйте, Serginio1, Вы писали:

S> При этом Сергей Губанов утверждал, что в Обероне существует возможность доступа как к регистрам так и памяти. Так что ...

Значит, у Оберона по этому вопросу больше общего с C++, чем с Явой

Здравствуйте, Дарней, Вы писали:

Д>Здравствуйте, Serginio1, Вы писали:

S>> При этом Сергей Губанов утверждал, что в Обероне существует возможность доступа как к регистрам так и памяти. Так что ...

Д>Значит, у Оберона по этому вопросу больше общего с C++, чем с Явой
Не совсем, в обероне только для сиситемных вещей. Опять же использование манагед сред нативных библиотек хотя и снижает риск, но полностью его не устраняет. Пример RSDN хоум, где узкие места представляют именно нативный код.

Здравствуйте, Дарней, Вы писали:

Д>Ну мне это безразлично. Можно даже порадоваться за него, что он не стал на этот раз делать слишком далеко идущих высказываний и разжигать флейм.

Кстати, действительно. Отзыв написан в, я бы сказал, академической манере.

Д>Боюсь только, что высказывания самого Вирта в духе "теории заговора" совсем не поднимают планку моего доверия к нему.

Что поделать. Есть такая категория людей. Я несколько лет работал с таким в НИИ. Нормальный человек, хороший специалист, но все ему казалось, что плетут вокруг него интриги, заговоры, зажимают. Всех, кто не соглашался с ним, обоснованно или нет, считал безграмотными <...>. Мне так и не удалось понять причины.

Здравствуйте, gear nuke, Вы писали:

GN>ИМХО (и не только моё), операции присваивания в этих языках далеки от "человеческого" представления.
GN>Для примера, возьмём записанный словами алгоритм: "Прибавить X к Y и поместить результат в Z".
GN>Как это выглядит сейчас:
GN>Z = X + Y // с точки зрения математика, это уравнение!
GN>Z := X + Y // это можно трактовать как "В Z помещяется сумма X и Y"
GN>Немного не по-русски звучит .
GN>А теперь, сравним с таким:
GN>X + Y => Z
GN>Такая запись в точности соответствует поставленной задаче, кроме того, она читается последовательно слева направо. В классической записи нам приходится "запоминать" куда же сохранится разультат, а потом "вспоминать", когда мы дошли до конца выражения. Следствием этого является и усложнение синтаксического анализатора в компиляторе.

Над этим можно подумать. Вполне вероятно, что такая запись больше соответствует человеческому образу мыслей (и однопроходному компилятору для 2-операндных команд ):

Сложить X и Y, результат сохранить в Z. (* add x,y; mov z,x; *)

вместо

Сохранить в Z результат сложения X и Y.

Все же, не уверен в том, что это упростит синтаксический анализ.
Надо подумать, будет ли по прежнему достаточно заглядывания только на один символ вперед (в "неформальном" смысле LL(1), хотя Павел Кузнецов указал, что в формальном смысле грамматика Оберона не является LL(1) из-за пары исключений).

AVC>>Вместе с тем, если бы все различие между языками сводилось к особенностям синтаксиса Си и Паскаля, оно не заслуживало бы слишком долгого обсуждения.

GN>На мой взгляд, различия между ними берут истоки в причинах создания. С создавался как развитый компилятор ассемблера PDP. Понять этот язык я смог буквально за пару дней после изучения этого ассемблера; у меня не вызывает удивление наличае операторов ++ и подобного. Паскаль же создавался как отвлечённый от железа язык для обучения — то есть, *как бы* понятный неподготовленному. А теперь риторический вопрос: есть ли разница в мышлении человека и логике работы машины? Что бы понять С, достаточно понять эту машину, а что с Паскалем? На нём же мы не можем использовать обычный человеческий язык, как бы мы не хотели — есть жёсткие рамки того, что язык всё-таки компютерный. И вот в этом месте начинается замкнутый круг: с одной стороны, нужно понимать принципы функционирования машины, с другой — философия языка от этого ограждает. В этом плане языки основанные на виртуальных машинах как бы шаг вперёд — понимать нужно уже эту самую абстрактную машину, что проще. Можно сколько угодно говорить о пользе абстракций, но самое интересное — все эти слова говорят люди прекрасно понимающие, что за абстракциями стоит. Именно поэтому они и могут извлечь из абстракций пользу .

В каком-то смысле, могу подтвердить Ваши слова.
Один мой знакомый программист в детстве учился программировать на Паскале (по очень неудачному учебнику), но никак не мог понять, что такое указатель. Начал писать на Си, и до него сразу "дошло", что указатель — это адрес.
Т.е. в абстракции тоже надо знать меру.
По-моему, Алекс Степанов (автор концепции обобщенного программирования) написал статью о том, что большая заслуга Си в том, что он "создал" очень удобную абстрактную машину.
Кажется, по смыслу это близко Вашему ходу мысли?

P.S. Прошу прощения у всех, что отвечать вынужденно (из-за обстоятельств) буду с задержками.

Здравствуйте, AVC, Вы писали:

AVC>Все же, не уверен в том, что это упростит синтаксический анализ.
AVC>Надо подумать, будет ли по прежнему достаточно заглядывания только на один символ вперед (в "неформальном" смысле LL(1), хотя Павел Кузнецов указал, что в формальном смысле грамматика Оберона не является LL(1) из-за пары исключений).

Кроме того, у конструкции X + Y => Z может быть другой недостаток, родственный защищаемой Евгением (eao197) конструкции do_something() if (condition).
Когда мы читаем в программе

z := x + y;

то сразу видим цель оператора — переменная z получает значение.
Мы можем временно игнорировать проверку самого вычисления и проверить последующий код на предмет корректности.
По крайней мере, мы хотя бы знаем, что переменная z инициализирована (ее не забыли инициализировать ).

Здравствуйте, AVC, Вы писали:

GN>>X + Y => Z

AVC>Все же, не уверен в том, что это упростит синтаксический анализ.

Упрощение, конечно, не слишком заметное, поскольку от скобок и приоритетов операций никуда не деться. Глубина используемого стека разбора уменьшится на единицу и всё. Да и сейчас об упрощении синтаксических анализаторов ИМХО не нужно сильно заботиться, времена машин для которых делали первый FORTRAN давно прошли.

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

AVC>Один мой знакомый программист в детстве учился программировать на Паскале (по очень неудачному учебнику), но никак не мог понять, что такое указатель. Начал писать на Си, и до него сразу "дошло", что указатель — это адрес.

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

AVC>Т.е. в абстракции тоже надо знать меру.

А обычно мы наблюдаем картину когда перегибают палку в том или ином направлении .

AVC>По-моему, Алекс Степанов (автор концепции обобщенного программирования) написал статью о том, что большая заслуга Си в том, что он "создал" очень удобную абстрактную машину.
AVC>Кажется, по смыслу это близко Вашему ходу мысли?

Почти. Алекс Степанов похоже имеет ввиду поздний С (с витающими в воздухе "идеями С++"), кода все заговорили о кросплатформенности. Язык начали "подтягивать" вверх, появились абстракции. Надо думать, к этому приложили немалые усилия теже последователи Вирта . Даже сейчас в исходниках Microsoft влияние паскалевского стиля попросту доминирует.

Здравствуйте, AVC, Вы писали:

GN>>X + Y => Z
AVC>Над этим можно подумать.

Вирту только не говорите, а то к выходу Oberon 3 идеальным синтаксисом начнет считаться польская нотация.

Здравствуйте, AVC, Вы писали:

AVC>Да, действительно, сборка мусора существовала как минимум со времен Лиспа, но только в интерпретируемых средах.
AVC>Насколько мне известно, Оберон был первым компилируемым императивным языком, в котором появилась сборка мусора.

Возможно даже не первыми компилируемыми императивными языками со сборщиком мусора были PL/I и Algol 68.