>>А что именно осложняет разбираться в проектах на Обероне (а также Go, Java) я описал выше и довольно подробно. Не вижу смысла повторяться.
Вот и получается, что никакого страдания нет, а если оно у тебя есть, то связано не только см Обероном, но и другими языками. Ведь не назовёшь же серьёзной проблемой ЯЗЫКА непонимание где что находится в ПРОЕКТЕ? На любом языке, открыв чужой проект в каком нибудь нотепаде ( ты же обероновские модули в неком подобии нотепада сиотришь, когда для С++ используешь наdороченную и настроенную IDE?) нужно потратить время на то чтобы разобраться что где лежит, настроить ту самую супер IDE и вперёд.
Нет, Алексей, периодически писать код на Обероне в пару десятков строк, и от этого тебя ломает, не даёт основания писать, вводя других в заблуждение, что Оберон осложняет всем жизнь.
Я ведь не пишу в паблике, что С осложняет мне жизнь, когда я эпизодически пишу те же самые пару десятков строк и постоянно читаю большое количество кода — в языках C, C++ вообще сложно найти где находится файл инклюда, по крайней мере мне. Не, понятно, что правильно настроенная IDE может решить этот вопрос, ноя смотрю исходники в простом npp.
Очень удобно это сделано в компиляторе Оберона-2 OO2C — по сигнатуре заголовка модуля видно где он находится и где находятся подключаемые модули. Вот заголовок первого попавшегося модуля:
В Модуле-3, которая мне больше всего нравится, и которую мы активно используем, есть очень серьезная проблема с пониманием не только того, где находятся исходники модулей, но даже где находится реализация интерфейса, потому что реализация интерфейса может быть разбросана по разным модулям реализации. Да и сам интерфейс может состоять и нескольких интерфейсных модулей, предоставляя клиентам только необходимое(этим достигается и реализация механизма private и protected членов интерфейса). Только анализируя сборочный скрипт и используя поиск можно найти где что находится.
Тем не менее, это, пожалуй лучший язык семейства Модула и наследников.
Но ты так и не сказал, что же усложняет тебе жизнь в Обероне.
А что для программистов усложнилось? Для каких программистов?
Мы используем Оберон и Активный Оберон и как-то усложнения не ощущаем. Ты на Обероне не пишешь, ты тем более не можешь ощущать проблем и дискомфорта.
Язык программирования также всегда наследует черты одного предка, разбавляя их внешними заимствованиями. Язык также может вообще быть новаторским, формируя новую семью и не имея предка, но имея заимствования — сейчас это случается редко, но случается.
Однако, когда некий человек создаёт язык, не имея достаточной базы знаний для этого и, по сути, не представляя свой создаваемый язык в целом, даже не представляя что он представляет, тогда в процессе вынужденной эволюции(язык плохо спроектирован), он может измениться до неузнаваемости, и будет казаться, что вот «отсуда» унаследован, тогда как первоначально был «оттуда», но это только значит, что только сейчас у разработчика сформировалось видение архитектуры и концепции языка (возможно, под действием чьих-то пинков)
Дак подобное было в Модуле-2, от которой произошел Оберон, Вирт специально это удалил в Обероне для упрощения языка и компилятора, чтобы любой студент мог разобраться, чтобы проще было портировать и компилятор и Обероне-Систему. И Оберон-Система была под все распространённые(и не очень) платформы, и как приложение хостовой ОС тоже.
Поэтому предъявлять по этому поводу претензии к Оберону не стоит, ибо это одна из главных концепций — простота и надёжность. Оберон никогда не претендовал на захват мира.
Речь больше о языках одного семейства, про возможность множественного наследования семейств я упомянул.
Тем не менее и креольские языки имеют одного предка — пиджин, если не ошибаюсь. к тому же, креольские языки это языковая семья
Добавил в статью выдержку из диссертации Патрика Реали, создателя многопоточного компилятора Активного Оберона, JVM для A2 и вообще внёсшего существенный вклад в Оберон-Технологии. Критика Языка Оберон от отцов-основателей, «чтобы в корне пресечь кривотолки»
Нет. Я ведь тебе говорил, не стоит путать наследование с заимствованием.
В русском языке, есть заимствования, к примеру, из немецкого, французского, английского ..., но при этом он не стал ни немецким, ни французским, ни английским, ни каким то ещё, он остался русским.
В рамках семейства языков( тем более языков программирования ) чётко прослеживается дерево наследования, потому что, как ни крути, любой язык семейства основан на каком то языке этого же семейства. Именно это и отображает генеалогическое дерево в том числе генеалогическое дерево языков Оберон. Это не отменяет того факта, что заимствования могут быть даже в рамках языкового семейства, но не заимствования формируют дерево.
В рамках же взаимосвязей языковых семейств, действительно дерево может превратиться в граф, хотя и здесь можно выстроить именно дерево, зафиксировав соглашение, по каким признакам будет строиться дерево семейств языков.
Не нужно передёргивать — заимствовать концепции какого либо языка и быть основанным на нём — это совершенно разные вещи. Если ты этого не понимаешь — мне жаль, но не более того.
Что касается C++98, C++11, они остаются быть C++, сколько ты там цифр ни напиши и есть семейство языков C++, куда входят различные диалекты, равно как есть и семейство языков Оберон, куда входят разные Обероны.
И таки да, некоторые относят C++ к семейству Алгола, хотя синтаксис разный, но семантика ведь важнее, не правда ли?
Далее, про то, что модули есть только в Обероне и это придумка Вирта может говорить только человек далёкий от Оберона, к тому же очевидно же, что Оберон основан на модуле-2, это никто не скрывал, как раз наоборот. А так как он основан(а не заимствует) на модуле-2, то входит в семейство модулы, формируя, в тоже время, новое семейство языков Оберон и так далее. На сайте ETHZ есть официальная генеалогия языков Оберон, и заметь там написано Oberon Language Genealogy Tree
Слово семейство там нет, можно, конечно, сказать, что писали тупые, а Вирта обозвать эээ… неумным, но прежде этого стоит внести как минимум такой же вклад в развитие информационных технологий и научной школы, а учитывая, что в том числе его ученики и ученики его учеников и коллег, прошедшие школу Оберона и создают тот самый менстрим, то это выглядит как минимум глупо и смешно.
Нет, Алексей. Я думаю, что разработчикам Go виднее, заимствовали они из Оберона и Паскаля или нет. Они явно пишут, что заимствовали. Раньше там было даже указано более подробно, что заимствование шло из Оберона Оберона-2, Активного Оберона. Сейчас стоит просто Оберон и это правильно, ибо это всё Обероны, включая Компонентный Паскаль( о чём, опять же, явно пишут его создатели, приложившие руку и к созданию Оберона-2, тем более, что и компилятор там от Оберона-2). Создатели Limbo и Inferno также писали о том, что их вдохновил именно Оберон — и язык и операционная система.
Конечно, с самого начала, разработчики Go о своих заимствованиях из Оберона и Паскаля не упоминали, пока их не ткнули носом. Тогда было признано, и на сайте Го появилась такая информация официально.
Чтл касается некое различие типов — это совсем не важно, ведь когда в Активный Оберон были добавлены комплексные типы, перечисления, беззнаковые, адрес, синтаксис определения типов остался тем же самым и язык также остался языком семейства Оберон.
В Модуле-3 также есть объявление переменных по месту(почти по месту) и вывод типа переменной по типу результата первого присваивания. Но, при этом oна осталась языком семейства Модула и синтаксис не изменился.
Добавятся в Активный Оберон кортежи — синтаксис объявления не изменится.
Поэтому и в Го, как типы не назови, какие новые типы не вводи, синтаксис останется неизменным, иначе такая каша получится…
И да, никто не называет Go Обероном с сишным синтаксисом.
>>То есть они в основном посмотрели у оберона немного синтаксиса объявлений (переменных, типов), и по факту его модифицировали и применили, а также модульную систему.
Позаимствовать синтаксис описания типов, переменных, методов и концепцию модулей/пакетов- это, извини уж, очень много.
Не только ARM, но и Cell, PPC, RISC-V, возможно ещё что-то.
Мы сами используем версию под dfhbfyn VAX-11 и PDP-11.
Но в официальном репозитории пока только x86-32/x86-64
Ну может быть, но это не отменяет того факта, что его можно выдрать из ОберонСистемы и сделать консольным. Я также знаю человека, который может тебе переписать его на фрипаскале и дать IDE для Оберона
Вот и получается, что никакого страдания нет, а если оно у тебя есть, то связано не только см Обероном, но и другими языками. Ведь не назовёшь же серьёзной проблемой ЯЗЫКА непонимание где что находится в ПРОЕКТЕ? На любом языке, открыв чужой проект в каком нибудь нотепаде ( ты же обероновские модули в неком подобии нотепада сиотришь, когда для С++ используешь наdороченную и настроенную IDE?) нужно потратить время на то чтобы разобраться что где лежит, настроить ту самую супер IDE и вперёд.
Я ведь не пишу в паблике, что С осложняет мне жизнь, когда я эпизодически пишу те же самые пару десятков строк и постоянно читаю большое количество кода — в языках C, C++ вообще сложно найти где находится файл инклюда, по крайней мере мне. Не, понятно, что правильно настроенная IDE может решить этот вопрос, ноя смотрю исходники в простом npp.
Очень удобно это сделано в компиляторе Оберона-2 OO2C — по сигнатуре заголовка модуля видно где он находится и где находятся подключаемые модули. Вот заголовок первого попавшегося модуля:
В Модуле-3, которая мне больше всего нравится, и которую мы активно используем, есть очень серьезная проблема с пониманием не только того, где находятся исходники модулей, но даже где находится реализация интерфейса, потому что реализация интерфейса может быть разбросана по разным модулям реализации. Да и сам интерфейс может состоять и нескольких интерфейсных модулей, предоставляя клиентам только необходимое(этим достигается и реализация механизма private и protected членов интерфейса). Только анализируя сборочный скрипт и используя поиск можно найти где что находится.
Тем не менее, это, пожалуй лучший язык семейства Модула и наследников.
Но ты так и не сказал, что же усложняет тебе жизнь в Обероне.
Мы используем Оберон и Активный Оберон и как-то усложнения не ощущаем. Ты на Обероне не пишешь, ты тем более не можешь ощущать проблем и дискомфорта.
Однако, когда некий человек создаёт язык, не имея достаточной базы знаний для этого и, по сути, не представляя свой создаваемый язык в целом, даже не представляя что он представляет, тогда в процессе вынужденной эволюции(язык плохо спроектирован), он может измениться до неузнаваемости, и будет казаться, что вот «отсуда» унаследован, тогда как первоначально был «оттуда», но это только значит, что только сейчас у разработчика сформировалось видение архитектуры и концепции языка (возможно, под действием чьих-то пинков)
Поэтому предъявлять по этому поводу претензии к Оберону не стоит, ибо это одна из главных концепций — простота и надёжность. Оберон никогда не претендовал на захват мира.
Тем не менее и креольские языки имеют одного предка — пиджин, если не ошибаюсь. к тому же, креольские языки это языковая семья
В русском языке, есть заимствования, к примеру, из немецкого, французского, английского ..., но при этом он не стал ни немецким, ни французским, ни английским, ни каким то ещё, он остался русским.
В рамках семейства языков( тем более языков программирования ) чётко прослеживается дерево наследования, потому что, как ни крути, любой язык семейства основан на каком то языке этого же семейства. Именно это и отображает генеалогическое дерево в том числе генеалогическое дерево языков Оберон. Это не отменяет того факта, что заимствования могут быть даже в рамках языкового семейства, но не заимствования формируют дерево.
В рамках же взаимосвязей языковых семейств, действительно дерево может превратиться в граф, хотя и здесь можно выстроить именно дерево, зафиксировав соглашение, по каким признакам будет строиться дерево семейств языков.
Генеалогическое дерево есть и у разговорных языков и у зыков программирования.
Что касается C++98, C++11, они остаются быть C++, сколько ты там цифр ни напиши и есть семейство языков C++, куда входят различные диалекты, равно как есть и семейство языков Оберон, куда входят разные Обероны.
И таки да, некоторые относят C++ к семейству Алгола, хотя синтаксис разный, но семантика ведь важнее, не правда ли?
Далее, про то, что модули есть только в Обероне и это придумка Вирта может говорить только человек далёкий от Оберона, к тому же очевидно же, что Оберон основан на модуле-2, это никто не скрывал, как раз наоборот. А так как он основан(а не заимствует) на модуле-2, то входит в семейство модулы, формируя, в тоже время, новое семейство языков Оберон и так далее. На сайте ETHZ есть официальная генеалогия языков Оберон, и заметь там написано Oberon Language Genealogy Tree
Слово семейство там нет, можно, конечно, сказать, что писали тупые, а Вирта обозвать эээ… неумным, но прежде этого стоит внести как минимум такой же вклад в развитие информационных технологий и научной школы, а учитывая, что в том числе его ученики и ученики его учеников и коллег, прошедшие школу Оберона и создают тот самый менстрим, то это выглядит как минимум глупо и смешно.
Конечно, с самого начала, разработчики Go о своих заимствованиях из Оберона и Паскаля не упоминали, пока их не ткнули носом. Тогда было признано, и на сайте Го появилась такая информация официально.
Чтл касается некое различие типов — это совсем не важно, ведь когда в Активный Оберон были добавлены комплексные типы, перечисления, беззнаковые, адрес, синтаксис определения типов остался тем же самым и язык также остался языком семейства Оберон.
В Модуле-3 также есть объявление переменных по месту(почти по месту) и вывод типа переменной по типу результата первого присваивания. Но, при этом oна осталась языком семейства Модула и синтаксис не изменился.
Добавятся в Активный Оберон кортежи — синтаксис объявления не изменится.
Поэтому и в Го, как типы не назови, какие новые типы не вводи, синтаксис останется неизменным, иначе такая каша получится…
И да, никто не называет Go Обероном с сишным синтаксисом.
Позаимствовать синтаксис описания типов, переменных, методов и концепцию модулей/пакетов- это, извини уж, очень много.
Мы сами используем версию под dfhbfyn VAX-11 и PDP-11.
Но в официальном репозитории пока только x86-32/x86-64