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

СГ>>Раздельной компиляции в С++ никогда не было, нет сейчас, и никогда не будет. В С++ есть независимая компиляция. Разницу между раздельной и независимой компиляцией можете узнать в диссертации

Д>это уже буквоедство. На практике же, в С++ МОЖНО компилировать модули по отдельности.

Это не буквоедство, а две "большие разницы".
Раздельно-компилируемые модули и загружать можно по отдельности.
В Си++ же требуется дополнительная статическая линковка (да еще не простая — чтобы уменьшить "распухание" кода из-за шаблонов).
В виду того, что в каждой программе есть некий общий набор функций, в системе, содержащей программы на Си++, всегда есть дублирование кода.
А главное — компонентное программирование на Си++ требует специальных (и чрезмерно навороченных) механизмов, которые надо отдельно изучать, и пользоваться которыми неудобно.
В Оберонах — с 1980-х годов — все программирование является компонентным, и этого никто не замечает.
А такие языки, как Си++, порождают необязательные уродства вроде OLE и COM.

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

AVC>Вирт называет источники, откуда заимствует идеи, а Гослинг главный источник — замолчал.

Кажется, я понял! Вирт скоммуниздил эти идеи раньше, поэтому Гослингу делать то же самое низзя

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

AVC>Вместе с тем, то, как именно Вирт соединил эти идеи, имеет огромное значение. Я не представляю, кто бы еще мог решить эту задачу так просто (и, ИМХО, очень красиво).

Мне это напомнило один пошлый анекдот.
"Ну и пусть не стоит! Но зато посмотри, как красиво висит!"

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

AVC>Раздельно-компилируемые модули и загружать можно по отдельности.

насколько мне известно, в Линуксе уже давным-давно есть "разделяемые" объектные файлы (so), которые НЕ встраиваются в конечный бинарный файл проги. Догадайся, на каком языке такие файлы делают?

AVC>А такие языки, как Си++, порождают необязательные уродства вроде OLE и COM.

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

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

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

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

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

AVC>>Раздельно-компилируемые модули и загружать можно по отдельности.

Д>насколько мне известно, в Линуксе уже давным-давно есть "разделяемые" объектные файлы (so), которые НЕ встраиваются в конечный бинарный файл проги. Догадайся, на каком языке такие файлы делают?

Язык и ОС Оберон созданы к середине 1988 г. (Конечно, они и дальше развивались и развиваются.)
Это можно было бы учесть при произнесении слов "давным-давно".
В Обероне все модули загружаются таким способом, и это не вызывает никаких проблем.
Об этом даже не задумываешься. Пишешь просто IMPORT, и используй дополнительные возможности на здоровье!
А если нужно использовать, к примеру, COM, то для начала надо прочесть хотя бы одну толстую книгу. Да и то...
Естественным способом использования объектов это не назовешь.
ИМХО, разница огромная.

Что касается so-файлов, то я ими не пользовался. Уже поэтому интересно.
Отличаются ли они по использованию от DLL? В DLL, увы, нет контроля типов.
В Обероне же система всегда целостная и "типо-безопасная".

AVC>>А такие языки, как Си++, порождают необязательные уродства вроде OLE и COM.

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

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

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

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

AVC wrote:

> Об этом даже не задумываешься. Пишешь просто IMPORT, и используй
> дополнительные возможности на здоровье!

Баян — было за десять лет до этого (в Аде).

> А если нужно использовать, к примеру, COM, то для начала надо прочесть
> хотя бы одну толстую книгу. Да и то...
> Естественным способом использования объектов это не назовешь.

А вот программистам на VB/Delphi почему-то это не сказали....

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

AVC wrote:

> Вместе с тем, то, *как именно* Вирт соединил эти идеи, имеет огромное
> значение. Я не представляю, кто бы еще мог решить эту задачу так
> просто (и, ИМХО, очень красиво).

Flame on: Anders Hejlsberg (создатель Дельфи).

Если говорить про паскалевидные компонентные языки, то Дельфи — самый
удачный из них. И намного более юзабельный, кстати (без идиотских
идеологических решений типа отсутствия break/continue для циклов).

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

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

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

AVC>>>Если Вас это удивило, то Вы — наивный (в хорошем смысле) человек.
AVC>>>Я Вам скажу, почему Оберон не упоминается. Это противоречило бы всей рекламной кампании Sun, прошедшей под лозунгом "Нигде кроме, как в Моссельпроме" , утверждающей, что Ява — абсолютно новая разработка, не имеющая аналогов.

AF>> А сам Вирт много упоминает о языках или людях — чьи идеи он черпал? Или его рекламная компания Oberon'ов чем то уступает рекламе Java (кроме вложеных денег)?

AVC>Отвечу именно на этот вопрос. Тогда, надеюсь, станет моя позиция станет яснее.
AVC>Когда тема заимствований из Оберона в Java всплыла впервые (где-то уже с год назад) я написал, что дело не в том, что в Java заимствованы идеи из Оберона ("заимствование означает уважение"), а в том, как это было сделано: без упоминания главного источника. ИМХО, это уже не заимствование, а воровство.

Вот именно — важно именно то, как было сделано заимстование Но ещё важнее то, как была получена информация о том, что именно из Оберона было сделано заимствование. Пока что фактов и доказательств я не видел. Только догадки и голословные утверждения. Есть понятие презумпции невиновности, а вы обвинили Гослинга не приводя фактов

Последователи Вирта делают вид, как будто именно Вирт изобрёл виртуальную машину, поминая при этом P-код. Однако теоретические работы в этой области относятся к началу 60-х, когда проводили расчёты оптимальных систем команд, с точки зрения размера команды, количества команд и энерго потребления. Тогда же появились и идеи виртуальных машин. Первые реализации появились в середине 60-х годов, но в те годы они требовали слишком много ресурсов — потому не имели практической ценности. Тогда же появились и идеи динамической компиляции. Именно тогда, а не как утверждается апологетами Вирта в середине 90-х. Притом данные факты признавал сам Вирт.

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

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

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

VD>>Здравствуйте, Сергей Губанов, Вы писали:

VD>>Ограничение на количество потоков в Виндовс есть, но объясняется оно не размерами стэка, а тем, что для каждого потока нужно хранить определенный объем невыгружаемой памяти. Короче просто захардкодено. Если не ошибаюсь, Русиновичь это раскапывал как-то.

VD>>Вот здесь я с ходу нашел упоминание о том, что орлы в тесте создали около 10 000 потоков.

AF> А точнее говоря, Windows использует аппаратные средства процессоров 386+, которые предусматривают поддержку 16384 потоков (тогда считалось, что это огромный запас, позже — что поток ресурс дорогой и просто так их создавать не следует). Кроме того, часть потоков зарезервирована для ядра и для общего пользования остаётся (если я не ошибаюсь) что то около 12000 потоков.

Я ошибся. В действительности ситуация несколько сложнее... В результате повторного изучения трактатов 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 процесс. Правда Русинович утверждает, что Windows использует несколько дескрипторов для каждого процесса, так что, видимо, в действительности процессов в Windows всё же меньше, чем это, максимально возможное (и поддерживаемое аппаратно) количество.

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

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

>> Об этом даже не задумываешься. Пишешь просто IMPORT, и используй
>> дополнительные возможности на здоровье!

C>Баян — было за десять лет до этого (в Аде).

А еще раньше — в Модуле-2.

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

>> Вместе с тем, то, *как именно* Вирт соединил эти идеи, имеет огромное
>> значение. Я не представляю, кто бы еще мог решить эту задачу так
>> просто (и, ИМХО, очень красиво).

C>Flame on: Anders Hejlsberg (создатель Дельфи).

C>Если говорить про паскалевидные компонентные языки, то Дельфи — самый
C>удачный из них. И намного более юзабельный, кстати (без идиотских
C>идеологических решений типа отсутствия break/continue для циклов).

Хорошо, вернусь на минуту к теме синтаксического минимализма и скажу пару слов по поводу break.
Предположим, я вижу некий цикл на Обероне.
Что-то вроде

WHILE cond DO
...тут тело цикла
END;
(* точка A, следующая за циклом *)

Читая этот текст, я уверен, что если я попаду в точку A, то там будет верным утверждение ~cond.
Это очень помогает быстро разобраться в программе.
А вот если я читаю текст на Си/Си++, то такой уверенности нет, т.к. из цикла можно выйти и другим путем — с помощью break или даже goto.
Значит, я должен лезть в тело цикла и выискивать там возможные break и goto.
Такое вот синтаксическое удобство.

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

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

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

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

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

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

C>>Если говорить про паскалевидные компонентные языки, то Дельфи — самый
C>>удачный из них. И намного более юзабельный, кстати (без идиотских
C>>идеологических решений типа отсутствия break/continue для циклов).

AVC>Хорошо, вернусь на минуту к теме синтаксического минимализма и скажу пару слов по поводу break.
AVC>Предположим, я вижу некий цикл на Обероне.
AVC>Что-то вроде
AVC>

AVC>WHILE cond DO
AVC>  ...тут тело цикла
AVC>END;
AVC>(* точка A, следующая за циклом *)
AVC>

AVC>Читая этот текст, я уверен, что если я попаду в точку A, то там будет верным утверждение ~cond.
AVC>Это очень помогает быстро разобраться в программе.
AVC>А вот если я читаю текст на Си/Си++, то такой уверенности нет, т.к. из цикла можно выйти и другим путем — с помощью break или даже goto.
AVC>Значит, я должен лезть в тело цикла и выискивать там возможные break и goto.
AVC>Такое вот синтаксическое удобство.

Ага... Берём и дорабатываем напильником.

VAR brokenglass:BOOLEAN; (* выдернуть шнур, выдавить стекло *)
.....
(* двадцать строк спустя *)
brokenglass := FALSE;
WHILE NOT brokenglass & cond DO
  .....
  brokenglass := TRUE; (* типа, break сделали *)
  .....
END;

Постусловие цикла — brokenglass|~cond. И что, это сильно облегчило нам жизнь? Наоборот, усложнило.

Паттерн программирования "break", элементарно воплощённый в turbo pascal / delphi, теперь эмулируется.
Нужно сперва вручную его прописывать (а рукоделие — это всегда повод для ошибок), причём можно это сделать многими разными способами (ещё один повод для ошибок).
А потом, читая код, придётся его же распознавать — а, благодаря вариативности, сделать это очень сложно (затрудняется отладка). Ещё догадайся, правда ли, что здесь именно эмуляция break, а не что-то иное. Ведь флаг можно повторно использовать.

А в языках, где break встроен в синтаксис, постусловие цикла формально звучит так: "или ложь в условии, или была достигнута одна из точек break в теле". Условия достижения этих точек можно выявить — не сложнее, чем найти, почему brokenglass взводится. Сравни:

   IF shortcut() THEN
     BREAK
   END;
   (* оставшаяся часть тела *)

   IF shortcut() THEN
     brokenglass:=TRUE (* здесь хоть брейкпоинт можно поставить *)
   END;
   IF ~brokenglass THEN (* оставшаяся часть тела *) END;

   brokenglass:=brokenglass|shortcut(); (* а это как отлаживать? *)
   IF ~brokenglass THEN (* оставшаяся часть тела *) END;

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

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

К>Ага... Берём и дорабатываем напильником.
К>

К>VAR brokenglass:BOOLEAN; (* выдернуть шнур, выдавить стекло *)
К>.....
К>(* двадцать строк спустя *)
К>brokenglass := FALSE;
К>WHILE NOT brokenglass & cond DO
К>  .....
К>  brokenglass := TRUE; (* типа, break сделали *)
К>  .....
К>END;
К>

К>Постусловие цикла — brokenglass|~cond. И что, это сильно облегчило нам жизнь? Наоборот, усложнило.

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

  (* локальная процедура *)
  PROCEDURE LoopWasBroken (* здесь какое-нибудь содержательное имя *) (): BOOLEAN;
  BEGIN
    WHILE cond DO
      НачалоТелаЦикла;
      IF ЧтоТоУжасное THEN
        RETURN TRUE
      END;
      КонецТелаЦикла;
    END;
    RETURN FALSE
  END LoopWasBroken;
BEGIN
  ...
  IF LoopWasBroken THEN ОбработкаЭтойПечальнойСитуации END;

Статистика показывает, что число циклов LOOP...EXIT...END не превышает 10% (9,1%). Для чего портить остальные 90% циклов?

Собственно, "мой ответ 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;

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

AVC>недоумение, что упоминания об Обероне он не нашел.

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

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

AVC>Язык и ОС Оберон созданы к середине 1988 г. (Конечно, они и дальше развивались и развиваются.)
AVC>Это можно было бы учесть при произнесении слов "давным-давно".

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

AVC>Отличаются ли они по использованию от DLL? В DLL, увы, нет контроля типов.

практически не отличаются

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

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

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

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

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

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

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

Автор: Дарней
Дата: 28.09.05

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

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Продуктом независимой компиляции являются lib или obj файлы, которые на исполнение запустить нельзя (не известно где взять f() функцию), предварительно, т.е. перед исполнением, нужно слинковать все независимо скомпилированные объектные файлы. Вот на этой-то стадии и ищется f() (везде), проверяется, что f() определена именно так как указано и всего один раз, а не несколько. В результате получается исполнимый файл exe или dll.

СГ>Продуктом раздельной компиляции является непосредственно исполнимый модуль (в BlackBox — это файл с расширением ocf, который есть light weight аналог dll-файла).

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

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

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

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

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

Что и неудивительно! Анализировались десятки языков. В том числе и Оберон. То, что он не упомянут, может (и наверняка) являться баналным следствием того, что он не был главным источником идей и даже — среди основных! Только и всего. Главным источником был C++, о чём они и пишут.

Почему то вы зациклились на том, что раз Оберон был раньше, чем Java то значит Гослинг и подумать не о чём другом не мог, как пуская похотливые слюни — спереть Оберон — по ходу уродуя его C++ подобным синтаксисом.

И вы и другие сторонники Вирта и сам Вирт — стыдливо умалчиваете о простейшем факте, а сменно: Если бы Sun настолько была восхищена Обероном, то она могла бы им воспользоваться сразу, не тратя деньги и без риска им воспользовавшись сразу. Оберон не был защищён какими-либо авторскими правами и препятствий комерческого, лицензионного или иного рода просто не существовало. Яркий пример тому — Pascal и Delphi, да и современный Оберон. Sun не взяла Оберон просто потому, что он не был ей нужен. Вот и всё!

Кроме того, вы банально не учитываете психологию разработчиков! Фактор NIH (not-invented-here), гораздо более известный, как пламенная любовь к велосипедо-строению. Вы думаете Гослингу нужен был какой-то паршивый Оберон с ужасным синтаксисом — который, к тому же, выдавали за верх совершенства? Ему (как и почти всем талантливым создателям в IT) был нужен собственный велосипед — даже ценой провала проекта. Вот потому он и не взял бы Оберон — хотя бы ему его и впаривали. И любой, кто хорошо знаком с разработкой ПО — может сам оценить — насколько часто бывает именно так (даже вопреки любому здравому смыслу). Да что говорить — мы общаемся на сайте велосипедостроителей! Возьмите сам проект — RSDN или R#. Это тоже велосипеды. Если бы команда RSDN рассуждала так, как вы с Обероном, то RSDN вообще не появился бы — ибо он повторял множество других сайтов и форумов — которые уже были.


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

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

А вы точно знаете что оберон был первой объектной средой с метаинформацией?

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

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

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

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

Автор: AVC
Дата: 30.09.05

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