OberonCore

А что тут гадать?
В типовой реализации Оберона сравнительная эффективность "динамических" операций достигается за счет ассоциации типа с его уровнем расширения (0, 1, 2 и т.д.).
Это позволяет организовать массив type tags (включая как сам тип, так и всех его предков). Массив -- структура эффективная по определению. Достаточно произвести сравнение type tag с элементом массива с индексом, равным требуемому уровню расширения.
Интересно, имеет ли смысл пытаться критиковать это решение за "жесткость" привязки типа к его уровню расширения?

Это да, но, мне кажется, имеет смысл тестировать то что может быть реально использовано в реальных задачах. Типовой оберон непонятно где можно сейчас использовать.

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

Но мне сложно судить. Если Оберон (типовой) я хоть как-то щупал, то сингулярность не видел вообще. И сужу по ней только исходя из сообщений в обсуждении.

ЭТО - КАК?
Это - про ЧТО?
Странно!
Операционка на на нём написана (не одна). Самолётами-вертолётами - управляет. Среда разработки - на нём сделана. Пакеты стат обработки - есть. Компиляторы. И много чего ещё...
Так - чего вам надо?

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

Мне нужен готовый инструмент.

В каждом из перечисленных случаев, по всей видимости, отдельно писался/дорабатывался компилятор, писалась ОС (или не ОС, но специфический рантайм), затем уже писалась прикладная часть. Для меня лично это не приемлемо.

Возьмем простой пример -- squid. Можно ли его написать на Обероне? Теоретически, безусловно можно и возможно даже нужно (скажем eCAP отлично бы на Обероне можно было б реализовать, да и много чего ещё. Условную компиляцию частично можно было бы спокойно заменить динамической загрузкой-выгрузкой модулей). Практически -- нельзя. Т.е. нужен компилятор который бы компилировал для многих платформ (x64,x86, Sparc, Itanium, ARM, MIPS and so on) и многих ОС. + быть достаточно эффективным (рантайм должен быть не требовательным к объемам памяти, компилятор должен уметь оптимизировать код).

И таких проектов просто КУЧА. С какого боку там прикладыать Оберон?

Что понимать под виртуальностью!
В смысле - под способом выражения полиморфности...

Не занимайтесь домыслами, а читайте литературу! Просто возмутительное невежество!
На мой взгляд, на "раннем" Обероне сделано больше, чем на всех последующих вместе взятых...


Афигеть аргументация! "Лошарик не умеет делать Р-Р-Р-Р-Р-Р! Мы не будем с ним выступать!"
Для версии gcc 0.1 вы бы то же самое трындели в своё время?


С боку ПРОГРАММИРОВАНИЯ!... Вы - НЕ программист. Вы - сборщик. Фу!

Я уже называл один из примеров - задачи трансляции. При этом там вообще удобен "WITH в квадрате". С одной стороны, для того, что Geniepro назвал "сопоставление с образцом" - т.е. прохода и анализа динамических структур данных. С другой стороны, для передачи по этим структурам сообщений, которые они динамически разруливают по своим уровням. Этакое активное синтаксическое дерево, например. Части которого сами трансформируются в соответствии со спускающимися от корня сообщениями.

Разве нет других проектов, куда его можно приложить? Или вам они все непонятны?
Например, для написания GUI-приложений для Windows/Linux вполне можно использовать. Я недавно плагин для Notepad++ написал. Получил DLL, которую вызывает программа, написанная на C++. Никаких проблем.

А на разных диалектах фортнара сколько сделано... Ууу...
Но мы говорим о том что можно и нужно использовать сейчас.



Гм... А gcc -- это язык такой? Я что-то пропустил?
И, да, gcc 0.1 в качестве основного компилятора (для языка С) для серьезного проекта я бы использовать скорее всего не стал бы. По моему, это разумно.



Ну, во-первых я на личности вроде не переходил. И вроде бы не давал повода. А во-вторых, программирование давным давно превратилось в сборку нового из готовых кубиков. Кубики бывают разного размера и сложности. От машинных команд и операторов ЯВУ, до больших библиотек и компонент. Сюрприз?

Почему непонятны? Просто немного не по моему профилю работы. Впрочем, то о чем вы говорите (GUI для Windows/Linux) это то как раз очень интересно. Как раз один из моих проектов это настраиваемый GUI для скады. Посему вопрос: какой инструментарий (компилятор, библиотеки и проч) вы посоветуете для реализации такого проекта (нужна версия под Linux и Windows. Под Windows, в недалекой перспективе потребуется поддержка x64).

Ну тогда пишите перед своими словами: "В определённых кругах принято считать, что..."


Вот как раз и момент, когда мой совет применим! Смотрите, как красиво и стройно тогда получается:
"В определённых кругах принято считать, что программирование давным давно превратилось в сборку нового из готовых кубиков"
:о)


Сюрприз! Вы - счастливийший из программистов! Да что там из программистов? - Из всех людей на Земле! Наверное степень вашего счастья может сравнится только со счастьем школьного учителя физики второй трети 19-го столетия: всё уже открыто и остаётся только комбинаторно применять заученные правила!...
Что потом последовало в физике надо рассказывать?...

А что у скада-систем ненастраиваемый ГИП бывает??? :о)


Любые! В любом сочетании!
Какая разница, в чём вам определять внешний вид интерфейсов и мнемосхем и потом восстанавливать их из файлов определений, соединять это с контроллерами доступа к драйверам внешних устройств и датчиков и транслировать приходящие от них извещения и отправлять им же преобразованную реакцию оператора АРМ-а?

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


Сюрприз! Вы - счастливийший из программистов! Да что там из программистов? - Из всех людей на Земле! Наверное степень вашего счастья может сравнится только со счастьем школьного учителя физики второй трети 19-го столетия: всё уже открыто и остаётся только комбинаторно применять заученные правила!...
Что потом последовало в физике надо рассказывать?...[/quote]

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

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

Без перекомпиляции и перезагрузки приложения.


Восстанавливать чем? Контроллер доступа писан на чем? Или он нам даден свыше?

Вот есть некий компилятор некого языка + некие стандартные библиотеки (скажем stl для С++ и wxWidgets). Есть ОС (Windows & Linux). Больше нет ничего. Задача -- сделать вот такое вот, как описано вначале.

Тут очень хорошо бы подошел ББ, но под Linux его нет, увы. На сколько я понимаю, под x64 тоже нет, и, вроде бы, не предвидится.

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


Предпосылка... Вывод... Собирание из кубиков предполагает формирование структуры поддержки работы такого конгломерата. А это - уже программирование. Да и описанная вами ситуация - ой как далека от практических примеров из жизни! (Чур работу с юниксовыми программами, общающимися через каналы не приводить! Это - ИЗ ДРУГОЙ ОПЕРЫ! :о) )

Вы не волнуйтесь так, а то с квотами путаться начали! :о)


"Ой, боюсь-боюсь!"


Да хоть на бейсике! Вы - программист (как вы говорите!) и вы не сможете раскопать на вверенной вам платформе механизма и способов динамической связи с библиотеками и сделать на этой базе механизм плагинов для своего приложения и динамически подключаться к драйверам и не сформулируете интерфейс связи между драйвером и контроллером и контроллером и моделью и моделью и представлениями??? Которые, в свою очередь, могут также быть в виде плагинов и динамических библиотек?

Не нужен, а полезен. А полезен серьёзным упрощением структуры транслятора (расслоением и облегчением модификации) и вводом декларативности (так, что уже ни на какое ФП не облизываешься после ).

Info21, кстати, про эту методу (сильная динамика структур + гуляющие по ним сообщения) рассказывал применительно к задачам символьной алгебры. Чем и навёл меня на мысль использовать это в трансляции.

Вот именно. Свитч по типам, ИМХО, далеко не самый удачный способ выражения полиморфности (собственно это и не выражение в привычном декларативном смысле, это императив в чистом виде).