Когда-то в мае я "заглянул" на RSDN и, возможно, частично ответственен за то, что разгорелась такая неожиданно долгая полемика вокруг Оберона.
Причина тому была простая: я взял описание Оберона, взял критическую статью Кернигана "Why Pascal is not my favorite language", затем сопоставил их. Выяснил, что критика Кернигана к Оберону уже неприменима.
Потом установил BlackBox и переписал на Обероне решение системы линейных уравнений методом Гаусса. Выяснилось, что, благодаря открытым массивам, решение для матриц разной размерности формулируется очень легко и без всяких "обходных маневров", в отличие от Си (где пришлось бы пользоваться макросами) и от Си++ (где пришлось бы вводить классы).
Об этом я и написал тогда.
Потом была критика, из которой я узнал, что (из современных языков с Си-подобным синтаксисом) С# (и, похоже, только он один) позволяет сформулировать этот алгоритм столь же элегантно. Я поблагодарил за ценную информацию и "отчалил" по своим делам.
Но вот сейчас заглянул на сайт и с удивлением вижу, что полемика продолжается (и даже с
участием тех же лиц).
Причины этого мне не очень понятны, но хочу предложить одну гипотезу: борьба идет между
сторонниками "многоязычных" систем и систем, основанных на "моноязыке".
Например, система UNIX — "многоязычная" (тут и Си, и Си++, и Shell, и AWK, и Perl, и прочая, прочая, прочая...). А вот виртовские системы Lilith и Ceres основаны на одном языке (Modula-2 и Oberon соответственно).
Что касается синтаксиса отдельных языков, то, например, шаблоны в Си++ и C# — тоже ведь
"языки в языке".
То, что многоязычие может быть принципиальной позицией можно вычитать из книги Кернигана и Пайка "Практика программирования", там достаточно говориться об использовании
специализированных нотаций.
Так как польза многоязычия видна каждому (удобство), то возникает вопрос: а есть ли польза в использовании одного языка?
Выскажу предположение, что есть, но проявляется она в основном на системном уровне.
Oberon позволяет решать именно системные задачи самыми простыми средствами.
Чтобы пользоваться выгодами компонентного программирования, здесь не нужно изучать талмуды с названиями вроде "Сущность COM" (!?). Достаточно просто импортировать модуль.
Для защиты адресного пространства процесса не нужно опираться на многомощные и чрезмерно
сложные операционные системы, ведь контроль индексов для массивов и "сборка мусора" для
указателей решают эту проблему.
Так что и виртовский подход имеет свои преимущества; особенно для создания надежных
автономных систем.
[поскипано злостно] AVC>Причины этого мне не очень понятны, но хочу предложить одну гипотезу: борьба идет между AVC>сторонниками "многоязычных" систем и систем, основанных на "моноязыке".
Твоя идея очень напоминает противостояние Sun(Java) vs. Microsft (C#? — .Net!):
Первая сказала — пишем один раз, выполняем где угодно, вторая же сказала, что: пишем на чём угодно, но всё будет замечательно друг с другом комбинироваться (компонентность?)
А "моноязычность" имхо — зло!
Ибо чем больше способов выразить то, что нужно реализовать тем лучше. И для каждой конкретной задачи будет выбран наиболее соответствующий, а не единственный (который далеко не обязательно лучший, а просто другого ничего нет )
Здравствуйте, AVC1, Вы писали:
AVC>Для защиты адресного пространства процесса не нужно опираться на многомощные и чрезмерно сложные операционные системы, ведь контроль индексов для массивов и "сборка мусора" для указателей решают эту проблему. Так что и виртовский подход имеет свои преимущества; особенно для создания надежных автономных систем.
Вот и я про тоже самое. В оберонистых операционках не нужны вирутальные адресные пространства для каждого отдельного процесса — вполне хватает всего одного адресного пространства. Это позволяет создавать очень эффективные системы (нет временного оверхеда связанного с переключением контекстов процессов в режим ядра (там все — в режиме ядра), нет оверхеда связанного с копированием данных из одного адресного пространства в другое). Например, в Aos BlueBottle время минимального системного вызова в 30 раз меньше аналогичного в Linux.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Вот и я про тоже самое. В оберонистых операционках не нужны вирутальные адресные пространства для каждого отдельного процесса — вполне хватает всего одного адресного пространства. Это позволяет создавать очень эффективные системы (нет временного оверхеда связанного с переключением контекстов процессов в режим ядра (там все — в режиме ядра), нет оверхеда связанного с копированием данных из одного адресного пространства в другое). Например, в Aos BlueBottle время минимального системного вызова в 30 раз меньше аналогичного в Linux.
Ну и что? Берём любую операционку без защиты памяти. Там тоже не будет оверхеда.
VxWorks, NevaOS, Win3.x, Win95
Здравствуйте, Курилка, Вы писали:
К>А "моноязычность" имхо — зло!
Мой вопрос в том и заключается: всегда ли "моноязычность" — зло?
Ведь и плюсы, кажется, тоже есть.
К>Ибо чем больше способов выразить то, что нужно реализовать тем лучше. И для каждой конкретной задачи будет выбран наиболее соответствующий, а не единственный (который далеко не обязательно лучший, а просто другого ничего нет )
Во многом согласен.
Но, с другой стороны, за каждым выразительным средством стоят затраты на его поддержку.
P.S. Прошу заранее прощения, если иногда не смогу отвечать вовремя. Сейчас у меня очень ограниченный доступ к Интернету.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Это классический пример выбора между надёжностью и призводительностью.
Если мы готовы абсолютно доверять виртуальной машине Оберона для
_данной_ аппаратной платформы — пожалуйста, имеем быструю систему. Если
такого доверия нет — априори систему разумно считать ненадёжной.
Другая крайность — микроядерные ОС, где в режиме ядра работает
минимально необходимое количество кода. Авария в драйвере файловой
системы, например, не будет фатальной (это отдельный процесс в
пользовательском режиме), но накладные расходы на системные вызовы могут
быть довольно высоки.
Сергей Губанов wrote:
> В оберонистых операционках не нужны вирутальные адресные пространства > для каждого отдельного процесса — вполне хватает всего одного > адресного пространства. Это позволяет создавать очень эффективные > системы (нет временного оверхеда связанного с переключением > контекстов процессов в режим ядра (там все — в режиме ядра), нет > оверхеда связанного с копированием данных из одного адресного > пространства в другое). Например, в > Aos BlueBottle время > минимального системного вызова в 30 раз меньше аналогичного в Linux.
Здравствуйте, AVC, Вы писали:
AVC>Здравствуйте, Курилка, Вы писали:
К>>А "моноязычность" имхо — зло!
AVC>Мой вопрос в том и заключается: всегда ли "моноязычность" — зло? AVC>Ведь и плюсы, кажется, тоже есть.
Приведи хоть 1 реальный плюс именно "моноязычности", плиз, а не просто плюс конкретного языка.
Здравствуйте, Курилка, Вы писали:
К>Приведи хоть 1 реальный плюс именно "моноязычности", плиз, а не просто плюс конкретного языка.
Чтобы не ходить далеко, возьмем Оберон-системы. Они основаны на одном хорошо продуманном языке системного программирования (Обероне), и именно потому более надежны и производительны.
Для меня это не праздный вопрос. В последнее время я в основном занимался автономными системами, а в последние два года — системами программирования для таких автономных систем (ассемблеры, компиляторы Си, отладчики).
Здесь важна именно простота и надежность всей системы в целом.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>Вот и я про тоже самое. В оберонистых операционках не нужны вирутальные адресные пространства для каждого отдельного процесса — вполне хватает всего одного адресного пространства. Это позволяет создавать очень эффективные системы (нет временного оверхеда связанного с переключением контекстов процессов в режим ядра (там все — в режиме ядра), нет оверхеда связанного с копированием данных из одного адресного пространства в другое). Например, в Aos BlueBottle время минимального системного вызова в 30 раз меньше аналогичного в Linux.
К>Ну и что? Берём любую операционку без защиты памяти. Там тоже не будет оверхеда. К>VxWorks, NevaOS, Win3.x, Win95
Не знаю насчет первых двух операционок, но в первых виндах, записав левые данные в левую область памяти я мог покалечить данные другого процесса, в итоге вся система могла упасть (что, в принципе, мы частенько и наблюдали). В BlueBottle же, благодаря тому, что язык Oberon не позволяет записать данные в чужую область памяти, от защиты памяти можно отказаться, тем самым съэкономив на переключении контекстов. Эта же идея, кстати, заложена и в процессорах Эльбрус. Только в BlueBottle защита сделана на уровне компилятора, а там — на уровне процессора.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Вот и я про тоже самое. В оберонистых операционках не нужны вирутальные адресные пространства для каждого отдельного процесса — вполне хватает всего одного адресного пространства. Это позволяет создавать очень эффективные системы (нет временного оверхеда связанного с переключением контекстов процессов в режим ядра (там все — в режиме ядра), нет оверхеда связанного с копированием данных из одного адресного пространства в другое). Например, в Aos BlueBottle время минимального системного вызова в 30 раз меньше аналогичного в Linux.
Думаю, что здесь мы во многом согласны.
Кстати, спасибо за информацию о BlueBottle.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, AVC, Вы писали:
AVC>Здравствуйте, Курилка, Вы писали:
К>>Приведи хоть 1 реальный плюс именно "моноязычности", плиз, а не просто плюс конкретного языка.
AVC>Чтобы не ходить далеко, возьмем Оберон-системы. Они основаны на одном хорошо продуманном языке системного программирования (Обероне), и именно потому более надежны и производительны. AVC>Для меня это не праздный вопрос. В последнее время я в основном занимался автономными системами, а в последние два года — системами программирования для таких автономных систем (ассемблеры, компиляторы Си, отладчики). AVC>Здесь важна именно простота и надежность всей системы в целом.
Не совсем уверен в справедливости приведённого тобой аргумента, да и не уверен, что Оберон — есть единственный язык дающий такие "гарантии", вопрост, имхо, заключается — в какие накладные расходы выльется реализация этого языка со всеми его замутками. Т.е. имеем по сути IL, т.е. систему аля .NET, но опять же — откуда тут ограничение на число языков, когда в том же .нете его НЕТ?
Т.е. имхо ты несправедливо перекладываешь ограничения, которые должны быть наложены на ОС на уровень языка, что есть несколько глупо (на мой скромный взгляд)
Здравствуйте, Kh_Oleg, Вы писали:
К>>Ну и что? Берём любую операционку без защиты памяти. Там тоже не будет оверхеда. К>>VxWorks, NevaOS, Win3.x, Win95
K_O>Не знаю насчет первых двух операционок, но в первых виндах, записав левые данные в левую область памяти я мог покалечить данные другого процесса, в итоге вся система могла упасть (что, в принципе, мы частенько и наблюдали). В BlueBottle же, благодаря тому, что язык Oberon не позволяет записать данные в чужую область памяти, от защиты памяти можно отказаться, тем самым съэкономив на переключении контекстов. Эта же идея, кстати, заложена и в процессорах Эльбрус. Только в BlueBottle защита сделана на уровне компилятора, а там — на уровне процессора.
В общем, ты прав: если компилятор гарантирует, что стрельбы по памяти не будет, то можно не тратиться на защиту памяти. В этом плане одноязыкие среды допускают ускорение.
Упомянутые VxWorks и NevaOS не навязывают язык разработки (первая — это пародия на *NIX, вторая — на MSDOS) и, в общем-то, могут быть смертельно ранены. Но поскольку они предназначены для встроенных систем, где что попало не запустят, то можно уж как следует отладить и забыть о проблемах.
Однако, кроме стрельбы, есть же уйма способов ввести систему в даун. Например, утечки памяти. (На всякий сборщик мусора найдутся способы).
И здесь изоляция процессов также спасает: замученный сервис можно прибить, перезапустить и продолжить. А если память выжрана на уровне системы — то увы.
Здравствуйте, Курилка, Вы писали:
К>Не совсем уверен в справедливости приведённого тобой аргумента, да и не уверен, что Оберон — есть единственный язык дающий такие "гарантии", вопрост, имхо, заключается — в какие накладные расходы выльется реализация этого языка со всеми его замутками. Т.е. имеем по сути IL, т.е. систему аля .NET, но опять же — откуда тут ограничение на число языков, когда в том же .нете его НЕТ?
К>Т.е. имхо ты несправедливо перекладываешь ограничения, которые должны быть наложены на ОС на уровень языка, что есть несколько глупо (на мой скромный взгляд)
Так ведь я и говорю о системах, основанных на одном языке.
Следовательно и ОС написана на этом самом языке, и представляет из себя всего-лишь набор модулей Оберона.
Почему это глупо, если иногда это дешевле, надежнее и производительнее?
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, Курилка, Вы писали:
К>Не совсем уверен в справедливости приведённого тобой аргумента, да и не уверен, что Оберон — есть единственный язык дающий такие "гарантии", вопрост, имхо, заключается — в какие накладные расходы выльется реализация этого языка со всеми его замутками. Т.е. имеем по сути IL, т.е. систему аля .NET, но опять же — откуда тут ограничение на число языков, когда в том же .нете его НЕТ?
А я знаю, как популяризировать Оберон: написать компилятор Oberon.Net
Здравствуйте, AVC, Вы писали:
AVC>Здравствуйте, Курилка, Вы писали:
К>>Не совсем уверен в справедливости приведённого тобой аргумента, да и не уверен, что Оберон — есть единственный язык дающий такие "гарантии", вопрост, имхо, заключается — в какие накладные расходы выльется реализация этого языка со всеми его замутками. Т.е. имеем по сути IL, т.е. систему аля .NET, но опять же — откуда тут ограничение на число языков, когда в том же .нете его НЕТ?
К>>Т.е. имхо ты несправедливо перекладываешь ограничения, которые должны быть наложены на ОС на уровень языка, что есть несколько глупо (на мой скромный взгляд)
AVC>Так ведь я и говорю о системах, основанных на одном языке. AVC>Следовательно и ОС написана на этом самом языке, и представляет из себя всего-лишь набор модулей Оберона. AVC>Почему это глупо, если иногда это дешевле, надежнее и производительнее?
Здравствуйте, kavlad, Вы писали:
K>Здравствуйте, Кодт, Вы писали:
К>>А я знаю, как популяризировать Оберон: написать компилятор Oberon.Net
K>Он уже есть.
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, Курилка, Вы писали:
К>>Не совсем уверен в справедливости приведённого тобой аргумента, да и не уверен, что Оберон — есть единственный язык дающий такие "гарантии", вопрост, имхо, заключается — в какие накладные расходы выльется реализация этого языка со всеми его замутками. Т.е. имеем по сути IL, т.е. систему аля .NET, но опять же — откуда тут ограничение на число языков, когда в том же .нете его НЕТ?
К>А я знаю, как популяризировать Оберон: написать компилятор Oberon.Net
Уже ActiveOberon называется. Но там есть один облом — нету перегрузки методов (функций, процедур). В итоге его расширили, чтобы он мог работать с .NET, но так убого:
System.Console.Write{System.String}("Hello, world!"); (*в фигурных скобках указана сигнатура перегруженного метода, чтобы компилятор знал, что вызывать*)
что работать с ним не хочется. На развалинах Оберона для .NET появился Zonnon. Но тот пока не может добраться до стадии релиза.
)
Перекуём баги на фичи!
ActiveOberon называется. Но там есть один облом — нету перегрузки методов (функций, процедур). В итоге его расширили, чтобы он мог работать с .NET, но так убого: