Ответ на »сообщение 1458« (Илья Ермаков)
___________________________
«Все это было бы смешно, когда бы не было так грустно»...

По поводу соотношения системного, низкоуровневого, прикладного программирования...
Из текста:
Современные задачи системного программирования невозможно решать низкоуровневыми методами.
Хм?..
Для написания миллионов строк кода и отражения сложных архитектурных
решений необходимы высокоуровневые языки 3GL со строгой системой типов и
контролем безопасности.
А для написания тысяч строк кода... контроль безопасности уже не нужен?.. Весьма странные представления, IMHO.
Вообще удивляет неистребимая потребность сравнивать зеленое и теплое... Системное программирование – составная часть разработки программных комплексов (систем). И, очевидно, само понятие «системное программирование» вне контекста разработки систем выглядит весьма... странно. В исторической ретроспективе операционные системы были едва ли не единственными программными системами, и в той же ретроспективе, низкоуровневые средства, были едва ли не единственными средствами разработки. И на этом (согласитесь!), странном основании было рождено понятие «системного программирования», фактически, эквивалентное понятию, низкоуровнего программирования. (Аналогичная софистика: все крысы смертны, Сократ смертен -> Сократ - крыса)
Однако создание систем не имеет никакой связи с языками программирования и не ориентировано ни на один из них. Точно также, «миллионы строк кода» не имеют ни малейшего отношения к созданию систем. Система – это совокупность взаимосвязных элементов... И все... Программный элемент может содержать два три десятка строк кода, и пара таких элементов может образовать систему (хоть и простую).
Сваливание в одну кучу различных понятий не ведет к пониманию того, о чем хочет сказать автор, IMHO.
Становится очевидной высокая сложность написания крупных надежных систем на таких языках, как C и C++.
«Сложность» - не в языках, а к подходах к моделированию и проектированию. Нет такой вещи, которую нельзя было бы выразить сложно на любом языке.

Из очерченной выше проблематики вытекает известное разделение программистов по направлениям их работы: прикладное и системное программирование.
Хм?.. Прикладные программисты не разрабатывают системы?.. Весьма странное противопоставление (оно имеет все ту же историческую подоплеку, но лишено смысла).

Прикладной программист ориентирован на решаемую задачу из некоторой проблемной области. Для ряда таких проблемных областей существуют декларативные языки 4GL, которые позволяют на порядок снизить трудоемкость таких задач по сравнению с использованием для этого универсальных языков 3GL.
Разработчик ОС ориентирован на  решаемую задачу из некоторой области ОС... 4GL – это, как правило, языки в рамках конкретных СУБД, расширяющие возможности SQL.

Низкоуровневый программист ориентирован на работу с оборудованием и решение проблем взаимодействия программного обеспечения с физическим окружением.
Прикладной программист ориентирован на работу с предметной областью в той же степени, в которой «низкоуровневый программист ориентирован на работу с оборудованием». У каждого своя предметна область... вот и все.

Системный программист ориентирован на создание инструментов, абстракций и механизмов, предназначенных для преодоления пропасти между примитивами
дискретной машины и задачами из проблемных областей. Центральное место
в системном программировании принадлежит языкам 3GL.
Инструменты разные важны, инструменты разные нужны... «ядерный реактор» - тоже инструмент для физика, например. Кто-то создает инструменты для работы с оборудованием, кто-то создает инструменты для работы с ОС, кто-то создает инструменты для пользователей... Это просто разные уровни... систем, а системы могут состоять из (условно!) произвольного количества уровней.

Основная цель системного программиста - создавать гибкие, многократно применимые технические решения, избежав привязки как к особенностям конкретной аппаратной платформы
А задача того, кто пишет ПО для склада, сделать такое ПО, которое бы не зависело от конкретной «кладовки» и могло применяться достаточно широко...

Эта черта мышления практически не характерна для низкоуровневых программистов, которые по определению создают конкретные решения, жестко привязанные в оборудованию
«Вот те бабушка и Юрьев день»... А такое понятие, как HAL (hardware abstraction level)... кто придумал?.. А стандарты на интерфейсы для чего создают?..

В целом эволюцию языков программирования следует рассматривать как развитие высокоуровневых абстракций, как отвлечение от аппаратной платформы в сторону проблемной области. Главным ограничением в этом направлении всегда являлась мощность оборудования. Чем выше уровень абстрагирования, тем большими становятся затраты на его поддержку, потери в быстродействии, разговорно часто называемые оверхедом
Единственная проблема развития состоит в преодолении собственной глупости. Это похоже на работу скульптора... который просто отсекает от каменной глыбы все лишнее. :) Уровень абстрагирования не имеет ни малейшего отношения к «затратам» на поддержку. Иное дело уровни систем, которые попадают под реализацию. Каждый уровень имеет свою логику, которая требует вполне определенных ресурсов.

Ответ на »сообщение 1445« (Jean)
___________________________

>>>Если бы Вирт копнул в изучении C++ чуть глубже
Не "переживайте" за Вирта :). Думаю, что он понял концепции С++ (а, точнее, их отсутствие) не хуже, чем кто-либо другой.


У меня сложилось впечатление, что Вирт летает в облаках и не видит ничего, кроме собственных изобретений (ну может чуть-чуть синтаксиса других языков, до которого он обычно и докапывается).


Что это за язык такой, если текст программы будет правильно работать на только на многих машинах?


Это переносимый ассемблер.

Ответ на »сообщение 1444« (Снегурочка)
___________________________
Если бы Вирт копнул в изучении C++ чуть глубже
1. Когда создавался Оберон, С++ на горизонте не наблюдалось.


Когда создавался С++ в нем много чего не было, что есть сейчас.


2. В языке важнее его цельность, а не набор отдельных фич.


Важнее для чего? Для реальной жизни? Не согласен.


3. Оберон создавался для конкретной задачи; оценивать "ошибки" Вирта надо по отношению к этой задаче.


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

Ответ на »сообщение 1441« (AVC)
___________________________

Ясно, что мы сейчас обсуждаем Оберон на уровне простых языков Оберон-1/2 и КП.
Замечу только, что в обероновском семействе есть "изощренные" языки (вроде Zonnon), существенно более "потакающие" Вашему вкусу. :)


Хотелось бы для определенности оставаться в рамках Оберон-2 и КП.



1) Механизм исключений

В Zonnon есть встроенная обработка исключений (с ней связаны ключевые слова ON и EXCEPTION).
В "чистом" же Обероне возможен способ обработки исключений, не требующий изменений в языке, за счет рефлексивности.


Интересно, зачем тогда в Zonnon все-таки добавили ключевые слова? ;) Подозреваю, что вопрос опять упирается в "человечность".


подпоследовательности (diff; алгоритм изложен практически в любом учебнике: Кормен и т.д.).
Не вижу больших проблем для реализации "документо-ориентированного" варианта CVS специально для Оберонов (если есть реальная потребность и если такового еще нет).


А я вижу проблему. Потому что алгоритма сравнения "документов" нет в любом учебнике.


Впрочем, все это относится к среде программирования, а не собственно к языку.


Среда программирования - очень важная часть "реальной жизни".


Есть реализации Оберона и с подсветкой, и с пошаговым отладчиком, и с чисто текстовыми исходниками, вполне пригодными для CVS. Хотя бы XDS.


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

Ответ на »сообщение 1461« (pepper)
___________________________
На Обероне ОСей написано больше, чем на С++ (не голом С). Около десятка, из них 3 - промышленные жесткого реального времени. О чем еще говорить?
Microsoft Research сегодня работает на базе, подготовленной в начале 90-х швейцарской школой. Для всех их "передовых технологий" можно проследить четко, "откуда ноги растут". Просто доходит до них все как до жирафа...

Ответ на »сообщение 1440« (AVC)
___________________________

http://www.oberon.ethz.ch/WirthPubl/ProjectOberon.pdf
:)


Хотел бы я дать ссылку на Singularity, но нету под рукой... А вообще ОС не каждый день пишутся и не в каждой конторе, хотелось бы более жизненныого примера.


Значит ли это, что в Eiffel предусловия require появляются сами собой, а не набиваются "тетками", наподобие ASSERT?


У меня нет опыта разработки на Eifell, но мне кажется, что в языке преподносимом как "язык с прямой поддержкой принципа design by contract", этот самый принцип должен выражаться проще и естественне, чем банальный ASSERT.


Вам когда-нибудь приходилось вылавливать утечки памяти в чужом Си++ном коде?


Приходилось. Обычный процесс примерно такой: в подозрительном месте ставится один из смартпоинтеров, избавление от ошибок компиляции, утечек нет.


Однако, слово "статические" здесь и правда неудачно.
Речь идет о том, что записи могут быть не только "динамическими" (в куче).
В частности, могут быть "автоматическими" (т.е. располагаться на стеке).


И как организовать банальную очередь из таких записей?

Ответ на »сообщение 1459« (pepper)
___________________________

Лично я говорил о невыразительности конкретно оберона. А C/C++ был упомянут только потому, что в этих сотни раз раскритикованных языках есть перечислимый тип, который добавляет выразительности.

По поводу дискуссии об отсутствии перечисления в Обероне. Как известно, за все надо платить. Осталось только понять цену вопроса.

Если перечисление Вирт включил бы в классический Оберон (точнее, сохранил при переходе от Modula-2), то в дополнение к приведенным ранее аргументам стоит заметить, что пришлось бы как-то выкручиваться и со значками экспорта: нужно было бы ставить звездочку не только у имени типа, но и у всех его значений (констант). Частичный экспорт здесь неприемлем.

Что важнее: стройность языка, где уже узаконена схема неявного интерфейсного модуля (через значки экспорта), либо введение относительно редко используемого базового типа, который требует уймы оговорок и исключений из правил, при том, что его несложно смоделировать? IMHO, Вирт был последователен в своем стремлении изъять все, на его взгляд, лишнее из языка.

Ответ на »сообщение 1432« (Jean)
___________________________

Замечание для тех, кто считает языки С/С++ "надежными" и "безопасными" языками.


А что, кто-то считает? Лично я говорил о невыразительности конкретно оберона. А C/C++ был упомянут только потому, что в этих сотни раз раскритикованных языках есть перечислимый тип, который добавляет выразительности.

Ответ на »сообщение 1457« (Снегурочка)
___________________________
По поводу соотношения системного, низкоуровневого, прикладного программирования...
Вот только вчера писал по этому поводу главу для учебного пособия...
Выложу, очень уж в тему:
http://ermakov.metasystems.ru/his-his.tex

Ответ на »сообщение 1455« (AVC)
___________________________

Итак, Си создавался как "язык системного программирования".
Хотелось бы получше разобраться в этом утверждении.
Действительно ли Си -- язык, особо подходящий для создания (операционных) систем?

Наверное, подвергать сомнению утверждение о том, что Си создавался как язык системного программирования, вряд ли кто возьмет на себя смелость. Да и Вы вопрос переводите в иную плоскость: насколько Си подходит в этом амплуа сегодня и как может здесь сопоставляться с Обероном?

Для начала стоит обратить внимание на один немаловажный нюанс: языки Си и Оберон роднит тот факт, что они создавались не вообще, не ради абстрактных целей облагодетельствования человечества в решении любых задач (вроде C++), а формировались в рамках реализации конкретных практических проектов, где их роль была едва ли не центральной. В тех проектах они и оттачивались: языки были инструментом реализации проектов, а не ярмаркой-продажей богатого функционала и не военным парадом мощи различных идей программирования. Ранние версии Си (без препроцессора, без union и типа перечисления, без long и unsigned) и Оберона (мини-Модула, явное разделение модуля на интерфейс и реализацию) потом доводились до ума в ходе адаптации их в соответствующих проектах реализации ОС UNIX и ОС Oberon.

Как известно, ОС UNIX создавалась в AT&T Bell Labs Кеном Томпсоном на языке B. Ему помогали еще 5 человек, среди которых был и Деннис Ритчи. К 1971 г. Деннис Ритчи спроектировал Си и реализовал первый его компилятор на PDP-11. Летом 1973 г. ядро UNIX было переписано на Си. За период 1971-1973 гг. язык Си был доработан так, чтобы по максимуму использоваться для реализации UNIX: в частности, именно тогда появился препроцессор и была реализована стандартная библиотека языка, во многом благодаря которой (и благодаря интересу к UNIX) он быстро стал завоевывать мир (чего не скажешь об Обероне). Однако более-менее язык вызрел только к 1978 г., когда и появилась книга Кернигана и Ритчи "The C Programming Language" (K&R). Эталонное описание Оберона, зафиксировавшее язык, появилось летом 1988 г. На появление первой эталонной версии языка у Си ушло 7 лет (1971-1978), у Оберона 3 года (1985-1988).

Выполнил ли Си тогда свою задачу как язык системного программирования для реализации переносимой ОС UNIX? Вне всякого сомнения. Более того, Си был и поныне остается стандартом де-факто в качестве промежуточного языка (высокоуровневый ассемблер) для переноса софта на разные архитектуры. Генерация Си-кода вместо машинного для компиляторов с новых языков - самый быстрый путь дать им путевку в жизнь и опробовать новые идеи на разных архитектурах.

ОС Oberon строилась на отличных от UNIX принципах (прежде всего, на идеях модульности и динамической расширяемости). При этом она сохраняла моноязыковость ОС. Разумеется, строилась не на пустом месте (работы Xerox и опыт OC Medos на Modula-2/Lilith).

В Обероне низкоуровневые средства по возможности локализованы в SYSTEM (run-time), а не размазаны по языку. В этом отношении язык выглядит более предпочтительно в роли языка системного программирования (с прицелом на переносимость), нежели Си. Но это не значит, что Си для этой роли сегодня уже не подходит.

P.S. ОС Oberon не почила в Бозе. Ralph Sommerer из Microsoft Research в рамках Mobile Web сейчас работает над проектом реинкарнации-переноса ОС Oberon в среду браузеров под JavaScript через свою реализацию Oberon Script (компилятор языка Оберон на JavaScript).