Rambler's Top100
"Knowledge itself is power"
F.Bacon
Поиск | Карта сайта | Помощь | О проекте | ТТХ  
 Базарная площадь
  
О разделе

Основная страница

Группы обсуждений


Тематический каталог обсуждений

Архив

 
 К н и г и
 
Книжная полка
 
 
Библиотека
 
  
  
 


Поиск
 
Поиск по КС
Поиск в статьях
Яndex© + Google©
Поиск книг

 
  
Тематический каталог
Все манускрипты

 
  
Карта VCL
ОШИБКИ
Сообщения системы

 
Форумы
 
Круглый стол
Новые вопросы

 
  
Базарная площадь
Городская площадь

 
   
С Л С

 
Летопись
 
Королевские Хроники
Рыцарский Зал
Глас народа!

 
  
ТТХ
Конкурсы
Королевская клюква

 
Разделы
 
Hello, World!
Лицей

Квинтана

 
  
Сокровищница
Подземелье Магов
Подводные камни
Свитки

 
  
Школа ОБЕРОНА

 
  
Арсенальная башня
Фолианты
Полигон

 
  
Книга Песка
Дальние земли

 
  
АРХИВЫ

 
 

Сейчас на сайте присутствуют:
 
  
 
Во Флориде и в Королевстве сейчас  15:33[Войти] | [Зарегистрироваться]
Обсуждение темы:
Оберон-технология: особенности и перспективы


Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение. 

Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру


Всего в теме 6256 сообщений

Добавить свое сообщение

Отслеживать это обсуждение

Обсуждение из раздела
Школа ОБЕРОНА

<<<... | 4156—4147 | 4146—4137 | 4136—4127 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 212


№ 4146   18-04-2007 16:24 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4143« (Jack Of Shadows)
___________________________

>>>Болото болтовни.

Заходите -- поквакаем. :)
 AVC


№ 4145   18-04-2007 16:04 Ответить на это сообщение Ответить на это сообщение с цитированием
Да, и еще...

Дабы поставить точку в "системности" импорта модулей.
Импорт в модульных языках может быть только иерархическим. Таким образом, вся статическая "связка" модулей образует дерево.
Рассматривайте всю цепь импорта от одного узла как систему. Срежьте этот узел - система распадется на подсистемы.
И наоборот.
У меня есть две подсистемы - сетевая с лицевым модулем Net и файловая с лицевым модулем Files.
Я создам новый модуль Server. В начале модуля Server я напишу IMPORT Net, Files.
В итоге я получаю новую систему более высокого уровня, в которую в качестве подсистем вошли Net и Files. А вся собственная логика системы "сервер" собрана в модуле Server.
Таким образом, импорт модулей куда как системен...
Каждый модуль в списке импорта - это подсистема данного модуля. Сам модуль включает в себя собственную логику новой надсистемы - и вместе со всем деревом импортированных модулей и образует эту новую надсистему.


№ 4144   18-04-2007 15:49 Ответить на это сообщение Ответить на это сообщение с цитированием
Что лучше - выдать личному составу автоматы с подствольными гранатометами, или не выдать их (хотя они есть на складе) под предлогом того, что "метать гранаты из автомата - глупость. Автомат - он и есть автомат... А для гранат существуют минометы".

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

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

Кому что... Я предпочитаю "идеальную пригонку" универсального, строгого языка - дешевке mainstream-калейдоскопа...


№ 4143   18-04-2007 15:26 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4141« (Илья Ермаков)
___________________________
Господа, вы уж меня извините, но появление ASU и его многословный поток сознания превратил эту ветку в очередные "Информационные Поля".
Последние несколько десятков постов я просто ниасилил. :))
Болото болтовни.


№ 4142   18-04-2007 15:16 Ответить на это сообщение Ответить на это сообщение с цитированием
Основными качествами системы, насколько я помню, является:
а) наличие четкой границы "система-окружение"
б) наличие внутренней структуры: подсистем и их связей
в) наличие собственной логики (система представляет собой нечто большее, чем сумма частей, что Вы справедливо все время подчеркиваете).

Пункт "наличие собственной логики" может, на самом деле, предполагать все, что угодно. Логика может концентрироваться на отдельном "объемлющем" уровне системы, а может - в ее внутренних связях. И связи эти могут быть как гибкими, так и жесткими. И инициироваться связи могут как централизованно, с "объемлющего" уровня, так и каждой подсистемой в отдельности. Самоорганизующиеся системы как раз-таки характеризуются тем, что связи инициируются отдельными элементами системы.

Есть отдельные системы a, b, c, d..., обладающие некотрыми интерфейсами. Они оказались вместе ("сумма") и по своей инициативе образовали взаимные связи. Каждая система знает, с кем взаимодействует. Однако именно в этих взаимодействиях и заключена логика системы, только в данном случае - не централизованная, а распределенная. Просто совокупность a, b, c, d не была системой. Совокупность a, b, c, d, образовавших между собой прямые связи и взаимодействие, уже дает систему, поскольку это нечто большее, чем просто сумма частей, обладающее качественными особенностями и новыми возможностями.

Теперь от 3GL...
Чем плохо введение в язык "системных" в Вашем понимании возможностей? Чем плохо, что программируя на Обероне, я несколько раз в день разбиваю с помощью модульной декомпозиции разрабатываемый сервис на отдельные "подсистемы", слои со строго специфицированными связями через "узкие горла"? Что вместо написания "монолита" я разбиваю на изолированные модули, связь между которыми выношу на отдельный уровень, уровень диспетчерских модулей - ну прямо "по ASU" :-)
Чем плохо, что каждый студент с самых первых занятий усваивает принципы таких архитектур?

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

Что лучше - выдать личному составу автоматы с подствольными гранатометами, или не выдать их (хотя они есть на складе) под предлогом того, что "метать гранаты из автомата - глупость. Автомат - он и есть автомат... А для гранат существуют минометы".


№ 4141   18-04-2007 14:41 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4132« (ASU)
___________________________


Еще раз... Система имеет свою собственную логику. Реализация этой логики происходит через посредство «слабых» связей. Нет «слабых» связей – нет логики; нет логики – нет системы... просто пазлы...

Прекрасно. Человеческий организм - тоже не система? Нет "слабых связей", нельзя отделить руки-ноги, а потом присоединить обратно? Потому что соседние клетки могут взаимодействовать между собой напрямую, в обход ЦНС?
Биосфера - тоже не система, потому что нельзя отдельно взятого зайца выкинуть в космос - он там помрет?


№ 4140   18-04-2007 09:27 Ответить на это сообщение Ответить на это сообщение с цитированием
Наткнулся в Интернете на статью Robert C. Martin "Design Principles and Design Patterns":
http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf
По-моему, хорошее и популярное изложение некоторых принципов объектно-ориентированного дизайна.
Некоторые принципы (OCP, DIP, ADP) очень близки Оберону.
 AVC


№ 4139   18-04-2007 09:02 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4096« (А.П.)
___________________________

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

Недостаточно. Здесь уже обсуждали пример олимпиадной задачки с последнего чемпионата мира ACM по программированию. Она была решена (вариант на КП) в виде программы (одного модуля).

Будьте так любезны, дайте ссылку


http://forum.oberoncore.ru/viewtopic.php?t=409
 AVC


№ 4138   18-04-2007 07:43 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4136« (MS)
___________________________

>>>Если я правильно понял ASU, интерфейс "вагончик--вагончик" относится к вагончикам и даёт состав, а "вагончик--рельсы" относится уже к составу (ну и его вырожденному случаю - одному вагночику) :-)

В любом случае, интерфейсов больше одного. :)
 AVC


№ 4137   18-04-2007 07:37 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4098« (Сергей Перовский)
___________________________

>>>Конвейер UNIXа и набор его утилит - простейший пример программной системы.

И хороший пример.
Оберон-система -- тоже простой пример программной системы.

UNIX основан на понятии процесса, инкапсулирующего все отведенные ему ресурсы.
Поэтому общение между процессами затруднено.
Т.к. процессы не могут общаться напрямую, то требуется специальная системная поддержка.
"Пайпы" -- один из способов организации общения процессов.
Оберон же построен на таких понятиях, как модуль и команда.
Модули могут общаться между собой через модульные интерфейсы.
Соответственно, совершенно необязательно прибегать к приемам, вызванными специфическим устройством UNIX.
 AVC


<<<... | 4156—4147 | 4146—4137 | 4136—4127 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 212


Добавить свое сообщение

Отслеживать это обсуждение

Дополнительная навигация:
Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру
  
Время на сайте: GMT минус 5 часов

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

Web hosting for this web site provided by DotNetPark (ASP.NET, SharePoint, MS SQL hosting)  
Software for IIS, Hyper-V, MS SQL. Tools for Windows server administrators. Server migration utilities  

 
© При использовании любых материалов «Королевства Delphi» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
Все используемые на сайте торговые марки являются собственностью их производителей.

Яндекс цитирования