Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 60
Не только ARM, но и Cell, PPC, RISC-V, возможно ещё что-то.
Мы сами используем версию под dfhbfyn VAX-11 и PDP-11.
Но в официальном репозитории пока только x86-32/x86-64
Мы сами используем версию под dfhbfyn VAX-11 и PDP-11.
Но в официальном репозитории пока только x86-32/x86-64
Как я уже говорил, инкапсуляция в Оберонах также построена на концепции модуля — все типы, объявленные в модуле прозрачны друг для друга, а доступ внешних клиентов к сущностям модуля осуществляется посредством спецификаторов доступа.По небольшому опыту с golang, где используется аналогичный подход, — довольно удобная вещь (там видимость определяется тем заглавная или прописная первая буква идентификатора).
Ну разработчики Go много чего взяли из Оберонов, в чём сами признались.
Go is mostly in the C family (basic syntax), with significant
input from the Pascal/Modula/Oberon family (declarations, packages), (дальше про другие языки)
То есть они в основном посмотрели у оберона немного синтаксиса объявлений (переменных, типов), и по факту его модифицировали и применили, а также модульную систему.
Но тут конечно есть нюанс в том, что ни синтаксис объявлений ни модульная система в принципе не уникальны у Оберона. Есть языки которые были раньше с тем же, есть языки которые были позже. Оберон просто наиболее простой из них (скорее всего).
Кроме того, те же модули у Го и Оберона действительно сильно отличаются. У Оберона модуль это обычно единица компиляции и загрузки-выгрузки. У Го — нет (а динамической загрузки-выгрузки там нет вовсе, сейчас компоновка только статическая). В обероне один модуль == один файл исходника. В Го пакет — это множество исходников в одном каталоге.
При этом вот лично мне и в Го и в Обероне не нравится как сделан экспорт сущностей из модуля/пакета. Там просто инлайн мелкая пометка (в Го — заглавная-строчкая буква идентификатора сущности, в Обероне — * ). Соответственно если например смотришь где-то исходники, где нельзя использовать дополнительный инструментарий (на гитхабе например), то приходится прочесывать всю реализацию чтобы понять что именно оно там экспортирует. Мне больше нравится когда перечень экспорта оформлен отдельно. В идеале — как в Аде например. Писать дольше, но читать и разбираться в исходниках потом намного проще.
При этом автогенерация спецификаций модуля по исходнику мне тоже не нравится — либо там не будет коментариев (коментариев именно к спецификации относящейся) либо в реализацию модуля придется забивать комментариями которые нужны для спецификации, но не для реализации.
В данном случае мне нравится когда мухи отдельно, котлеты отдельно. И при этом чтобы компилятор проверял, что реализация модуля не противоречит его спецификации (иногда полезно разрабатывать отталкиваясь от спецификации на модуль, а не от реализации, то есть вначале пишем спеку, потом реализуем, причем по спеке можно также автоматически сгенерировать реализацию-заглушку).
>>То есть они в основном посмотрели у оберона немного синтаксиса объявлений (переменных, типов), и по факту его модифицировали и применили, а также модульную систему.
Позаимствовать синтаксис описания типов, переменных, методов и концепцию модулей/пакетов- это, извини уж, очень много.
Позаимствовать синтаксис описания типов, переменных, методов и концепцию модулей/пакетов- это, извини уж, очень много.
Описание типов в обероне ничем не отличается от того, что было раньше его, в той же Аде например, или даже паскале, или в Mesa. При этом, у Го система типов другая, следовательно и объявления все же другие. Даже синтаксически.
Объявления переменных в Go откровенно другие — местами это похоже на Оберон или Аду, местами нет. Например в Go активно переменные объявляются по месту и без анотации типов.
А концепция модулей и пакетов, как я уже говорил, во-первых отличается, а во-вторых опять таки, в этом Обероне тоже не уникален. До него была Ада и Модула-2, а до Модулы-2 была Mesa.
Единственное что действительно у Go очень похоже на Оберон-2 (но не Оберон) — это синтаксис объявления методов (ака процедур связанных с типом). Но семантика там все же другая.
Ну и естественно на Го намного больше повлиял Limbo — это по сути прямой предшественник Го. Питон тоже повлиял, и еще пачка разных других языков.
Есть и свои, уникальные находки.
Это все в совокупности делает Go новым, самостоятельным языком. Не иеальным естественно, но и не клоном какого-либо сущствующего языка. И уж точно это не Оберон с сишным синтаксисом.
PS. Да, а синтаксис таки вторичен. Семантика языка всегда важнее.
Объявления переменных в Go откровенно другие — местами это похоже на Оберон или Аду, местами нет. Например в Go активно переменные объявляются по месту и без анотации типов.
А концепция модулей и пакетов, как я уже говорил, во-первых отличается, а во-вторых опять таки, в этом Обероне тоже не уникален. До него была Ада и Модула-2, а до Модулы-2 была Mesa.
Единственное что действительно у Go очень похоже на Оберон-2 (но не Оберон) — это синтаксис объявления методов (ака процедур связанных с типом). Но семантика там все же другая.
Ну и естественно на Го намного больше повлиял Limbo — это по сути прямой предшественник Го. Питон тоже повлиял, и еще пачка разных других языков.
Есть и свои, уникальные находки.
Это все в совокупности делает Go новым, самостоятельным языком. Не иеальным естественно, но и не клоном какого-либо сущствующего языка. И уж точно это не Оберон с сишным синтаксисом.
PS. Да, а синтаксис таки вторичен. Семантика языка всегда важнее.
Нет, Алексей. Я думаю, что разработчикам Go виднее, заимствовали они из Оберона и Паскаля или нет. Они явно пишут, что заимствовали. Раньше там было даже указано более подробно, что заимствование шло из Оберона Оберона-2, Активного Оберона. Сейчас стоит просто Оберон и это правильно, ибо это всё Обероны, включая Компонентный Паскаль( о чём, опять же, явно пишут его создатели, приложившие руку и к созданию Оберона-2, тем более, что и компилятор там от Оберона-2). Создатели Limbo и Inferno также писали о том, что их вдохновил именно Оберон — и язык и операционная система.
Конечно, с самого начала, разработчики Go о своих заимствованиях из Оберона и Паскаля не упоминали, пока их не ткнули носом. Тогда было признано, и на сайте Го появилась такая информация официально.
Чтл касается некое различие типов — это совсем не важно, ведь когда в Активный Оберон были добавлены комплексные типы, перечисления, беззнаковые, адрес, синтаксис определения типов остался тем же самым и язык также остался языком семейства Оберон.
В Модуле-3 также есть объявление переменных по месту(почти по месту) и вывод типа переменной по типу результата первого присваивания. Но, при этом oна осталась языком семейства Модула и синтаксис не изменился.
Добавятся в Активный Оберон кортежи — синтаксис объявления не изменится.
Поэтому и в Го, как типы не назови, какие новые типы не вводи, синтаксис останется неизменным, иначе такая каша получится…
И да, никто не называет Go Обероном с сишным синтаксисом.
Конечно, с самого начала, разработчики Go о своих заимствованиях из Оберона и Паскаля не упоминали, пока их не ткнули носом. Тогда было признано, и на сайте Го появилась такая информация официально.
Чтл касается некое различие типов — это совсем не важно, ведь когда в Активный Оберон были добавлены комплексные типы, перечисления, беззнаковые, адрес, синтаксис определения типов остался тем же самым и язык также остался языком семейства Оберон.
В Модуле-3 также есть объявление переменных по месту(почти по месту) и вывод типа переменной по типу результата первого присваивания. Но, при этом oна осталась языком семейства Модула и синтаксис не изменился.
Добавятся в Активный Оберон кортежи — синтаксис объявления не изменится.
Поэтому и в Го, как типы не назови, какие новые типы не вводи, синтаксис останется неизменным, иначе такая каша получится…
И да, никто не называет Go Обероном с сишным синтаксисом.
Сейчас стоит просто Оберон и это правильно, ибо это всё Обероны, включая Компонентный Паскаль( о чём, опять же, явно пишут его создатели, приложившие руку и к созданию Оберона-2, тем более, что и компилятор там от Оберона-2).
…
Чтл касается некое различие типов — это совсем не важно, ведь когда в Активный Оберон были добавлены комплексные типы, перечисления, беззнаковые, адрес, синтаксис определения типов остался тем же самым и язык также остался языком семейства Оберон.
В Модуле-3 также есть объявление переменных по месту(почти по месту) и вывод типа переменной по типу результата первого присваивания. Но, при этом oна осталась языком семейства Модула и синтаксис не изменился.
С такой логикой можно очень далеко уйти :-)
Ну, например: С++ получился из Си после того как в него добавили немножко типов и изменили систему типов, так что это тот же самый язык! C взял очень многое у Алгола-68, так что это считай алгол, Алгол-68 базируется на Алголе 60. В это же время Паскаль вырос из Алгола 60, а модула выросла из паскаля, а из Модулы получился тот самый, первый Оберон, ну а Активный Оберон это ж тоже тот же самый Оберон. Таки образом что? Правильно, С++ и Активный Оберон — это языки одного и того же семейства Алгол, очень-очень близкие языки. Почти одно и то же :-)
Но на самом деле нет. Си от С++ отличается очень и очень сильно (и хороший программист на Си не факт что сможет хорошо программировать на С++, и наоборот — С++ программисту придется серьезно переучиваться чтобы вменяемо писать на Си большие проекты). А С++98 значительно отличается от С++17 и это таки разные языки, хотя и с обратной совместимостью.
В линейке оберонов же обратной совместимости часто нет вовсе (исключение (с оговорками) Оберон изначальный и Оберон-2). КП а АО не совместим. О2 не совместим с КП, а Оберон 1990 не совместим с Обероном 2015. Это действительно разные языки, с точки зрения прикладного программиста разные.
Я уверен что многим может понравиться Активный Оберон, он действительно довольно современен и удобен. Те же математические расширения его могт весьма порадовать тех, кому в программах часто приходится иметь дело с матрицами (аля матлаб). Но, одновременно с этим, настолько же многим скорее всего не понравится писать на Обероне 2015 который делает, между прочим, Вирт (а Активный Оберон это все же не его детище).
Не нужно передёргивать — заимствовать концепции какого либо языка и быть основанным на нём — это совершенно разные вещи. Если ты этого не понимаешь — мне жаль, но не более того.
Что касается C++98, C++11, они остаются быть C++, сколько ты там цифр ни напиши и есть семейство языков C++, куда входят различные диалекты, равно как есть и семейство языков Оберон, куда входят разные Обероны.
И таки да, некоторые относят C++ к семейству Алгола, хотя синтаксис разный, но семантика ведь важнее, не правда ли?
Далее, про то, что модули есть только в Обероне и это придумка Вирта может говорить только человек далёкий от Оберона, к тому же очевидно же, что Оберон основан на модуле-2, это никто не скрывал, как раз наоборот. А так как он основан(а не заимствует) на модуле-2, то входит в семейство модулы, формируя, в тоже время, новое семейство языков Оберон и так далее. На сайте ETHZ есть официальная генеалогия языков Оберон, и заметь там написано Oberon Language Genealogy Tree
Слово семейство там нет, можно, конечно, сказать, что писали тупые, а Вирта обозвать эээ… неумным, но прежде этого стоит внести как минимум такой же вклад в развитие информационных технологий и научной школы, а учитывая, что в том числе его ученики и ученики его учеников и коллег, прошедшие школу Оберона и создают тот самый менстрим, то это выглядит как минимум глупо и смешно.
Что касается C++98, C++11, они остаются быть C++, сколько ты там цифр ни напиши и есть семейство языков C++, куда входят различные диалекты, равно как есть и семейство языков Оберон, куда входят разные Обероны.
И таки да, некоторые относят C++ к семейству Алгола, хотя синтаксис разный, но семантика ведь важнее, не правда ли?
Далее, про то, что модули есть только в Обероне и это придумка Вирта может говорить только человек далёкий от Оберона, к тому же очевидно же, что Оберон основан на модуле-2, это никто не скрывал, как раз наоборот. А так как он основан(а не заимствует) на модуле-2, то входит в семейство модулы, формируя, в тоже время, новое семейство языков Оберон и так далее. На сайте ETHZ есть официальная генеалогия языков Оберон, и заметь там написано Oberon Language Genealogy Tree
Слово семейство там нет, можно, конечно, сказать, что писали тупые, а Вирта обозвать эээ… неумным, но прежде этого стоит внести как минимум такой же вклад в развитие информационных технологий и научной школы, а учитывая, что в том числе его ученики и ученики его учеников и коллег, прошедшие школу Оберона и создают тот самый менстрим, то это выглядит как минимум глупо и смешно.
Ну, если уж мы занялись генеалогией, то следует заметить, что у ЯП нет генеалогического древа. У ЯП это будет абсолютно сумасшедший граф :-)
Поэтому, вообще говоря, таксономия из биологии, или же из генеалогии людей тут совершенно не применима.
Единственный четкий критерий который можно использовать для эмпирического выявления близости ЯП — это существует ли такая программа на языке А, которая также соберется и компилятором языка Б и будет корректно работать, и если существует, то насколько велика эта программа (в плане использования возможностей языка А (но тут мы сейчас упремся в определение что такое «языковая возможность» и как их считать)) может быть.
Это покажет насколько человеку придется переучиваться в плане написания кода при переходе с языка А на язык Б.
И еще один критерий, уже не столь четкий, и более субъективный, но вполне явно проявляющийся: насколько хорошие практики программирования на языке А применимы как хорошие практики для языка Б. То есть это покажет насколько сильно человеку придется переучиваться при переходе с одного ЯП на другой в плане архитектуры.
Ну а затем наоборот. Если наблюдается симметрия — то языки скорее всего содержат в себе общего «предка», или не содержат общего вовсе. Если наблюдается ассиметрия, значит кто-то из них, возможно, предок другого.
Как-то так.
PS. А «генеалогия» языков Оберон похоже перестала обновляться примерно в 2000 году. Там нет многих языков. Даже Zonnon'a нет (наверно Active Oberon for .net это его предшественник). И естественно там нет современного Оберона от Вирта.
Поэтому, вообще говоря, таксономия из биологии, или же из генеалогии людей тут совершенно не применима.
Единственный четкий критерий который можно использовать для эмпирического выявления близости ЯП — это существует ли такая программа на языке А, которая также соберется и компилятором языка Б и будет корректно работать, и если существует, то насколько велика эта программа (в плане использования возможностей языка А (но тут мы сейчас упремся в определение что такое «языковая возможность» и как их считать)) может быть.
Это покажет насколько человеку придется переучиваться в плане написания кода при переходе с языка А на язык Б.
И еще один критерий, уже не столь четкий, и более субъективный, но вполне явно проявляющийся: насколько хорошие практики программирования на языке А применимы как хорошие практики для языка Б. То есть это покажет насколько сильно человеку придется переучиваться при переходе с одного ЯП на другой в плане архитектуры.
Ну а затем наоборот. Если наблюдается симметрия — то языки скорее всего содержат в себе общего «предка», или не содержат общего вовсе. Если наблюдается ассиметрия, значит кто-то из них, возможно, предок другого.
Как-то так.
PS. А «генеалогия» языков Оберон похоже перестала обновляться примерно в 2000 году. Там нет многих языков. Даже Zonnon'a нет (наверно Active Oberon for .net это его предшественник). И естественно там нет современного Оберона от Вирта.
Хотя нет, тест не очень. Если я получу язык Б из языка А простым изменением синтаксиса (то есть даже грамматику менять не буду, просто лексемы другие выберу, например заменю все {} на begin end и далее по списку), то первый тест покажет нулевое пересечение, второй же покажет 100 процентное пересечение (но этот тест сложно назвать формальным).
Таким образом в этом, первом, тесте предусловием его прохождения является совпадение синтаксисов, что скучно и не правильно.
Возможно тут стоит иметь два этапа теста:
1) текст as is
2) интерпретация ast после приведения всех лексем и простых правил к единому виду для обоих языков (тут требуется уточнение).
Просто потому, что довольно глупо считать два языка соврешенно разными, если у них из отличий {} vs begin/end и := VS =
Таким образом в этом, первом, тесте предусловием его прохождения является совпадение синтаксисов, что скучно и не правильно.
Возможно тут стоит иметь два этапа теста:
1) текст as is
2) интерпретация ast после приведения всех лексем и простых правил к единому виду для обоих языков (тут требуется уточнение).
Просто потому, что довольно глупо считать два языка соврешенно разными, если у них из отличий {} vs begin/end и := VS =
Не стоит своё виденье мира выдавать за этот мир.
Генеалогическое дерево есть и у разговорных языков и у зыков программирования.
Генеалогическое дерево есть и у разговорных языков и у зыков программирования.
Откуда там дерево то? Это граф. Направленный и ацикличный, если считать что каждая новая ревизия языка это новый язык. У каждого узла графа несколько родителей и несколько потомков.
Либо это направленный граф с циклами, если новую ревизию языка (или новый стандарт) считать тем же языком.
Разве нет?
Либо это направленный граф с циклами, если новую ревизию языка (или новый стандарт) считать тем же языком.
Разве нет?
Нет. Я ведь тебе говорил, не стоит путать наследование с заимствованием.
В русском языке, есть заимствования, к примеру, из немецкого, французского, английского ..., но при этом он не стал ни немецким, ни французским, ни английским, ни каким то ещё, он остался русским.
В рамках семейства языков( тем более языков программирования ) чётко прослеживается дерево наследования, потому что, как ни крути, любой язык семейства основан на каком то языке этого же семейства. Именно это и отображает генеалогическое дерево в том числе генеалогическое дерево языков Оберон. Это не отменяет того факта, что заимствования могут быть даже в рамках языкового семейства, но не заимствования формируют дерево.
В рамках же взаимосвязей языковых семейств, действительно дерево может превратиться в граф, хотя и здесь можно выстроить именно дерево, зафиксировав соглашение, по каким признакам будет строиться дерево семейств языков.
В русском языке, есть заимствования, к примеру, из немецкого, французского, английского ..., но при этом он не стал ни немецким, ни французским, ни английским, ни каким то ещё, он остался русским.
В рамках семейства языков( тем более языков программирования ) чётко прослеживается дерево наследования, потому что, как ни крути, любой язык семейства основан на каком то языке этого же семейства. Именно это и отображает генеалогическое дерево в том числе генеалогическое дерево языков Оберон. Это не отменяет того факта, что заимствования могут быть даже в рамках языкового семейства, но не заимствования формируют дерево.
В рамках же взаимосвязей языковых семейств, действительно дерево может превратиться в граф, хотя и здесь можно выстроить именно дерево, зафиксировав соглашение, по каким признакам будет строиться дерево семейств языков.
добавлю, что каждый язык генеалогического дерева (узел) может сформировать своё семейство, выступая в качестве основы, что, в принципе, и происходит
Не всегда наследование «одиночное». Креольские языки
При разработке ЯП вообще никто не мешает взять и смешать фичи двух родителей хоть поровну.
При разработке ЯП вообще никто не мешает взять и смешать фичи двух родителей хоть поровну.
Речь больше о языках одного семейства, про возможность множественного наследования семейств я упомянул.
Тем не менее и креольские языки имеют одного предка — пиджин, если не ошибаюсь. к тому же, креольские языки это языковая семья
Тем не менее и креольские языки имеют одного предка — пиджин, если не ошибаюсь. к тому же, креольские языки это языковая семья
Язык программирования также всегда наследует черты одного предка, разбавляя их внешними заимствованиями. Язык также может вообще быть новаторским, формируя новую семью и не имея предка, но имея заимствования — сейчас это случается редко, но случается.
Однако, когда некий человек создаёт язык, не имея достаточной базы знаний для этого и, по сути, не представляя свой создаваемый язык в целом, даже не представляя что он представляет, тогда в процессе вынужденной эволюции(язык плохо спроектирован), он может измениться до неузнаваемости, и будет казаться, что вот «отсуда» унаследован, тогда как первоначально был «оттуда», но это только значит, что только сейчас у разработчика сформировалось видение архитектуры и концепции языка (возможно, под действием чьих-то пинков)
Однако, когда некий человек создаёт язык, не имея достаточной базы знаний для этого и, по сути, не представляя свой создаваемый язык в целом, даже не представляя что он представляет, тогда в процессе вынужденной эволюции(язык плохо спроектирован), он может измениться до неузнаваемости, и будет казаться, что вот «отсуда» унаследован, тогда как первоначально был «оттуда», но это только значит, что только сейчас у разработчика сформировалось видение архитектуры и концепции языка (возможно, под действием чьих-то пинков)
Оберон-07 создовался Виртом под свой конкретный проект — RISC процессор на FPGA. Простой процессор — простоя язык программирования, только те типы, которые напрямую отображаются на машину. Всё вместе — процессор с кодом verilog(сейчас на Lola-2), Компилятор и операционная система — это пособие для студентов, которое и используют в ETHZ (в принципе в качестве учебной ОС там могут использовать другую свою разработку — MINOS, по крайней мере в других курсах её используют).
Это учебный проект и личный интерес Вирта к FPGA.
Ещё раз — Оберон-07 создавался под конкретный проект, под конкретный процессор, и в языке есть только то, что требуется для этого проекта. Студенты могут легко изучить все разделы — разработка процессора, разработка компилятора, разработка операционной системы.
Поэтому претензии типа как на нём написать LibreOffice несколько несостоятельны.
Как-то так.
Это учебный проект и личный интерес Вирта к FPGA.
Ещё раз — Оберон-07 создавался под конкретный проект, под конкретный процессор, и в языке есть только то, что требуется для этого проекта. Студенты могут легко изучить все разделы — разработка процессора, разработка компилятора, разработка операционной системы.
Поэтому претензии типа как на нём написать LibreOffice несколько несостоятельны.
Как-то так.
Ну, во-первых это полуправда. Хотя бы потому, что операционная система Оберон от 2013 года не написани ни на Обероне ревизии 2007 года ни на Обероне ревизии 2013 или 2015 года. Там свой диалект (и именно поэтому мне пришлось компилятор Виртовский таки портировать).
А во-вторых если говорить о том Обероне что в Project Oberon 2013, то цели создания его ничем в общем то не отличаются от целей создания Оберона (и системы и языка) что вышел в 1989 году. Конкретный язык оптимизированный под данный конкретный проект, под конкретное железо и нужды. Цели идентичные — изначально Оберон был также писан потому и для того, чтобы было по чему преподавать и на чем тренеровать студентов. Но была и разница — тогда рабочии станции Ceres с Обероном на борту, насколько я понимаю, использовались еще и для почты внутри университета например.
Попытка же из Оберона сделать ЯП общего назначения (то есть не под конкретный проект) неизбежно его раздувает. В оригинальном ЯП Оберон описание 16 страниц, в Оберон-2 (а это уже первые шаги к народному ЯП) уже 26 + 50 страниц из Oakwood Guidelines (там уже и стандартная библиотека какая-то появляется + уточнения семантики и синтаксиса языка). Насколько я понимаю, Компонентный Паскаль и Активный Оберон (со всеми расширениями) еще сложнее и больше.
Но мы с тобой конечно смотрим на Оберон под разными углами — ты с точки зрения практического применения, ибо ты его активно применяешь в работе, поэтому у тебя Active Oberon, а я с точки зрения исследователя и копателя концепций, поэтому меня больше занимают именно виртовские Обероны — изначальный и вот свежий.
В плане оптимизации проекта по размеру и обозримости (и ЯП и ОС) Вирт безусловно добился отличных успехов. Тут если ему и есть равные, то я их не знаю.
В плане применимости на практике (то есть не для DIY, а именно промышленно, когда нужен прежде всего результат, а не процесс), видимо следует смотреть на то, что там делали уже ученики Вирта — Active Oberon, КП и проч.
А во-вторых если говорить о том Обероне что в Project Oberon 2013, то цели создания его ничем в общем то не отличаются от целей создания Оберона (и системы и языка) что вышел в 1989 году. Конкретный язык оптимизированный под данный конкретный проект, под конкретное железо и нужды. Цели идентичные — изначально Оберон был также писан потому и для того, чтобы было по чему преподавать и на чем тренеровать студентов. Но была и разница — тогда рабочии станции Ceres с Обероном на борту, насколько я понимаю, использовались еще и для почты внутри университета например.
Попытка же из Оберона сделать ЯП общего назначения (то есть не под конкретный проект) неизбежно его раздувает. В оригинальном ЯП Оберон описание 16 страниц, в Оберон-2 (а это уже первые шаги к народному ЯП) уже 26 + 50 страниц из Oakwood Guidelines (там уже и стандартная библиотека какая-то появляется + уточнения семантики и синтаксиса языка). Насколько я понимаю, Компонентный Паскаль и Активный Оберон (со всеми расширениями) еще сложнее и больше.
Но мы с тобой конечно смотрим на Оберон под разными углами — ты с точки зрения практического применения, ибо ты его активно применяешь в работе, поэтому у тебя Active Oberon, а я с точки зрения исследователя и копателя концепций, поэтому меня больше занимают именно виртовские Обероны — изначальный и вот свежий.
В плане оптимизации проекта по размеру и обозримости (и ЯП и ОС) Вирт безусловно добился отличных успехов. Тут если ему и есть равные, то я их не знаю.
В плане применимости на практике (то есть не для DIY, а именно промышленно, когда нужен прежде всего результат, а не процесс), видимо следует смотреть на то, что там делали уже ученики Вирта — Active Oberon, КП и проч.
Алексей, прекрати троллить.
В чём же я соврал то, что это правда только наполовину, если ты повторил мои слова?
Я ведь написал, что может быть Oberon System, а может быть MINOS. Для подтверждения этого заходим на сайт ETHZ в раздел Native Systems Group, находим там Jurg Gutknecht и Felix Friedrich, смотрим там учебные планы, темы и убеждаемся в сказанном мной.
Вот, кстати, пример (pdf) и т.п.
И видим там FPGA, A2, MINOS, Project Oberon и ссылки на Вирта и много чего, подтверждающее мои слова.
Ну а в плане использования, у на сне только A2 с Активным Оберонаом, но есть и Native Oberon с Обероном, для укправления производственной линией.
Так что да, интерес к Оберонам у меня не праздный.
А портирование(выполнено моим сотрудникам) нового Project Oberon на нашу железяку (VAX-11), было выполнено за два выходных, это довольно просто сделать для такого маленького и проработанного проекта.
В чём же я соврал то, что это правда только наполовину, если ты повторил мои слова?
Я ведь написал, что может быть Oberon System, а может быть MINOS. Для подтверждения этого заходим на сайт ETHZ в раздел Native Systems Group, находим там Jurg Gutknecht и Felix Friedrich, смотрим там учебные планы, темы и убеждаемся в сказанном мной.
Вот, кстати, пример (pdf) и т.п.
И видим там FPGA, A2, MINOS, Project Oberon и ссылки на Вирта и много чего, подтверждающее мои слова.
Ну а в плане использования, у на сне только A2 с Активным Оберонаом, но есть и Native Oberon с Обероном, для укправления производственной линией.
Так что да, интерес к Оберонам у меня не праздный.
А портирование(выполнено моим сотрудникам) нового Project Oberon на нашу железяку (VAX-11), было выполнено за два выходных, это довольно просто сделать для такого маленького и проработанного проекта.
Сергей, читай пожалуйста внимательнее то, что пишу я. Про полуправду — это было про язык на котором писан Project Oberon и язык Oberon rev 2007.
А портирование(выполнено моим сотрудникам) нового Project Oberon на нашу железяку (VAX-11), было выполнено за два выходных, это довольно просто сделать для такого маленького и проработанного проекта.
Любоптыно. А железка у вас с экраном/gui? А в важей железке тоже прерываний нет, или вы ими просто не пользуетесь? А если пользуетесь, то как реализовали их поддежрку в Project Oberon, ведь там их поддержки нет вовсе, да и язык тоже их не умеет.
Оберон-07, как и Оберон изначальный, это основа, базмс, минимально необходимое ядро, на котором строится необходимый инструментарий. Если сравнивать с процессорами, то Оберон это risc, а C++, это cisc подход. И Там и там можно решить одну и туже задачу, причём любую.
Исходя из этого, к базису( Оберон-07 ) можно добавит надстройку, получив в итоге такое же ядро для конкретной предметной области, что и сделано, например, в реализации Оберон-07 для ОС Minos, написанной на варианте этого языка. И в этом варианте языка и компилятора есть поддержка прерываний. И привязка процедуры к конкретному адресу в ОЗУ тоже есть.
Об этом я сужу по примерам кода для Minos в презентациях и планах лекций.
В нашем порте Project Oberon также нет прерываний — это простой порт практически один в один. Архитектура процессора позволят использовать программный ввод/вывод, без использования прерываний
Но небольшая прослойка между железом и ОС всё-таки есть. На плате нет никаких разъемов для монитора, да и экран подключить нельзя — всё отображается на удалённом компьютере, связанном с железкой Ethernet, WF, BT. Для удалённой отрисовки используется некий вариант ReGIS.
Исходя из этого, к базису( Оберон-07 ) можно добавит надстройку, получив в итоге такое же ядро для конкретной предметной области, что и сделано, например, в реализации Оберон-07 для ОС Minos, написанной на варианте этого языка. И в этом варианте языка и компилятора есть поддержка прерываний. И привязка процедуры к конкретному адресу в ОЗУ тоже есть.
Об этом я сужу по примерам кода для Minos в презентациях и планах лекций.
В нашем порте Project Oberon также нет прерываний — это простой порт практически один в один. Архитектура процессора позволят использовать программный ввод/вывод, без использования прерываний
Но небольшая прослойка между железом и ОС всё-таки есть. На плате нет никаких разъемов для монитора, да и экран подключить нельзя — всё отображается на удалённом компьютере, связанном с железкой Ethernet, WF, BT. Для удалённой отрисовки используется некий вариант ReGIS.
А портирование(выполнено моим сотрудникам) нового Project Oberon на нашу железяку (VAX-11), было выполнено за два выходных, это довольно просто сделать для такого маленького и проработанного проекта.
А кстати, ты ведь опять тут вводишь хабрасообщество в заблуждение. За два выходных получилось его портировать (Project Oberon 2013) в основном не потому что он такой маленький простой и хорошо описанный, а потому, что у вас уже был порт на вашу железяку (VAX-11) прежнего Project Oberon, а новый Project Oberon от старого не слишком отличается. Соответственно требовалась лишь адаптация порта под новую версию Project Oberon.
Насколько я помню, Вирт писал, что портирование Project Oberon на новую платформу занимало примерно по полгода работы. Но никак не два выходных.
Алексей, мы использовали Native Oberon(«использовали» — потому, что сейчас используем A2).
Естественно, что нигде использовать Project Oberon мы не будем — это было тестовое задание для нового сотрудника. И выполнил он его именно за два выходных дня.
Естественно, что нигде использовать Project Oberon мы не будем — это было тестовое задание для нового сотрудника. И выполнил он его именно за два выходных дня.
Ну вот оттуда видимо и перенесли те части в PO которые за VAX-11 отвечали. Без этого допил бекенда под VAX-11 и перенос системы занял бы как обычно — полгода. Как Вирт и писал.
Не стоит придумывать, я ведь всё написал
Ты не написал как именно порт Project Oberon 2013 осуществлялся, сказал лишь что за 2 выходных. Исходня из того, что у вас уже Native Oberon под VAX-11 уже был, я предположил что эти наработки как раз и использовались. Просто глупо не использовать эти наработки и этот опыт делая порт Project Oberon 2013 под VAX-11.
Разве нет?
Разве нет?
Коллеги Вирта вполне могли тратить полгода — явно основная часть времени у них уходила на учебный процесс, исследовательскую работу и т.п., на портирование оставалось всего ничего.
Ну, наврятли это все же делались за пару выходных за все эти полгода. Полагаю это все же как минимум 2-3 недели фултайма. Кроме того, Вирт в таком вот режиме, когда основную часть времени уходит на учебный процесс и т.п., написал первую ревизию Проекта Оберон за 2 года. Таким образом выходит, что ваш коллега вполне мог бы осилить проект оберон (из рассчета что два его выходных это примерно полгода работы профессора из Цюриха в свободное от основных занятий время) за 8 выходных.
Ну, либо твои коллеги на порядок профессиональней учеников и коллег Вирта, а также самого Вирта, и лучше разбираются как в чужом железе, так и в Обероне :-)
В общем, по моему, что-то не сходится.
Ну, либо твои коллеги на порядок профессиональней учеников и коллег Вирта, а также самого Вирта, и лучше разбираются как в чужом железе, так и в Обероне :-)
В общем, по моему, что-то не сходится.
>>В плане применимости на практике (то есть не для DIY, а именно промышленно, когда нужен прежде всего результат, а не процесс), видимо следует смотреть на то, что там делали уже ученики Вирта — Active Oberon, КП и проч.
Алексей, ещё раз повторю даже то, что ты сам написал, Project Oberon -это учебный и исследовательский проект, то, что плоды этого труда вдохновляют других людей на собственные исследования и творчество, используют для реального применения, говорит, что труд Вирта и его коллег был не пустым времяпровождением и не попыткой попила бюджетного бабла, что тоже вызывает уважение.
Алексей, ещё раз повторю даже то, что ты сам написал, Project Oberon -это учебный и исследовательский проект, то, что плоды этого труда вдохновляют других людей на собственные исследования и творчество, используют для реального применения, говорит, что труд Вирта и его коллег был не пустым времяпровождением и не попыткой попила бюджетного бабла, что тоже вызывает уважение.
Вот и перевод статьи одного из отцов основателей Go подоспел. Limbo в предках Go мы там не видим. Однако видим, что языки семейства Оберон там в качестве фундамента.
В данном случае мне нравится когда мухи отдельно, котлеты отдельно. И при этом чтобы компилятор проверял, что реализация модуля не противоречит его спецификации (иногда полезно разрабатывать отталкиваясь от спецификации на модуль, а не от реализации, то есть вначале пишем спеку, потом реализуем, причем по спеке можно также автоматически сгенерировать реализацию-заглушку).
Именно так и сделано в Ocaml — файлы разделяются на .mli и .ml. Первые содержат интерфейс модуля и комментарии, вторые — реализацию. Причём .mli можно самому не писать, компилятор их сам может генерировать. Но хорошим тоном считается всё же писать их руками (при этом можно сгенерить хедер компилятором, а потом поправить руками).
Мне вообще импонирует модульная система Ocaml, отчасти позаимствованная из Standard ML.
Да, в OCaml сделано хорошо. Единственное что мне в нем, пожалуй не нравится (в плане модульности) — это то, что чтобы использовать что-либо не нужно это самое что-либо ипортировать. То есть это как в java. Использовать можно сразу, только придется присать все префиксы.
Соответственно взглянув на реализацию модуля сразу нельзя сделать вывод от каких модулей он зависит. А видеть такое бывает полезно все же.
PS. На всякий случай: я за объявление переменных по месту использования, а не в единой могучей секции VAR :-)
Соответственно взглянув на реализацию модуля сразу нельзя сделать вывод от каких модулей он зависит. А видеть такое бывает полезно все же.
PS. На всякий случай: я за объявление переменных по месту использования, а не в единой могучей секции VAR :-)
На всякий случай: я за объявление переменных по месту использования, а не в единой могучей секции VAR :-)
На самом деле, когда смотришь много кода в вебе (например, в тулах для код-ревью), где нет умных IDE, потребность в явных квантификаторах для импорта приходит довольно скоро. Сразу осознаёшь, почему жабий
import pkg.*;, плюсовое using namespace xxx; или хаскелевский неквалифицированный import Data.XXX должны использоваться как можно реже, желательно никогда. Обязательные явные квалификаторы (с возможными алиасами) — одна из моих любимых фич golang.Сейчас набегут любители JetBrains и начнут тыкать меня в upsource и называть неосилятором IDE, но я по прежнему считаю, что код должен хорошо читаться без всяких IDE.
Ну, моя позиция тут следующая: если ты просто пишешь import Foo, тогда ты обязан любую сущность из Foo дергать вместе с префиксом, типа Foo.bar, если же ты при импорте явным образом указываешь список сущностей которые ты импортируешь (и только их), то можешь не указывать префикс. Типа import Foo (bar, baz) затем просто используешь bar.
Но нельзя использовать Foo.bar без импорта вообще, как это можно в ocaml и java. И нельзя после import Foo спокойно себе использовать bar без префикса вообще как во всяких сях и java.
IMHO
Но нельзя использовать Foo.bar без импорта вообще, как это можно в ocaml и java. И нельзя после import Foo спокойно себе использовать bar без префикса вообще как во всяких сях и java.
IMHO
Дак подобное было в Модуле-2, от которой произошел Оберон, Вирт специально это удалил в Обероне для упрощения языка и компилятора, чтобы любой студент мог разобраться, чтобы проще было портировать и компилятор и Обероне-Систему. И Оберон-Система была под все распространённые(и не очень) платформы, и как приложение хостовой ОС тоже.
Поэтому предъявлять по этому поводу претензии к Оберону не стоит, ибо это одна из главных концепций — простота и надёжность. Оберон никогда не претендовал на захват мира.
Поэтому предъявлять по этому поводу претензии к Оберону не стоит, ибо это одна из главных концепций — простота и надёжность. Оберон никогда не претендовал на захват мира.
В данном случае простота и надежность компилятора достигается за счет усложнения жизни всем тем, кто будет пользоваться языком. Ну, тоесть я мотивы Вирта вполне принимаю, и оно возможно было оправдано даже. Но это язык точно не сделало лучше для пользователей языка.
А что для программистов усложнилось? Для каких программистов?
Мы используем Оберон и Активный Оберон и как-то усложнения не ощущаем. Ты на Обероне не пишешь, ты тем более не можешь ощущать проблем и дискомфорта.
Мы используем Оберон и Активный Оберон и как-то усложнения не ощущаем. Ты на Обероне не пишешь, ты тем более не можешь ощущать проблем и дискомфорта.
Ты прекрасно знаешь, что периодически я на нем пишу. И еще чаще я читаю код на нем писанный.
Вообще, чтение кода штука значительно более частая чем написания кода, и вот с чтением у Оберона имеются определенные проблемы.
Если говорить о том сколько требуется усилий чтобы разобраться в коде написанного на разных языках в проекте более-менее осмысленного размера, то, по моему личному опыту получается примерно такой списочек (вначале идут ЯП в коде которых проще всего разобраться — где что лежит и как это поправить). Список не полный, и кроме этого, я сюда включил только императивные ЯП:
Напомню, что это список чисто субъективный, и основан на моем личном опыте.
С++(without stl/boost-like code) — это код С++ возможно с интенсивным использованием stl и boost, но не код этих библиотек сам по себе.
С++/templates (это как раз код stl или boost) на последнем месте не в последнюю очередь из за того, что там нет разделения на спецификацию и реализацию. Компилятор это не умеет.
Вообще, чтение кода штука значительно более частая чем написания кода, и вот с чтением у Оберона имеются определенные проблемы.
Если говорить о том сколько требуется усилий чтобы разобраться в коде написанного на разных языках в проекте более-менее осмысленного размера, то, по моему личному опыту получается примерно такой списочек (вначале идут ЯП в коде которых проще всего разобраться — где что лежит и как это поправить). Список не полный, и кроме этого, я сюда включил только императивные ЯП:
- Modula-2, Modula-3
- Ada (with generics too), ObjC, С, С++(without stl/boost-like code)
- Go, java, Oberon 1990/2015
- C++/templates (stl, boost, etc)
Напомню, что это список чисто субъективный, и основан на моем личном опыте.
С++(without stl/boost-like code) — это код С++ возможно с интенсивным использованием stl и boost, но не код этих библиотек сам по себе.
С++/templates (это как раз код stl или boost) на последнем месте не в последнюю очередь из за того, что там нет разделения на спецификацию и реализацию. Компилятор это не умеет.
Нет, Алексей, периодически писать код на Обероне в пару десятков строк, и от этого тебя ломает, не даёт основания писать, вводя других в заблуждение, что Оберон осложняет всем жизнь.
Я ведь не пишу в паблике, что С осложняет мне жизнь, когда я эпизодически пишу те же самые пару десятков строк и постоянно читаю большое количество кода — в языках C, C++ вообще сложно найти где находится файл инклюда, по крайней мере мне. Не, понятно, что правильно настроенная IDE может решить этот вопрос, ноя смотрю исходники в простом npp.
Очень удобно это сделано в компиляторе Оберона-2 OO2C — по сигнатуре заголовка модуля видно где он находится и где находятся подключаемые модули. Вот заголовок первого попавшегося модуля:
В Модуле-3, которая мне больше всего нравится, и которую мы активно используем, есть очень серьезная проблема с пониманием не только того, где находятся исходники модулей, но даже где находится реализация интерфейса, потому что реализация интерфейса может быть разбросана по разным модулям реализации. Да и сам интерфейс может состоять и нескольких интерфейсных модулей, предоставляя клиентам только необходимое(этим достигается и реализация механизма private и protected членов интерфейса). Только анализируя сборочный скрипт и используя поиск можно найти где что находится.
Тем не менее, это, пожалуй лучший язык семейства Модула и наследников.
Но ты так и не сказал, что же усложняет тебе жизнь в Обероне.
Я ведь не пишу в паблике, что С осложняет мне жизнь, когда я эпизодически пишу те же самые пару десятков строк и постоянно читаю большое количество кода — в языках C, C++ вообще сложно найти где находится файл инклюда, по крайней мере мне. Не, понятно, что правильно настроенная IDE может решить этот вопрос, ноя смотрю исходники в простом npp.
Очень удобно это сделано в компиляторе Оберона-2 OO2C — по сигнатуре заголовка модуля видно где он находится и где находятся подключаемые модули. Вот заголовок первого попавшегося модуля:
MODULE OOC:SSA;
IMPORT
SYSTEM, Log, Object, Object:Boxed, Object:BigInt, ADT:Dictionary,
Sym := OOC:SymbolTable, OOC:SymbolTable:Predef, OOC:IR,
OOC:SSA:Opcode, ResultClass := OOC:SSA:Result, OpndClass := OOC:SSA:Opnd;
В Модуле-3, которая мне больше всего нравится, и которую мы активно используем, есть очень серьезная проблема с пониманием не только того, где находятся исходники модулей, но даже где находится реализация интерфейса, потому что реализация интерфейса может быть разбросана по разным модулям реализации. Да и сам интерфейс может состоять и нескольких интерфейсных модулей, предоставляя клиентам только необходимое(этим достигается и реализация механизма private и protected членов интерфейса). Только анализируя сборочный скрипт и используя поиск можно найти где что находится.
Тем не менее, это, пожалуй лучший язык семейства Модула и наследников.
Но ты так и не сказал, что же усложняет тебе жизнь в Обероне.
Не-е, меня лично ломает писать на Matlab'e и js (больше всего кода я сейчас пишу как раз на матлабе). А вот ПИСАТЬ код на Обероне — от этого ломки нет (и Оберон я таки лучше знаю и легче на нем пишу, чем на Go, на котором я по работе пишу). А вот разбираться в Обероно-проектах, да, хуже чем в С++ или Аде и, тем более, на Модуле-3 (хотя на Аде я писал совсем-совсем мало, а на Модуле-3 не писал вовсе, но разбираться в исходниках на этих языках почему то проще. парадокс? ;-) )
А что именно осложняет разбираться в проектах на Обероне (а также Go, Java) я описал выше и довольно подробно. Не вижу смысла повторяться.
PS. И да, мне Модула-3 тоже очень нравится. Они же вроде сейчас затеяли сделать для нее llvm бекенд? Судя по активному шевелению в рассылке.
А что именно осложняет разбираться в проектах на Обероне (а также Go, Java) я описал выше и довольно подробно. Не вижу смысла повторяться.
PS. И да, мне Модула-3 тоже очень нравится. Они же вроде сейчас затеяли сделать для нее llvm бекенд? Судя по активному шевелению в рассылке.
>>А что именно осложняет разбираться в проектах на Обероне (а также Go, Java) я описал выше и довольно подробно. Не вижу смысла повторяться.
Вот и получается, что никакого страдания нет, а если оно у тебя есть, то связано не только см Обероном, но и другими языками. Ведь не назовёшь же серьёзной проблемой ЯЗЫКА непонимание где что находится в ПРОЕКТЕ? На любом языке, открыв чужой проект в каком нибудь нотепаде ( ты же обероновские модули в неком подобии нотепада сиотришь, когда для С++ используешь наdороченную и настроенную IDE?) нужно потратить время на то чтобы разобраться что где лежит, настроить ту самую супер IDE и вперёд.
Вот и получается, что никакого страдания нет, а если оно у тебя есть, то связано не только см Обероном, но и другими языками. Ведь не назовёшь же серьёзной проблемой ЯЗЫКА непонимание где что находится в ПРОЕКТЕ? На любом языке, открыв чужой проект в каком нибудь нотепаде ( ты же обероновские модули в неком подобии нотепада сиотришь, когда для С++ используешь наdороченную и настроенную IDE?) нужно потратить время на то чтобы разобраться что где лежит, настроить ту самую супер IDE и вперёд.
Вот и получается, что никакого страдания нет, а если оно у тебя есть, то связано не только см Обероном, но и другими языками. Ведь не назовёшь же серьёзной проблемой ЯЗЫКА непонимание где что находится в ПРОЕКТЕ?
Я как раз назову это (а точнее то, сколько усилий требуется чтобы разобраться что где в проекте находится и что с чем как связано, и как это все использовать) проблемой языка, причем весьма серьзеной. В модуле этой проблемы почти нет. В С++ (если оно не в стиле stl писано) тоже проблемы в общем то нет. В Аде — нет. А вот в Обероне, Го, Яве и C++ в стиле boost/stl — есть.
На любом языке, открыв чужой проект в каком нибудь нотепаде ( ты же обероновские модули в неком подобии нотепада сиотришь, когда для С++ используешь наdороченную и настроенную IDE?) нужно потратить время на то чтобы разобраться что где лежит, настроить ту самую супер IDE и вперёд.
Ошибаешься. В основном когда я разбираюсь в чужом проекте (не важно на каком он языке) я использую либо просто веб-просмотрщик github'a (или что-то аналогичное), либо что-то типа FAR'а (если в винде) либо grep + cat | less в юниксах. Вне зависимости от языка.
Если бы я говорил с учетом IDE, то java могла бы (но это вовсе не обязательно) переместиться на самый верх списка (у java прекрасные IDE), но она там, где она есть — рядышком с Обероном. Просто потому, что я не люблю зависить от того, за каким компьютером я сейчас сижу и какое окружение у меня сейчас настроено. Частенько я код читаю, и в нем разбираюсь вообще с планшета, где IDE нет вовсе никакой.
Тем более что если я умею разбираться в коде без IDE, то в IDE я тем более смогу сориентироваться, а вот если я привыкну использовать IDE, то без нее (или в другой IDE) может быть уже больно.
Ну и вообще, у меня обычно получается найти то что нужно в чужом проекте (без IDE) часто быстрее чем у людей знакомых с этим прокетом и с IDE ;-)
Чукча таки опытный читатель ;-)
Вот поэтому в постах и говори, что это ты от чего-то страдаешь, и уточняй от чего, а то ведь незнакомые с Оберон-технологией могут поверить в то, что ты пишешь и применить к языку Оберон, тогда как это нужно применять лишь к твоим собственным субъективным ощущениям, причём вообще с языком не связанным. А то, все, всем, для всех, у всех…
Кстати, портирование Оберон-компилятора (виртовского) с переписыванием кусков Оберон-системы под другую платформу, это вот программированием и написанием кода на Обероне не считается, правда? ;-) Ведь компилятор — это очень маленькая и простая штучка, в которой разобраться легко, а кусочки операционки — это вообще фигня.
Так что да, действительно, не пишу и не писал на Обероне :-) Совсем. Никогда.
PS. Но таки да, по работе я оберон действительно не использую. Это хобби и отличная моделька для изучения.
Так что да, действительно, не пишу и не писал на Обероне :-) Совсем. Никогда.
PS. Но таки да, по работе я оберон действительно не использую. Это хобби и отличная моделька для изучения.
Заглавная и прописная это одно и то же :-) Вы очевидно имели ввиду «заглавная или строчная».
В хаскеле тоже так, а видимость определяется явными списками экспорта. Таким же макаром можно абстрактные типы делать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Оберон умер, да здравствует Оберон! Часть 2. Модули