В данном случае простота и надежность компилятора достигается за счет усложнения жизни всем тем, кто будет пользоваться языком. Ну, тоесть я мотивы Вирта вполне принимаю, и оно возможно было оправдано даже. Но это язык точно не сделало лучше для пользователей языка.
Ну, моя позиция тут следующая: если ты просто пишешь import Foo, тогда ты обязан любую сущность из Foo дергать вместе с префиксом, типа Foo.bar, если же ты при импорте явным образом указываешь список сущностей которые ты импортируешь (и только их), то можешь не указывать префикс. Типа import Foo (bar, baz) затем просто используешь bar.
Но нельзя использовать Foo.bar без импорта вообще, как это можно в ocaml и java. И нельзя после import Foo спокойно себе использовать bar без префикса вообще как во всяких сях и java.
Откуда там дерево то? Это граф. Направленный и ацикличный, если считать что каждая новая ревизия языка это новый язык. У каждого узла графа несколько родителей и несколько потомков.
Либо это направленный граф с циклами, если новую ревизию языка (или новый стандарт) считать тем же языком.
Хотя нет, тест не очень. Если я получу язык Б из языка А простым изменением синтаксиса (то есть даже грамматику менять не буду, просто лексемы другие выберу, например заменю все {} на begin end и далее по списку), то первый тест покажет нулевое пересечение, второй же покажет 100 процентное пересечение (но этот тест сложно назвать формальным).
Таким образом в этом, первом, тесте предусловием его прохождения является совпадение синтаксисов, что скучно и не правильно.
Возможно тут стоит иметь два этапа теста:
1) текст as is
2) интерпретация ast после приведения всех лексем и простых правил к единому виду для обоих языков (тут требуется уточнение).
Просто потому, что довольно глупо считать два языка соврешенно разными, если у них из отличий {} vs begin/end и := VS =
Ну, если уж мы занялись генеалогией, то следует заметить, что у ЯП нет генеалогического древа. У ЯП это будет абсолютно сумасшедший граф :-)
Поэтому, вообще говоря, таксономия из биологии, или же из генеалогии людей тут совершенно не применима.
Единственный четкий критерий который можно использовать для эмпирического выявления близости ЯП — это существует ли такая программа на языке А, которая также соберется и компилятором языка Б и будет корректно работать, и если существует, то насколько велика эта программа (в плане использования возможностей языка А (но тут мы сейчас упремся в определение что такое «языковая возможность» и как их считать)) может быть.
Это покажет насколько человеку придется переучиваться в плане написания кода при переходе с языка А на язык Б.
И еще один критерий, уже не столь четкий, и более субъективный, но вполне явно проявляющийся: насколько хорошие практики программирования на языке А применимы как хорошие практики для языка Б. То есть это покажет насколько сильно человеку придется переучиваться при переходе с одного ЯП на другой в плане архитектуры.
Ну а затем наоборот. Если наблюдается симметрия — то языки скорее всего содержат в себе общего «предка», или не содержат общего вовсе. Если наблюдается ассиметрия, значит кто-то из них, возможно, предок другого.
Как-то так.
PS. А «генеалогия» языков Оберон похоже перестала обновляться примерно в 2000 году. Там нет многих языков. Даже Zonnon'a нет (наверно Active Oberon for .net это его предшественник). И естественно там нет современного Оберона от Вирта.
Да, в OCaml сделано хорошо. Единственное что мне в нем, пожалуй не нравится (в плане модульности) — это то, что чтобы использовать что-либо не нужно это самое что-либо ипортировать. То есть это как в java. Использовать можно сразу, только придется присать все префиксы.
Соответственно взглянув на реализацию модуля сразу нельзя сделать вывод от каких модулей он зависит. А видеть такое бывает полезно все же.
PS. На всякий случай: я за объявление переменных по месту использования, а не в единой могучей секции VAR :-)
Сейчас стоит просто Оберон и это правильно, ибо это всё Обероны, включая Компонентный Паскаль( о чём, опять же, явно пишут его создатели, приложившие руку и к созданию Оберона-2, тем более, что и компилятор там от Оберона-2).
…
Чтл касается некое различие типов — это совсем не важно, ведь когда в Активный Оберон были добавлены комплексные типы, перечисления, беззнаковые, адрес, синтаксис определения типов остался тем же самым и язык также остался языком семейства Оберон.
В Модуле-3 также есть объявление переменных по месту(почти по месту) и вывод типа переменной по типу результата первого присваивания. Но, при этом oна осталась языком семейства Модула и синтаксис не изменился.
С такой логикой можно очень далеко уйти :-)
Ну, например: С++ получился из Си после того как в него добавили немножко типов и изменили систему типов, так что это тот же самый язык! C взял очень многое у Алгола-68, так что это считай алгол, Алгол-68 базируется на Алголе 60. В это же время Паскаль вырос из Алгола 60, а модула выросла из паскаля, а из Модулы получился тот самый, первый Оберон, ну а Активный Оберон это ж тоже тот же самый Оберон. Таки образом что? Правильно, С++ и Активный Оберон — это языки одного и того же семейства Алгол, очень-очень близкие языки. Почти одно и то же :-)
Но на самом деле нет. Си от С++ отличается очень и очень сильно (и хороший программист на Си не факт что сможет хорошо программировать на С++, и наоборот — С++ программисту придется серьезно переучиваться чтобы вменяемо писать на Си большие проекты). А С++98 значительно отличается от С++17 и это таки разные языки, хотя и с обратной совместимостью.
В линейке оберонов же обратной совместимости часто нет вовсе (исключение (с оговорками) Оберон изначальный и Оберон-2). КП а АО не совместим. О2 не совместим с КП, а Оберон 1990 не совместим с Обероном 2015. Это действительно разные языки, с точки зрения прикладного программиста разные.
Я уверен что многим может понравиться Активный Оберон, он действительно довольно современен и удобен. Те же математические расширения его могт весьма порадовать тех, кому в программах часто приходится иметь дело с матрицами (аля матлаб). Но, одновременно с этим, настолько же многим скорее всего не понравится писать на Обероне 2015 который делает, между прочим, Вирт (а Активный Оберон это все же не его детище).
Описание типов в обероне ничем не отличается от того, что было раньше его, в той же Аде например, или даже паскале, или в Mesa. При этом, у Го система типов другая, следовательно и объявления все же другие. Даже синтаксически.
Объявления переменных в Go откровенно другие — местами это похоже на Оберон или Аду, местами нет. Например в Go активно переменные объявляются по месту и без анотации типов.
А концепция модулей и пакетов, как я уже говорил, во-первых отличается, а во-вторых опять таки, в этом Обероне тоже не уникален. До него была Ада и Модула-2, а до Модулы-2 была Mesa.
Единственное что действительно у Go очень похоже на Оберон-2 (но не Оберон) — это синтаксис объявления методов (ака процедур связанных с типом). Но семантика там все же другая.
Ну и естественно на Го намного больше повлиял Limbo — это по сути прямой предшественник Го. Питон тоже повлиял, и еще пачка разных других языков.
Есть и свои, уникальные находки.
Это все в совокупности делает Go новым, самостоятельным языком. Не иеальным естественно, но и не клоном какого-либо сущствующего языка. И уж точно это не Оберон с сишным синтаксисом.
PS. Да, а синтаксис таки вторичен. Семантика языка всегда важнее.
Go is mostly in the C family (basic syntax), with significant
input from the Pascal/Modula/Oberon family (declarations, packages), (дальше про другие языки)
То есть они в основном посмотрели у оберона немного синтаксиса объявлений (переменных, типов), и по факту его модифицировали и применили, а также модульную систему.
Но тут конечно есть нюанс в том, что ни синтаксис объявлений ни модульная система в принципе не уникальны у Оберона. Есть языки которые были раньше с тем же, есть языки которые были позже. Оберон просто наиболее простой из них (скорее всего).
Кроме того, те же модули у Го и Оберона действительно сильно отличаются. У Оберона модуль это обычно единица компиляции и загрузки-выгрузки. У Го — нет (а динамической загрузки-выгрузки там нет вовсе, сейчас компоновка только статическая). В обероне один модуль == один файл исходника. В Го пакет — это множество исходников в одном каталоге.
При этом вот лично мне и в Го и в Обероне не нравится как сделан экспорт сущностей из модуля/пакета. Там просто инлайн мелкая пометка (в Го — заглавная-строчкая буква идентификатора сущности, в Обероне — * ). Соответственно если например смотришь где-то исходники, где нельзя использовать дополнительный инструментарий (на гитхабе например), то приходится прочесывать всю реализацию чтобы понять что именно оно там экспортирует. Мне больше нравится когда перечень экспорта оформлен отдельно. В идеале — как в Аде например. Писать дольше, но читать и разбираться в исходниках потом намного проще.
При этом автогенерация спецификаций модуля по исходнику мне тоже не нравится — либо там не будет коментариев (коментариев именно к спецификации относящейся) либо в реализацию модуля придется забивать комментариями которые нужны для спецификации, но не для реализации.
В данном случае мне нравится когда мухи отдельно, котлеты отдельно. И при этом чтобы компилятор проверял, что реализация модуля не противоречит его спецификации (иногда полезно разрабатывать отталкиваясь от спецификации на модуль, а не от реализации, то есть вначале пишем спеку, потом реализуем, причем по спеке можно также автоматически сгенерировать реализацию-заглушку).
Погоди, а это не ты ли на RSDN с годик назад искал какого-нибудь оберонщика на тему правки древних-древних сырцов оберона? ( http://rsdn.ru/forum/job/5715649.all )
Вообще, полагаю, можно сделать так, чтобы Оберон среда запускалась, что-то делала (аргументы что именно делать — передавать в виде аргументов, или же таки через файл) и сразу вырубалась. Какая именно версия используется?
Использова Active Oberon в линуксе или винде можно, примерно также как можно использовать смалтолк/squeak. Хотя Kemet лучше расскажет, возможно там есть реализации которые не тащат с собой например всю среду.
В плане любых оберонов — там разное бывает. Во-первых есть реализации ОС Оберон в виде приложения (не эмулятора, а именно приложения, опять же, привет smalltalk/squeak только с учетом того, что Оберон компиляется в реальные машкоды целевой архитектуры, например x86 — никаких эмуляторов). А во-вторых довольно много самых разных компиляторов оберона и оберона-2, как в x86, так и в Си например.
То есть Оберон (не Active — про Active я лично просто не в курсе) бывает без среды под винду или линукс. В качестве IDE были какие-то плагины к eclipse, ну или можно использовать Sublime Text. Мною к sublime был даже плагин писан для того, чтобы было удобней код набирать (в частности ключевые слова там становились КАПСОМ автоматом, не нужно никаких шифтов жать).
Ну, я же про матлаб и векторизацию и написал :-) Сам на нем пишу по работе (у нас стартап, так что и на матлабе писать надо, и приложение под IOS, и код для сервера, так что каждый и жнец и жрец и на трубе игрец). Что-то там можно сделать очень производительным (и с автоматическим распараллеливанием), а что-то нет (приходится на С++ писать модуль).
Вообще, в науке нет какого-то единого инструмента на все случаи жизни, Марков (http://macroevolution.livejournal.com/ ) вон вообще на VisualBasic for Excel писал обработку экспериментов например :-)
Поэтому даже BlackBox вполне себе применяется и некоторыми весьма успешно. Помню Иван Денисов демонстрировал автоматизированный лабораторный журнал на базе BlackBox — действительно весьма удобно получилось.
Но нельзя использовать Foo.bar без импорта вообще, как это можно в ocaml и java. И нельзя после import Foo спокойно себе использовать bar без префикса вообще как во всяких сях и java.
IMHO
Либо это направленный граф с циклами, если новую ревизию языка (или новый стандарт) считать тем же языком.
Разве нет?
Таким образом в этом, первом, тесте предусловием его прохождения является совпадение синтаксисов, что скучно и не правильно.
Возможно тут стоит иметь два этапа теста:
1) текст as is
2) интерпретация ast после приведения всех лексем и простых правил к единому виду для обоих языков (тут требуется уточнение).
Просто потому, что довольно глупо считать два языка соврешенно разными, если у них из отличий {} vs begin/end и := VS =
Поэтому, вообще говоря, таксономия из биологии, или же из генеалогии людей тут совершенно не применима.
Единственный четкий критерий который можно использовать для эмпирического выявления близости ЯП — это существует ли такая программа на языке А, которая также соберется и компилятором языка Б и будет корректно работать, и если существует, то насколько велика эта программа (в плане использования возможностей языка А (но тут мы сейчас упремся в определение что такое «языковая возможность» и как их считать)) может быть.
Это покажет насколько человеку придется переучиваться в плане написания кода при переходе с языка А на язык Б.
И еще один критерий, уже не столь четкий, и более субъективный, но вполне явно проявляющийся: насколько хорошие практики программирования на языке А применимы как хорошие практики для языка Б. То есть это покажет насколько сильно человеку придется переучиваться при переходе с одного ЯП на другой в плане архитектуры.
Ну а затем наоборот. Если наблюдается симметрия — то языки скорее всего содержат в себе общего «предка», или не содержат общего вовсе. Если наблюдается ассиметрия, значит кто-то из них, возможно, предок другого.
Как-то так.
PS. А «генеалогия» языков Оберон похоже перестала обновляться примерно в 2000 году. Там нет многих языков. Даже Zonnon'a нет (наверно Active Oberon for .net это его предшественник). И естественно там нет современного Оберона от Вирта.
Соответственно взглянув на реализацию модуля сразу нельзя сделать вывод от каких модулей он зависит. А видеть такое бывает полезно все же.
PS. На всякий случай: я за объявление переменных по месту использования, а не в единой могучей секции VAR :-)
С такой логикой можно очень далеко уйти :-)
Ну, например: С++ получился из Си после того как в него добавили немножко типов и изменили систему типов, так что это тот же самый язык! C взял очень многое у Алгола-68, так что это считай алгол, Алгол-68 базируется на Алголе 60. В это же время Паскаль вырос из Алгола 60, а модула выросла из паскаля, а из Модулы получился тот самый, первый Оберон, ну а Активный Оберон это ж тоже тот же самый Оберон. Таки образом что? Правильно, С++ и Активный Оберон — это языки одного и того же семейства Алгол, очень-очень близкие языки. Почти одно и то же :-)
Но на самом деле нет. Си от С++ отличается очень и очень сильно (и хороший программист на Си не факт что сможет хорошо программировать на С++, и наоборот — С++ программисту придется серьезно переучиваться чтобы вменяемо писать на Си большие проекты). А С++98 значительно отличается от С++17 и это таки разные языки, хотя и с обратной совместимостью.
В линейке оберонов же обратной совместимости часто нет вовсе (исключение (с оговорками) Оберон изначальный и Оберон-2). КП а АО не совместим. О2 не совместим с КП, а Оберон 1990 не совместим с Обероном 2015. Это действительно разные языки, с точки зрения прикладного программиста разные.
Я уверен что многим может понравиться Активный Оберон, он действительно довольно современен и удобен. Те же математические расширения его могт весьма порадовать тех, кому в программах часто приходится иметь дело с матрицами (аля матлаб). Но, одновременно с этим, настолько же многим скорее всего не понравится писать на Обероне 2015 который делает, между прочим, Вирт (а Активный Оберон это все же не его детище).
Объявления переменных в Go откровенно другие — местами это похоже на Оберон или Аду, местами нет. Например в Go активно переменные объявляются по месту и без анотации типов.
А концепция модулей и пакетов, как я уже говорил, во-первых отличается, а во-вторых опять таки, в этом Обероне тоже не уникален. До него была Ада и Модула-2, а до Модулы-2 была Mesa.
Единственное что действительно у Go очень похоже на Оберон-2 (но не Оберон) — это синтаксис объявления методов (ака процедур связанных с типом). Но семантика там все же другая.
Ну и естественно на Го намного больше повлиял Limbo — это по сути прямой предшественник Го. Питон тоже повлиял, и еще пачка разных других языков.
Есть и свои, уникальные находки.
Это все в совокупности делает Go новым, самостоятельным языком. Не иеальным естественно, но и не клоном какого-либо сущствующего языка. И уж точно это не Оберон с сишным синтаксисом.
PS. Да, а синтаксис таки вторичен. Семантика языка всегда важнее.
То есть они в основном посмотрели у оберона немного синтаксиса объявлений (переменных, типов), и по факту его модифицировали и применили, а также модульную систему.
Но тут конечно есть нюанс в том, что ни синтаксис объявлений ни модульная система в принципе не уникальны у Оберона. Есть языки которые были раньше с тем же, есть языки которые были позже. Оберон просто наиболее простой из них (скорее всего).
Кроме того, те же модули у Го и Оберона действительно сильно отличаются. У Оберона модуль это обычно единица компиляции и загрузки-выгрузки. У Го — нет (а динамической загрузки-выгрузки там нет вовсе, сейчас компоновка только статическая). В обероне один модуль == один файл исходника. В Го пакет — это множество исходников в одном каталоге.
При этом вот лично мне и в Го и в Обероне не нравится как сделан экспорт сущностей из модуля/пакета. Там просто инлайн мелкая пометка (в Го — заглавная-строчкая буква идентификатора сущности, в Обероне — * ). Соответственно если например смотришь где-то исходники, где нельзя использовать дополнительный инструментарий (на гитхабе например), то приходится прочесывать всю реализацию чтобы понять что именно оно там экспортирует. Мне больше нравится когда перечень экспорта оформлен отдельно. В идеале — как в Аде например. Писать дольше, но читать и разбираться в исходниках потом намного проще.
При этом автогенерация спецификаций модуля по исходнику мне тоже не нравится — либо там не будет коментариев (коментариев именно к спецификации относящейся) либо в реализацию модуля придется забивать комментариями которые нужны для спецификации, но не для реализации.
В данном случае мне нравится когда мухи отдельно, котлеты отдельно. И при этом чтобы компилятор проверял, что реализация модуля не противоречит его спецификации (иногда полезно разрабатывать отталкиваясь от спецификации на модуль, а не от реализации, то есть вначале пишем спеку, потом реализуем, причем по спеке можно также автоматически сгенерировать реализацию-заглушку).
Собственно я как раз недавно это все дело листал. Потихоньку пытаюсь собрать материал, как-то упорядочить и написать таки статью.
Вообще, полагаю, можно сделать так, чтобы Оберон среда запускалась, что-то делала (аргументы что именно делать — передавать в виде аргументов, или же таки через файл) и сразу вырубалась. Какая именно версия используется?
Скажи что нужно, расскажем что есть, а чего нет, но что есть вместо этого.
Именно Активный. Active Oberon это отдельный ЯП, дальнейшее развитие системы и языка в стенах Швейцарской высшей технической школы Цюриха
Использова Active Oberon в линуксе или винде можно, примерно также как можно использовать смалтолк/squeak. Хотя Kemet лучше расскажет, возможно там есть реализации которые не тащат с собой например всю среду.
В плане любых оберонов — там разное бывает. Во-первых есть реализации ОС Оберон в виде приложения (не эмулятора, а именно приложения, опять же, привет smalltalk/squeak только с учетом того, что Оберон компиляется в реальные машкоды целевой архитектуры, например x86 — никаких эмуляторов). А во-вторых довольно много самых разных компиляторов оберона и оберона-2, как в x86, так и в Си например.
То есть Оберон (не Active — про Active я лично просто не в курсе) бывает без среды под винду или линукс. В качестве IDE были какие-то плагины к eclipse, ну или можно использовать Sublime Text. Мною к sublime был даже плагин писан для того, чтобы было удобней код набирать (в частности ключевые слова там становились КАПСОМ автоматом, не нужно никаких шифтов жать).
Насколько я знаю, в его компании промышленно используют Active Oberon (а еще Модулу-3 например).
То есть, выходит, семантическу многих конструкций определяет в нем что-то типа прагм или аннотаций по месту?
У XEROX Park было три лагеря: lisp, smalltalk, mesa. Cedar является результатом их совместной работы и консенсуса.
При этом lisp'овцы работали на мейнфреймах, а smalltalk и mesa, а в последствии и Cedar — это уже все было уже на персоналках (ака рабочих станциях).
То есть никаких мейнфреймов.
Вообще, в науке нет какого-то единого инструмента на все случаи жизни, Марков (http://macroevolution.livejournal.com/ ) вон вообще на VisualBasic for Excel писал обработку экспериментов например :-)
Поэтому даже BlackBox вполне себе применяется и некоторыми весьма успешно. Помню Иван Денисов демонстрировал автоматизированный лабораторный журнал на базе BlackBox — действительно весьма удобно получилось.