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

Вероятно, речь идет о прикладном (сложные задачи) и системном (сложные системы) программировании.

Классический Оберон -- язык программирования, который с одной стороны хорошо работает на уровне алгоритмических абстракций (в computer science), т.е. как алгоритмический язык (algorithmic language), а с другой -- является языком системного программирования, т.е. языком реализации (implementation language). КП -- язык в большей степени, чем Оберон, ориентированный на сферу программной инженерии (software engineering). Он вбирает в себя некоторые элементы проектирования.

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

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

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

Предполагаю, что большинство не знакомы с работой Дэвида Парнаса "Старение программного обеспечения" ("Software Aging", 1994). В ней достаточно убедительно показан тот феномен, как программа, будучи вроде бы математической абстракцией (которая должна оставаться справедливой и спустя 200 лет), тем не менее подвержена старению. Причины -- она живет в мире изменений. Старение, по словам Парнаса, может и будет возникать в любом успешном продукте. Это надо знать и, если требуется строить максимально адаптивную систему, закладывать данное знание в проект. Чтобы этого добиться (добавлю уже от себя), недостаточно только предусматривать вероятности возникновения различных классов изменений как на стадии  разработки продукта, так и в период его использования и развития. Важно выстраивать фундамент с возможностью расширения/коммутации и минимизацией зависимостей. Модульное программирование (вышедшее из модульного проектирования) как механизм разбиения большого на малое и как средство конкретизации функциональности (с целью последующего обобщения) обладает большей устойчивостью и гибкостью для подобных целей. ОО-проектирование (как механизм обобщения для последующей конкретизации) хорошо себя зарекомендовало в тех областях, где нет белых пятен и где фундамент можно строить надолго. Но таких сфер гораздо меньше, чем мы думаем.

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

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

>>>Вероятно, речь идет о прикладном (сложные задачи) и системном (сложные системы) программировании.

В то время как с точки зрения Оберона грань между ними стирается.

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

Ответ на »сообщение 2824« (Сергей Перовский)
___________________________

>>>... Я уже говорил, что Оберон заточен не под решение сложных задач, а под построение сложных программных систем. Это разные (хотя и пересекающиеся) области.

Хоть отношусь внимательно к Вашим постам, но этого пункта не понимаю.
Не поясните в  двух словах?

Вероятно, речь идет о прикладном (сложные задачи) и системном (сложные системы) программировании.

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

вообщем последнее время при чтении ветки складывается такое пессимистическое впечатление:

А Вы не ветку читайте -- тут много мусора и много людей, не понимающих систему образования в ее широте и глубине :))
Начните с основных текстов на Информатике-21 (август 2003, июнь 2005, октябрь 2006).

Ответ на »сообщение 2824« (Сергей Перовский)
___________________________

Я не понимаю, как подойти к такой задаче с позиций модульного программирования.

Грубо говоря, Вы хотите сказать, что будете держать все Ваши классы в одном модуле, и не видите н ужды разбить этот модуль на несколько?
Странно как-то.

Ответ на »сообщение 2824« (Сергей Перовский)
___________________________

... Я уже говорил, что Оберон заточен не под решение сложных задач, а под построение сложных программных систем. Это разные (хотя и пересекающиеся) области.


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

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

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

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

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

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

Это мое утверждение, основанное на лицейском опыте (австрийский доклад 2003 г.).
Только мы в лицее возились со списками, начиная с 9-го класса. Это разумно в общем физ-мат классе, если курс 8-го класса (первый год изучения информатики) потратить на самые первые основы.

Ответ на »сообщение 2833« (Сергей Перовский)
___________________________

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

Почему Вы не видите этой связи? :))

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

вот тут я и хотел услышать мнение Оберон-сообщества
на один конкретны вопрос
педвуз, подготовка учителей математики, доп специальность информатика

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

Исходя из своего опыта интенсивного общения с деятелями системы образования всего спектра за последние пять лет, ответы вполне очевидны:

Хороший основной курс должен быть на Компонентном Паскале (в Блэкбоксе). Это реально единственный вариант (ну нету других! хоть тресни, нету). Только так можно построить серьезный курс -- с серьезной перспективой, если говорить о применении этих знаний в школе.
С другими Оберонами возникнут проблемы в тот или иной момент, по разным причинам.

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