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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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


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

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

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

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


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

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

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

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

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


№ 4356   24-04-2007 02:33 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4354« (Stargazer)
___________________________
>>> По-вашему получается, что существуют такие задачи и такие сущности, которые на 3GL принципиально невыразимы?
Нет, дело в том, что всё, что можно заставить работать на компьютерах, можно написать не то, что на ASM, но в машинных кодах. Но управление памятью, например, в данном случае остается на вашей совести… любые ошибки и центральный процессор ни чем Вам не поможет… В тоже время в Оберон или в dot-NET берут эти вещи под свой контроль и гарантируют, что ничего ни куда не утечет…
Да, без проблем, на 3GL языках Вы можете написать распределенную систему в виде множества exe-шников, крутящихся на многих компьютеров, но семантика взаимодействия храниться в Вашей голове, и нет такого выполняющего устройства, которое бы брало на себя управление и гарантировало стабильность этой системы, и правильность взаимодействия частей в рамках этой системы.


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

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

С этим высказыванием трудно согласиться. И вот почему. Язык ориентирован в две стороны -- в сторону человека и в сторону машины (компилятора, другого языка, операционной прослойки и т.п.). Рассмотрим ту сторону, которая ориентирована на человека. Не слишком ли мы много (с подачи американцев) уделяем внимания компьютерам. Знаете, у Дейкстры по этому поводу была очень хорошая фраза: "Вычислительная наука имеет не большее отношение к компьютерам, чем астрономия -- к телескопам". Именно "вычислительная наука" (computing science), а не "компьютерная наука" (computer science) -- плод американского взгляда на программирование.

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

Упоощенное деление:
1. Аналитик (постановщик задачи)
2. Архитектор (главный архитектор проекта -- ГАП, chief software architect)
3. Инженер (главный инженер проекта -- ГИП, chief software engineer)
4. Проектировщик
5. Начальник участка (прораб, он же team leader)
6. Монтажник, электрик, отделочник (программисты)
7. Руководитель службы технического контроля (и сама служба, quality assurance)
8. Эксплуатанционщики

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

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

А что касается того, что все сведется к одному процессу в рамках конкретной ОС, так, например, нетрудно показать, что для программирования достаточно всего-то обычной спички -- они выкладываются друг к другу (головкой вверх -- "1", головка вниз -- "0") -- и готов (любой) алгоритм.


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


...
Вот она – задача системы! И dot-NET, стоящий на наших клиентских компьютерах, ничем не поможет, так как он ничего не знает о конфигурациях каналов связи, да и не должен знать. Это другой уровень, другие языки и другие системы.


По-вашему получается, что существуют такие задачи и такие сущности, которые на 3GL принципиально невыразимы?


№ 4353   24-04-2007 01:56 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4318« (Антон Григорьев)
___________________________

Ответ на »сообщение 4315« (Стэн)
___________________________

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

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

Антон, в свете сказанного мной до этого, выскажу следующее предположение. Да, действительно, для некоторого вида систем такие языки могут подходить лучше, чем другие, но принципиально это не спасает, и большие системы строить не помогает.
Рассмотрим пример:
Вы начальник какой-то вирусной лаборатории и у вас произошел инцидент с экспериментальным и очень опасным вирусом. Много народу заразилось и очень скоро погибнет, если быстро не сконструировать антивирус. Вы не знаете, как это сделать и связываетесь со мной, так как я очень крутой вирусолог и знаю все обо всем ;)  Но есть одна проблема – я живу уединенно далеко в горах, и единственная связь со мной – И-нет через спутник. И у меня и у Вас имеются приложения, которые обеспечивают видеоконференцию в реальном времени, написанные на C# + dot-NET. Ну и что? Самое узкое место – это канал связи. У нас экстренная ситуация и крайне желательно переконфигурировать спутники и роутеры так, чтобы на время обеспечить нашему трафику максимальный приоритет, потому что от этого зависят жизни многих людей.
Вот она – задача системы! И dot-NET, стоящий на наших клиентских компьютерах, ничем не поможет, так как он ничего не знает о конфигурациях каналов связи, да и не должен знать. Это другой уровень, другие языки и другие системы.


№ 4352   24-04-2007 01:34 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4345« (Сергей Перовский)
___________________________
>>> И я склонен принять его сторону: какой модуль должен реализовывать тот или иной интерфейс в конкретной системе, должно описываться в языке конструирования системы, а не в языке программирования.
Вы уж извините, я повторюсь. (»сообщение 4315«) О какой системе сейчас речь? Запуская Оберон-программу, да и любую другую, в Windows – мы получаем систему из одного приложения, что-то типа Excel. Это конечно система, но явно не того типа, о котором тут говорил ASU. И можно очень долго рассуждать о том, надо ли изобретать какой-либо язык для описания взаимодействия модулей или нет – это ничего принципиально не даст. Любое взаимодействие с удаленным сервером – и приехали. Весь протокол этого взаимодействия придется реализовывать руками в отдельно взятом модуле, и среда выполнения локального приложения ничем не поможет потому, что сервер не обязан быть написан на Обероне или dot-NET.

Однако все не так плохо! Главное, не начинать делить языки – на языки программирования, и языки конструирования систем, так как, как уже было выяснено, даже самая небольшая программа – система.
Начиная с ассемблеров и далее, так называемые языки программирования, были предназначены только для одного – написания управляющих программ для аппаратных процессоров. Потом появились виртуальные машины SmallTalk, Java, .NET и т.д., но всё осталось по-старому – выполняющее устройство и программа. Даже язык SQL, считающийся декларативным, и который многие любят противопоставлять таким «императивным» языкам как C++ и Pascal на самом деле ничем не отличается от них – на SQL мы тоже пишем управляющую программу, только исполняющее устройство имеет другую конструкцию, что и обуславливает столь сильные различия в языках.

Доказательство декларативности Pascal: На Pascal мы не описываем, как центральный процессор должен выполнять вычисления, т.е. когда и на какие линии должен подаваться тот или иной уровень напряжения, следовательно, Pascal – декларативный язык ;)

И переходя к построению больших систем, но не систем вообще, а распределенных  программно-аппаратных систем, мы можем посмотреть на эту задачу также: исполняющее устройство и язык. Только в данном случае понятие исполняющего устройства трансформируется в среду, распределенную между многими компьютерами, где каждый из них является командным блоком, также как блоки в процессоре.
И язык в данном случае – это такой же язык, как и языки 3GL, но, так как исполняющее устройство другое, он будет обладать иным синтаксисом и семантикой. И ни какое это не другое средство… все то же самое, просто это другой уровень.
И это совсем не должен быть скриптовый динамический язык. Он вполне может быть компилируемым со статической проверкой типов и т.д., просто типы и форматы выходных файлов будут отличаться от того, что мы видим в Pascal и C++.

PS: С созданием нового языка – 3GL никуда не денуться. Как драйверы писались на C или ASM, так и будут писаться, только эти языки останутся в той нише, для которой они предназначены, а не будут использоваться для всего подряд.


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

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

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


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

С ходу не найду, слишком много наворотили :) Поищу.
Он говорил о том, что для конструирования нужны другие средства, а не 3GL.  А в языке программирования средств межмодульного взаимодействия быть не должно. Так что притензии к языку были, но именно с позиций ДРУГОГО СРЕДСТВА(слово язык действительно, видимо, не употреблялось).


Убежден, что не найдете. Можете даже не тратить понапрасну время.

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


№ 4349   23-04-2007 15:55 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4347« (Руслан Богатырев)
___________________________
>>>в подтверждение того, что ASU говорил о языке конструирования и не предъявлял претензии к языку программирования -- ссылку в студию!
С ходу не найду, слишком много наворотили :) Поищу.
Он говорил о том, что для конструирования нужны другие средства, а не 3GL.  А в языке программирования средств межмодульного взаимодействия быть не должно. Так что притензии к языку были, но именно с позиций ДРУГОГО СРЕДСТВА(слово язык действительно, видимо, не употреблялось).


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

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

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


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

И я склонен принять его сторону: какой модуль должен реализовывать тот или иной интерфейс в конкретной системе, должно описываться в языке конструирования системы, а не в языке программирования.

Извините за требование конкретики, но в подтверждение того, что ASU говорил о языке конструирования и не предъявлял претензии к языку программирования -- ссылку в студию!


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


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

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

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

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

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

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