>>>1) Не совсем представляю, как можно "надёжность 17-го уровня" (йава, шарп)
>>>отличить от "надёжности уровня 18бис" (оберон).

Не знаю, как насчет точных чисел (17, 18 и тд.), но сравнивать надежность языков можно. В C# есть директива unsafe - т.е. программист может, если ему очень хочется, написать фрагмент "опасного" кода. В Оберонах этого нет (или я об этом еще не знаю :)). В C/C++ вообще можно использовать "арифметику указателей" и забывать освобождать динамическую память. Следовательно, надежность C#, в котором есть авт. сборка мусора и "защита" в форме "unsafe" выше, чем у C/C++, а надежность Оберонов, соответственно, еще выше. А уж чему она равна 17 или 18бис - это дело десятое. Главное, что можно делать относительные оценки надежности.
P.S.
Не знаю, как обстоит дело с самыми последними версиями VB (не люблю этот язык, да простит меня Б.Г.). Но в программе на VBA у меня был пример такого кода, в котором программист ошибся в имени переменной, а Basic этого не заметил - он принял эту переменную за новую, только необъявленную! Вот "надежность" таких языков можно принять равной нулю. А для остальных уже измерять по какой-то шкале.

Ответ на »сообщение 1052« (AVC)
___________________________
Java и C# считаются вполне "надежными" языками
требуется сочетание еще более высокой надежности и эффективности
Это сильно напоминает 19 уровней критичности ошибки в T-SQL.
1) Не совсем представляю, как можно "надёжность 17-го уровня" (йава, шарп) отличить от "надёжности уровня 18бис" (оберон).
2) А кто поручится за надёжность самого программиста - самого слабого звена в любом языке. Или первоклассник, первокурсник и кандидат пишут программы на Обероне на одинаковом уровне?

Там же, где требуется сочетание еще более высокой надежности и эффективности, вполне можно использовать Оберон
Не "вполне можно", а "обязательно нужно!", простите. Ветка посвящена Оберонам, а не Йаве и Шарпу. :)

Я так понимаю, это ирония.
Ага.

а также отсутствие опыта создания больших "стандартных" библиотек
Кстати, а может, Кладов этой идеей проникнется? Уж у кого - у кого, а у него такого опыта...

Ответ на »сообщение 1053« (AVC)
___________________________
Да, с сайтом Р. Богатырева что-то непонятное... Может, на другой сервер переезжает?

Что случилось с замечательным сайтом Р.Богатырева www.oberon2005.ru ? :(

Ответ на »сообщение 1049« (гость)
___________________________

Возможно, есть возможность использовать огромные библиотеки Java и .NET?
Как можно?! Ведь это же подорвёт ни с чем не сравнимую сверхнадёжность Оберона! Всё равно, что паять микросхемы паяльной лампой.

Java и C# считаются вполне "надежными" языками (с той же сборкой мусора, с контролем индексов и т.д.).
Там же, где требуется сочетание еще более высокой надежности и эффективности, вполне можно использовать Оберон (что и делается -- проект ONBASS и т.д.).
ИМХО, в таких случая наличие/отсутствие больших GUI-библиотек вроде WinForms, созданных усилиями крупных корпораций, особого значения не имеет.

Мой опыт написания программ на Обероне/КП, работающих совместно с кодом, написанным на других языках, ограничен DLL для работы с Си/Си++.
А вот если бы Вы вместо того, чтобы тратить силы и время на всякое старьё (Си/Си++), посвятили их разработке этих самых библиотек для Оберона...

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

Ответ на »сообщение 1050« (Mirage)

либо считать классы константами типа метакласс в операторе CASE

Если так сделать, то это будет выбор по точному совпадению типа, а надо (WITH делает) с учётом возможного расширения - тип сообщения может быть расширен, но старый код при этом должен остаться работоспособным. Старый код должен рассматривать объект-сообщение расширенного типа как объект старого нерасширенного типа, не зная что он на самом деле расширен. В этом-то и состоит суть механизма позволяющего "бесплатно" расширять систему.

Ответ на »сообщение 1043« (Илья Ермаков)
___________________________

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

Ну вопрос производительности при работе с программной шиной не стоит особо остро. Особенно сейчас. Гораздо неприятнее многочисленные IF'ы. Поэтому не обязательно модифицировать рантайм. Достаточно сделать аналог обероновского WITH (с другим именем, конечно), либо считать классы константами типа метакласс в операторе CASE.

На самом деле Delphi - единственный путь более-менее массового внедрения ОТ. Динамические массивы там уже есть. Еще ряд технологий внедрят, а там уже и о Turbo Oberon задумаются.:)

Ответ на »сообщение 1048« (AVC)
___________________________
Возможно, есть возможность использовать огромные библиотеки Java и .NET?
Как можно?! Ведь это же подорвёт ни с чем не сравнимую сверхнадёжность Оберона! Всё равно, что паять микросхемы паяльной лампой.
Вот смотрите: Оберон - кошер, остальное - треф. Ибо на корню уничтожит все преимущества Оберона.

Мой опыт написания программ на Обероне/КП, работающих совместно с кодом, написанным на других языках, ограничен DLL для работы с Си/Си++.
А вот если бы Вы вместо того, чтобы тратить силы и время на всякое старьё (Си/Си++), посвятили их разработке этих самых библиотек для Оберона...

Ответ на »сообщение 1047« (info21)
___________________________

Вот только как быть с библиотеками?

Если есть -- использовать.
Нет -- написать.

Прямо как в инструкции для новобранцев американского ВМФ:
если предмет движется -- отдай ему честь, если неподвижен -- покрась его. :)

Возможно, есть возможность использовать огромные библиотеки Java и .NET?
(При условии написания для JVM/.NET.)
Мой опыт написания программ на Обероне/КП, работающих совместно с кодом, написанным на других языках, ограничен DLL для работы с Си/Си++.

Что можно сказать об использовании "чужих" библиотек?

Ответ на »сообщение 1046« (AVC)
___________________________

Вот только как быть с библиотеками?

Если есть -- использовать.
Нет -- написать.