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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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


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

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

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

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


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

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

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

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

<<<... | 3226—3217 | 3216—3207 | 3206—3197 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 305


№ 3216   15-03-2007 17:05 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3193« (Илья Ермаков)
___________________________
>>>Я примеры с грузовиками тут приводил для чего - чтобы продемонстрировать нелогичность наследования реализации как факта... :-)
Пример нелогичного применения инструмента очень хорошо подходит для доказательства нелогичности инструмента :)
Прежде чем строить иерархию в которой появится грузовой автомобиль, необходимо ответить на ряд вопросов: для чего будем строить систему, какие задачи решать, каковы перспективы развития и т.д.
Объект "грузовик" из задачи оптимизации плана перевозок все равно невозможно использовать в задаче оптимизации переключения передач.
Нужно ли выделять двигатель и движитель в отдельные объекты, определяется характером задачи.
Мы опять с разных горок смотрим. Вы делаете нечто общеупотребительное, а я узкоспециализированное.
Делегирование вовсе не противоречит использованию наследования - это прекрасно совмещаемые приемы.

Музыкой навеяло(С)
При создании немецко-русского промышленного словаря переводчики столкнулись с удивительной проблемой: 5000 названий различных инструментов невозможно перевести на русский - не используются у  нас эти инструменты. Все больше топором :)
Иметь кем-то написанный модуль на каждый чих может быть удобно, но во первых нужно в этом море его найти, во вторых убедится, что он делает именно то, что нужно, в третьих оттестировать. Тут уже развивалась тема о Броуновском программировании. Чаще проще топором :) А если я делаю все на собственной платформе, то придерживаться стандартов лего и делать на всех деталях пупырышки мне нет необходимости.


№ 3215   15-03-2007 17:00 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3214« (Руслан Богатырев)
___________________________
Я надеюсь это интерлюдия, и код последует чуть попозже :))


№ 3214   15-03-2007 16:50 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3211« (Jack Of Shadows)
___________________________

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

Будем отрываться еще дальше. Пора переходить на язык раба Эзопа, того самого, который, получив свободу, отправился к Крезу, а тот послал его в Дельфы, где Эзопа обвинили в святотатстве и свергли со скалы. На тему модулей -- несколько анекдотов и высказываний.

Про модули и их неповоротливость.

Саперы ходят медленно, но лучше их не обгонять.



Про ненужность модулей.

Любой корабль может быть минным тральщиком. Один раз.



Про модули и namespaces:

Hепpавда, что женщины не могyт хpанить тайнy. Пpосто нyжно помнить, что это -- нелегкая задача, и женщины обычно спpавляются с ней коллективно.



Про жалкие модули и высокие материи мэйнстрима.

Жили-были мыши и все их обижали. Как-то пошли они к мудрому филину и говорят:
-- Мудрый филин, помоги советом. Все нас обижают, коты разные, совы. Что нам делать?
Филин подумал и говорит:
-- А вы станьте ёжиками. У ёжиков иголки, их никто не обижает.
Мыши обрадовались и побежали домой. Но по дороге одна мышка сказала:
-- Как же мы станем ёжиками? -- и все побежали обратно, чтобы задать
этот вопрос мудрому филину.
Прибежав, они спросили:
-- Мудрый филин, а как же мы станем ёжиками?
И ответил филин:
- Ребята, вы меня ерундой не грузите. Я стратегией занимаюсь.




№ 3213   15-03-2007 16:46 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3210« (Илья Ермаков)
___________________________

В модульной парадигме архитектура строится на основе отношений модулей.
Чего тут непонятного?

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

Так вот и непонятно.

Что есть модуль? По сути это единственный экземпляр финального класса, ни от кого не наследующего и никому не позволяющего себя унаследовать. Что, собственно, и представлено в так нелюбимых Вами языках семейства Си и в Эйффеле.

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

Если использование классов - объектно-ориентированное программирование, то использование модулей (без классов) - объектное программирование (был когда-то такой термин).


№ 3212   15-03-2007 16:22 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3208« (Руслан Богатырев)
___________________________

>> Так же как нет и промышленных чисто-императивных языков без элементов функционального программирования.

А что там в Си такого декларативного (помимо очевидных деклараций сущностей)? И что там за элементы ФП?

Ну как же? 8-о

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

Тернарная операция ?: - аналог выражения if-then-else из функциональных языков (не оператора, а именно выражения, возвращающего результат).

Урезанный pattern-matching с помощью оператора switсh (декларативный элемент).

Вот лямбда-абстракций нет, ну так ведь никто и не говорил, что Си - функциональный язык. Но элементы ФЯ имеет! :о))

Аналогично и Оберон (за исключением условной операции ?:)...


№ 3211   15-03-2007 16:19 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3209« (Руслан Богатырев)
___________________________
Мы хотим элементы конструктора, чтобы можно было отвинтить-привинтить, разобрать-собрать, вынуть-вставить, а нам в ответ -- тут только паспортный контроль: сверяем имена со списками, а мертвые души али живые -- какая разница, откуда прибыли -- тоже не колышет. Главное, виза есть -- проходи.
Руслан, ваши цветастые аллегории уж совсем оторваны от какого то бы ни было сравнительного анализа возможностей модульных систем оберона и скажем того же хаскеля.
Давайте поближе к телу.
Приведите пример кода, и что он дает в обероне, чего нельзя получить скажем в дельфи. А хаскель мы уж как нибудь присобачим для сравнения после вашего примера.
Там и поговорим про вынуть-вставить :))


№ 3210   15-03-2007 16:13 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3207« (Geniepro)
___________________________
Нет, я говорю именно не про разницу в реализации, а про разницу в использовании. У ФП есть набор своих рецептов для архитектуры ПО, модули там используются только в качестве элементов композиции.

В модульной парадигме проектирование архитектуры строится на отношениях между модулями. Т.е. для других парадигм тот же синтаксический модуль - это всего лишь модуль, он служит местом скалдывания других сущностей и ни в каких отношениях не участвует.

Естественно, модульная парадигма - это не просто наличие модулей. Это наличие развитых отношений, в которых участвуют модули. Ведь статический импорт модуля - это самое простое и банальное. Самые интересные связи строятся динамически, через различного рода коммутаторы, интерфейсы, шины... И здесь уйма приемов, которые и составили предмет этой ветки.
Что нового в модульное программирование принес Оберон? Такие же модули были в Модуле-2.
Так становление модуля как конструкции завершилось и уже давно.
А развитие модульного программирования идет, так развиваются принципы построения межмодульных отношений. Оберон включил в себя ООП и принес новый пакет приемов, уже с применением "объектно-ориентированных" межмодульных интерфейсов ("объектно-ориентированных" в техническом смысле, т.е. "поддерживающих дописывание новых расширений без переписывания существующего кода"). Ну и т.п.

В объектно-ориентированной парадигме архитектура строится на основе отношений классов (наследование, агрегация...).
В функциональной парадигме архитектура строится на основе отношений функций (вам виднее, какие они там бывают).
В модульной парадигме архитектура строится на основе отношений модулей.
Чего тут непонятного?

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


№ 3209   15-03-2007 16:10 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3207« (Geniepro)
___________________________

Для Хаскелла модули - всего лишь способ разграничить пространства имён и спрятать ненужные другим внутренние сущности. Те самые namespaces, только реализованные жёстко, как в Обероне, а не как в С++...

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

Мы тут заморачиваемся, а что будет, ежели модуль рановато выгрузили, а у них -- никаких проблем. Неча грузить. Мы тут боимся на родственные классы из разных модулей слишком сильно подуть, а им -- трын-трава. Мы тут рассусоливаем про динамическое связывание и коммутацию как важное средство расширения систем и их функционала, а у них модули с функциями без состояний и переменных вяжутся в динамике тока так. Аж завидки берут. Живут же люди!


№ 3208   15-03-2007 15:57 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3206« (Geniepro)
___________________________

Так же как нет и промышленных чисто-императивных языков без элементов функционального программирования.

А что там в Си такого декларативного (помимо очевидных деклараций сущностей)? И что там за элементы ФП?


№ 3207   15-03-2007 15:40 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3205« (Илья Ермаков)
___________________________

И модуль в Хаскеле и модуль в Обероне - это "две большие разницы". Потому что архитектурная нагрузка у них разная. Модуль же - это не просто единица упаковки функций и типов...

Мне кажется, Вы придаёте черезчур большое значение модульности.

Конечно, Хаскелл существенно отличается от Оберона. Потому и предназначение модулей в этих языках разное.

Для Хаскелла модули - всего лишь способ разграничить пространства имён и спрятать ненужные другим внутренние сущности. Те самые namespaces, только реализованные жёстко, как в Обероне, а не как в С++...

В Обероне же - ещё и способ хранения изменяемой информации, которая в Хаскелле на уровне модулей просто не существует. В Обероне модуль - по сути объект, как в Аде-83 (только урезанный).

Но разница эта всего лишь в назначении модулей, а не в их реализации. Да, в Хаскелле нет простого экспорта - весь экспорт только read-only, ну так экспорт read-write в Хаскелле просто невозможен, вот и всё... А в остальном всё реализовано практически также, как и в Обероне.


<<<... | 3226—3217 | 3216—3207 | 3206—3197 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 305


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

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

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

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

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

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