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

.. "А разве бывает так, что программное решение строится до построения полной модели?" - вот я и привел пример, что бывает...

Бывает, бывает...

В сущности, построение полной модели есть построение некоторой конструкции  (sorry за масло масляное) на некотором формальном языке. Язык ли это математики, или программирования -- уже следующий вопрос.

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

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

Вообще-то в Оберонах нет встроенной проверки предусловий, так же как и в С/С++, например.
Процедуру ASSERT можно использовать в любом языке.

Проверка предусловий/постусловий встроена в такие языки, как CLU, Eiffel...

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

Ответ на »сообщение 4711« (Илья Ермаков)
___________________________
Главное, я так и не могу понять, в чем противоречие. Почему ООП мешает использовать другие приемы? Обмен сообщениями, составные объекты и другие, рекламируемые Вами, приемы давно и успешно используются в рамках ООП. Я бы даже сказал, что они составляют неотъемлемую часть ООП. Поэтому их противопоставления я не понимаю.

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

Ответ на »сообщение 4709« (info21)
___________________________
>>>Похоже на догму.
Спасибо на добром слове :)
В другой ветке уже встречал такую формулировку.
Когда настаивал на том, что GoTo в Дельфи пользоваться нельзя.

Всех с праздником, коллеги!

Ответ на »сообщение 4711« (Илья Ермаков)
___________________________
>>>Тут приходится программистам становиться лингвистами
Ну это всегда полезно :)
>>>Каждый рабочий день - новая модель, новые прогонки.
>>>Строить жесткие иерархии некогда, ООП (как глобальный метод) отдыхает.
Однако, какие же они жесткие, если Вы их сами строите?
Пресловутая хрупкость может проявится только если иерархия строилась одними людьми, а надстраивается другими, причем для других задач. А если это Ваш инструмент, построеный Вами, то что в нем жесткого? В последних версиях Дельфи уделено много внимания автоматизации редактирования дерева наследования, но и без этого модификации занимали не слишком много времени.
Главное, я так и не могу понять, в чем противоречие. Почему ООП мешает использовать другие приемы? Обмен сообщениями, составные объекты и другие, рекламируемые Вами, приемы давно и успешно используются в рамках ООП. Я бы даже сказал, что они составляют неотъемлемую часть ООП. Поэтому их противопоставления я не понимаю.

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

Ответ на »сообщение 4705« (Илья Ермаков)
___________________________
>>>Сама система и является себе моделью, в которой заключены тысячи правил живой лингвистики...
И причем тут программирование? Опять таки программисты создали инструмент для лингвистов. Какой нужен инструмент можно понять и достаточно строго описать. А дальше дело за лингвистами. Конечно, если правила выражаются только алгоритмически, то скорее всего придется программировать и каждое отдельное правило. Но общий каркас будет сохраняться.
Неа, Сергей, тут разделение труда другое. Тут приходится программистам становиться лингвистами, слишком сложная логика...  Лингвисты носятся "на подхвате", консультируют, забивают словари и т.п.
Опять же, правила здесь - это не правила лингвистики как таковые. Это уже их интерпретация в свете "машинного понимания". Модель, естественно, строится до программирования - но мы никогда не можем сказать ничего о ее точности/применимости до тех пор, пока не закодируем и не испытаем. Иногда прямые, "строгие" решения показывают низкий КПД, приходится менять или вводить на ходу десятки корректив.

Речь не о том, чтобы программировать без модели, речь о том, что на одну модель, которая станет долговременной, придется десять, которые пойдут "в корзину". Каждый рабочий день - новая модель, новые прогонки.
Строить жесткие иерархии некогда, ООП (как глобальный метод) отдыхает.

Ответ на »сообщение 4699« (Сергей Губанов)
___________________________

Я Вас предупредил, что Вы неграмотно использовали термин, а дальше решайте сами.
По этому поводу может быть два мнения - моё и неправильное. :-)

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

Ответ на »сообщение 4705« (Илья Ермаков)
___________________________
>>>Сама система и является себе моделью, в которой заключены тысячи правил живой лингвистики...
И причем тут программирование? Опять таки программисты создали инструмент для лингвистов. Какой нужен инструмент можно понять и достаточно строго описать. А дальше дело за лингвистами. ...

И.Е. тут описывает любимой мною случай, когда теоретизирование и алгоримтическое экспериментирование разделить невозможно (во всяком случае, не получается).
А С.П. настаивает, что нужно подождать, пока разделят. Похоже на догму.

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

Ау-у-у! Дяденька, подменой тезиса не занимайтесь!
... РЕЧЬ НЕ ОБ ЭТОМ ШЛА...

Каждый спокойный читатель форума сумеет прочесть несколько последних постов и понять, кто подменяет тезисы.

ЕЩЁ РАЗ ПОВТОРЮСЬ: В ШКОЛЬНЫЕ МАССЫ МОЖЕТЕ ДВИГАТЬ ЧТО ВАШЕЙ ДУШЕ УГОДНО.

Спасибо.

Еще раз повториться = сказать то же самое в третий раз. Позвольте полюбопытствовать -- где Вы в первый-то раз это утверждали (уж не спрашиваю про второй)?

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

Ответ на »сообщение 4705« (Илья Ермаков)
___________________________
>>>Сама система и является себе моделью, в которой заключены тысячи правил живой лингвистики...
И причем тут программирование? Опять таки программисты создали инструмент для лингвистов. Какой нужен инструмент можно понять и достаточно строго описать. А дальше дело за лингвистами. Конечно, если правила выражаются только алгоритмически, то скорее всего придется программировать и каждое отдельное правило. Но общий каркас будет сохраняться. Или не будет, если первоначально программисты не сумели понять лингвистов.
Очень странно, что человек, профессионально занимающийся языком с встроенной проверкой предусловий, не считает необходимым "фиксировать предусловия" при постановке задачи.
Каждый программист знает правило "garbage in - garbage out", если на входе программы мусор, на выходе будет мусор. А если мусор на входе программиста?