OberonCore

Из книги Алана Донована и Брайана Кернигана.

Можно тыкать в наглые мейнстримовские рожи, утверждающие, что "масштабы влияния Оберона на Яву, Го и др. чисто символические".

Следует различать текстовое и визуальное программирование.

Визуальный язык ДРАКОН тоже берет начало из ALGOL 60.

Структурная схема (картинка) ограничивается анализом в рамках текстового программирования, НЕ ВЫХОДЯ за его пределы.

Все разногласия, порою острые, также находятся в рамках текстового программирования, НЕ ВЫХОДЯ за его пределы.

По моему мнению, победит тот, кто разработает общий подход, объединяющий текстовое и визуальное программирование.

Похоже, что среди теоретиков таких смельчаков пока нет.

А есть такие рожи? Может, они это публично утверждали?

Мнению трудно найти основания в истории текста (начиная с истории речи).

Надо отдать должное, что в чем-то Go превосходит Оберон: в том, что там реализована определенная модель многозадачности. В КП же есть только кооперативная многозадачность и не используются преимущества многоядерности процессоров. Вообще, насколько я знаю, в языке Модула была реализована какая-то модель многозадачности, затем Вирт решил, что не следует встраивать в язык то, что, во-первых, может быть реализовано в виде библиотек, а, во-вторых, пока не достаточно устаканилось (не смог подобрать лучшего слова). И Оберон не включает в себя реализацию многозадачности, с другой стороны, нет и большого количества реализаций многозадачности для Оберонов в виде библиотек.

Многозадачность не есть элемент языка. Это элемент рантайма. Вводить многозадачность, как оператор FOR -- неразумно. И прикрутить библиотеку process гораздо проще, логичней, и если не надо -- то и необязательно. Go, ко всему прочему создаёт монолит без всяких DLL, в попытке избежать ада динамических библиотек. На мой взгляд, тут Go вчистую проигрывает Компонентному Паскалю. И да, Go -- не язык системного программирования до тех пор, пока я не увижу ОС на нём. БлэкБокс может и не является полноценной ОС, но заменяет с успехом 90% необходимого функционала ОС в прикладнухе.

В Go многозадачность как раз в языке. Это, кстати, одно из главных удобств в нем.

Знаю. Да, плюшка удобная. Но именованные каналы известны ещё с эпохи динозавров. И сделать более удобный интерфейс к ним:
1) Признать, что именованные каналы и либы к ним сделаны через одно место.
2) Втащить в язык либу, только потому, что она красиво сделана, имхо, признак непонимания принципа достаточности и необходимости.
почему бы было не сделать так:

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

Ознакомьтесь для начала со всеми возможностями каналов в Go.

)) Благодарю за предложение. Не сомневаюсь, что каналы в golang замечательная универсальная штука, но то что, golang изуродованный Оберон -- в этом у меня нет сомнений,)

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

Столько раз проходили, что ...

))))

Во что Вы превращаете форум oberoncore.ru?

Пётр, я выразил свои эмоции как мог. Если Вы считаете, что моё сообщение превращает форум в мусор -- удалите моё предыдущее и это сообщение, я не против. Могли бы и в личку написать.

Ну и отлично. Будет следующий виток эволюции языков.

Ничего не делать тоже не вариант.

Но сперва будут отстроены парсеки инфраструктур и написаны мегатонны софта, потрачены миллионы человеко-часов на борьбу с неочевидностями и костылями, в погоне за сиюминутной выгодой упущено время и недополучена подводная часть айсберга прибыли. Думаю так, если человечество допускает, что ему в этом мире больше нечем заняться, то отчего бы не потусоваться.

Согласен с Иваном. Конечно, есть вероятность, что идя непонятно куда, можно попасть в нужную точку.
Но на порядки больше вероятность прийти в никуда, чем куда-то, используя такие способы построения ИТ.
Я всегда ставлю мысленный эксперимент короткого замыкания и холостого хода.
Например, что будет, если все в мире станут программистами? Мы все сдохнем от голода через пару недель.
Что будет если никто не будет программистом? Ну, просто не будет ИТ, но ничего кардинального с человечеством не произойдёт.
Программист -- не фундаментальная профессия)))
Точно такой же эксперимент можно поставить с мультипроцессорностью в языке.
Или аналогичный эксперимент (с другой стороны) с бесконечной тактовой частотой ЦП))
Качественные выводы, имхо, не так очевидны, но они в любом случае говорят о том, что без неё (встроенной мультипроцессорности) в языке прожить можно,)

Однако, они знают куда идут и зачем.
Кстати, в Активном Обероне вполне себе нормально получилось и та же концепция Активных Объектов и синтаксис монопольных секций применим и для вытесняющей многозадачности и для кооперативной многозадачности на неблокирующих алгоритмах. Реализация внутри различная, а внешне для программиста мало что изменилось на прикладном уровне.
Ну, а кому не нравятся языковые конструкции, тот может использовать соответствующий программный каркас, напрямую управляя потоками, впрочем языковые конструкции используют от же самый каркас.

А вот кстати, да, Кемет!
Может я что-то упустил, но монопольных секций в golang -- нет!
А это проблема при написании драйверов. Да, я не утверждаю, что монопольную секцию реализовать невозможно без специальных языковых конструкций. Но, фактически указание монопольной секции может быть реализована либой/каркасом в одну строку.
Вот сейчас специально проверил запрос "Драйвер на golang" в яндексе/гугле. Всё крутится вокруг драйверов к базам данных.
На запрос "Операционная система на golang" есть парочка ссылок с примитивными поделками, что не идёт близко в сравнение с WinAos. Плюс ко всему потребуются шаманские танцы на golang.

Языковые конструкции в Go не самые дурные, хотя и во многом нелогичные. Я понимаю, что это плата за желание сделать и правильно, и модно.
Речь идёт именно том, а на сколько это КРАЙНЕ необходимо. Как ключевое слово PROCEDURE или FOR? И вот здесь у меня (и не только у меня), есть большие сомнения в правильности выбранного направления.

В итоге, лично для меня -- golang забавная штукенция, но в отличии от того же BlackBox, который способен выжить сам без денежных вливаний -- golang, в условиях безденежья, имхо обречён. И в этом оооочень существенная разница.

Я знаю людей, которые переходили с явы, перла, бейсика на питон (сам такой, Ваня Денисов тут близок). Не знаю людей ушедших на питон после Оберонов)))

Это просто механизм, функциональное назначение которого - гарантировать, что с ресурсом работает только один поток. В Активном Обероне реализовали так - через монитор. Каждый объект, в котором есть монопольные секции защищается монитором. В Модуле-3, которая тоже поддерживает многопоточность на уровне языка, есть оператор LOCK, который решает ту же самую проблему. Но это, просто синтаксический сахар, и можно использовать соответствующий интерфейс и это хорошо, а в АО такого нет и это, наверное, плохо.
В Go тоже есть мониторы Хоара, но работают они, вроде, классически - на основе очередей сообщений Бринча Хансена.
Да что-то переписывали, Plan9 или Inferno? не помню.
Унификация. Как следствие меньше ошибок. Есть стандартный языковой механизм и правила его использования. Многопоточка это та еще муть и столько ошибок при реализации вылазит, причем трудно отлавливаемых. И такая поддержка на уровне языка дает определенное преимущество. Конечно, это накладывает и ограничения, но данный баланс оправдан. Впрочем, в Оберонах тоже много разных ограничений, кому-то нравится, кому-то нет.

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