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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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


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

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

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

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


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

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

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

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

<<<... | 4346—4337 | 4336—4327 | 4326—4317 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 193


№ 4336   23-04-2007 05:59 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4318« (Антон Григорьев)
___________________________

Есть языки, в которые на уровне либо самого языка, либо СТАНДРТНЫХ библиотек встроены средства создания распределённых приложений. Java, например, или C#.
Формально, стандартные библиотеки и в C#, и в Java как раз очень маленькие.


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

Подобные размышления наталкивают на мысль о выведении средств управления кластерами в отдельный язык (именно язык), в большей степени декларативного характера, который описывает "топологию", инварианты, отношения, состояния. Это в чем-то близко направлению constraint programming.

Еще один немаловажный момент в этой цепочке рассуждений. Кластер при работе с модулями должен оперировать не штатными интерфейсами (DEFINITION), а верифицирующими интерфейсами (INTERFACE). Соответственно их синтаксис/структура определяются языком кластеров (кластеризации модулей).


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

Исключение -- это сигнал об изменении состояния. Модули должны иметь соответствующую часть интерфейса (или отдельный, верифицирующий интерфейс, о котором уже говорилось), где декларируются имена допустимых исключений. Модуль может выдавать наружу (генерировать) только те исключения, которые заявлены в верифицирующем интерфейсе. Более того, каждая экспортируемая процедура (равно как и процедурная переменная) должна декларировать свое активное подмножество исключений. Это правило, которое можно отконтролировать.

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


№ 4333   23-04-2007 03:30 Ответить на это сообщение Ответить на это сообщение с цитированием
Еще одна уязвимость Оберонов. Для обеспечения надежности (операционной) нужна обработка исключений. Мой опыт в этой области показал, что:
1. Исключения строятся как программные прерывания с делегированием полномочий по принятию решения на верхние уровни контроля исключений.
2. Низкоуровневые исключения (внутренние) должны всегда ретранслироваться в высокоуровневые (внешние).
3. Нужны "саркофаги" ("поглотители" исключений с автономным принятием решения) разного уровня вложенности.

Чтобы не было терминологической путаницы: исключительная ситуация -- это ситуация (условие), при которой возникает/генерируется исключение (exception) явно (вручную) или косвенно (автоматически).

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

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

Для работы с исключениями достаточно следующих вещей:
1. Выделение блока контроля исключений (зона чувствительности на предмет генерирования)
2. Выделение блока обработки исключений (зона распознавания и реакции)
3. Распознавание (перехват) исключения
4. Генерирование исключения

Блоки контроля могут выравниваться на границу модулей/процедур/методов, тогда не требуется их отдельно помечать. Блоки обработки можно выносить на "теневой" уровень. Это позволяет для одного и того же исходного текста задавать разные схемы обработки исключений, подключая их динамически в зависимости от требований проекта и режима эксплуатации системы.


№ 4332   23-04-2007 03:10 Ответить на это сообщение Ответить на это сообщение с цитированием
>>> ...лебедь рвется в облака, рак пятится назад, а щука тянет в воду...
Есть определение лучше! Пришло приглашение на семинар ... прямо на злобу дня! :)

    "Персонал всегда чем-то занят. Он может быть перегружен, но при этом быть поразительно неэффективным! Почему? Обычно, нормальный персонал разгребает завалы, созданные особым видом сотрудников – «бобрами». По аналогии с особенностями поведения бобров в природе, "бобрами" в организации названы люди, посвятившие свою жизнь созданию завалов в любом виде деятельности, за которую они только берутся.
    Как же повысить эффективность существующих работников? Опыт показывает, что простое выявление и устранение из компании работников, создающих бардак и непродуктивность, само по себе повышает эффективность компании и оздоравливает внутреннюю атмосферу в коллективе. 
    Персонал не делает правильных вещей, просто потому что они правильные. Он делает их, потому что решает определенные задачи. Как эффективно помочь продуктивным работникам и заставить покинуть компанию скрытых «бобров» всех мастей – тема однодневного семинара «Как отстреливать «бобров в организациях»".


№ 4331   23-04-2007 02:44 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4324« (Сергей Перовский)
___________________________

Но такова уж судьба авторских языков: компактный с единой идеей синтаксис и бедный словарь. Разработка стандартных библиотек работа не для одиночек. И толпой энтузиастов их не создать, требуется некоторый комитет с серьезными ресурсами. Или крупная фирма.

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

1. Оберону/КП нет необходимости пытаться перестроить весь мир под себя. Надо пользовать то, что есть (как "ненадежный" сервисный уровень).
2. Фундамент унифицированной (стандартной) библиотеки и ее архитектура должны быть тщательно продуманы.
3. Не надо игнорировать другие миры. Оба распространенных подхода: независимое сосуществование языков с последующей попыткой их интеграции на уровне случайных контактов, либо единая платформа для всего на свете (.NET, читай ООН) -- уже показали свои проблемы. Имеет смысл продумывать долгосрочное тесное сотрудничество взаимодополняющих "стран" со своими экономиками (например, Оберон/КП-Erlang/Haskell). С организацией максимально удобной инфраструктуры такой интеграции.

Каждый уровень абстракции библиотеки оперирует своими сущностями и отношениями (внеязыковыми). Это задает свои требования к проектированию и реализации таких уровней (сколько их оптимально иметь, какие там должны быть сущности). Лично я категорический противник строить эти уровни исключительно через ООП. Должен быть разумный баланс, где использовать ООП, а где -- нет. Благо Оберон/КП это позволяют делать.


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

А перед этим он же отметил, что во вложенных модулях нет небходимости. ;-)

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

При этом исходит из того, что перед кластером стоят задачи:
1. Обеспечения высокоуровневой композиции модулей -- главных сущностей (в простейшем случае -- поименованный каркас-framework с ограничением прямых контактов на уровне модулей разных кластеров, соответственно, с иной трактовкой имен модулей/интерфейсов -- как "локальных" имен).
2. Предоставления средств контроля надежности (включая инварианты)
3. Обеспечения интерфейса для композиции с другими кластерами (но интерфейса иного плана, нежели DEFINITION). Этот интерфейс оперирует сущностями возможно иного порядка (не переменными, не константами, не типами, не процедурами языка Оберон, а например, состояниями и кое-чем еще).

Подобные размышления наталкивают на мысль о выведении средств управления кластерами в отдельный язык (именно язык), в большей степени декларативного характера, который описывает "топологию", инварианты, отношения, состояния. Это в чем-то близко направлению constraint programming.


№ 4329   23-04-2007 01:01 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4238« (AVC)
___________________________

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


№ 4328   23-04-2007 00:55 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4303« (MS)
___________________________
Конечность является формальным признаком алгоритма.

А почему же тогда проблема завершаемости - одна из центральных в теории алгоритмов?


№ 4327   23-04-2007 00:52 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4275« (Илья Ермаков)
___________________________
Насчет дженериков обсуждали много раз уже...
Легковесный полиморфизм не очень интересен ...
Полноценный параметрический полиморфизм полезен как раз для самых ценных штук - обобщенных алгоритмов, контейнеров и т.п., где он дает и обобщенность, и сохраняет высокое быстродействие

Мы тут пообсуждали, и я решил. :-)
"Легковесный" полиморфизм покрывает бОльшую часть того, что может предоставить параметрический полиморфизм.
"Полноценный" параметрический полиморфизм слишком тяжел и, собственно, не является параметрическим.


<<<... | 4346—4337 | 4336—4327 | 4326—4317 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 193


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

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

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

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

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

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