Re[27]: Публичное утверждение - Философия программирования

Здравствуйте, 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#
Модульность и раздельная компиляция     Нет         Да      Да        Да
Сборка мусора                           Нет         Да      Да        Да
Наследование                            Мн.         Од.     Од.       Од.
Виртуальная машина                      Нет         Да      Нет       Да
Отражение                               Нет         Да        Нет       Да
Доступ к регистрам и памяти             Да          Нет     Да        Да

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

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

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

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

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

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

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)

Posted via RSDN NNTP Server 2.0 beta

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

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

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

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

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

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

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

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

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

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

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

... << RSDN@Home 1.1.4 stable rev. 510>>

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

Д>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что же касается ссылки на спецификацию языка, то в истории проекта 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>А вообще, очень рад тебя слышать.

Взаимно!

... << RSDN@Home 1.1.4 stable rev. 510>>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

... << RSDN@Home 1.1.4 stable rev. 510>>

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

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

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

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

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

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

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

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

Не совсем, в обероне только для сиситемных вещей. Опять же использование манагед сред нативных библиотек хотя и снижает риск, но полностью его не устраняет. Пример RSDN хоум, где узкие места представляют именно нативный код.

... << RSDN@Home 1.1.4 stable rev. 510>>

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

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

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

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

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

Здравствуйте, 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>Не обижайтесь, Андрей, но Ваш пост получился весьма забавным.

Хотя бы повеселил. Уже хорошо.

AF>>С++. Добавьте сборку мусора, блоки инициализации, уберите указатели, шаблоны, макросы, переопределение операторов и delete и получаем Java

AVC>Можно оставить указатели и вернуть всем этим "новшествам" Явы родной паскалевский синтаксис.
AVC>Перед Вами портрет Оберона.

AF>>ИМХО в обероне придётся для этого поменять гораздо больше.

AVC>Неужели вернуть паскалеподобный синтаксис — больше, чем
AVC>

AVC>добавить сборку мусора, блоки инициализации, убрать указатели, шаблоны, макросы, переопределение операторов и delete

AVC>?!

AVC>Ну, попробуйте исполнить в Си++ хотя бы первое (добавить сборку мусора).

Очень сомневаюсь. Я не знаток оберона, но сам факт того, что великий и ужастный регулярно СГ хвастается тем, что в обероне фича X есть, а в поганом C# и Java — её нет, уже говорит о том, что как минимум в Обероне есть что-то ещё, кроме описанного выше.

AF>>Идею сборщика мусора придумали до Вирта, первые работы на эту тему были аж в 50-х.

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

Во первых до оберона был Algol 68 (об этом уже писали), а во-вторых, это вовсе не означает, что Java была срисована именно с Оберона. Если вы знаете идея общей шины и единого набора команд впервые была явлена массам в IBM-360, однако появилась значительно раньше (начало 50-х) и современные микропроцессоры вовсе не развивались именно оттуда. Да, идеи были взяты и из IBM-360 и теоретических работ и много ещё откуда, но прямого копирования или развития не было.

Подозреваю, что аналогичная ситуация была и с Java. К примеру те же лекции по оберону я послушал бы уже хотя бы ради того, что бы представлять, какие сложности могут возникнуть на этапе построения системы с использованием языка — то есть в JDK, а вовсе не в самой Java. Игорь здесь приводит хронологию, которая как раз подтверждает эту версию

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

AVC>Ну, попробуйте исполнить в Си++ хотя бы первое (добавить сборку мусора).
Без проблем: http://www.hpl.hp.com/personal/Hans_Boehm/gc/

#include "gc.h"
#include <assert.h>
#include <stdio.h>

int main()
{
  int i;

  GC_INIT();    /* Optional on Linux/X86; see below.  */
  for (i = 0; i < 10000000; ++i)
   {
     int **p = (int **) GC_MALLOC(sizeof(int *));
     int *q = (int *) GC_MALLOC_ATOMIC(sizeof(int));
     assert(*p == 0);
     *p = (int *) GC_REALLOC(q, 2 * sizeof(int));
     if (i % 100000 == 0)
       printf("Heap size = %d\n", GC_get_heap_size());
   }
  return 0;
}

Реально использовал в достаточно сложном приложении — проблем никаких.

.
GN>А теперь, сравним с таким:
GN>X + Y => Z
GN>Такая запись в точности соответствует поставленной задаче, кроме того, она читается последовательно слева направо. В классической записи нам приходится "запоминать" куда же сохранится разультат, а потом "вспоминать", когда мы дошли до конца выражения. Следствием этого является и усложнение синтаксического анализатора в компиляторе.
Надеюсь меня можно считать человеком?

Как по мне, так
Z = X + Y
Z := X + Y
куда естественнее чем
X + Y => Z

Даже с той же точки зрения математики (не навороченной а простой, соответствующей уровню Z = X + Y) запись X + Y => Z выглядит как криво записанное неравенство X + Y больше либо равно Z. Также неестественны записи вида 5 => x тогда как х = 5 — естественна.
Естественность разумеется рассматривается с точки зрения чтения человеком. Поскольку машине все равно, естественна запись или нет — она ее все равно по правилам заданной ей грамматики читает

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

CC>Надеюсь меня можно считать человеком?

CC>Как по мне, так
CC>Z = X + Y
CC>Z := X + Y
CC>куда естественнее чем
CC>X + Y => Z

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

ИМХО мы просто путаем понятное и привычное

.

CC>Даже с той же точки зрения математики (не навороченной а простой, соответствующей уровню Z = X + Y) запись X + Y => Z выглядит как криво записанное неравенство X + Y больше либо равно Z.

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

Кстати, SourceInsight может показывать опрации присваивания в таком виде:
Z <- X + Y
(стрелочка там конечно не ASCII)
Так что все дебаты по поводу приимущества фаллического символа перед сишным "=" я считаю анахронизмом.

CC>Также неестественны записи вида 5 => x тогда как х = 5 — естественна.

Последняя запись естесствена для укзания того, что x равен 5. Где в ней скрытый смысл операции перемещения данных?

CC>Естественность разумеется рассматривается с точки зрения чтения человеком.

Поправлю — человека, не один год привыкшего так рассматривать запись.
Это важный момент. Он хорошо объясняет в том числе все эти holywar = vs :=

Почему никто из разработчиков массовых языков (читай — языков расчитанных на домохозяек) не догадался обратиться за советам к психологам, провести исследования, спросить у людей с незамыленым взглядом? А потом удивляются, мол, сделали язык, что бы домохозяйки могли стиральную машину программировать, а на нём могут писать лишь люди с нехилым опытом. Что-то я не вижу java в каждой кофемолке, как это обещали десять лет назад

.

На закуску — alma mater всех этих споров о естественностях:

mov r0, r1

А теперь вопрос: что куда помещается?

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

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

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

Вирт на такое никогда не пойдёт. В психологии есть такое понятие как ригидность, с возрастом она только усиливается.

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

GN>Так что все дебаты по поводу приимущества фаллического символа перед сишным "=" я считаю анахронизмом.

Хорошо сказано!

CC>>Также неестественны записи вида 5 => x тогда как х = 5 — естественна.
GN>Последняя запись естесствена для укзания того, что x равен 5. Где в ней скрытый смысл операции перемещения данных?

Ну, присваивание не всегда является перемещением. Скорее это копирование

За скрытым смыслом это не ко мне. Я практик. Я языки программирования использую для выражения нужных мне от компа действий.

GN>На закуску — alma mater всех этих споров о естественностях:
GN>

GN>mov r0, r1
GN>

А теперь вопрос: что куда помещается?

В зависимости от ассемблера

Есть и r0->r1 и r1->r0 варианты.
для x386: r1->r0 а для DEC: r0->r1

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

CC>>>Также неестественны записи вида 5 => x тогда как х = 5 — естественна.
GN>>Последняя запись естесствена для укзания того, что x равен 5. Где в ней скрытый смысл операции перемещения данных?

CC>Ну, присваивание не всегда является перемещением. Скорее это копирование

Согласен, я ошибся в выборе термина.

GN>>На закуску — alma mater всех этих споров о естественностях:
GN>>

GN>>mov r0, r1
GN>>

А теперь вопрос: что куда помещается?

CC>В зависимости от ассемблера

CC>Есть и r0->r1 и r1->r0 варианты.
CC>для x386: r1->r0 а для DEC: r0->r1

Так о чём и речь! Абсолютно уверен, что для придумавших это людей всё было совершенно естественно. Но почему тогда они такие разные

PS: Вы даже незаметно (?) для себя использовали мой вариант записи копирования

. r0->r1

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

CC>>Z := X + Y
CC>>куда естественнее чем
CC>>X + Y => Z

GN>Полностью согласен, и я тоже так считаю.
GN>Но провёл простой эксперимент — спросил ребёнка что он думает по этому поводу (знак "=>" был заменён на обычную стрелочку).

Занятно. Smalltalk, который в процессе разработки постоянно "испытывали на детях", для знака присваивания использовал именно "стрелочку". Только, всё же, в более классическом варианте z <- x + y. Что, в профессиональных диалектах таки трансформировалось в :=.
Чем-то это напоминает вопрос о записи if и while после действий вместо "нормального".

GN>ИМХО мы просто путаем понятное и привычное

.

Похоже — да.
Привычка — вторая натура, однака.

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

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

Д>

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

Каким образом получить доступ к регистрам CPU в C++ ?

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

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

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

Спасибо за информацию!
Похоже, я должен взять свои слова (о том, что Оберон был первым компилируемым языком со сборкой мусора) назад.
Действительно, по указанным Вами ссылкам я нашел упоминания о сборке мусора в языках PL/I и Algol-68.
Жаль, что эта информация весьма скупая. Я не смог пока составить себе представления о механизмах сборки мусора в
этих языках. Но сборка мусора упоминается, это факт.
Насчет скупости информации. Интересно, что дома у меня завалялась старая книжка по Алголу-68; в ней сборщик мусора вообще не был упомянут. Прямо военная тайна какая-то.

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

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

AVC>>Ну, попробуйте исполнить в Си++ хотя бы первое (добавить сборку мусора).
C>Без проблем: http://www.hpl.hp.com/personal/Hans_Boehm/gc/

C>

C>#include "gc.h"
C>#include <assert.h>
C>#include <stdio.h>

C>int main()
C>{
C>  int i;

C>  GC_INIT();    /* Optional on Linux/X86; see below.  */
C>  for (i = 0; i < 10000000; ++i)
C>   {
C>     int **p = (int **) GC_MALLOC(sizeof(int *));
C>     int *q = (int *) GC_MALLOC_ATOMIC(sizeof(int));
C>     assert(*p == 0);
C>     *p = (int *) GC_REALLOC(q, 2 * sizeof(int));
C>     if (i % 100000 == 0)
C>       printf("Heap size = %d\n", GC_get_heap_size());
C>   }
C>  return 0;
C>}
C>

C>Реально использовал в достаточно сложном приложении — проблем никаких.

Для меня это действительно интересная информация.
Последняя фраза даже вогнала меня в краску.

Почему-то мне до сих пор просто не пришло в голову использовать сборщик мусора Боэма в своих программах на Си/Си++.

Я ограничивался мыслью: так ведь это консервативный (не "прецизный") сборщик мусора, не весь мусор соберет...
я уж сам как нибудь...
Глупость какая-то!

В любом случае, это лучше, чем ничего! (Речь, конечно, о достаточно сложных программах.)
Возможно, в какой-то степени я упустил из виду одну из тенденций последнего времени. Не всегда все надо делать на 100%: сжатие с потерями, рандомные алгоритмы (например, тест числа на "простоту" у Миллера и Рабина), консервативный сборщик мусора.
Надо будет над этим подумать.

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

AVC>Возможно, в какой-то степени я упустил из виду одну из тенденций последнего времени. Не всегда все надо делать на 100%: сжатие с потерями, рандомные алгоритмы (например, тест числа на "простоту" у Миллера и Рабина), консервативный сборщик мусора.
AVC>Надо будет над этим подумать.

Сюда же можно добавить "ленивые" вычисления и т.д. и т.п.

Что касается сборщика мусора в Си/Си++.
Конечно я имел в виду "прецизный" ("точный", "аккуратный" и т.п.; tracing garbage collector) сборщик мусора, наподобие обероновского.
(Не уверен, что сборщик мусора в Алгол-68 именно такой. Уверен, что в Си/Си++ такой сборщик мусора — на сегодня — невозможен.)
Просто сейчас мне пришла в голову мысль: а не "завышены" ли мои требования? М.б. и правда консервативного сборщика мусора вполне достаточно в большинстве случаев?

Это не к Вирту, а к Муру (автору Форта).

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

GN>Каким образом получить доступ к регистрам CPU в C++ ?

__asm mov ax, my_var

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

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

GN>PS: Вы даже незаметно (?) для себя использовали мой вариант записи копирования

. r0->r1
Отнюдь не незаметно.

Как можно это не заметит когда только что о такой форме записи шла речь?

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

GN>Но провёл простой эксперимент — спросил ребёнка что он думает по этому поводу (знак "=>" был заменён на обычную стрелочку).

GN>ИМХО мы просто путаем понятное и привычное

.

Код на Рапире:

A+B->C

почти идеальный язык для обучения детей. Жаль, что заброшен.

Возможно мне изменяет память, но не было в PL/I сборки мусора.
Что касается Algol-68, там было очень много интересных нововведений. Но к тому времени, как появились первые полноценные компиляторы, он уже стал историей.

Скорее всего главный претендент в номинации "первый компилируемый язык со сборкой мусора" — Симула-67.

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

Т>Возможно мне изменяет память, но не было в PL/I сборки мусора.

Мне тоже кажется, что не было. Если не ошибаюсь, в PL/1 вообще впервые появилась возможность динамического выделения/освобождения памятью, но о сборке мусора там я никогда ничего не слышал. И в оставшихся с тех времен книгах на эту тему нет ни слова. Вот с Algol-ами всеми сразу я разминулся — у нас все читалось на базе сначала Фортрана, а потом — Pl/1.

AVC wrote:

> Что касается сборщика мусора в Си/Си++.
> Конечно я имел в виду "прецизный" ("точный", "аккуратный" и т.п.;
> tracing garbage collector) сборщик мусора, наподобие обероновского.

В той реализации Оберона, которую я смотрел, нет полностью точного
сборщика GC. Он там "mostly precise" — куча собирается точно, но стек
рассматривается консервативно. Boehm GC так тоже умеет.

> (Не уверен, что сборщик мусора в Алгол-68 именно такой. Уверен, что в
> Си/Си++ такой сборщик мусора — на сегодня — невозможен.)

В C++/CLI будет возможен.

> Просто сейчас мне пришла в голову мысль: а не "завышены" ли мои
> требования? М.б. и правда консервативного сборщика мусора вполне
> достаточно в большинстве случаев?

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

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

Posted via RSDN NNTP Server 2.0 beta

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

AVC>>[code]
AVC>> Си++ Java Oberon
AVC>>Модульность и раздельная компиляция Нет Да Да

Если вспомнить о dll, то раздельная компиляция в С++ есть

AVC>>Шаблоны Да Нет Нет

Начиная с 1.5 в Java средства обобщеного программирования присутствуют

AVC>>Наследование Мн. Од. Од.

В Java есть множественное наследование интерфейсов.

... << RSDN@Home 1.2.0 alpha rev. 617>>

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

GN>>Каким образом получить доступ к регистрам CPU в C++ ?

Д>

Д>__asm mov ax, my_var

Вы всерьёз утверждаете, что это С++ ?

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

Т>Код на Рапире:
Т>

Т>A+B->C

Т>почти идеальный язык для обучения детей. Жаль, что заброшен.

Как всегда, всё уже украдено до нас.

А вокруг всё не утихали споры, что первично, яйцо или курица

...

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

GN>Вы всерьёз утверждаете, что это С++ ?

Определенно не Оберон

Суть в том, что в С++ есть простая и удобная интеграция с асмом, которая позволяет делать такие вещи без усилий. В Яве например такой интеграции нет — что и неудивительно, учитывая требования, которые предъявлялись к языку.

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

Здравствуйте, Дарней,

GN>>Вы всерьёз утверждаете, что это С++ ?

Д>Определенно не Оберон

Уже больше похоже на правду — утверждения, что это С++ нет

.

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

Ну так давайте будем называть вещи своими именами

— доступ к регистрам обеспечивает ассемблер. Про простоту и удобство ИМХО немного преувеличено, только начнёшь его использовать более-менее серьёзно в том же MSVC/ICC, как компилятор бьёт по рукам вразумительным сообщением "internal compiler error".

Д>В Яве например такой интеграции нет — что и неудивительно, учитывая требования, которые предъявлялись к языку.

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

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

GN>Ну так давайте будем называть вещи своими именами

— доступ к регистрам обеспечивает ассемблер.

обычно под любым языком понимается не только собственно язык, но и совокупность стандартных для него средств. Тот же самый reflection обеспечивается никак не самим C#, а CLI. Тем не менее, когда говорят, что в C# есть reflection, все прекрасно понимают, о чем идет речь.

GN>Про простоту и удобство ИМХО немного преувеличено, только начнёшь его использовать более-менее серьёзно в том же MSVC/ICC, как компилятор бьёт по рукам вразумительным сообщением "internal compiler error".

всё познается в сравнении

GN>А теперь вопрос: можно ли получить доступ к регистрам в кроссплатформенном коде на С++?

.

Я думаю, если написать несколько #ifdef, то можно

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

Здравствуйте, Дарней, Вы писали:
Д>Суть в том, что в С++ есть простая и удобная интеграция с асмом, которая позволяет делать такие вещи без усилий.
Гм. У меня вопрос: что будет, если я попробую скомпилировать этот код для таргет платформы... ну, скажем, хотя бы Intel 80c31?
У меня (и не только) есть глубокое подозрение, что ты называешь "С++" не совсем тот язык.

... << RSDN@Home 1.1.4 stable rev. 510>>

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

S>Гм. У меня вопрос: что будет, если я попробую скомпилировать этот код для таргет платформы... ну, скажем, хотя бы Intel 80c31?

Если ты скомпилируешь любой свой код (pure C++, безо всякого asm interop) под эту платформу, нет абсолютно никакой гарантии, что он там заработает. И даже — что он там вообще скомпилируется. Если конечно предположить, что ты не закладывал совместимость именно с этой платформой в свой код.
Надо просто понимать, что никакой "полной" кроссплатформенности у C++ нет — есть только та, которую ты закладываешь в свой код сам.

S>У меня (и не только) есть глубокое подозрение, что ты называешь "С++" не совсем тот язык.

А ты уверен, что "C++" — это единый язык? Есть конечно стандарт, но много ли компиляторов, которые полностью ему удовлетворяют? И много ли кода, который не нарушает стандарт и не использует никаких платформо-зависимых вещей?

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

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

>> Что касается сборщика мусора в Си/Си++.
>> Конечно я имел в виду "прецизный" ("точный", "аккуратный" и т.п.;
>> tracing garbage collector) сборщик мусора, наподобие обероновского.

C>В той реализации Оберона, которую я смотрел, нет полностью точного
C>сборщика GC. Он там "mostly precise" — куча собирается точно, но стек
C>рассматривается консервативно. Boehm GC так тоже умеет.

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

Но вряд ли Boehm умеет "прецизно" работать с сегментом данных.

C>В C++/CLI будет возможен.

Си++ — всегда большие надежды.

>> Просто сейчас мне пришла в голову мысль: а не "завышены" ли мои
>> требования? М.б. и правда консервативного сборщика мусора вполне
>> достаточно в большинстве случаев?

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

Спасибо за информацию.
По крайней мере, у меня появилась новая идея.

P.S. Еще раз прошу прощения у тех, кому пока не успел ответить.

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

AVC>>>[code]
AVC>>> Си++ Java Oberon
AVC>>>Модульность и раздельная компиляция Нет Да Да

AVK>Если вспомнить о dll, то раздельная компиляция в С++ есть

Это скорее старая добрая независимая компиляция.
Разве есть в DLL контроль типов?

AVC>>>Шаблоны Да Нет Нет

AVK>Начиная с 1.5 в Java средства обобщеного программирования присутствуют

И вызывают большие нарекания.

В любом случае, это не шаблоны.

AVC>>>Наследование Мн. Од. Од.

AVK>В Java есть множественное наследование интерфейсов.

Эта идея в Java действительно новая и, похоже, неплохая.

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

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

CC>>Надеюсь меня можно считать человеком?

CC>>Как по мне, так
CC>>Z = X + Y
CC>>Z := X + Y
CC>>куда естественнее чем
CC>>X + Y => Z

GN>Полностью согласен, и я тоже так считаю.
GN>Но провёл простой эксперимент — спросил ребёнка что он думает по этому поводу (знак "=>" был заменён на обычную стрелочку).

GN>ИМХО мы просто путаем понятное и привычное

.

Тут есть еще один ньюанс. Дело не только в прозрачности записи. При анализе кода я, например, часто выполняю такую задачу: найти место, где переменной Z присваивалось значение. В силу многолетней привычки поиск я осуществляю слева направо. Соответствено с случае Оператора := мне прийдется смотреть строку только до этого оператора и я сразу определю, какой переменной присваивается значение. А вот в случае использования -> мне прийдется бегать глазами по невыровненой правой части выражений.

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

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

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

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

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

GN>>Ну так давайте будем называть вещи своими именами

— доступ к регистрам обеспечивает ассемблер.

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

Как может быть стандартным средством ассемблер, если процессоры все "нестандартные"?

. Ну есть в языке ключевое слово asm, которое добрая половина компиляторов, включая распространённые для windows, не поддерживает. Остальное-то — implementation defined.

Д> Тот же самый reflection обеспечивается никак не самим C#, а CLI. Тем не менее, когда говорят, что в C# есть reflection, все прекрасно понимают, о чем идет речь.

Прошу прощения за глупый (от незнания) вопрос: а в других (каких?) языках транслируемых в cli эта штука есть? В Component Pascal думаю нет

.

GN>>Про простоту и удобство ИМХО немного преувеличено, только начнёшь его использовать более-менее серьёзно в том же MSVC/ICC, как компилятор бьёт по рукам вразумительным сообщением "internal compiler error".

Д>всё познается в сравнении

Не совсем понятно, что с чем сравнивать

. По сравнению со standalone ассемблерами, __asm в MSVC/ICC не выдерживает никакой критики — куча ограничений + множество багов. Вот на вскидку пара вещей, транслируемых неверно:

mov eax, $              ; mov eax, 0
mov eax, [ecx][0*edx]   ; mov eax, [ecx][ 1*edx]

GN>>А теперь вопрос: можно ли получить доступ к регистрам в кроссплатформенном коде на С++?

.

Д>Я думаю, если написать несколько #ifdef, то можно

Даже не буду упирать на CPU без регистров (например, исполняющие java bytecode

), скажу только, что для ряда процессоров нет возможности использовать asm в существующих для них компиляторах. Ну а для тех, где есть, количество #ifdef будет несколько больше, чем несколько

.

Резюме — если нужна кросплатформенность в С++, то забываем про asm. Нужна кросплатформенность в другом языке — тоже самое. Так что в качестве каких-то признаков генетического наследования регистры не уместны ИМХО.

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

GN>Прошу прощения за глупый (от незнания) вопрос: а в других (каких?) языках транслируемых в cli эта штука есть? В Component Pascal думаю нет

.

Я с ним тоже не знаком, но думаю, что есть. Никакой особой поддержки со стороны языка там не требуется.
Только не "транслируемые в CLI", а "работающие в среде CLI"

GN>Резюме — если нужна кросплатформенность в С++, то забываем про asm. Нужна кросплатформенность в другом языке — тоже самое. Так что в качестве каких-то признаков генетического наследования регистры не уместны ИМХО.

Ну ладно, как скажешь

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

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

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

GN>>ИМХО мы просто путаем понятное и привычное

.

M>Тут есть еще один ньюанс. Дело не только в прозрачности записи. При анализе кода я, например, часто выполняю такую задачу: найти место, где переменной Z присваивалось значение. В силу многолетней привычки поиск я осуществляю слева направо. Соответствено с случае Оператора := мне прийдется смотреть строку только до этого оператора и я сразу определю, какой переменной присваивается значение. А вот в случае использования -> мне прийдется бегать глазами по невыровненой правой части выражений.

В общем-то ответ находися в моей цитате выше.

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

Д>Пусть останется "прямой доступ к памяти и платформо-зависимым фичам"

Какже останется? Мы же говорим о кроссплатформенном языке

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

GN>Какже останется? Мы же говорим о кроссплатформенном языке

.

Язык — он такой, какой есть. Не очень то кроссплатформенный

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

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

Д>Язык — он такой, какой есть. Не очень то кроссплатформенный

А если захотели мы кросплатформенность получить? (java)

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

GN>А если захотели мы кросплатформенность получить? (java)

вот-вот. если захотели — то получили Яву
в С++ слишком много неочевидных граблей

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

AVC wrote:

> C>В той реализации Оберона, которую я смотрел, нет полностью точного
> C>сборщика GC. Он там "mostly precise" — куча собирается точно, но стек
> C>рассматривается консервативно. Boehm GC так тоже умеет.
> Действительно, кандидаты из стека выбираются "консервативно" (по
> крайней мере, в Компонентном Паскале).
> По-видимому, это реализационный компромисс.

Да, так как точная сборка стека (и регистров процессора) — это такой
маленький хвостик, который тянет за собой слона. Например, придется
придумывать pinned pointers для интероперабельности с нативным кодом,
защизенные секции и т.п. Для этого нужны изменения в яыке (который Вирту
не хочется менять, я так понимаю).

Вообще, сейчас только в C++/CLI нормально продумана интеграция GC и
нативного кода.

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

Умеет, умеет. Ему лишь надо указать формат объектов (то есть где в них
искать указатели) — этим успешно пользуются в Mono. С С++ это немного
неудобно, но тоже возможно.

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

Posted via RSDN NNTP Server 2.0 beta

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

Д>>Язык — он такой, какой есть. Не очень то кроссплатформенный

GN>А если захотели мы кросплатформенность получить? (java)

А ты попробуй j2ee приложение на j2me платформе запустить.

И Java и C++ -- кроссплатформенные языки. А вот отдельные программы на них совершенно не переносимы. И в C++ посредством директивы asm есть возможность такую программу при необходимости сделать.

... << RSDN@Home 1.1.4 stable rev. 510>>

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

E>И Java и C++ -- кроссплатформенные языки. А вот отдельные программы на них совершенно не переносимы. И в C++ посредством директивы asm есть возможность такую программу при необходимости сделать.

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

В С++ есть намного больше таких способов, чем в Java. Из них asm — еще самый безобидный, поскольку найти куски на асме можно простым текстовым поиском. Найти непереносимые фокусы с приведением типов, доступом к памяти, нарушения стандарта и т.п. — куда сложнее.

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

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

E>>И Java и C++ -- кроссплатформенные языки. А вот отдельные программы на них совершенно не переносимы. И в C++ посредством директивы asm есть возможность такую программу при необходимости сделать.

Д>Ты конечно прав. Но есть еще разница в том, насколько легко получить такую непереносимую программу на данном языке

Д>В С++ есть намного больше таких способов, чем в Java. Из них asm — еще самый безобидный, поскольку найти куски на асме можно простым текстовым поиском. Найти непереносимые фокусы с приведением типов, доступом к памяти, нарушения стандарта и т.п. — куда сложнее.

Подавляющее большинство этих проблем связано с тем, что программам на C++ приходилось напрямую работать с нативным API, который еще для C был расчитан. Были бы библиотеки типа ACE и Boost в C++ сразу (как JDK в Java), глядишь, и проблем с переносимостью C++ было бы на несколько порядков меньше.

... << RSDN@Home 1.1.4 stable rev. 510>>

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

E>Подавляющее большинство этих проблем связано с тем, что программам на C++ приходилось напрямую работать с нативным API, который еще для C был расчитан. Были бы библиотеки типа ACE и Boost в C++ сразу (как JDK в Java), глядишь, и проблем с переносимостью C++ было бы на несколько порядков меньше.

Кому-нибудь придет в голову сериализовать объекты, приводя указатель к void* и записывая блок памяти на диск — и всё, приплыли. Забудь про переносимость

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

Хотя "толстая" стандартная библиотека и правда уменьшила бы количество проблем на порядок. Эх, мечты.....

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

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

Д>Кому-нибудь придет в голову сериализовать объекты, приводя указатель к void* и записывая блок памяти на диск — и всё, приплыли. Забудь про переносимость

Ну это опять к вопросу полноты стандартной библиотеки

Д>Или кто-нибудь напишет очередной загиб на шаблонах, который просто не откомпилируется на другом компиляторе.

А вот это не корректно. Код для Java 1.5 на Java 1.4 не скопилируется. Так же, как и C# 2.0 и C# 1.0. Просто пока Java и C# настолько молоды и развиваются централизовано, что не появилось множества их независимых реализаций. Как только появятся (если появятся, конечно), так те же самые проблемы и возникнут.

... << RSDN@Home 1.1.4 stable rev. 510>>

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

E>А вот это не корректно. Код для Java 1.5 на Java 1.4 не скопилируется. Так же, как и C# 2.0 и C# 1.0. Просто пока Java и C# настолько молоды и развиваются централизовано, что не появилось множества их независимых реализаций. Как только появятся (если появятся, конечно), так те же самые проблемы и возникнут.

Ну не совсем так. У С++ проблема не в версиях стандартов, а в ее сложности — большинство компиляторов не полностью соотвествуют стандартам. У Явы и C# намного меньше всяких тонкостей и "особых случае", поэтому и объем спецификации намного меньше -> на порядок меньше проблем совместимости компиляторов.

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

Меня позабавила цитата:

Здесь надо сказать, что по сравнению с другими языками C++ имеет много недостатков, которые затрудняют разработку сложных научных программ. В частности, у него слабая поддержка одномерных и многомерных массивов, нет локальных процедур, неудачная концепция модуля, не поддерживается проверка индексов массивов, а также выполняется неконтролируемое преобразование типов.

http://alexcheremkhin.boom.ru/oberon.htm

sch wrote:

> Меня позабавила цитата:
>
>Здесь надо сказать, что по сравнению с другими языками C++ имеет много недостатков, которые затрудняют разработку сложных научных программ. В частности, у него слабая поддержка одномерных и многомерных массивов, нет локальных процедур, неудачная концепция модуля, не поддерживается проверка индексов массивов, а также выполняется неконтролируемое преобразование типов.
>
> http://alexcheremkhin.boom.ru/oberon.htm

А главный недостаток — в ламерах, которые в С++е не разбираются

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

Posted via RSDN NNTP Server 2.0 beta

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

Чем?

... << RSDN@Home 1.1.4 stable rev. 510>>

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

C>AVC wrote:

>> C>В той реализации Оберона, которую я смотрел, нет полностью точного
>> C>сборщика GC. Он там "mostly precise" — куча собирается точно, но стек
>> C>рассматривается консервативно. Boehm GC так тоже умеет.
>> Действительно, кандидаты из стека выбираются "консервативно" (по
>> крайней мере, в Компонентном Паскале).
>> По-видимому, это реализационный компромисс.

C>Да, так как точная сборка стека (и регистров процессора) — это такой
C>маленький хвостик, который тянет за собой слона. Например, придется
C>придумывать pinned pointers для интероперабельности с нативным кодом,
C>защизенные секции и т.п. Для этого нужны изменения в яыке (который Вирту
C>не хочется менять, я так понимаю).

Компиляторы Оберона (кроме версий,расчитанных на JVM и .NET) порождают нативный код.
В принципе, чтобы обеспечить точную сборку мусора для стека, язык менять не нужно.
Вот первое, что приходит в голову.
Компилятор Оберона обнуляет указатели (и процедурные переменные) при входе в процедуру.
Значит, знает их адреса.

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

C>Вообще, сейчас только в C++/CLI нормально продумана интеграция GC и
C>нативного кода.

Компилятор Оберона порождает нативный код. Так что его интеграция с GC — a priori.
Возможно, я просто недопонял последнее утверждение?

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

C>Умеет, умеет. Ему лишь надо указать формат объектов (то есть где в них
C>искать указатели) — этим успешно пользуются в Mono. С С++ это немного
C>неудобно, но тоже возможно.

Но чревато ошибками, как всякая ручная работа (и особенно — в Си++

).
В Обероне же это делает компилятор.

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

sch>Меня позабавила цитата:
sch>

sch>Здесь надо сказать, что по сравнению с другими языками C++ имеет много недостатков, которые затрудняют разработку сложных научных программ. В частности, у него слабая поддержка одномерных и многомерных массивов, нет локальных процедур, неудачная концепция модуля, не поддерживается проверка индексов массивов, а также выполняется неконтролируемое преобразование типов.
sch>

sch>http://alexcheremkhin.boom.ru/oberon.htm

???

AVC wrote:

> Компиляторы Оберона (кроме версий,расчитанных на JVM и .NET) порождают
> нативный код.
> В принципе, чтобы обеспечить точную сборку мусора для стека, язык
> менять не нужно.
> Вот первое, что приходит в голову.
> Компилятор Оберона обнуляет указатели (и процедурные переменные) при
> входе в процедуру.
> Значит, знает их адреса.

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

> Можно заодно его "попросить" заносить адреса указателей в специальную
> структуру (устроеную по принципу стека).
> При выходе из процедуры — просто сокращать этот второй стек.

Есть такой метод, вот тут он хорошо описан:
http://citeseer.ist.psu.edu/henderson02accurate.html

> Тогда в любой момент будут точно известны все локальные указатели, и
> сборку можно будет проводить точно, а не консервативно.
> Скорее всего, просто в этом нет необходимости.
> Удельная масса "корней" в стеке сравнительно невелика (по сравнению с
> числом нелокальных "корней").

Тут немного другие проблемы — сборка мусора в многотредовом приложении
может возникнуть в любой момент исполнения функции. Но это не всегда
безопасно.

Например, представим такой сценарий:

создать_новый_объект
pop ax ; В ax будет адрес нового объекта
<-- И тут врубается полный цикл GC, запущеный из другого потока
mov var_1,ax ;Запишем ax в переменную

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

Или другой вариант:

;В ax лежит адрес объекта
push ax ;Кладем его в стек
push some_parameter
<-- Приходит пушной зверек GC
call SomeFunction
...

Тут GC не увидит положенную в стек переменную.

Если используется передвигающий GC (moving GC), то такие ошибки будут
фатальны для программы.

Поэтому делают GC возможным только в специальных GC safepoint'ах (их
обычно расставляют в началах циклов, длинных ветвлений и т.п.) — для
каждого safepoint'а сохранена в виде таблиц точная информация о
состоянии стека и регистров в нем (stackmaps, register maps). Сразу
появляются проблемы: как заставить потоки остановиться в safepoint'ах,
как построить stackmap'ы с минимальным оверхедом и т.п. Поэтому точная
сборка стека — это и есть хвостик, тянущий за собой слона.

> C>Вообще, сейчас только в C++/CLI нормально продумана интеграция GC и
> C>нативного кода.
> Компилятор Оберона порождает нативный код. Так что его интеграция с GC
> — a priori.
> Возможно, я просто недопонял последнее утверждение?

Да, я другое имел в виду. Почитайте, хотя бы:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcmex/html/vclrf__pin.asp
и http://www.codeproject.com/dotnet/pointers.asp

> C>Умеет, умеет. Ему лишь надо указать формат объектов (то есть где в них
> C>искать указатели) — этим успешно пользуются в Mono. С С++ это немного
> C>неудобно, но тоже возможно.
> Но чревато ошибками, как всякая ручная работа (и особенно — в Си++ ).

Естественно.

> В Обероне же это делает компилятор.

Для GCC есть расширение, которые автоматически генерирует object map'ы.

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

Posted via RSDN NNTP Server 2.0 beta

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

Д>Оказывается, Ява — это испорченный Оберон. Чем дальше, тем лохмаче

Причем испорченый сишным синтаксисом. А все беды в мире от "х = у".

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

... << RSDN@Home 1.2.0 alpha rev. 618>>

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

Д>>Оказывается, Ява — это испорченный Оберон. Чем дальше, тем лохмаче

AVC>Есть возражения по существу?

Ага.

AVC>Hint: отвлекитесь от разницы Си-подобного и Паскале-подобного синтаксиса и сопоставьте конструкции языков.

Ты читал то внимательно? Напомню "Ява это Оберон испорченный С-шным синтаксисом". То есть основная проблема в синтаксисе!

AVC>Попробуйте указать другой язык-предшественник, с которым у Явы были бы такие большие совпадения.

Легко:
1. С/С++ — синтаксис.
2. Смолток — заимствование джит-компиляции, сборщика мусора, виртуальной машины.
3. Паскаль/Ада — заимствование идей безопастного программирования.

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

AVC>Лично я это проделал, у меня больших сомнений насчет Явы нет.

Да Вирт с Губавновым вобще сомневаются в том, что нужны какие-то языки кроме Оберона и Зенона. Ну, и что? Ты будешь третьим.

... << RSDN@Home 1.2.0 alpha rev. 618>>

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

AVC> Си++ Java Oberon
AVC>Модульность и раздельная компиляция Нет Да Да

А что Паскаль модули не использовал? Или других языков небыло? А я вот даже момню, что модулность в Бэйсике поддерживалась.

AVC>Шаблоны Да Нет Нет

Отсуствие н сегодня стало доказательством родства? А, ну, тогда начем с ассемблера и С в них тоже небыло ничерта. Так что с ними совпадений можно насчитать больше всего.

AVC>Сборка мусора Нет Да Да

Ой, а Смолток то ты куда подевал?

AVC>Деструкторы Да Нет Нет

Ой, и в С небыло.

AVC>Объединения (union) Да Нет Нет

Да, юнионы в С были. Но в ассемблере небыло.

AVC>Многомерные открытые массивы Нет Да Да

Погоди. В яве нет многомерных массивов. Кстати, как и в ассемблере.

AVC>Наследование Мн. Од. Од.

В Смолтоке тоже одиночное вроде.

AVC>Оператор goto Да Нет Нет

Ой, а в C# есть. Ну. слава богу хоть он доказано не от Явы или не дай бог Оберона произошел. И то радость.

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

А Оберон ночевал? Сопаденй столько скольк с ассемблером.

Яву проектировали анализируя целую кучу языков. Оберон был одним из них. Причем тем одним который не привнес ни одной конструкции или подхода которые не были бы известны до этого из других языков.

Твои аргументы просто смешны. Это чистая притягивание за уши.

... << RSDN@Home 1.2.0 alpha rev. 618>>

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

AVC>Разумеется, здесь перечислено далеко не все.
AVC>Например, в Java (как и в Обероне) нет адресной арифметики — "краеугольного камня" Си/Си++.

А в C# есть адресная арифметика, хотя она и не является краеуголным камнем. А ведь многие считают Шарп клоном Явы. Забавно, правда?

AVC>(Впрочем, в Java вообще нет указателей.

)

Ой. Несовпаденице. Теория рушится.

AVC>И т.д. и т.п.

Ага. Самому то не смешно?

... << RSDN@Home 1.2.0 alpha rev. 618>>

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

AVC>Возможно, она смотрится несерьезно.

AVC>Но практически за каждым указанным в ней синтаксическим ( ="внешним") отличием между Си++ и Java/Обероном стоит различие механизмов языков и соответствующего им рантайма ( ="внутренних", существенных особенностей).

А ты не задумывался, что различия с одной сущностью не доказывает схожести с другой?
Знашь как называется "логика" которую ты применяешь?

AVC>Возьмем, к примеру, отсутствие в Обероне и Java вариантных записей (union).

Класс! Эдак мы докажем, что у Явы и Эйфелевой башней много общего. Например, у них о обоих нет крыльев и хвоста.

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

), а вот Оберон и Java — сильно "привязаны" к безопасности типов.

Интересно, а вот в ОКамле есть нечто вроде юнионов, но по строгости типизации по сравнению с ним Ява и даже Оберон отдыхают по полной. И что?

AVC>Во-вторых, здесь есть прямая связь с реализацией сборки мусора.

Зашибись. В ОКамле есть сборка мусора и есть юнионы. Твоя теори разрушена. Идем дальше.

AVC> Дескриптор типа в Обероне включает не только адреса методов (type-bound procedures), но и смещения указателей в записи. Если бы во время исполнения программы по этому смещению могли находиться как указатель, так и переменная неуказательного типа, то механизм сборки мусора сильно бы усложнился, а то и вовсе стал бы труднореализуемым. Т.к. Вирт уже добавил в язык расширение типа ( =наследование), то потребность в вариантных записях, порождающих эти проблемы, отпала сама собой.

Проблемы реализации в обсуждении схожести языков? Прэлесно!

AVC>Но возникла другая проблема: а как эффективно определить динамический тип записи?

Да. Тут ты прав. Первые реализации Явы думали именно о эффективности. От того они наверно были интерпретаторами и делали все методы по умолчанию виртуальными. Просто полная аналогия с Обероном.

AVC>(Напомню, что факт принадлежности переменной к тому или иному динамическому типу требует всего одного сравнения.)

Это как-то следует из спецификации языка?

AVC>А табличка, возможно, и правда смотрится несерьезно.
AVC>Ну и Бог с ней.

Извини за прямоту, но притягиванием за уши она смотрится. Болше ничем (это если в мягких выражениях).

... << RSDN@Home 1.2.0 alpha rev. 618>>

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

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

Его нет в спецификации языка. В том время как в спецификациях C#, Явы и Смолтока рефлексия есть.

И вообще если посчитать количество фич повзаимствованных из языков, то окажется, что у Смолтока и С было повзаимствовано больше всего. А Оберон окажется в ряду тех кто взаимствовал.

... << RSDN@Home 1.2.0 alpha rev. 618>>

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

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

Я тоже так хочу.

Итак ассемблер:
1. Модульный потому как я так хочу. Смотри это сообщение.
2. Сборка мусора в нем возможна так как на на оссемблере можно все, и еще см. вот это.
3. Многомерные массивы на ассемблере возможны, так как на нем можно все.

Теперь о сходствах Оберона и ассеблера:
1. И у ассемблера, и у Оберона нет множественного наследования.
2. И у ассемблера, и у Оберона нет юнионов.
3. И у ассемблера, и у Оберона нет оперторов select.
4. И у ассемблера, и у Оберона нет обработки исключений.
5. И у ассемблера, и у Оберона нет... короче много чего нет.

Думаю этого достаточно чтобы сделать вывод, что Оберон является клонм ассемблера?

... << RSDN@Home 1.2.0 alpha rev. 618>>

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

AVC>Это скорее старая добрая независимая компиляция.
AVC>Разве есть в DLL контроль типов?

Ну, длл это конечно за уши притянуто. Правда у тебя вообще все за уши притянуто, и тебя это не смушает.

AVK>>Начиная с 1.5 в Java средства обобщеного программирования присутствуют

AVC>И вызывают большие нарекания.

AVC>В любом случае, это не шаблоны.

А ничего, что в Обероне нет даже дженериков, и что Вирт всячески от них открещивается? Хорошее такое сходство.

AVC>Эта идея в Java действительно новая и, похоже, неплохая.

Хм. А не из С++ ли она повзаимствована? Там вроде бы и МН было, и интерфейсы вроде как эмулировались очень давно. Ком появился в 93-ем, и в нем уже были интерфейсы эмулируемые на С++.

... << RSDN@Home 1.2.0 alpha rev. 618>>

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

sch>

sch>Здесь надо сказать, что по сравнению с другими языками C++ имеет много недостатков, которые затрудняют разработку сложных научных программ. В частности, у него слабая поддержка одномерных и многомерных массивов, нет локальных процедур, неудачная концепция модуля, не поддерживается проверка индексов массивов, а также выполняется неконтролируемое преобразование типов.

sch>http://alexcheremkhin.boom.ru/oberon.htm

И надо признать, что в отличии от той ахинеи что несется в этой ветке эти претензии не лешины смысла.

... << RSDN@Home 1.2.0 alpha rev. 618>>

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

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

Блин, нет слов. А что Ява сразу стала компилируемой? Она и в 1998 была интерпретируемой, и джит-компилятор который сейчас используется в реализации Явы от Сана был банально позаимствован... догадайся откуда? И Смолтока! Такого всего на свквозь инерпретироуемого.

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

В общем, кончай ридумывать. Связь меду Обероном и Явой только одна — это два языка поставивших во главу угла безопастность типов. Но таких языков далего не два. Их множество. И Ява брала лучшие (и не очень) черты из разных языков.

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

... << RSDN@Home 1.2.0 alpha rev. 618>>

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

AVC>Спасибо за информацию!
AVC>Похоже, я должен взять свои слова (о том, что Оберон был первым компилируемым языком со сборкой мусора) назад.

Ага. Как и все остальные.

AVC>Жаль, что эта информация весьма скупая. Я не смог пока составить себе представления о механизмах сборки мусора в
AVC>этих языках. Но сборка мусора упоминается, это факт.

А ничего что еще были компилируемые варианты Лиспа и Смолтока? И что в них тоже были сборщики мусора? И что они были куда раньше чем даже эти дремучие языки?

... << RSDN@Home 1.2.0 alpha rev. 618>>

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

Т>Скорее всего главный претендент в номинации "первый компилируемый язык со сборкой мусора" — Симула-67.

Напомни, мне когда появился первый компилятор Лиспа?

... << RSDN@Home 1.2.0 alpha rev. 618>>

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

Т>Код на Рапире:
Т>

Т>A+B->C
Т>

Т>почти идеальный язык для обучения детей. Жаль, что заброшен.

А для меня это выглядит как правило. Мол А+Ь это порождает правило С. В общем, любые знаковые записи являются всего лишь соглашениями к которым нужно просто привыкнуть. И все! Бессмысленно рассуждать о том, что ":=" лучше "=". Это кодирование и его нужно интерпретировать. Тут может помочь только привычка. Иначе нжно признавать, что запись должна быть такая:

Переменной C писваевается значение получаемое в результате сложения A и B.

Все, приехали.

... << RSDN@Home 1.2.0 alpha rev. 618>>

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

AVK>>В Java есть множественное наследование интерфейсов.
AVC>Эта идея в Java действительно новая и, похоже, неплохая.

Да, ребята...
Без комментариев

VladD2 wrote:

> Блин, нет слов. А что Ява сразу стала компилируемой?

Почти. JIT-компилятор уже был в версии 1.0.2 в 96 году.

> Она и в 1998 была *интерпретируемой*, и джит-компилятор который сейчас
> используется в реализации Явы от Сана был банально позаимствован...
> догадайся откуда? И Смолтока! Такого всего на свквозь инерпретироуемого.

В 98 уже Java 1.2 была на подходе.

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

А вот тут согласен

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

Posted via RSDN NNTP Server 2.0 beta

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

Д>>>Оказывается, Ява — это испорченный Оберон. Чем дальше, тем лохмаче

AVC>>Есть возражения по существу?

VD>Ага.

AVC>>Hint: отвлекитесь от разницы Си-подобного и Паскале-подобного синтаксиса и сопоставьте конструкции языков.

VD>Ты читал то внимательно? Напомню "Ява это Оберон испорченный С-шным синтаксисом". То есть основная проблема в синтаксисе!

Я сказал, что, если отвлечься от синтаксиса (C vs. Pascal), у Явы слишком много совпадений с Обероном.
Так что критика не по делу. Надеюсь, совет читать внимательнее применим не ко мне одному.

AVC>>Попробуйте указать другой язык-предшественник, с которым у Явы были бы такие большие совпадения.

VD>Легко:
VD>1. С/С++ — синтаксис.
VD>2. Смолток — заимствование джит-компиляции, сборщика мусора, виртуальной машины.
VD>3. Паскаль/Ада — заимствование идей безопастного программирования.

Напомню, что Модула-2 была создана раньше Ады.
Оберон — модификация Модулы-2. (Вирт много из нее повыбрасывал, добавил лишь расширение типа и связанные с ним конструкции, вроде type test, который так очевидно просвечивает в явовском instanceof.)
Так что последняя цепочка выглядит так: Паскаль/Модула-2.

VD>Да Вирт с Губавновым вобще сомневаются в том, что нужны какие-то языки кроме Оберона и Зенона. Ну, и что? Ты будешь третьим.

Влад, я так понимаю, что весь этот поток красноречия вызван тем, что так и не удалось высосать из пальца обещанный пример опечатки с операцией присваивания :=

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

AVC>>Жаль, что эта информация весьма скупая. Я не смог пока составить себе представления о механизмах сборки мусора в
AVC>>этих языках. Но сборка мусора упоминается, это факт.

VD>А ничего что еще были компилируемые варианты Лиспа и Смолтока? И что в них тоже были сборщики мусора? И что они были куда раньше чем даже эти дремучие языки?

Речь шла об использовании сборки мусора в компилируемых языках.
Я думал (по незнанию

), что таким первым языком был Оберон. Я ошибался.
uw указал на Алгол-68 (хотя у меня была книжка по Алголу-68, где про сборку мусора не было сказано ни слова), Trurl на Симулу-67.
Что касается сборки мусора как таковой, то, кажется, ее предложил МакКарти (автор Лиспа) в 1959 году, но на "сборку мусора вообще" я не покушался.

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

AVC>Я сказал, что, если отвлечься от синтаксиса (C vs. Pascal), у Явы слишком много совпадений с Обероном.

что-то я так и не дождался ответа на критику твоих "совпадений", которых "слишком много"

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

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

AVK>>>В Java есть множественное наследование интерфейсов.
AVC>>Эта идея в Java действительно новая и, похоже, неплохая.

J>Да, ребята...
J>Без комментариев

А к чему такая скрытность?

Я имел в виду, что ни в Обероне, ни в Си++, ни в других известных мне популярных языках наследование интерфейса не было синтаксически отделено от наследования реализации.
Возможно, Вы можете привести неучтенный мной пример (как сделали uw и Trurl), но фраза "без комментариев" мне мало что дает.

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

>> Компилятор Оберона обнуляет указатели (и процедурные переменные) при
>> входе в процедуру.
>> Значит, знает их адреса.

C>Ну во-первых, сейчас только самые тупые компиляторы обнуляют все
C>переменные при входе в функцию — стандартной оптимизацией будет обнулять
C>только те переменные, для которых это нужно.

На всякий случай: "процедурные переменные" — это не "локальные переменные", а "указатели на функции" (в терминологии Си).
Что касается присвоения указателям NULL, то, конечно, иногда оптимизатор может сразу присвоить ненулевое значение. Но я имел в виду "общий случай" (без оптимизации). Он касается только указателей.

>> Можно заодно его "попросить" заносить адреса указателей в специальную
>> структуру (устроеную по принципу стека).
>> При выходе из процедуры — просто сокращать этот второй стек.

C>Есть такой метод, вот тут он хорошо описан:
C>http://citeseer.ist.psu.edu/henderson02accurate.html

Ну вот! Что ни придумаешь, все уже было!

>> Тогда в любой момент будут точно известны все локальные указатели, и
>> сборку можно будет проводить точно, а не консервативно.
>> Скорее всего, просто в этом нет необходимости.
>> Удельная масса "корней" в стеке сравнительно невелика (по сравнению с
>> числом нелокальных "корней").

C>Тут немного другие проблемы — сборка мусора в многотредовом приложении
C>может возникнуть в любой момент исполнения функции. Но это не всегда
C>безопасно.

C>Например, представим такой сценарий:
C>

C>создать_новый_объект
C>pop ax ; В ax будет адрес нового объекта
C><-- И тут врубается полный цикл GC, запущеный из другого потока
C>mov var_1,ax ;Запишем ax в переменную
C>

C>В этом случае GC не увидит только что созданый объект, лежащий в регистре.

C>Или другой вариант:
C>

C>;В ax лежит адрес объекта
C>push ax ;Кладем его в стек
C>push some_parameter
C><-- Приходит пушной зверек GC
C>call SomeFunction
C>...
C>

C>Тут GC не увидит положенную в стек переменную.

C>Если используется передвигающий GC (moving GC), то такие ошибки будут
C>фатальны для программы.

C>Поэтому делают GC возможным только в специальных GC safepoint'ах (их
C>обычно расставляют в началах циклов, длинных ветвлений и т.п.) — для
C>каждого safepoint'а сохранена в виде таблиц точная информация о
C>состоянии стека и регистров в нем (stackmaps, register maps). Сразу
C>появляются проблемы: как заставить потоки остановиться в safepoint'ах,
C>как построить stackmap'ы с минимальным оверхедом и т.п. Поэтому точная
C>сборка стека — это и есть хвостик, тянущий за собой слона.

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

>> В Обероне же это делает компилятор.

C>Для GCC есть расширение, которые автоматически генерирует object map'ы.

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

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

Д>что-то я так и не дождался ответа на критику твоих "совпадений", которых "слишком много"

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

Отвечу.

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

E>Теперь о том, к чему я вел. А к тому, что, имхо, на момент прочтения лекции Францем Oak/Java были уже в таком стабильном состоянии, что менять что-то в них под влиянием Oberon, C++, Eiffel, Smalltalk, Perl или еще чего-нибудь было бы уже просто не реально.

Всё верно. Франц рассказал об открытом им способе компактного древовидного промежуточного представления программ, которое допускает быструю оптимизирующую генерацию кода во время загрузки модуля с жесткого диска (кодогенерация "на лету"). Франц нашел способ как совместить загрузчик и кодогенератор в одном флаконе. Создатели Java не решились использовать этот новейший метод древовидного представления программы, а оставили допотопный линейный байт-код (известный еще с Pascal 1970 года как P-код). Так что к лекции Франца прочитанной всего лишь за 1 год до выхода Java действительно цепляться нечего. Дело в другом — создатели Java еще за семь лет до ее появления изучили исходные коды Oberon системы.

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

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

Сергей Губанов wrote:

> Создатели Java не решились использовать этот новейший метод
> древовидного представления программы, а оставили допотопный линейный
> байт-код (известный еще с Pascal 1970 года как P-код). Так что к
> лекции Франца прочитанной всего лишь за 1 год до выхода Java
> действительно цепляться нечего. Дело в другом — создатели Java еще за
> семь лет до ее появления изучили исходные коды Oberon системы.

В которых тогда уже не было чего-либо кардинально нового.

> E>Еще хотелось бы сказать пару слов о мнении Вирта, что Java это
> испорченный Oberon, а Oberon -- это предтеча Java. Не могу с этим
> согласиться по следующим причинам.
> Представьте себе, что Вы изобрели супер-пупер язык программирования и
> написали на нем супер-пупер операционную систему. Потом показали
> исходные коды людям из компании "Солнышко". Спустя семь лет компания
> "Солнышко" объявляет на весь мир о своём изобретении супер-пупер языка
> программирования и супер-пупер системы основанной на нем.

Это сомнительно. У SUN уже был язык Oak до того, как они получили
Оберон. Да и, честно говоря, ничего нового в Обероне в то время уже не было.

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

Posted via RSDN NNTP Server 2.0 beta

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

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

Многопоточность подразумевает существование нескольких стеков. В классическом случае размер каждого стека фиксируется в момент создания нового потока. Из-за этого в классических операционных системах всегда есть ограничение на количество потоков. Так, например, в Windows количество потоков ограничено всего лишь 2000 штуками (просто делим размер доступной виртуальной памяти для 32-разрядной машины на размер резервируемой для каждого стека виртуальной памяти). Спрашивается, как же в Aos BlueBottle написанной на Active Oberon добились не ограниченного количества активностей? Ну как как, а так — а не надо резервировать виртуальную память для стека. Наращивай стэк динамически в динамической памяти вот и все. Активностей можно одновременно создать столько сколько влезет (60 тысячь активностей — ерунда).

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

VD>А то не дай бог Губано поверит в то, что должен остаться только один язык — Зенон и начен отстреливать всех кто с этим не согласен.

Zonnon — нет. Он слишком сложен (его описание занимает целых 40 страниц). В нём много вещей которые можно было бы перенести в библиотеки. Идеи в него заложены могучие, но реализованы уж как-то не по оберонски. Короче, отстреливать из-за Зоннона я не буду...

Спрашивал я у Гуткнехта и Зуева, чего это они компилятор языка Zonnon пишут на C#, а не на нём же самом (как это делал Вирт со своими языками). Гуткнехт сказал — "а чё такого-то C# — нормальный язык"; Зуев сказал — "Возиться с раскруткой не охота, на C# быстрее." Ну и спрашивается чего эти два товарища сделают с таким подходом к делу? Потратят денежки проплаченные микрософтом на свои собственные исследования — вот что они сделают. А потом, чую я, все эти изученные идеи по человечески реализуют в новейшей Aos BlueBottle 2.0, а микрософт оставят с носом т.е. с Зонноном.

Сергей Губанов wrote:

> Многопоточность подразумевает существование нескольких стеков.

Совсем необязательно, может быть и всего один аппаратный стек.

> В классическом случае размер каждого стека фиксируется в момент
> создания нового потока.

Это "классика" где-то 70-х годов. В современных системах в конце стека
помещается guard-страница, при попытке записи в которую генерируется
аппаратное исключение, которое перехватывается. В обработчике исключения
стек автоматически расширяется.

> Из-за этого в классических операционных системах всегда есть
> ограничение на количество потоков. Так, например, в Windows количество
> потоков ограничено всего лишь 2000 штуками (просто делим размер
> доступной виртуальной памяти для 32-разрядной машины на размер
> резервируемой для каждого стека виртуальной памяти).

Чушь. Стек в Винде может быть минимально в 32Кб, что дает 120 тысяч
потоков. Я уже не говорю, что в Виндоусе есть еще режим расширения
памяти (в котором адресуется до 16Тб). Ну а мелочи типа fiber'ов,
которых может быть хоть миллионы, вообще можно не упоминать.

> Спрашивается, как же в Aos BlueBottle написанной на Active Oberon
> добились не ограниченного количества активностей? Ну как как, а так —
> а не надо резервировать виртуальную память для стека. Наращивай стэк
> динамически в динамической памяти вот и все. Активностей можно
> одновременно создать столько сколько влезет (60 тысячь активностей —
> ерунда).

Читаем:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/thread_stack_size.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/createfiber.asp

В Линуксе используется аналогичный механизм.

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

Posted via RSDN NNTP Server 2.0 beta

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

C>Это "классика" где-то 70-х годов. В современных системах в конце стека
C>помещается guard-страница, при попытке записи в которую генерируется
C>аппаратное исключение, которое перехватывается. В обработчике исключения
C>стек автоматически расширяется.

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

C>Чушь. Стек в Винде может быть минимально в 32Кб, что дает 120 тысяч
C>потоков.

И что будет если этим 120 тысячам потокам надо будет (по очереди) занимать на стэке больше чем 32Кб? Например, что если каждому из потоков (по очереди) надо будет занимать всю оперативную память под стек, в то время как всем остальным потокам в это время память будет не нужна?

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

Сергей Губанов wrote:

> C>Это "классика" где-то 70-х годов. В современных системах в конце стека
> C>помещается guard-страница, при попытке записи в которую генерируется
> C>аппаратное исключение, которое перехватывается. В обработчике
> исключения
> C>стек автоматически расширяется.
> Это Вы про физический размер стэка говорите. А я про виртуальный.

Про виртуальный тоже. Стеки находится в самом обычном блоке памяти,
которые могут управляться обычными API. Другое дело в том, что не всегда
расширение стека возможно — может не быть свободного места "под" стеком.

Тут возможно использование "зеленых потоков" (green threads, greenlets),
которые не зависят от системного стека. Такие библиотеки есть для
Windows и Linux.

> C>Чушь. Стек в Винде может быть минимально в 32Кб, что дает 120 тысяч
> C>потоков.
> И что будет если этим 120 тысячам потокам надо будет (по очереди)
> занимать на стэке больше чем 32Кб?

Memory overflow будет. А что вы хотели?

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

Posted via RSDN NNTP Server 2.0 beta

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

AVC>> Си++ Java Oberon
AVC>>Модульность и раздельная компиляция Нет Да Да
AVC>>Многомерные открытые массивы Нет Да Да
VD>Погоди. В яве нет многомерных массивов. Кстати, как и в ассемблере.

Это как это "В яве нет многомерных массивов"?
Читаем Брюса Эккеля:

Многомерные массивы
Java позволяет вам легко создавать многомерные массивы:
//: c04:MultiDimArray.java
// Создание многомерных массивов.
import java.util.*;

public class MultiDimArray {
  static Random rand = new Random();
  static int pRand(int mod) {
    return Math.abs(rand.nextInt()) % mod + 1;
  }
  static void prt(String s) {
    System.out.println(s);
  }
  public static void main(String[] args) {
    int[][] a1 = {
      { 1, 2, 3, },
      { 4, 5, 6, },
    };
    for(int i = 0; i < a1.length; i++)
      for(int j = 0; j < a1[i].length; j++)
        prt("a1[" + i + "][" + j +
            "] = " + a1[i][j]);
    // 3-х мерный массив фиксированной длины:
    int[][][] a2 = new int[2][2][4];
    for(int i = 0; i < a2.length; i++)
      for(int j = 0; j < a2[i].length; j++)
        for(int k = 0; k < a2[i][j].length;
            k++)
          prt("a2[" + i + "][" +
              j + "][" + k +
              "] = " + a2[i][j][k]);
    // 3-х мерный массив с векторами переменной длины:
    int[][][] a3 = new int[pRand(7)][][];
    for(int i = 0; i < a3.length; i++) {
      a3[i] = new int[pRand(5)][];
      for(int j = 0; j < a3[i].length; j++)
        a3[i][j] = new int[pRand(5)];
    }
    for(int i = 0; i < a3.length; i++)
      for(int j = 0; j < a3[i].length; j++)
        for(int k = 0; k < a3[i][j].length;
            k++)
          prt("a3[" + i + "][" +
              j + "][" + k +
              "] = " + a3[i][j][k]);
    // Массив не примитивных объектов:
    Integer[][] a4 = {
      { new Integer(1), new Integer(2)},
      { new Integer(3), new Integer(4)},
      { new Integer(5), new Integer(6)},
    };
    for(int i = 0; i < a4.length; i++)
      for(int j = 0; j < a4[i].length; j++)
        prt("a4[" + i + "][" + j +
            "] = " + a4[i][j]);
    Integer[][] a5;
    a5 = new Integer[3][];
    for(int i = 0; i < a5.length; i++) {
      a5[i] = new Integer[3];
      for(int j = 0; j < a5[i].length; j++)
        a5[i][j] = new Integer(i*j);
    }
    for(int i = 0; i < a5.length; i++)
      for(int j = 0; j < a5[i].length; j++)
        prt("a5[" + i + "][" + j +
            "] = " + a5[i][j]);
  }
} ///:~
Код, использующийся для печати, использует length, так что он не зависит от того, имеет ли массив фиксированную длину.

Первый пример показывает многомерный массив примитивных типов. Вы ограничиваете каждый вектор в массиве с помощью фигурных скобок:
int[][] a1 = {
      { 1, 2, 3, },
      { 4, 5, 6, },
    };
Каждая пара квадратных скобок переносит нас на новый уровень в массиве.
Второй пример показывает трехмерный массив, резервируемый с помощью new. Здесь весь массив резервируется сразу:
int[][][] a2 = new int[2][2][4];
А в третьем примере показано, что каждый вектор массива, создающий матрицу, может быть произвольной длины:
int[][][] a3 = new int[pRand(7)][][];
    for(int i = 0; i < a3.length; i++) {
      a3[i] = new int[pRand(5)][];
      for(int j = 0; j < a3[i].length; j++)
        a3[i][j] = new int[pRand(5)];
    }
Первый new создает массив произвольной длиной первого элемента, а остальные элементы не определены. Второй new, внутри цикла for, заполняет элементы, но оставляет третий индекс неопределенным, пока вы не введете третий new.

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

Вы можете работать с массивами не примитивных объектов точно таким же образом, что показано в четвертом примере, демонстрирующем возможность помещения множества выражений new в фигурных скобках:
Integer[][] a4 = {
      { new Integer(1), new Integer(2)},
      { new Integer(3), new Integer(4)},
      { new Integer(5), new Integer(6)},
    };
Пятый пример показывает, как можно построить массив не примитивных объектов по частям:
Integer[][] a5;
    a5 = new Integer[3][];
    for(int i = 0; i < a5.length; i++) {
      a5[i] = new Integer[3];
      for(int j = 0; j < a5[i].length; j++)
        a5[i][j] = new Integer(i*j);
    }
i*j — это просто помещает отличное от нуля значение в Integer.

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

Т>Скорее всего главный претендент в номинации "первый компилируемый язык со сборкой мусора" — Симула-67.
Возможно.
Язык SIMULA
компиляция http://www.radioland.net.ua/contentid-171-page2.html
и
http://ivn73.tripod.com/dis_simula.htm

SIMULA 67

Алгоритмический язык Simula 67 (от “simulation” – моделирование) является первым полноценным объектно-ориентированных языком, который представлял собой все основные концепции объектного моделирования (инкапсуляция, полиморфизм, наследование). Simula был разработан в начале 60-х гг. в Norwegian Computing Centre для моделирования дискретных событий в реальном физическом мире.

Синтаксис языка Simula взят из Алгола-60. Основными новшествами были понятия объекта, класса и наследования. Симула не навязывает строгую инкапсуляцию данных и не заботится о деталях реализации. Модули можно перекомпилировать по отдельности, не меняя внешние интерфейсы. Проверка типов осуществляется во время компиляции. Сборка мусора осуществляется системой поддержки работающей программы.

В Simula имеется поддержка моделирования физических процессов реального времени. Для этого Simula может оперировать понятиями Модель (Simulation) и Процесс (Process).

Для инкапсуляции (сокрытие реализации, принцип “черный ящика”) в Simula было введено строгое контролирование к доступу информации, однако “черный ящик” в объектной модели является в открытым к изменениям. Создавая свою модель на подобием существующей (наследуясь от нее) можно сделать изменения в базовой модели для своего объекта. Это достигается за счет техники полиморфизма.

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

Среда

Переносимая система Simula (S-Port) содержит независимый пакет, состоящий из компилятора, генерирующего промежуточный язык S-code, систему поддержки работающей программы и символьного отладчика. Также есть система, зависимая от целевой машины, содержащая компилятор, транслирующий S-code в целевой код, и набор программ интерфейса. Планируется создать дополнительные средства и библиотеку предопределенных модулей.

Поставщики

Первая реализации на Univac 1107 появилась в начале 70-х гг. С этих пор язык был реализован на большинстве платформ, от больших ЭВМ до персоналок. В настоящее время Simula развивается и выступает на рынке под названием Simula a.s., установленным норвежской фирмой в 1984 г.

Переносимая система Simula (S-Port) — является основой многочисленных версий, включая PC Simula.
<...>
Сформированная в 1972 г. организация Simula Standards Group осуществляет контроль за развитием языка: самая последняя версия была выпущена в 1986г. Изменения в язык вносит Simula Developement Group. Кроме того, есть ассоциация пользователей языка Simula.

пример кода: из INTRODUCTION TO OOP IN SIMULA:

! The program defines the main class "Geometry".;
! It represents a theory with terms "point, rectangle, circle, and line".;
Class Geometry;
Begin
  Class Point(X,Y); Real X,Y;
  Begin
    Procedure Print; Begin  ...  End;
    Procedure Shift(Dx, Dy); Real Dx, Dy; Begin  ...  End;
    Print;                  ! Life of point;
  End of Point;

  Class Rectangle(RecName, Width, Height);
       Text RecName; Real Width, Height;
  Begin
    Real Area, Perimeter;
    Procedure Update; Begin  ...  End;
    Procedure Show; Begin  ...  End;
    Update; Show;           ! Life of rectangle;
  End of Rectangle;

  Class Circle(Radius, Center); Real Radius; Ref(Point) Center;
  Begin
    Procedure Shift(Dx, Dy); Real Dx, Dy; Begin  ...  End;
    OutText("Circle created at "); ! Life of circle;
    Center.Print;
  End of Circle;

  Class Line(M,N); Ref(Point) M,N; ! Line defined by two points;
  Begin
    Real Slope;
    Slope :=  ...  ;       ! Life of line;
  End of Line;

  !Variables declared in geometry:;
  Ref(Point) Origin, A, B;
  Ref(Line) X,Y;

  !Life of geometry:;
  Origin :- New Point(0,0); ! Creating the origin;
  A :- New Point(1,0); B :- New Point(0,1);
  X :- New Line(Origin, A); ! Creating the axes;
  Y :- New Line(Origin, B);
  OutText("*** Geometry initialized ***"); OutImage;
End of Geometry;

Next program is using the main class Geometry. Note how the classes declared in Geometry are used to declare subclasses specialized to the problem being solved. Later it is possible to declare and use reference variables qualified into both imported and locally declared classes. This is the fundamental idea of Simula based packages or user defined languages (what is the difference?)

External Class Geometry;
Geometry Begin
  ! Subclasses declared in the prefixed block:;
  Point Class Color_Point(C); Character C; Begin  ...  End;
  Rectangle Class Square; Begin  ...  End;

  ! Variables declared in the prefixed block:;
  Ref(Color_Point) A1;
  Ref(Point) C, D;
  Ref(Circle) K;
  Ref(Line) E, F;
  Ref(Rectangle) R1;
  Ref(Square) S1;

  ! Block body:;
  C :- New Point(5,6);
  D :- New Point(20,30);
  A1 :- New Color_Point(3, 4, 'G');
  K :- New Circle(10, C);
  E :- New Line(C, D);
  F :- X;
  K.Shift (1,1);
  R1 :- New Rectangle("Rec_R1", 5, 4);
  S1 :- New Square("Square_S1", 4, 6);
  S1.Show;
End of prefixed block;

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

AVC>Речь шла об использовании сборки мусора в компилируемых языках.

Ява не компилируемый язык! По крайней мере не был таковым до появления в конце девяностых!

Компиляторы для Лиспа сушествовали еще в 70-ых.

О Алголах и т.п. вообще лучше умолчать..

Еще вопросы?

AVC>Я думал (по незнанию

), что таким первым языком был Оберон. Я ошибался.

Ты вообще думал, что Оберон это великое открытие, а от от Явм ничем не отличается в том плане, что вобрал в себя кучу уже придуманных идей.

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

... << RSDN@Home 1.2.0 alpha rev. 618>>

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

C>Почти. JIT-компилятор уже был в версии 1.0.2 в 96 году.

Небыло. Первый джит создал МС. Потом Сан купил ХотСпот. Надо рассказывать где появился ХотСпот?

Ява же как технология появилась значительно раньше 96-го. Так что твои "аргументы" о том, тут были какие-то заимствования из Оберона просто смешна.

>> Она и в 1998 была *интерпретируемой*, и джит-компилятор который сейчас
>> используется в реализации Явы от Сана был банально позаимствован...
>> догадайся откуда? И Смолтока! Такого всего на свквозь инерпретироуемого.

C>В 98 уже Java 1.2 была на подходе.

Ага, вот только 1.2 — это конец 98 года. Вот овервь для нее. Погляди дату в конце.

... << RSDN@Home 1.2.0 alpha rev. 618>>

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

AVC>Влад, я так понимаю, что весь этот поток красноречия вызван тем, что так и не удалось высосать из пальца обещанный пример опечатки с операцией присваивания :=

Этот поток от возмущения вызванного твоими словами. Придумывать же ничего не нужно. Опечалася и будет "=". Вопрос поправит или нет компилятор. А раз дело в контроле компилятора, то какая разница что использовать "=" или "==" для сравнения если компилятор все равно не даст ошибиться?

... << RSDN@Home 1.2.0 alpha rev. 618>>

VladD2 wrote:

> C>Почти. JIT-компилятор уже был в версии 1.0.2 в 96 году.
> Небыло. Первый джит создал МС. Потом Сан купил ХотСпот. Надо
> рассказывать где появился ХотСпот?

JIT в Java появился в начале 97 года в версии 1.0.не_помню_какая (там
еще оставался консервативный сборщик мусора и старый JNI). Затем в
начале 98 года (как раз после новогодних праздников) зарелизили Java
1.1. Причем у Sun в JVM даже был специальный документированый интерфейс
для custom'ных JITов (его убрали в 1.2).

JIT у MS появился примерно в то же время — как раз к выпуску новой Студии.

Затем в конце 98 года действительно появилась 1.2, но ветки 1.1 и 1.2
долго жили параллельно.

>>> Она и в 1998 была *интерпретируемой*, и джит-компилятор который сейчас
>>> используется в реализации Явы от Сана был банально позаимствован...
>>> догадайся откуда? И Смолтока! Такого всего на свквозь инерпретироуемого.
> C>В 98 уже Java 1.2 была на подходе.
> Ага, вот только 1.2 — это конец 98 года. Вот овервь
> <http://www.artima.com/insidejvm/newin12.html> для нее. Погляди дату в
> конце.

А еще есть http://www.webarchive.org

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

Posted via RSDN NNTP Server 2.0 beta

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

ZEN>Это как это "В яве нет многомерных массивов"?

Это не многомерные массивы, а массивы массивов.

... << RSDN@Home 1.1.4 stable rev. 510>>

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

AVC>uw указал на Алгол-68 (хотя у меня была книжка по Алголу-68, где про сборку мусора не было сказано ни слова), Trurl на Симулу-67.

Смотри здесь, это Algol 68 Revised Report, а не какая-нибудь "книжка". В Алголе-68 просто была возможность динамически выделять память(скорее всего неявно), а освобождать не было. Нужен был сборщик мусора.

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

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

Это же и относится к PL/I, который содержит сразу несколько механизмов управления памятью; возможно для какого-то из них требовался сборщик мусора.

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

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

AVC>>> Си++ Java Oberon
AVC>>>Модульность и раздельная компиляция Нет Да Да
AVC>>>Многомерные открытые массивы Нет Да Да
VD>>Погоди. В яве нет многомерных массивов. Кстати, как и в ассемблере.

ZEN>Это как это "В яве нет многомерных массивов"?

Так. Нет.

ZEN>Читаем Брюса Эккеля:
Лучше спецификацию почитать.

ZEN>//: c04:MultiDimArray.java
ZEN>// Создание многомерных массивов.
ZEN>import java.util.*;

Раскажи мне любезный, как можно импортировать фичи языка?

ZEN> // 3-х мерный массив фиксированной длины:
ZEN> int[][][] a2 = new int[2][2][4];

Это не 3-х мерный массив. Это массив, массивов, массивов. Короче воженные массивы тройной вложенности.

Пример на шарпе:

int[][][] jaggedArray3x...
int[,,] threeDimensionalArray...

ZEN>

ZEN>int[][] a1 = {
ZEN>      { 1, 2, 3, },
ZEN>      { 4, 5, 6, },
ZEN>    };
ZEN>

ZEN>Каждая пара квадратных скобок переносит нас на новый уровень в массиве.

Скажи, а это как назвать:

int[][] a1 = 
{
    null,
    { 4, 5, 6, },
};

Блин, и какой энтузиазм (это я о поскипаном).

... << RSDN@Home 1.2.0 alpha rev. 618>>

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

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

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

СГ>

СГ>P. S.
СГ>При переходе к 64-разрядным системам указанная проблема (фиксации виртуального размера стэка) снимается, т.к. виртуальное пространство становится ну очень большим.

Сильно ошибашся. х64-процессоры не адресуют невероятных адресных пространств. У них просто уразанные шины. Так что от разных Xeon-ов они мало чем отличаются.

... << RSDN@Home 1.2.0 alpha rev. 618>>

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

СГ>Спрашивал я у Гуткнехта и Зуева, чего это они компилятор языка Zonnon пишут на C#, а не на нём же самом (как это делал Вирт со своими языками). Гуткнехт сказал — "а чё такого-то C# — нормальный язык"; Зуев сказал — "Возиться с раскруткой не охота, на C# быстрее." Ну и спрашивается чего эти два товарища сделают с таким подходом к делу? Потратят денежки проплаченные микрософтом на свои собственные исследования — вот что они сделают. А потом, чую я, все эти изученные идеи по человечески реализуют в новейшей Aos BlueBottle 2.0, а микрософт оставят с носом т.е. с Зонноном.

Сыр на халяву бывает только в мышеловке
Более вероятно, что изученные идеи появятся в C# 3.0, а с носом останется Вирт

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

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

>> C>Чушь. Стек в Винде может быть минимально в 32Кб, что дает 120 тысяч
>> C>потоков.
>> И что будет если этим 120 тысячам потокам надо будет (по очереди)
>> занимать на стэке больше чем 32Кб?

C>Memory overflow будет. А что вы хотели?

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

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

Д>Сыр на халяву бывает только в мышеловке
Д>Более вероятно, что изученные идеи появятся в C# 3.0, а с носом останется Вирт

А Вирт-то тут при чем? Zonnon-ом занимается не Вирт, а Гуткнехт. Кстати, Вирт совсем не в восторге от этой работы Гуткнехта. По вопросам Zonnon-а у Вирта и Гуткнехта есть большие разногласия. Опять же кстати, не знаю как там на счет C# 3.0, но вот язык Active C# уже применяет могучие идеи аппробированные в процессе реализации проекта Zonnon.

Сергей Губанов wrote:

> А Вирт-то тут при чем? Zonnon-ом занимается не Вирт, а Гуткнехт.
> Кстати, Вирт совсем не в восторге от этой работы Гуткнехта. По
> вопросам Zonnon-а у Вирта и Гуткнехта есть *большие* разногласия.
> Опять же кстати, не знаю как там на счет C# 3.0, но вот язык Active C#
> уже применяет могучие идеи аппробированные в процессе реализации
> проекта Zonnon.

Эти идеи изначально появились в языке Эрланг, еще в 80-х годах. Задолго
до ActiveOberon.

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

Posted via RSDN NNTP Server 2.0 beta

Сергей Губанов wrote:

>>> И что будет если этим 120 тысячам потокам надо будет (по очереди)
>>> занимать на стэке больше чем 32Кб?
> C>Memory overflow будет. А что вы хотели?
> Вот. А если не резервировать виртуальную память под стэк заранее, а
> выделять ее по честному в куче (при каждом вызове очередной
> процедуры), то глубина стэка каждого потока будет ограничена только
> физически установленным в машине количеством памяти.

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

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

Posted via RSDN NNTP Server 2.0 beta

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

C>Эти идеи изначально появились в языке Эрланг, еще в 80-х годах. Задолго
C>до ActiveOberon.

Какие такие идеи изначально появились в языке Эрланг?

Трурль wrote:

> C>Эти идеи изначально появились в языке Эрланг, еще в 80-х годах. Задолго
> C>до ActiveOberon.
> Какие такие идеи изначально появились в языке Эрланг?

Меня уже поправили — сначала они появились в Симуле-67.

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

Posted via RSDN NNTP Server 2.0 beta

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

AVC>>>> Си++ Java Oberon
AVC>>>>Модульность и раздельная компиляция Нет Да Да
AVC>>>>Многомерные открытые массивы Нет Да Да
VD>>>Погоди. В яве нет многомерных массивов. Кстати, как и в ассемблере.

iZEN>>Это как это "В яве нет многомерных массивов"?
VD>Так. Нет.
iZEN>>Читаем Брюса Эккеля:
VD>Лучше спецификацию почитать.
Читаем вместе.
Кен Арнольд, Джеймс Гослинг, Дэвид Холмс "Язык программирования Java, 3-е издание", изд. Вильямс, 2001

6.4.2 Многомерные массивы
В Java поддерживается возможность объявления многомерных массивов (multidimensional arrays) (т.е. массивов, элементами которых служат массивы). Код, предусматривающий объявление двумерной матрицы и вывод на экран содержимого её элементов, может выглядеть, например, так:
float[][] mat = new float[4][4];
setupMatrix(mat);
for (int y = 0; y < mat.length; y++) {
   for (int x = 0; x < mat[y].length; x++)
      System.out.print(mat[y][x] + " ");
   System.out.println();
}
При создании массива должна быть указана, по меньшей мере, его первая, "самая левая", размерность. Другие размерности разрешается не задавать — в этом случае их придётся определить позже. Указание в операторе new единовременно всех размерностей — это самый лаконичный способ создания массива, позволяющий избежать необходимости использования дополнительных операторов new. Выражение объявления и создания массива mat, приведённое выше, равнозначно следующему фрагменту кода:
float[][] mat = new float[4][];
for (int y = 0; y < mat.length; y++)
   mat[y] = new float[4];
Такая форма объявления обладает тем преимуществом, что позволяет наряду с получением массивов с одинаковыми размерностями (скажем 4x4) строить и массивы массивов различных размерностей, необходимых для хранения тех или иных последовательностей данных.

Раз уж сами создатели языка решили, что многомерные массивы и массивы массивов — одно и то же, то в чём же их/моё заблуждение кроется. Может неправильно перевели?
Объясни, а?

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

VD>Раскажи мне любезный, как можно импортировать фичи языка?

Легко.

Вот простой пример из Оберона:

IMPORT SYSTEM;

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

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

AVC>>uw указал на Алгол-68 (хотя у меня была книжка по Алголу-68, где про сборку мусора не было сказано ни слова), Trurl на Симулу-67.

uw>Смотри здесь, это Algol 68 Revised Report, а не какая-нибудь "книжка". В Алголе-68 просто была возможность динамически выделять память(скорее всего неявно), а освобождать не было. Нужен был сборщик мусора.

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

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

uw>Это одна из многочисленных "засад", которые ожидали ипмлементоров языка.
uw>Напомню, что тогда большинство языков сначала полностью описывались в спецификациях, а только затем реализовывались.

Не только тогда.

Поэтому мне больше нравится подход Вирта, когда язык и компилятор разрабатываются вместе.
Этим его подход принципиально отличается от "комитетских" разработок.
ИМХО, как раз Алгол-68 и стал поворотным пунктом для Вирта. (Он вместе с Хоаром входил в состав комитета, его предложения сформулированы в проекте языка Algol W. Стиль работы комитета описан в тьюринговской лекции Хоара.)
С тех пор Вирт в комитетах "не участвовал".

И самостоятельно создал Паскаль, Модулу (эксперимент в середине 70-х по встраиванию многопоточности в язык на основе хоаровских мониторов; причем здесь Эрланг?! Модула была одним из первых языков такого рода), Модулу-2 и Оберон.
(Кстати, что касается динамических языков и функционального программирования, то был у Вирта в 1960-х экспериментальный язык Euler.)

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

VD>Ты вообще думал, что Оберон это великое открытие, а от от Явм ничем не отличается в том плане, что вобрал в себя кучу уже придуманных идей.

Все эти реплики мне напоминают басню Крылова.
Там некий персонаж идет в кунсткамеру, восхищается всякой мелочью, а в конце выясняется что "слона-то он и не приметил".

Не в "отдельных фичах", Влад, счастье!

Фичи — это еще не язык.
Главное — что можно из них построить.
Пусть кто-нибудь укажет мне на какой-нибудь дообероновский императивный язык, сочетающий ООП с полной безопасностью типов (антипримеры: Си с классами и Смоллток в этом смысле — дыра на дыре), имеющий модульную структуру (с динамической загрузкой модулей; статическая линковка не требуется), обеспечивающий сборку мусора, эффективное динамическое определение типа и все это — элегантно, минимальными средствами.
Вот этой целостности до Оберона просто не существовало.
А так и про Льва Толстого можно сказать, что он совсем не великий писатель: ведь он пользовался обычными русскими
буквами, а не изобретал свой собственный алфавит.

VD>Так что единственный вклад в науку Вирта — это как не смешно звучит — это Паскаль, в котором Вирт отстаивал принципы строгой статической типизации. Все остальное всего лишь развитие этой идеи на базе заимствований из других языков.

Угу, "всего лишь".

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

Т>Скорее всего главный претендент в номинации "первый компилируемый язык со сборкой мусора" — Симула-67.

Наверное, стоит уточнить, что мы признаем за полноценную сборку мусора (и за компилируемый язык

).
Например, в виртовском языке Euler (1963) уже была сборка мусора.
http://www.oberon2005.ru/paper/nw_euler.pdf

Дарней,

> Ну не совсем так. У С++ проблема не в версиях стандартов, а в ее сложности — большинство компиляторов не полностью соотвествуют стандартам.

Это не из-за сложности (исключая экспорт шаблонов), а из-за того, что стандарт был выпущен уже после того, как у многих производителей была готова реализация компилятора.

> У Явы и C# намного меньше всяких тонкостей и "особых случае", поэтому и объем спецификации намного меньше -> на порядок меньше проблем совместимости компиляторов.

Объем спецификации C# 2 не меньше, чем объем спецификации C++ даже, особенно при учете того, что спецификация C++ заметно подробнее.

Posted via RSDN NNTP Server 2.0 beta

ZEN>Читаем вместе.
ZEN>Кен Арнольд, Джеймс Гослинг, Дэвид Холмс "Язык программирования Java, 3-е издание", изд. Вильямс, 2001
ZEN>[q]6.4.2 Многомерные массивы
ZEN>В Java поддерживается возможность объявления многомерных массивов (multidimensional arrays)

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

ZEN>Раз уж сами создатели языка решили, что многомерные массивы и массивы массивов — одно и то же, то в чём же их/моё заблуждение кроется. Может неправильно перевели?

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

... << RSDN@Home 1.2.0 alpha rev. 618>>

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

AVC>Легко.

AVC>Вот простой пример из Оберона:
AVC>

AVC>IMPORT SYSTEM;
AVC>

AVC>SYSTEM — не отдельный модуль,

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

... << RSDN@Home 1.2.0 alpha rev. 618>>

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

AVC>Не в "отдельных фичах", Влад, счастье!

AVC>Фичи — это еще не язык.

Мы говорим о заимствованиях? Тогда предлагаю не обсуждать посторонние вопросы вроде "в чем счастье".

Оберон созданный в 88 даже не додумался вобрать в себя зачатки ООП. Новых идей в нем — 0.
Он точно так же собрал в себе фичи которые автор посчитал нужными как и любой другой язык. Результат получился довольно удручающий. Единственное доствоинство языка котороя лично я чутко вижу — это размер минтаксиса. Но тут однозначно победителем является БрэйнФак. Если Вирта устраивает соревнование с этим чудом природы, то я поздрвляю его и желаю счаться на этом поприще. Ну, а пользоваться я лично буду тем, что удобно.

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

Смолток как минимум. Еще вопросы?

AVC>Вот этой целостности до Оберона просто не существовало.

Я бы назвал Оберон неудавшимся экспеременотом который попытался вобрать в себя лучшие идеи существовавшие на тот момент. И неудачным он стал потому, что автор неверно оценил список этих лучших идей. Авторы Явы, Дельфи, Шарпа, Ди оказались чуть более прозарливы. А то что некоторые их мысли совпали говорит о том, что у них у всех были правильные мысли.

AVC>А так и про Льва Толстого можно сказать, что он совсем не великий писатель: ведь он пользовался обычными русскими буквами, а не изобретал свой собственный алфавит.

Про Льва Толстого это можно сказаь и без дополнительных обоснований. Его творчество или нравится, или нет. Что же касается языка которым пользовался Толстой, то почитай как-нить на достуге аригиналы той же "Воны и мира". Говорят в них половина на французком было написано. Так что даже эта аналогия не имеет под собой почвы.

VD>>Так что единственный вклад в науку Вирта — это как не смешно звучит — это Паскаль, в котором Вирт отстаивал принципы строгой статической типизации. Все остальное всего лишь развитие этой идеи на базе заимствований из других языков.

AVC>Угу, "всего лишь".

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

... << RSDN@Home 1.2.0 alpha rev. 618>>

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

ПК>Объем спецификации C# 2 не меньше, чем объем спецификации C++ даже, особенно при учете того, что спецификация C++ заметно подробнее.

Откуда дровишки?

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

Дарней wrote:

> ПК>Объем спецификации C# 2 не меньше, чем объем спецификации C++ даже,
> особенно при учете того, что спецификация C++ заметно подробнее.
> Откуда дровишки?

Скачай и сравни сам.

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

Posted via RSDN NNTP Server 2.0 beta

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

C>Дарней wrote:

>> ПК>Объем спецификации C# 2 не меньше, чем объем спецификации C++ даже,
>> особенно при учете того, что спецификация C++ заметно подробнее.
>> Откуда дровишки?

C>Скачай и сравни сам.

Да я вот и сравнил. C# 2.0 — 115 страницы, C++ — 776 страниц. Спека по C++ к тому же далеко не самая свежая. И где ты тут усмотрел, что у C# она "не меньше"?

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

Дарней wrote:

> C>Скачай и сравни сам.
> Да я вот и сравнил. C# 2.0 — 115 страницы, C++ — 776 страниц. Спека по
> C++ к тому же далеко не самая свежая. И где ты тут усмотрел, что у C#
> она "не меньше"?

ISO-IEC-14882(2003): описание языка заканчивается на 296 странице,
дальше идет описание стандартной библиотеки.
http://download.microsoft.com/download/8/1/6/81682478-4018-48fe-9e5e-f87a44af3db9/standard.pdf
(C# Language Working Draft 2.7, June 2004 (PDF)): описан только язык,
без послесловий всего 454 страницы.

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

Posted via RSDN NNTP Server 2.0 beta

I went to a Pascal conference in Southampton in 1977 and Brinch-Hansen described Concurrent
Pascal. When asked what he thought of Modula (that Wirth just had brought out), he replied that
you might do something clever but then "Claus" would come with the worked-through elegant version of it!

Bjarne Dacker

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

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

AVC>>Легко.

AVC>>Вот простой пример из Оберона:
AVC>>

AVC>>IMPORT SYSTEM;
AVC>>

AVC>>SYSTEM — не отдельный модуль,

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

Импортируется именно часть языка.
Я бы выделил так:

SYSTEM — не отдельный модуль

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

VD>Оберон созданный в 88 даже не додумался вобрать в себя зачатки ООП. Новых идей в нем — 0.

Пусть так. (Хотя у меня прямо противоположное мнение. Интересно, как удалось Вирту создать объектно-ориентированную операционную систему на языке, "не вобравшем в себя зачатки ООП"?)
Хотелось бы только понять, что именно Vlad2 считает "новыми идеями", а что "старыми"?

VD>Он точно так же собрал в себе фичи которые автор посчитал нужными как и любой другой язык. Результат получился довольно удручающий. Единственное доствоинство языка котороя лично я чутко вижу — это размер минтаксиса. Но тут однозначно победителем является БрэйнФак. Если Вирта устраивает соревнование с этим чудом природы, то я поздрвляю его и желаю счаться на этом поприще. Ну, а пользоваться я лично буду тем, что удобно.

Лично у меня с БрейнФаком другая ассоциация — Си++.
По крайней мере, эффект от Си++ вполне соответствующий.

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

VD>Смолток как минимум. Еще вопросы?

По-моему, я ясно назвал Смоллток антипримером.
Если кто-то считает, что в Смоллтоке существует полная безопасность типов, я даже не знаю, что и сказать.

При этом, похоже, этот кто-то вообще не читает ответов.

AVC>>Вот этой целостности до Оберона просто не существовало.

VD>Я бы назвал Оберон неудавшимся экспеременотом который попытался вобрать в себя лучшие идеи существовавшие на тот момент. И неудачным он стал потому, что автор неверно оценил список этих лучших идей. Авторы Явы, Дельфи, Шарпа, Ди оказались чуть более прозарливы. А то что некоторые их мысли совпали говорит о том, что у них у всех были правильные мысли.

Конкретнее, пожалуйста. В чем совпали мысли авторов Явы, Дельфи, Шарпа, Ди?
И что именно неверно оценил Вирт?

VD>>>Так что единственный вклад в науку Вирта — это как не смешно звучит — это Паскаль, в котором Вирт отстаивал принципы строгой статической типизации. Все остальное всего лишь развитие этой идеи на базе заимствований из других языков.

AVC>>Угу, "всего лишь".

VD>Я, кстати, не сказал, что это был ненужный, или даже малый вклад. Так давайте же ценить Вирта за то что он действительно сделал, а не за то что его имя является брэндом.

Давайте. Только Оберон гораздо лучше Паскаля. Поэтому ценю Вирта не столько за Паскаль (в котором многие идеи были еще в зачатке), а за Оберон, давший этим идеям реальное воплощение.

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

C>ISO-IEC-14882(2003): описание языка заканчивается на 296 странице,

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

C>(C# Language Working Draft 2.7, June 2004 (PDF)): описан только язык,
C>без послесловий всего 454 страницы.

Только язык? А как же соглашения об именовании, например? Описание грамматики? Описание генератора документации?

а за ссылочку спасибо

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

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

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

Д>да и вообще спор не имеет особого смысла. Сложность грамматики и сложность реализации языка — вещи совершенно перпендикулярные. Достаточно вспомнить про тот же самый экспорт шаблонов.

Который, очень вероятно, так и останется тупиковой ветвью развития. С последующим исключением из стандарта.

... << RSDN@Home 1.1.4 stable rev. 510>>

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

E>Который, очень вероятно, так и останется тупиковой ветвью развития. С последующим исключением из стандарта.

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

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

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

E>А ты попробуй j2ee приложение на j2me платформе запустить.

Отличный набор слов, звучит убидительно — только ссмысла в них нет, поскольку j2ee и j2me реализуют разные интерфейсы

E>И Java и C++ -- кроссплатформенные языки. А вот отдельные программы на них совершенно не переносимы. И в C++ посредством директивы asm есть возможность такую программу при необходимости сделать.

Тогда все языки кроссплатформенны. Абсолютно.
Даже распоследний ассемблер. Был бы только компилятор под нужную платформу

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

Если моё приложение будет искать в заранее заданной папке А, заранее заданный файл B и, ненайдя его, заканчивать работу — то оно станет непреносимым не то что между платформами, но даже между разными инстансами одной и той же платформы

^^^ на правах анекдота.

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

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

AVC>SYSTEM — не отдельный модуль

Да? И что каким оператором является SYSTEM?

... << RSDN@Home 1.2.0 alpha rev. 618>>

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

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

VD>>Оберон созданный в 88 даже не додумался вобрать в себя зачатки ООП. Новых идей в нем — 0.

AVC>Пусть так. (Хотя у меня прямо противоположное мнение. Интересно, как удалось Вирту создать объектно-ориентированную операционную систему на языке, "не вобравшем в себя зачатки ООП"?)

Зачатки ООП появились в Оберон 2. А это произошло несколько позже.

AVC>Хотелось бы только понять, что именно Vlad2 считает "новыми идеями", а что "старыми"?

VladD2, если можно.

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

В общем, были языки в которых та или иная фича появилась в первый раз. Это Алгол, Симула, Смолток, Фортран, С, Паскаль, Лисп, ОКамл и т.п. А есть успешные и не очень собиратели идей. К оным как раз относятся Оберон, Шарп и возможно Ява (хотя есть пара сомнений).

Но вот что точно, так это то что ни Ява, ни Шарп не являются клонами Оберона. Их авторы смотрели на множество языков. Оберон конечно был среди них, но утверждать что из него что-то было взято нельзя просто потому что он сам все взял из других языков.

AVC>Лично у меня с БрейнФаком другая ассоциация — Си++.
AVC>По крайней мере, эффект от Си++ вполне соответствующий.

А ты спопоставь факты. Вирт стремился к минимализму в синтаксисе? БрэйнФак этого достиг. С++ все же явно синтаксически богаче.

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

VD>>Смолток как минимум. Еще вопросы?

AVC>По-моему, я ясно назвал Смоллток антипримером.

Где? И почему? Как раз все перечисленное в нем уже было.

AVC>Если кто-то считает, что в Смоллтоке существует полная безопасность типов,

Я не знаток Смолтока, но вроде как с этим проблем нет.

AVC> я даже не знаю, что и сказать.

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

AVC>При этом, похоже, этот кто-то вообще не читает ответов.

Ты для начала обоснуй утверждение о дырах в Смолтоке, а потом посмотрим кто что читает не так.

AVC>Конкретнее, пожалуйста. В чем совпали мысли авторов Явы, Дельфи, Шарпа, Ди?

Автоматическое управление памятью, безопастность типов (Ди тут чуть в стороне, но все же).

AVC>И что именно неверно оценил Вирт?

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

VD>>Я, кстати, не сказал, что это был ненужный, или даже малый вклад. Так давайте же ценить Вирта за то что он действительно сделал, а не за то что его имя является брэндом.

AVC>Давайте. Только Оберон гораздо лучше Паскаля.

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

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

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

... << RSDN@Home 1.2.0 alpha rev. 618>>

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

E>>А ты попробуй j2ee приложение на j2me платформе запустить.

NGG>Отличный набор слов, звучит убидительно — только ссмысла в них нет, поскольку j2ee и j2me реализуют разные интерфейсы

Не менее отличный набор, чем:

Write once, run everywhere

Как выясняется, только набором он и остался.

E>>И Java и C++ -- кроссплатформенные языки. А вот отдельные программы на них совершенно не переносимы. И в C++ посредством директивы asm есть возможность такую программу при необходимости сделать.

NGG>Тогда все языки кроссплатформенны. Абсолютно.
NGG>Даже распоследний ассемблер. Был бы только компилятор под нужную платформу

Ты сам пришел к правильному выводу: язык является кроссплатформенным, если на разных платформах есть компиляторы этого языка. Я бы добавил, что эти компиляторы должны уметь компилировать корректные программы, которые не используют не описанные в стандарте (платформо-зависимые) вещи.

А посколько на DEC Alpha вряли есть x86 ассемблер, то x86 ассемблер не является кроссплатформенным.

... << RSDN@Home 1.1.4 stable rev. 510>>

NotGonnaGetUs wrote:

> E>И Java и C++ -- кроссплатформенные языки. А вот отдельные программы
> на них совершенно не переносимы. И в C++ посредством директивы asm
> есть возможность такую программу при необходимости сделать.
> Тогда все языки кроссплатформенны. Абсолютно.

Да, в таком смысле — все языки кроссплатформенны.

> Даже распоследний ассемблер. Был бы только компилятор под нужную
> платформу

Только вот программа на ассемблере не будет выполняться на другой
архитектуре. А вот программа на С — будет.

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

Posted via RSDN NNTP Server 1.9

Дарней wrote:

> C>ISO-IEC-14882(2003): описание языка заканчивается на 296 странице,
> Такой же в точности версии у меня нет, так что сравнить не могу.
> Однако, никакой четкой границы между описанием собственно языка и
> библиотек там не прослеживается.

Граница там абсолютно четкая:

15. Exception handling
16. Preprocessor directives
17. Library introduction.

Ну можно в спеку самого языка еще добавить 20 страниц "Language support
library". Все равно до C# не дотягивает.

> C>(C# Language Working Draft 2.7, June 2004 (PDF)): описан только язык,
> C>без послесловий всего 454 страницы.
> Только язык? А как же соглашения об именовании, например? Описание
> грамматики? Описание генератора документации?

Только язык. Соглашения о наименовании и грамматику я включил в оба
стандарта языка. Описание генератора документации в C# я специально
пропустил.

> да и вообще спор не имеет особого смысла. Сложность грамматики и
> сложность реализации языка — вещи совершенно перпендикулярные.
> Достаточно вспомнить про тот же самый экспорт шаблонов.

Экспорт шаблонов — это не сверхсуперсложная фича, просто для ее
реализации приходилось менять само ядро компилятора.

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

Posted via RSDN NNTP Server 1.9

Трурль wrote:

> I went to a Pascal conference in Southampton in 1977 and Brinch-Hansen
> described Concurrent
> Pascal. When asked what he thought of Modula (that Wirth just had
> brought out), he replied that
> you might do something clever but then "Claus" would come with the
> worked-through elegant version of it!

К чему бы это? Никто вроде бы не спорит, что для своего времени (70-80е
годы) Паскаль и его последователи были одними из лучших языков. Только
вот времени с 77 года уже скоро 30 лет будет.

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

Posted via RSDN NNTP Server 1.9

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

>> Даже распоследний ассемблер. Был бы только компилятор под нужную
>> платформу

C>Только вот программа на ассемблере не будет выполняться на другой
C>архитектуре. А вот программа на С — будет.

Будет-будет, главное иметь правильный компилятор

Эмулятор нужной архитекутры, написанный на одном из "кроссплатформенных языков"
+ компилятор с ассеблера в код на вышеупоянутом языке взаимодействующий с эмулятором +
уже "настоящий" компилятор в машинный код с "кроссплатформенного языка"

^^^ продолжение анекдота.

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

C>Граница там абсолютно четкая:
C>

C>15. Exception handling
C>16. Preprocessor directives
C>17. Library introduction.

C>Ну можно в спеку самого языка еще добавить 20 страниц "Language support
C>library". Все равно до C# не дотягивает.

То есть вот это, например:

18.4 Dynamic memory management 337

уже не является частью описания языка? Лихо ты с ним обошелся

C>Экспорт шаблонов — это не сверхсуперсложная фича, просто для ее
C>реализации приходилось менять само ядро компилятора.

ну да, ввести четвертую стадию обработки кода — прелинкер.
всего навсего

ладно, неважно это всё

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

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

E>Не менее отличный набор, чем:
E>

E>Write once, run everywhere

E>Как выясняется, только набором он и остался.

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

Компилируем один раз. Запускаем на какой угодно платформе, где стоит jdk нужной версии + есть порты не pure java библиотек, если таковые использовались (например, swt). Естественно, с точностью до багов реализации %)

Если вам обещали большее... — я точно ничего не могу поделать с этим

E>Ты сам пришел к правильному выводу: язык является кроссплатформенным, если на разных платформах есть компиляторы этого языка. Я бы добавил, что эти компиляторы должны уметь компилировать корректные программы, которые не используют не описанные в стандарте (платформо-зависимые) вещи.

Тут вольно — не вольно задумаешься.

Если есть стандарт "теоретический" и есть компиляторы, которые являются стандартном "практическим", и эти стандарты различаются (причём даже зависят от платформы), то говорить "язык Y@@" мы вообще не имеем права,
т.к. для разных языков используются одно название! Что в свою очередь даёт только повод к путанице и пространство для игры со словами, тем самым лишая смысла большую часть высказываний, поскольку они не могут быть в результате выражены
просто и однозначно

E>А посколько на DEC Alpha вряли есть x86 ассемблер, то x86 ассемблер не является кроссплатформенным.

По-этому поводу я ответил в посте рядом

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

E>>

E>>Write once, run everywhere

E>>Как выясняется, только набором он и остался.

NGG>Ну отчего же, если не путать желаемое с предлагаемым, то вполне себе правильный слова.
NGG>Так оно на практике и есть.

NGG>Компилируем один раз. Запускаем на какой угодно платформе, где стоит jdk нужной версии + есть порты не pure java библиотек, если таковые использовались (например, swt). Естественно, с точностью до багов реализации %)

Так ведь, если программа состоит только из if, switch и return, а из jdk использует только java.lang, то все так и есть. А если взять какую нибудь Java реализацию для SIM-карт (не для телефонов, хотя я слышал, что и у телефонов с поддержкой j2me так же есть проблемы с совместимостью JDK), то окажется, что весь API там свой. Да еще и сама Java урезана так, что даже лишний вызов метода не сделаешь, т.к. под стек всего 256 байт отводится. Вот и получается, что Java-приложение для такой платформы имеет с Java-приложением для другой платформы общего только название Java.

Тоже самое можно сказать и о C/C++. Пока ты пользуешься STL/stdlibc -- твои программы вполне себе переносимы. А взял FindFirst вместо opendir -- все, кроссплатформенность кончилась.

E>>Ты сам пришел к правильному выводу: язык является кроссплатформенным, если на разных платформах есть компиляторы этого языка. Я бы добавил, что эти компиляторы должны уметь компилировать корректные программы, которые не используют не описанные в стандарте (платформо-зависимые) вещи.

NGG>Тут вольно — не вольно задумаешься.

NGG>Если есть стандарт "теоретический" и есть компиляторы, которые являются стандартном "практическим", и эти стандарты различаются (причём даже зависят от платформы), то говорить "язык Y@@" мы вообще не имеем права,

А стандарт C++ по-твоему -- это "теоритический" стандарт?
В такой же ситуации находится и Java, если брать Sun Java и GNU Java Compiler.
Или C# от MS или Mono, или DotGNU.

... << RSDN@Home 1.1.4 stable rev. 510>>

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

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

C>>Дарней wrote:

>>> ПК>Объем спецификации C# 2 не меньше, чем объем спецификации C++ даже,
>>> особенно при учете того, что спецификация C++ заметно подробнее.
>>> Откуда дровишки?

C>>Скачай и сравни сам.

Д>Да я вот и сравнил. C# 2.0 — 115 страницы, C++ — 776 страниц. Спека по C++ к тому же далеко не самая свежая. И где ты тут усмотрел, что у C# она "не меньше"?
а кто подскажет откуда можно с++ спецификацию посл. скачать? так сказать почитать на сон грядущий

... << RSDN@Home 1.2.0 alpha rev. 618>>

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

E>Так ведь, если программа состоит только из if, switch и return, а из jdk использует только java.lang, то все так и
E>есть. А если взять какую нибудь Java реализацию для SIM-карт (не для телефонов, хотя я слышал, что и у телефонов с
E>поддержкой j2me так же есть проблемы с совместимостью JDK), то окажется, что весь API там свой. Да еще и сама Java
E>урезана так, что даже лишний вызов метода не сделаешь, т.к. под стек всего 256 байт отводится. Вот и получается, что
E>Java-приложение для такой платформы имеет с Java-приложением для другой платформы общего только название Java.

Не надо ничего брать, достаточно не путать твёрдное с круглым, причём мне тоже

Существует спецификация языка java
http://java.sun.com/docs/books/jls/third_edition/html/j3TOC.html

Cуществует спецификация виртуальной машины
http://java.sun.com/docs/books/vmspec/2nd-edition/html/VMSpecTOC.doc.html

и

Существуют стандарты J2SE, J2EE, J2ME и что-то там для карт, — вот они как раз,
не являются стандартом языка, это стандарты библиотек.

Процитированная вами фраза: "Write once, run everywhere", относится к языку java и его байткоду.
Например, я могу написать и скомпилировать j2me-приложение на PC, там же могу его запустить и потестировать, и
и, абсолютно ничего не меняя, я могу запустить полученный код на телефоне.

Всё!

Если приложение требует 150мб памяти, а есть только 10кб — это не значит, что оно стало зависить от платформы, оно стало зависеть от параметров этой платформы, а именно от количества доступной памяти

Но никто ведь и не обещал чудес?

Думаю каждый понимает, что если приложению А, требуется библиотека Б, а её нет, то приложение А работать не станет.
Тут уже речь идёт не о переносимости, а о чём-то другом, более печальном

Аналогичную ситуацию мы получаем, когда пытаемся запустить приложения требующее j2ee библиотек с j2me библиотеками

Или приложение использующее библиотеку телефона сименс в телефоне нокиа

Я уверен, что не открыл для вас ничего нового о java.
Единственное в чём мы расходимся — это в трактовке "Write once, run everywhere".

В этом сообщении я, как мог, прокомментировал свои предыдущие слова:
NG> Ну отчего же, если не путать желаемое с предлагаемым, то вполне себе правильный слова.
NG> Так оно на практике и есть.

E>Тоже самое можно сказать и о C/C++. Пока ты пользуешься STL/stdlibc -- твои программы вполне себе переносимы. А взял FindFirst вместо opendir -- все, кроссплатформенность кончилась.

Только их ещё компилировать нужно для этого

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

Или написать самим с нуля.

^^^ Это если отвлечься на практическую сторону дела, которая делают такую кроссплатформенность скорее номинальной,
чем реальной, по сравнению с той же java.

А теоретически — да, сначала "вполне себе", а потом — "кончилась"

E>А стандарт C++ по-твоему -- это "теоритический" стандарт?

Какой-то там ISO C++0x %)

E>В такой же ситуации находится и Java, если брать Sun Java и GNU Java Compiler.
E>Или C# от MS или Mono, или DotGNU.

В такой, да не совсем.

Sun сертифицирует реализации своих стандартов и не допускает к жизни и комерческому распространению
"кривые реализации" своих спецификаций, одновременно с этим предлагая свои реализации: бесплатные и сделанные на достаточно высок уровне, за что sun'у большой респект.
Ситуация, когда один компилятор считает так, а другой этак — ноненс.

Кстати, gcj — он и есть GNU Java Compiler? — к моему удивлению оказался медленнее sun реализации j2se,
к тому же он живёт всё ещё на уровне java1.2, поддерживая её в не полном виде %)
Его можно называть "сужением" языка, но никак не "платформеннозависимым или любым другим расширением", как это имело место быть с С++ (прости господи, за упоминание в суе этого славного языка)

Но речь не об этом.

Что бы понять о чём речь придётся напрячься и вспомнить о какой "ситуации" шла речь.

Вспомнил.

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

Да, вы правы, и java и с# оказываются в похожей ситуации, только масштаб другой.
Согласитесь, общественность не сильно озаботится, если я напишу кривую jvm для java? %)
У java есть Sun c референсной реализацией спецификаций, у C# — вообще только одна
полная реализация спецификаций — от микрософт (моно — всё ещё не поддерживает спецификацию целиком
и давайте не будем кривить душой, .net никогда не слезет с win %))

Странный у нас получается разговор. Не понятно про что

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

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

Дык, как раз таки в результате импорта SYSTEM появляется возможность использовать новые синтаксические конструкции (смотри, например, BlackBox).

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

NGG>Странный у нас получается разговор. Не понятно про что

Имхо, ты просто подтвердил, что суть не столько в кроссплатформенности языков, сколько в кроссплатформенности написанных на этих языках программ (это про j2ee программу и j2me программу, которые без своих платформ работать не будут).

Кстати, не некоторые SIM карты нельзя заливать Java-вский байт-код -- нужно специальными препроцессорами получить найтив код для этой SIM-ки, и именно этот нейтив код заливать. Ну это так, к слову.

... << RSDN@Home 1.1.4 stable rev. 510>>

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

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

СГ>

Дык, как раз таки в результате импорта SYSTEM появляется возможность использовать новые синтаксические конструкции (смотри, например, BlackBox).

Ну блин, неужели их здесь коротко пречислить нельзя было?! Вот взял бы и написал: без SYSTEM case писать нельзя, а вот с SYSTEM, кроме case, мы еще elsif получаем. Посмотреть на такие фокусы мне интересно, а вот лазить, искать какой-то BlackBox -- времени нет. Я лучше с Павлом Дворкиным понастальгирую.

... << RSDN@Home 1.1.4 stable rev. 510>>

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

E>Имхо, ты просто подтвердил, что суть не столько в кроссплатформенности языков, сколько в кроссплатформенности написанных на этих языках программ (это про j2ee программу и j2me программу, которые без своих платформ работать не будут).

Вот же как получается.

А хотел сказать только одно: пример про j2ee и j2me — не корректен.
И не имеет к переносимости и кроссплатформенности никакого отношения.

Просто этим приложениям нужны разные библиотеки...

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

E>Ну блин, неужели их здесь коротко пречислить нельзя было?

Появляется возможность писать системные флаги SysFlag, машинные инструкции, обертки над win32 dll-ками и т.п.

Type     =    Qualident
        | ARRAY ["[" SysFlag "]"] [ConstExpr {"," ConstExpr}]
            OF Type 
        | RECORD ["[" SysFlag "]"] ["("Qualident")"] FieldList
            {";" FieldList} END
        | POINTER ["[" SysFlag "]"] TO Type
        | PROCEDURE [FormalPars].
ProcDecl    =    PROCEDURE ["[" SysFlag "]"] [Receiver] IdentDef
            [FormalPars] ";"
        DeclSeq [BEGIN StatementSeq] END ident.
FPSection    =    [VAR ["[" SysFlag "]"]] ident {"," ident} ":" Type.
SysFlag    =    ConstExpr | ident.

Для машинных инструкций:

ProcDecl    =    PROCEDURE "[" SysFlag "]" IdentDef [FormalPars]
            [ConstExpr {"," ConstExpr}] ";".

Обертка для win32 dll-ки:

Module     =    MODULE ident ["[" SysString "]"] ";"
        [ImportList] DeclSeq  [BEGIN StatementSeq] END ident ".".
ProcDecl    =    PROCEDURE ["[" SysFlag "]"] [Receiver]
        IdentDef ["[" [SysString ","] SysString "]"] [FormalPars] ";"
        DeclSeq [[BEGIN StatementSeq] END ident].
SysString    =    string.

Дарней wrote:

> C>Ну можно в спеку самого языка еще добавить 20 страниц "Language support
> C>library". Все равно до C# не дотягивает.
> То есть вот это, например:
> 18.4 Dynamic memory management 337
> уже не является частью описания языка? Лихо ты с ним обошелся

Я же сказал, что еще можно добавить 20 страниц Language support library.

> C>Экспорт шаблонов — это не сверхсуперсложная фича, просто для ее
> C>реализации приходилось менять само ядро компилятора.
> ну да, ввести четвертую стадию обработки кода — прелинкер.
> всего навсего

Так и делают.

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

Posted via RSDN NNTP Server 1.9

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

VD>Зачатки ООП появились в Оберон 2. А это произошло несколько позже.

Кстати, для тех кто по разным причинам не в курсе о чем речь и им не понятно почему VladD2 отказывается видеть в Oberon-1 признаки ООП языка надо заметить, что разница между Oberon-1 и Oberon-2 в этом смысле состоит в следующем:
В Oberon-1 динамический полиморфизм реализован посредством процедурных переменных, а в Oberon-2 динамический полиморфизм реализован посредством процедур связанных с типом (так называемых виртуальных функций).

Вот пример на Oberon-1:

MODULE Oberon1;

  TYPE
    Object* = POINTER TO RECORD
      handler-: Handler;
      (*...*)
    END;

    Message* = RECORD END;

    Handler* = PROCEDURE(obj: Object; VAR msg: Message);


  PROCEDURE Handle (obj: Object; VAR msg: Message);
  BEGIN 
    (* ... *)
  END Handle;

  PROCEDURE NewObject (VAR obj: Object);
  BEGIN
    NEW(obj);
    obj.handler := Handle;
    (*...*)
  END NewObject;

END Oberon1.

А вот аналогичный пример на Oberon-2 (с использованием процедуры связанной с типом):

MODULE Oberon2;

  TYPE
    Object* = POINTER TO RECORD
      (*...*)
    END;

    Message* = RECORD END;


  PROCEDURE (obj: Object) Handle* (VAR msg: Message);
  BEGIN 
    (* ... *)
  END Handle;

  PROCEDURE NewObject (VAR obj: Object);
  BEGIN
    NEW(obj);
    (*...*)
  END NewObject;

END Oberon2.

Собственно, вот такая вот разница.

Для полноты картины аналогичный код на Component Pascal:

MODULE ComponentPascal;

  TYPE
    Object* = POINTER TO EXTENSIBLE RECORD
      (*...*)
    END;

    Message* = RECORD END;


  PROCEDURE (obj: Object) Handle* (VAR msg: Message), NEW, EXTENSIBLE;
  BEGIN 
    (* ... *)
  END Handle;

  PROCEDURE NewObject (VAR obj: Object);
  BEGIN
    NEW(obj);
    (*...*)
  END NewObject;

END ComponentPascal.

Отличие от Oberon-2 заключается в явно прописанных словах: NEW и EXTENSIBLE.

Oberon-1 является подмножеством Oberon-2, а Oberon-2 с некими оговорками подмножеством Component Pascal.

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

СГ>Для полноты картины аналогичный код на Component Pascal:

Извиняюсь, забыл исправить тип Message, должно быть так:

    Message* = ABSTRACT RECORD END;

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

СГ>Появляется возможность писать системные флаги SysFlag, машинные инструкции, обертки над win32 dll-ками и т.п.

<...кусок грамматики поскипан...>

Нифига не понятно. Как вообще в этом разобраться, если нет грамматик для FieldList, IdentDef, FormalPars, DeclSeq, StatementSeq.

Сергей, а по-человечески можно? Ну фрагмент программы что-ли, или объяснение на пальцах. А то приведенная тобой часть формальной грамматики для меня не сильно отличается от:

(смотри, например, BlackBox)

К тому же из того, что ты привел как-то новых конструкций и не видно. По твоим словам выходило чуть ли, что без SYSTEM в Oberon нет оператора case, а вот с SYSTEM есть. А на поверку -- аналоги __declspec или __asm из C++.

... << RSDN@Home 1.1.4 stable rev. 510>>

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

СГ>Кстати, для тех кто по разным причинам не в курсе о чем речь и им не понятно почему VladD2 отказывается видеть в Oberon-1 признаки ООП языка надо заметить, что разница между Oberon-1 и Oberon-2 в этом смысле состоит в следующем:
СГ>В Oberon-1 динамический полиморфизм реализован посредством процедурных переменных, а в Oberon-2 динамический полиморфизм реализован посредством процедур связанных с типом (так называемых виртуальных функций).

СГ>Вот пример на Oberon-1:
СГ>

СГ>  PROCEDURE NewObject (VAR obj: Object);
СГ>  BEGIN
СГ>    NEW(obj);
СГ>    obj.handler := Handle;
СГ>    (*...*)
СГ>  END NewObject;
СГ>

СГ>А вот аналогичный пример на Oberon-2 (с использованием процедуры связанной с типом):
СГ>

СГ>MODULE Oberon2;
СГ>  PROCEDURE NewObject (VAR obj: Object);
СГ>  BEGIN
СГ>    NEW(obj);
СГ>    (*...*)
СГ>  END NewObject;
СГ>

СГ>Собственно, вот такая вот разница.

Ага, всего лишь есть поддержка ООП средствами языка, или нет ее.

... << RSDN@Home 1.1.4 stable rev. 510>>

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

E>Нифига не понятно. Как вообще в этом разобраться, если нет грамматик для FieldList, IdentDef, FormalPars, DeclSeq, StatementSeq.

Эти штуки взяты из основной грамматики, а системные флаги такие:

System flags for record types

Name    Value    Description
untagged    1    No type tag and no type descriptor is allocated.
        The garbage collector ignores untagged variables.
        NEW is not allowed on pointers to untagged variables.
        No type-bound procedures are allowed for the record.
        Pointers to untagged record type or extensions of this
        record type inherit the attribute of being untagged.
        The offsets of the fields are aligned to
        MIN(4-byte, size), where size is the size of the field.
        The size of the record and the offsets of the fields are
        aligned to 32-bit boundaries.
noalign    3    Same as untagged but without alignment.
align2    4    Same as untagged but with
        MIN(2-byte, size) alignment. 
align8    6    Same as untagged but with
        MIN(8-byte, size) alignment. 
union    7    Untagged record with all fields allocated at offset 0.
        The size of the record is equal to the size of the
        largest field.
        Used to emulate C union types.

System flags for array types
Name    Value    Description
untagged    1    No typetag and no type descriptor is allocated.
        The garbage collector ignores untagged variables.
        NEW is not allowed on pointers to untagged variables.
        Pointers to this array type inherit the attribute of
        being untagged.
        Only one-dimensional untagged open arrays
        are allowed.
        For open untagged arrays, index bounds are
        not checked.

System flags for pointer types
Name    Value    Description
untagged    1    Not traced by the garbage collector.
        No type-bound procedures are allowed for the pointer.
        Must point to an untagged record.

System flags for VAR parameters
Name    Value    Description
nil    1    NIL is accepted as formal parameter.
        Used in interfaces to C
        functions with pointer type parameters.

System flags for procedures
Name    Value    Description
code    1    Definition of a Code procedure (see below).
ccall    -10    Procedure uses CCall calling convention.

E>Сергей, а по-человечески можно? Ну фрагмент программы что-ли, или объяснение на пальцах.

    PROCEDURE [code] Sqrt (x: REAL): REAL        (* Math.Sqrt *)
        0D9H, 0FAH;            (* FSQRT *)

    PROCEDURE [code] Erase (adr, words: INTEGER)    (* erase memory area *)
        089H, 0C7H,            (* MOV EDI, EAX *)
        031H, 0C0H,            (* XOR EAX, EAX *)
        059H,            (* POP ECX *)
        0F2H, 0ABH;            (* REP STOS *)

MODULE MyInterface ["MyDll"];
    PROCEDURE Proc1*;                (* Proc1 from MyDll *)
    PROCEDURE Proc2* ["BlaBla"];                (* BlaBla from MyDll *)
    PROCEDURE Proc3* ["OtherDll", ""];                (* Proc3 from OtherDll *)
    PROCEDURE Proc4* ["OtherDll", "DoIt"];                (* DoIt from OtherDll *)
END MyInterface.

    RECORD [noalign]    (* untagged, size = 7 bytes *)
        c: SHORTCHAR;    (* offset 0, size = 1 byte *)
        x: INTEGER;    (* offset 1 , size = 4 bytes *)
        i: SHORTINT    (* offset 5, size = 2 bytes *)
    END

MODULE Ddraw ["DDRAW.DLL"];

TYPE
  GUID = ARRAY 4 OF INTEGER;

  PtrIUnknown = POINTER TO RECORD [untagged]
    vtbl: POINTER TO RECORD [untagged]
      QueryInterface: PROCEDURE (this: PtrIUnknown; IN iid: GUID; OUT obj: PtrIUnknown): INTEGER;
      AddRef: PROCEDURE (this: PtrIUnknown): INTEGER;
      Release: PROCEDURE (this: PtrIUnknown): INTEGER;
    END
  END;

  PtrDirectDraw = POINTER TO RECORD [untagged]
    vtbl: POINTER TO RECORD [untagged]
      QueryInterface: PROCEDURE (this: PtrDirectDraw; IN iid: GUID; OUT obj: PtrIUnknown): INTEGER;
      AddRef: PROCEDURE (this: PtrDirectDraw): INTEGER;
      Release: PROCEDURE (this: PtrDirectDraw): INTEGER;
      Compact: PROCEDURE (this: PtrDirectDraw): INTEGER;
      ...
      SetCooperativeLevel: PROCEDURE (this: PtrDirectDraw; w, x: INTEGER): INTEGER;
      ...
    END
  END;

PROCEDURE DirectDrawCreate* (IN guid: GUID; OUT PDD: PtrDirectDraw; outer: PtrIUnknown) : INTEGER;

END Ddraw.

MODULE GDI ["GDI32"];

    CONST
        WhiteBrush* = 0; BlackBrush* = 4; NullBrush* = 5;
        WhitePen* = 6; BlackPen* = 7; NullPen* = 8;
        PSSolid* = 0; PSDash* = 1; PSDot* = 2;

    TYPE
        Bool* = INTEGER;
        Handle* = INTEGER;
        ColorRef* = INTEGER;
        Point* = RECORD [untagged] x*, y*: INTEGER END;
        Rect* = RECORD [untagged] left*, top*, right*, bottom*: INTEGER END;

    PROCEDURE CreatePen* (style, width: INTEGER; color: ColorRef): Handle;
    PROCEDURE CreateSolidBrush* (color: ColorRef): Handle;
    PROCEDURE GetStockObject* (object: INTEGER): Handle;
    PROCEDURE SelectObject* (dc, obj: Handle): Handle;
    PROCEDURE DeleteObject* (obj: Handle): Bool;
    PROCEDURE Rectangle* (dc: Handle; left, top, right, bottom: INTEGER): Bool;
    PROCEDURE SelectClipRgn* (dc, rgn: Handle): INTEGER;
    PROCEDURE IntersectClipRect* (dc: Handle; left, top, right, bottom: INTEGER): INTEGER;
    PROCEDURE SaveDC* (dc: Handle): INTEGER;
    PROCEDURE RestoreDC* (dc: Handle; saved: INTEGER): Bool;

END GDI.

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

E>Ага, всего лишь есть поддержка ООП средствами языка, или нет ее.

Если "ООП = виртуальные функции", то Вы правы. Но я так не считаю. Динамический полиморфизм можно реализовывать по разному и виртуальные функции лишь один из способов.

Здравствуйте, Сергей Губанов

Ну вот, стало понятно.

Только это больше напоминает не новый синтаксис, а анотации методов в Java/C# и ассемблерные вставки в C++.

... << RSDN@Home 1.1.4 stable rev. 510>>

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

E>>Ага, всего лишь есть поддержка ООП средствами языка, или нет ее.

СГ>Если "ООП = виртуальные функции", то Вы правы. Но я так не считаю. Динамический полиморфизм можно реализовывать по разному и виртуальные функции лишь один из способов.

Нет, разница в том, реализую ли я полифорфизм вручную, или же за меня это делает язык/компилятор.

... << RSDN@Home 1.1.4 stable rev. 510>>

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

Д>>Да я вот и сравнил. C# 2.0 — 115 страницы, C++ — 776 страниц. Спека по C++ к тому же далеко не самая свежая. И где ты тут усмотрел, что у C# она "не меньше"?
I>а кто подскажет откуда можно с++ спецификацию посл. скачать? так сказать почитать на сон грядущий

Не проснуться не боишься?

... << RSDN@Home 1.1.4 stable rev. 510>>

Сергей Губанов wrote:

> E>Ага, всего лишь есть поддержка ООП средствами языка, или нет ее.
> Если "ООП = виртуальные функции", то Вы правы. Но я так не считаю.
> Динамический полиморфизм можно реализовывать по разному и виртуальные
> функции лишь один из способов.

Тогда С — это объектно-ориентированый язык. В нем можно организовать
полиморфизм с помощью vtable'ов (что и делается в COM, кстати).

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

Posted via RSDN NNTP Server 1.9

СГ>Если "ООП = виртуальные функции", то Вы правы. Но я так не считаю. Динамический полиморфизм можно реализовывать по разному и виртуальные функции лишь один из способов.

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

... << RSDN@Home 1.1.4 stable rev. 510>>

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

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

AVK>>>>В Java есть множественное наследование интерфейсов.
AVC>>>Эта идея в Java действительно новая и, похоже, неплохая.

J>>Да, ребята...
J>>Без комментариев

AVC>А к чему такая скрытность? :)
AVC>Я имел в виду, что ни в Обероне, ни в Си++, ни в других известных мне популярных языках наследование интерфейса не было синтаксически отделено от наследования реализации.

Да потому что это нафиг не нужно, если есть полноценное множественное наследование.

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

Так что то, что в java есть синтаксическое разделение, объясняется исключительно отсутствием полноценного множественого наследования, а оставлять язык совсем без множественого наследования было бы уже совсем неприемлемо — никто бы им не пользовался.

Так что называть недоработки Java новой (!) и неплохой фичей — уж увольте. Особенно в части новизны.
Если хотите, множественное наследование интерфейсов было в винде в COM тыщу лет уж как.
И в IDL также.

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

Так... погодите.. где-то я это уже...

unsafe 
{
...
}

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

C>Тогда С — это объектно-ориентированый язык. В нем можно организовать
C>полиморфизм с помощью vtable'ов (что и делается в COM, кстати).

А главно, что это как раз доказывает гипотизу о воровстве идей Явой из Оберона. Как они лихо то украли идею ООП из Оберона-1. Ведь на С++ ни сколички не похоже.

... << RSDN@Home 1.2.0 alpha rev. 618>>

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

L>Был такой язык Clipper, мир праху его.
L>Так вот, на нём тоже можно было сэмулировать виртуальные функции примерно с такой же дозой извращений. Я так понимаю, после этого Clipper можно смело зачислять в славные ряды обьектно-ориентированных языков?

Справидливости ради, в Клипере 5 вроде как ООП ввели полноценно. Но кому он был в это время уже нужен?

... << RSDN@Home 1.2.0 alpha rev. 618>>

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

VD>Зачатки ООП появились в Оберон 2. А это произошло несколько позже.

Зачатки ООП в Обероне назывались "расширение типа" (type extension), "процедурная переменная" и "охранник типа" (type guard).

AVC>>Хотелось бы только понять, что именно Vlad2 считает "новыми идеями", а что "старыми"?

VD>VladD2, если можно.

Пардон муа.

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

Ну, Дейкстру теперь мало кто читает. Писал он об иерархии абстрактных машин и даже реализовал на основе этой идеи операционную систему THE.
Другой, и более близкий, пример — паскалевский P-код. Тот же Гослинг в 1970-е годы занимался именно паскалевским P-кодом.

VD>В общем, были языки в которых та или иная фича появилась в первый раз. Это Алгол, Симула, Смолток, Фортран, С, Паскаль, Лисп, ОКамл и т.п. А есть успешные и не очень собиратели идей. К оным как раз относятся Оберон, Шарп и возможно Ява (хотя есть пара сомнений).

VD>Но вот что точно, так это то что ни Ява, ни Шарп не являются клонами Оберона. Их авторы смотрели на множество языков. Оберон конечно был среди них, но утверждать что из него что-то было взято нельзя просто потому что он сам все взял из других языков.

Оберон первый смог свести "концы с концами", гармонично соединив главные идеи в одно целое.
Чего, повторяю, до него не было.
Поэтому Оберон — именно "классический", а не "экспериментальный" (вроде экстремального Смолтока) язык.
"Экспериментальные" языки стремятся не к сбалансированности и практичности, а к тому, чтобы все построить на основании нового "чудодейственного" средства (ООП, ФП и т.д.)

AVC>>Лично у меня с БрейнФаком другая ассоциация — Си++.
AVC>>По крайней мере, эффект от Си++ вполне соответствующий.

VD>А ты спопоставь факты. Вирт стремился к минимализму в синтаксисе? БрэйнФак этого достиг. С++ все же явно синтаксически богаче.

Т.е. Си++ — сложнее и запутаннее почти всех других языков? Не спорю.
Вирт стремился не к минимализму в синтаксисе как таковому, а к максимальной простоте и ясности в программировании.
Минимализм в синтаксисе служит именно этим целям, будучи весьма удобным и практичным.
Утверждаю это на основании сравнения своего собственного опыта на Си++ и Обероне.

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

VD>>>Смолток как минимум. Еще вопросы?

AVC>>По-моему, я ясно назвал Смоллток антипримером.

VD>Где? И почему? Как раз все перечисленное в нем уже было.

AVC>>Если кто-то считает, что в Смоллтоке существует полная безопасность типов,

VD>Я не знаток Смолтока, но вроде как с этим проблем нет.

AVC>> я даже не знаю, что и сказать.

VD>Знашь, в Смолтоке мне не нравятся две вещи. Очень необычный синтаксис и динамическая типизация.

AVC>>При этом, похоже, этот кто-то вообще не читает ответов.

VD>Ты для начала обоснуй утверждение о дырах в Смолтоке, а потом посмотрим кто что читает не так.

Сопоставь два своих утверждения: о динамической типизации в Смолтоке (определеннее: статической типизации нет вообще) и о том, что в нем нет проблем с безопасностью типов.
А затем объясни, пожалуйста, какая может быть безопасность типов в языке, в котором типов все равно что нет.

AVC>>Конкретнее, пожалуйста. В чем совпали мысли авторов Явы, Дельфи, Шарпа, Ди?

VD>Автоматическое управление памятью, безопастность типов (Ди тут чуть в стороне, но все же).

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

AVC>>И что именно неверно оценил Вирт?

VD>Потребности программистов. Его идея, что лучший язык должен быть примитивным была мягко говоря неразумной. Языки должны быть удобны и выразительны. Ну, и его маньиакальное отношение к С-шному синтаксису кроме как маниакальным камризом старика больше никак назвать нельзя. Так биться за ":=" может только недалекие люди. Очень странно что этим занимается стольк известный и уважаемый человек.

Во-первых, Оберон — не примитивный, а очень выразительный язык.
Синтаксический минимализм здесь очень важен: каждая конструкция несет свою уникальную синтаксическую нагрузку, намерения программиста сразу понятны (при чтении программы).
Что касается ":=", то признай, что ты не смог подобрать примера опечатки с ":=". Я все прощу!

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

VD>Реальное вовлощение идей Оберона было до Оберона и без Оберона.

Где??!

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

Да, логика непобедимая.
Оберон (1988) ничем не отличается от C# (2000?) с точки зрения новизны.
А может, все-таки, наоборот?

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

СГ>динамический полиморфизм реализован посредством процедур связанных с типом (так называемых виртуальных функций).

Ну ты и сноб! Хотя возможно твое мышление просто извращено обероном...

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

AVK>>>>>В Java есть множественное наследование интерфейсов.
AVC>>>>Эта идея в Java действительно новая и, похоже, неплохая.

J>>>Да, ребята...
J>>>Без комментариев

AVC>>А к чему такая скрытность?

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

J>Да потому что это нафиг не нужно, если есть полноценное множественное наследование.
<...>
J>Так что то, что в java есть синтаксическое разделение, объясняется исключительно отсутствием полноценного множественого наследования, а оставлять язык совсем без множественого наследования было бы уже совсем неприемлемо — никто бы им не пользовался.

J>Так что называть недоработки Java новой (!) и неплохой фичей — уж увольте. Особенно в части новизны.
J>Если хотите, множественное наследование интерфейсов было в винде в COM тыщу лет уж как.
J>И в IDL также.

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

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

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

iT>Так... погодите.. где-то я это уже...
iT>

iT>unsafe 
iT>{
iT>...
iT>}
iT>

Т.к. компиляторы Оберона (за исключением компиляторов, ориентированных на JVM и .NET) порождают "нативный" код, то

unsafe {}

имеет несколько другой смысл, чем обероновское

IMPORT SYSTEM;

Сходство тоже есть.

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

AVC>Сопоставь два своих утверждения: о динамической типизации в Смолтоке (определеннее: статической типизации нет вообще) и о том, что в нем нет проблем с безопасностью типов.
AVC>А затем объясни, пожалуйста, какая может быть безопасность типов в языке, в котором типов все равно что нет.

Алексей, статическая/динамическая и строгая/слабая типизация -- это ортогональные понятия, как это хорошо объяснил _vovin вот здесь: Re[25]: Типизация и здесь: Re[27]: Типизация.

... << RSDN@Home 1.1.4 stable rev. 510>>

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

>> E>Ага, всего лишь есть поддержка ООП средствами языка, или нет ее.
>> Если "ООП = виртуальные функции", то Вы правы. Но я так не считаю.
>> Динамический полиморфизм можно реализовывать по разному и виртуальные
>> функции лишь один из способов.

C>Тогда С — это объектно-ориентированый язык. В нем можно организовать
C>полиморфизм с помощью vtable'ов (что и делается в COM, кстати).

И даже без vtable-ов. Вполне достаточно указателей на функции.
О чем, кстати, писал Пайк в своей статье о стиле программирования на Си.

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

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

E>>Так ведь, если программа состоит только из if, switch и return, а из jdk использует только java.lang, то все так и
E>>есть. А если взять какую нибудь Java реализацию для SIM-карт (не для телефонов, хотя я слышал, что и у телефонов с
E>>поддержкой j2me так же есть проблемы с совместимостью JDK), то окажется, что весь API там свой. Да еще и сама Java
E>>урезана так, что даже лишний вызов метода не сделаешь, т.к. под стек всего 256 байт отводится. Вот и получается, что
E>>Java-приложение для такой платформы имеет с Java-приложением для другой платформы общего только название Java.

NGG>Не надо ничего брать, достаточно не путать твёрдное с круглым, причём мне тоже

NGG>Существует спецификация языка java
NGG>http://java.sun.com/docs/books/jls/third_edition/html/j3TOC.html
NGG>Cуществует спецификация виртуальной машины
NGG>http://java.sun.com/docs/books/vmspec/2nd-edition/html/VMSpecTOC.doc.html
NGG>и
NGG>Существуют стандарты J2SE, J2EE, J2ME и что-то там для карт, — вот они как раз,
NGG>не являются стандартом языка, это стандарты библиотек.

Ну не совсем.
В J2ME нет:
* Java Native Interface (JNI, собственный интерфейс Java);
* загрузчики определяемых пользователем классов;
* отражение (reflection);
* группы нитей и демоны нитей (thread daemons);
* финализация (отсутствие метода Object.finalizeQ в библиотеках CLDC);
* слабые ссылки (weak references);
* ошибки (поддерживается небольшая подгруппа ошибок J2SE);
* проверка класса файла.
А это языковые фичи, а не библиотечные (не как в C++).

Большая свинья подложена Sun'ом в виде preverify для мобильного кода. Ничего страшного в этом нет, но по самой своей сути он нарушает принцип WORA.
Конечно, прикладной код J2ME может быть запущен в J2SE. Но точно такой же код, не прошедший preverify никогда не будет работать в среде J2ME.
(Отрадно, что сейчас ведутся работы над новой спецификацией J2ME CDC1.1, в которой не будет необходимости "верифицировать" код во время разработки, а язык Java для портативных устройств снова пулучит те качества, какие у него есть на десктопе (J2SE v.1.4), и Nokia обещала сделать девайсы Series60 на этой платформе, но всё может измениться не в лучшую сторону...)

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

E>Алексей, статическая/динамическая и строгая/слабая типизация -- это ортогональные понятия, как это хорошо объяснил _vovin вот здесь: Re[25]: Типизация и здесь: Re[27]: Типизация.

"строгая" — недетерминированное понятие. Периодически используется как для описания статической-, так и для сильной-типизации. Так что предлагаю его не испоьзовать.

... << RSDN@Home 1.2.0 alpha rev. 618>>

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

AVC>>Сопоставь два своих утверждения: о динамической типизации в Смолтоке (определеннее: статической типизации нет вообще) и о том, что в нем нет проблем с безопасностью типов.
AVC>>А затем объясни, пожалуйста, какая может быть безопасность типов в языке, в котором типов все равно что нет.

E>Алексей, статическая/динамическая и строгая/слабая типизация -- это ортогональные понятия, как это хорошо объяснил _vovin вот здесь: Re[25]: Типизация и здесь: Re[27]: Типизация.

Евгений,

это очень интересная тема.
Насколько я вижу, ты всерьез увлекся возможностями динамических языков программирования.
Я тоже немного об этом думал, хотя, скорее всего, меньше, чем ты и _vovin.
Мое возражение тебе (возможно, недостаточно хорошо продуманное) состоит в следующем: использование динамической типизации не требует отказа от статической типизации.
Такие языки, как Смолток, создаются во время горячего увлечения новой идеей.
Все старое и хорошо проверенное выкидывается как "старый хлам".
Как эксперимент (видимо, именно это Вирт называет academic exсersize) это очень интересно.
Но давай посмотрим, а правда ли это дает такие преимущества?

В чем я вижу преимущества динамической типизации на примере
Lisp/Smalltalk (многие перечисленные преимущества являются следствием
предыдущих):

* Маленькое количество правил языка, простой, но очень гибкий и
выразительный синтаксис

Ну что же, Оберон вполне подходит. Только он не в пример читабельнее Смолтока.

* Нет необходимости писать много лишнего кода для многократного
указания типов

Здесь, конечно, Оберон "уступает" Смолтоку: он требует указания типа.
Но посмотрим с другой стороны: (1) указание типа повышает читабельность программы; (2) велика роль опечаток; (3) типы — не хлам, а строительные конструкции.

* Широкии возможности интроспекции/рефлекшна

Есть в Обероне.

* Наличие мощных конструкции вроде closures, continuations, green threads

Здесь, к сожалению, ничего определенного сказать не могу.
Еще в Паскале были closures, но не знаю, имеется ли здесь в виду что-то похожее.

* Более высокий уровень абстракции, благодаря чему можно на самом
языке можно создавать domain-specific languages

Интересно, в чем заключается "высота" абстракции в данном случае?
Я, например, использую в приложениях "специфические" АТД. Это ведь тоже абстракция?

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

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

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

Все это есть (и было с самого начала) в Обероне.
Сохранилось и в Компонентном Паскале.
При наличии статической типизации.

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

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

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

А то как же

Эпиграф: Гослинг и его команда использовали C++ как руководство — чего нужно избегать.

Ты в целом прав, ошибся в некоторых деталях:
1) Oak был не "язык для некоторого устройства", а язык для встраиваемых компьютеров вообще (в смысле, стиральных машин, микроволновок и проч.), предполагалось продавать его производителям бытовой техники; производители не заинтересовались (для них идея показалась слишком сложной; в частности, TimeWarner, искавший партнера для проекта "интерактивного телевидения", выбрало SiliconGraphics, а не Sun) — в результате чего проект провалился (заметим в скобках, что много лет спустя Java, похоже, таки добралась до бытовой техники — через мобильную связь).
2) Для Гослинга Билл Джой не был "сам". Они дружили еще будучи студентами (оба были Unix-гуру, поддерживающими серверы своих ВУЗов, познакомились в сети). Так что Oak был придуман Гослингом и Джоем совместно, и Джой внимательно следил за проектом
3) Как раз Гослинг после провала идеи окучить производителей бытовой техники собирался бросать проект и распускать группу. А Джой, как и было сказано, придумал переориентацию проекта.

Теперь про корни языка.
Все из тот же GoTo by Steve Lohr* подтверждает то, что говорил eao197: начинался язык как "слегка упрощенный C++", рабочий прототип Star7 был готов в 1992.

Тем не менее — готовность Star7 не означала что на тот момент существовала Java. В 1994 году ее разработка была еще в разгаре, и окончательно язык сформировался в начале 1995го. Интересно, что дизайн языка был результатом длительного спора Джоя и Гослинга — первый считал, что важнее мощность и выразительность, второй — что простота. Гослинг победил.
Цитата:

Для разработчика, язык выглядел совершенно как C++. Но в душе Java взяла очень много от Smalltalk, Lisp и Pascal. Моя заслуга в том, что я смог их совместить. (Джеймс Гослинг)

Такие дела.

* Я цитирую чаще всего именно эту книгу, потому что она — относительно надежный источник.
Надежный — потому что Steve Lohr ради ее написания лично разговаривал со всеми участниками событий. (в нашем случае — Gosling, Joy, McNeele, Schmidt).
Относительно — потому что "лично участники событий" могут забыть детали или (намеренно или случайно) соврать.

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

C>Я же сказал, что еще можно добавить 20 страниц Language support library.

даже есди добавить 20, то все равно не хватит

>> C>Экспорт шаблонов — это не сверхсуперсложная фича, просто для ее
>> C>реализации приходилось менять само ядро компилятора.
>> ну да, ввести четвертую стадию обработки кода — прелинкер.
>> всего навсего

C>Так и делают.

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

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

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

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

Д>>>Да я вот и сравнил. C# 2.0 — 115 страницы, C++ — 776 страниц. Спека по C++ к тому же далеко не самая свежая. И где ты тут усмотрел, что у C# она "не меньше"?
I>>а кто подскажет откуда можно с++ спецификацию посл. скачать? так сказать почитать на сон грядущий

L>Не проснуться не боишься?

неа

у меня организм странный, когда бы не лег всегда меня поднимает в 06:25 или 06:30

... << RSDN@Home 1.2.0 alpha rev. 618>>

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

E>>Алексей, статическая/динамическая и строгая/слабая типизация -- это ортогональные понятия, как это хорошо объяснил _vovin вот здесь: Re[25]: Типизация и здесь: Re[27]: Типизация.

AVC>Евгений,

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

Да, Алексей, тема очень интересная. Но я бы сказал, что это динамические языки (в частности Ruby) увлекли меня своими возможностями. Настолько, что вскоре наши с VladD2 споры будут идти не о C# vs C++, а о Ruby vs C#

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

AVC>Мое возражение тебе (возможно, недостаточно хорошо продуманное) состоит в следующем: использование динамической типизации не требует отказа от статической типизации.

Чесно говоря, я вообще слабо себе представляю, как динамическая типизация может уживаться со статической. Разве что, как в C++ шаблонах. Но там мы не можем выйти за рамки того, что определили во время компиляции.

AVC>Такие языки, как Смолток, создаются во время горячего увлечения новой идеей.
AVC>Все старое и хорошо проверенное выкидывается как "старый хлам".
AVC>Как эксперимент (видимо, именно это Вирт называет academic exсersize) это очень интересно.

Возможно, в случае со Смолтолком так и было. Но тогда вообще была эра "Дикого Запада" -- языки с революционными идеями появлялись и имели возможность урвать для себя часть программистов. Нужно заметить, что Smalltalk-у и Lisp-у это вполне удалось. Поэтому они как-то здравствуют и поныне. Хотя их синтаксис, конечно, очень уж непревычен для меня. Возможно, синтаксис таких языков, как C, Pascal и производных от них так удобен именно потому, что их авторам не навился синтаксис Smalltalk/Lisp.

Однако, мир не стоит на месте. Тот же Ruby вобрал в себя очень много из того, что было в Smalltalk (фактически, все пункты, которые перечислил _vovin). Но при этом он имеет очень похожий на C/Perl/Python синтаксис и допускает программирование в стиле C/Perl, что очень облегчает вхождение в Ruby. Тем не менее, Ruby создавался не как реализация очередной академической идеи, а как прагматический язык для прагматических задач. Именно благодоря этому Ruby уже больше десяти лет, а его популярность в последние годы увеличивается. Так что, имхо, обкатаные в Smalltalk идеи были с успехом востребованны в более удобном (для меня), современном языке.

Дальше я попробую сравнивать твои и _vovin доводы с Ruby (т.к. Smalltalk я не знаю, да к тому же, "всяк кулик свое болото хвалит").
А вообще-то странно, ты сравниваешь Smalltalk и Oberon, а я C++ и Ruby

Но мы именно здесь не столько об Oberon vs Smalltalk, сколько о статическая типизация vs динамическая типизация.

AVC>Но давай посмотрим, а правда ли это дает такие преимущества?

AVC>

AVC>В чем я вижу преимущества динамической типизации на примере
AVC>Lisp/Smalltalk (многие перечисленные преимущества являются следствием
AVC>предыдущих):

AVC> * Маленькое количество правил языка, простой, но очень гибкий и
AVC> выразительный синтаксис

AVC>Ну что же, Оберон вполне подходит. Только он не в пример читабельнее Смолтока.

Давай я объеденю этот пункт с еще одним:

AVC>

AVC> * Более высокий уровень абстракции, благодаря чему можно на самом
AVC> языке можно создавать domain-specific languages

AVC>Интересно, в чем заключается "высота" абстракции в данном случае?
AVC>Я, например, использую в приложениях "специфические" АТД. Это ведь тоже абстракция?

Думаю, что в Ruby все же не такой простой синтаксис, как в Smalltalk или Pascal. Хотя бы потому, что это line-oriented язык. Т.е. в нем

def hello
    puts "hello"
end

не может быть просто переписано в одну строку:

# Это не правильно!
def hello puts "hello" end

Нужно самому имитировать переводы строк:

def hello; puts "hello"; end

Так же можно припомнить, что скобки при вызове функций или объявлении Hash-ей можно опускать. Например, следующие записи эквивалентны:

def f(a); a.inspect; end

f :a => 3, :b => 4, :c => 5
f( :a => 3, :b => 4, :c => 5 )
f( { :a => 3, :b => 4, :c => 5 } )

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

c.field :name => :source_addr_ton,
                :type => "oess_1::uchar_t",
                :bit_mask => 0x1,
                :default => 0

(взято из Re: Использование метаданных в программах на языке C++).
Этот код является описанием поля source_addr_ton с типом oess_1::uchar_t и начальным значением 0, для которого нужно сгенерировать порцию C++ кода. При этом я могу писать значения :name, :type, :bit_mask в произвольном порядке.

while line = gets.chop
    if "quit" == line
        break
    elsif line =~ REQUIRE_REGEX
        exception_guard do
            require REQUIRE_REGEX.match( line )[ 1 ]
        end
    elsif line =~ CALL_METHOD_REGEX
        exception_guard do
            m = t.method( CALL_METHOD_REGEX.match( line )[ 1 ] )
            m.call
        end
    elsif line =~ EVAL_REGEX
        exception_guard do
            eval EVAL_REGEX.match( line )[ 1 ]
        end
    end

    print "=>"
end

(взято из Re[14]: Следующий язык программирования).
Что такое exception_guard? Похоже на специальную синтаксическую конструкцию, вроде try/catch. На самом деле -- это штатный вызов обычной функции:

def exception_guard
    begin
        yield
    rescue StandardError => x
        puts x
    end
end

Более подробно о возможностях Ruby для метапрограммирования и построения DSL см. Re: Следующий язык программирования. В частности меня поразило, как в Ruby on Rails используют метапрограммирование для поддержки ORM:

class Project < ActiveRecord::Base
    belongs_to              :portfolio
    has_one                 :project_manager
    has_many                :milestones
    has_and_belongs_to_many :categories
end

Сомневаюсь, что на Oberon можно достигать подобного уровня абстракции.

AVC>

AVC> * Нет необходимости писать много лишнего кода для многократного
AVC> указания типов

AVC>Здесь, конечно, Оберон "уступает" Смолтоку: он требует указания типа.
AVC>Но посмотрим с другой стороны: (1) указание типа повышает читабельность программы; (2) велика роль опечаток; (3) типы — не хлам, а строительные конструкции.

Здесь так же, имхо, нужно объеденить два пункта.

AVC>

AVC> * Отсутствие статического контроля типов волей-не-волей *вынуждает*
AVC> задумываться о хорошем покрытии тестами. Как показывает практика, такое
AVC> покрытие столь же необходимо и для статических языков вроде Java. Но там
AVC> о нем задумываются позже, потому что создается ложная уверенность, что
AVC> компилятор позволяет избежать большинства ошибок

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

Во-первых, _vovin даже не делал намека на то, что типы -- это хлам. Важность типов в динамических языках ничуть не меньше, чем в статически-типизированных языках. Просто указание типов нужно делать гораздо меньше. Что не может не радовать. Вот есть у меня код на С++:

void f()
{
    std::auto_ptr< Some_Class > my_object( new Some_Class() );
}

или же:

std::auto_ptr< Some_Class >
create_object()
    {
        return std::auto_ptr< Some_Class >( new Some_Implementation_Class() );
    }

Аналогичные конструкции можно привести и в C#, и в Java, и в Oberon (поправь меня, если по поводу Oberon я не прав).
А как бы это выглядело на динамически типизированном языке?

def f
    my_object = Some_Class.new
end

def create_object
    return Some_Implementation_Class.new
end

Поначалу мне так же казалось, что запись на статически типизированном языке понятнее

Теперь я так не думаю.

Но самое удивительное открытие для меня было в том, что хоть переменные могут в динамике менять свой тип (скажем my_object может затем стать и Array, и Hash, и String), но проблем это не вызывает. Потому что, как оказалось, работа с такими "нетипизированными" переменными происходит в локальных контекстах (малых по объему методах), поэтому легко запомнить или увидеть тип каждой из них. А малый объем методов как раз достигается выразительной мощью языка и высоким уровнем абстракции.

Ну а на случаи ошибок действительно есть тесты. Тестов должно быть гораздо больше, чем для программы на статически типизированном языке. Это как раз главная причина, из-за которой я все еще мало программирую на Ruby. Но, если смотреть на это с другой стороны, тестирование не бывает избыточным. Если благодоря динамической типизации мы имеем возможность писать код быстрее, то у нас появляется возможность написать больше тестов. А увеличение количества тестов только увеличивает качество программы. Вот такой парадокс -- в Ruby запуская программу на выполнения я даже не уверен, что в ней нет синтаксических ошибок. Из-за этого я вынужден так гонять ее и в хвост, и в гриву на тестах, что начинаю быть уверенным в ее работоспособности даже больше, чем в случае с C++.

И еще одна штука о тестировании. Я еще не проверял ее на практике, но кажется, что так и есть. В C++ мне часто приходиться отлаживать объекты, которые очень сложно представить отдельно от остальных частей системы. Эти объекты встраиваются в сложный фреймворк, попают в нужное мне состояние по сложной траектории (через некоторую цепочку действий) и затем должна выпасть определенная комбинация условий, чтобы проверить работоспособность объекта. Для чего приходится создавать не менее сложные имитационные стенды. А все из-за того, что объект очень жестко связан со своим окружением. В динамически типизированных языках, где возможно использование Duck Typing, как мне кажется, гораздо легче поместить тестируемый объект в искуственное окружение (sandbox) и в этом окружении дергать его как хочешь.

AVC>

AVC> * Широкии возможности интроспекции/рефлекшна

AVC>Есть в Обероне.

Интересно, а можно пример? Вот в Ruby можно так:

irb(main):014:0> a = {}
=> {}
irb(main):015:0> a.class.name
=> "Hash"
irb(main):016:0> a.instance_variables
=> []
irb(main):017:0> a.class.instance_methods
=> ["reject", "[]=", "send", "object_id", "value?", "size", "singleton_methods", "to_hash", "__send__",
"member?", "equal?", "taint", "find", "frozen?", "instance_variable_get", "each_with_index",
"each_pair", "kind_of?", "delete_if", "merge!", "instance_eval", "require", "to_a", "replace",
"collect", "merge", "all?", "entries", "type", "store", "protected_methods", "extend", "detect", "eql?",
"values", "zip", "instance_variable_set", "hash", "is_a?", "empty?", "default", "map", "to_s", "any?",
"class", "sort", "tainted?", "private_methods", "default=", "default_proc", "key?", "min", "f",
"require_gem_with_options", "untaint", "find_all", "keys", "reject!", "invert", "each", "id",
"has_key?", "inject", "inspect", "delete", "==", "indexes", "===", "sort_by", "clone", "public_methods",
"fetch", "each_value", "max", "values_at", "respond_to?", "display", "index", "select", "freeze",
"shift", "update", "clear", "length", "has_value?", "__id__", "rehash", "partition", "=~", "methods",
"require_gem", "method", "indices", "nil?", "grep", "dup", "each_key", "instance_variables", "include?",
"[]", "instance_of?"]

Затем я могу по имени метода получить объект типа Method и вызвать его (пример показан выше, внутри одного из блоков exception_guard).

Про closures, continuations и green threads ничего не скажу, т.к. сам не владею терминологией Smalltalk-а.

AVC>

AVC> * Хорошие инструменты для работы с кодом, браузеры, интерактивные
AVC> отладчики, возможность писать любой код во время отладки программы,
AVC> запускать отдельные участки кода практически из любого места среды
AVC> * Наличие среды разработки, написанной на самом языке с доступом ко
AVC> всем исходным текстам. Это позволяет на ходу подстраивать среду под себя
AVC> и на ее примере изучать строение серьезных программ.

AVC>Все это есть (и было с самого начала) в Обероне.
AVC>Сохранилось и в Компонентном Паскале.
AVC>При наличии статической типизации.

А вот есть ли в Oberon возможность менять типы прямо по ходу выполнения программы? Посмотри на пример, который я приводил в Re[14]: Следующий язык программирования. Это ведь простейший случай, когда программа модифицируется прямо по ходу работы. Возможно ли такое в Oberon? В C++ точно не возможно.

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

А можно примеры того, что ты считаешь проявлениями динамической типизации в Oberon?

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

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

Disclamer: Алексей, не нужно думать, что я стал адептом динамически типизированных языков. Основную работу я все равно выполняю на C++. Но сейчас мне кажется, что лучше всего сочетать в работе оба подхода. Хотя бы на уровне использования в проекте двух языков. А то и написание основного каркаса на динамически типизированном языке, а наиболее ответственные/ресурсоемкие части -- на компилируемом статически типизированном.

Ну и напоследок анекдот, который, имхо, очень в тему:

Разговаривают католический священник и иудейский раввин.
Священник спрашивает:
-- Вот вам нельзя свинину есть, так неужели вы никогда ее не пробовали?
-- Ну был в молодости такой грех, пробовал. А вот вы давали обед безбрачия, неужели вы никогда не были с женщиной?
-- Ну был в молодости такой грех, пробовал.
-- Так вы мне и скажите, что лучше?

... << RSDN@Home 1.1.4 stable rev. 510>>

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

J>Если хотите, множественное наследование интерфейсов было в винде в COM тыщу лет уж как.

Во-первых далеко не тысячу лет (вспомним сколько лет винде — всего 10). Во-вторых, в COM интерфейсы множественно не наследуются. Один объект может реализовывать много интерфейсов, но каждый из этих интерфейсов может иметь не более одного непосредственного (интерфейсного) предка.

То есть конструкция:

interface A: B, C
{
}

в которой интерфейс A наследуется от интерфейсов B и C в COM недопустима.

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

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

И что? То что у кого-то это потребовало столько времени не значит, что у всех оно будет требовать столько же. Просто не было опыта в реализации этой фичи, да и требует она немного другого подхода к компиляции, нежели тот на который заточены существующие компиляторы C++. Кстати, сами разработчики EDG изменили своё мнение насчет экспорта после того, как он был реализован. А предложение Саттера сделать экспорт deprecated не было поддержано коммитетом.

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

J>>Если хотите, множественное наследование интерфейсов было в винде в COM тыщу лет уж как.

СГ>Во-первых далеко не тысячу лет (вспомним сколько лет винде — всего 10).

Всего 10 -- это если с Win95 считать?
А предыдущие почти 10 лет как же?

... << RSDN@Home 1.1.4 stable rev. 510>>

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

C>Тогда С — это объектно-ориентированый язык. В нем можно организовать
C>полиморфизм с помощью vtable'ов (что и делается в COM, кстати).

Возможность реализовывать один лишь только динамический полиморфизм не достаточно для того чтобы называть язык ОО-языком.

Разница между Си и Обероном с точки зрения ООП состоит в том, что:

1) Наследование: В Си тип struct расширять нельзя, а в Обероне тип RECORD расширять можно.
2) RTTI: Коль скоро в Обероне есть механизм расширения типов, то есть и (эффективный) механизм динамического определения типа

IF obj IS SomType THEN obj(SomType).field := 2.718 END

Еще следует добавить, что Оберон строго типизированный язык. Попытки заведомо не правильного приведения типов пресекаются еще на стадии компиляции. А в языке Си компилятор так сильно за типами не следит.

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

A>И что? То что у кого-то это потребовало столько времени не значит, что у всех оно будет требовать столько же.

Ну да. Остальные вообще решили, что овчинка выделки не стоит

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

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

Евгений,

с интересом читал твой пост.
Конечно, мне нужно его обдумать. Когда человек с большим опытом увлекается какой-то идеей, это "ж-ж-ж" неспроста ((c) Винни-Пух

). Значит, здесь есть что-то действительно ценное.
Все же попытаюсь сразу ответить на некоторые реплики, зная, что мое "раздумье" иногда затягивается на много дней.

AVC>>Мое возражение тебе (возможно, недостаточно хорошо продуманное) состоит в следующем: использование динамической типизации не требует отказа от статической типизации.

E>Чесно говоря, я вообще слабо себе представляю, как динамическая типизация может уживаться со статической. Разве что, как в C++ шаблонах. Но там мы не можем выйти за рамки того, что определили во время компиляции.

ИМХО, если бы динамическая типизация не могла ужиться со статической, то мы не имели бы статически-типизированных ОО-языков.
Собственно, в литературе полно подобных утверждений: "Переменная x имеет статический тип T и динамический тип T1."

ИМХО, главные удобства динамически-типизированных языков основаны не на отказе от статической типизации, а на поддержке run-time system (RTS). Не зря же большинство из них (по крайней мере, в начале своего пути) — интерпретируемые языки.
Интерпретатор и выполняет роль RTS.
Пока статически-типизированные компилируемые языки были "голыми", без run-time поддержки, как Си и Паскаль, динамически-типизированные языки имели огромное преимущество в гибкости.
Но как только статически-типизированные языки стали опираться на помощь продуманной небольшой RTS (как Оберон, например), это преимущество стало значительно меньше, в то время как помощь статической системы типов в профилактике ошибок переоценить трудно.

E>И еще одна штука о тестировании. Я еще не проверял ее на практике, но кажется, что так и есть. В C++ мне часто приходиться отлаживать объекты, которые очень сложно представить отдельно от остальных частей системы. Эти объекты встраиваются в сложный фреймворк, попают в нужное мне состояние по сложной траектории (через некоторую цепочку действий) и затем должна выпасть определенная комбинация условий, чтобы проверить работоспособность объекта. Для чего приходится создавать не менее сложные имитационные стенды. А все из-за того, что объект очень жестко связан со своим окружением. В динамически типизированных языках, где возможно использование Duck Typing, как мне кажется, гораздо легче поместить тестируемый объект в искуственное окружение (sandbox) и в этом окружении дергать его как хочешь.

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

А основана эта фича в основном на динамической загрузке модулей "по запросу". (Но модуль — не тип.)

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

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

Вот этот бы аргумент Павлу Кузнецову!

Он утверждал, что использование обобщенного контейнера без шаблонов обязательно приведет к долгой и мучительной отладке.
А я этого что-то не замечаю...

E>Disclamer: Алексей, не нужно думать, что я стал адептом динамически типизированных языков. Основную работу я все равно выполняю на C++. Но сейчас мне кажется, что лучше всего сочетать в работе оба подхода. Хотя бы на уровне использования в проекте двух языков. А то и написание основного каркаса на динамически типизированном языке, а наиболее ответственные/ресурсоемкие части -- на компилируемом статически типизированном.

Да, иногда использовать два (и более?) языка удобно.
Не всегда это статический и динамический языки.
Вот простой пример: когда пишется компилятор Си, то часто совместно используются Си и yacc (BNF), потому что это удобно.

E>Ну и напоследок анекдот, который, имхо, очень в тему:
E>

E>Разговаривают католический священник и иудейский раввин.
E>Священник спрашивает:
E>-- Вот вам нельзя свинину есть, так неужели вы никогда ее не пробовали?
E>-- Ну был в молодости такой грех, пробовал. А вот вы давали обед безбрачия, неужели вы никогда не были с женщиной?
E>-- Ну был в молодости такой грех, пробовал.
E>-- Так вы мне и скажите, что лучше?

E>)

Я до сих пор вспоминаю анекдот про воробья и орла ("куда мы летим?").

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

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

AVC>Вот этот бы аргумент Павлу Кузнецову!

AVC>Он утверждал, что использование обобщенного контейнера без шаблонов обязательно приведет к долгой и мучительной отладке.
AVC>А я этого что-то не замечаю...

А ты не поделишься ссылкой, где вы это обсуждали?

E>>Disclamer: Алексей, не нужно думать, что я стал адептом динамически типизированных языков. Основную работу я все равно выполняю на C++. Но сейчас мне кажется, что лучше всего сочетать в работе оба подхода. Хотя бы на уровне использования в проекте двух языков. А то и написание основного каркаса на динамически типизированном языке, а наиболее ответственные/ресурсоемкие части -- на компилируемом статически типизированном.

AVC>Да, иногда использовать два (и более?) языка удобно.
AVC>Не всегда это статический и динамический языки.
AVC>Вот простой пример: когда пишется компилятор Си, то часто совместно используются Си и yacc (BNF), потому что это удобно.

Да, но в некоторых языках, т.к. Lisp и Ruby удается делать удобный DSL прямо на этом языке. Вот в чем прелесть-то.

... << RSDN@Home 1.1.4 stable rev. 510>>

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

E>Disclamer: Алексей, не нужно думать, что я стал адептом динамически типизированных языков. Основную работу я все равно выполняю на C++. Но сейчас мне кажется, что лучше всего сочетать в работе оба подхода. Хотя бы на уровне использования в проекте двух языков. А то и написание основного каркаса на динамически типизированном языке, а наиболее ответственные/ресурсоемкие части -- на компилируемом статически типизированном.

Кстати, а на Mathematica кто-нибудь пробовал профессионально программировать? Она ведь включает в себя некий вариант Lisp, некий вариант Си и всё в одной куче. Говорят в Японии уж больно любят на Mathematica программировать, чуть ли не первый язык у них. Просто когда заходит речь о Mathematica обычно вспоминают Maple или Mathlab и говорят, что они лучше чем Mathematica совершенно забывая о том, что Mathematica — это не столько пакет для аналитических вычисления сколько новый язык программирования, в то время как Maple или Mathlab полноценных языков программирования не предоставляют.

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

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

A>>И что? То что у кого-то это потребовало столько времени не значит, что у всех оно будет требовать столько же.

Д>Ну да. Остальные вообще решили, что овчинка выделки не стоит

Остальные просто повелись на пропаганду.

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

Д>>Ну да. Остальные вообще решили, что овчинка выделки не стоит

A>Остальные просто повелись на пропаганду.

какую пропаганду? где ты ее видел?

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

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

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

Д>>>Ну да. Остальные вообще решили, что овчинка выделки не стоит

A>>Остальные просто повелись на пропаганду.

Д>какую пропаганду? где ты ее видел?

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

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

A>Которую некоторые деятели вроде Саттера разводили в своих книжках. А потом оказалось, что аргумент про неколько человеко-лет был основан буквально на разговоре в пивной на багамах между Саттером и Вандевурде.

Насчет пропаганды Саттера вообще в первый раз слышу

Наверно, проивзодители компиляторов тоже на нее купились, или все-таки они сами оценивали трудоемкость?

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

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

AVC>>Вот этот бы аргумент Павлу Кузнецову!

AVC>>Он утверждал, что использование обобщенного контейнера без шаблонов обязательно приведет к долгой и мучительной отладке.
AVC>>А я этого что-то не замечаю...

E>А ты не поделишься ссылкой, где вы это обсуждали?

Давно уже было.

Кажется, это было где-то в инициированной мной ветке:
http://www.rsdn.ru/Forum/Message.aspx?mid=880496&only=1

Указанное утверждение Павла Кузнецова было сделано им здесь:
http://www.rsdn.ru/Forum/Message.aspx?mid=892858&only=1

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

E>> Я думаю, что полную историю этого дела будет знать Зверек Харьковский.

ЗХ>А то как же

ЗХ>

ЗХ>Эпиграф: Гослинг и его команда использовали C++ как руководство — чего нужно избегать.

(Выделение мое: AVC)

<...>

ЗХ>

ЗХ>Для разработчика, язык выглядел совершенно как C++. Но в душе Java взяла очень много от Smalltalk, Lisp и Pascal. Моя заслуга в том, что я смог их совместить. (Джеймс Гослинг)

Очень трогательно и оригинально. Сравним с Виртом:

Просто невозможно поблагодарить всех тех, кто так или иначе подпитывал своими идеями то, что
теперь называется Oberon. Большинство идей пришло от использования и изучения
существующих языков, таких как Modula-2, Ada, Smalltalk и Cedar, которые часто предостерегали
нас от того, как не надо делать.

(Выделение тоже мое.)

Что касется "заслуги" Гослинга в "совмещении языков", то это как решение задачки из школьного задачника.
В конце задачника есть ответ.
Оберон с 1988 года широко доступен: преподается, сразу после завершения работы над Обероном Вирт и Гуткнехт издали книгу о проекте (с объяснением всех решений и даже исходными текстами).
Гослинг не мог об этом не знать.
Тщательное изучение компилятора Оберона в Sun ни для кого не секрет.
И — ни слова!
Зато — "моя заслуга".
Ну-ну.

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

AVC>И почему же, по Вашему, разработчики Явы не ввели это замечательное свойство в свой язык?
AVC>Или они просто неисправимые халтурщики, и решили "сдать" язык с "недоделками". Мол, и так сойдет?

Именно так. Т.е. не халтурщики, а люди, которых сильно напрягли со сроками.
Java появилась на моих глазах и я читал о ней самые что ни на есть первоисточники (т.е. создателей языка).
Так вот то, что они рассказали про историю языка, и тот уровень аргументации, которую они приводили в пользу отсутствия тех или иных фич, которые есть в С++ (про перегрузку операторов там вообще просто песня была), оставила у меня именно такое впечатление: сроки поджимали, выпуск продукта больше задерживать было нельзя.

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

ЗХ>>

ЗХ>>Для разработчика, язык выглядел совершенно как C++. Но в душе Java взяла очень много от Smalltalk, Lisp и Pascal. Моя заслуга в том, что я смог их совместить. (Джеймс Гослинг)

[...]

AVC>Что касется "заслуги" Гослинга в "совмещении языков", то это как решение задачки из школьного задачника.

[...]

AVC>Тщательное изучение компилятора Оберона в Sun ни для кого не секрет.
AVC>И — ни слова!
AVC>Зато — "моя заслуга".
AVC>Ну-ну.

Виноват, это проблема моего перевода на ходу. В оригинале он выражается не так хвастливо: "What I do, was..." — то есть верный перевод — "Все что я сделал — просто объединил эти языки".

Приношу свои извинения.

Но про Оберон они действительно ни слова не говорят (что меня лично удивило, но обратите внимание на мою сноску об "относительной достоверности источников").

ЗЫ: а вообще — я бы не был так категоричен в отыскании корней. Идеи "носятся в воздухе" — обсуждаются, пересказываются, творчески перерабатываются, десятки раз изменяются и т.п. Попытка свести все к "такой-то увидел то-то и упер", как правило, слишком все упрощает.

Характерный пример: классическая версия происхождения GUI первого Мака — "Джобс съездил в Xerox PARC и все у них упер". В действительности (точнее, в том, о чем можно судить по документам), генезис первых гуев был существенно сложнее.

Сергей Губанов wrote:

> J>Если хотите, множественное наследование интерфейсов было в винде в
> COM тыщу лет уж как.
> Во-первых далеко не тысячу лет (вспомним сколько лет винде — всего 10).

Для справки: Windows 1.0 появилась в 84 году. Еще одна справка: COM уже
был в Windows 3.11 в 92 году.

> Во-вторых, в COM интерфейсы множественно не наследуются.

Наследуются, просто наследование виртуальное (для cast'а к предку нужно
использовать QueryInterface).

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

Posted via RSDN NNTP Server 1.9

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

Сергей Губанов wrote:

> C>Тогда С — это объектно-ориентированый язык. В нем можно организовать
> C>полиморфизм с помощью vtable'ов (что и делается в COM, кстати).
> Возможность реализовывать один лишь только динамический полиморфизм не
> достаточно для того чтобы называть язык ОО-языком.
> Разница между Си и Обероном с точки зрения ООП состоит в том, что:
> 1) *Наследование*: В Си тип struct расширять нельзя, а в Обероне тип
> RECORD расширять можно.

Неверно. В C можно расширять тип struct:

struct tagStruct
{
    int a,b;
} Struct;

struct tagStruct2
{
    Struct parent;
    int c,d;
} Struct2;

Теперь делаем так:

Struct2 *ptr=....; //Создаем экземпляр Struct2 каким-то образом
Struct *ptr2=ptr; //И это правильный код!

> 2) *RTTI*: Коль скоро в Обероне есть механизм расширения типов, то
> есть и (эффективный) механизм динамического определения типа
>
>IF obj IS SomType THEN obj(SomType).field := 2.718 END
>
>

int checkInterface(IUnknown *obj, IID ifc)
{
    HRESULT hr;
    IUnknown *res;
    hr=obj->QueryInterface(ifc,&res);
    if (SUCCEEDED(hr))
    {
       res->Release();
       return 1;
    }
    return 0;
}

Теперь:

if (checkInteface(obj,SOME_INTERFACE_ID) {...}

> Еще следует добавить, что Оберон строго типизированный язык. Попытки
> заведомо не правильного приведения типов пресекаются еще на стадии
> компиляции. А в языке Си компилятор так сильно за типами не следит.

И что? На объектную ориентированость это никак не влияет.

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

Posted via RSDN NNTP Server 1.9

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

C>Неверно. В C можно расширять тип struct:

Ну так — грязный хак во всей красе

C>int checkInterface(IUnknown *obj, IID ifc)
C>{
C>    HRESULT hr;
C>    IUnknown *res;
C>    hr=obj->QueryInterface(ifc,&res);
C>    if (SUCCEEDED(hr))
C>    {
       res->>Release();
C>       return 1;
C>    }
C>    return 0;
C>}
C>

А можно Вас попросить, если это Вас не затруднит, показать текст процедуры QueryInterface, а также описание использованных здесь типов?

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

L>>Был такой язык Clipper, мир праху его.

VD>Справидливости ради, в Клипере 5 вроде как ООП ввели полноценно. Но кому он был в это время уже нужен?

Если память мне не изменяет, то в Clipper 5.0 были добавлены несколько объектов: TBrowse и еще два или три. Но ООП там так и не появились.

Сергей Губанов wrote:

> C>Неверно. В C можно расширять тип struct:
> Ну так — грязный хак во всей красе

Это не хак, а фича. Причем явно прописаная в Стандарте на язык С.

> А можно Вас попросить, если это Вас не затруднит, показать текст
> процедуры QueryInterface, а также описание использованных здесь типов?

Лучше всего написано здесь:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncomg/html/msdn_comppr.asp

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

Posted via RSDN NNTP Server 1.9

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

C>Это не хак, а фича. Причем явно прописаная в Стандарте на язык С.

А разве компилятор не может изменить физичекий порядок следования полей в структуре?

... << RSDN@Home 1.1.4 stable rev. 510>>

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

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

C>>Это не хак, а фича. Причем явно прописаная в Стандарте на язык С.

L>А разве компилятор не может изменить физичекий порядок следования полей в структуре?

Нет. Стандарт C99, 6.7.2.1/13

Within a structure object, the non-bit-field members and the units in which bit-fields reside have addresses that increase in the order in which they are declared. A pointer to a structure object, suitably converted, points to its initial member (or if that member is a bit-field, then to the unit in which it resides), and vice versa. There may be unnamed padding within a structure object, but not at its beginning.

... << RSDN@Home 1.1.4 stable rev. 510>>

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

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

Это все же совсем другое.

AVC>Другой, и более близкий, пример — паскалевский P-код. Тот же Гослинг в 1970-е годы занимался именно паскалевским P-кодом.

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

AVC>Оберон первый смог свести "концы с концами", гармонично соединив главные идеи в одно целое.

Расскажи за проблему решил Оберон? Была ли вообще проблема требующая решения? Или все же речь идет о гормонином сочетании фич. Если последнее, то оберон всего лишь один из ряда, и явно не самый удачливый. Если бы Оберон был удачным решением, то Ява просто не появилась бы на свет. В Сане просто напроста взяли бы Оберон.

AVC>Чего, повторяю, до него не было.

Каждый создатель языка считает, что его детище уникально и круче паравоза. И саздаются языки именно потому, что их авторы считают, что имеющиеся языки не гармоничны. Зачем по-твоему Сану и МС было затевать собственные разработки если бы Оберон оказался таким каковым его считает Вирт и вы с Губановым?

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

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

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

Эксперементальные языки бывают разными. Бывают шуточными вроде БрэйнФака. Бывают практичными и сбалансированными вроде Руби. Бывают экзотическими и дерзкими вроде Смолтока. А бывают спартанскими вроде Оберона. На то они и эксперементы, чтобы проверять свои идеи. И вообще, любая классика когда-то была эксперементом. Так что классикой становятся удавшиеся эксперементы. Оберону классикой никогда не стать. Разве что ереходным звеном.

Кстати, вот синтаксис МЛ-я и Питона, как не смешно это звучит начинает по-тихоничку становиться классическим. Все больше и больше новых языков вбирают из них многие конструкции. Все эти def[ine]-ы и безымянные функции явно приживаются и становятся классическими конструкциями. А вот минимализм явно не приживется никогда. Язык должен быть выразительным. Простота же достигается логичностью выразительностью сложных констукций. Например, foreach намного проще воспринимается людьми нежели минималистские for-ы и while-ы. От того они потихоничку прорываются во все языки. Даже в плюсы и те хотя добавить аналог foreach-а.

AVC>Т.е. Си++ — сложнее и запутаннее почти всех других языков? Не спорю.

С++ на самом деле не так уж сложен с точки зрения синтаксиса. Тот же C# в разы его сложнее (особенно 3.0). С++ подводит другое. Многие его конструкции запутаны в следствии неоднозначностей и не понятности на интуитивном уровне. К тому же дает о себе знать наследие С.

Мне вот другое интересно. Старонники Оберона стремясь доказать его приемущества все время пытаются сравнивать Оберон с С++. Причем делают это только там где С++ действительно слабее. Но ведь есть языки и помимо С++, да и в С++ есть вещи вроде обобщенного программирования и метапрограммироания. Почему бы не сравнить Оберон с ними? Или не хочется обращать внимание нанедостатки?

AVC>Вирт стремился не к минимализму в синтаксисе как таковому, а к максимальной простоте и ясности в программировании.

Отнюдь. Вот создатели C#, Руби и VB действительно каждый по-своему к этому стремились. Причем они понимали, что минимализм и простота использования разные вещи. Для того чтобы язык был проще в него наоборот ввели "лишние" конструкции вроде foreach. Такие конструкции позволяют выражать мысли значительно проще. При этом код не тольк проще писать. Что намного важнее его проще воспринимать.

AVC>Минимализм в синтаксисе служит именно этим целям, будучи весьма удобным и практичным.

Это очень большое заблуждение. Иначе самым простым языком был бы имено БрэйнФак. В нем же всего 4 (или сколько там) конструкции!

AVC>Утверждаю это на основании сравнения своего собственного опыта на Си++ и Обероне.

А ты срани свой любимый Оберон не с корявым С++, а с C# 2.0 или с Руби. Причем не просто полистав документацию, а попрограммировав на этих языках.

AVC>>>По-моему, я ясно назвал Смоллток антипримером.

VD>>Где? И почему? Как раз все перечисленное в нем уже было.

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

AVC>Сопоставь два своих утверждения: о динамической типизации в Смолтоке (определеннее: статической типизации нет вообще) и о том, что в нем нет проблем с безопасностью типов.

Уууу... И ты с такими дырами в базовых знаниях берешся за сравнение языков и определение первенства среди них?

Нда, беда (с).

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

Ясно. Тогда разговор нужно прекратить за полным невладением материалом собеседника.
Дла продолжения разговора тебе прийдется изучить вот это:
http://en.wikipedia.org/wiki/Datatype
http://en.wikipedia.org/wiki/Type_safe
http://en.wikipedia.org/wiki/Programming_language

После детального изучения этих сатей ты поймшь, что динамическая типизация и ее отсуствие это не одно и тоже. И что плохая статическая типизация (напримем в С, особенно в раннем), намного хуже хорошей динамической (например в Смолтоке). А так же возможно поймешь, что динамическая типизация имеет как плюсы, так и минусы. Главный плюс динамической типизации — это очень гибкий полиморфизм. В статически типизированных языках полиморфизм далек от гибкости, так что его развивают разыми средствами. Самое эффекнивное из которых добавление статического полиморфизма. Например, в С++ с этой целью добавили макросы. А в C# и Яву джереники. Самым мощным наверное является подход МЛ-я и его клонов. Там полимпофизм очень похож на полиморфизм динамически типизировнных языков, но при том он все же статический. Оберон же в этом отношении сильно обделен. В нем нет статического полиморфизма, да и динамический то как бы придела к языку сбоку.

AVC>>>Конкретнее, пожалуйста. В чем совпали мысли авторов Явы, Дельфи, Шарпа, Ди?

VD>>Автоматическое управление памятью, безопастность типов (Ди тут чуть в стороне, но все же).

AVC>Какие прозорливцы создатели этих языков! Куда до них Вирту!

Ты хотя бы понял, что я перечислил те идеи которые совпали с теми что Вирт удосужился включить в Оберон?

А идеи эти придуманы задолго до появления всех этих языков. Они были уже Лиспе и Смолтоке. Так что вирт эти идеи позаимствовал. Вот в Паскале он идею безопастности типов использвал одним из первых. Хотя опять же в Лиспе она уде была, а он лет эдак на 15 по страше.

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

Может быдушь слидить за дискуссией? Напомню. Я сказал следующую фразу:

А то что некоторые их мысли совпали говорит о том, что у них у всех были правильные мысли.

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

AVC>Во-первых, Оберон — не примитивный, а очень выразительный язык.

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

AVC>Синтаксический минимализм здесь очень важен: каждая конструкция несет свою уникальную синтаксическую нагрузку, намерения программиста сразу понятны (при чтении программы).

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

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

AVC>Что касается ":=", то признай, что ты не смог подобрать примера опечатки с ":=". Я все прощу!

Понимашь ли, чтобы понять другого человека нужно:
1. Хотеть его понять.
2. Обладать набором базовых знаний в обсуждаемом вопросе.

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

Если ты уже прочел приведенные ссылки на вики, то я еще раз попытаюсь объяснить обсурдность борьбы за ":=".

Итак, для человека соврешенно все равно каким знаком обозначается некоторое дейсвтие. Чем более привчен знак тем лучше, так как адаптация будет легче. Знак "=" неплохо отражает суть операции и привычен так как именно его все использвали в школе.

Так вот, исходя из этой предпосылки получается что единственная проблема оператора "=" в С/С++ = это то, что есть другой оператор содержащий тот же символ, но использующийся по другому. Собственно проблема в том, что человек может опечататься и не заметить этого. Понятно, что можно опечататься как при наборе "==", так и при наборе ":=". Если человек опечатается в месте где синтаксис языка не допускает использования "=", то проблем не возникнет, так как компилятор/интерпретатор обнаружит несоотвествие и сообщит об ошибке. Если же в контексте допустимы оба ператора (например, "=" и "==" или "=" и ":="), то появляется поле для "граблей". Ошибка может быть попросу не замечина и приводить не сообщению о ней, а к невреному поведению программы (несоотвествию ожиданиям).

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

Первый путь — это запретить присваения внутри выражений. Ведь проблема проявляется только в этом случае. Таким путем пошли Руби и многие другие языки.
Второй путь — повысить строгость типизации, а конкретно — запретить автоматическое приведение чего бы то нибыло к булевому типу. Это привдет к тому, что незамеченными останутся только опечатки в выражениях с булевыми типами, но сравнение булевых типов — это мякго говоря идеотизм, так как предикаты уже придекаты и формировать из них новые путем сравнения смысла нет. В остальных же случаях тип получаемый в результате присвоения значения не будет булевы и если программистп опытается использовать его в булевом выражении (напрмер в if-е, компилятор выдаст сообщение об ошибке). Таким путем пошел C#.

Оберон же пошел перым путем попросту запретив присваения в выражениях.

Что касается оператора ":=", то Вирту просто хочется видить привчный именно ему оператор, и так как никаких разумных обоснований этому капризу нет, то начинает откровенную демагогию про "не естественность" использования "=" в присвоениях.

Понятнее я уже не могу объяснить. Если и это не понятно, то лучше не развивать этот спор, так как это уже совершенно бесцельное занятие.

AVC>Где??!

Ну, например, в МЛ есть и ЖЦ, и сильная статическая типизация. Что там у Вирта еще уникального было?

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

AVC>Да, логика непобедимая.

Потому что верная.

AVC>Оберон (1988) ничем не отличается от C# (2000?) с точки зрения новизны.

Ага. Все идеи, ну, кроме того что "в такой" комбинации они есть только в этих языках, ни в Обероне, ни в C# нет.

AVC>А может, все-таки, наоборот?

Можно и наоборот. Ни в C#, ни в Обероне нет ни одной придуманной для этго языка идеи. Они воплощают давно известные мысли других людей соеденяя их в уникальную комбинацию.

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

Кстати, чем дальще мем меньше вероятноать появления новых идей. Уж слишком много их уже придумано. Однако комбинаций их может быть неисчислимое множество. Это как с нотами. Всего семь нот, но люди вот вже тысячи лет не могут исчерпать запас их возможных комбинаций приводящих к тому что мы называем музыкой.

... << RSDN@Home 1.2.0 alpha rev. 618>>

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

AVC>>И почему же, по Вашему, разработчики Явы не ввели это замечательное свойство в свой язык?
AVC>>Или они просто неисправимые халтурщики, и решили "сдать" язык с "недоделками". Мол, и так сойдет?

J>Именно так. Т.е. не халтурщики, а люди, которых сильно напрягли со сроками.

Я пока скромно замечу, что Ваш аргумент совершенно несовместим с аргументом Евгения (eao197), о том, что Java была готова уже давно и использовалась в проекте Star7.
Вот история, пересказанная Евгением:
http://www.rsdn.ru/Forum/Message.aspx?mid=1406278&only=1
Даже фигурируют спецификации... 1994 года. (Мол язык был, да вот только спецификации куда-то затерялись.

)
Все эти истории от "создателей Явы" странные и сами по себе, но главное — противоречат одна другой.

J>Java появилась на моих глазах и я читал о ней самые что ни на есть первоисточники (т.е. создателей языка).
J>Так вот то, что они рассказали про историю языка, и тот уровень аргументации, которую они приводили в пользу отсутствия тех или иных фич, которые есть в С++ (про перегрузку операторов там вообще просто песня была), оставила у меня именно такое впечатление: сроки поджимали, выпуск продукта больше задерживать было нельзя.

Интересно, а почему так торопились разработчики Явы?
С кем они гнались наперегонки?
Знаете ли Вы какие-нибудь разработки, конкурировавшие тогда с Явой в области ее применения?
Ведь очень интересная картина: люди отчаянно спешат, портят из-за этого язык (который должен стать их "брэндом"!). Неужели без причины?

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

AVC>>Тщательное изучение компилятора Оберона в Sun ни для кого не секрет.
AVC>>И — ни слова!
AVC>>Зато — "моя заслуга".
AVC>>Ну-ну.

ЗХ>Виноват, это проблема моего перевода на ходу. В оригинале он выражается не так хвастливо: "What I do, was..." — то есть верный перевод — "Все что я сделал — просто объединил эти языки".

Как было сказано в каком-то фильме — "та же фигня".

Смысл этих выражений один и тот же.
Просто не Гослинг это сделал. А в каких выражениях он об этом говорит (а говорит он частенько в выражениях хвастливых и рекламных) — дело второе.

ЗХ>Но про Оберон они действительно ни слова не говорят (что меня лично удивило, но обратите внимание на мою сноску об "относительной достоверности источников").

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

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

ЗХ>ЗЫ: а вообще — я бы не был так категоричен в отыскании корней. Идеи "носятся в воздухе" — обсуждаются, пересказываются, творчески перерабатываются, десятки раз изменяются и т.п. Попытка свести все к "такой-то увидел то-то и упер", как правило, слишком все упрощает.

Доказательство теоремы Ферма "носилось в воздухе" больше трехсот лет.
Но доказал ее конкретный человек.
Потратив на это 25 лет.
Пойдемте и скажем ему, что это (потраченная жизнь) не важно. Ведь идеи "носились в воздухе"!

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

AVC>>Другой, и более близкий, пример — паскалевский P-код. Тот же Гослинг в 1970-е годы занимался именно паскалевским P-кодом.

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

Правда? Совершенно другое? Ну ни капельки не похоже, да?

А как же знаменитое

Write once, run everywhere

?

AVC>>Оберон первый смог свести "концы с концами", гармонично соединив главные идеи в одно целое.

VD>Расскажи за проблему решил Оберон? Была ли вообще проблема требующая решения? Или все же речь идет о гормонином сочетании фич. Если последнее, то оберон всего лишь один из ряда, и явно не самый удачливый. Если бы Оберон был удачным решением, то Ява просто не появилась бы на свет. В Сане просто напроста взяли бы Оберон.

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

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

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

AVC>>>И почему же, по Вашему, разработчики Явы не ввели это замечательное свойство в свой язык?
AVC>>>Или они просто неисправимые халтурщики, и решили "сдать" язык с "недоделками". Мол, и так сойдет?

J>>Именно так. Т.е. не халтурщики, а люди, которых сильно напрягли со сроками.

AVC>Я пока скромно замечу, что Ваш аргумент совершенно несовместим с аргументом Евгения (eao197), о том, что Java была готова уже давно и использовалась в проекте Star7.
AVC>Вот история, пересказанная Евгением:
AVC>http://www.rsdn.ru/Forum/Message.aspx?mid=1406278&only=1
AVC>Даже фигурируют спецификации... 1994 года. (Мол язык был, да вот только спецификации куда-то затерялись.

)
AVC>Все эти истории от "создателей Явы" странные и сами по себе, но главное — противоречат одна другой.

Я пока скромно замечу (

), что не противоречит. У меня у самого от Java такое же впечатление, как у Jazzer-а.
Имхо, Грослинг и компания просто не смогли сделать в Java то хорошее, что было в C++. Та же перегрузка операторов, шаблоны или полноценная поддержка множественного наследования. За это я Java и не люблю. И пользоваться мне Java поэтому не удобно.

Я как-то делал в своей СУБД поддержку множественного наследования (с виртуальным множественным) -- это сложно и трудоемко. А ведь для языка программирования это всего лишь один фрагментик.

А мой аргумент относился именно к лекции Франца. Именно тогда, когда Франц ее читал, вносить изменения в Java было уже поздно. Что и подтвердил Зверек: Re[9]: Мои впечатления о лекции Н. Вирта в ННГУ 26.09.2005. А вот если бы Франц прочел эту лекцию года на три раньше...

J>>Java появилась на моих глазах и я читал о ней самые что ни на есть первоисточники (т.е. создателей языка).
J>>Так вот то, что они рассказали про историю языка, и тот уровень аргументации, которую они приводили в пользу отсутствия тех или иных фич, которые есть в С++ (про перегрузку операторов там вообще просто песня была), оставила у меня именно такое впечатление: сроки поджимали, выпуск продукта больше задерживать было нельзя.

AVC>Интересно, а почему так торопились разработчики Явы?
AVC>С кем они гнались наперегонки?

Думаю, сами с собой. В исследовательских проектах (каким был Green Project) самое главное -- суметь отказаться от грандиозных всеобъемлющих планов и уложиться в сроки и бюджеты хотя бы с чем-нибудь работающим.

AVC>Знаете ли Вы какие-нибудь разработки, конкурировавшие тогда с Явой в области ее применения?

А какая у Java тогда планировалась область применения? Сомневаюсь, что в 92-м году идеи j2ee уже витали в воздухе.

AVC>Ведь очень интересная картина: люди отчаянно спешат, портят из-за этого язык (который должен стать их "брэндом"!). Неужели без причины?

К сожалению, так очень часто бывает. Я вот у себя в ObjESSty дальше 2-й беты двинутся не могу -- нет физических возможностей. Хотя задумок было ой как много. Se la vi.

... << RSDN@Home 1.1.4 stable rev. 510>>

P>Если память мне не изменяет, то в Clipper 5.0 были добавлены несколько объектов: TBrowse и еще два или три. Но ООП там так и не появились.

В 5.2 был недокументированный и достаточно убогий способ создавать свои обьекты — но я не видел чтобы им кто-то реально пользовался. Помнится, реализовывал полиморфизм через массивы (структуры Clipper не поддерживал) и "блоки кода" (как своеобразные указатели на функции). В целом это работало, но назвать после этого Clipper обьектно-ориентированным языком — увольте...

... << RSDN@Home 1.1.4 stable rev. 510>>

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

AVC>>Все эти истории от "создателей Явы" странные и сами по себе, но главное — противоречат одна другой.

E>Я пока скромно замечу (

), что не противоречит. У меня у самого от Java такое же впечатление, как у Jazzer-а.

Евгений, ну как же не противоречат?!
То утверждается, что на этом языке уже был завершен проект в 1992 году (а спецификации — корова съела), то говорится, что язык и к осени 1995 года сделать не успели. Ограничились, мол, каким-то "обрубком".

E>Имхо, Грослинг и компания просто не смогли сделать в Java то хорошее, что было в C++. Та же перегрузка операторов, шаблоны или полноценная поддержка множественного наследования. За это я Java и не люблю. И пользоваться мне Java поэтому не удобно.

За это ты бы, наверное, и Оберон не любил (если бы писал на нем).

Но ведь эти свойства не случайны, а закономерны.
Шаблоны, например, трудно (если возможно) запихнуть в компонентное программирование.
Перегрузка операторов — вредна (ИМХО). В Оберон (за исключением "подлого изменника" Oberon X

) она не включена принципиально.
Множественное наследование, ИМХО, плохо совмещается с точной сборкой мусора и эффективным динамическим определением типа. (К тому же, в модульных языках в нем вообще нет потребности.)

E>А мой аргумент относился именно к лекции Франца. Именно тогда, когда Франц ее читал, вносить изменения в Java было уже поздно. Что и подтвердил Зверек: Re[9]: Мои впечатления о лекции Н. Вирта в ННГУ 26.09.2005. А вот если бы Франц прочел эту лекцию года на три раньше...

14 месяцев — огромный срок!
Весь Оберон (язык, компилятор, ОС, редактор, др., книга) был сделан за 2,5 года двумя людьми в размеренном темпе, причем у них были и другие обязанности (все-таки Вирт тогда еще и профессором ETH был).
А здесь такая корпорация, да еще не на пустом месте! Да еще в таком угаре (судя по утверждениям jazzer).

В начале 1994 года Франц читает лекцию, после этого принимается решение о переориентации Java на Интернет, а потом наблюдается уже упомянутая спешка.

J>>>Java появилась на моих глазах и я читал о ней самые что ни на есть первоисточники (т.е. создателей языка).
J>>>Так вот то, что они рассказали про историю языка, и тот уровень аргументации, которую они приводили в пользу отсутствия тех или иных фич, которые есть в С++ (про перегрузку операторов там вообще просто песня была), оставила у меня именно такое впечатление: сроки поджимали, выпуск продукта больше задерживать было нельзя.

AVC>>Интересно, а почему так торопились разработчики Явы?
AVC>>С кем они гнались наперегонки?

E>Думаю, сами с собой. В исследовательских проектах (каким был Green Project) самое главное -- суметь отказаться от грандиозных всеобъемлющих планов и уложиться в сроки и бюджеты хотя бы с чем-нибудь работающим.

Определенно, Java не была исследовательским проектом, в отличие от Оберона.
Это именно "рыночный" проект.

AVC>>Знаете ли Вы какие-нибудь разработки, конкурировавшие тогда с Явой в области ее применения?

E>А какая у Java тогда планировалась область применения? Сомневаюсь, что в 92-м году идеи j2ee уже витали в воздухе.

Могу сказать, что почти сразу после Java стал доступным Juice, сделанный всего одним человеком (Францем).
Так что причины спешить все-таки были.

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

E>>Я пока скромно замечу (

), что не противоречит. У меня у самого от Java такое же впечатление, как у Jazzer-а.

AVC>Евгений, ну как же не противоречат?!
AVC>То утверждается, что на этом языке уже был завершен проект в 1992 году (а спецификации — корова съела), то говорится, что язык и к осени 1995 года сделать не успели. Ограничились, мол, каким-то "обрубком".

Ну так и есть. Делали Oak. Чтобы Green Project не стал долгостроем выбросили из него все, что было хорошего в C++. Затем осознали, что получилось. Решили продвигать в массы. Может быть, что-то подправили в языке, хотя особенно уже и времени не было. Потому что нужно было JDK клепать. И какие-то приложения вокруг Java (ведь тогда, как мне помнится, откуда-то какие-то JavaOS расплодились). Ну некогда, имхо, им было Oak до "ума" доводить. Так же, как и прогрессивную идею Франца внедрять. Потому, что релиз на носу был. Да и возможно, переносился не один раз.

А то, что обрубком, так первая Java такой и была. Те же самые generic-и, которые на тот момен уже были в C++ в виде шаблонов, появились только спустя лет семь после первой Java.

E>>Имхо, Грослинг и компания просто не смогли сделать в Java то хорошее, что было в C++. Та же перегрузка операторов, шаблоны или полноценная поддержка множественного наследования. За это я Java и не люблю. И пользоваться мне Java поэтому не удобно.

AVC>За это ты бы, наверное, и Оберон не любил (если бы писал на нем).

Вряд ли. Мне Паскаль нравился. Правда Object Pascal уже нет.

AVC>Но ведь эти свойства не случайны, а закономерны.
AVC>Шаблоны, например, трудно (если возможно) запихнуть в компонентное программирование.

Да мне тут VladD2 уже про это разсказал.

AVC>Перегрузка операторов — вредна (ИМХО). В Оберон (за исключением "подлого изменника" Oberon X

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

Плохо, это значит "сложно"? Или принципиально невозможно?

E>>А мой аргумент относился именно к лекции Франца. Именно тогда, когда Франц ее читал, вносить изменения в Java было уже поздно. Что и подтвердил Зверек: Re[9]: Мои впечатления о лекции Н. Вирта в ННГУ 26.09.2005. А вот если бы Франц прочел эту лекцию года на три раньше...

AVC>14 месяцев — огромный срок!
AVC>Весь Оберон (язык, компилятор, ОС, редактор, др., книга) был сделан за 2,5 года двумя людьми в размеренном темпе, причем у них были и другие обязанности (все-таки Вирт тогда еще и профессором ETH был).

Ну чего тут скажешь? Если судить по результатам, то мы сейчас выясняем, не взял ли суперпопулярный язык Java чего-нить тайком у малоизвестного Oberon-а? Может время разработки здесь по другому стоит оценивать?

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

Может в Sun была другая ситуация. Может там потратили 90% времени на создание языка, который будет понятен и удобен 80% разработчиков?

AVC>А здесь такая корпорация, да еще не на пустом месте! Да еще в таком угаре (судя по утверждениям jazzer).

AVC>В начале 1994 года Франц читает лекцию, после этого принимается решение о переориентации Java на Интернет, а потом наблюдается уже упомянутая спешка.

Возможно, спешка была и до 1994 года. Либо после завершения Green Project до исторического решения Джоя на переориентацию Java вообще был полный застой и Java не развивалась вовсе. А когда Джой сказал, что Java в интернете быть, то и работа закипела.

E>>Думаю, сами с собой. В исследовательских проектах (каким был Green Project) самое главное -- суметь отказаться от грандиозных всеобъемлющих планов и уложиться в сроки и бюджеты хотя бы с чем-нибудь работающим.

AVC>Определенно, Java не была исследовательским проектом, в отличие от Оберона.
AVC>Это именно "рыночный" проект.

Java -- нет, а вот Oak, в котором ядро Java сформировалось -- был.

... << RSDN@Home 1.1.4 stable rev. 510>>

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

VD> В Сане просто напроста взяли бы Оберон.

Блин, так они же его и взяли! Только выбросили value-типы и осквернили Си-образным синтаксисом.

VD> На то что в других языках достаточно пары слов в Обероне нужно наваять кучу кода.

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

VD>Так вот, дело в том, что Вирт как неразумное дитя тычит пальцем во второе "равно" и громко, так, заявляет, что это нелогично... (далее масса эпитетов), в общем дело мол в нелогичном использовании "=". Между тем дело не в этом. Дело именно в допустимости похожей конструкции. И проблему эту можно решить двумя путями...

1) Описать эту проблему в стандарте. (Си-онисты)
2) Признаться и исправить допущенную ошибку. (Вирт)

Сергей Губанов wrote:

> VD> На то что в других языках достаточно пары слов в Обероне нужно
> наваять кучу кода.
> Вообще-то, Обероны еще славятся тем, исходный код операционных систем
> написанных на них имеет очень мало строчек кода по сравнению с
> операционными системами написанными на Си/Си++.

И соответственно меньше функций.

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

Агащаз. Покажите операционку, которая сравнится с Линуксом по фичам. А
мы сравним исходники.

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

Posted via RSDN NNTP Server 1.9

Здравствуйте, Cyberax, Вы писали:
C>Только вот программа на ассемблере не будет выполняться на другой
C>архитектуре. А вот программа на С — будет.
Гм. А не на Альфе ли мы гоняли стандартный solitair.exe в режиме эмуляции x86?

... << RSDN@Home 1.1.4 stable rev. 510>>

Sinclair wrote:

> C>Только вот программа на ассемблере не будет выполняться на другой
> C>архитектуре. А вот программа на С — будет.
> Гм. А не на Альфе ли мы гоняли стандартный solitair.exe в режиме
> эмуляции x86?

А на NT для PPC (в просторечии — "пипец") не получилось бы

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

Posted via RSDN NNTP Server 1.9

Здравствуйте, Cyberax, Вы писали:
C>А на NT для PPC (в просторечии — "пипец") не получилось бы

но ведь мы же не говорили "на любой другой архитектуре"

... << RSDN@Home 1.1.4 stable rev. 510>>

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

СГ>Вообще-то, Обероны еще славятся тем, исходный код операционных систем написанных на них имеет очень мало строчек кода по сравнению с операционными системами написанными на Си/Си++.

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

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

Конечно отличаются! Из них выкинуто все лишнее.

Ну там, к примеру, поддержка квот ресурсов. Зачем она нужна?

... << RSDN@Home 1.1.4 stable rev. 510>>

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

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

Да, отличаются: не требуют столько ресурсов.

AVC wrote:

> В>Еще на заре спора о "синтаксическом оверхеде" я просил привести код
> на Обероне для решения какой-то реальной задачи. Чтобы оценить
> реальный выигрыш. Так и не дождался. Вот и сейчас у меня есть
> подозрение, что ОС, написанные на Обероне, сильно отличаются от
> "реальных" линуксов и виндовсов (которые на "миллионы строк").
> Да, отличаются: не требуют столько ресурсов.

микроЛинукс, например, работает на ооооочень слабых машинах.

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

Posted via RSDN NNTP Server 1.9

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

C>Агащаз. Покажите операционку, которая сравнится с Линуксом по фичам. А
C>мы сравним исходники.

А вот и ягодки: Линукс настолько "потяжелел", что больше не устанавливается на машины, на которые раньше вставал без проблем.
Ядро раздутое.
ИМХО, разные "фичи" не должны навязываться, а предоставляться как дополнительные возможности.

AVC wrote:

> C>Агащаз. Покажите операционку, которая сравнится с Линуксом по фичам. А
> C>мы сравним исходники.
> А вот и ягодки: Линукс настолько "потяжелел", что больше не
> устанавливается на машины, на которые раньше вставал без проблем.
> Ядро раздутое.

Ничуть. Я лично конфигурировал компилировал ядро 2.6.12 для старого
Cyrix'а (уровня 486 компьютера) — все вполне нормально работает. Хотя
действительно пришлось отключить много опций, включеных по умолчанию

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

Posted via RSDN NNTP Server 1.9

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

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

Зайду с другой стороны.
Конечно, вполне справедливо можно говорить о "множественном наследовании"

Java (в смысле — от многих языков).
Например, у Паскаля заимствована идея P-кода (с теми же однобайтовыми инструкциями и размещением операндов в стеке).
Почему я думаю, что байт-код взят именно из Паскаля? Да посмотрите на биографию Гослинга. В 1975 году он занимается Паскалем для Multics (как я понял, взяв сначала за основу компилятор ETH Pascal). В 1979 году он пишет PERQ: транслятор с паскалевского P-кода в машкод DEC VAX.
Раздельная компиляция была уже в Модула-2.
Вероятно, справедливо было бы говорить и о заимствованиях из Смолтока, и из Лиспа.
Почему же я "упираю" на Оберон?
(Не считая многих косвенных свидетельств, вроде изучения в Sun исходных текстов компилятора ETH Oberon, покупки в Sun лицензии на него, переориентации Java на Интернет именно после лекции Франца о динамической кодогенерации и постоянных консультаций Sun с ETH в 1994-1995 годах, т.е. в самое горячее время. Главное же косвенное свидетельство — полное замалчивание этого в Sun.)
Давайте рассмотрим немного подробнее, что представлял из себя Оберон на начало 1990-х годов.
1) Сочетание статической типизации, динамических типов и сборки мусора, с гарантией полной проверки типов (type safety).
2) Раздельная компиляция с межмодульным контролем соответствия типов.
3) Динамическая загрузка модулей "по требованию".
4) Возможности метапрограммирования (в т.ч. рефлексия).
5) Гипертекстовый интерфейс (например, команда вызывалась щечком мышки по текстовой паре модуль.процедура).
6) Внедряемые в текстовые документы объекты, обладающие собственным поведением, — апплеты. (Они назывались по разному, но уже Франц называл их именно апплетами.)
7) Уникальная в то время переносимость. Разные Оберон-системы имели единый API и единый машинно-независимый формат данных.
8) Наконец, машинно-независимый мобильный код. Например, к 1994 году практически для всех модулей (кроме компилятора и самого нижнего уровня) в Обероне для Макинтоша при загрузке использовалась JIT-компиляция, причем временные потери на нее составляли всего 10-20% (Вирт всегда считал скорость компиляции важной, а скорость самокомпиляции — одним из важнейших критериев качества компилятора). Эту технологию, разработанную Францем, еще называли "slim binaries".

И что, перечисленного недостаточно?

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

AVC>Как было сказано в каком-то фильме — "та же фигня".

AVC>Смысл этих выражений один и тот же.
AVC>Просто не Гослинг это сделал. А в каких выражениях он об этом говорит (а говорит он частенько в выражениях хвастливых и рекламных) — дело второе.

Вот в том то и суть — Вирт так же заимствовал чужие идеи

Как и Гослинг. Так что справедливости ради стоит помнить и об этом тоже. И саморекламой он занимается так же. Просто он выпендривается перед другой аудиторией — студентами и профессурой, а не перед бизнесменами и журналистами (как Гослинг).

ЗХ>>Но про Оберон они действительно ни слова не говорят (что меня лично удивило, но обратите внимание на мою сноску об "относительной достоверности источников").

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

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

А сам Вирт много упоминает о языках или людях — чьи идеи он черпал?

Или его рекламная компания Oberon'ов чем то уступает рекламе Java (кроме вложеных денег)?

ЗХ>>ЗЫ: а вообще — я бы не был так категоричен в отыскании корней. Идеи "носятся в воздухе" — обсуждаются, пересказываются, творчески перерабатываются, десятки раз изменяются и т.п. Попытка свести все к "такой-то увидел то-то и упер", как правило, слишком все упрощает.

AVC>Доказательство теоремы Ферма "носилось в воздухе" больше трехсот лет.
AVC>Но доказал ее конкретный человек.
AVC>Потратив на это 25 лет.

Сравнили же Вы, Алексей, самолёт с велосипедом.

И в Обероне, и в Java и в C++ — каждая идея заимствована, всё что отличает эти языки — это уникальная комбинация уже имевшихся идей, которая, к тому же, во всех случаях имеет как множество интересных достоинств, так и множество недостатков.

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

И то, что одни ремесленники проектируют здания по Фен-Шуй и изображают из себя больших учёных, а другие — честно сознаются в своём занятии — сути дела не меняет.

AVC>Пойдемте и скажем ему, что это (потраченная жизнь) не важно. Ведь идеи "носились в воздухе"!

Лучше бы потратил на вино и девушек

Патетика тут ни к чему. Тем более, что ситуация совсем иная

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

AVC>Например, у Паскаля заимствована идея P-кода (с теми же однобайтовыми инструкциями и размещением операндов в стеке).
AVC>Почему я думаю, что байт-код взят именно из Паскаля? Да посмотрите на биографию Гослинга. В 1975 году он занимается Паскалем для Multics (как я понял, взяв сначала за основу компилятор ETH Pascal). В 1979 году он пишет PERQ: транслятор с паскалевского P-кода в машкод DEC VAX.

"После этого — значит, вследствие этого"
Одно из классических построений ложной логики

AVC>(Не считая многих косвенных свидетельств, вроде изучения в Sun исходных текстов компилятора ETH Oberon, покупки в Sun лицензии на него,

Да, изучали. Ну и что? Другие языки они тоже изучали.

AVC>переориентации Java на Интернет именно после лекции Франца о динамической кодогенерации

И снова. "После этого — значит, вследствие этого"
Что касается самой идеи динамической кодогенерации, то у нее вооот такая бородища. При чем тут вообще Оберон?

AVC>и постоянных консультаций Sun с ETH в 1994-1995 годах, т.е. в самое горячее время. Главное же косвенное свидетельство — полное замалчивание этого в Sun.)

Какие именно консультации и на какую тему? Подробнее, плиз

AVC>2) Раздельная компиляция с межмодульным контролем соответствия типов.

это еще в C++ было, пусть и кривовато

AVC>3) Динамическая загрузка модулей "по требованию".

а когда появились DLL и их аналоги?

AVC>4) Возможности метапрограммирования (в т.ч. рефлексия).

Правда? Как интересно. В стандартной реализации? И в каком году?

AVC>5) Гипертекстовый интерфейс (например, команда вызывалась щечком мышки по текстовой паре модуль.процедура).

Только не говори, что это Вирт первый изобрел

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

а как же POSIX?

AVC>8) Наконец, машинно-независимый мобильный код. Например, к 1994 году практически для всех модулей (кроме компилятора и самого нижнего уровня) в Обероне для Макинтоша при загрузке использовалась JIT-компиляция, причем временные потери на нее составляли всего 10-20% (Вирт всегда считал скорость компиляции важной, а скорость самокомпиляции — одним из важнейших критериев качества компилятора). Эту технологию, разработанную Францем, еще называли "slim binaries".

Согласно Вики, проект по разработке Явы начался в 1990 году. Первые части проекта демонстрировались в 1992. Java 1.0a в 1994 году уже была готова. И снова — при чем тут вообще Оберон?!

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

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

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

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

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

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

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

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

1.1.4 stable rev. 510

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

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

AVC>>Например, у Паскаля заимствована идея P-кода (с теми же однобайтовыми инструкциями и размещением операндов в стеке).
AVC>>Почему я думаю, что байт-код взят именно из Паскаля? Да посмотрите на биографию Гослинга. В 1975 году он занимается Паскалем для Multics (как я понял, взяв сначала за основу компилятор ETH Pascal). В 1979 году он пишет PERQ: транслятор с паскалевского P-кода в машкод DEC VAX.

Д>"После этого — значит, вследствие этого"
Д>Одно из классических построений ложной логики

1) Гослинг много занимался паскалевским P-кодом.
2) Байт код Java по смыслу есть паскалевский P-код.

В данном случае "после" именно и значит "вследствие".

Д>Что касается самой идеи динамической кодогенерации, то у нее вооот такая бородища. При чем тут вообще Оберон?

Какая такая бородища??? Древовидное компактное представление программ допускающее кодогенерацию "на лету" открыл Михаэль Франц и защитил по этому поводу диссертацию в ETH в 1994 году. Он реализовал ее для Оберон-систем. Кстати, научными руководителями Франца были Вирт и Гуткнехт. Теперь понятно при чем тут Оберон?

AVC>>2) Раздельная компиляция с межмодульным контролем соответствия типов.

Д>это еще в C++ было, пусть и кривовато

Раздельной компиляции в С++ никогда не было, нет сейчас, и никогда не будет. В С++ есть независимая компиляция. Разницу между раздельной и независимой компиляцией можете узнать в диссертации
R. Crelier. Separate Compilation and Module Extension (ETH 1994) http://www.oberon2005.ru/paper/eth10650.pdf

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

S>а) в двух словах пояснить, почему именно 16384? (Ну типа там — threadId 14разрядный)
S>б) дать ссылку на то, где это написано?
S>А то у меня появляется чувство, что я не знаю чего-то фундаментального.

Тоже мне — фундаментальное. Не фундаментальное это! Это — только лишь подробности реализации.

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

Д>>Что касается самой идеи динамической кодогенерации, то у нее вооот такая бородища. При чем тут вообще Оберон?
СГ>Какая такая бородища??? Древовидное компактное представление программ допускающее кодогенерацию "на лету" открыл Михаэль Франц

Прошу прощения за буквоедство, но "древовидное компактное представление программ допускающее кодогенерацию на лету" и "динамическая кодогенерация" — не эквивалентные понятия. Это я к тому, что непонятно, что именно открыл Франц — "кодогенерацию на лету", "древовидное представление" или новым было вообще их сочетание.

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

А для неграмотных вкратце здесь можно рассказать?

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

СГ>Тоже мне — фундаментальное. Не фундаментальное это! Это — только лишь подробности реализации.
Бывают такие подробности реализации, не знать которые — стыдно. Ну, как например, разрядность IP адреса, или количество доступных портов в архитектуре PC, или то, что в современных процессорах — риск-ядро, или то, что современному компилятору наплевать на порядок записи коммутативных операций в исходнике и т.д.

1.1.4 stable rev. 510

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

СГ>1) Гослинг много занимался паскалевским P-кодом.
СГ>2) Байт код Java по смыслу есть паскалевский P-код.

"по смыслу" — это как?

СГ>Какая такая бородища??? Древовидное компактное представление программ допускающее кодогенерацию "на лету" открыл Михаэль Франц и защитил по этому поводу диссертацию в ETH в 1994 году. Он реализовал ее для Оберон-систем. Кстати, научными руководителями Франца были Вирт и Гуткнехт. Теперь понятно при чем тут Оберон?

динамическую кодогенерацию еще в машинных кодах писали — такая вот бородища

согласно википедии, в том самом 1994 году уже была выпущена некая версия Явы 1.0а (вероятно, это обозначает альфа-версию)
далее — не ты ли говорил, что это самое "Древовидное компактное представление программ" НЕ используется в Яве?
так что при чем тут оберон, мне таки не понятно

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

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

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

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

П> Это я к тому, что непонятно, что именно открыл Франц

Code Generation On the Fly: A Key to Portable Software
presented by
Michael Steffen Oliver Franz
Dipl. Informatik Ing. ETH
born 1st May 1964
citizen of Germany
accepted on the recommendation of
Prof. Dr. N. Wirth, examiner
Prof. Dr. J. Gutknecht, co examiner

http://www.oberon2005.ru/paper/eth10497.pdf

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

П>А для неграмотных вкратце здесь можно рассказать?

Если вкратце, то вот:

В языках с независимой компиляцией можно писать так:

extern int f(int x);

int g(int x)
{
  return f(x) + 1;
}

а потом скомпилировать это дело, например, в lib-файл.

В языках с раздельной компиляцией так писать нельзя. Надо писать так:

MODULE B;

  IMPORT A;

  PROCEDURE g(x: INTEGER): INTEGER;
  BEGIN
    RETURN A.f(x) + 1
  END g;

END B.

Разница в том, что при независимой компиляции не может быть произведено проверки целостности системы (это просто не предусмотрено). В данном случае не известно что еще за функция f() такая. При раздельной компиляции целостность системы гарантируется. В данном случае точно известно, что f() — это функция экспортируется модулем A, и компилятор проверяет так ли это на самом деле. Но здесь я привел очень простой пример. Теперь представьте себе, что функция f() имеет дело с каким-нибудь сложным типом данных (указательным). При раздельной компиляции компилятор проверит правильность типов, а при независимой — у компилятора такой возможности просто нет.

Теперь другой вопрос — исполнение программы.

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

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

Преимущества раздельной компиляции перед независимой:
1) Проверка целостности системы (межмодульная проверка типов) непосредственно на стадии компиляции, которая в принципе невозможна при независимой компиляции.
2) Нет необходимости в дополнительной стадии изготовления исполнимого модуля из нескольких obj и lib-файлов, поскольку исполнимый модуль получается сразу в результате компиляции.

Раздельная компиляция используется для построения модульных расширяемых систем. Использовать для этих целей независимую компиляцию уж очень не удобно.

В указанной в предыдущем сообщении диссертации
R. Crelier. Separate Compilation and Module Extension (ETH 1994) http://www.oberon2005.ru/paper/eth10650.pdf
много чего интересного написано по этой теме.

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

AVC>Просто не Гослинг это сделал. А в каких выражениях он об этом говорит (а говорит он частенько в выражениях хвастливых и рекламных) — дело второе.

не ты ли говорил, что "главное достоинство Оберона — не новаторство его отдельных фич, а их уникальная комбинация"?
Получается, что когда Вирт комбинирует позаимствованные идеи, то честь ему и хвала? А когда Гослинг комбинирует (частично из тех же источников, частично из других) — то он нагло все украл?

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

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

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

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

AF> А сам Вирт много упоминает о языках или людях — чьи идеи он черпал?

Или его рекламная компания Oberon'ов чем то уступает рекламе Java (кроме вложеных денег)?

Отвечу именно на этот вопрос. Тогда, надеюсь, станет моя позиция станет яснее.
Когда тема заимствований из Оберона в Java всплыла впервые (где-то уже с год назад) я написал, что дело не в том, что в Java заимствованы идеи из Оберона ("заимствование означает уважение"), а в том, как это было сделано: без упоминания главного источника. ИМХО, это уже не заимствование, а воровство.
В отличие от Гослинга, Вирт всегда прямо называл источники своих идей.
Важнейшим "источником вдохновения" для Вирта (как и для Дейкстры, и т.д.) стал Алгол-60. Первый популярный результат: Паскаль.
С тех пор он все время совершенствовал "алгольное" семейство языков.
Огромное влияние оказали два визита в Xerox PARC.
В 70-е годы там на Вирта произвел большое впечатление модульный язык Mesa. Результат: язык Модула-2.
В 80-е — объектно-ориентированный язык (и так же — ОС с развитым графическим интерфейсом) Cedar. Результат: язык (и ОС) Оберон.
Конечно, через паскалеподобный Cedar Вирту приходилось считаться с его идейными предшественниками: Smalltalk и Simula-67.
Вместе с тем, то, как именно Вирт соединил эти идеи, имеет огромное значение. Я не представляю, кто бы еще мог решить эту задачу так просто (и, ИМХО, очень красиво).

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

Д>не ты ли говорил, что "главное достоинство Оберона — не новаторство его отдельных фич, а их уникальная комбинация"?
Д>Получается, что когда Вирт комбинирует позаимствованные идеи, то честь ему и хвала? А когда Гослинг комбинирует (частично из тех же источников, частично из других) — то он нагло все украл?

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

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

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

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

Это не буквоедство, а две "большие разницы".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ну а по другим пунктам что скажешь? Давай ка сделаем сводную таблицу совпадений и различий?

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

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

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

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

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

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

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

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

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

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

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

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

Д>Ну а по другим пунктам что скажешь? Давай ка сделаем сводную таблицу совпадений и различий?

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

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

AVC wrote:

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

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

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

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

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

Posted via RSDN NNTP Server 1.9

AVC wrote:

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

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

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

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

Posted via RSDN NNTP Server 1.9

Здравствуйте, 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>недоумение, что упоминания об Обероне он не нашел.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

СГ>Продуктом независимой компиляции являются 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-код — голимо процедурен.

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

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

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

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

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

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

AVC>Об этом пишет, например, Франц в старой статье "Java: критическая оценка".

AVC>

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

AVC>• Переносимость Java ...
AVC>• Не нова также идея строгой типизации с поддержкой динамических типов и системы "сборки
AVC>мусора", ...
AVC>• Мысль о том, что язык со строгой типизацией делает возможным построение программ,
AVC>переносимых с одной архитектуры на другую, ...
AVC>• Программы на Java могут состоять из нескольких независимо компилируемых единиц,
AVC>которые "динамически" собираются воедино только в момент загрузки ...
AVC>• Даже преподносимая сейчас в качестве главной инновации Java идея не зависящих от
AVC>платформы мобильных программ в сочетании с генерацией кода в процессе выполнения...

Ну что тут можно сказать? Вирт в Oberon допустил всего одну фатальную ошибку: придал Oberon-у паскалевский синтаксис.

А теперь не может простить Грослингу, что тот эту ошибку "тайком" исправил

А вообще, я присоединяюсь к Re[22]: В догонку

... << RSDN@Home 1.1.4 stable rev. 510>>

Можно подумать что AVC первый или единственный публично утверждает о том что Sun не имела права замалчивать об оберонах. Как минимум, я слышал или читал ранее про аналогичную мысль утверждаемую публично следующими людьми: Никлаус Вирт (слышал лично во время его турне), Михаэль Франц, Сергей Свердлов, Руслан Богатырёв (статьи доступны на сайте http://www.oberon2005.ru/). Плюс я сам эту мысль публично утверждаю. Уверен, что есть еще масса людей тоже готовых утверждать это публично. Не считаю разумным замалчивать данный факт воровства. Не разумным я считаю лишь спорить об этом до посинения в форумах.

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

СГ>Не считаю разумным замалчивать данный факт воровства. Не разумным я считаю лишь спорить об этом до посинения в форумах.

Это не факт, это всего лишь натянутое предположение. И от того, что ты десять раз скажешь "факт", быть предположением оно не перестанет.
Так что не надо начинать всё по новой.

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

Сергей,

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

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

Для меня тема Ява-Оберон возникла случайно.
Когда-то (давно уже) я предложил на одном из форумов рассмотреть язык Оберон в качестве языка для обучения студентов.
Потом меня стали за это критиковать (иногда, ИМХО, чрезмерно сурово

), в том числе и сторонники Java и C#.
Я тогда удивился и спросил, почему такая жестокая критика, ведь эти языки (хотя бы частично) обязаны своим происхождением Оберону.
Тут-то я и узнал, что не все думают так же, и что Sun ни слова не сказала о связи между Явой и Обероном.
Моя эмоциональная реакция Вам понятна.

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

) аргументы, но нельзя заставить других оценивать их также.
Как утверждалось в одной старой поговорке, "можно привести лошадь к водопою, но нельзя заставить ее пить".

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

AVC>Когда-то (давно уже) я предложил на одном из форумов рассмотреть язык Оберон в качестве языка для обучения студентов.

еще один изувер

за что вы так бедных студентов не любите?

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

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

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

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

СГ>Можно подумать что AVC первый или единственный публично утверждает о том что Sun не имела права замалчивать об оберонах. Как минимум, я слышал или читал ранее про аналогичную мысль утверждаемую публично следующими людьми: Никлаус Вирт (слышал лично во время его турне), Михаэль Франц, Сергей Свердлов, Руслан Богатырёв (статьи доступны на сайте http://www.oberon2005.ru/). Плюс я сам эту мысль публично утверждаю. Уверен, что есть еще масса людей тоже готовых утверждать это публично. Не считаю разумным замалчивать данный факт воровства. Не разумным я считаю лишь спорить об этом до посинения в форумах.

Сергей! Вы выставляете себя в смешном свете. Никаких фактов ни вы ни другие сторонники Оберона так и не сумели привести. Голословных утверждений и домыслов — предостаточно. Фактов — ни одного. Только факты не имеющие прямого отношения к сути дела, из которых и делались все умозаключения. Ни на один из банальных вопросов ответа вы так и не дали. Вместо этого вы сослались на то, что мол Алексей не один, кто повторял легенду о краже оберона (вероятно принадлежащую Вирту). Есть такая поговорка: "Сколько не кричи халва — во рту слаще не станет". Надеюсь вы понимаете, что если кричать толпой, халва так же не появится.

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

Потому предлагаю тему закрыть, по крайней мере до появления новых и прямых фактов.

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

AVC>>Когда-то (давно уже) я предложил на одном из форумов рассмотреть язык Оберон в качестве языка для обучения студентов.

Д>еще один изувер

Д>за что вы так бедных студентов не любите?

Зря ты так. Паскаль в качестве первого языка при программировании очень хорош. Почему бы его место сейчас не отдать Oberon-у. Язык, как мне представляется, простой, лаконичный, модульный, надежный. Для первого года обучения, имхо, то, что нужно. А затем уже можно на C++/Java/C# переходить.

... << RSDN@Home 1.1.4 stable rev. 510>>

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

Д>>еще один изувер

Д>>за что вы так бедных студентов не любите?

слишком неправильная идея положена в его основу (это я про примитивизацию конструкций языка)

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

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

Д>>за что вы так бедных студентов не любите?

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

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

Владик wrote:

> Д>>за что вы так бедных студентов не любите?
> E>Зря ты так. Паскаль в качестве первого языка при программировании
> очень хорош. Почему бы его место сейчас не отдать Oberon-у.
> Нынче модно ООП. Ни классический паскаль, ни Оберон для демонстрации
> ОО-подхода не подходят. Если начинать с процедурного программирования,
> то, возможно, Оберон весьма достойная замена паскалю.

Угу, а потом студенты пишут программы с кучей глобальных переменных и
непонятных функций. Знаем, проходили.

Надо учиться с функциональных языков — хорошо мозги прочищает.

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

Posted via RSDN NNTP Server 2.0 beta

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

C>Надо учиться с функциональных языков — хорошо мозги прочищает.

Вот в этом не уверен. Все-таки человеку свойственна итерация

А для последующего прочищения мозгов — да, самое то

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

>> Д>>за что вы так бедных студентов не любите?
>> E>Зря ты так. Паскаль в качестве первого языка при программировании
>> очень хорош. Почему бы его место сейчас не отдать Oberon-у.
>> Нынче модно ООП. Ни классический паскаль, ни Оберон для демонстрации
>> ОО-подхода не подходят. Если начинать с процедурного программирования,
>> то, возможно, Оберон весьма достойная замена паскалю.

C>Угу, а потом студенты пишут программы с кучей глобальных переменных и
C>непонятных функций. Знаем, проходили.

По-твоему, Паскаль способствует написанию неструктурированных программ с большим количеством глобальных переменных?

C>Надо учиться с функциональных языков — хорошо мозги прочищает.

Да уж

. А ты, оказывается, экстремал. Или экстремист. Не знаю, что в данном случае более подходит.

... << RSDN@Home 1.1.4 stable rev. 510>>

eao197 wrote:

> C>Угу, а потом студенты пишут программы с кучей глобальных переменных и
> C>непонятных функций. Знаем, проходили.
> По-твоему, Паскаль способствует написанию неструктурированных программ
> с большим количеством глобальных переменных?

ДА!

Сколько раз уже видел такой код:

program blah;
var
    d  : Integer;
    m,n : array [1..4][1..4] of real;

procedure PoschitatDeterminant;
begin
{Тут считают детерминант матрицы m}
end;

procedure UmnozhitMatricy;
begin
{Тут умножают матрицу m на n}
end;

begin
{что-то еще}
end.

И это встречается у 99% студентов.

Паскаль не стимулирует писать в хорошем стиле — поставил глобальную
переменную и оно работает.

А вот в функциональных языках такое не получится — там переменные менять
нельзя

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

В УдГУ на мат. факе в прошлом году первым языком изучали Рефал. Ничего,
живут люди.

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

Posted via RSDN NNTP Server 2.0 beta

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

СГ>. Как минимум, я слышал или читал ранее про аналогичную мысль утверждаемую публично следующими людьми: [...]Михаэль Франц

Насколько мне известно, Франц никогда не говорил о заимствованиях в языке. Он говорил о другом:

For example, Adl-Tabatabai et al. [ACL98] describe a compilation strategy for Java that they might
just as well have copied from one of Wirth’s books [WG92, Wir96], but they present it as a new
invention and give it the new name “lazy code selection”. Wirth has been teaching the identical
method at least since the mid-1980’s, calling it “delayed code emission”.

Кстати, разработчики Java HotSpot таки ссылались на Вирта.

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

C>Сколько раз уже видел такой код:
C>

C>program blah;
C>var
C>    d  : Integer;
C>    m,n : array [1..4][1..4] of real;

C>procedure PoschitatDeterminant;
C>begin
C>{Тут считают детерминант матрицы m}
C>end;

C>procedure UmnozhitMatricy;
C>begin
C>{Тут умножают матрицу m на n}
C>end;

C>begin
C>{что-то еще}
C>end.
C>

Да, гораздо лучше так

class blah 
{   int d;
    double[][] m,n;
   public void SozdatMatricy;
     { m = new double[4][4];
       n = new double[4][4];}

   public void PoschitatDeterminant;
   {Тут считают детерминант матрицы m}

   public void  UmnozhitMatricy;
   {Тут умножают матрицу m на n}

   {что-то еще}
}

Трурль wrote:

> Да, гораздо лучше так
>
>class blah
>{ int d;
> double[][] m,n;
> public void SozdatMatricy;
> { m = new double[4][4];
> n = new double[4][4];}
>
> public void PoschitatDeterminant;
> {Тут считают детерминант матрицы m}
>
> public void UmnozhitMatricy;
> {Тут умножают матрицу m на n}
>
> {что-то еще}
>}
>
Вы читаете что я пишу хоть, где вы увидели предложение сразу учить ООП
на С++? Надо сначала учить функциональные языки, чтобы было понятие
контекста вычислений и сторонних эффектов.

Чтобы писать потом код хотя бы примерно так:

program blah;

type
    Matrix4 = array[1..4][1..4] of real;

function Determinant4(m : Matrix4) : real ;
begin
    {Считаем детерминант}
end;

function Multiplicate4(m1,m2 : Matrix4) : Matrix4;
begin
    {Тут умножают матрицу m1 на m2}
end;

var
    m,n : Matrix4;
begin
{что-то еще}
end.

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

Posted via RSDN NNTP Server 2.0 beta

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

C>Чтобы писать потом код хотя бы примерно так:
C>

C>program blah;

C>type
C>    Matrix4 = array[1..4][1..4] of real;

C>function Determinant4(m : Matrix4) : real ;
C>begin
C>    {Считаем детерминант}
C>end;

C>function Multiplicate4(m1,m2 : Matrix4) : Matrix4;
C>begin
C>    {Тут умножают матрицу m1 на m2}
C>end;

C>var
C>    m,n : Matrix4;
C>begin
C>{что-то еще}
C>end.
C>

Меня на паскале именно так и учили писать. И били по рукам за глобальные переменные, рассказывая, почему это плохо.

... << RSDN@Home 1.1.4 stable rev. 510>>

eao197 wrote:

> Меня на паскале именно так и учили писать. И били по рукам за
> глобальные переменные, рассказывая, почему это плохо.

Меня так еще на QuickBasic'е учили писать

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

Поэтому проще всего взять язык где "неправильно" просто нельзя писать

Кстати, так и делают в MITе — там используют Scheme.

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

Posted via RSDN NNTP Server 2.0 beta

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

>> Меня на паскале именно так и учили писать. И били по рукам за
>> глобальные переменные, рассказывая, почему это плохо.

C>Меня так еще на QuickBasic'е учили писать

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

C>Поэтому проще всего взять язык где "неправильно" просто нельзя писать

C>Кстати, так и делают в MITе — там используют Scheme.

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

А то до сих пор вижу динозавров, которые утверждают, что мол алгоритм сортировки — это "суть программирования", а объекты — ерунда (и в общем с определённой точки зрения правы — но не для тех детей, кого они этому учат) а потом бедолаги обнаруживают, что вокруг них одна "едунда", а "суть программирования" используется лишь в готовом виде (а за попытки писать свои сортировки Тим лиды лупят по рукам)

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

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

Насчет классического Паскаля Вы, несомненно, правы. Для демонстрации ООП он не годится.
Но за что "досталось" бедному Оберону?

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

) в рациональности такого шага — язык для него новый.
Говорю ему через несколько дней: таких-то вот компонентов у тебя, вероятно, нет; можешь приспособить мои, написанные на Си. А он отвечает: да я их уже на Компонентном Паскале реализовал — все работает.
Это я к тому, что простота имеет все же значение.

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

AVC>Насчет классического Паскаля Вы, несомненно, правы. Для демонстрации ООП он не годится.
AVC>Но за что "досталось" бедному Оберону?

Попробуй нарисовать простейшую иерархию классов и пример их взаимодействия на Обероне и сравни с той же джавой (которая типа копия). Посчитаем синтаксический оверхед

Насчет компонентного паскаля не знаю, может там все лучше.

P.S. Понятно, что писать в ОО-стиле можно и на С (без плюсов) и на асме. Все упирается в "шашечки", которых Вирт лишил свой язык сознательно.

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

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

AVC>>>Когда-то (давно уже) я предложил на одном из форумов рассмотреть язык Оберон в качестве языка для обучения студентов.

Д>>еще один изувер

Д>>за что вы так бедных студентов не любите?

E>Зря ты так. Паскаль в качестве первого языка при программировании очень хорош. Почему бы его место сейчас не отдать Oberon-у. Язык, как мне представляется, простой, лаконичный, модульный, надежный. Для первого года обучения, имхо, то, что нужно. А затем уже можно на C++/Java/C# переходить.

Оберон и другие языки из семейства паскалеподобных по моему мнению очень мешают пониманию некоторых концепций программирования. За тот год который я провёл программируя на паскале я так и не смог понять, что такое указатель. Только поймите меня правильно. Использовать указатели в паскале я умел, но мне почему-то всегда нужно было обращаться к справочнику. Абстракция указателя, его синтаксис, а так же управление памятью в паскале и в ему подобных языках совсем неинтуитивны. Я помню, как только я перешёл на С, все проблемы с пониманием ушли сами собой. Тут я мог себе чётко представить память как последовательность ячеек, а указатель как адрес в памяти. Malloc был гораздо естественнее паскалевского new(p); сразу понятно откуда берётся память. Да и преобразования массивов к указателям немало этому процессу понимания способствовали. Причём типы указателей в С совершенно этому не препятствуют. Тогда как в паскале они заставляют видеть указатели разных типов по разному. Я помню, как месяца через три, после того, как я перешёл с паскаля на С, я попробовал написать какую-то несложную программу на паскале и больше часа потратил на то, чтобы преобразовать какие-то одни простые типы к другим. Это определило моё отношение к паскалеподобным языкам. С тех пор за более чем 10 лет я не написал на них вообще ничего.

Вот так. Не стоит учить Оберону. Мне подобный язык не пригодился. Да и у 95% остальных, я думаю, был сходный опыт.

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

E>>Паскаль в качестве первого языка при программировании очень хорош. Почему бы его место сейчас не отдать Oberon-у. Язык, как мне представляется, простой, лаконичный, модульный, надежный. Для первого года обучения, имхо, то, что нужно. А затем уже можно на C++/Java/C# переходить.

A>Оберон и другие языки из семейства паскалеподобных по моему мнению очень мешают пониманию некоторых концепций программирования. За тот год который я провёл программируя на паскале я так и не смог понять, что такое указатель.

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

... << RSDN@Home 1.1.4 stable rev. 510>>

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

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

) в рациональности такого шага — язык для него новый.
AVC>Говорю ему через несколько дней: таких-то вот компонентов у тебя, вероятно, нет; можешь приспособить мои, написанные на Си. А он отвечает: да я их уже на Компонентном Паскале реализовал — все работает.
AVC>Это я к тому, что простота имеет все же значение.

интересно, это только мне ТВ-рекламу напомнило? Типа, купите наш журнал и ваши волосы станут мягкими и шелковистыми

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

AVC wrote:

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

Эээээ? Поддержка динамических типов и сборки мусора появилась ТОЧНО не в
ETH.

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

Posted via RSDN NNTP Server 2.0 beta

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

C>Поэтому проще всего взять язык где "неправильно" просто нельзя писать

C>Кстати, так и делают в MITе — там используют Scheme.

Нельзя писать, говорите? А я все-таки попробую

(define  d 0) 
(define  m (make-matrix 4 4)) 
(define  n (make-matrix 4 4)) 

(define (PoschitatDeterminant )
  ;Тут считают детерминант матрицы m
  ...
  (set! d (+ d ...))
  ...)

(define  (UmnozhitMatricy)
  ;Тут умножают матрицу m на n
  ...
    (matrix-set! m i j (* ...)
  ...)

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

AF>Полностью согласен! Особенно изуитски это выглядит у Вирта. Он единственный кто регулярно заявляет о том, что мол его языки позволяют писать только в правильном стиле.

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

AF> А то до сих пор вижу динозавров, которые утверждают, что мол алгоритм сортировки — это "суть программирования", а объекты — ерунда (и в общем с определённой точки зрения правы — но не для тех детей, кого они этому учат) а потом бедолаги обнаруживают, что вокруг них одна "едунда", а "суть программирования" используется лишь в готовом виде (а за попытки писать свои сортировки Тим лиды лупят по рукам)

Имхо, большинство преподавателей убеждены, что суть программирования — выбрать готовое решение и правильно подставить параметры.
А объекты и в самом деле ерунда. Это вам и Пол Грем подтвердит.

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

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

интересно, зачем он тогда вообще затевал всю эту идею с примитивизацией синтаксиса?

Т>А объекты и в самом деле ерунда. Это вам и Пол Грем подтвердит.

Объекты — ерунда. А вот архитектура — нет. Но как раз этому не учат

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

Трурль wrote:

> C>Поэтому проще всего взять язык где "неправильно" просто нельзя писать
> C>Кстати, так и делают в MITе — там используют Scheme.
> Нельзя писать, говорите? А я все-таки попробую

Забыл сказать, set запрещают использовать.

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

Posted via RSDN NNTP Server 2.0 beta

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

C>Чтобы писать потом код хотя бы примерно так:
C>

program blah;

type
    Matrix4 = array[1..4][1..4] of real;

function Multiplicate4(m1,m2 : Matrix4) : Matrix4;

Функция возвращающая матрицу? Ну-ну, флаг Вам в руки. sizeof(Matrix4) = 4*4*sizeof(real) = 96 // точно не помню, вроде в Турбо Паскале real 6 байтов было.

А вот как надо правильно писать:

  TYPE
    Matrix = ARRAY OF ARRAY OF REAL;

  PROCEDURE Mul (IN a, b: Matrix; OUT c: Matrix);

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

В>Попробуй нарисовать простейшую иерархию классов

А что Вы имеете в виду под "простейшей иерархией классов" и под "попробуй нарисовать" в особенности? Если не секрет.

Сергей Губанов wrote:

> Функция возвращающая матрицу? Ну-ну, флаг Вам в руки. sizeof(Matrix4)
> = 4*4*sizeof(real) = 96 // точно не помню, вроде в Турбо Паскале real
> 6 байтов было.

Нормальные компиляторы делают return value optimization для таких
случаев (то есть неявно переписывают функция в виде c out-параметром).

Невозможность создания удобных типов с эстафетным владением — это вообще
минус Оберона.

> А вот как надо правильно писать:
>
> TYPE
> Matrix = ARRAY OF ARRAY OF REAL;
>
> PROCEDURE Mul (IN a, b: Matrix; OUT c: Matrix);
>
Нет, так как не понятно, что c — это возвращаемый результат из просмотра
исходников вызывающего кода.

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

Posted via RSDN NNTP Server 2.0 beta

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

C>Забыл сказать, set запрещают использовать.

Настоящему индусу завсегда везде ништяк.

(define  m ...)
(define  n ...)

(define (PoschitatDeterminant)  
   ;детерминант матрицы m

(define  (UmnozhitMatricy)  
  ;произведеие матриц m и n
...
(define  d (PoschitatDeterminant)) 
...
(define  m (UmnozhitMatricy))

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

ПК>Объем спецификации C# 2 не меньше, чем объем спецификации C++ даже,

+1

ПК> особенно при учете того, что спецификация C++ заметно подробнее.

-1

... << RSDN@Home 1.2.0 alpha rev. 618>>

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

AVC>1) Сочетание статической типизации, динамических типов и сборки мусора, с гарантией полной проверки типов (type safety).

Была в VB.

AVC>2) Раздельная компиляция с межмодульным контролем соответствия типов.

Была в VB.

AVC>3) Динамическая загрузка модулей "по требованию".

Была в VB.

AVC>4) Возможности метапрограммирования (в т.ч. рефлексия).

Была в VB (COM).

AVC>5) Гипертекстовый интерфейс (например, команда вызывалась щечком мышки по текстовой паре модуль.процедура).

Небыло в Ява.

AVC>6) Внедряемые в текстовые документы объекты, обладающие собственным поведением, — апплеты. (Они назывались по разному, но уже Франц называл их именно апплетами.)

Небыло в Ява.

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

Небыло в VB.

AVC>8) Наконец, машинно-независимый мобильный код.

Был в VB.

AVC>И что, перечисленного недостаточно?

Все достаточно. Вывовд однозначный Ява — клон VB.

Твоя аргументация — это PPC (как тут сказали, в простонародии пипец).

... << RSDN@Home 1.2.0 alpha rev. 618>>

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

СГ>А что Вы имеете в виду под "простейшей иерархией классов" и под "попробуй нарисовать" в особенности? Если не секрет.

Что-нибудь классическое, на чем учат ООП. Иерархия геометрических фигур и т.п. "Нарисовать" — привести код декларации, имплементации и использования.

Здравствуйте, Владик, Вы писали:
В>Нынче модно ООП. Ни классический паскаль, ни Оберон для демонстрации ОО-подхода не подходят.
Вообще-то даже Турбо Паскаль 6.0 — вполне неплохой язык для преподавания. Он не настолько сложен, как С++, почти не содержит магически работающих конструкций за сценой (типа того же сборщика мусора), и вообще довольно-таки прост.
На практике — проблема в преподавателях. Девочка, которая преподавала информатику у нас в школе, никак не могла заучить разницу между 255 и 275 (для длины строки), и единственное, что знала — что "GOTO — это плохо".
Ее никак не напрягали декларации типов навроде

TPersonList = array[1..5] of record Name, LastName:string end;

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

1.1.4 stable rev. 510

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

СГ>>А что Вы имеете в виду под "простейшей иерархией классов" и под "попробуй нарисовать" в особенности? Если не секрет.

В>Что-нибудь классическое, на чем учат ООП. Иерархия геометрических фигур и т.п. "Нарисовать" — привести код декларации, имплементации и использования.

Спасибо за ответ, теперь буду знать.

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

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

AF>>Полностью согласен! Особенно изуитски это выглядит у Вирта. Он единственный кто регулярно заявляет о том, что мол его языки позволяют писать только в правильном стиле.

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

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

AF>> А то до сих пор вижу динозавров, которые утверждают, что мол алгоритм сортировки — это "суть программирования", а объекты — ерунда (и в общем с определённой точки зрения правы — но не для тех детей, кого они этому учат) а потом бедолаги обнаруживают, что вокруг них одна "едунда", а "суть программирования" используется лишь в готовом виде (а за попытки писать свои сортировки Тим лиды лупят по рукам)

Т>Имхо, большинство преподавателей убеждены, что суть программирования — выбрать готовое решение и правильно подставить параметры.

Видимо мы видели разных преподавателей

Т>А объекты и в самом деле ерунда. Это вам и Пол Грем подтвердит.

Объекты сами по себе — да. А вот умение понять что нужно сделать, построить правильно архитектуру и спроектировать систему с помощью объектов — вот это и есть суть программирования. И ей, увы, не учат

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

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

Я считаю, что наличие GC — только плюс для обучения. Не надо вводить понятия времени жизни объекта и объяснять все связанные с этим грабли прочию "магию".

Владик wrote:

> В>>Нынче модно ООП. Ни классический паскаль, ни Оберон для
> демонстрации ОО-подхода не подходят.
> S>Вообще-то даже Турбо Паскаль 6.0 — вполне неплохой язык для
> преподавания. Он не настолько сложен, как С++, почти не содержит
> магически работающих конструкций за сценой (типа того же сборщика мусора),
> Я считаю, что наличие GC — только плюс для обучения. Не надо вводить
> понятия времени жизни объекта и объяснять все связанные с этим грабли
> прочию "магию".

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

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

Posted via RSDN NNTP Server 2.0 beta

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

СГ>Спасибо за ответ, теперь буду знать.

Я правильно понял, что до "дела" (примера обероновского кода, на котором можно (якобы наглядно) изучать принципы ООП) так и не дойдет?

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

C>Ага, а после этого нормальным программистам приходится отлаживать
C>приложения, где запросто сохраняются ссылки на мегабайтные документы в
C>какой-нибудь большой карте объектов — а потом забывают удалять их оттуда.

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

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

C>>Ага, а после этого нормальным программистам приходится отлаживать
C>>приложения, где запросто сохраняются ссылки на мегабайтные документы в
C>>какой-нибудь большой карте объектов — а потом забывают удалять их оттуда.

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

Ну уж нет. Лучше дать людям во время учебы набить шишек с ручным управлением памятью. Пока они реальных проектов не завалили. Зато потом они будут ценить GC и языки с GC. А заодно не будут забывать ненужные ссылки занулять, чтобы memory leak-ов не было. Ведь они будут знать, что это такое.

... << RSDN@Home 1.1.4 stable rev. 510>>

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

E>Ну уж нет. Лучше дать людям во время учебы набить шишек с ручным управлением памятью. Пока они реальных проектов не завалили. Зато потом они будут ценить GC и языки с GC. А заодно не будут забывать ненужные ссылки занулять, чтобы memory leak-ов не было. Ведь они будут знать, что это такое.

Так и вижу: научная работа "О благотворном влиянии сообщения 'core dumped' на мОзги начинающих программистов"

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

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

C>>> Надо сначала учить функциональные языки, чтобы было понятие
контекста вычислений и сторонних эффектов.

Владик> Я считаю, что наличие GC — только плюс для обучения. Не надо вводить
Владик> понятия времени жизни объекта и объяснять все связанные с этим грабли
Владик> прочию "магию".

C>Ага, а после этого нормальным программистам приходится отлаживать
C>приложения, где запросто сохраняются ссылки на мегабайтные документы в
C>какой-нибудь большой карте объектов — а потом забывают удалять их оттуда.

Так, все-таки. Сначала надо учить функциональные языки или управление памятью?

Здравствуйте, Andrei N.Sobchuck, Вы писали:

E>>Ну уж нет. Лучше дать людям во время учебы набить шишек с ручным управлением памятью. Пока они реальных проектов не завалили. Зато потом они будут ценить GC и языки с GC. А заодно не будут забывать ненужные ссылки занулять, чтобы memory leak-ов не было. Ведь они будут знать, что это такое.

ANS>Так и вижу: научная работа "О благотворном влиянии сообщения 'core dumped' на мОзги начинающих программистов"

А следом, еще более серьезную: "О благотворном влиянии сообщения 'core dumped' на мОзги опытных программистов". Сомневаешься в ее актуальности? Ну посмотри, как VladD2 управляемый C# нравится.

... << RSDN@Home 1.1.4 stable rev. 510>>

Трурль wrote:

> C>Ага, а после этого нормальным программистам приходится отлаживать
> C>приложения, где запросто сохраняются ссылки на мегабайтные документы в
> C>какой-нибудь большой карте объектов — а потом забывают удалять их
> оттуда.
> Так, все-таки. Сначала надо учить функциональные языки или управление
> памятью?

Сначала функциональные языки, чтобы понять что такое контекст
вычисления, а потом С++ и узнать про политики владения и ручное
управление памятью.

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

Posted via RSDN NNTP Server 2.0 beta

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

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

СГ>>Спасибо за ответ, теперь буду знать.

В>Я правильно понял, что до "дела" (примера обероновского кода, на котором можно (якобы наглядно) изучать принципы ООП) так и не дойдет?

Так у Вирта же в его книге Programming in Oberon (2004) как раз на примере этих самых графических фигурок и написано. Чем Вам его пример не понравился? Или Вы не читали? Если не читали, то все книги можно скачать, например, от туда: http://www.oberon2005.ru/

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

СГ>Так у Вирта же в его книге Programming in Oberon (2004) как раз на примере этих самых графических фигурок и написано. Чем Вам его пример не понравился? Или Вы не читали?

Не читал. Зато видел некоторые примеры ООП на Обероне, которые обсуждались здесь. Они были ужасны.

СГ> Если не читали, то все книги можно скачать, например, от туда: http://www.oberon2005.ru/

Целостного примера (от начала и до конца) там нет. Я попробую в свободное время собрать все вместе и сравнить. Но вам наверное это было бы проще.

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

В>Целостного примера (от начала и до конца) там нет. Я попробую в свободное время собрать все вместе и сравнить. Но вам наверное это было бы проще.

Целостный пример (правда на Component Pascal) есть в системе BlackBox — это она сама (иходники открыты).

Документация к ней чем-то напоминает главы из книги "Паттерны проектирования" Гамма, Хелм, ...

Получение и установка Блэкбокса
http://www.inr.ac.ru/~info21/install/welcome.html

Первые сведения о работе в системе Блэкбокс
http://www.inr.ac.ru/~info21/blackbox/welcome.html

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

СГ>Целостный пример (правда на Component Pascal) есть в системе BlackBox — это она сама (иходники открыты).

Чтобы не путаться, хотелось бы оставаться в рамках одного языка. Возможно в Component Pascal все не так плохо и там для отражения концепций ООП есть человеческий синтаксис. Но в качестве языка для обучения ООП был предложен именно Оберон.

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

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

СГ>>Целостный пример (правда на Component Pascal) есть в системе BlackBox — это она сама (иходники открыты).

В>Чтобы не путаться, хотелось бы оставаться в рамках одного языка. Возможно в Component Pascal все не так плохо и там для отражения концепций ООП есть человеческий синтаксис. Но в качестве языка для обучения ООП был предложен именно Оберон.

Проект "Информатика 21" предлагает именно Component Pascal.

Component Pascal — некое надмножество языков Oberon и Oberon-2.

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

Т>>А объекты и в самом деле ерунда. Это вам и Пол Грем подтвердит.

AF> Объекты сами по себе — да. А вот умение понять что нужно сделать, построить правильно архитектуру и спроектировать систему с помощью объектов — вот это и есть суть программирования. И ей, увы, не учат

В книге Project Oberon (Вирт и Гуткнехт) как раз и рассматривается конкретный пример операционной системы, созданной с нуля. С объяснением архитектурных решений. С исходными текстами.
А Вы говорите — не учат.

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

Т>>>А объекты и в самом деле ерунда. Это вам и Пол Грем подтвердит.

AF>> Объекты сами по себе — да. А вот умение понять что нужно сделать, построить правильно архитектуру и спроектировать систему с помощью объектов — вот это и есть суть программирования. И ей, увы, не учат

AVC>В книге Project Oberon (Вирт и Гуткнехт) как раз и рассматривается конкретный пример операционной системы, созданной с нуля. С объяснением архитектурных решений. С исходными текстами.
AVC>А Вы говорите — не учат.

О! А вы не подскажете, где ее скрасть можно?

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

AF>> Объекты сами по себе — да. А вот умение понять что нужно сделать, построить правильно архитектуру и спроектировать систему с помощью объектов — вот это и есть суть программирования. И ей, увы, не учат

Ну а Линукс Торвальдс делает тоже на C++, только с гораздо большим количеством разнообразных примеров

Потом я же не утверждал, что нет информации — просто студентов действително не учат проектированию — на каком либо языке.

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

AVC>Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>>Честно говоря, по широте выборки фич сильно напоминает приколы на тему "что общего между женщиной и пивом".
ЗХ>>(я не отрицаю и не подтверждаю, что Ява ближе к Оберону, нежели к С++. но табличка эта смотрится несерьезно)

AVC>Возможно, она смотрится несерьезно.

AVC>Но практически за каждым указанным в ней синтаксическим ( ="внешним") отличием между Си++ и Java/Обероном стоит различие механизмов языков и соответствующего им рантайма ( ="внутренних", существенных особенностей).

И начать стоит вестимо с глубоких концептуальных отличий, вызванных отказом от goto и выходом из цикла по continue с меткой

AVC>Возьмем, к примеру, отсутствие в Обероне и Java вариантных записей (union).
AVC>Во-первых, такие записи могут использоваться (и используются) для скрытого приведения типов, что в корне противоречит концепции безпасности типов. Си++ это заботит мало (по-моему, ему на все наплевать

), а вот Оберон и Java — сильно "привязаны" к безопасности типов.
AVC>Во-вторых, здесь есть прямая связь с реализацией сборки мусора. Дескриптор типа в Обероне включает не только адреса методов (type-bound procedures), но и смещения указателей в записи. Если бы во время исполнения программы по этому смещению могли находиться как указатель, так и переменная неуказательного типа, то механизм сборки мусора сильно бы усложнился, а то и вовсе стал бы труднореализуемым. Т.к. Вирт уже добавил в язык расширение типа ( =наследование), то потребность в вариантных записях, порождающих эти проблемы, отпала сама собой.

Ну если уже Вирт наследование придумал, то нам остаётся только удивляться — почему это C++ не объявлен сильно испорченным обероном?

Возникшая ситуация описана совершенно верно, однако она носит фундаментальных характер и с ней встреться любой проектировщик языка со сборщика мусора и у него будет выбор — отказаться от вариантных записей (тем паче что даже на презираемом вами C++ они встречаются крайне редко) или же — добавлять к union дополнительную информацию и механизмы, что бы различать — ссылка там или что-то другое. Первый вариант очевидно — проще

AVC>Но возникла другая проблема: а как эффективно определить динамический тип записи?
AVC>(Напомню, что факт принадлежности переменной к тому или иному динамическому типу требует всего одного сравнения.)
AVC>Решение следующее: каждый тип записи имеет свой уровень расширения. (Базовый тип — уровень 0, прямо ему наследующий — уровень 1 и т.д.) Указатели на дескрипторы с соответствующими уровнями расширения хранятся в массиве в дескрипторе типа. Когда мы проверям переменную на принадлежность типу, мы на самом деле сразу обращаемся к элементу массива с соответствующим индексом. Этот механизм реализован на Обероне настолько эффективно, что сначала в языке даже не было методов, а просто использовалась процедурная переменная в качестве поля записи.
AVC>Легко также видеть, что подобная схема плохо сочетается с множественным наследованием.
AVC>Т.к. в Обероне единицей инкапсуляции является модуль, а не класс, то множественное наследование оказалось излишним и не попало в язык.

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

AVC>И т.д. и т.п.

AVC>Короче говоря, это целая система взаимоувязанных решений.

Да, естественно, любой язык или платформа — это комплекс взаимосвязанных решений.

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

Ну и что? Решение схожих задач приводит зачастую к схожим результатам.

Простой пример. Есть две ящирицы — внешне почти не отличимы, причём даже для того, кто знает, как их отличать. При этом у них совершенно различный генетический код — одна из них ящерица, а вторая — саламандра. Схожие внешние условия сделали их — таких разных по происхождению — такими похожими внешне.

Это я к тому, что подобие ещё не означает происхождение из одного источника.

От:	Сергей Губанов	http://sergey-gubanov.livejournal.com/
Дата:	26.09.05 18:56
Оценка:	142 (18)

	От:	Дарней
	Дата:	27.09.05 05:22
	Оценка:

	От:	AVC
	Дата:	27.09.05 08:26
	Оценка:	+1

	От:	Дарней
	Дата:	27.09.05 08:52
	Оценка:	+2

	От:	AndreyFedotov
	Дата:	27.09.05 09:13
	Оценка:	+3

	От:	gear nuke
	Дата:	27.09.05 21:17
	Оценка:	9 (2) +1

От:	eao197	http://eao197.blogspot.com
Дата:	27.09.05 22:16
Оценка:

	От:	Зверёк Харьковский
	Дата:	27.09.05 22:50
	Оценка:	1 (1) +7

	От:	Cyberax
	Дата:	28.09.05 04:17
	Оценка:	3 (1) +3 -1

От:	Serginio1	https://habrahabr.ru/users/serginio1/topics/
Дата:	28.09.05 06:50
Оценка:

От:	Andrei N.Sobchuck	www.smalltalk.ru
Дата:	28.09.05 19:57
Оценка:	1 (1)

	От:	Трурль
	Дата:	29.09.05 05:55
	Оценка:	1 (1) +1

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	29.09.05 14:28
Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	30.09.05 05:45
Оценка:	+1

От:	Mystic	http://mystic2000.newmail.ru
Дата:	30.09.05 06:48
Оценка:

От:	VladD2	www.nemerle.org
Дата:	03.10.05 00:24
Оценка:	1 (1)

От:	jazzer	Skype: enerjazzer
Дата:	03.10.05 01:34
Оценка:

	От:	Павел Кузнецов
	Дата:	04.10.05 22:43
	Оценка:

	От:	Кодт
	Дата:	11.10.05 22:31
	Оценка:	7 (2) +3

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

	От:	alexeiz
	Дата:	13.10.05 20:17
	Оценка:	2 (2) +1