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

sch>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Т>A+B->C
Т>

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

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

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

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

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

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

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

You will always get what you always got
  If you always do  what you always did

VladD2 wrote:

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

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

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

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

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

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

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

Здравствуйте, 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), у Явы слишком много совпадений с Обероном.

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

Здравствуйте, 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)

Здравствуйте, 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)

Здравствуйте, 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)