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

А на каких языках "наши" и "не-наши" разработчики В НАСТОЯЩЕЕ ВРЕМЯ создают программные средства в тех областях, где ошибка программиста - не просто кривая картинка или глухое звучание, а жизнь человека? Ну, скажем бортовые программы самолетов или ПО, предназначенное для управления ядерным реактором.

О некоторых "засвеченных" в плане военно-космического использования можно сказать:

1. В.Лось (Украина, Харьков) -- http://www.delphikingdom.com/asp/users.asp?ID=1485
Язык: Обероны в голове, в работе C/C++.

2. А.А.Колташев (Россия, г.Железногорск, НПО ПМ им. Решетнева) -- см. http://www.inr.ac.ru/~info21/info/konsuljtanty.htm
Язык: Модула-2
Используют спец. инструментарий, который сделан на основе XDS по их заказу самими авторами XDS (новосибирцы, Excelsior) -- http://www.excelsior-usa.com/pr20040923.html


Добавлю, что для таких задач, на мой взгляд, Модула-2 несколько предпочтительнее Оберона. Вообще-то Модулой и стал заниматься в МАИ именно по той причине, что Си для встроенных систем ответственного/военного назначения -- мало подходящая вещь.

Объясню, с чем связан вопрос. Знаю, что у Вирта и его учеников была разработка - система управления вертолетом (кажется, беспилотным). Называется, вроде, OLGA. Написана на Обероне (а на чем же еще :)). Так вот, мне кажется, что для этой системы всякая там эстетика на экране может и нужна, но она уж точно не главное. Главное, чтобы неаккуратная работа с типами данных не привела к падению этой железяки на наши головы :).

Не знаю в тему или нет, но раз уж речь пошла об отношении между функционалом и эстетикой в мире программирования и о месте "простых и надежных Оберонов" в этом мире, то спрошу. Если это не государственная тайна, то прошу специалистов дать справку:
А на каких языках "наши" и "не-наши" разработчики В НАСТОЯЩЕЕ ВРЕМЯ создают программные средства в тех областях, где ошибка программиста - не просто кривая картинка или глухое звучание, а жизнь человека? Ну, скажем бортовые программы самолетов или ПО, предназначенное для управления ядерным реактором. То есть там, где если перемудрил с арифметикой указателей, то так ...ет, что мало не покажется. Неужели тоже на С/C++?

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

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

Ответ на »сообщение 892« (Alexey Veselovsky)
___________________________
что и как будет делать Борланд. Ибо полноценная замена уже довольно есть - FreePascal (как
*довольно давно

Ответ на »сообщение 890« (Руслан Богатырев)
___________________________

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

Насчет Delphi и Оберона.

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


Кончины не будет вообще. Вне зависимости от того что и как будет делать Борланд. Ибо полноценная замена уже довольно есть - FreePascal (как компилятор) и Lazarus, как среда. Практически идентичная Делфи. И проекты туда делфовские вполне переносятся.

Есдинственное что - там пока палитра компонентов существенно беднее делфовой. Ну да это дело наживное. Постоянно новые компоненты появляются.

Может знает кто-нибудь из присутствующих, где достать компилятор Oberon-M (он для MS-DOS) версии старше 1.1? Если ещё и исходники его есть, то буду очень рад :). Обыскал всё, вроде и есть он где-то, а вроде и нет... год был 1991.

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

Насчет Delphi и Оберона.

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

Если кто-то работал на Delphi и посматривает на Оберон с точки зрения идейной "отдушины" -- это полезно, если же как спасательный круг для существующих работ и проектов, то это уже куда менее оправданно. Здесь я бы не говорил о явном превосходстве Оберона (в смысле того же BlackBox/КП) над Delphi. По крайней мере, на нынешнем уровне Оберон-инфраструктуры.

А вот если есть желание уже сегодня сделать что-то стОящее, не сиюминутное, причем там, где вы будете чуть ли "первый парень на деревне", то Обероны -- то, что надо.

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

Писал на Васике и Дельфях. Хочится научится на Жабе. Если через Оберон то как ?

Ну вот, стоило только заикнуться насчет обдумывания того, как Оберону "закорешиться" с Java, как сразу же берут за горло. :0)

Попробую набросать кое-какие идеи на этот счет.

Если возникает необходимость/желание изучить сам язык Java, то тут Оберон не сильный помощник. Зачем через посредника, если можно напрямую?

А вот если язык -- не самоцель, если есть твердое желание работать в Java-мире или уметь то же самое, но "другими словами" -- то к Оберону присмотреться стоит. И быть может, использовать именно его как плацдарм для освоения Java-технологий.

Итак, можно предложить три подхода:
1. Оберон как Java-заменитель (вроде заменителя сахара, вспомним про Coca Cola light)
2. Оберон как Java-ретранслятор (пишем на Обероне, а результат автоматически получаем на Java).
3. Оберон как Java-резидент (атташе, разведчик, "засланец" в чужом мире).


Java-заменитель

Это полезно, когда человек хочет приобщиться к миру ООП (без знания которого тебя сверстники сейчас сочтут за идиота), знать, что делает это на прообразе Java (кто не знает такого языка -- неуч, в которого будут тыкать пальцем). Причем на языке, который проще изучить, чем Java, и который можно быстрее начать использовать. Здесь Pow (Оберон-2) и BlackBox (Компонентный Паскаль) -- хорошая отправная точка. А Pow даже может выступить в роли того самого козла из притчи (см. »сообщение 762« ); на его фоне BlackBox покажется верхом совершенства.


Java-ретранслятор

Тут, однако, напряженка. Вот из Оберона в Си (ANSI C) -- так это пожалуйста (XDS и OO2C). А в Java: есть JOB для Oberon-2 (крохотный, бесплатный, зато для некоторых вещей вполне подойдет), есть Canterbury Oberon-2 (хошь -- генерирует исходники на Java, хошь -- байт-код, но стоит денюжку), есть GPCP/Eclipse для КП (этот погружен в Java-мир, плавает в нем, причем в самой что ни на есть передовой среде от могучего IBM).


Java-резидент

Программируя на конкретном языке программирования, практически каждый с годами вырабатывает для себя свое активное/рабочее подмножество этого языка. Выработка ведется достаточно стихийно, методом проб и ошибок. Можно ли это как-то упорядочить? Конечно, многие так и делают. Можно работать на другом уровне абстракции (проблемно-ориентированный язык, сети Петри и конечные автоматы и т.п.), а потом отображать это автоматически или с участием человека на конкретный целевой язык. Причем вне зависимости от того, идет ли речь о программисте-слуге (по А.П.Ершову) или о программисте-хозяине.

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

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

Для этого пути Оберон выступает в роли тренажера. Тренажера навыков и мозгов.

Если тулбар забит, то несколько слов об инспекторе модулей.
Или это противоречит неразделению на интерфейс и код
из принципиальных соображений духа призмы Оберона?

Я, для затравки, набросаю эскиз.
Прошу критиковать без фанатизьму и генерировать идеи.
ЦЕЛЬ:
Создавая инспектор, мы не только облегчаем доступ к компонентам (модулям)
и манипуляции с ними, но будем вынуждены выработать спецификацию
на эти компоненты, что пойдёт на пользу (?) стандартизации библиотеки
и, вообще, её дальнейшему развитию. Или ветви библиотек "для инспектора".

ВОЗМОЖНЫЙ ФУНКЦИОНАЛ:
Выводить переменные модуля.
Накладывать ограничения на них (область определения аргумента).
Выводить хинты к переменным - их описания в отдельной закладке.
Почему декларация переменных только в объявлении типа?
Почему бы не описание предназначения, где возможно или (и)
размерность величины для практических задач.
Выводить описание всего модуля в целом в отдельной закладке.
Цеплять тестовый пример проверки работы с возможностью
варьирования входных параметров и отображением выходных.
Система связи переменных разных модулей (?).

Выработка набора модулей-заглушек (?) , что для сборочного
программирования манна небесная.
Отдельно браузер модулей на компе или в архиве.

Дорогу осилит идущий.