Ответ на »сообщение 1204« (Илья Ермаков)
___________________________
>>> В VCL для того, чтобы ввести в базовый класс некоторое новое свойство (например, alpha) требуется менять его интерфейс.
Я не могу сказать, что VCL идеально спроектирована. Разумеется, библиотека общего назначения всегда компромис. Но VCL спроектирована хорошо.
Мне никогда не требовалось добавлять свойства к TObject или к TList. Более того, я не могу себе такую ситуацию представить.
Системные абстракции такие, какие есть и надо ими пользоваться или писать свои.
Это ведь только вспомогательные инструменты.
В прикладных задачах это совсем не главное.
А вот возможность отобразить иерархию предметной области, это критически важно.
И отсутствие полноценного наследования с виртуальными функциями это существенно.

>>>Для нединамической среды это позволительно. Для динамических Оберонов - нет.
Вот с этого места поподробнее...
Что мы потеряли, понятно. А что приобрели взамен?
Возможность подгружать/выгружать модули по мере надобности? Я не уверен, что это так важно.

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

Ответ на »сообщение 1190« (Stargazer)

Не шибко хотел отвечать анониму... Да не сочтёт админ это за оффтоп, тему обещаю дальше не развивать :)

>Из личного - недавно дефрагментировал рабочий диск с NTFS. Ушло часов 5 времени - а работа стоит!

Почему стоит? Если у тебя такой эксклюзивный дефрагментатор, который останавливает работу, то проще скопировать все на другой винч, форматнуть, и скопировать обратно - времени меньше часа уйдет.

Ыгы, эксклюзив - от Мелкософта. Запускается с командной строки, в безопасном режиме - иначе дефрагментация оканчивается ничем. Совет про другой винт как бы не в струю, извините.

>Сразу вспомнилась OS/2 Warp 1995 года - с файловой системой HPFS, которой дефрагментация вообще не требовалась.

Человек, который изобретет ФС, не требующую дефрагментации, может смело расчитывать на Нобелевскую премию. А на сегодняшний момент заявления о таких ФС - не более чем маркетинговый PR.

*пожимает плечами
Я сидел на полуоси длительное время, так что сравнительный опыт имеется. На сегодняшний момент мы имеем то, что имеем, хотя могли иметь другое, и не обязательно хуже.

Ответ на »сообщение 1203« (Сергей Перовский)
___________________________
Сергей по поводу наследования и "опасного наворота"...
Я не против и за то, чтобы выражать отношения "род-вид" между абстракциями предметной области с помощью наследования.
Я против глубоких иерархий наследования в системных абстракциях - там они не нужны и вредны.
Предметные абстракции и абстракции архитектуры, как я считаю, ортогональны.
Первые диктуются реалиями ПрО, вторые - технической целесообразностью, принципами инженерии. Первые чаще привязаны к конкретному проекту, чем выносятся в повторно используемые библиотеки, задача динамической расширяемости предметной модели не стоит остро, обычно касается лишь добавления частных "артефактов". Вторые, напротив, должны легко эволюционировать, повторно использоваться, иметь множество разъемов для динамического расширения.
Отсюда различная роль ООП там и там. Прикладная роль ООП - выразить иерархии "род-вид" из ПрО. Системная роль ООП - обеспечить расширяемость без перекомпиляции и переписывания, дать асбтрактные разъемы для подключения конкретных реализаций. Отсюда и принятый стиль наследования - абстрактный интерфейс - скрытое конкретное расширение - конец иерархии наследования. Иногда два-три промежуточных типа в Framework'е присутствует (например, Views.View-Containers.Container-TextViews.View-закрытые конечные TextViews.StdView и другие реализации текста), но часто глубина иерархии = 2.
Использовать иной стиль наследования в системных задачах - значит, рушить расширяемость. Сравните VCL и BlackBox Framework по возможностям динамического расширения и интеграции. В VCL для того, чтобы ввести в базовый класс некоторое новое свойство (например, alpha) требуется менять его интерфейс, а значит - вынуждать перекомпилировать все клиентские модули при переходе на новую версию среды, что неоднократно было... Для нединамической среды это позволительно. Для динамических Оберонов - нет.

Ответ на »сообщение 1200« (Снегурочка)
___________________________
>>>Чем меньше будет технических наворотов в языке, тем проще сосредоточиться на сути вариантов и самой задачи.
Вот тут и возникает вопрос, который меня очень тревожит.
Что есть навороты, а что реально необходимый инструмент.
Применительно к теме это проблема наследования.
Сторонники Оберона считают это опасным наворотом.
Мне представляется, что это очень мощный инструмент анализа задачи.
Построение адекватного задаче дерева классов по сути и есть самая важная часть работы: нужно понять, из каких типов элементов состоит рассматриваемая система, что в них действительно общего и т.д.

>>>Программирование же по накатанным алгоритмам для проработанных задач мало чем отличается от задач покраски забора или замены дорожного покрытия. Для них сойдет практически что угодно.
Чем красить забор совсем не все равно. Хотя сойдет что угодно :)

Ответ на »сообщение 1201« (студентос)
___________________________

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

Я може чего не понимаю, но КП хорош в масштабных задачах. Чем задача масштабнее и сложнее в проектировании, тем больше выигрыш от его использования. Сравнивать на мелких проектах никакого проку. А сличать функциональные возможности двух языков вообще смысла нет. И какой Delphi брать? Если за критерий брать навороченность фишками, то КП тут не в лидерах. Компонентность и расширяемость - другое дело. Но Delphi задумывался не как язык, а как ответ Чемберлену - Visual Basic'у. Это среда, в которой язык играет вторичную роль.

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

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

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

Формулировка задачи, даже очень грамотная, не есть ее решение. Существует немало задач, где непонятно, как вообще подступиться к решению. Можно формулировать разные гипотезы-варианты; все они могут пойти на выброс. Можно подбирать для этих вариантов различные структуры и алгоритмы, пытаться строить модели, сопоставляя затем результаты. Наверное, делать это лучше не на естественном языке, а с применением языков программирования. Чем меньше будет технических наворотов в языке, тем проще сосредоточиться на сути вариантов и самой задачи. Чем быстрее можно преодолеть путь от идеи к действующей модели, тем для решения таких задач лучше.

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

Ответ на »сообщение 1197« (info21)
___________________________
>>>Да просто нет такого изложения ни на каком языке!

Не понял...
Пусть есть плохо осознанная задача. Ее изложение на некотором языке помогает ее осознать. Согласен.
Вот только требования к такому языку на мой взгляд сильно отличаются от требований к языку программирования. При недостаточной формализации помогает естественный язык, для высокого уровня формализации хорошо подходят различные математические языки.
Да, иногда хочется проверить правильность своих представлений на реализации.
Но тогда нужно буть готовым к тому, что это будет система на выброс.
Закладывать в идеологию программирование принцип "главное ввязаться в сражение", по моему неправильно. И затачивать под это инструмент тоже.

Ответ на »сообщение 1190« (Stargazer)

>Из личного - недавно дефрагментировал рабочий диск с NTFS. Ушло часов 5 времени - а работа стоит!

Почему стоит? Если у тебя такой эксклюзивный дефрагментатор, который останавливает работу, то проще скопировать все на другой винч, форматнуть, и скопировать обратно - времени меньше часа уйдет.

>Сразу вспомнилась OS/2 Warp 1995 года - с файловой системой HPFS, которой дефрагментация вообще не требовалась.

Человек, который изобретет ФС, не требующую дефрагментации, может смело расчитывать на Нобелевскую премию. А на сегодняшний момент заявления о таких ФС - не более чем маркетинговый PR.

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

Серьезно, не понимаю, чем изложение задачи на языке программирования помогает человеку ее осознать? Русского языка и математики не хватает?

Да просто нет такого изложения ни на каком языке!