Здравствуйте, Курилка, Вы писали:
AVC>>Почему это глупо, если иногда это дешевле, надежнее и производительнее?
К>Когда это "иногда"? К>И чем это подтверждено?
Под "иногда" я имею в виду именно автономные системы.
Под "дешевле" — то, что Вирт на своем примере продемонстрировал как делать системы from scratch минимальными силами.
Под "надежнее" — тот факт, что чем проще базовые принципы и меньше лишнего кода, тем система надежнее.
Под "производительнее" — см. реплику Губанова о BlueBottle.
Кроме того, в книгах по теории компиляции прямым текстом говориться о преимуществе синтаксиса Модулы-2 для оптимизации кода: см. в "красном драконе" Ахо, Ульмана и Сети.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
СГ>Вот и я про тоже самое. В оберонистых операционках не нужны вирутальные адресные пространства для каждого отдельного процесса — вполне хватает всего одного адресного пространства. Это позволяет создавать очень эффективные системы (нет временного оверхеда связанного с переключением контекстов процессов в режим ядра (там все — в режиме ядра), нет оверхеда связанного с копированием данных из одного адресного пространства в другое). Например, в Aos BlueBottle время минимального системного вызова в 30 раз меньше аналогичного в Linux.
Интересно. То есть получается кооперативная многозадачность? А как решается подержка нескольких процессоров и распеределение процессорного времени?
Здравствуйте, FR, Вы писали:
FR>Интересно. То есть получается кооперативная многозадачность? А как решается подержка нескольких процессоров и распеределение процессорного времени?
Кооперативная/вытесняющая многозадачность и общее/раздельное адресное пространство — вещи пенпердикулярные.
Затраты времени на переключение потоков примерно одинаковы. Сделать вытесняющую из кооперативной можно, например, так: в обработчик прерывания таймера запихнуть вызов функции Sleep(0). (грубо говоря, конечно. На деле — чуть сложнее).
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, FR, Вы писали:
FR>>Интересно. То есть получается кооперативная многозадачность? А как решается подержка нескольких процессоров и распеределение процессорного времени?
К>Кооперативная/вытесняющая многозадачность и общее/раздельное адресное пространство — вещи пенпердикулярные.
Так тут раньше в других ветках проскакивало что в обероне как раз кооперативная, хотя может я не так понял, внимательно не читал.
К>Затраты времени на переключение потоков примерно одинаковы. Сделать вытесняющую из кооперативной можно, например, так: в обработчик прерывания таймера запихнуть вызов функции Sleep(0). (грубо говоря, конечно. На деле — чуть сложнее).
Если бы было так просто то кооперативных и не было бы
Здравствуйте, FR, Вы писали:
FR>Так тут раньше в других ветках проскакивало что в обероне как раз кооперативная
Обероны разные бывают. Оригинальный Оберон разработка которого началась в 1985 году может и был кооперативный я точно сам не знаю. А Aos BlueBottle (Active Object System) датируется что-то около 2000 — 2002 годами, впрочем разработка ведется по сей день (последняя версия от March 12, 2004)
Я так понимаю, в остальном возражений нет? Вот и AVC (думаю, много более
компетентный, чем я) пишет об "экологической нише" Оберона и других
подобных языков.
Возвращаясь к информатике-21, повторю своё мнение: школьникам Оберон как
_язык_ вполне подойдёт, но вот _конкретное исполнение_ BlackBox'а никуда
не годится. Почему — было сказано в изобилии.
Сергей Губанов wrote:
> TB> виртуальной машине Оберона > я бы заменил слово "виртуальный" на "runtime system"...
Здравствуйте, AVC1, Вы писали:
AVC>Причины этого мне не очень понятны, но хочу предложить одну гипотезу: борьба идет между AVC>сторонниками "многоязычных" систем и систем, основанных на "моноязыке". AVC>Например, система UNIX — "многоязычная" (тут и Си, и Си++, и Shell, и AWK, и Perl, и прочая, прочая, прочая...). А вот виртовские системы Lilith и Ceres основаны на одном языке (Modula-2 и Oberon соответственно).
[...] AVC>Так что и виртовский подход имеет свои преимущества; особенно для создания надежных AVC>автономных систем.
Кстати, шутки — шутками, наезды — наездами, а Оберон вполне может набрать популярность и "вес", особенно если Оберон-системы будут переносимы c .Net на Oberon-Native. Вот нам, кстати, и своего рода альтернатива .Net появляется. И это уже может быть оченно интересно.
В сущности, а в чём проблема-то? "Паскалистов" — вагон (на пост-советском пространстве, по крайней мере); слово Microsoft, ИМХО, в Европе скоро станет формой ругательства; синтаксис у Оберона простой; опять-таки, имя "Вирт" кое-что значит; с набором популярности Oberon и наработок под него появится тоже немало (в т.ч. — и раскраска синтаксиса ). Я, разумеется, могу ошибаться, но ИМХО, не так уж всё плохо для Оберона должно обстоять. А .Net... ну что .Net... платформа, как и другие.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>Вот и я про тоже самое. В оберонистых операционках не нужны вирутальные адресные пространства для каждого отдельного процесса — вполне хватает всего одного адресного пространства. Это позволяет создавать очень эффективные системы (нет временного оверхеда связанного с переключением контекстов процессов в режим ядра (там все — в режиме ядра), нет оверхеда связанного с копированием данных из одного адресного пространства в другое). Например, в Aos BlueBottle время минимального системного вызова в 30 раз меньше аналогичного в Linux.
FR>Интересно. То есть получается кооперативная многозадачность? А как решается подержка нескольких процессоров и распеределение процессорного времени?
A possible solution is to require computationally intensive active objects
to release the processor voluntarily by calling a runtime procedure
from time to time. However, this solution is not satisfactory; experience
with tasks in Oberon have shown that this is difficult to coordinate, especially
when active objects make use of other objects to perform their
work. It can also be inefficient, as releasing the processor too often
causes unnecessary overhead, and releasing it too seldom restricts the
progress of other active objects.
A better solution is to use time-slicing, i.e., let the system automatically
preempt long-running processes by setting a timer to interrupt
them. In this way the system is in control of the frequency of process
switches and the active object programmer does not have to worry
about releasing the processor.
To make the Aos runtime system viable for realtime environments
and responsive in interactive use, a facility must be provided to allow
more important processes to run before less important ones. Therefore
the assignment of relative priorities to processes is foreseen. At any
time, the processes executing will have a priority not lower than that of
all other runnable processes.
There are basically two approaches to scheduling multiple processors:
either each processor is responsible for its own scheduling, or one
processor is responsible for scheduling on all the processors [112]. The
first approach is preferred for its simplicity, symmetry and scalability.
Цит. по: "The Active Object System Design and Multiprocessor Implementation" (она же — PieterMuller.pdf), chapter 4. Active object runtime design, pp 35-36. Жирным я выделил то, что относится непосредственно к твоему вопросу.
Так что, там вытесняющая многозадачность. Притом планировщик вешается на каждый процессор свой собственный.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Кстати, шутки — шутками, наезды — наездами, а Оберон вполне может набрать популярность и "вес", особенно если Оберон-системы будут переносимы c .Net на Oberon-Native. Вот нам, кстати, и своего рода альтернатива .Net появляется. И это уже может быть оченно интересно.
ГВ>В сущности, а в чём проблема-то? "Паскалистов" — вагон (на пост-советском пространстве, по крайней мере); слово Microsoft, ИМХО, в Европе скоро станет формой ругательства; синтаксис у Оберона простой; опять-таки, имя "Вирт" кое-что значит; с набором популярности Oberon и наработок под него появится тоже немало (в т.ч. — и раскраска синтаксиса ). Я, разумеется, могу ошибаться, но ИМХО, не так уж всё плохо для Оберона должно обстоять. А .Net... ну что .Net... платформа, как и другие.
"Васюки переименовываются в Нью-Моска, а Москва — в Старые Васюки" (С) Ильф и Петров
Здравствуйте, TheBeard, Вы писали:
TB>Я так понимаю, в остальном возражений нет? Вот и AVC пишет об "экологической нише" Оберона и других подобных языков.
Думаю, что на этом можно остановиться: у Оберона есть своя "экологическая ниша".
У меня нет цели "рекламировать" Оберон. Я также ценю и другие концептуально целостные системы и языки: UNIX или даже Форт. (Вот только что напомнили о Прологе.)
Но, основываясь на опыте Оберона, хочу сформулировать один тезис.
Разумные ограничения повышают качество ПО: делают его более простым, надежным и эффективным.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, AVC, Вы писали:
AVC>Разумные ограничения повышают качество ПО: делают его более простым, надежным и эффективным.
В том, то и дело, что именно разумные, а не "святые" ограничения, написанные непререкаемым Виртом, как тут Сергей вещает.
(прошу не принимать близко к сердцу, но у меня именно такое впечатление складывается )
Здравствуйте, Курилка, Вы писали:
К>В том, то и дело, что именно разумные, а не "святые" ограничения, написанные непререкаемым Виртом, как тут Сергей вещает. К>(прошу не принимать близко к сердцу, но у меня именно такое впечатление складывается )
Согласен, что Вирт не "святой", и его вполне можно и нужно критиковать.
Только критика критике рознь. Я вот тут почитал на форуме: Вирт и "looser" и еще бог весть кто. Это несправедливо.
Оберон — красивое решение определенной проблемы (как и Форт, как и UNIX, и т.д.).
Видимо, нам (видящим в Обероне хорошую сторону) просто не удается внятно это выразить.
Так что, хотя бы отчасти, мы сами виноваты.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, AVC, Вы писали:
AVC>Разумные ограничения повышают качество ПО: делают его более простым, надежным и эффективным.
Абсолютно не согласен с данным утверждением. На практике, даже разумные ограничения делают код непростым, ненадежным. Стоит посмотреть на те же форумы Net. Программисты в погоне за эффективностью пляшут с бубном. Огромное количество времени и сил уходит именно на обход ограничений. Зачастую программа на Net похожа на программу C++ + WinAPI. Только надо приплюсовать еще борьбу с ограничениями, для которой в платформу встроено огромное количество средств.
Мне нравится Net, который принципиально борется со своими ограничениями (к сожалению за некоторыми исключениями). Если среда предоставляет не только концептуально-целостный подход, но и средства их обхода, то мне представляется именно тогда код будет надежным и эффективным. Пускай за это и придется платить "концептуальной" простотой кода. Все равно на 95 процентов это будет действительно "концептуальный" код, но за остальные 5 процентов не придется платить слишком высокой цены. И да умрут танцы с бубном.
PS. Все вышесказанное относится к языкам используемых в промышленной разработке.
PS. Каюсь, не смотрел Оберон, нет времени. Сообщение было ответом на конкретную фразу.
Ничего личного, бизнес есть бизнес.
Здравствуйте, GlebZ, Вы писали:
AVC>>Разумные ограничения повышают качество ПО: делают его более простым, надежным и эффективным. GZ>Абсолютно не согласен с данным утверждением. На практике, даже разумные ограничения делают код непростым, ненадежным.
Видимо, надо думать, что отсутствие всяких ограничений делает код простым и надежным?!
GZ>Если среда предоставляет не только концептуально-целостный подход, но и средства их обхода, то мне представляется именно тогда код будет надежным и эффективным. Пускай за это и придется платить "концептуальной" простотой кода. Все равно на 95 процентов это будет действительно "концептуальный" код, но за остальные 5 процентов не придется платить слишком высокой цены. И да умрут танцы с бубном.
IMHO, дело обстоит как раз наоборот.
Мы платим цену как раз за отсутствие концептуальной целостности, т.е. за противоречивость архитектуры ПО, когда "левая рука не знает, что делает правая".
Отсюда и происходят столь красочно описанные Вами танцы с бубном.
Возьмем конкретное ограничение Оберона: указатели могут указывать только на объекты "кучи".
Любой Си-программист скажет, что это "ужасное" ограничение. И это понятно, ведь в Си нет параметров-переменных, надо обязательно использовать указатель.
Так же воспринимается как ограничение контроль индексов при обращению к элементу массива.
Но зато в операционных системах, написанных на Си, приходится уделять много внимания и драгоценных ресурсов защите процессов... друг от друга. А в Оберон-системах объекты вполне могут мирно сосуществовать в одном адресном пространстве, компилятор гарантирует, что они друг другу не помешают.
В итоге Оберон-система и проще, и эффективнее, и обходится без бубна.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, kavlad, Вы писали:
K>Здравствуйте, Кодт, Вы писали:
К>>А я знаю, как популяризировать Оберон: написать компилятор Oberon.Net
K>Active Oberon for .Net
Ну, вот, кстати, сравните его нововедения и исходный Оберон. Думаю все бует ясно. А еще забавно будет глянуть на то как этот чудо переползет на второй фрэймворк где появятся дженерики. Вот будет забавно послушать Губанова, как он обоснует приклеивание такой некомпонетной вещи как дженерики к Оберону.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AVC, Вы писали:
AVC>Возьмем конкретное ограничение Оберона: указатели могут указывать только на объекты "кучи". AVC>Любой Си-программист скажет, что это "ужасное" ограничение. И это понятно, ведь в
Вы со своей любовью сравнивать Оберон с С уже до смеха доводите. С 35 лет. И язык был создан, для того чтобы эффективно биты двигать. А ты с равнивай Оберон с C#. Вот тогла и поглядим где надежность выше. И где удобства больше.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Перекуём баги на фичи!
я точно сам не знаю. А Aos BlueBottle (Active Object System) датируется что-то около 2000 — 2002 годами, впрочем разработка ведется по сей день (последняя версия от March 12, 2004)
)
