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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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


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

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

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

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


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

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

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

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

<<<... | 4276—4267 | 4266—4257 | 4256—4247 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 200


№ 4266   22-04-2007 04:08 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4264« (Сергей Перовский)
___________________________

Когда я утверждал, что ПРОГРАММУ удобно проектировать прямо на языке программирования, мне начинали объяснять про UML и прочие специальные инструменты.
Когда я говорю, что СИСТЕМУ неудобно проектировать прямо на языке программирования, мне говорят, что никакие дополнительные инструменты не нужны.
Ну куды бедному крестьянину податься :(


Для этого бедному крестьянину стоит призадуматься о применимости обоих подходов, выявляя контекст применения инструмента:
1. кустарное или промышленное производство ПО
2. условия исполнения проекта (требования, ресурсы, квалификация/опыт, сроки и т.п.)



№ 4265   22-04-2007 04:07 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4263« (Руслан Богатырев)
___________________________
>>>Она реализует простой алгоритм, но подпадает под Ваше определение отличия программы и системы и трактуется как система.
Процедура реализует алгоритм ввода символа.
А система поддерживает ввод с клавиатуры.


№ 4264   22-04-2007 04:01 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4258« (AVC)
___________________________
>>>...лебедь рвется в облака, рак пятится назад, а щука тянет в воду...
Самое забавное, что в различных ветках от одних и тех же людей можно получить противоположные возражения :)
Когда я утверждал, что ПРОГРАММУ удобно проектировать прямо на языке программирования, мне начинали объяснять про UML и прочие специальные инструменты.
Когда я говорю, что СИСТЕМУ неудобно проектировать прямо на языке программирования, мне говорят, что никакие дополнительные инструменты не нужны.
Ну куды бедному крестьянину податься :(


№ 4263   22-04-2007 03:59 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4262« (Сергей Перовский)
___________________________

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

Простой контрпример: я пишу процедуру P, которая считывает ввод одного символа с клавиатуры, вычисляет его код по таблице (допустим ASCII), отображает код в диапазон от 0 до 9 (операция MOD 10) и выводит на экран итоговую цифру. Эта процедура работает в бесконечном цикле и помещается в модуль M. Она реализует простой алгоритм, но подпадает под Ваше определение отличия программы и системы и трактуется как система.

Не в этом деле. Совсем не в этом.


№ 4262   22-04-2007 03:51 Ответить на это сообщение Ответить на это сообщение с цитированием
По поводу различия программ и систем можно, наверно, использовать понятие алгоритма: вспомните, что в самом определении алгоритма заложена конечность числа шагов до достижения результата. Так вот, программы и процедуры (подпрограммы) имеют алгоритм, а система нет - она реагирует на внешние события выполнением тех или иных алгоритмов, но ее "основной цикл", вообще говоря, бесконечен.


№ 4261   22-04-2007 03:48 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4256« (Сергей Перовский)
___________________________

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

Не поленитесь еще раз перечитать »сообщение 4173«, чтобы убедиться в том, что упрек в работе только на передачу, но не на прием (т.е. не слыша оппонентов) я уж никак не мог адресовать в адрес себя любимого.

Руслан, ситуация абсолютно симметричная, Ваши ответы тоже не о том :)

Безусловно. Я совершенно напрасно подробно объяснял (и все время не о том):
1. что такое квалифицирующий импорт в Обероне
2. что такое импорт вообще и чем принципиально отличается раздельная компиляция от независимой
3. что импорт в Оберонах реализуется исключительно через интерефейсы
4. что некорректно сопоставлять средства архитектуры (методологии) с реализацией (универсальным языком программирования), особенно тому, кто согласен с тезисом об инвариантности методологии относительно языка программирования.

Любая программная система состоит из элементов (сущностей). Между ними существуют отношения/связи. Отсутствие отношений -- это не система, а набор сущностей; поскольку понятие системы подразумевает как минимум взаимосвязь/взаимодействие сущностей. Каким бы ни был элемент системы, он должен взаимодействовать (находиться в отношении) с другими элементами (сущностями). Чтобы элемент "прикрепился" к слою, он должен предоставлять "разъемы" (считаем, что он ничегошеньки не знает о том, кто, когда и к чему его будет крепить). При этом есть три варианта:
1. "разъемами" являются любые внутренние сущности
2. "разъемы" строго регламентированы
3. элемент "присасывается" без "разъемов"

Случай 1 -- это отсутствие абстрагирования ("по-живому" без наркоза)
Случай 2 -- это наличие абстрагирования (интерфейс)
Случай 3 -- это вынесение описания отношений в отдельную область (но эти отношения все равно должны будут оперировать поименованными сущностями на другом уровне абстракции).

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

Оберон предлагает достаточно прозрачную схему:
1. Модуль -- это главная сущность для формирования элементов системы.
2. Интерфейс модуля -- это механизм абстрагирования (отделения внешнего представления от внутреннего).
3. Экспорт -- это отображение вида "модуль --> интерфейс"
4. Импорт -- это отображение вида "интерфейс --> модуль"
5. Межмодульные связи в языке выстраиваются через интерфейсы (и только через них). Они строятся на отношении импорта.
6. Межсущностные (межъэлементные) связи в языке регулируются как межмодульными связями, так и межклассовыми связями (отношения между расширяемыми типами-классами).

Язык Оберон де-факто создавался как язык реализации Oberon System (операционной системы).  Мне трудно себе представить какую-то программную систему, которая по своей архитектурно-инженерной сложности превосходила бы этот класс задач (ибо в ней все равно будет решаться задача обеспечения взаимодействия элементов, распределения ресурсов и управления применительно к исполнению на компьютере).

Можно рассуждать о том, подходит или нет язык Оберон/КП в качестве языка проектирования. Простите, а почему он должен обязательно подходить для целей, для которых не создавался? Проектируйте другими средствами, на других языках (не 3GL) и отображайте хошь на языки 3GL, хошь на операционные слои (выполненные в итоге на них же). Можно ли в принципе проектировать на сущностях и языковых средствах Оберона (модули, интерфейсы, экспорт-импорт)? Да, можно. У меня лично в этом сомнений нет.


№ 4260   21-04-2007 19:24 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4247« (Axcel)
___________________________

Раз уж зашел разговор о неких "надмодульных" средствах. Как известно в BlackBox есть удивительная вещь - "командеры". В настоящее время "язык" командеров крайне прост, но может быть это зародыш чего-то большего? А может быть, вместо командеров уместно использовать "нечто в функциональном стиле"?

Сомневаюсь насчет "функционального стиля", остальное -- верно.
Команды были в Оберон-системе изначально и являются одним из важных условий ее расширяемости.
IMHO, у Мессенбека была простая, но очень неплохая статья о расширяемости в Оберон-системе:
http://www.oberon2005.ru/paper/p_ext.pdf
В ней значительное место уделено командам.
Важно, что команды очень тесно интегрированы с модулями.
 AVC


№ 4259   21-04-2007 18:16 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4245« (ASU)
___________________________

>>>Когда я предлагал улучшать Оберон?.. Если вспомнить, то я ратовал за мультиязычность систем...

Мультиязычность систем может иметь один конкретный недостаток: недостаток надежности.
По крайней мере, раньше мультиязычность была основана на независимой компиляции и безразличии линкера к типам. Линкеру все едино: ЯВУ и ассемблер.
Раздельная компиляция надежна, но требует некоей единой основы: одного ЯВУ (оригинальная Оберон-система) или одного промежуточного языка (.NET).

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

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


№ 4258   21-04-2007 17:49 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4256« (Сергей Перовский)
___________________________

>>>Руслан Богатырев назвал режим общения полудуплексным, мол он чужое читает, а его ответы то ли не читают, то ли не понимают. Руслан, ситуация абсолютно симметричная, Ваши ответы тоже не о том :)

Ох, Сергей, все еще более симметрично... :)
Не помню как у Крылова. Примерно так:
...лебедь рвется в облака, рак пятится назад, а щука тянет в воду...
:)
 AVC


№ 4257   21-04-2007 17:39 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4241« (Geniepro)
___________________________

>>>И обобщённое программирование, и "кластерно-модульное программирование" вовсе не требуют расширения языка. С расширениями, конечно, удобнее и понадёжнее, но и без них можно.

Если не ошибаюсь, известно, что область применения ООП шире, нежели обобщенного программирования.
С помощью ООП всегда можно добиться того же, что и с шаблонами (конечно, иногда это может выглядеть несколько искусственно), обратное же неверно.
В принципе, шаблоны необязательны, но я к ним привык в Си++... :)
Что касается "кластеров" (Руслан Богатырев), то поддержка языка все-таки, наверное, желательна.
Я имею в виду (очень :) ) большие программные комплексы.

>>>Для обобщённых модулей/процедур/типов вполне можно приспособить какой-нибудь простейший препроцессор/макропроцессор, расширив его контролем типов/разрешений доступа и т.д.

В статье "Oberon vs. C++" (1994) Йозеф Темпл высказал ту же мысль:
In principle, a template preprocessor would also be possible for Oberon, however, as a separate tool.
http://www.oberon2005.ru/paper/p_obecpp.pdf (eng)
http://www.oberon2005.ru/paper/templ.pdf (рус)
Это возможно, но меня давно смущает, что была все-таки сделана попытка "внедрить" дженерики в Оберон.
Я имею в виду старую работу Роу и Шиперски о легковесном параметрическом полиморфизме для Оберона (примерно 1997).
 AVC


<<<... | 4276—4267 | 4266—4257 | 4256—4247 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 200


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

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

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

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

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

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