Оберон-технология: особенности и перспективы |
Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение.
Всего в теме 6256 сообщений
Добавить свое сообщение
Отслеживать это обсуждение Обсуждение из раздела Школа ОБЕРОНА
№ 1126 27-11-2006 06:15 | |
Небольшое добавление к теме обсуждения.
Обсуждение безопасности и надежности языков и систем программирования - это "вечная" тема, в которой никого нельзя убедить или переубедить. Причина в человеческой психологии - одни любят свободу, другие ценят надежность. Представим себе два типа светофоров: один не запрещает идти на красный свет, другой закрывает турникет на время красного сигнала. Оба светофора включают красный. На первом стоит бабушка, она понимает, что опасно, но все равно идет на другую сторону, потому что она любит свободу (unsafe). На другом переходе тоже мальчик хочет перейти, но не может - переход заблокирован (Оберон?). Каждый из нас выберет из этих вариантов что-то свое, то, что ему больше по душе. Одни (которые любят свободу) выберут VB и C#. Другие (которые любят надежность) выберут Модулу и Оберон. И переубедить они друг друга не смогут никогда.
P.S.
Я вот только сейчас понял, почему мне так по душе строгая надежность Оберона? Я по натуре такой. Если на переходе горит красный и нет ни одной машины, я все равно буду ждать зеленый. Потому что такое правило.
№ 1125 27-11-2006 04:32 | |
Не могу удержаться еще от одного примера. Для экономии места приведу только суть проблемы. Был у меня когда-то случай с Javascript - сразу даже не понял в чем шутка юмора. В общем что-то считалось, а в итоге получалось, что 1+1 в квадрате равно 121 (это я просто для примера, конкретные вычисления уже не помню :)
Так вот текст функции.
function f1()
{
var x,y,z
x=prompt("Введите x","0")
y=prompt("Введите y","0")
z=Math.pow(x+y,2)
alert("x+y в квадрате =\n"+z)
}
Вроде все нормально. Кроме одного - язык небезопасный! Вводим два числа, потом вычисляем квадрат их суммы и, разумеется, получаем полный бред. Например, ввели две 1 и с помощью функции Math.pow получили квадрат их суммы 121 (!!!). И дело не в том, что специалисту сразу ясно, в чем тут фикус-пикус! А в том, что "неряшливость" по отношению к типам приводит к таким ситуациям, а язык даже не подозревает, что это не "мощная задумка" программиста, а просто глупая ошибка, забыли выполнить преобразование типов. Ни один "серьезный" компилятор не может пропускать такой ляп! А Javascript - "чего изволите?" Хотите сложить две единицы как строки, а результат возвести в квадрат как число с помощью математической функции? Пожалуйста! Никакого контроля за согласованием типов, полная демократия. А у меня в той ситуации человек (это был новичок в программировании, воспитанный на Бейсике - но разве это имеет значение?) 30 минут пытался понять в чем дело и чуть было не поверил, что 2 в квадрате равно 121 :))
№ 1124 27-11-2006 04:15 | |
Ответ на »сообщение 1120« (Img)
Я эту статью давно читал, но помню, что причина, кажется, связана с необходимостью полной квалификации имен в Оберонах и отсутствии такой необходимости в C#.
Не совсем так. Конечно если имена переменных писать не полностью квалифицируя их, то за это рано или поздно поплатишься. Но Свердлов указал не на эту "мелкую" неприятность, а на гораздо более серьёзную вещь - на фундаментальный изъян механизма пространств имён. Вспомните, что имя идентификатора у него было полностью квалифицировано: A.B.C.
№ 1123 27-11-2006 02:50 | |
Вот и я о том же!
Если компилятор пропустил в моем тексте ошибку, которую он ОБЯЗАН и МОЖЕТ (!) заметить на данном этапе, то мне после этого что угодно можно говорить о надежности этого языка и о миллионах программистов, которые его выбирают. С этим языком уже все ясно :)
№ 1122 27-11-2006 01:24 | |
Ответ на »сообщение 1121« (Илья Ермаков)
___________________________
По поводу ссылки - не раздел Документация, а раздел Статьи, прошу прощения.
№ 1121 27-11-2006 01:21 | |
Ответ на »сообщение 1120« (Img)
___________________________
Назову два важнных преимущества Оберона:
1) по сравнению с Явой и C# - наличие МОДУЛЬНОСТИ. Модуль - единое понятие: синтаксическая конструкция, единица инкапсуляции, компиляции, распространения и загрузки в память. Аналога модулям в непаскалевских языках нет. По поводу роли модульности и т.п. - спорить здесь не буду, все это давно перемусолено, если интересно - читайте мои статьи в разделе Документация на blackbox.metasystems.ru.
2) по сравнению с Явой - в Яве все объекты динамические, что дает большую нагрузку на диспетчер памяти и сборщик мусора. В Обероне многие механизмы сообщений построен на статических расширяемых записях, то есть, является объектно-ориентированным, хотя передача данных идет по ссылке через стек. В Яве аналогичная система сообщений будет пожирать динамической памяти в единицу времени немерянно...
По поводу Ada, парижского метро и т.п. - да, не все пишется на Обероне и Аде. Иногда используется Eiffel, иногда - специализированные языки повышенной надежности. В системах связи часто - Erlang, LISP и другие функциональные языки. C++ и C в этих отраслях к использованию в ряде стран законодательно запрещены.
Что тут спорить - есть отраслевые стандарты и традиции. В Штатах один из этих стандартов Ada. В Европе Оберон/Ada. У нас часто используется Модула-2/Паскаль, где вычислительная мощность позволяет, например, на спутниках и беспилотных самолетах. Да, в тех военных устройствах, где на отечественных кристалах особо не разгонишься, вынужденно используется ассемблер. Вынужденно...
По поводу влияния языка - еще раз повторюсь - язык дает совокупный эффект. Когда нет глупых ошибок, все внимание идет на логику. Поиск ошибок производится многократно быстрее, когда я уверен в языке. Когда язык поддерживает метаинформацию, я могу полностью увидеть состояние программы в момент срабатывания моего ASSERT'а, не лазая по окошкам Watch etc, а просто кликая мышкой по ссылкам...
Что тут спорить - кто не пробовал, тому и сказать нечего. Я работал и на С++ (3 года), и на Обероне (полтора года), и на обычной Дельфе (6 лет), и на Ada (совсем немного), и знаю, что говорю.
№ 1120 27-11-2006 00:59 | |
>>>Я имею в виду: отсуствие указателей, сборщик мусора
>>>и прочие подобные аргументы, почему "Оберон
>>>надёжнее C++". В Java и C# всё это есть.
Если уж сравнивать языки, то давайте сравнивать корректно.
Java - это виртуальная машина, C# и Оберон компиляторы, которые генерируют нативный код (C#, правда, работает через промежуточный код, но в итоге все-равно получаем код платформы). Поэтому Java в этой тройке "лишняя" - ее надо сравнивать с какой-нибудь другой виртуальной машиной.
Итак, что мы имеем в итоге?
Перед нами два "нативных" компилирующих языка, удовлетворяющих базовым требованиям безопасности программирования - C# и Оберон. Чья защита от ошибок программиста надежнее? Я бы так сформулировал задачу: есть ли ошибки, которые пропустит компилятор C#, но не пропустит компилятор Оберона? Или наоборот.
Вот тут и находится ответ на вопрос. Я не очень хорошо знаю C#, чтобы делать окончательные выводы, но статья Свердлова наводит на некоторые размышления. По крайней мере, это означает, что существует один тип ошибок, которые возможны в программе на C#, но невозможны на Оберонах. Я эту статью давно читал, но помню, что причина, кажется, связана с необходимостью полной квалификации имен в Оберонах и отсутствии такой необходимости в C#.
P.S.
А субъективное мнение такое - я примерно 2 года пишу на Компонентном Паскале и у меня еще не было ситуации, чтобы я не понял и не исправил допущенную ошибку в течение нескольких минут. Причем без отладчика - его просто нет :) И это мне очень нравится - очень надежный язык получился у господина Вирта.
№ 1119 27-11-2006 00:58 | |
AVC, info21:
Хочу развеять ваши заблуждения по поводу человека, подписывающегося здесь "гость". Вы слишком серьёзно относитесь к его вопросам - видимо, думаете, что этоому человеку действительно интересны ваши ответы. На самом деле вы столкнулись с банальным флеймогоном, которого интересует только сам процесс придирок к вашим словам. Здесь это пока не очень заметно, но в соседней ветке он лучше проявился - см. »сообщение 83 в теме №77 на БП« и далее. Можете почитать и сделать вывод, стоит ли отвечать такому.
№ 1118 27-11-2006 00:36 | |
Ответ на »сообщение 1116« (info21)
___________________________
Не понял про 90% -- Вы буквы считаете?
Не понял про буквы.
Я имею в виду: отсуствие указателей, сборщик мусора и прочие подобные аргументы, почему "Оберон надёжнее C++". В Java и C# всё это есть.
В оставшиеся 10% входят 1) большая разница в производительности 2) большая разница в сложности.
Достаточно произвольные утверждения.
И: Оберон - производительнее макроассемблера "Си"? Слабо верится.
№ 1117 27-11-2006 00:32 | |
Ответ на »сообщение 1115« (info21)
___________________________
Связанных с языком - возможно.
Но, как показывают данные, представленные AVC, язык влияет лишь на 30% ошибок.
70% ошибок не зависят от языка.
А поскольку Java и С#, пользуясь вашими критериями, "надёжнее" C++, то преимущество Оберона перед Java/C# - вообще несколько процентов.
Зато достигается ценой отказа от совместимости практически со всем.
К тому же, как я понимаю, о написании полноценных библиотек к Оберону речь только идёт (вы вроде с AVC это обсуждали).
Вы полагаете, алгоритмических ошибок в свежесозданной библиотеке будет меньше, чем в выстраданных годами в ведущих фирмах сильнейшими программистами?
Т.о. пока что речь идёт о том, что практическое повышение надёжности при использовании Оберона - мизерное (особенно по сравнению с Java/C#), а цена его - велика (отказ от совместимости с существующим ПО, изобретение велосипедов и т.п.).
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|