Ответ на »сообщение 1728« (Снегурочка)
___________________________

Система мониторинга ГЭС - это конечно реальная задача, спору нет. Только сделана она не на обероне-1 и не на обероне-2 и даже не на компонентном паскале, а на блэкбоксе (ББ).
Как Вы думаете, можно ли такую систему сделать на Си? А почему, тогда, скажите на милость, ее НЕЛЬЗЯ сделать на Обероне-1? Нет, ну если мы начнем задаваться проблемами менеджмента и рассуждать о целесообразности выбора инструментария для данного проекта с учетом оптимизации стоимости, сроков и качества (наличия кадров, проблем сопровождения, интеграции и т.п.), то зайдем в сферы, имеющие отдаленное отношение к самим обсуждаемым языкам.


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



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


Описания языка и компилятора - мало. Какой бы крутой специалист ты не был, ты можешь не заметить подводных камней. Даже если с виду все хорошо, нужен, как минимум, опыт работы на этом языке. Success stories могут быть использованиы вместо этого опыта, когда нет возможности этот опыт приобрести. Так вот, в случае оберона я вижу, что в языке все не так хорошо даже без опыта работы на нем. А success stories могли бы как-то нивелировать такое впечатление.

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

Учить надо не столько простому, хотя это полезно, сколько строгому и показывающему базовые принципы программирования

Вот с этим согласен. Обучать надо не со сложного, а с простого. Но простое простому рознь (Бейсик vs. Оберон). Нужна целостность простого, которая дает важное качество, необходимое для познания программирования.

Чистота (purity) сама по себе дает целостность, но не дает простоты. Ибо это чистота воплощения определенных концепций (строгость, ничего наносного). А вот сочетание простоты (simplicity) и чистоты (purity) применительно к базовым вещам computer science (либо software engineering, если требуется именно инженерия) - гораздо полезнее.

Ключевая идея Вирта, воплощенная в Обероне: Оберон - это модули (module) + расширение типа (type extension). Все остальное (включая сборку мусора) вторично.

Ответ на »сообщение 1720« (Jean)
___________________________
Ответьте, pepper, если не трудно просто и честно (я в C# и Java не работаю, поэтому не в курсе дела):
При создании или работе проекта на C# или Яве я могу также, как в Блэкбоксе, изменять компоненты проекта динамически, без перекомпиляции и перелинковки всего проекта.


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


Например, изменить внешний вид визуальной формы, сохранить ее файл и после этого все будет работать и никакой перекомпиляции не потребуется?


Ну с формой (без кода) вообще просто - такое даже на дельфях делается.

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

Снегурочка - провокатор. :)

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

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

Снегурочка - провокатор. :)

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

Но, в свою очередь, опыт и навыки легче и быстрее сформировать на более простом языке.

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

С++ в качестве ПЕРВОГО языка, по моему мнению, это почти преступление.

Смотря кого учат, в каком объеме дают знания и на что ориентируют. Если человека готовят для программирования в софтверной компании (а не для программирования научных экспериментов или абстрактного изучения computer science в университете), то в чем преступление? Знания по C++ можно дозировать. Можно выстроить ровно то надмножество Си, которое вполне эффективно для решения конкретных практических задач в данной компании (или подобных компаниях).

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

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

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

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

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

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

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

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

У info21 оба этих пункта сочетаются

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

их задачи невозможно решать эффективно без ООП и модульности.

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