Ответ на »сообщение 802« (Дмитрий)
___________________________

Попробую ответить коротко, как того требует возмущенная общественность.

1. Подъездные пути к Оберонам (из серии Getting Started -- С чего начать) недоделаны. Это факт.

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

3. Когда я внимательно вчитывался в различные предложения о создании хорошей среды, то приходил к выводу -- хотят а-ля Delphi или а-ля Visual Studio. Есть примерные представления о трудозатратах? Кто-нибудь проводил оценку объемов работ и последующих рисков?

Простой вопрос: а зачем страждущие непременно самой что ни на есть современной IDE так зациклились на Обероне? Работайте на Delphi. Почти все есть. И почти теми же словами...

Ответ на »сообщение 803« (Неуч)
___________________________

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

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

И вообще, поток сознания в виде многострочных постов явно захлестывает (забалтывает) любую здравую мысль в этом форуме.

Что делать? Видимо, надо исправляться. Но Вы можете сильно помочь, если приведете перечень здравых (на Ваш взгляд) мыслей в этом форуме.

Ответ на »сообщение 796« (Alexey Veselovsky)
___________________________

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

Тут я с Вами не соглашусь.

В своей работе "Научные основы доказательного программирования" Андрей Петрович Ершов (надо будет выложить) выделял три вида программирования:

1) синтезирующее (автоматическое, автоматизированное или ручное манипулирование знанием о задаче с синтезом соответствующей программы);
2) сборочное (построение программы из уже существующих и корректных фрагментов)
3) конкретизирующее (построение специализированных программ из универсальных заготовок).

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

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

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

Второе (информационные технологии) - это уже программирование как таковое. Задачки разные. Паскаль. Написание макросов для МС-Офиса. Сейчас вот Visual Basic 6.3 они начали проходить.

Занятно. Но не удивлен. На мой взгляд, не нужно учить язык программирования в школе сам по себе. Даже Оберон. Нужно решать задачки, как в математике. А язык -- это всего лишь средство записи решения, которое можно потом перепроверить.

Помнится, в начале 1980-х годов у нас в МАИ были проблемы с доступом к компилятору Паскаля. Так писали на бумаге и мелом на доске. А параллельно -- Фортран -- через перфокарты. Так мне мелом и пером как-то даже понравилось. Дисциплинирует. Сначала думаешь, а потом уже делаешь. Сильно потом помогло. К работе с отладчиком не привык. Совсем иное мышление.

Что касается "бирюлек" в виде макросов и скриптов -- то не алгоритмика. Это "домазывание-приляпывание". Но чтобы не очень обидно звучало -- конкретизирующее программирование.

Ответ на »сообщение 802« (Дмитрий)
___________________________
Очень здраво. Как говорят в ЖЖ - +1.

Ответ на »сообщение 798« (Руслан Богатырев)
___________________________
Вообще не худо бы к каждому утверждению типа "Оберон-2 -- экспериментальный язык" добовлять "по моему мнению, которое конечно не может быть истиной в последней инстанции".

И вообще, поток сознания в виде многострочных постов явно захлестывает (забалтывает) любую здравую мысль в этом форуме.

Уважаемые коллеги!

С приезда Вирта начал следить за форумом "Мысли об Обероне".
Первые несколько месяцев с трудом понимал и половину текста, т.к. было очень много относительно непонятных слов или они были употреблены в незнакомом контексте.
Это я к тому, что понять о чем идет речь непросто (при простоте языка).

Неоднократно выплывал вопрос "Что делать?".

Нормальную среду с хорошими библиотеками.
Все, больше ничего не надо.

0) О мышлении
Считаю, что язык Оберон (в любой ипостаси) учит думать. И хотя бы поэтому его надо развивать. Особенно в России, поскольку у нас сильны традиции изучения Паскаля.

1) Инструмент отделен от результата
Когда детей начинают учить программированию (или, как вариант, дети начинают учиться программированию), то очень важно, чтобы путь от алгоритма до результата исполнения был наиболее коротким.
Т.е. грубо говоря,

BEGIN
  Out.WriteLn("Привет, мир!");
END;

F9

и на консоли появляется
Привет, мир!.
Причем в виде приложения (*.exe)

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

В BlackBox надо постараться, чтобы получить результат, отдельно от среды (у меня так и не получилось).

2) Среда для тех, кто понимает
Turbo/Borland Паскали, а затем и Delphi подкупают тем, что по F9 получаешь готовое приложение, которое очень хорошо вписывается в предложенную Виртом модель последовательных изменений (извините, если термин процитировал неверно). Это с одной стороны.
С другой стороны, Дельфи включает в исполняемый файл все, что можно. Получается много. Но можно включить "Build with runtime packages" и файл получается маленький (но несет за собой runtime).
Получается, что с одной стороны вы можете сразу взять и пользоваться, а с другой стороны, что-то можно вынести в пакеты и использовать отдельно.

В среде XDS, GPCP и BlackBox мне с первого раза не удалось запустить исполняемый файл. Что-то требовалось дополнительно.

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

Поэтому среда, сделанная под Оберон, должна уметь делать результат (исполняемый файл) сразу. На мой взгляд, она должна генерировать исполняемые модули примерно следующего вида (названия мои и они условны):

• Статическое связывание (сборщик мусора впаян в исполняемый файл, нет динамической загрузки)  (по умолчанию)
  
• Полустатическое связывание (Исполняемый фай - отдельный файл, состоит из модулей; при подкладывании рядом с ехе компилированного модуля производится его динамическая загрузка с выгрузкой того, что зашит в ехе)
  
• runtime отдельно, статическое связывание. (Сборщик мусора (и, возможно, другие модули) лежит отдельно в виде DLL. Размер исполняемого файла резко уменьшается. Нет динамической загрузки)
  
• runtime отдельно, полустатическое связывание. (то же, что и предыдущее, но с динамической загрузкой)
  
• Сборка в виде набора модулей (по типу BlackBox - чистой воды динамическая загрузка с предкомпилированными модулями)
  
• предыдущее + наличие встроенного компилятора (т.е. в чистом виде BlackBox %) )
  

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

3) + Юникодизация всей среды.
Очень интересной мне кажется идея (и она не так уж сложна в реализации), что нужно указывать кодировку результата. Наверняка многие сталкивались с тем, что среда (Дельфи) работает в CP1251 кодировке, а на консоль выводить надо в CP866. Никому не попадались студенческие работы со строками вида

Writeln('Rezultat wychisleniy');

?
Если явно компилятору указать, что исходник в CP1251, а выводить надо в другой кодировке (хоть koi-8), то немало преподавателей спасибо скажут разработчикам.

Не менее важно и действительная юникодизация библиотеки, с которой будет работать среда.

4) Работа со сторонними инструментами.
От этого никуда не дется.
Это значит (как минимум) система плагинов, работа с CVS со товарищи, внешний отладчик (что бы про это не писали, для работы в WinAPI отладчик нужен), профайлер.
Безусловно, среда должна уметь работать с текстовыми файлами, т.к. файлы своей структуры (бинарные) напрочь отбивают возможность использования хотя бы других редакторов.

5) Бантики
Подсветка синтаксиса, CodeComplete - обязательные атрибуты среды.
Показ содержимого библиотек (Code Browser) тоже не помешает.

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

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

Надеюсь, меня сильно тут не побьют.
Спасибо.

Ответ на »сообщение 795« (Alexey Veselovsky)
___________________________

> Но можно себя ограничить подмножеством.
Можно. Равно как и подмножеством любого другого языка. например С++.

Подмножество -- не от хорошей жизни. Был бы эталонный Оберон-компилятор, можно было бы писать на чистом Обероне хоть детишкам, хоть дядям и тетям.

Подмножество подмножеству рознь. Можно говорить о том, что рекомендуемое мной подмножество Оберона-2 -- это просто отказ от связанных процедур (при использовании в системах программирования, ориентированных на Оберон-2, т.е. XDS, Pow!, OO2C, JOB). В таком свете это трудно сравнивать с Вашим примером относительно C++ (особенно если брать ограничения к гигантскому ISO-стандарту 1998 г.).

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

На самом деле с ней ситуация такова. Есть инициативная группа. Проведены бурные обсуждения целесообразности вообще построения такой библиотеки. Появилось некоторое понимание нужности работ. Сделан набросок структуры библиотеки и сформулированы ее принципы (но они не зафиксированы). Об этой инициативе знает проф. Вирт, с ним и велись консультации. Его пожелания -- иметь совместимость с базовыми модулями системы Oberon. Что очень разумно, ибо они проверены жизнью и документированы в книгах. На этом уровне пока все и затормозилось.

> Библиотека -- очень важный момент. Но здесь нужно
> движение (подвижки) со стороны всех заинтересованных
> лиц.
Какие именно движение нужно? Вот к примеру я заинтересованное лицо. Что я могу сделать?
В близжайшее время (месяц) я буду ковырять GDI+, возможно попробую прицепить (сделать модуль или набор модулей) к XDS либо к BB.
Так что если графика будет входить в стандартную библиотеку, то наверно смогу поспособствовать.

Это уже хорошо. Значит, есть-таки потребность в стандартной библиотеке. Давайте реанимируем. У кого есть желание подключиться -- пишите мне: bogatyrev@pcworld.ru . Вместе со старыми участниками, глядишь, что-то до ума и доведем. Хотя бы на уровне проекта. Наверное, настало время от анализа переходить к синтезу, а потом уже к критике и публичному обсуждению.

Также в сферу моих интересов входит операционная система BeOS (жель не нашел внятного компилятора Оберон - Оберон-2 под нее).

Была декларирована такая реализация: http://www.beatjapan.org/mirror/www.be.com/beware/Languages/BeOberon.html Попробуйте напрямую связаться с группой по развитию OO2C: http://ooc.sourceforge.net/ Они ранее заявляли о планах поддержки и BeOS: http://www.bebits.com/app/943

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

"Программирование: теоремы и задачи" А.Шеня. Эти задачи, правда, надо бы перевести с Паскаля на Оберон, но это несложно.

Кстати, у Шеня задачи требующие динамической памяти реализуются на массивах, т.е. фактически, настоящая динамическая память не используется вовсе.
В Обероне и Компонентном Паскале есть сборщик мусора, так что переделывая книгу Шеня с Паскаля на Оберон многие задачи можно реализовать через настоящее использование динамической памяти - списки и деревья реализовывать не через массивы, а через POINTRER TO RECORD.

Ответ на »сообщение 797« (Alexey Veselovsky)
___________________________

Кстати, а что такое POW!
Чем оно хуже-лучше чем XDS например?

С удивлением обнаружил, что в свое время не разместил Pow! на Oberon2005. Непорядок. Исправим. Вот прямая ссылка http://www.fim.uni-linz.ac.at/pow/Pow.htm

Инструментарий сделан в университете Линца под руководством проф. Мессенбека. Давно заморожен и не развивается. Очень простая и понятная IDE. Ориентирована на Windows. Есть все исходники. Среда реализована на C/C++ и обеспечивает интеграцию с Oberon-2, Java и C++.

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

Кстати, хорошая мысль. Pow! для школ -- это очень и очень неплохо.

Ответ на »сообщение 795« (Alexey Veselovsky)
___________________________

> Oberon(-1), который исходить из канонической модели
> NW-1990 с поправками Вирта конца прошлого года
> (неформальными уточнениями).
А где можно узнать о этих поправках?
Т.е. отличае 1990 от 2004.

Они войдут в качестве дополнения к переводу книги Вирта "Программирование на Обероне", поскольку в явном виде не документировались. В двух словах (пишу по памяти) -- это возвращение оператора FOR (который был изъят из Оберона при переходе от Modula-2, но включен в Оберон-2), отказ от вариативности числовых базовых типов, связанной с диапазоном представления -- только INTEGER и REAL (без LONGINT и LONGREAL). Были еще нюансы.

> Ключевое отличие такого Oberon от Oberon-2 --
> связанные процедуры (type-bound procedures).
Кстати, а чем такие процедуры мешают?

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

Процедурные переменные позволяют получить гибкость при построении расширяемых систем (на этом базируется система Оберон, для реализации которой язык Оберон и проектировался из Modula-2). У классов (точнее, их имитации) не статические методы (методы-константы), а динамические методы (методы-переменные). Детали и нюансы этого не один раз подробнейшим образом разбирались в Мыслях об Обероне.

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

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

Думаю, здесь стоит еще раз вернутся к водоразделу между родственными языками Оберон-семейства.

Оберон -- один из самых компактных императивных языков. Создан Виртом и фактически зафиксирован более 15 лет назад. Это лаконичная символика программирования. Своего рода эсперанто, латынь программирования. В сфере императивного программирования ему в такой ипостаси трудно найти конкурента.

Оберон-2 -- экспериментальный язык, созданный проф. Мессенбеком из университета Кеплера в Линце (Австрия), который перестал им заниматься более 8 лет назад и переключился на модные Java и C#. Кушать хочется всем.

Компонентный Паскаль -- язык конкретной компании (Oberon microsystems). Ревизия Оберон-хозяйства. Ответ на выход Java. Изменение базовых типов -- не самое страшное. Они создают проблемы несовместимости, но, как выясняется, в Обероне нигде не зафиксировано, что INTEGER -- 16 битов.  Размеры практически всех базовых типов в Обероне могут определяться реализацией. Лицо КП определяют связанные процедуры (type bound) + модификаторы (ABSTRACT, EXTENSIBLE, LIMITED, EMPTY, NEW). Это создает понятийные навороты (и новые понятийные проблемы) в ООП по сравнению с моделью Оберона.

В КП принципиально меняется подход к расширению типа (RECORD). У Вирта он по умолчанию. На нем и строится расширяющее программирование. У КП -- требует явного модификатора EXTENSIBLE (с точностью до наоборот).

Чем выигрывает КП в реализации BlackBox по сравнению с классическим Обероном? Практичностью, определенным удобством для программистов. Язык придвинут к индустрии. В этой связи его разумнее позиционировать как облегченную версию Java (Java light) в синтаксисе Паскаля.

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

Таким образом, есть "теоретический" Оберон, "практический" Компонентный Паскаль, а между ними -- "связующий" Оберон-2.