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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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


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

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

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

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


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

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

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

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

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


№ 4326   22-04-2007 17:44 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4288« (AVC)
___________________________


Конечность является формальным признаком алгоритма.
http://ru.wikipedia.org/wiki/Алгоритм
Так что это просто ошибка. :)


Может лучше алгоритм рассматривать как чётко определйнную последовательность действий,
а систему через логику взаимодействия элементов?


№ 4325   22-04-2007 14:48 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4322« (Илья Ермаков)
___________________________

Другой вариант, даже более вероятный - не хотят использовать слишком высокоуровневое представление. Если по .NET-коду уже можно декомпилировать более-или менее читаемый исходник, то если ввести в представление еще больше семантики, то не станет ли это вообще как раз плюнуть? Для бизнес-технологий это ой как нехорошо. А для опенс-соурс - как раз даже наоборот :-)

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


№ 4324   22-04-2007 14:27 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4318« (Антон Григорьев)
___________________________
>>>Вообще, с этими стандартными библиотеками возникает интересный вопрос.
Совершенно верно: компактность синтаксиса замечательная вещь (до определенного придела), а компактность словаря большая беда.
Но такова уж судьба авторских языков: компактный с единой идеей синтаксис и бедный словарь. Разработка стандартных библиотек работа не для одиночек. И толпой энтузиастов их не создать, требуется некоторый комитет с серьезными ресурсами. Или крупная фирма.


№ 4323   22-04-2007 13:51 Ответить на это сообщение Ответить на это сообщение с цитированием
В отношении модульного программирования и его истоков есть довольно интересная информация.

В 1953-1954 гг. выдающий советский математик акад. Лев Витальевич Канторович (1912-1986), которому в 1975 г. была присуждена Нобелевская премия по экономике, высказал ряд идей, положивших начало крупноблочному программированию и т.н. деревьям Канторовича (внутреннее представление программы). Он ввел в рассмотрение составные данные как объект программы и определил понятие дескриптора ("маркер", определяющий способ доступа к компонентам динамического объекта). Предложил "геометрические операции" — правила композиции составных объектов из простых. Как отмечают А.П.Ершов и М.Р.Шура-Бура, "процесс выполнения программного комплекса, представляющего собой информационную сеть (схему) отдельных модулей, Л.В.Канторович рассматривал как функционирование некоторой сверхпрограммы, которая определяет выполнение модулей на основе анализа информационных и управляющих связей схемы. Многие положения крупноблочного программирования были позднее переоткрыты или заново осмыслены на более высоком уровне при разработке систем работы со структурными файлами и в том, что сейчас называют модульным программированием".


№ 4322   22-04-2007 13:34 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4314« (Mirage)
___________________________

Ответ на »сообщение 4312« (Илья Ермаков)
___________________________
то я к тому, что обратная совместимость не является причиной неиспользования Сановцами деревьев Франца. Интересно почему тогда не используют?

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

Ответ на »сообщение 4312« (Илья Ермаков)
___________________________
Это я к тому, что обратная совместимость не является причиной неиспользования Сановцами деревьев Франца. Интересно почему тогда не используют?

Шут их знает... Много причин может быть.
Изначально, когда Яву делали, не рискнули использовать чрезмерно новаторские концепции, предпочли попроще, но чтобы работало... В дальнейшем про это могли и просто забыть, а Франц сам не напоминал ясное дело :-)

Другой вариант, даже более вероятный - не хотят использовать слишком высокоуровневое представление. Если по .NET-коду уже можно декомпилировать более-или менее читаемый исходник, то если ввести в представление еще больше семантики, то не станет ли это вообще как раз плюнуть? Для бизнес-технологий это ой как нехорошо. А для опенс-соурс - как раз даже наоборот :-)


№ 4321   22-04-2007 13:32 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4318« (Антон Григорьев)
___________________________

В качестве достоинства Оберона нередко приводится то, что его полное описание занимает двадцать страниц против тысячи страниц описания C++.

С одной стороны, 16 страниц описания языка -- это достоинство. А с другой -- недостаток. Почему столь кратко Вирт излагает язык? Это отличительная черта европейской школы, традиций, которые были заложены Петером Науром. Описание Алгола-60 составляло именно 16 страниц. См. http://www.europrog.ru/book/alpn1963e.pdf

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

Чтобы въехать в Оберон, вообще говоря, нужно брать описание языка и изучать детально всю пятерку книг Вирта по Оберону -- это 65+442+338+179+131=1155 стр. Лучше брать Programming in Oberon и Compiler Construction. Многое будет понятно. Хотя то, что мы тут обсуждаем, Вы даже там не найдете. Нюансов немало. Простота обманчива.

Я уже отмечал, что Оберон в большей степени рассчитан на тех, кто готов самостоятельно разрабатывать (практически с нуля), а не комбинировать уже готовое. Это разная психология разработки.

Что касается библиотек -- да, это уязвимое место Оберонов. С ними наблюдается вполне объяснимая напряженка. Значит, есть над чем работать. Что же до их описания -- вряд ли разумно пытаться не глядя переводить на Оберон библиотеки других языков. Надо делать свои, проектируя их более компактно и продуманно, либо подключаясь к уже готовенькому.

Как я понял со слов Ильи, уже потихоньку назревает ревизия хозяйства BlackBox. Это сейчас, пожалуй, главный инструмент в Оберон-хозяйстве. И благоустройство его территории очень важно.


№ 4320   22-04-2007 13:10 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4316« (Руслан Богатырев)
___________________________

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

Ассемблер и Оберон
В принципе -- да, но ассемблер - не 3GL, потому его упоминать не стал.


Это я не в рамках диспута с Вами
Это я в целях более корректного отражения идей ASU :-)

»сообщение 4272« (ASU)
Да, как видите, и ассемблер ему в этом ничуть не уступает... следовательно, и ассемблер обладает средствами разработки систем... :)


№ 4319   22-04-2007 12:59 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4312« (Илья Ермаков)
___________________________

Нет, Франц в Sun вроде не работает - или уже работает? :-)

Вспоминается известный мультик: "Таити, Таити... Нас и тут неплохо кормят..." :) Он все там же, в Ирвайне, в Калифорнии. Он все гранты с американцев, с их Java заколачивает... Молодец, а чего это Европе раскошеливаться, когда можно за счет американцев? Его персональная страничка -- http://www.ics.uci.edu/~franz/

Там открыто публикует и финансовые детали по грантам. Впечатляет.

Маленькое экспресс-введение к подходу Франца тут: http://www.europrog.ru/qa141005.html


№ 4318   22-04-2007 12:58 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4315« (Стэн)
___________________________

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

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

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

Вообще, с этими стандартными библиотеками возникает интересный вопрос. В качестве достоинства Оберона нередко приводится то, что его полное описание занимает двадцать страниц против тысячи страниц описания C++. Да, но при этом в описание C++ входят многие вещи (например, исключения), которые в Обероне предлагается вынести в библиотеки. Я уж молчу о том, что описание C++ включает в себя и описание STL. Следовательно, чтобы программист на Обероне реально имел все те же средства, что и в C++ (именно имел готовые средства, а не принципиальную возможность их написать), он должен использовать дополнительные библиотеки. Пердположим, что эти библиотеки уже есть (стандартные или нет - не суть важно). Но тогда программисту придётся изучить не только описание самого языка, но и документацию на эти библиотеки. Сколько страниц это будет? Далеко не 20.

В общем, последний абзац - это не какая-то критика выбранного в Обероне подхода - вынесения необязательных сущностей из языка в библиотеки. Просто захотелось сказать, что отдельно взятый аргумент - сравнение объёмов описаний языков - становится некорректным, если забыть про размеры описаний библиотек.


№ 4317   22-04-2007 12:51 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4311« (Mirage)
___________________________

А может уже используются?

Кто использует, особо об этом не трепется :) В диссертации Франца была важная оговорка -- его подход не заточен конкретно под Оберон. Можно применять и для других языков. В принципе это и так очевидно.

На EuroProg в новых поступлениях выложен ряд весьма интересных материалов, имеющих отношение к данной дискуссии. Там же есть и работы по JIT -- редкая работа Esmertec (они в свое время ее изъяли быстрехонько со своего сайта) -- коротенький такой ликбез по подходам компиляции: Way Ahead of Time compilation (WAT), Ahead of Time compilation (AOT), Just in Time compilation (JIT) и Dynamic Adaptive Compilation (DAC). Там же интересная работа Кистлера и Франца 2003 г. Из нее понятно, куда движутся их идеи.


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


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

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

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

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

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

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