>>>я не вижу у него никаких преимуществ перед мэйнстримом в лице >>>Java/C#/Python/C++/C.
Особенно перед C/C++ :) Ну совсем никаких преимуществ.
Недавно на глаза попалась очередная книга на тему критики С/C++.
"Уэллин С. Как не надо программировать на C++,изд.«Питер»,2004".
Советую. И дело тут не в том, что в программах на C++ возможны коварные ошибки - их можно сделать на любом языке, это и так ясно. Проблема в том, что существенная часть этих ошибок на таких языках, как обероны, невозможна в принципе. Поэтому из Вашего мэйнстрима надо убрать хотя бы C/C++ (программировать на них просто опасно), Яву, потому что она виртуальная машина и сравнивать ее с нативным компилятором не корректно, Python тоже из другой области... Итого, в "сухом" остатке остается: C#. Вот этот язык и давайте сравнивать с Оберонами.

Ответ на »сообщение 1260« (Владимир Лось)
___________________________

Было бы очень интересно услышать мнение гуру по такому вопросу: "Чего в принципе не хватает Оберону2(КП)?". Без чего в сегодняшних реалиях никак нельзя? Если можно, то, пож-та, по пунктам. "п1. Не хватает того-то. Нужно для того-то и того. п2...." Спасибо.

Человечности (высокоуровности) ему не хватает. Исключительно императивный язык с нулевой декларативностью (даже перечислимым типом обделили). Я допускаю, что для этого  у Вирта были веские причины (легкость обучения, легкость динамического расширения, легкость создания компилятора), но эти причины, сами по себе, могут только оправдать его существование, но никак не помочь популярности (в качестве промышленного языка) в "сегодняшних реалиях". Возможно Оберон неплох в качестве языка для обучения (вон, Кнут вообще на асмо-подобном языке учит), возможно он неплох в качестве платформы для других языков (по аналогии с MSIL в .NET). Но в качестве ЯП повседневого использования профессиональными программистами, на котором руками пишут код - я не вижу у него никаких преимуществ перед мэйнстримом в лице Java/C#/Python/C++/C.

Исправление к »сообщение 1263« (Владимир Лось)
___________________________
ПОследние два слова (конкретных решений.) лучше вё же читать вот так:
частных решений.

Ответ на »сообщение 1261« (пачимучкин)
___________________________
"Чего в принципе не хватает Оберону2(КП)?". Без чего в сегодняшних реалиях никак нельзя? Если можно, то, пож-та, по пунктам. "п1. Не хватает того-то. Нужно для того-то и того. п2...." Спасибо.

ОБРАЗОВАННЫХ, ГРАМОТНЫХ ПРОГРАММИСТОВ.

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

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

Ответ на »сообщение 1261« (пачимучкин)
___________________________

Самое главное - денег!

Что бы проводить кучу рекламных акций и пиар-кампаний, создать моду на Обероны, развивать всякие библиотеки и среды типа BlackBox...

Ответ на »сообщение 1260« (Владимир Лось)
___________________________

Было бы очень интересно услышать мнение гуру по такому вопросу: "Чего в принципе не хватает Оберону2(КП)?". Без чего в сегодняшних реалиях никак нельзя? Если можно, то, пож-та, по пунктам. "п1. Не хватает того-то. Нужно для того-то и того. п2...." Спасибо.

Продолжение нытья...

Великое щастье для тех коллективов, что используют языки с явно выраженной записью графа зависимостей между текстуальными частями программы (одно из проявлений "модульностей"), состоит в том, что поддержка актуальности такой зависимости НЕ является организационной мерой, а сводится ВСЕГО ЛИШЬ к рутинной работе компилятора.
Это, казалось бы естественное (для "виртистов") положение вещей, в конторах, где пользуются "самым-самым" и не хотят "читать книжки" (в такой имею счастье работать и я), часто приводит к довольно громким конфликтам. Тоисть мы даже о make не хотим слышать, но хотим иметь сотни модулей в согласованном состоянии...
Причём, самое поразительное, что тыканье пальцем в первую же строчку сообщения той же Винды (типа Windows 2000 build 2195), ничего доказать не может. QNX – конечно же классная модульная система, где достигнут идеальный предел разделения и изоляции исполнимых сущностей, но КАКОЕ ЭТО ИМЕЕТ ОТНОШЕНИЕ К ЗАВСИСМОСТИ МОДУЛЕЙ (ПОДПРОЕКТОВ) В ПРОЕКТЕ??? Это как-то доходит со скрипом. Необходимость формализации таких отношений выродилось в твёрдое убеждение начальствующих лиц, что если я предоставляю сервисы в своём подпроекте и ими пользуется множество клиентов, то, в отсутствии средства реализации, прямо выражающего ("синтаксически") такую зависимость, я должен всех обзвонить/оббегать и предупредить, что у меня сделаны какие-то изменения... Больше всего меня поразила сама готовность превратить это чисто "конструкционное решение" в "чисто организационное": один из "миньеджеров" даже готов был "взять на себя эту ответственность". Дальше пошёл уже полный бред: договорились о форме документа, извещающего о сделанных изменениях и со списком потенциальных заинтересованных исполнителей... :о)))))) Маразм!
Корни у него растут из:
1) недоразвитости Си/Си++ как средства реализации для применения в действительно БОЛЬШИХ проектах (а не в отдельных приложениях).
2) необходимости наличия кроме чисто "внутриязыковых" средств для явного выражения и учёта зависимостей между "подпроектами" и внутри "подпроектов". Компенсируется внешними "примочками" в виде *make или средствами сред разработки. Однако не всегда есть комплексный подход в их использования (если вообще их используют).
3) непонимания самой проблемы комплексной поддержки процесса разработки и сопровождения БОЛЬШИХ программных проектов.

При всей миниатюрности оберонов – слава им за наличие минимально необходимых средств, помогающих избегать того маразма, в котором я варился и парился последние три недели!!!
Си/Си++ имеют свои вкусности, но, посмотрите на Си в Плане 9. Мэтры поняли его слабину в этой части и там нет уже #include "*.h-файл"! Вместо этого там - нормальное #import "*.lib-файл". А последний имеет другую, явно выраженную, форму зависимости от исходников и других объектников и библиотек для своего построения...

Добавление к »сообщение 1258« (Владимир Лось)
___________________________
... Хотя, с другой стороны, раз мы эти шарики в одной схеме поместили, - уже нашли критерий похожести: "относящиеся к рассматриваемой тематике" - уже первый шаг к упрощению... :о))))

Ответ на »сообщение 1250« (Как слышно? Приём!)
___________________________
Сложное - это где этих элементов и связей достаточно много.
Такие системы, не СЛОЖНЫЕ, а - БОЛЬШИЕ.
Количество элементов и связей между ними сложности не прибавляют, скорее - мороки и повышенное внимание к индексам в циклах... :о)
Сложность превносится РАЗНООБРАЗИЕМ типов элементов и связей.

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

Суперструны -- не теория, а quasi una phantasia. Как и С++.
Таких квази уна фантазий -- действительно, полная наука. Надо же людям ум показывать, а вперед науку толкнуть не очень-то... вот и сочиняют...

Я всегда говоря о теории суперструн убирал приставку "физическая", поскольку теория может считаться физической только если она описывает хотя бы одно физическое явление. А Вы пошли ещё дальше и убрали приставку "теория". И я не могу с Вами не согласиться! В самом деле, чтобы фантазия была теорией чего-то надо как минимум иметь это чего-то как предмет над которым строится эта теория... ;-)