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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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


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

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

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

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


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

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

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

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

<<<... | 4036—4027 | 4026—4017 | 4016—4007 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 224


№ 4026   17-04-2007 05:26 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4020« (ASU)
___________________________
>>>Я не ругаю Оберон, как не ругаю и другие языки, но называть его системным – нонсенс.
Давайте, все таки вести дискуссию на русском языке, как прописано в правилах сайта :)
В русском языке термин "системное программирование" произошел не от филосовского или научного понятия "система", а от конкретного (и не очень удачного) термина "операционная система". Так уж получилось.
Я, например, хотел бы использовать термин "авторемонтник" для обозначения самовосстанавливающегося механизма. Но термин уже занят мужиком, ремонтирующим самобеглые повозки :(




№ 4025   17-04-2007 05:26 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4003« (ASU)
___________________________

Ответ на »сообщение 3997« (MS)
___________________________
ООП vs Модульное программирование?
С этим не ко мне... С моей точки зрения, есть четкая последовательность:
процедуры -> библиотеки -> модули -> объекты -> агрегаты -> системы...
и никаких "противоборств"...

Насколько принципиально наличие в этом ряду библиотек и объектов? И именно в этих местах?


№ 4024   17-04-2007 05:18 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4019« (Руслан Богатырев)
___________________________
>>>Тезис о квалифицирующем импорте был просто предлогом поговорить на тему системности в ветке по Оберонам.
Не надо так резко. Проблема на самом деле существует.
Оберон предполагает автоматическую сборку описания интерфейса по ГОТОВОЙ РЕАЛИЗАЦИИ - только звездочки поставить.
Тогда как описание интерфейса должно предшествовать разработке модуля.
Когда мы создаем аппаратуру с заданным интерфейсом, предполагается, что проведена работа по разработке интерфейса, он описан в некоторых документах до того, как начинается разработка конкретного железа.
Вы именуете эти стандарты протоколами, но термин интерфейс гораздо точнее отражает их смысл.
Посмотрите, например, спецификацию IDE. Там все, от протоколов до физических размеров. Полное описание интерфейса.

>>>Имеет смысл также понимать, что интерфейсы (межуровневые, межэлементные) той или иной реализуемой системы не обязаны отображаться один в один на интерфейсы Оберон-модулей, которые во избежание терминологической путаницы предлагаю называть спецификациями модулей (DEFINITION).
Отлично, избавились от терминологической путаницы. Теперь давайте определимся снова, имя ЧЕГО должно использоваться для квалификации импорта?
ASU считает, что это должно быть имя интерфейса, а не модуля, так получается гораздо  более гибко. Присоединяюсь.



№ 4023   17-04-2007 05:13 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4020« (ASU)
___________________________

Я не ругаю Оберон, как не ругаю и другие языки, но называть его системным – нонсенс.

Ну вот, грохнулся один тезис, вернулись к другому: "Оберон не является языком системного программирования". Как мы уже выяснили, системное программирование по ASU не имеет отношения к системному программированию (systems programming) в сфере программирования (а не общей теории систем, экономических и эволюционных теорий и т.п.).

Мной ранее утверждалось, что язык Оберон является языком системного программирования (systems programming) в понимании терминологии, принятой в области программирования (если будем придерживаться строгости и конкретики, то американской классификационной системы системы ACM -- computer science и software engineering).

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


№ 4022   17-04-2007 05:03 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4020« (ASU)
___________________________

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

Об экспорте и импорте интерфейсов.
И о том, что любой использованный внешний интерфейс нужно явно предварять его именем в каждом месте его использования в коде.


№ 4021   17-04-2007 05:01 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4020« (ASU)
___________________________

Ответ на »сообщение 4017« (Илья Ермаков)
___________________________
На всякий случай повторю, что Оберон для создания систем ничуть не лучше других языков, он развивает идеи Н. Вирта, но к системномк программированию не приблизился ни на йоту. Я не ругаю Оберон, как не ругаю и другие языки, но называть его системным – нонсенс.

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

По поводу создания систем... Для создания ПРОГРАММНЫХ систем Оберон лучше многих языков, потому что система состоит не только из связей сверхвысокого уровня (которые, как Вы справедливо заметили, строятся на надъязыковом уровне), но и из отдельных компонентов. Если некоторый язык позволяет реализовывать каждый компонент системы и каждую отдельную связь в ней лучше, чем многие другие, то и для создания систем он будет подходить лучше.
Попробуйте построить систему из элементов, которые сделаны внешне в полном соответствии с интерфейсами, но внутри нашпигованы ошибками. Как бы прекрасно не была продумана вся Ваша система в целом, но в один прекрасный момент она рухнет из ошибки в единственном гнилом компоненте, созданном единственным из многих разработчиков на конкретном гнилом языке программирования вроде того же Си...


№ 4020   17-04-2007 04:50 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4017« (Илья Ермаков)
___________________________
>> Увидели?.. О каком модуле Вы говорите?.. Нет еще никаких модулей, даже в проекте нет, а Вы уже что-то там импортируете... Откуда?..
> Если "никаких модулей" в проекте еще нет, то ничего вообще и не импортируем :-) И импорт Вам на этом этапе мешать не будет.

Совершенно верно...

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

А описание спецификаций ведется в разных модульных языках по-разному. В той же Аде мы пишем отдельную конструкцию package is ... end; помещаемую в отдельный файл ads (Ada Specification). Еще никакой реализацией (package body...) и в помине не пахнет, а мы уже можем компилировать спецификации, импортировать их друг другом - и тем самым проверять их совместимость и непротиворечивость.
Это очень полезно... на первых порах... по крайней мере. Потом понимаешь, что даже в больших системах интерфейсы крайне просты.

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

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

Нарушение? Не вижу... А где в этой схеме Оберон?..


№ 4019   17-04-2007 04:27 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4014« (ASU)
___________________________

Я не отрицаю полезность модулей, но для декларирования при моделировании мне никакие модули не нужны... Нужен инструмент, который проводит это описание через все стадии проектирования, разработки, тестирования и эксплуатации. Это не языковые (в смысле, не 3GL) средства, я об этом с самого начала говорил...

Ну вот, наконец-то проступает ясность. Тезис о квалифицирующем импорте был просто предлогом поговорить на тему системности в ветке по Оберонам. Офтопик под благовидным предлогом с недомолвками, интригами и попутными обвинениями.

Языки программирования (языковые средства) для системности в понимании ASU не нужны. Оберон, не-Оберон, какая разница. Речь с самого начала шла не о языке. Но те неязыковые средства, которые имеет в виду ASU, на чем-то в конечном счете реализуются. Их можно делать на Обероне (если нет -- с интересом выслушаю контраргументацию), на каком-то другом языке. Т.е. претензии к Оберону в этом контексте абсолютно надуманы и преследовали вполне понятную теперь цель.


№ 4018   17-04-2007 04:26 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4012« (Сергей Тарасов)
___________________________
я сторонник "сетевых структур с горизонтальными связями", а не корпораций. По жизни :) ИМХО, на таком уровне искусства декомпозиции личные пристрастия начинают накладывать отпечаток.
Не поверите... я тоже... за "сетевые" структуры. Все последние системы строил именно так: распределенные, слабосвязные, с произвольным числом подсистем. (И нет здесь никакого противоречия)...


№ 4017   17-04-2007 04:25 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4014« (ASU)
___________________________

Ответ на »сообщение 4005« (Илья Ермаков)
___________________________
Увидели?.. О каком модуле Вы говорите?.. Нет еще никаких модулей, даже в проекте нет, а Вы уже что-то там импортируете... Откуда?..

Если "никаких модулей" в проекте еще нет, то ничего вообще и не импортируем :-) И импорт Вам на этом этапе мешать не будет.

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

А описание спецификаций ведется в разных модульных языках по-разному. В той же Аде мы пишем отдельную конструкцию package is ... end; помещаемую в отдельный файл ads (Ada Specification). Еще никакой реализацией (package body...) и в помине не пахнет, а мы уже можем компилировать спецификации, импортировать их друг другом - и тем самым проверять их совместимость и непротиворечивость. А уже затем начинаем писать реализации в этим спецификациям. При этом элементы системы ничего не знают друг о друге, кроме того, что записано в спецификациях. В Обероне с целью минимализации отдельные файлы исходного кода спецификаций отсутствуют. На этапе специфицирования пишутся просто "заглушки", а двоичные файлы спецификаций создаются автоматически компилятором. Но разделение на спецификацию и реализацию от этого не исчезает.
Так где же в этой схеме нарушение любимого Вами системного подхода?


<<<... | 4036—4027 | 4026—4017 | 4016—4007 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 224


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

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

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

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

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

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