Оберон-технология: особенности и перспективы |
Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение.
Всего в теме 6256 сообщений
Добавить свое сообщение
Отслеживать это обсуждение Обсуждение из раздела Школа ОБЕРОНА
№ 2046 21-01-2007 08:18 | |
Ответ на »сообщение 2045« (Geniepro)
___________________________
Если Оберон не будет развиваться, то он безнадёжно устареет и потеряет актуальность...
Ради Бога, не надо развивать Оберон. Оставьте этот язык в покое! Если много нерастраченной энергии, лучше создавайте для него инфраструктуру. Или совершенствуйте тот же КП. Для него стабильность менее важна.
№ 2045 21-01-2007 07:02 | |
Снегурочка пишет:
Интересно, а с чем связано желание все "запихать" в один язык? Почему развитие мэйнстрим-языков идет именно по этому направлению безудержного "ожирения"? Казалось бы, есть "чистые" языки в каждой парадигме, так не лучше ли было бы добиться их полноценной интеграции?
AVC пишет:
Бедный Оберон!
Одни от него хотят, чтобы он непременно контролировал перечислимые типы и диапазоны, другие - чтобы он, напротив, сам выводил типы...
Как было сказано в "Алисе в Стране Чудес": Что бы удержаться на месте, нужно бежать вперёд изо всех сил! А иначе неизбежно отстанешь!
Если Оберон не будет развиваться, то он безнадёжно устареет и потеряет актуальность...
№ 2044 21-01-2007 05:53 | |
Ответ на »сообщение 2042« (Илья Ермаков)
___________________________
Также, мне кажется, для образования идеальна пара Оберон-Хаскель.
Очень разумная идея. И не только для задач education. Могла бы и несколько сплотить всех, кто активно участвует в обсуждении ФП и Оберона. Вместо того, чтобы попусту тратить время на бесконечные уколы, имело бы смысл заняться конструктивом.
Тем более, что уже есть полезный опыт. В Оксфордском университете, в вычислительной лаборатории (The Computing Laboratory), вотчине проф. Тони Хоара, Haskell является первым языком, с помощью которого студентам преподаются основы computer science. Вторым - Oberon-2 в OCaml-реализации.
* http://web.comlab.ox.ac.uk/oucl/prospective/ugrad/csatox/why_oxford.htm
* http://spivey.oriel.ox.ac.uk/mike/obc/
№ 2043 21-01-2007 04:17 | |
Ответ на »сообщение 2041« (Jack Of Shadows)
___________________________
В виртовском Паскале никогда не было слова class.
А сборщика мусора не было по чисто техническим причинам (наличие вариантных записей и отсутствие расширения типа). Уже в Algol-W сборка мусора предполагалась (не знаю точно, была ли она там реализована).
Так что Оберон воспринимается как вполне логичное развитие Паскаля.
№ 2042 21-01-2007 04:15 | |
Ответ на »сообщение 2037« (Geniepro)
___________________________
Как раз такой полиморфизм - с введением базового типа - в Обероне есть. Чего нет - так это принципа "пользовательские типы не отличаются от элементарных". Написать полиморфную процедуру для типов-записей ничего не стоит. Однако сделать ее полиморфной и для записей, и для элементарных типов нельзя, как нельзя перегрузить +. На практике это и требуется нечасто.
А вот дженерики - полиморфизм без общего базового типа - как раз-таки и интересны.
Спасибо за высокое доверие :-)
Развитие КП/ББ в России действительно во многом в руках нашей команды, "Метасистем", но с нами вместе над развитием ББ работают люди из русскоязычного сообщества из самых разных концов страны. А самым старожилом в ББ, без сомнения, является Info21.
По поводу ФП и КП - я периодически размышляю над этим вопросом. Я склоняюсь к тому, что стоило бы отработать интеграцию ББ- и Хаскель-приложений, лучше всего на каком-то конкретном проекте, где найдутся эффективные точки приложения и для того, и для другого. Также, мне кажется, для образования идеальна пара Оберон-Хаскель.
№ 2041 21-01-2007 04:09 | |
Ответ на »сообщение 2040« (AVC)
___________________________
Бедный паскаль. Одни хотят удалить из него слово класс. Другие - засунуть в него сбощик мусора :))
№ 2040 21-01-2007 04:07 | |
Ответ на »сообщение 2037« (Geniepro)
___________________________
Бедный Оберон!
Одни от него хотят, чтобы он непременно контролировал перечислимые типы и диапазоны, другие - чтобы он, напротив, сам выводил типы...
№ 2039 21-01-2007 04:06 | |
Ответ на »сообщение 2036« (Geniepro)
___________________________
В неё добавлены классы типов - своего рода абстрактные классы или интерфейсы.
Не совсем верно. Функции классов типов реализовываются в отличии от абстрактных классов и интерфейсов.
Скорее это ближе к traits.
№ 2038 21-01-2007 04:06 | |
Ответ на »сообщение 2036« (Geniepro)
___________________________
Да, эти механизмы потребуют изменения системы типов Оберона.
Интересно, а с чем связано желание все "запихать" в один язык? Почему развитие мэйнстрим-языков идет именно по этому направлению безудержного "ожирения"? Казалось бы, есть "чистые" языки в каждой парадигме, так не лучше ли было бы добиться их полноценной интеграции?
№ 2037 21-01-2007 03:07 | |
Ответ на »сообщение 2030« (Geniepro)
___________________________
Мой предыдущий пример (с map) не совсем ясно показывает мою мысль.
Что бы лучше представить себе полиморфизм в Хаскелле, разберём лучше такие функции, как inc и dec:
module Test where
import Complex
inc :: (Num a) => a -> a
dec :: (Num a) => a -> a
inc x = x + 1
dec x = x - 1
main = do print (inc 1) -- целочисленная единица
print (inc 1.0) -- вещественная единица
print (inc (1 :+ 1)) -- комплексное число 1 + 1i
Типы этих функций показывают, что они имеют параметр и результат одного и того же типа, причём тип этот является экземпляром класса типов Num.
Таким образом, эти функции можно использовать с любыми аргументами, типы которых являются потомками или экземплярами класса Num, будь то Int, Integer, Float, Double, да хоть Complex или пользовательские типы, включающие интерфейс класса Num, например вещественные числа с учётом погрешности расчётов...
В теле этих функций нет конкретных ограничений на набор операций над их аргументом - только операция сложения, имеющая одинаковую семантику для любых чисел. Так что конкретное устройство используемого числа в конкретном случае никого не волнует, главное что бы оно являлось числом, т.е. для него был реализован интерфейс работы с числами...
А константа 1 будет приведена к нужному типу компилятором в зависимости от контекста вызова этих функций...
Такой полиморфизм, я думаю, не отказался бы иметь ни один оберонщик...
И этот полиморфизм, имхо, нисколько не навязывает функциональный стиль, ведь он соответствует и настоящему ООП.
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|