Оберон-технология: особенности и перспективы |
Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение.
Всего в теме 6256 сообщений
Добавить свое сообщение
Отслеживать это обсуждение Обсуждение из раздела Школа ОБЕРОНА
№ 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 в Хаскелле просто невозможен, вот и всё... А в остальном всё реализовано практически также, как и в Обероне.
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|