Ответ на »сообщение 2810« (Антон Григорьев)
___________________________

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

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

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

Здесь м.б. обычный для процедур стимул: экономия сил.
Один раз написал фабричную процедуру, впоследствии остается только вызывать ее.

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

Ответ на »сообщение 2810« (Антон Григорьев)
___________________________

Тогда я вообще не понял, об чем речь.

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

а что есть модульное программирование?
http://www.europrog.ru/qa191005.html

Ответ на »сообщение 2810« (Антон Григорьев)
___________________________
надо не бездумно нажимать эти кнопки, а сесть и крепко задуматься - отчего вдруг такая ситуация возникла?

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

А вот с трудно и невозможно у оберона проблемы (впрочем также как и у его предка паскаля)
Очень легко на обероне и паскале (и на java и на сшарп) писать хреново. Горааздо легче чем писать хорошо.

Вы тут уже вступаете в дебри психолигии человека. А она никакого отношения к техническим характеристикам того или иного языка не имеет.

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

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

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

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

2. Есть начальство, которое проверяет качество кода и делает оргвыводы по результатам проверки.

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

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

У Плутарха есть хорошая история. Старик пришёл посмотреть на олимпиаду, но когда пришёл на стадион, там уже не осталось свободных мест. Он ходил по трибунам и просил уступить ему место, но никто не хотел уважить его старость. Но когда он подошёл к тому месту, где сидели спартанские юноши, они все сразу же вскочили, уступая ему свои места. И весь стадион, увидев это, зааплодировал спартанцам. Тогда старик воскликнул: "Горе Элладе! Ибо все эллины знают, как надо поступать, но поступают так только спартанцы!"

У нас ситуация, к сожалению, похожая: теоретически, как надо поступать, знают почти все... А толку? Мне несколько раз приходилось слышать от очень неглупых людей рассуждения такого рода: "Я -дцать лет уже программирую на Паскале. За всё это время мне ни разу не понадобилось использовать goto. Но если я встерчусь с ситуацией, где goto будет удобно, я его применю не задумываясь. И работы Дейкстры мне по боку - я не стану из-за какой-то академической теории осложнять себе жизнь". И даже не задумывается человек о том, что если многолетняя практика подтверждает правоту Дейкстры, то при встрече с ситуацией, где goto просто напрашивается, надо не бездумно нажимать эти кнопки, а сесть и крепко задуматься - отчего вдруг такая ситуация возникла?

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

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

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



а что есть модульное программирование?

Ответ на »сообщение 2790« (Денис Зайцев)
___________________________

И работали бы сейчас бухгалтеры по старинке, с помощью ручки, бумаги да калькулятора.

А может, так оно и лучше было бы?

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

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

Нету там никаких скрытых проблем.

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

Немотивированное утверждение. Причем неверное.