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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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


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

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

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

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


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

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

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

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

<<<... | 4376—4367 | 4366—4357 | 4356—4347 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 190


№ 4366   24-04-2007 04:36 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4355« (Руслан Богатырев)
___________________________
>>> Здесь нужно чувство меры: представители всех указанных выше профессий конечно могут общаться каждый на своем "птичьем" языке, но будет ли от этого толк? Нужно искать золотую середину -- минимизировать число языков (абстрактных слоев), понимая, что есть ключевая тройка "замысел --> проект --> строительство".
>>> Но при этом не стоит заниматься проработкой архитектуры, коммуникаций, проектных решений исключительно на языке программирования (который для этого не предназначен). Поверьте, этим занимались и занимаются не от хорошей жизни. Не надо язык программирования всячески расширять и дополнять в эту сторону -- у него свои функции -- регламентированная модель непосредственной работы с компьютером.
Вообще, будет хорошо, если они начнут нормально общаться между собой хотя бы на русском. Потому, что на нем можно объяснить все что угодно, что вообще можно объяснить.
У естественных языков грамматика, подчас проще, чем у формальных языков программирования, а семантическая емкость просто зашкаливает… А все потому, что семантика формальных языков вынесена на уровень грамматики, чтобы обеспечить однозначность передачи (так как CPU еще не научился мыслить).  Хотите обеспечить для них семантическую емкость сравнимую с естественными языками, не потеряв в однозначности – будьте добры построить грамматику соответствующего размера.
Вот языки и плодятся как кролики. Конечно, необходимо искать баланс между количеством классов решаемых задач и размером языков, на которых каждый класс задач описывается.

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

Правда, мы, похоже, немного не поняли друг друга… Я-то говорил, что не надо делить языки на те, с помощью которых разрабатываются модули и те, с помощью которых они объединяются в единое целое. Так как в объединяющий язык все равно придется внести большую часть понятийного аппарата.
Вот когда вы уже написали 100 exe-шников, запустили их на 1000 компьютеров по всему миру, объединили их в сеть и назвали это Системой. Вот тогда, управлять такой системой и конфигурировать такую систему на Обероне, а также C++ и Delphi /Pascal вряд ли стоит.  Потому, что эта система иного уровня с совершенно иным набором абстракций.


№ 4365   24-04-2007 04:32 Ответить на это сообщение Ответить на это сообщение с цитированием
>>> Среда -- это "судебная практика", причем ... как у нас

Спасибо. Смешное сравнение :)

Модули, которые не взаимодействуют в модульном языке - тоже.

>>> Да, можно и "Построение программных систем".
Да нет, это же только уровень 6 классификации Богатырёва.
Лучше так:
"Построение архитектуры систем из модулей без связей".
или точнее
"Помечтаем о застывшей музыке систем по Берталанфи".


№ 4364   24-04-2007 03:33 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4362« (Руслан Богатырев)
___________________________

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

Язык -- это "законодательная база". Любое его изменение -- это изменение законодательства, правил игры, необходимость пересмотра налаженных схем и решений, зависящих от "законодательной базы".

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

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


№ 4363   24-04-2007 03:31 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4360« (Руслан Богатырев)
___________________________
>>> Почему обязательно распределенных? Может быть, просто: "Построение программных систем" или "Конструирование программных систем"?
Да, можно и "Построение программных систем".
Но, на мой взгляд, термин "конструирование" лучше не использовать, так как его семнтика ближе к проектированию и подготовке... реализация и эксплуатация не менее важна.


№ 4362   24-04-2007 03:19 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4361« (MS)
___________________________


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

Ну если для Вас на уровне Оберон-модуля проблем нет, то попробую их сформулировать:
1. Есть группа взаимосвязанных модулей (подсистема, назовите хоть как). Эта взаимосвязь должна контролироваться как на этапе проектирования, так и на этапе выполнения (элементарная задача: выгрузить динамически все модули данной подсистемы и подгрузить -- если надо -- замену).
2. Реализован Оберон-модуль с некоторым интерфейсом. Возникает необходимость в создании его клонов (назовем, скажем, параметризацией заготовки). Как будем решать? Copy-paste?
3. Интерфейсы (модули) неравноправны -- есть публичные, есть служебные; есть проверенные (trusted), есть сырые; есть верифицируемые, есть бесконтрольные...

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

Чтобы понять границы/возможности/проблемы языка, достаточно прочитать и проанализировать в кабинетной тиши его формальное описание. Для системы требуется экспериментальный опыт: что и происходит на практике -- выпускается очередная версия системы программирования (IDE) и 1-2 месяца уходит на выявление ее особенностей (а будет ли она поддерживать тот парк наших программ и средств, что уже наработан, не возникает ли там новых проблем). А через полгодика -- новый релиз. И так непрерывно. Собственно, идея смещения акцента с языка в сторону среды -- это элементарная основа современной бизнес-модели выкачивания денег из населения. Чтобы выкачивать деньги, язык должен меняться (новые версии, новые стандарты), среда постоянно обновляться (иначе, при тиражируемом ПО и уровне пиратства -- кранты производителю) -- а вы, господа-программисты, тестируйте на собственном бизнесе очередную версию и восхищайтесь (или плюйтесь -- кому как карта ляжет)!


№ 4361   24-04-2007 02:58 Ответить на это сообщение Ответить на это сообщение с цитированием
По поводу языка для создания систем.

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

Программу, по хорошему, надо будет хранить в отдельном файле. Если это система Оберон или ББ, то этот файл будет начинатся со слова MODULE ...

ИНХО незачем городить таку городулю и стоит просто создать специальную визуальною среду, которая будет позволять строить кластеры и связи между ними с помощью хоть квадратиков, хоть в виде программы на неком спец языке, транслирую всё это затем в обероновский модуль (который особые экстремалы могут и ручками подправить :-)).

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


№ 4360   24-04-2007 02:56 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4357« (Стэн)
___________________________

Назовем её, например – «Построение распределенных систем».
Почему обязательно распределенных? Может быть, просто: "Построение программных систем" или "Конструирование программных систем"?


№ 4359   24-04-2007 02:54 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4329« (Trurl)
___________________________

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

>>>Руслан Богатырев, IMHO, правильно отметил отсутствие в Обероне более крупной конструкции, чем модуль, назвав ее "кластером"
А перед этим он же отметил, что во вложенных модулях нет небходимости. ;-)


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


№ 4358   24-04-2007 02:51 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4357« (Стэн)
___________________________
Не плохо было бы перенести туда сообщения начиная, например с № 4352, если движок форума позволяет?!


№ 4357   24-04-2007 02:49 Ответить на это сообщение Ответить на это сообщение с цитированием
Обращение!
Господа, может нам все-таки стоит создать новую тему? А то многие, действительно интересные вопросы, которые здесь поднимаются, имеют к Оберону очень отдаленное отношение.
Назовем её, например – «Построение распределенных систем».
Уважаемые модераторы, как вы на это смотрите?


<<<... | 4376—4367 | 4366—4357 | 4356—4347 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 190


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

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

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

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

Перейти на конкретную страницу по номеру
  
Время на сайте: 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» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
Все используемые на сайте торговые марки являются собственностью их производителей.

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