Ответ на »сообщение 1438« (pepper)
___________________________
По поводу примера архитектурных приемов - я допишу небольшой текстик и тогда уже его опубликую на нашем, сегодня-завтра, видимо. Просто надоело одно и то же перемалывать в форуме.

По поводу CVS - для работы с исходниками Блэкбокса в русской команде поддержки среды успешно используется SVN (Subversion).

По поводу пошаговой отладки - это не "современное средство", а уродливый костыль. За два года работы в Блэксбоксе я ни разу не пожалел об его отсутствии, о чем уже писал чуть раньше. Пошаговая отладка нужна из-за невозможности в реализациях Цешных языков наглядно обозреть состояние и последовательность выполнения программы. Приходится ограничивать себя узкой пошаговой трассой, вправо-влево от которой можно просмотреть состояние программы. А как быть с многопоточными приложениями? В Active BlackBox я могу в любой момент просмотреть текущее состояние, стек вызовов, локальные переменные любого из потоков, не  выполняя его пошаговой отладки. Сомневаюсь, что классические пошаговые дебаггеры могут дать мне такое же удобство.

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

>>>Когда создавался Оберон, С++ на горизонте не наблюдалось.
???!
Коммерческий выпуск С++ состоялся в 1985 году.
Проект Оберон - 1987 г.
Оберон-2 - 1992 г.

>>>Если бы Вирт копнул в изучении C++ чуть глубже
Не "переживайте" за Вирта :). Думаю, что он понял концепции С++ (а, точнее, их отсутствие) не хуже, чем кто-либо другой.
И понял достаточно, чтобы не проектировать еще один подобный ужас. А то, что язык С, прямой предок С++, заслуживает такой оценки, не скрывают даже его авторы. Вот что пишут Д.Ритчи и Б.Керниган о своем ужасном "детеныше". Цитирую, дабы меня не обвиняли, что я что-то выдумываю.
- Начало цитаты:
"Эта программа будет правильно работать на многих машинах, потому что по умолчанию функции и аргументы имеют тип INT, а указатель и целое обычно можно безопасно пересылать туда и обратно. Однако такой стиль программирования в своем существе является рискованным, поскольку зависит от деталей реализации и архитектуры машины и может привести к непра-
вильным результатам на конкретном используемом вами компиляторе."
- Конец цитаты.
Что это за язык такой, если текст программы будет правильно работать на только на многих машинах? А на некоторых он будет работать неправильно! Хотя с точки зрения языка он совершенно нормален! Это не язык, это "грамматический бред".

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

Если бы Вирт копнул в изучении C++ чуть глубже

1. Когда создавался Оберон, С++ на горизонте не наблюдалось.
2. В языке важнее его цельность, а не набор отдельных фич.
3. Оберон создавался для конкретной задачи; оценивать "ошибки" Вирта надо по отношению к этой задаче.

Право, такое затруднение -- выбор! Если бы еще один,
два человека, а то четыре. Как хочешь, так и выбирай. Никанор Иванович
недурен, хотя, конечно, худощав; Иван Кузьмич тоже недурен. Да если сказать
правду. Иван Павлович тоже хоть и толст, а ведь очень видный мужчина. Прошу
покорно, как тут быть? Балтазар Балтазарыч опять мужчина с достоинствами. Уж
как трудно решиться, так просто рассказать нельзя, как трудно! Если бы губы
Никанора Ивановича да приставить к носу Ивана Кузьмина, да взять
сколько-нибудь развязности, какая у Балтазара Балтазарыча, да, пожалуй,
прибавить к этому еще дородности Ивана Павловича -- я бы тогда тотчас же
решилась. А теперь поди подумай! просто голова даже стала болеть. Я думаю,
лучше всего кинуть жребий. Положиться во всем на волю божию: кто выкинется,
тот и муж. (Н.В.Гоголь "Женитьба")

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


Мне понравилась статья Евгения Зуева "Редкая профессия" о том, как он в середине 90-х занимался разработкой компилятора С++ для какой-то европейской фирмы...
Весьма интересно и поучительно.


Да, я читал эту статью, весьма занимательно. С компилятором Оберона они бы наверняка справились бы на порядок быстрее, если не на два порядка. И чего? С тем, что C++ непомерно сложен, как и его компилятор, никто не спорит. Но то, что я вижу в обероне и его компиляторе, я считаю другой крайностью.

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

В этом языке Вы можете определить такие типы данных, как "Множество цветов" и, даже, "Множество белых медведей". Причем на уровне обычных стандартных типов, без всяких классов и прочих последних новомодных изобретений. Так что насчет особой "выразительности" языков типа C/C++ и их наследников лучше помолчать. Против выразительности языков виртовской школы они "не катят".


В C++ классы ничем не отличаются от "стандартных" типов, за счет этого и получается достичь выразительности, до которой виртовским языкам так далеко. Если бы Вирт копнул в изучении C++ чуть глубже, нежели "идиотского синтаксиса, в котором операция присваивания обозначается значком '=', а не понятным любому нормальному человеку значком ':='", то кто знает, насколько выразительнее стал бы Оберон.

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


>>А какие более серьезные претензии к Оберону?

Лично для меня (в порядке убывания необходимости)


Ясно, что мы сейчас обсуждаем Оберон на уровне простых языков Оберон-1/2 и КП.
Замечу только, что в обероновском семействе есть "изощренные" языки (вроде Zonnon), существенно более "потакающие" Вашему вкусу. :)


1) Механизм исключений


В Zonnon есть встроенная обработка исключений (с ней связаны ключевые слова ON и EXCEPTION).
В "чистом" же Обероне возможен способ обработки исключений, не требующий изменений в языке, за счет рефлексивности.
Что любопытно, он обходится практически даром и совсем не влияет на эффективность кода (zero-overhead) в случае, когда исключение не было возбуждено. :)
(Я имею в виду "Zero-Overhead Exception Handling Using Metaprogramming".
Кстати, этот подход применен в Native Oberon.)


2) Возможность обобщенного программирования


Самим жалко. :(
Тем более, была же как минимум одна попытка:
http://www.fit.qut.edu.au/~szypersk/pub/JMLC97.ps.gz
Т.е. потребность все-таки ощущалась.
Видимо, проблема где-то в сочетаемости дженериков с компонентностью.
(Там, где речь не идет о компонентности, существуют и варианты Оберона с шаблонами.)
Сейчас же эта потребность может частично удовлетворяться за счет ООП, частично -- за счет внеязыковых средств.


3) Не такой дубовый синтаксис (объявление переменных по месту, нормальный возврат структур, перегрузка операторов и т.п. "фенечки", которые Вирт счел "необязательными", но которые скрашивают долбление кода простым программерам).


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


4) CVS (как туда прикрутить документы блэкбокса пока не очень понятно).


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


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


Тем не менее, что касается пошагового отладчика, его ориентированность "на ламеров" слишком правдоподобна. :)
Впрочем, все это относится к среде программирования, а не собственно к языку.
Есть реализации Оберона и с подсветкой, и с пошаговым отладчиком, и с чисто текстовыми исходниками, вполне пригодными для CVS. Хотя бы XDS.


>>Просто предлагаю подумать, как в Си/Си++ контролируется целостность проекта.
Один способ -- перекомпилировать весь проект целиком. Есть ли другой?

Ну нету в C/C++ модулей, нету. Целостность проекта контроллируется внеязыковыми средствами.


Ага.
Кнопкой "Rebuild all".

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


>>1) выразителен архитектурно.

Допустим. Можно маленький примерчик это демонстрирующий?

http://www.oberon.ethz.ch/WirthPubl/ProjectOberon.pdf
:)


>>Появление ошибочных данных мгновенно "срезается" на каком-либо из неотключаемых ASSERT-ов,

Основная проблема ASSERT'а это не отключаемость/неотключаемость. Никто не мешает в том же C/C++ сделать его неотключаемым (достаточно ввести свой макрос). Проблема в том, чтобы заставить "теток" эти ASSERT'ы расставлять. Оберон/C/C++/C#/Java/Python здесь в абсолютно одинаковых позициях. А вот, например, Eiffel - дает фору.

Значит ли это, что в Eiffel предусловия require появляются сами собой, а не набиваются "тетками", наподобие ASSERT?


Вот это не очень понял. В чем сложность "сложных динамических структур" для C++ (без сборки мусора)? И даже для C без плюсов? Только хотелось бы рассуждений не уровня "студентам придется изучить, что такое динамическая память и как с ней работать", а что-то более приближенное к программерской практике.

Вам когда-нибудь приходилось вылавливать утечки памяти в чужом Си++ном коде?


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

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

Какие мы гордые. ;)
Однако, слово "статические" здесь и правда неудачно.
Речь идет о том, что записи могут быть не только "динамическими" (в куче).
В частности, могут быть "автоматическими" (т.е. располагаться на стеке).

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

Ответ на »сообщение 1426« (pepper)
___________________________
А какие более серьезные претензии к Оберону?


Лично для меня (в порядке убывания необходимости)
1) Механизм исключений
2) Возможность обобщенного программирования
3) Не такой дубовый синтаксис (объявление переменных по месту, нормальный возврат структур, перегрузка операторов и т.п. "фенечки", которые Вирт счел "необязательными", но которые скрашивают долбление кода простым программерам).
4) CVS (как туда прикрутить документы блэкбокса пока не очень понятно).
5) Современные средства написания кода (начиная с подсветки синтаксиса и заканчивая автокомплитом) и отладки (включая пошаговый отлдадчик). Только не надо песен про то, что подсветка нужна только пионерам, а отладчик вообще придумали ламеры.
6) Мне так и не разъяснили вопрос относительно построения физической иерархии модулей для больших систем (>1000 модулей).


Просто предлагаю подумать, как в Си/Си++ контролируется целостность проекта.
Один способ -- перекомпилировать весь проект целиком. Есть ли другой?


Ну нету в C/C++ модулей, нету. Целостность проекта контроллируется внеязыковыми средствами.

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

Ответ на »сообщение 1428« (Jean)
1) выразителен архитектурно.


Допустим. Можно маленький примерчик это демонстрирующий? Того же уровня, что и пример с перечислимым типом? А то для меня это совсем неочевидно. Поддержка модульности на уровне языка говорит в пользу архитектурной выразительности, я не спорю. Однако, как мы выяснили, большинство современных языков в той или иной мере поддерживают модульность. Исключением является, пожалуй, только C/C++, где поддержки модульности на уровне языка нет (что, впрочем, не мешает писать компонентные системы и на C/C++, просто ручной работы на порядок больше).


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


Не знаю, с чего ты взял, что оберон так обожают ученые. Цифры есть?


Точно сформулировать можно так - для прикладных задач, сложных интенсивно, т.е. за счет сочетания сложной логики и требований к гибкости и быстродействию. Т.е. 2) выразителен в алгоритмике. Казалось бы, в чем тут язык может превосходить другие современные языки - программирование "в малом" - оно и в Африке, как говорится... Тут 2 аспекта: строгий синтаксис, не позволяющий "выкрутасов", дает а) простые и красивые решения б) уменьшает кол-во ошибок


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


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


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


Второй аспект - те ошибки, которые все-таки допущены - вылавливаются очень быстро. Это - по собственному опыту разработок в Блэкбоксе.


Я уже рассказывал про вылов ошибок в чужом коде только лишь с помощью компилятора и введения дополнительной типизации.


Появление ошибочных данных мгновенно "срезается" на каком-либо из неотключаемых ASSERT-ов,


Основная проблема ASSERT'а это не отключаемость/неотключаемость. Никто не мешает в том же C/C++ сделать его неотключаемым (достаточно ввести свой макрос). Проблема в том, чтобы заставить "теток" эти ASSERT'ы расставлять. Оберон/C/C++/C#/Java/Python здесь в абсолютно одинаковых позициях. А вот, например, Eiffel - дает фору.


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


Вот это не очень понял. В чем сложность "сложных динамических структур" для C++ (без сборки мусора)? И даже для C без плюсов? Только хотелось бы рассуждений не уровня "студентам придется изучить, что такое динамическая память и как с ней рабоать", а что-то более приближенное к программерской практике.


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


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


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


Что такое "система GUI-сообщений"?


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


Непонятно. Совсем. Почему оберон может быть полезен для обучения (вместо какого-нибудь древнего турбопаскаля или дельфи) - понятно. Даже могу предположить, что он может оказаться лучше для обучения, чем Java/C#.

С наступающим Новым Годом!
Всем здоровья, успехов, счастья!