Понятия не имею в чем там тяжесть, ведь это ж не я переходил. По работе я использую как минимум три разных языка программирования (это при условии что C, C++, Objective C считать за один язык), поэтому для меня новый язык обычно проблемой не является.
По моему ты усложняешь. Для азов алгоритмики достаточно знать что такое целое число и что такое массивы. Затем что такое указатели, да (для тех же деревьев). Но указатели в Обероне это не то же страшное аццкое существо, что в нашем с тобой любимом С++, там это по сути ссылки (нет арифметики указателей, их нельзя инкрементировать, нет крышесносных звездочек, амперсандов и прочего страшного). Ну и record'ы. Всё. больше типов для изучения алгоритмов и структур данных не нужно.
Программист должен не должен намертво привязваться к одному единственному языку. Так или иначе в течение своей карьеры приходится переходить с языка на язык. Поэтому будет очень хорошо, если после оберона человек изучит и попробует что-то еще.
Если первый язык большой. тяжелый и фичастый, при его изучении было потрачено много сил, и вроде бы нет повода с него переходить на какой-то другой, то тогда, когда программисту таки придется поменять язык (лет через 15 возможно), это сделать ему будет очень сложно. Я наблюдал как народ проработавший в делфях по 10-15 лет потом переходил на другие языки — им было тяжко.
Поэтому один из уроков который должен обучающийся вынести — нельзя зацикливаться на одном единственном языке.
Во-первых проблемы Оберона с 64битностью не зависят от того, какой именно это процессор — x86_64, IA64 или какая-нибудь Alpha.
Во-вторых про Windows никто и не писал. Откровенно говоря, у меня лично опыта программирования, да и опыта использования Windows меньше чем под иные системы.
А проблемы с 64битностью следующие — половина языков Оберон-семейства (КП, Оберон-07) так или иначе имеют жесткую привязку примитивных типов к разрядности. (в последней ревизии Оберона-07 вообще смешно — Вирт отвязал INTEGER от разрядности в явном виде, но оставил привязку SET к 32 битам, а SET напрямую связан с INTEGER, таким образом и INTEGER оказался привязан к 32 битам) Соответственно для переезда на 64 бита следует изменять язык. В качестве иллюстрации приведу пример обсуждения о миграции BlackBox Component Builder на 64 бита (обсуждаются собственно вопросы языка, а не, скажем, кодогенерации): forum.oberoncore.ru/viewtopic.php?f=2&t=2439
У тех же языков Оберон-семейства, где нет жесткой привязки базовых типов к разрядности (Оберон, Оберон-2) остаются проблемы во-первых с псевдомодулем SYSTEM (который, как показывает практика, частенько используется при практическом программировании), а во-вторых с тем, что в них нельзя указать явным образом указать какой диапазон тебе требуется для переменной. Ну, то есть нельзя сказать что вот эта вот переменная i должна быть хотя бы 32битной. Эта проблема собственно вытекает от принципиального отсутствия стандартной библиотеки в Оберонах, соответственно в них нет ничего напоминающего stdint.h.
Все это приводит к не переносимости в общем случае приложений да и просто реализаций алгоритмов с 32битной машины на 64битную.
Сейчас в плане 64битности дальше всех продвинулась OS A2 с языком Active Oberon. Там наконец ввели тип ADDRESS, ну и многие другие неприятные мелочи устранили. Собственно нативная OS A2 под 64 битами вполне бегает, осталось сделать биндинги для 64битной версии A2 for Windows, чтобы всю эту радость можно было запускать под виндами также, как 32биную версию (операционка A2 характеризуется тем, что может быть не только полновесной операционкой работающей с железом непосредственно, но и выглядеть как обычное приложение скажем в виндах, без эмуляторов, впрочем это вообще типично для Оберон-операционок). Собственно одно российское предприятие (коммерческое, да. не университет), которое активно использует Active Oberon и A2 в своей работе, думаю вскоре сделает эти биндинги :-)
Уж что-что а лисп, а тем более его более легковесные диалекты вроде Scheme, должен понять с лету любой грамотный инженер. Синтаксис там элементарный (ибо он практически отсутствует). А на счет семантики конструкций все равно в доку надо вначале посмотреть. Потому как совершенно интуитивно не ясно что делает например statement WITH в Обероне-2. И что означают именя процедур со звездочкой.
Короче, в доку все равно смотреть надо и там и там. Проще будет то, что больше похоже на то, с чем ты работал. Новичку же — будет одинаково что Оберон, что Scheme, ибо это и будет его начальная точка отсчета.
Прям таки компилятора который сразу компилит в x86_64 я не припомню. Есть трансляторы из Оберона в Си, и этот код, возможно, можно нормально собрать уже под 64 (но я не помню чтобы кто-то делал такие эксперименты). Ну и есть компиляторы под jvm и .net, и там уже через jit будет 64 битный код.
Но вообще, сейчас потихоньку движется одновременно для нескольких компиляторов работа по прикручиванию llvm-бекенда, как прикрутится, так будет и 64 бита, и вообще кодогенерация станет более качественной.
Ну, во-первых это все уже было сто раз. См UML, и см. rational rose, которая вообще по исходнику все эти графические модели строила. Не взлетело. То есть взлетело, но не стало всеобъемлющим, живет в своей узкой нише.
Дело в том, что программа многомерна. В 2D хорошо отображается лишь то, что и так просто и имеет мало элементов (например самый верхний уровень архитектуры). Об этом писал еще Брукс в своем мифическом человекомесяце.
Я планировал вдумчивую серию статей на хабре про то откуда взялся оберон (начиная с Оберон ОС), как развивался и на что годится сейчас. С его плюсами и минусами. Объективная такая серия статей, без фанатизма. Это серия статей обсуждалась и готовилась на нашем форуме. А этот вот товарищ, автор данной статьи, увидел идею публикации и быстренько накатал вот это, сильно смахивающее на рекламную брошюру обильно сдобренную ссылками на свой собственный форум, видимо в рассчете на приток новых участников на оный.
Так что мне приходится отдуваться пока в комментах.
Ну это ж красота — штука весьма субъективная. Равно как и минимализм (где тот порог, где уже не минималистичность, а примитивизм?). Кому то и С++ красиый минималистичный язык :-)
В паскале все же не было наследования у RECORD'ов, да и сборщика мусора не водилось. Кроме того, в Оберонах принято (хотя это и не обязательно) также в рантайме иметь некую метаинформацию о модулях, переменных и прочем — то есть есть рефлексия. Часто также есть возможность динамической загрузки и выгрузки отдельного модуля.
Вообще, отличным инструментом для обучения является тот инструмент, на котором обучаемый (ну, например ребенок) может (возможно с помощью учителя) быстро сделать что-то интересное (интересное для него) и наглядное. Это дико мотивирует продолжать обучаться дальше.
Так вот, у Оберонов с этим вроде бы как раз все хорошо:
BlackBox CB (Component Pascal) позволяет наглядно (через те самые составные документы) делать интерактивные живые графические штуки, не парясь особо о формах, и прочем. Сделать виртуального робота ездящего по полю и для него же тут рядом сделать пультр управления — да легко!
Astrobe (Oberon-07/11) позволяет запрограммировать микроконтроллер. И тут уже можно ездить реальным роботом, управлять реальными физическими объектами. Причем алгоритмический код у Компонентного Паскаля и Оберона-07, вообще говоря может быть один и тот же (есть некое базовое подмножество statement'ов, где они совместимы). Скажем программа управления роботом может как управлять им в BlackBox'е так и работать в микроконтроллере и управлять реальной железной штукой.
Так что тут не будет проблем.
Если первый язык большой. тяжелый и фичастый, при его изучении было потрачено много сил, и вроде бы нет повода с него переходить на какой-то другой, то тогда, когда программисту таки придется поменять язык (лет через 15 возможно), это сделать ему будет очень сложно. Я наблюдал как народ проработавший в делфях по 10-15 лет потом переходил на другие языки — им было тяжко.
Поэтому один из уроков который должен обучающийся вынести — нельзя зацикливаться на одном единственном языке.
Во-вторых про Windows никто и не писал. Откровенно говоря, у меня лично опыта программирования, да и опыта использования Windows меньше чем под иные системы.
А проблемы с 64битностью следующие — половина языков Оберон-семейства (КП, Оберон-07) так или иначе имеют жесткую привязку примитивных типов к разрядности. (в последней ревизии Оберона-07 вообще смешно — Вирт отвязал INTEGER от разрядности в явном виде, но оставил привязку SET к 32 битам, а SET напрямую связан с INTEGER, таким образом и INTEGER оказался привязан к 32 битам) Соответственно для переезда на 64 бита следует изменять язык. В качестве иллюстрации приведу пример обсуждения о миграции BlackBox Component Builder на 64 бита (обсуждаются собственно вопросы языка, а не, скажем, кодогенерации): forum.oberoncore.ru/viewtopic.php?f=2&t=2439
У тех же языков Оберон-семейства, где нет жесткой привязки базовых типов к разрядности (Оберон, Оберон-2) остаются проблемы во-первых с псевдомодулем SYSTEM (который, как показывает практика, частенько используется при практическом программировании), а во-вторых с тем, что в них нельзя указать явным образом указать какой диапазон тебе требуется для переменной. Ну, то есть нельзя сказать что вот эта вот переменная i должна быть хотя бы 32битной. Эта проблема собственно вытекает от принципиального отсутствия стандартной библиотеки в Оберонах, соответственно в них нет ничего напоминающего stdint.h.
Все это приводит к не переносимости в общем случае приложений да и просто реализаций алгоритмов с 32битной машины на 64битную.
Сейчас в плане 64битности дальше всех продвинулась OS A2 с языком Active Oberon. Там наконец ввели тип ADDRESS, ну и многие другие неприятные мелочи устранили. Собственно нативная OS A2 под 64 битами вполне бегает, осталось сделать биндинги для 64битной версии A2 for Windows, чтобы всю эту радость можно было запускать под виндами также, как 32биную версию (операционка A2 характеризуется тем, что может быть не только полновесной операционкой работающей с железом непосредственно, но и выглядеть как обычное приложение скажем в виндах, без эмуляторов, впрочем это вообще типично для Оберон-операционок). Собственно одно российское предприятие (коммерческое, да. не университет), которое активно использует Active Oberon и A2 в своей работе, думаю вскоре сделает эти биндинги :-)
Впрочем, полнотекстовый поиск никто не отменял.
А Oberspace — это, как ни странно, форум. Где любому гарантирована свобода высказываний, в отличае от иных оберон-форумов.
А то что ты эту статью не планировал — оно и видно. По содержанию :-)
Короче, в доку все равно смотреть надо и там и там. Проще будет то, что больше похоже на то, с чем ты работал. Новичку же — будет одинаково что Оберон, что Scheme, ибо это и будет его начальная точка отсчета.
Но вообще, сейчас потихоньку движется одновременно для нескольких компиляторов работа по прикручиванию llvm-бекенда, как прикрутится, так будет и 64 бита, и вообще кодогенерация станет более качественной.
Дело в том, что программа многомерна. В 2D хорошо отображается лишь то, что и так просто и имеет мало элементов (например самый верхний уровень архитектуры). Об этом писал еще Брукс в своем мифическом человекомесяце.
Так что мне приходится отдуваться пока в комментах.
Все это не слишком похоже на Паскаль.
Так вот, у Оберонов с этим вроде бы как раз все хорошо: