Мои впечатления о лекции Н. Вирта в ННГУ 26.09.2005 - Философия программирования

AVC wrote:

> Собственно, "мой ответ Cyberax-у" имел простую цель: указать на то,
> что в большинстве случаев break (EXIT) не нужен.
> Вместо популярного на Си решения вроде (схематично)
>
>for (i = 0; i < n; ++i)
> if (a[i] == x)
> break;
>
> вполне хорошо
>
>i := 0;
>WHILE (i < n) & (a[i] # x) DO INC(i) END;
>
Не забудьте еще про continue.

Я не вижу смысла запрещать break/continue ради сомнительной (еще для
70-х годов) выгоды. Лучше бы именованые циклы ввели — они РЕАЛЬНО
помогают (и делают goto ненужным).

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

Posted via RSDN NNTP Server 2.0 beta

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

AF>> Разработчики Oak и Java никогда и не скрывали того факта, что при разработке этих языков были использованы и проанализированы многие языки и существующие решения в том числе и оберон.

AVC>Да ну?! Почитайте еще раз ответ Зверька Харьковского и его детское недоумение, что упоминания об Обероне он не нашел.

Коль скоро вы меня всуе

поминаете, позволю себе ткнуть пальцем сюда.

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

AF> Я ошибся. В действительности ситуация несколько сложнее...

В результате повторного изучения трактатов IA-32 Intel® Architecture Software Developer’s Manual Volume 3: System Programming Guide и выяснилась следующая картинка. Windows использует глобальную таблицу дескрипторов для хранения дескрипторов процессов (Task State Segment Descriptors по терминологии IA-32 IASDM), что обеспечивает аппаратное разделение и защиту адрессных пространств процессов. Поскольку процессор на прямую работает не с самими дескрипторами, а с т.н. селекторами (по сути индексами дескрипторов в таблицах), а в поле индекса селектора всего 13 бит (сам селектор 16 битный, ещё два бита используются для указания уровня привелегий и один — для выбора таблицы — глобальной или локальной), получаем фундаментальное ограничение в 8191 задачи (нулевой дескриптор занят аппаратно под внутренние нужды CPU) или в терминологии Windows — 8191 процесс.
Я правильно понимаю, что таких локальных таблиц может быть море разливанное? И что можно переключаться между таблицами, и всего таск дескрипторов в системе может одновременно существовать чуть больше, чем 8191?
AF> Потоки же (внутри процесса) поддерживаются сугубо программными средствами. То есть потенциально количество потоков ограничено лишь памятью процесса, а так же размерами системных таблиц ресурсов, поддерживаемыми Windows.
Т.е. процессор не предоставляет никакой поддержки концепции потока? Никаких там тебе сохранений состояния, идентификации, верно?

1.1.4 stable rev. 510

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

AVC>Собственно, "мой ответ Cyberax-у"

имел простую цель: указать на то, что в большинстве случаев break (EXIT) не нужен.

Там где break не нужен, я на C++ могу написать std::for_each (или еще более выразительный аналог), а вместо:

i := 0;
WHILE (i < n) & (a[i] # x) DO INC(i) END;

я напишу std::find_if. Писанины меньше, степень абстракции больше. Но Вирт этого не понимает и навязывыет в 21 веке низкуровневые концепции (пусть и отточенные до совершенства) времен первых процедурных языков. ООП на Обероне никак иначе, чем "восход солнца вручную" назвать трудно. И все ради минимализма в синтаксисе и чистоты концепций, которые в таком виде оценят разве что студенты и разработчики компиляторов. Хотя и студентам изучать ООП на Обероне я бы не стал предлагать, есть куда более выразительные и понятные языки.

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

AVC>>В Обероне же система всегда целостная и "типо-безопасная".

Д>иными словами, просто более "дурако-защищенная"

Д>>>неважно. если такая задача есть — то есть и средства для ее решения.

AVC>>Я лично думаю, что очень важно.
AVC>>Разница в удобстве и надежности — огромная.

Д>не спорю. тем не менее, такой ход развития был очевидным

Как всегда — post factum.

AVC>>По ограниченности времени (сейчас уже выхожу из Интернета) "уступаю право первого хода".

Д>я вот на это еще не дождался внятного ответа, а не измышлений в духе теории заговора
Д>Re[5]: Мои впечатления о лекции Н. Вирта в ННГУ 26.09.2005

Это не совсем так:
http://rsdn.ru/Forum/Message.aspx?mid=1426246&only=1
ИМХО, я привел там именно тот уникальный набор возможностей, которым "похвалялась" Java.
Лично мне известен только один "до-явовский"

язык, в котором эти возможности были раньше.
И именно об этом языке "ни гу-гу".
Еще раз подчеркну мысль: не заимствование как таковое является воровством, а замалчивание источников.

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

Если же Вы решили ограничиться "наскоками" в духе "Оберон — кривая поделка" и выставлением минусов уж за совсем невинные утверждения, то стоит ли спорить дальше?

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

AVC>По-видимому, использование вспомогательных логических переменных для управления циклом навеяно старыми учебниками по
AVC>Паскалю.

AVC>По крайней мере, на Обероне так не пишут.
AVC>Если мне надо иметь "запасной люк", чтобы выйти из середины цикла в каких-то особых обстоятельствах, используют либо
AVC>цикл LOOP...EXIT...END, либо встраиваемую локальную процедуру.
AVC>Например, применим локальную процедуру (т.к. использование EXIT аналогично break, но не внушает ложных надежд предусловием цикла).

Один чёрт.
Какое постусловие функции, содержащей цикл с пожарными выходами?

Всё упирается не в минимализм языка (убрать всё лишнее), и даже не в пуризм методологии кодирования (goto это зло, one shot one body — единственный выход из блока или функции, и т.п.)
А в то, насколько легко читаемый (и верифицируемый с листа) получается конкретный код.

Для этого есть и метрики (скажем, размер листинга или количество ветвлений), и методологии, и здравый смысл.

Сделать же макароны можно в любом случае — не с помощью goto, так с помощью дебильных условий и ветвлений. Пуризм здесь не спасёт.

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

AF>>>В действительности проанализируйте байт код Java и P-код. У них общего только то что оба — система команд и не более. Ну а то что "архитектуры Java машины и виртуальной машины исполняющей P-код очень похоже" — вообще никакой критики не выдерживает. Хотя бы потому, что Java — объектная среда с метаинформацией, а P-код — голимо процедурен.

AVC>>Потрясающе логично!
AVC>>Например, отсюда следует, что Оберон не может быть откомпилирован в машинные инструкции, потому что Оберон — "объектная среда с метаинформацией" (ой, опять случайное совпадение

), а машинный код — просто набор машинных команд.

AF>Во первых из моего утверждения этого не следует,

Вообще-то именно следует.
Прочитайте свой аргумент еще раз свежим, "незамыленным" глазом.
Теперь по его сути.
То, что P-код процедурен, никак не ограничивает его возможностей как кода.
(В конце концов, любой код превращается в машинные инструкции.)
С его помощью вполне можно создавать "объектные среды с метаинформацией".

AF>а во-вторых вы сами недавно утверждали, что Оберон компилируется сразу в native код, а вовсе не в байт-код. Не находите некое различие с Java?

Или по-вашему Вирт — спёрший идеи ООП из кучи других языков — большой новатор — а аналогичное новаторство (в форме компиляции в байт код) — почему-то является воровством?

Я уже пояснял, почему я считаю заимствования в Java из Оберона воровством.

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

AVC>Как всегда — post factum.

нет, не как всегда
не сделал бы Вирт — сделал бы кто-то другой. "Но Хунта успел первым" (С)

Д>>я вот на это еще не дождался внятного ответа, а не измышлений в духе теории заговора
Д>> Re[5]: Мои впечатления о лекции Н. Вирта в ННГУ 26.09.2005

AVC>Это не совсем так:
AVC> http://rsdn.ru/Forum/Message.aspx?mid=1426246&only=1
AVC>ИМХО, я привел там именно тот уникальный набор возможностей, которым "похвалялась" Java.

вот именно про этот постинг я и говорил. бОльшая его часть — это как раз те самые измышления (таинственные консультации на неустановленную тему, странные выводы из биографии Гослинга и т.п.).
Если он когда-то как-то участвовал в разработке, связанной с Паскалем — значит, всего его разработки до самой смерти принадлежат Вирту?
Если ты утверждаешь, что "Например, у Паскаля заимствована идея P-кода" — значит, у тебя есть точные данные, что P-код был изобретен именно во время этой самой разработки, а не раньше?
Что касается оставшегося, то оно производит еще более странное впечатление.
К "ключевым фичам, которыми похваляется Ява", ты причислил:
3) Динамическая загрузка модулей "по требованию". — а что, до этого динамической загрузки не было? Да почти в любом языке она есть!
4) Возможности метапрограммирования (в т.ч. рефлексия). — так они там есть или нет? Тут недалеко утверждали, что ничего подобного в стандарте и близко не было
5) Гипертекстовый интерфейс (например, команда вызывалась щечком мышки по текстовой паре модуль.процедура). — какое вообще отношение возможности IDE имеют к языку?
6) Внедряемые в текстовые документы объекты, обладающие собственным поведением. — опять же, какое отношение это имеет к языку?
7) Уникальная в то время переносимость. Разные Оберон-системы имели единый API и единый машинно-независимый формат данных. — ну а как насчет POSIX то?
8) Наконец, машинно-независимый мобильный код. Например, к 1994 году практически для всех модулей... — к этому году уже и Ява была почти готова.

В обшем, сплошная вода. Только пункты 1 и 2 заслуживают внимания, из которых ни один не является новшеством.

AVC>Еще раз подчеркну мысль: не заимствование как таковое является воровством, а замалчивание источников.

значит, этот источник не заслуживает упоминания.

AVC>Мне действительно интересно, какую бы Вы "нарисовали" табличку.

дубль два

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

* только для интерфейсов, но не для реализаций
** без поддержки ООП

AVC>Возможно, прояснилась бы разница в подходах к языкам, по причине которой одному человеку (мне) заимствование многих (важнейших!) фич Явы от Оберона кажется очевидным, а другие (и даже многие) — ну вот ничего похожего в этих языках не находят.

AVC>Если же Вы решили ограничиться "наскоками" в духе "Оберон — кривая поделка" и выставлением минусов уж за совсем невинные утверждения, то стоит ли спорить дальше?

а о чем тут спорить? Я тебе про виртуальную машину, а ты мне про гиперлинки в IDE. Спорить и правда не о чем.
Мне интересно — это Оберон сам по себе вызывает в людях такой фанатизм, или просто никто кроме фанатиков не хочет с ним связываться?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

В>Там где break не нужен, я на C++ могу написать std::for_each (или еще более выразительный аналог), а вместо:

В>

В>i := 0;
В>WHILE (i < n) & (a[i] # x) DO INC(i) END;
В>

В>я напишу std::find_if. Писанины меньше, степень абстракции больше. Но Вирт этого не понимает и навязывыет в 21 веке низкуровневые концепции (пусть и отточенные до совершенства) времен первых процедурных языков. ООП на Обероне никак иначе, чем "восход солнца вручную" назвать трудно. И все ради минимализма в синтаксисе и чистоты концепций, которые в таком виде оценят разве что студенты и разработчики компиляторов. Хотя и студентам изучать ООП на Обероне я бы не стал предлагать, есть куда более выразительные и понятные языки.

Точки зрения могут не совпадать.

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

Что касается std::find_if, то зачастую это требует переопределения операторов.
Если Вам это нравится, то ясно, что Вы предпочтете такой вариант.

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

AVC>Лично я, например, считаю, что break лишает while выразительности.
AVC>Аргументы я приводил. С ними, конечно, можно не соглашаться.

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

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

Весьма спорное утверждение.

AVC>Оценивая выразительность языка, я исхожу из позиции читателя программ.

И я привел пример, когда вместо просто цикла (пусть даже и без break) язык позволяет выразить происходящее более явно. И этот язык не Оберон.

AVC>Что касается std::find_if, то зачастую это требует переопределения операторов.
AVC>Если Вам это нравится, то ясно, что Вы предпочтете такой вариант.

std::find_if может работать с предикатом.

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

Ммм... возможно... Тогда слишком малое число конструкций приводит к тому, что выразительность теряет программа в целом. Искусство, как всегда, найти золотую середину.

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

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

AVC>>Как всегда — post factum.

Д>нет, не как всегда
Д>не сделал бы Вирт — сделал бы кто-то другой. "Но Хунта успел первым" (С)

Д>>>я вот на это еще не дождался внятного ответа, а не измышлений в духе теории заговора
Д>>> Re[5]: Мои впечатления о лекции Н. Вирта в ННГУ 26.09.2005

AVC>>Это не совсем так:
AVC>> http://rsdn.ru/Forum/Message.aspx?mid=1426246&only=1
AVC>>ИМХО, я привел там именно тот уникальный набор возможностей, которым "похвалялась" Java.

Д>вот именно про этот постинг я и говорил. бОльшая его часть — это как раз те самые измышления (таинственные консультации на неустановленную тему, странные выводы из биографии Гослинга и т.п.).

Почему измышления? Об этом пишет, например, Франц в старой статье "Java: критическая оценка".

Что в Java действительно ново?

При ближайшем рассмотрении довольно быстро обнаруживается, что революционных новшеств в
Java совсем немного. Правильнее сказать, что Java объединяет ряд давно известных идей, причем
поразительно многие из них восходят к работам Никлауса Вирта и его исследовательской группы в
Швейцарском федеральном технологическом институте (ETH) в Цюрихе.
• Переносимость Java основана на наличии виртуальной машины [Линдхольм и др.],
позволяющей легко имитировать большое число архитектур. Идея виртуальной машины была
очень популярна уже более двадцати лет назад, хотя впоследствии о ней забыли. Тогда речь
шла о Pascal-P — созданной в ETH реализации Паскаля [Нори и др.], которая сыграла
решающую роль в распространении этого языка. Интересно, что виртуальные машины для
Паскаля и Java весьма схожи по архитектуре: в обеих используются однобайтовые
инструкции без адресов (операнды помещаются в стек).
• Не нова также идея строгой типизации с поддержкой динамических типов и системы "сборки
мусора", причем роль первооткрывателя здесь тоже сыграл цюрихский ETH. Многие из
аргументов, с помощью которых команда разработчиков Java обосновывает отказ от
использования указателей, были сформулированы за пять лет до выхода Java в среде
"сообщества модульных языков" (modular language community) при обсуждении
разработанного Виртом языка программирования Оберон [Вирт 88]. С давних пор в
виртовских языках [Вирт 71, 82, 88] принимаются и другие меры по усилению надежности,
такие как проверка индекса при добавлении элементов в массив, — однако до сих пор
программисты рассматривали их скорее как досадное ограничение, чем как преимущество.
По-видимому, рекламная кампания Sun привела к определенному перелому в общественном
мнении по данному вопросу.
• Мысль о том, что язык со строгой типизацией делает возможным построение программ,
переносимых с одной архитектуры на другую, в 1990-93 гг. нашла в ETH воплощение в целом
семействе [Брандис и др.] реализаций Оберон-систем [Вирт-Гуткнехт 89, 92]. Они отличались
не только единым интерфейсом прикладных программ для всех аппаратно-программных сред
[Франц 93], но и единой машинно-независимой архитектурой документов [Шиперский], уже в
то время предусматривавшей встраивание в текст "плавающих" активных объектов.
Созданный в развитие идеи пакет Oberon System 3 [Гуткнехт] идет еще дальше, заменяя
присущее современным Java-браузерам концептуально неудовлетворительное разграничение
между текстом и объектами на единую интегрированную объектную модель.
• Программы на Java могут состоять из нескольких независимо компилируемых единиц,
которые "динамически" собираются воедино только в момент загрузки [Франц 97]. В Java
поддерживается "истинная" раздельная компиляция, при которой компилятор производит
проверку границ между модулями. Программистам, имеющим дело в основном с Си/Си++,
это, возможно, покажется значительным усовершенствованием, поскольку там для
раздельной обработки применяется крайне примитивный механизм включения
непосредственно в текст так называемых "заголовочных файлов". Однако в мире модульного
программирования возможности, эквивалентные имеющимся в Java, на протяжении уже
более чем десяти лет являются стандартом. Краеугольный камень здесь также заложил
Никлаус Вирт, создав язык Модула-2 [Вирт 82].
• Даже преподносимая сейчас в качестве главной инновации Java идея не зависящих от
платформы мобильных программ в сочетании с генерацией кода в процессе выполнения
еще раньше появилась в ETH. Выполненная под руководством Вирта диссертация автора
этих строк [Франц 94] посвящена описанию динамически расширяемой системы, в
которой исполняемый объектный код "на лету" порождается из промежуточного
машинно-независимого формата. В этой диссертации, опубликованной на английском
языке в феврале 1994 г., т. е. более чем за год до самой первой презентации Java, уже
появляется слово applet и описывается ряд сценариев, весьма сходных с
существующими сегодня на Java. В настоящее время автор работает над дальнейшим
развитием своей системы, обладающей несколькими преимуществами по сравнению с
Java [Франц-Кистлер]. В связи с этим может быть интересно то обстоятельство, что в
марте 1994 г. автором был прочитан в Калифорнии ряд докладов по теме диссертации,
причем один из них — в Sun Laboratories, Inc. Кроме того, упомянутый выше Билл Джой,
который переориентировал проект Java на WWW, стал одним из первых обладателей
лицензии на Оберон-систему ETH, и в конце 1994 — начале 1995 г. он неоднократно
связывался с ETH; в процессе контактов выяснилось, что он читал мою диссертацию.

Д>Если ты утверждаешь, что "Например, у Паскаля заимствована идея P-кода" — значит, у тебя есть точные данные, что P-код был изобретен именно во время этой самой разработки, а не раньше?

P-код был создан для того, чтобы облегчить перенос Паскаля на разные машины.
http://en.wikipedia.org/wiki/P-Code

In computer programming, a virtual machine executing p-code, the p-Code machine or pseudo-code machine was the target of some early Pascal implementations. That is, the programming language Pascal was translated not to machine code instructions (understandable directly to a processor), but to p-code instructions. To execute the program, another program is used that interprets this code.

Хочу обратить внимание на следующее:

The Business Operating System (BOS) of the 1980s was a cross-platform operating system designed to exclusively run p-code based programs.

The UCSD p-System was a portable machine independent operating system based on p-code.

Д>Что касается оставшегося, то оно производит еще более странное впечатление.
Д>К "ключевым фичам, которыми похваляется Ява", ты причислил:
Д>3) Динамическая загрузка модулей "по требованию". — а что, до этого динамической загрузки не было? Да почти в любом языке она есть!

Разве?
Например, в Обероне даже нет понятия главной программы. Все модули подгружаются динамически, если содержат указанную
пользователем команду или перечислены в списке импорта другого загружаемого модуля.
Насколько я понимаю, механизм загрузки классов в Яве работает сходным образом.

Д>4) Возможности метапрограммирования (в т.ч. рефлексия). — так они там есть или нет? Тут недалеко утверждали, что ничего подобного в стандарте и близко не было

ИМХО, без таких возможностей была бы невозможна динамическая загрузка и связывание модулей (с полной проверкой типов и т.д.).
Вероятно, Вы хотите сказать, что эти свойства использовались run-time system, но не использовались прикладными программистами, т.к. модуль Types не упоминается в самой ранней литературе об Обероне.
Я посмотрел в исходники ETH Oberon (для Windows). Самая ранняя временная метка в модуле Types датируется серединой января 1992 года. Это не значит, что этот модуль не существовал раньше. Просто я нашел такую дату, и, ИМХО, этого достаточно.

Д>5) Гипертекстовый интерфейс (например, команда вызывалась щечком мышки по текстовой паре модуль.процедура). — какое вообще отношение возможности IDE имеют к языку?

Потому что привязано к вызову обероновской команды — экспортируемой модулем процедуры.
В Оберон-системе пользователь вызывал команду, кликая мышкой на текстовой паре: Module.Procedure.

Д>6) Внедряемые в текстовые документы объекты, обладающие собственным поведением. — опять же, какое отношение это имеет к языку?

По крайней мере, это имеет отношение к понятию "compound document".
Наверное, Вам приходилось иметь дело с OLE и COM.
А ведь насколько проще все это реализовано в Обероне!
Во вторых, я все же говорю об аплетах. Которые, резюмирую, появились не в Яве.

Д>7) Уникальная в то время переносимость. Разные Оберон-системы имели единый API и единый машинно-независимый формат данных. — ну а как насчет POSIX то?

А что, POSIX имеет какое-то отношение к динамической загрузке, динамической кодогенерации, динамическим типам и т.д.
и т.п.?

Д>8) Наконец, машинно-независимый мобильный код. Например, к 1994 году практически для всех модулей... — к этому году уже и Ява была почти готова.

Ну, как она почти была готова, уже делился впечатлениями от прочитанной литературы jazzer.
По его мнению, народ очень торопился к концу 1995 года, даже язык был сдан "с недоделками".
Евгений (eao197) высказался в том духе: а что, это вполне возможно.

Хотя сам незадолго высказывал предположение, что уже проект Star7 был реализован на Яве, только спецификации потерялись.

Зверек Харьковский сам сначала удивлялся, что Оберон не был упомянут создателями Явы, а потом вдруг говорит: на меня
(всуе

) не ссылайся, в этом мире вообще ничего доказать нельзя.

А первые материалы Франц публиковал еще в 1991 году (м.б. и раньше).
Просто, чтобы защитить диссертацию у Вирта, надо своими руками сделать на основе защищаемых тезисов что-нибудь стоящее. Вот Франц и реализовывал (сам, не корпорация!) JIT-компиляцию для MacOberon, и диссертацию защитил только в
1994 году.

Д>В обшем, сплошная вода. Только пункты 1 и 2 заслуживают внимания, из которых ни один не является новшеством.

Понимаю. Это Ваша точка зрения.

AVC>>Еще раз подчеркну мысль: не заимствование как таковое является воровством, а замалчивание источников.

Д>значит, этот источник не заслуживает упоминания.

Ну что же, и это Ваша точка зрения.

AVC>>Мне действительно интересно, какую бы Вы "нарисовали" табличку.

Д>дубль два

Д>

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

Д>* только для интерфейсов, но не для реализаций
Д>** без поддержки ООП
Д>

Интересно, для чего сюда добавлен C#, созданный значительно позже Си++, Оберона и Явы?
Как он-то мог стать предшественником Явы?
По сути таблицы.
Раздельной компиляции и модульности в Си++ нет. (Вместо них есть жалкий суррогат с header-файлами.)
Наследование интерфейса и наследование реализации — совсем не одно и то же.
И это все Ваши возражения?
Даже если бы я принял их, табличка пока в целом подтверждает точку зрения, что Java (как, кстати, и C#) гораздо ближе к Оберону, чем к Си++.

AVC>>Если же Вы решили ограничиться "наскоками" в духе "Оберон — кривая поделка" и выставлением минусов уж за совсем невинные утверждения, то стоит ли спорить дальше?

Д>а о чем тут спорить? Я тебе про виртуальную машину, а ты мне про гиперлинки в IDE. Спорить и правда не о чем.
Д>Мне интересно — это Оберон сам по себе вызывает в людях такой фанатизм, или просто никто кроме фанатиков не хочет с ним связываться?

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

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

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

iT>Ммм... возможно... Тогда слишком малое число конструкций приводит к тому, что выразительность теряет программа в целом. Искусство, как всегда, найти золотую середину.

В принципе, согласен.

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

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

AF>>>>В действительности проанализируйте байт код Java и P-код. У них общего только то что оба — система команд и не более. Ну а то что "архитектуры Java машины и виртуальной машины исполняющей P-код очень похоже" — вообще никакой критики не выдерживает. Хотя бы потому, что Java — объектная среда с метаинформацией, а P-код — голимо процедурен.

AVC>>>Потрясающе логично!
AVC>>>Например, отсюда следует, что Оберон не может быть откомпилирован в машинные инструкции, потому что Оберон — "объектная среда с метаинформацией" (ой, опять случайное совпадение

), а машинный код — просто набор машинных команд.

AF>>Во первых из моего утверждения этого не следует,

AVC>Вообще-то именно следует.
AVC>Прочитайте свой аргумент еще раз свежим, "незамыленным" глазом.
AVC>Теперь по его сути.
AVC>То, что P-код процедурен, никак не ограничивает его возможностей как кода.
AVC>(В конце концов, любой код превращается в машинные инструкции.)
AVC>С его помощью вполне можно создавать "объектные среды с метаинформацией".

Алексей, прошу прошения за излишне эмоциональное письмо, которое я написал ранее. Стоило бы выражаться более красиво и вежливо.

Не кажется ли вам аргумент "P-код можно доработать до объектной среды" немного странным? P-код не был первым примером подобного рода. И сам Вирт, замечу, не утверждал когда либо что P-код был первым примером такого рода ( Угадайте почему?

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

Тем более, что Вы сами утверждали неоднократно, что существенная доработка чужих идей — это уже своя идея. Ну а поскольку я прекрасно представляю себе то, как выглядит различие между структурным байт кодом без метаинформации и сборки мусора и объектным байт-кодом с метаинформацией и сборкой мусора — как выглядят архитектуры подобных машин и насколько они различаются, то я вряд ли могу согласиться с тем, что виртуальная машина Java — это есть "доработка" P-кода.

Хотя бы по тривиально простой причине, что если принять данное утверждение, то мы получим, что Вирт сам своровал чужие идеи. Так как его предложения отличаются от того, что он развивал — примерно в той же степени, в какой Java машина отличается от P-кода.

Так что Вам придётся выбрать одно из двух — или признать, что Вирт сам ворует чужие идеи или признать, что Java являлась оригинальной разработкой. Выбирайте.

AF>>а во-вторых вы сами недавно утверждали, что Оберон компилируется сразу в native код, а вовсе не в байт-код. Не находите некое различие с Java?

Или по-вашему Вирт — спёрший идеи ООП из кучи других языков — большой новатор — а аналогичное новаторство (в форме компиляции в байт код) — почему-то является воровством?

AVC>Я уже пояснял, почему я считаю заимствования в Java из Оберона воровством.

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

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

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

AF>> Я ошибся. В действительности ситуация несколько сложнее...

В результате повторного изучения трактатов IA-32 Intel® Architecture Software Developer’s Manual Volume 3: System Programming Guide и выяснилась следующая картинка. Windows использует глобальную таблицу дескрипторов для хранения дескрипторов процессов (Task State Segment Descriptors по терминологии IA-32 IASDM), что обеспечивает аппаратное разделение и защиту адрессных пространств процессов. Поскольку процессор на прямую работает не с самими дескрипторами, а с т.н. селекторами (по сути индексами дескрипторов в таблицах), а в поле индекса селектора всего 13 бит (сам селектор 16 битный, ещё два бита используются для указания уровня привелегий и один — для выбора таблицы — глобальной или локальной), получаем фундаментальное ограничение в 8191 задачи (нулевой дескриптор занят аппаратно под внутренние нужды CPU) или в терминологии Windows — 8191 процесс.

S>Я правильно понимаю, что таких локальных таблиц может быть море разливанное? И что можно переключаться между таблицами, и всего таск дескрипторов в системе может одновременно существовать чуть больше, чем 8191?

Не совсем, к сожалению.

Дескрипторы задач (соответствуют процессам) могут храниться только в глобальной таблице дескрипторов (а она увы одна и в ней может быть до 8192 дескрипторов без 0-го, т.к. он занят, т.е. 8191 дескриптор).

6.2.2 TSS Descriptor

The TSS, like all other segments, is defined by a segment descriptor. Figure 6-3 shows the
format of a TSS descriptor. TSS descriptors may only be placed in the GDT; they cannot be
placed in an LDT or the IDT.

В структуре данных, описывающих задачу (сиреч процесс) хранится указатель на локальную таблицу дескрипторов (уникальную для данной задачи — процесса) и директория каталога страниц задачи (процесса). Таким образом процессор обеспечивает разделение и защиту адресных пространств задач (т.е. процессов). И именно для задач (процессов) процессор обеспечивает переключение контекста выполнения. Причём и то не всегда, а только для 16 и 32 битных режимов:

2.1.3.1 Task-State Segments in IA-32e Mode

Hardware task switches are not supported in IA-32e mode. However, TSSs continue to exist.
The base address of a TSS is specified by its descriptor.

AF>> Потоки же (внутри процесса) поддерживаются сугубо программными средствами. То есть потенциально количество потоков ограничено лишь памятью процесса, а так же размерами системных таблиц ресурсов, поддерживаемыми Windows.

S>Т.е. процессор не предоставляет никакой поддержки концепции потока? Никаких там тебе сохранений состояния, идентификации, верно?

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

Как я описал выше — процессор может поддерживать не более 8191 задачи. Но этого может быть мало, особенно в серверных системах (мне говорили, что в Advanced Server лимит на количество потоков больше, чем в Professional). С другой стороны аппаратное переключение потоков гораздо эффективнее программного. Потому перед MS стояла задача — как бы так извернуться, что бы обойти злостное ограничение. Ну и извернулись. Когда система переключается в диспетчер задач — оный просто подсовывает в структуре данных задачм на место счётчика команд задачи (процесса) вместо одного потока — счётчик команд другого (т.е. копирует 2x4 байта), после чего преспокойно прыгает в поток с подменённым дескриптором. Таким образом переключение контекста по-прежнему обеспечивает процессор, который, однако дурит диспетчер задач, увеличивая количество потоков (но не процессов), сверх лимита, накладываемого архитектурой процессора. Потому, потенциально количество потоков ограничивает лишь память и размеры системных таблиц, выделенных для работы с потоками.

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

AF> Я уже указавал, что вы привели лишь догадки, но не факты. Потому, Алексей, вы можете считать как угодно, но вот утверждать это публично, с моей точки зрения, не совсем разумно.

Андрей,

я сам себя уже проклял за то, что сделал такое утверждение (о некрасивом — потому что тайном — заимствовании Явой идей из Оберона).

Результатом этого стало то, что я поссорился (или почти уже поссорился) со многими хорошими людьми, с которыми я бы никогда не мог поссориться по причине расхождения во мнениях.
Честно говоря, мне было бы гораздо легче, если бы выяснилось, что я неправ, и Sun не заимствовала обероновских идей без всякого упоминания их происхождения. Для меня даже мир стал бы светлее и чище. (Без шуток!)
Моя проблема в том, что заимствования в Яву из Оберона (а также причины замалчивания этого) мне кажутся очевидными, как день.
И теперь я не знаю, что с этим делать. Может, поступить как Галилей: "Ладно, ребята, ваша взяла — она не вертится!"?

Предлагаю такой вариант: бросим эту неблагодарную тему.
Никто от нее стал счастливее.

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

AVC>Что в Java действительно ново?

А что в обероне действительно ново?
Правильный ответ — НИ-ЧЕ-ГО.
Поэтому Вирт и иже с ним, вместе со своими параноидальными претензиями отправляются прямо в сад.

<дальнейшее поскипано за неимением смысла>

AVC>P-код был создан для того, чтобы облегчить перенос Паскаля на разные машины.
AVC>http://en.wikipedia.org/wiki/P-Code
AVC>

AVC>In computer programming, a virtual machine executing p-code, the p-Code machine or pseudo-code machine was the target of some early Pascal implementations. That is, the programming language Pascal was translated not to machine code instructions (understandable directly to a processor), but to p-code instructions. To execute the program, another program is used that interprets this code.

AVC>Хочу обратить внимание на следующее:
AVC>

AVC>The Business Operating System (BOS) of the 1980s was a cross-platform operating system designed to exclusively run p-code based programs.

Ага. Вот еще, оттуда же:
[q]
Java code is typically transmitted as bytecode to a receiving machine, which then uses a JIT compiler to translate the bytecode to machine code before execution. The current implementation of the Ruby programming language actually does not use bytecode, instead, it relies on tree-like structures, which resembles intermediate representation used in compilers.

Also of interest are p-Codes, which are just like byte codes, but may be physically larger than a single byte and may vary in size (much like opcodes on many CPUs). They work at very high levels, such as "print this string" and "clear the screen". Both BASIC and some versions of Pascal use p-Codes.

Д>>3) Динамическая загрузка модулей "по требованию". — а что, до этого динамической загрузки не было? Да почти в любом языке она есть!

AVC>Разве?

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

Д>>4) Возможности метапрограммирования (в т.ч. рефлексия). — так они там есть или нет? Тут недалеко утверждали, что ничего подобного в стандарте и близко не было

AVC>ИМХО, без таких возможностей была бы невозможна динамическая загрузка и связывание модулей (с полной проверкой типов и т.д.).

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

AVC>Вероятно, Вы хотите сказать, что эти свойства использовались run-time system, но не использовались прикладными программистами, т.к. модуль Types не упоминается в самой ранней литературе об Обероне.
AVC>Я посмотрел в исходники ETH Oberon (для Windows). Самая ранняя временная метка в модуле Types датируется серединой января 1992 года. Это не значит, что этот модуль не существовал раньше. Просто я нашел такую дату, и, ИМХО, этого достаточно.

и какую же функциональность обеспечивал код, который существовал на то время? У тебя есть точные данные?

Д>>5) Гипертекстовый интерфейс (например, команда вызывалась щечком мышки по текстовой паре модуль.процедура). — какое вообще отношение возможности IDE имеют к языку?

AVC>Потому что привязано к вызову обероновской команды — экспортируемой модулем процедуры.

ну и что?
какое отношение это имеет к языку как таковому?

AVC>Во вторых, я все же говорю об аплетах. Которые, резюмирую, появились не в Яве.

и не в Обероне

An applet is a software component that runs in the context of another progam, for example a web browser. The applet must run in a container, which is provided by a host program, or through a plugin, or a variety of other applications including mobile devices that support the applet programming model.

Unlike a program, an applet cannot run independently, features display and often interaction with the human user, and is usually stateless and has restricted security privileges. An applet characteristically performs a very narrow function that has no independent use. Hence, it is an application -let. Historically, the term was introduced in AppleScript in 1993.

Д>>7) Уникальная в то время переносимость. Разные Оберон-системы имели единый API и единый машинно-независимый формат данных. — ну а как насчет POSIX то?

AVC>А что, POSIX имеет какое-то отношение к динамической загрузке, динамической кодогенерации, динамическим типам и т.д.
AVC>и т.п.?

а какое вообще отношение имеет переносимость к динамической загрузке, динамической кодогенерации (которой в обероне нет), динамическим типам и т.п.?

AVC>Интересно, для чего сюда добавлен C#, созданный значительно позже Си++, Оберона и Явы?
AVC>Как он-то мог стать предшественником Явы?

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

AVC>Раздельной компиляции и модульности в Си++ нет. (Вместо них есть жалкий суррогат с header-файлами.)

неважно. с практической точки зрения, такая возможность там есть

AVC>Наследование интерфейса и наследование реализации — совсем не одно и то же.

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

AVC>И это все Ваши возражения?
AVC>Даже если бы я принял их, табличка пока в целом подтверждает точку зрения, что Java (как, кстати, и C#) гораздо ближе к Оберону, чем к Си++.

праавда? два совпадения из шести?

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

основание — это склонность делать странные и ничем не обоснованные высказывания, а также пропускать мимо ушей все аргументы. Очень напоминает манеру СГ, кстати. Вот я и удивляюсь.

Очень разумыне мысли человек пишет
http://gzip.rsdn.ru/Forum/?mid=1430710
Что вы имеете сказать по этому поводу?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

AF>> Я уже указавал, что вы привели лишь догадки, но не факты. Потому, Алексей, вы можете считать как угодно, но вот утверждать это публично, с моей точки зрения, не совсем разумно.

AVC>Андрей,

AVC>....
AVC>Предлагаю такой вариант: бросим эту неблагодарную тему.
AVC>Никто от нее стал счастливее.

Согласен.

Аналогично.

Всё равно кроме "логичных" умозаключений у нас всё равно фактов нет, а без них это вопрос священного флейма.

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

AF> Как я описал выше — процессор может поддерживать не более 8191 задачи. Но этого может быть мало, особенно в серверных системах (мне говорили, что в Advanced Server лимит на количество потоков больше, чем в Professional). С другой стороны аппаратное переключение потоков гораздо эффективнее программного. Потому перед MS стояла задача — как бы так извернуться, что бы обойти злостное ограничение. Ну и извернулись. Когда система переключается в диспетчер задач — оный просто подсовывает в структуре данных задачм на место счётчика команд задачи (процесса) вместо одного потока — счётчик команд другого (т.е. копирует 2x4 байта), после чего преспокойно прыгает в поток с подменённым дескриптором. Таким образом переключение контекста по-прежнему обеспечивает процессор, который, однако дурит диспетчер задач, увеличивая количество потоков (но не процессов), сверх лимита, накладываемого архитектурой процессора. Потому, потенциально количество потоков ограничивает лишь память и размеры системных таблиц, выделенных для работы с потоками.

Ем со стыда свою шляпу. Я всё напутал и переврал.

В общем на тему подмены — всё правильно, только делается всё несколько проще. Подменяется не счётчик команд, а сам дескриптор задачи (8 байт). При запуске процесса после инициализации структур данных процесса (включающей инициализацию LDT — локальной таблицы дескрипторов процесса и каталога виртуальных страниц) с помощью NtCreateThread создаются структуры данных главного потока процесса, в ходе создания которых создаётся сегмент состояния задачи, соответствующей главному потоку процесса. После создания процесса TSS дескриптор главного потока процесса помещается в глобальную таблицу дескрипторов и производится запуск главного потока, как текущей задачи, выполняемой в рамках данного процесса. Если главный поток хочет создать дополнительные потоки, то он вызывает CreateThread, внутри которого NtCreateThread аналогичным образом создаёт сегмент состояния задачи для нового потока, а так же дескриптор для нового TSS. При переключении задач диспетчер задач, используя внтутренние таблицы потоков и схему приоритетов выбирает поток, который должен выполняться CPU и копирует его дескриптор (8 байт) в глобальную талицу дескрипторов. Таким образом само сохранение/восстановление контекста задачи (в 32 или 16 битном режиме) выполняет аппаратно сам CPU, но диспетчер задач его слегка дурит, подменяя дескрипторы задач и, тем самым, снимая лимит задач, накладываемый аппаратурой CPU

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

AF> Согласен.

Аналогично.

AF> Всё равно кроме "логичных" умозаключений у нас всё равно фактов нет, а без них это вопрос священного флейма.

Согласен.
Всякие споры на эту тему прекращаю.
Такое чувство, будто из "штопора" вышел.

	От:	Cyberax
	Дата:	12.10.05 06:36
	Оценка:	2 (1) +1

	От:	Зверёк Харьковский
	Дата:	12.10.05 06:55
	Оценка:	1 (1)

От:	Sinclair	https://github.com/evilguest/
Дата:	12.10.05 07:59
Оценка:

	От:	Владик
	Дата:	12.10.05 08:39
	Оценка:

	От:	AVC
	Дата:	12.10.05 08:40
	Оценка:

	От:	Igor Trofimov
	Дата:	12.10.05 18:44
	Оценка:	+1

	От:	AndreyFedotov
	Дата:	13.10.05 05:10
	Оценка:	+1