Comments 153
Несколько уточнений:
Ну и пачка ссылок на описание языков:
Oberon (1990 год): www.inf.ethz.ch/personal/wirth/Articles/Oberon/Oberon.Report.pdf
Oberon-07 (2011 год): www.inf.ethz.ch/personal/wirth/Articles/Oberon/Oberon07.Report.pdf
Oberon-2 (1992 год): http://www-vs.informatik.uni-ulm.de:81/projekte/Oberon-2.Report/
Component Pascal (2006 год): www.oberon.ch/pdf/CP-Lang.pdf
- Вирт не развивал из оригинального Оберона Оберон-2. Он по сути лишь консультировал. Основную работу по Оберону-2 провел Х. Мёссенбёк. По сути Оберон-2 принадлежит к ветке Object Oberon. Вирт же продолжил развитие Оберона по своему, что и вылилось в Oberon-07/11 (в Обероне 07/11 нет ничего от Оберона-2, это чистое переосмысление и уточнение оригинального Оберона).
- Язык Оберон появился не сам по себе, он появился в рамках проекта написания операционной системы Оберон, и был получен путем упрощения и адаптации Модулы под данную задачу. Более того, без описания ОС Оберон, сообщение о языке Оберон не полно.
- ОС Оберон (и соответственно ЯП Оберон) изначально проектировалась под 32битные процессора. В дальнейшем мне не известны работы Вирта и его команды по адаптации ЯП Оберон под процессора с меньшей разрядностью. Сейчас Вирт смотрит в строну микроконтроллеров, и соответственно причёсывает Оберон-07, но это опять таки в фаворе 32битные ARMы (вообще, у Вирта есть даже отдельный форк оберона — Oberon-ARM, вот он конкретно пода ARM и был заточен). На 64 бита языки Оберон-семейства тоже так себе заточены.
- ЯП Оберон подразумевает наличие рантайма и сборщика мусора (в описаннии Компонентного Паскаля, и Оберона-2 это прописано явно, в описании Оберона и Оберона-07 просто сказано что вот есть NEW, а как освобождать память — не сказано)
- В языке многое не определено. Особенно этим грешит Оберон-07. Соответственно могут существовать (и, вообще говоря, существуют) две разных реализации языка, ни в одной букве не противоречащих описанию языка, но при этом не совместимые уже на уровне описания алгоритмов, на уровне базовой семантики. В описании языка также нет ничего про стандартную библиотеку. Так что hello world не написать.
Ну и пачка ссылок на описание языков:
Oberon (1990 год): www.inf.ethz.ch/personal/wirth/Articles/Oberon/Oberon.Report.pdf
Oberon-07 (2011 год): www.inf.ethz.ch/personal/wirth/Articles/Oberon/Oberon07.Report.pdf
Oberon-2 (1992 год): http://www-vs.informatik.uni-ulm.de:81/projekte/Oberon-2.Report/
Component Pascal (2006 год): www.oberon.ch/pdf/CP-Lang.pdf
На 64 бита языки Оберон-семейства тоже так себе заточены.
«Так себе» они заточены на x86-64, а на 64-х битах Оберон живёт уже давно. Просто ты не учёл, что мир 64 бит не ограничивается платформой Wintel.
И вообще в Оберонах явной привязки к разрядности особо нет, за исключением системных средств из псевдомодуля SYSTEM конечно.
Во-первых проблемы Оберона с 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 в своей работе, думаю вскоре сделает эти биндинги :-)
Во-вторых про 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 в своей работе, думаю вскоре сделает эти биндинги :-)
Насчёт Оберона и кроссплатформенности — не слушайте его, он для восьмибитных процев на Обероне не программил. :) «Проблемы Оберона с 64битностью» — это высосанная из пальца г-на Веселовского заморочка. Я уже имел честь пространно отвечать г-ну Веселовскому на его искажённое представление о кроссплатформенности Оберонов, однако он продолжает упорствовать. Так что надо на это ответить хотя бы затем, чтобы прояснить неточности.
Ключевой момент: «Готов ли Оберон к 64 битам»? Здесь одним «да» или «нет» не обойдёшься, и тут, вероятно, тёрки потому, что Веселовский вкладывает в понятие «Оберон», скорее, Оберон-07 и Активный Оберон, я же вкладываю в это понятие, скорее, Оберон-2 и Компонентный Паскаль, т.к. считаю эти диалекты более пригодными для промышленного использования. А Оберон-07 слишком мал, чтобы комфортно его использовать в повседневных задачах. Даже КП — чрезвычайно маленький язык. И его, на мой взгляд, надо только дополнять. А уж что говорить про О-07, самая свежая редакция которого, к тому же, не выглядит полностью законченной. И Веселовский, видимо, прочитав описание последней редакции, до сих пор не может прийти в себя. Да и вообще вкладывать в понятие «Оберон» самую урезанную ревизию, косвенно предполагая ту же фигню и в других диалектах. Вот чем грешит Веселовский, он передёргивает факты и трактует их в меру своего скромного разумения.
Что вообще можно вложить в понятие «64-битность» в контексте Оберона?
Разумность и целесообразность широкого использования 32-битной арифметики на 64-битных архитектурах, если её разрядности хватает для задачи? Сама возможность работы на 64-битном процессоре 32-битной Оберон-программы, которая не знает о 64-х битах и думает, что их по-прежнему 32? Ну да, в принципе, Оберон-программа может быть номинально 64-битной, но арифметика в ней будет 32-битной. Или 64-битной. Или той и другой вместе (INTEGER и LONGINT). Указатели 64-битными. При этом в Обероне-07 целочисленная арифметика может быть только одной разрядности, потому что там предусмотрен только один целочисленный тип INTEGER.
Наличие типа INTEGER строго размером в 64 бита? Понимать ли под 64-битностью именно то, чтобы тип INTEGER был 64 бита, потому что Веселовский упёрся в это? Если так, то в Дельфи XE4 тип INTEGER остался 32-битным, и горе тем, кто кастовал указатели в INTEGER; а значит Дельфи XE4 тоже не готов к 64 битам. И Java не готова, потому что по стандарту int 32-битный, а для 64 бит надо юзать long.
Вообще возможность работы Оберон-программ на 64-битных процессорах?
Возможность использования как 32-битной арифметики, так и 64-битной?
Разные диалекты Оберона предлагают разные ответы на эти вопросы.
Готова ли последняя виртовская редакция Оберона-07 к 64 битам?
Не будет ли ещё более новых редакций? Кто его знает. Авторы компилеров Оберона-07, готовьтесь к приятному внесению изменений.
Поэтому важный момент: INTEGER в 64-битной реализации Оберона-07 может быть 32-битным. Стоит ли в 64-битном Обероне-07 делать тип INTEGER разрядностью 64 бита или оставить 32, как в Дельфи XE4? Если делать, то будут одни плюсы. Если не делать — другие.
Можно сделать INTEGER 64-битным, вот в Питоне вся целочисленная арифметика 64-битная, и ничего. Но тогда нельзя будет низкоуровневыми средствами кастовать INTEGER в SET, чего конечно Веселовскому не нравится, и он зашёл с этим в тупик. Ибо с одной стороны надо и редакцию соблюсти, от буковки редакции — ни на шаг! С другой наверно это всё дело как-то задумывалось как практический инструмент. На том, что этот тупик пробит в других диалектах Оберона, Веселовский особо не акцентирует. Я же говорю: минимальность Оберона-07, святое соблюдение буквы его последней ревизии, которая, возможно, не окончательная, желание при этом решать на нём какие-то задачи и полный игнор тех фактов, что в других диалектах Оберона эта проблема решена (да-да, и не только в Active Oberon) — это плохой винегрет, которому мы дадим рабочее название «сумбур в голове Веселовского».
Как в рамках зафиксированной редакции Оберона-07, не меняя её, всё-таки его развивать? Или всё-таки поправить явные ляпы в этой редакции самим или ждать, когда это сделает дядька Вирт? Я открою вам секрет: в связи с тем, что Бертран Мейер сейчас заведует в ETH (альма-матер Оберонов) кафедрой, на которой разрабатывается Active Oberon, и любит он не Оберон, а вовсе даже Эйфель, то по дальнейшему развитию Оберонов силами ETH нанесён значительный удар. Если этим не займётся кто-то ещё. OberonCore? Да, возможно. Оберспейс на «продолжателя традиций», извините, не тянет.
Готовы ли Оберон и Оберон-2 к 64 битам?
Абсолютно готовы. В стандарте этих языков нет явной привязки к разрядности. Что всё-таки не мешает делать на них переносимые программы сегодня, не дожидаясь годков 20 новой редакции «Дубовых требований», в которой модуль:
MODULE MustBeStandard; TYPE Int64* = LONGINT; END MustBeStandard.
будет стандартным. Но если то, что такой модуль не стандартизирован — это религия, то никогда уже г-н Веселовский не сможет попрограммить на Обероне-2 под 64 бита.
Готов ли Компонентный Паскаль к 64 битам?
Абсолютно готов. Есть ли смысл делать INTEGER 64-битным, а LONGINT — 128-битным — это отдельный вопрос. В принципе, числовые типы достигли своего насыщения, и, наверное, всё-таки в новой версии Питона целочисленна арифметика не будет 128-битной, а ещё в следующей — 256-битной. Это в моём понимании тупиковый путь. Есть ниша для длинной арифметики, а много где хватает и 32-битных вычислений.
Буду признателен Веселовскому, если он ткнёт носом в такое место стандарта языка КП, где декларируется «жесткая привязка примитивных типов к разрядности», потому что ничего такого я не встречал. Или Веселовского смущает то, что эти типы всё-таки имеют при реализации какую-то разрядность?
Сентенция «а SET напрямую связан с INTEGER», может быть, и имеет смысл в Обероне-07, где всё-таки приходится, ну просто ввиду отсутствия других средств, использовать прямое кастование между этими типами системными средствами, однако в языке КП это уже исправлено: там есть битовые операции BITS и ORD. А в реализации GPCP есть типы SET и LONGSET (по аналогии с INTEGER и LONGINT).
Готов ли Активный Оберон к 64 битам?
Готов, как и остальные Обероны. Вот эту туманную цитату: «Там наконец ввели тип ADDRESS, ну и многие другие неприятные мелочи устранили.» я бы попросил г-на Веселовского прояснить, пусть расскажет нам о других неприятных мелочах. Мелочи — не конёк Веселовского, он обожает обобщать всё до «джедайских сверхсредств, которых вы всё равно не поймёте, простые сельские парни», поэтому ждите потехи.
Ключевой момент: «Готов ли Оберон к 64 битам»? Здесь одним «да» или «нет» не обойдёшься, и тут, вероятно, тёрки потому, что Веселовский вкладывает в понятие «Оберон», скорее, Оберон-07 и Активный Оберон, я же вкладываю в это понятие, скорее, Оберон-2 и Компонентный Паскаль, т.к. считаю эти диалекты более пригодными для промышленного использования. А Оберон-07 слишком мал, чтобы комфортно его использовать в повседневных задачах. Даже КП — чрезвычайно маленький язык. И его, на мой взгляд, надо только дополнять. А уж что говорить про О-07, самая свежая редакция которого, к тому же, не выглядит полностью законченной. И Веселовский, видимо, прочитав описание последней редакции, до сих пор не может прийти в себя. Да и вообще вкладывать в понятие «Оберон» самую урезанную ревизию, косвенно предполагая ту же фигню и в других диалектах. Вот чем грешит Веселовский, он передёргивает факты и трактует их в меру своего скромного разумения.
Что вообще можно вложить в понятие «64-битность» в контексте Оберона?
Разумность и целесообразность широкого использования 32-битной арифметики на 64-битных архитектурах, если её разрядности хватает для задачи? Сама возможность работы на 64-битном процессоре 32-битной Оберон-программы, которая не знает о 64-х битах и думает, что их по-прежнему 32? Ну да, в принципе, Оберон-программа может быть номинально 64-битной, но арифметика в ней будет 32-битной. Или 64-битной. Или той и другой вместе (INTEGER и LONGINT). Указатели 64-битными. При этом в Обероне-07 целочисленная арифметика может быть только одной разрядности, потому что там предусмотрен только один целочисленный тип INTEGER.
Наличие типа INTEGER строго размером в 64 бита? Понимать ли под 64-битностью именно то, чтобы тип INTEGER был 64 бита, потому что Веселовский упёрся в это? Если так, то в Дельфи XE4 тип INTEGER остался 32-битным, и горе тем, кто кастовал указатели в INTEGER; а значит Дельфи XE4 тоже не готов к 64 битам. И Java не готова, потому что по стандарту int 32-битный, а для 64 бит надо юзать long.
Вообще возможность работы Оберон-программ на 64-битных процессорах?
Возможность использования как 32-битной арифметики, так и 64-битной?
Разные диалекты Оберона предлагают разные ответы на эти вопросы.
Готова ли последняя виртовская редакция Оберона-07 к 64 битам?
Не будет ли ещё более новых редакций? Кто его знает. Авторы компилеров Оберона-07, готовьтесь к приятному внесению изменений.
Поэтому важный момент: INTEGER в 64-битной реализации Оберона-07 может быть 32-битным. Стоит ли в 64-битном Обероне-07 делать тип INTEGER разрядностью 64 бита или оставить 32, как в Дельфи XE4? Если делать, то будут одни плюсы. Если не делать — другие.
Можно сделать INTEGER 64-битным, вот в Питоне вся целочисленная арифметика 64-битная, и ничего. Но тогда нельзя будет низкоуровневыми средствами кастовать INTEGER в SET, чего конечно Веселовскому не нравится, и он зашёл с этим в тупик. Ибо с одной стороны надо и редакцию соблюсти, от буковки редакции — ни на шаг! С другой наверно это всё дело как-то задумывалось как практический инструмент. На том, что этот тупик пробит в других диалектах Оберона, Веселовский особо не акцентирует. Я же говорю: минимальность Оберона-07, святое соблюдение буквы его последней ревизии, которая, возможно, не окончательная, желание при этом решать на нём какие-то задачи и полный игнор тех фактов, что в других диалектах Оберона эта проблема решена (да-да, и не только в Active Oberon) — это плохой винегрет, которому мы дадим рабочее название «сумбур в голове Веселовского».
Как в рамках зафиксированной редакции Оберона-07, не меняя её, всё-таки его развивать? Или всё-таки поправить явные ляпы в этой редакции самим или ждать, когда это сделает дядька Вирт? Я открою вам секрет: в связи с тем, что Бертран Мейер сейчас заведует в ETH (альма-матер Оберонов) кафедрой, на которой разрабатывается Active Oberon, и любит он не Оберон, а вовсе даже Эйфель, то по дальнейшему развитию Оберонов силами ETH нанесён значительный удар. Если этим не займётся кто-то ещё. OberonCore? Да, возможно. Оберспейс на «продолжателя традиций», извините, не тянет.
Готовы ли Оберон и Оберон-2 к 64 битам?
Абсолютно готовы. В стандарте этих языков нет явной привязки к разрядности. Что всё-таки не мешает делать на них переносимые программы сегодня, не дожидаясь годков 20 новой редакции «Дубовых требований», в которой модуль:
MODULE MustBeStandard; TYPE Int64* = LONGINT; END MustBeStandard.
будет стандартным. Но если то, что такой модуль не стандартизирован — это религия, то никогда уже г-н Веселовский не сможет попрограммить на Обероне-2 под 64 бита.
Готов ли Компонентный Паскаль к 64 битам?
Абсолютно готов. Есть ли смысл делать INTEGER 64-битным, а LONGINT — 128-битным — это отдельный вопрос. В принципе, числовые типы достигли своего насыщения, и, наверное, всё-таки в новой версии Питона целочисленна арифметика не будет 128-битной, а ещё в следующей — 256-битной. Это в моём понимании тупиковый путь. Есть ниша для длинной арифметики, а много где хватает и 32-битных вычислений.
Буду признателен Веселовскому, если он ткнёт носом в такое место стандарта языка КП, где декларируется «жесткая привязка примитивных типов к разрядности», потому что ничего такого я не встречал. Или Веселовского смущает то, что эти типы всё-таки имеют при реализации какую-то разрядность?
Сентенция «а SET напрямую связан с INTEGER», может быть, и имеет смысл в Обероне-07, где всё-таки приходится, ну просто ввиду отсутствия других средств, использовать прямое кастование между этими типами системными средствами, однако в языке КП это уже исправлено: там есть битовые операции BITS и ORD. А в реализации GPCP есть типы SET и LONGSET (по аналогии с INTEGER и LONGINT).
Готов ли Активный Оберон к 64 битам?
Готов, как и остальные Обероны. Вот эту туманную цитату: «Там наконец ввели тип ADDRESS, ну и многие другие неприятные мелочи устранили.» я бы попросил г-на Веселовского прояснить, пусть расскажет нам о других неприятных мелочах. Мелочи — не конёк Веселовского, он обожает обобщать всё до «джедайских сверхсредств, которых вы всё равно не поймёте, простые сельские парни», поэтому ждите потехи.
Есть ли какая-либо объективная причина ключевым словам быть только в верхнем регистре? Я помню, что это было придумано, вроде бы как для того, чтобы ключевые слова выделялись среди кода без подсветки синтаксиса. Очень странно звучит, тем более, что подсветка синтаксиса была придумана за несколько лет до появления Оберона.
Полагаю это просто традиция тех лет. Если посмотреть на программы писанные на Аде (хотя ада и не чувствительна к регистру) в те годы, то видно что ТАМ БЫЛ В МОДЕ КАПС, ну и примеры программ в стандарте Ады-83 были оформлены соответственно. В стандарте Ады-95 уже все примеры без капса.
Да, и еще нюанс — в ОС Оберон (ну и соответственно у оберонщиков вообще, и у почитателей BlackBox Component Builder'a в особенности) не принято подсвечивать синтаксис. Там принято использовать ручную раскраску текста для выделения смысловых частей кода (например можно пометить красным какие-то части кода, которые требуют особого внимания). Поэтому если считать, что ключевые слова надо таки как-то выделять, то КАПС оказывается в этом случае не таким уж плохим решением.
Да, и еще нюанс — в ОС Оберон (ну и соответственно у оберонщиков вообще, и у почитателей BlackBox Component Builder'a в особенности) не принято подсвечивать синтаксис. Там принято использовать ручную раскраску текста для выделения смысловых частей кода (например можно пометить красным какие-то части кода, которые требуют особого внимания). Поэтому если считать, что ключевые слова надо таки как-то выделять, то КАПС оказывается в этом случае не таким уж плохим решением.
Да, а традиция тех лет была такова потому, что кое-где, таки еще были charsets в которых были буковки только в верхнем регистре.
Ну, получается, в итоге, что эта традиция была создана не по причине того, что это как-то помогает увеличить продуктивность (раскраска кода, может, и помогает обратить внимание на какую-то его часть, но она бессмысленна без комментариев, а комментарии и сами по себе помогают обратить внимание), а наоборот, чтобы справиться с ограничениями. Этих ограничений давно не существует, но традиция сохраняется. Так уж ли это хорошо?
Плюс, не знаю, как у других людей, а лично для меня код, в КОТОРОМ треть слов ВЫДЕЛЕНА верхним регистром, ЭСТЕТИЧЕСКИ воспринимается не очень ПРИЯТНО.
Плюс, не знаю, как у других людей, а лично для меня код, в КОТОРОМ треть слов ВЫДЕЛЕНА верхним регистром, ЭСТЕТИЧЕСКИ воспринимается не очень ПРИЯТНО.
Аналогично — мне тоже не слишком приятно смотреть на код половина слов в котором КАПСОМ. Поэтому например в Zonnon'e (тоже потомок Оберона) ключевые слова уже нормальные: ru.wikipedia.org/wiki/Zonnon
Но опять таки, смотреть на синтаксис Оберона и Компонентного Пасаля в отрыве от ОС Оберон, или среды BlackBox Component Builder не совсем правильно.
Кстати, сейчас еще возможно шокирую, но традиционно в ОС Оберон и в BB для программирования используется пропорциональный шрифт :-) Моноширинный шрифт считается ересью.
Да, автор статьи ничего не сказал о Active Oberon'e — то что сейчас как раз развивается в Цюрихе. Ну и операционной системе A2. Это собственно то, во что сейчас превратился Оберон (ОС и язык) в стенах того университета.
Но опять таки, смотреть на синтаксис Оберона и Компонентного Пасаля в отрыве от ОС Оберон, или среды BlackBox Component Builder не совсем правильно.
Кстати, сейчас еще возможно шокирую, но традиционно в ОС Оберон и в BB для программирования используется пропорциональный шрифт :-) Моноширинный шрифт считается ересью.
Да, автор статьи ничего не сказал о Active Oberon'e — то что сейчас как раз развивается в Цюрихе. Ну и операционной системе A2. Это собственно то, во что сейчас превратился Оберон (ОС и язык) в стенах того университета.
> традиционно в ОС Оберон и в BB для программирования используется пропорциональный шрифт :-) Моноширинный шрифт считается ересью
Ох. Интересно, а как это можно объяснить? Надеюсь, хотя бы гарнитуры без засечек? Хотя, это уже будет не удивительно.
Ох. Интересно, а как это можно объяснить? Надеюсь, хотя бы гарнитуры без засечек? Хотя, это уже будет не удивительно.
Ну, BB это обычная виндовозная прога — какой хочешь, такой шрифт и поставишь. Народ вроде бы Вердану любит. Но могу тут уже путать.
Какой шрифт в ОС Оберон, можно глянуть тут: www.youtube.com/watch?v=BTEeZe7nj6c
Какой шрифт в ОС Оберон, можно глянуть тут: www.youtube.com/watch?v=BTEeZe7nj6c
Замечу, что синтаксис в ЯП это самое не интересное, не важное и вообще скучное. Много важнее семантика, система типов и так далее. Библиотеки наконец.
Но, к сожалению, подавляющее большинство судит о ЯП всегда по синтаксису (увидели блоки из фигурных скобочек — сразу ярлык: очередной Си).
Но, к сожалению, подавляющее большинство судит о ЯП всегда по синтаксису (увидели блоки из фигурных скобочек — сразу ярлык: очередной Си).
Плюс, не знаю, как у других людей, а лично для меня код, в КОТОРОМ треть слов ВЫДЕЛЕНА верхним регистром, ЭСТЕТИЧЕСКИ воспринимается не очень ПРИЯТНО.
А ведь у многих SQL-щиков эта традиция до сих пор живее всех живых, даже IDE для работы с БД в верхний регистр ключевые слова автоматом переводят.
Это точно. Lowercase ключевые слова в SQL совсем не приняты. Я выбрал компромисный вариант и хотябы названия таблиц и полей пишу в lowercase или camelCase, хотя многие до сих пор и из пишут в UPPERCASE.
Смысл в том случае всё-таки есть т.к. SQL-запросы не редко встраиваются в код (хорошо это или плохо — отдельный вопрос) программы на другом языке и редактор обычно отображает такой SQL-код одним цветом как обычную строку.
Смысл в том случае всё-таки есть т.к. SQL-запросы не редко встраиваются в код (хорошо это или плохо — отдельный вопрос) программы на другом языке и редактор обычно отображает такой SQL-код одним цветом как обычную строку.
Как хорошо сказал Руслан Богатырёв на тему синтаксиса: это традиция модульных языков. Выделяется скелет программы, её костяк. Можно делать смысловые пометки выделением цвета или стиля. И примерно туда же двигается программинг. От плоского представления текстов программ на языках (в текстовом формате) — к манипуляции набором принятых решений в визуальных редакторах. И помяните моё слово, когда в новой версии вашей любимой среды разработки появится что-то подобное, только основанное на XML. Как только «великие» придумают как совместить это дело с раскраской синтаксиса. Предпосылки для этого есть уже сейчас (например, javadoc и прочие средства для Code Review). Значит не хватает уже текстового представления? Да, я знаю как глубоко мы в него увязли, но это является и тормозом прогресса же. Можно не юзать diff, можно пользоваться для сравнения исходников встроенными средствами BlackBox. Можно адаптировать системы контроля версий для бинарных исходников. Тут нет проблем. Но почему-то вместо этого (пока) предпочитают навешивать мета-информацию поверх текста либо с помощью тегов, либо отдельным файлом проекта, записанным в своём формате.
Так что бинарные исходники — это исследовательское направление, которое может быть многообещающим, если абстрагироваться от преимуществ готового набора инструментария для работы с текстами (grep и прочее) и начать осваивать новые просторы, находя в них новые достоинства, которых на самом деле много. Например, можно иметь несколько вариантов исходного текста, переключаемые селекторами. Можно вставлять в исходник в качестве комментариев поясняющие картинки, которые очень часто информативнее текста.
Впрочем, в XDev есть поддержка и чисто текстового формата исходников (недавно введена) с привычной для всех раскраской синтаксиса.
Так что бинарные исходники — это исследовательское направление, которое может быть многообещающим, если абстрагироваться от преимуществ готового набора инструментария для работы с текстами (grep и прочее) и начать осваивать новые просторы, находя в них новые достоинства, которых на самом деле много. Например, можно иметь несколько вариантов исходного текста, переключаемые селекторами. Можно вставлять в исходник в качестве комментариев поясняющие картинки, которые очень часто информативнее текста.
Впрочем, в XDev есть поддержка и чисто текстового формата исходников (недавно введена) с привычной для всех раскраской синтаксиса.
Ну, во-первых это все уже было сто раз. См UML, и см. rational rose, которая вообще по исходнику все эти графические модели строила. Не взлетело. То есть взлетело, но не стало всеобъемлющим, живет в своей узкой нише.
Дело в том, что программа многомерна. В 2D хорошо отображается лишь то, что и так просто и имеет мало элементов (например самый верхний уровень архитектуры). Об этом писал еще Брукс в своем мифическом человекомесяце.
Дело в том, что программа многомерна. В 2D хорошо отображается лишь то, что и так просто и имеет мало элементов (например самый верхний уровень архитектуры). Об этом писал еще Брукс в своем мифическом человекомесяце.
Да, поскольку автор статьи обделил ссылками два основных рускоязычных форума по Оберону, то исправлю ка я это маленькое недоразумение.
Вначале народ обсуждал обероны на королевстве делфи, вот тут: www.delphikingdom.com/oberon/
Затем, обзавелись своим форумом и переехали вот сюда: forum.oberoncore.ru
Но там, через какое-то время началась странная политика модерации: любая критика оберона, и вообще любое высказывание противоречащее основной линии партии мгновенно вырезалось. Форум начал закукливаться, замыкать сам на себя. Поэтому часть народа (в основном тех, кто знает и умеет не только оберон) постепенно переехали сюда: oberspace.dyndns.org, где сейчас постепенно и ведется разработка парочки компиляторов Оберона-07/11.
Вначале народ обсуждал обероны на королевстве делфи, вот тут: www.delphikingdom.com/oberon/
Затем, обзавелись своим форумом и переехали вот сюда: forum.oberoncore.ru
Но там, через какое-то время началась странная политика модерации: любая критика оберона, и вообще любое высказывание противоречащее основной линии партии мгновенно вырезалось. Форум начал закукливаться, замыкать сам на себя. Поэтому часть народа (в основном тех, кто знает и умеет не только оберон) постепенно переехали сюда: oberspace.dyndns.org, где сейчас постепенно и ведется разработка парочки компиляторов Оберона-07/11.
Говорить о «закукливании» и «замыкании на себя» форума OberonCore — это слишком субъективно, хотя чего же вы надеялись тут услышать от valexey, который является папочкой-основателем форума-«продолжателя». :) Да и говорить, что на Core «все знают и умеют ТОЛЬКО Оберон» — это тоже профанация (попробуй найди хотя бы полтора программиста, который не знает ничего другого?). Да, на Core есть некоторые проблемы с неприятием явных троллей, были и несогласия одних умных людей с другими, и даже очень серьёзные. Но всё-таки поводом существования OberonCore являются сами Обероны. Я предлагаю составить личное мнение по каждому из форумов, но моё таково — что при всех недостатках Core у него есть и достоинства, ему присущ академический флёр. Чистота, хорошая структуризация материала, есть много интересных людей, использующих Оберон в своей деятельности.
Ну а альфа и омега Оберспейса, сама сердцевина его существования — это жажда самовосхвалений основной банды участников, к Оберонам имеющих не то что косвенное отношение, а вообще никакого. Именно поэтому там со скоростью диареи появляются пачками личные разборки, наезды и темы типа "Мы победили!". Если убрать оттуда Ермакова, Губанова, akron1 и ещё пару человек, которые чего-то делают, останется голая болтовня в стиле «я самый умный». Но присутствие этих самых челов даёт им всем право говорить «Мы делаем». А декларируемая «папочкой» форума «свобода» в купе с общим пофигизмом и мусорной подачей информации напоминает тусовку хиппи. Добавьте сюда невозможность редактирования постов, что само по себе плохо для работы (материал закостеневает), хотя наверное хорошо для холиваров.
Так что я бы поостерёгся назвать Оберспейс таким уж идейным продолжателем движения «За Оберон». И valexey не понял, что я не ставил целью расписать все ресурсы по Оберонам в статье, на это есть гугле, и неплохо справляется, а просто рассказал о своей деятельности и своём виденьи Оберонов.
Вы спросите, как борятся с троллингом на VEDAsoft форуме? А пока никак, он просто недостаточно велик для этого явления. Будут проблемы — будем думать. Наверное спорные моменты будут решаться кем-то вроде совета старейшин — тех людей, которые приняли активное положительное участие в работе форума. И сейчас это — форум практиков Оберона, которые пытаются его применять с пользой.
Вобщем, резюме:
OberonCore — «академия» Оберона. Со своей внутренней политикой (а где её нет?)
Oberspace — «курилка» при отделе, имеющем какое-то отношение к Оберону, на двери надпись «Оберон», но внешнее впечатление обманчиво; часто заходят «поболтать» из соседних отделов (ну надо же где-нить расслабиться и перекурить?). Внимание: поскольку здесь курят не только табак, то можно зайти с лучшими побуждениями и получить ни за что ни про что по морде.
VEDAsoft — «клуб по интересам» для Оберон-практиков
Всё же хорошо, что они есть — есть выбор куда пойти (и, надеюсь, всем понятно почему «академиков» и практиков меньше, чем курильщиков?)
Кстати, помимо «основных», есть и другие форумы и форумные темы по Оберону, не такие большие, но тоже интересные. Например, форум по Активному Оберону и ОС A2.
Ну а альфа и омега Оберспейса, сама сердцевина его существования — это жажда самовосхвалений основной банды участников, к Оберонам имеющих не то что косвенное отношение, а вообще никакого. Именно поэтому там со скоростью диареи появляются пачками личные разборки, наезды и темы типа "Мы победили!". Если убрать оттуда Ермакова, Губанова, akron1 и ещё пару человек, которые чего-то делают, останется голая болтовня в стиле «я самый умный». Но присутствие этих самых челов даёт им всем право говорить «Мы делаем». А декларируемая «папочкой» форума «свобода» в купе с общим пофигизмом и мусорной подачей информации напоминает тусовку хиппи. Добавьте сюда невозможность редактирования постов, что само по себе плохо для работы (материал закостеневает), хотя наверное хорошо для холиваров.
Так что я бы поостерёгся назвать Оберспейс таким уж идейным продолжателем движения «За Оберон». И valexey не понял, что я не ставил целью расписать все ресурсы по Оберонам в статье, на это есть гугле, и неплохо справляется, а просто рассказал о своей деятельности и своём виденьи Оберонов.
Вы спросите, как борятся с троллингом на VEDAsoft форуме? А пока никак, он просто недостаточно велик для этого явления. Будут проблемы — будем думать. Наверное спорные моменты будут решаться кем-то вроде совета старейшин — тех людей, которые приняли активное положительное участие в работе форума. И сейчас это — форум практиков Оберона, которые пытаются его применять с пользой.
Вобщем, резюме:
OberonCore — «академия» Оберона. Со своей внутренней политикой (а где её нет?)
Oberspace — «курилка» при отделе, имеющем какое-то отношение к Оберону, на двери надпись «Оберон», но внешнее впечатление обманчиво; часто заходят «поболтать» из соседних отделов (ну надо же где-нить расслабиться и перекурить?). Внимание: поскольку здесь курят не только табак, то можно зайти с лучшими побуждениями и получить ни за что ни про что по морде.
VEDAsoft — «клуб по интересам» для Оберон-практиков
Всё же хорошо, что они есть — есть выбор куда пойти (и, надеюсь, всем понятно почему «академиков» и практиков меньше, чем курильщиков?)
Кстати, помимо «основных», есть и другие форумы и форумные темы по Оберону, не такие большие, но тоже интересные. Например, форум по Активному Оберону и ОС A2.
А почему в среде XDev все исходники в бинарных файлах? Как с этим можно нормально работать?
Сейчас бегло глянул что это за XDev такой — насколько я понимаю, XDev это BlackBox CB с какими-то накрученными сверху модулями для сборки через ofront чего-то там под Z80.
Так вот, BlackBox Component Builder оперирует не просто исходными текстами, а так называемыми составными документами. То есть в одном таком документе может быть и исходник (причем расцвеченный во все цвета радуги программистом) и дока к нему с картинками, и что-нибудь интерактивное. Это позволяет изобразить нечто наподобие literate programming'a.
Обрати внимание — тут в коде имя процедуры Do выделено жирным шрифтом — это выделил так программист, это не автоподсветка. Восклицательный знак в черном круге — это иконка клик на которую запустит процедуру Do модуля ObxHello1 (то есть ObxHello1.Do запустит). На а текст вокруг — эдакий мегакоммент-дока для данного модуля.
В результате имеем составной интерактивный документ.
Плюсы у такого подхода очевидны, очевидны и минусы же — проблемы с системами контроля версий + смотреть/редактировать исходники в таком виде можно только в BB.
Надеюсь понятно описал :-) Если интересно, то могу попробовать написать статью о том, откуда есть всё это взялось вообще. То есть по ОС Оберон.
Так вот, BlackBox Component Builder оперирует не просто исходными текстами, а так называемыми составными документами. То есть в одном таком документе может быть и исходник (причем расцвеченный во все цвета радуги программистом) и дока к нему с картинками, и что-нибудь интерактивное. Это позволяет изобразить нечто наподобие literate programming'a.
Выглядит это примерно так.
Обрати внимание — тут в коде имя процедуры Do выделено жирным шрифтом — это выделил так программист, это не автоподсветка. Восклицательный знак в черном круге — это иконка клик на которую запустит процедуру Do модуля ObxHello1 (то есть ObxHello1.Do запустит). На а текст вокруг — эдакий мегакоммент-дока для данного модуля.
В результате имеем составной интерактивный документ.
Плюсы у такого подхода очевидны, очевидны и минусы же — проблемы с системами контроля версий + смотреть/редактировать исходники в таком виде можно только в BB.
Надеюсь понятно описал :-) Если интересно, то могу попробовать написать статью о том, откуда есть всё это взялось вообще. То есть по ОС Оберон.
Ну и как с таким составным документом работать? Все традиционные средства разработки направленные на работу с текстом, становятся безполезными: diff/patch не работает, grep тоже, половина возможностей git безполезна.
Плюсы в виде ручного расцвечевания цветами радуги своего кода и интерактивности — очень сомнительные.
Плюсы в виде ручного расцвечевания цветами радуги своего кода и интерактивности — очень сомнительные.
Да, unix-way не прокатит :-)
Этот BB CB он сам себе среда и операционка. Расширяется легко и непринужденно. Собственно в том скриншоте модуль — это уже модуль самой среды по сути. Там нет четкой границы между средой разработки и программы разрабатываемой. Соответственно и инструментарий народ себе потихоньку делает. Diff там по крайней мере есть.
(но опять таки — не нужно это все переносить на язык Оберон — он бывает и в виде традиционных компиляторов с обычными текстовыми исходниками)
С git'ом народ выкручивается (если видит смысл выкручиваться) по разному. Например кто-то экспортирует исходники в обычные текстовые файлы.
Понятно что этот самый BB CB не есть серебряная пуля для всего на свете. На ряд решаемых задач такой подход ложится очень хорошо, и те преимущества которые оно дает перевешивает те недостатки которые оно же и привносит. На других же задачах в точности наоборот — недостатки играют сильнее чем достоинства.
Этот BB CB он сам себе среда и операционка. Расширяется легко и непринужденно. Собственно в том скриншоте модуль — это уже модуль самой среды по сути. Там нет четкой границы между средой разработки и программы разрабатываемой. Соответственно и инструментарий народ себе потихоньку делает. Diff там по крайней мере есть.
(но опять таки — не нужно это все переносить на язык Оберон — он бывает и в виде традиционных компиляторов с обычными текстовыми исходниками)
С git'ом народ выкручивается (если видит смысл выкручиваться) по разному. Например кто-то экспортирует исходники в обычные текстовые файлы.
Понятно что этот самый BB CB не есть серебряная пуля для всего на свете. На ряд решаемых задач такой подход ложится очень хорошо, и те преимущества которые оно дает перевешивает те недостатки которые оно же и привносит. На других же задачах в точности наоборот — недостатки играют сильнее чем достоинства.
Еще факт, который мне показался интересным, когда я читал про Оберон: там нет интерфейсов. Поэтому объектно-ориентированное программирование на нём затрудненно.
Оберонов их как собак не резанныхмного. Ты про какой именно читал? В Компонентном Паскале например вполне есть абстрактные RECORD'ы. Но вот множественного наследования интерфейсов там действительно нет. На эту тему на одном из форумов было многостраничное обсуждение: forum.oberoncore.ru/viewtopic.php?f=29&t=3640
Ну, а например в Zonnon'e с интерфейсами вообще все отлично — есть искаропки.
Оригинальный же Оберон и Оберон-07… Ну, собственно там даже в общем то нет функций связанных с типом. То есть, банально методов как таковых. Наприсать obj.foo() нельзя. Там все это несколько иначе делается.
Ну, а например в Zonnon'e с интерфейсами вообще все отлично — есть искаропки.
Оригинальный же Оберон и Оберон-07… Ну, собственно там даже в общем то нет функций связанных с типом. То есть, банально методов как таковых. Наприсать obj.foo() нельзя. Там все это несколько иначе делается.
Тема того обсуждения говорит о многом: «Моделирование интерфейсов». Зачем их моделировать, если они есть? Есть абстрактные рекорды, которые не являются эквивалентом традиционного понятия интерфейса. Отсюда и необходимость моделировать интерфейсы в языке, который их напрямую не поддерживает.
А Zonnon — это такой хитрый оберон, который включает в себя все возможности .NET?
А Zonnon — это такой хитрый оберон, который включает в себя все возможности .NET?
Zonnon — это такое развитие Active Oberon'a под .net. Собственно, что я буду википедию пересказывать? ru.wikipedia.org/wiki/Zonnon
Ну, закат солнца вручную — довольно частое явление в Оберонах (если Зоннон вычеркнуть). :-)
Ну, например руками делаем конструкторы: forum.oberoncore.ru/viewtopic.php?f=23&t=4326&p=79442
И исключения: forum.oberoncore.ru/viewtopic.php?f=26&t=808&p=11934&#p11933
Изобретаем беззнаковое целое: oberspace.dyndns.org/index.php/topic,398.0.html
Боремся с byte-stream: oberspace.dyndns.org/index.php/topic,399.0.html
Ну, например руками делаем конструкторы: forum.oberoncore.ru/viewtopic.php?f=23&t=4326&p=79442
И исключения: forum.oberoncore.ru/viewtopic.php?f=26&t=808&p=11934&#p11933
Изобретаем беззнаковое целое: oberspace.dyndns.org/index.php/topic,398.0.html
Боремся с byte-stream: oberspace.dyndns.org/index.php/topic,399.0.html
Вы можете ответить на вопрос: зачем? Какие преимущества имеет оберон перед остальными языками (и всем, что их окружает: библиотеки, среды разработки и т.п.)?
Про обучение я бы лучше б промолчал: не дай божЕ потом эти выученные программисты придут в какую-нибудь коммерческую разработку и начнут там хреначить в верхнем регистре, потому что так заметнее…
По мне так для обучения, особенно на начальном этапе очень хорош Python. Хотя бы даже потому, что будущие коллеги заимеют привычку расставлять отступы. Я не говорю уже просто о самом языке.
По мне так для обучения, особенно на начальном этапе очень хорош Python. Хотя бы даже потому, что будущие коллеги заимеют привычку расставлять отступы. Я не говорю уже просто о самом языке.
Про отступы там вызрело вот такое: www.sem-tech.net/ :-)
Но это опять таки, вторично. Ибо просто синтаксис. Это скучно. И это банально лечится единым coding style на контору.
А вот семантические заморочки, проблемы с типизацией — вот они лечатся туго. Так что нет, никаких питонов в начальном обучении. Впрочем, на счет Оберона тоже сомнения у меня некоторые имеются.
Но это опять таки, вторично. Ибо просто синтаксис. Это скучно. И это банально лечится единым coding style на контору.
А вот семантические заморочки, проблемы с типизацией — вот они лечатся туго. Так что нет, никаких питонов в начальном обучении. Впрочем, на счет Оберона тоже сомнения у меня некоторые имеются.
Вы слишком большие требования предъявляете к тем, кто ещё алгоритмику не освоил. Нельзя же народ прямо так сразу окунать во все эти заморочки, когда он цикл нормальный написать не в состоянии.
Вы как-то сразу из университета прямо бросились в какую-то «контору».
Кроме отступов у Питона ещё очень много всего: это и ООП, и функциональщина, и регулярки… Можно на одном языке сделать довольно неплохой обзор, как вводную в современные практики.
Да и потом, я нисколько не утверждаю, что нужно только на Питоне просиживать — потом, когда хоть какие-то зачатки мышления появятся можно уже макать во все эти заморочки на каком-нибудь языке со статической типизацией.
Вы как-то сразу из университета прямо бросились в какую-то «контору».
Кроме отступов у Питона ещё очень много всего: это и ООП, и функциональщина, и регулярки… Можно на одном языке сделать довольно неплохой обзор, как вводную в современные практики.
Да и потом, я нисколько не утверждаю, что нужно только на Питоне просиживать — потом, когда хоть какие-то зачатки мышления появятся можно уже макать во все эти заморочки на каком-нибудь языке со статической типизацией.
Ну, народ бросается в какие-то конторы прямо во время универа. И это правильно.
Основам именно что алгоритмики можно вполне и на Обероне. Вот правда-правда можно. Там ничего лишнего (угу, те самые 16 страниц описания языка) и всего хватает для таких задач. Не даром же его в Оксфорде в качестве одного из первых изучаемых ЯП преподают.
Потом на Обероне (как уже на подопытном ЯП) же отлично отрабатывать теорию и практику компиляторостроения и методов трансляции. Ну и по ОС тоже Оберон может пригодиться, у Вирта аж целая книжка по ОС Оберон написана. Подробно, компактно и ясно. То есть в плане обучалова Оберон штука в принципе годная, если с умом подходить. Ну и для некоторых научных изысканий тоже штука годная (в качестве объекта изучения).
Другое дело, что не стоит Оберон тащить во все промышленные задачи, как некоторые ярые пропагандисты делают. У простоты есть своя цена в конце концов, как, впрочем, и у сложности.
Основам именно что алгоритмики можно вполне и на Обероне. Вот правда-правда можно. Там ничего лишнего (угу, те самые 16 страниц описания языка) и всего хватает для таких задач. Не даром же его в Оксфорде в качестве одного из первых изучаемых ЯП преподают.
Потом на Обероне (как уже на подопытном ЯП) же отлично отрабатывать теорию и практику компиляторостроения и методов трансляции. Ну и по ОС тоже Оберон может пригодиться, у Вирта аж целая книжка по ОС Оберон написана. Подробно, компактно и ясно. То есть в плане обучалова Оберон штука в принципе годная, если с умом подходить. Ну и для некоторых научных изысканий тоже штука годная (в качестве объекта изучения).
Другое дело, что не стоит Оберон тащить во все промышленные задачи, как некоторые ярые пропагандисты делают. У простоты есть своя цена в конце концов, как, впрочем, и у сложности.
Вы меня просто не слышите. Что для вас начала? Неужели человек, который не может даже простой проход по элементам написать идёт в контору. В конторы на программистов идут как правило на 3-4 курсах (хотя конечно есть самородки).
И хватит ссылаться на всякие Оксфорды. А я вот скажу, что в MIT (по-круче вроде в плане IT конторка) на Lisp'е начинают… И?
А алгоритмы и на Ассемблере писать можно… Правда-правда :) Оберон для преподавания алгоритмов новичками уже тем плох, что там статическая типизация, поэтому кроме непосредственно работой над алгоритмами народу придётся возиться со всем, что вы выше описали.
Или ваш подход к обучению таков: выбросил из лодки — выплывет — научится плавать, утонет — ну и хрен с ним — заведомо хреновый потенциальный специалист был? :)
И хватит ссылаться на всякие Оксфорды. А я вот скажу, что в MIT (по-круче вроде в плане IT конторка) на Lisp'е начинают… И?
А алгоритмы и на Ассемблере писать можно… Правда-правда :) Оберон для преподавания алгоритмов новичками уже тем плох, что там статическая типизация, поэтому кроме непосредственно работой над алгоритмами народу придётся возиться со всем, что вы выше описали.
Или ваш подход к обучению таков: выбросил из лодки — выплывет — научится плавать, утонет — ну и хрен с ним — заведомо хреновый потенциальный специалист был? :)
Ой, давай не будем сейчас тут очередной флейм на тему динамическая VS статическая типизация устраивать. А то ведь всё как раз к тому идет, ибо я считаю что питон не годится для начального обучения именно в силу динамической типизации.
И да, я обучал таких людей которые не могли сами цикл написать (да и не особо программированием интересовались). И вот с чем-чем, а с типами проблем не было (и да, я не на Обероне учил). Там были смешнее проблемы — народ по привычке текст программы воспринимал как нечто декларативное (видимо по аналогии с математикой), и никак не мог понять, что вот до этой строчки комп еще не дошел, и про нее пока не знает и ничего не исполнял что там написано. Как ни странно, тут очень сильно помог пошаговый отладчик (столь упоенно чмыримый апологетами Оберона), который позволил наглядно показать как же оно на самом деле там работает.
И да, я обучал таких людей которые не могли сами цикл написать (да и не особо программированием интересовались). И вот с чем-чем, а с типами проблем не было (и да, я не на Обероне учил). Там были смешнее проблемы — народ по привычке текст программы воспринимал как нечто декларативное (видимо по аналогии с математикой), и никак не мог понять, что вот до этой строчки комп еще не дошел, и про нее пока не знает и ничего не исполнял что там написано. Как ни странно, тут очень сильно помог пошаговый отладчик (столь упоенно чмыримый апологетами Оберона), который позволил наглядно показать как же оно на самом деле там работает.
Как-то вот эти два момента из ваших комментариев противоречат друг другу:
> И вот с чем-чем, а с типами проблем не было (и да, я не на Обероне учил)
> А вот семантические заморочки, проблемы с типизацией — вот они лечатся туго
По ходу вы сами уже запутались :)
И я не устраиваю флейм и не собираюсь… И уж точно я не являюсь апологетом Питона (вот ни за что не догадаетесь какой язык для меня любимый — только чур в мои предыдущие комментарии не смотреть ;) ). И вообще не являюсь апологетом того или иного лагеря. Я из тех самых скучных, которые считают, что для каждой задачи нужно в первую очередь правильный инструмент найти, а не хреначить всё на очередной «серебряной пуле». А научить программировать я и на ассемблере могу — другое дело сколько усилий с моей стороны и стороны ученика это потребует.
> И вот с чем-чем, а с типами проблем не было (и да, я не на Обероне учил)
> А вот семантические заморочки, проблемы с типизацией — вот они лечатся туго
По ходу вы сами уже запутались :)
И я не устраиваю флейм и не собираюсь… И уж точно я не являюсь апологетом Питона (вот ни за что не догадаетесь какой язык для меня любимый — только чур в мои предыдущие комментарии не смотреть ;) ). И вообще не являюсь апологетом того или иного лагеря. Я из тех самых скучных, которые считают, что для каждой задачи нужно в первую очередь правильный инструмент найти, а не хреначить всё на очередной «серебряной пуле». А научить программировать я и на ассемблере могу — другое дело сколько усилий с моей стороны и стороны ученика это потребует.
Нет, не запутался. Если человек не научится работать с типами сразу, то есть четко понимать что такое тип и зачем он нужен. Понимать зачем типы проверять до запуска приложения, то потом это привить будет очень сложно, и такое банальным кодинг-стайлом не лечится.
Вы предлагаете преподавать дифуры людям, которые не освоили ещё таблицу умножения… Или я преувеличиваю?
Поймите, это только ваше мнение о том, как нужно правильно преподавть программирование… Ни статистики, ни каких-то данных это подтверждающих нет. И начинать вдалбливать про арифметику указателей, правильное преобразование типов и прочие премудрости, до которых сухой теорией вряд ли дойти можно, а практики реально много (оооочень много!) надо, чтобы всё это понимать в полной мере — так вот, такому человеку это только во вред, потому что он сдохнет и сдуется от такого нагромождения информации, без соответсвующего количества практики (а в сутках, напомню 24 часа). Это будет для него очень долго просто шумом, и правилами, которые он просто не будет понимать на самом деле. А то, что вы так за статически-типизированные языки — это только ваше мнение. По мне так нужно начинать с алгоритмики — уже тут многие не справляются на самом деле — что уж там про нюансы работы с памятью говорить. И да, я не верю, что человек, который назубок знает все эти низкоуровневые премудрости, но обладает слабым алгоритмическим аппаратом и не владеет паттернами проектирования, сможет написать что-то стоящее, кроме постоянного приведения типов, смещая указатели и в общем плодя такие адовые макароны, что лучше б он ничего не писал — больше бы пользы было в перспективе.
А давайте ещё на начальных этапах всякого разного ещё накидаем на голову студента, чтобы он сразу начинал только с правильных практик? По-аналогии, давайте сразу ему расскажем про мок и юнит тестирование, начнём требовать использовать только правильные паттерны проектирвания, чтобы код был покрыт на 90% минимум тестами, причём любой, даже тот же ХэлоуВорлд!.. Ведь так сложно потом человека часами не вылезающего из дебаггера перевести на разработку через тестирование :( Вообще преподаватели, гады такие, ничего не рассказывают про юнит и мок тестирование, как правило, а если и рассказывают, то не вдаются в подробности :((((
Но знаете, многие всё равно приходят к этому. Не нужно держать людей, даже молодых, за идиотов!
P.S. Блин, неужели я такой же упёртый C++ — сник, как и вы? Даже смешно немного посмотреть на себя со стороны :)
Поймите, это только ваше мнение о том, как нужно правильно преподавть программирование… Ни статистики, ни каких-то данных это подтверждающих нет. И начинать вдалбливать про арифметику указателей, правильное преобразование типов и прочие премудрости, до которых сухой теорией вряд ли дойти можно, а практики реально много (оооочень много!) надо, чтобы всё это понимать в полной мере — так вот, такому человеку это только во вред, потому что он сдохнет и сдуется от такого нагромождения информации, без соответсвующего количества практики (а в сутках, напомню 24 часа). Это будет для него очень долго просто шумом, и правилами, которые он просто не будет понимать на самом деле. А то, что вы так за статически-типизированные языки — это только ваше мнение. По мне так нужно начинать с алгоритмики — уже тут многие не справляются на самом деле — что уж там про нюансы работы с памятью говорить. И да, я не верю, что человек, который назубок знает все эти низкоуровневые премудрости, но обладает слабым алгоритмическим аппаратом и не владеет паттернами проектирования, сможет написать что-то стоящее, кроме постоянного приведения типов, смещая указатели и в общем плодя такие адовые макароны, что лучше б он ничего не писал — больше бы пользы было в перспективе.
А давайте ещё на начальных этапах всякого разного ещё накидаем на голову студента, чтобы он сразу начинал только с правильных практик? По-аналогии, давайте сразу ему расскажем про мок и юнит тестирование, начнём требовать использовать только правильные паттерны проектирвания, чтобы код был покрыт на 90% минимум тестами, причём любой, даже тот же ХэлоуВорлд!.. Ведь так сложно потом человека часами не вылезающего из дебаггера перевести на разработку через тестирование :( Вообще преподаватели, гады такие, ничего не рассказывают про юнит и мок тестирование, как правило, а если и рассказывают, то не вдаются в подробности :((((
Но знаете, многие всё равно приходят к этому. Не нужно держать людей, даже молодых, за идиотов!
P.S. Блин, неужели я такой же упёртый C++ — сник, как и вы? Даже смешно немного посмотреть на себя со стороны :)
По моему ты усложняешь. Для азов алгоритмики достаточно знать что такое целое число и что такое массивы. Затем что такое указатели, да (для тех же деревьев). Но указатели в Обероне это не то же страшное аццкое существо, что в нашем с тобой любимом С++, там это по сути ссылки (нет арифметики указателей, их нельзя инкрементировать, нет крышесносных звездочек, амперсандов и прочего страшного). Ну и record'ы. Всё. больше типов для изучения алгоритмов и структур данных не нужно.
Так что тут не будет проблем.
Так что тут не будет проблем.
Про строковые алгоритмы забыли… Ну да ладно — с кем не бывает.
Но самое для меня непонятное это то, что вы по сути берёте статически-типизированный язык, упрощаете его до состояния ложноножки тем, что не даёте использовать весь спектр типов, и говорите, что на этом нужно преподавать.
При этом статика лезет из всех щелей, приходится прописывать кучу дополнительного непонятного пока для студента и потому кажущегося ему шлаком текста. Может конечно Оберон действительно что-то такое невероятное предлагает, что на нём это вообще не видно. Честно — не знаю — не очень вникал в синтаксис на том, что сумел найти на просторах интернета.
Почему бы сразу не взять какой-нибудь язык, который будет ближе всего к простому псевдоязыку, где не будет кучи мусора и непонятных для студента ошибок, потому что как раз привязки к типу не будет и не преподавать на нём. И студент больше будет сосредоточен именно на алгоритмах, потому что нет привязки к типу. Есть только простое разделение: строки и числа, потом объекты (они же структуры), которые по сути указывают друг на друга, и не воплотить все ваши задумки через эту идеологию. Да, студент пока не столкнётся лицом к лицу с таким понятием как указатель, он будет только знать, что один объект может указывать на другой через ссылки. Но в вашем случае по сути то же самое: арифметики нет, поэтому как не назови, а просто один объект ссылается или указывает на другой.
Что такое record'ы — не понял. Объясните?
А так получается, вы берёте статически-типизированный ЯП, по сути запрещаете использовать мощь статической типизации, потому что сводите всё к нескольким типам, указателей как таковых нет, т.е. и смысл именно их, а не ссылки использовать? А проблемы приведения наверняка будут возникать постоянно, потому что там забыл, тут не доглядел… Вот зачем в алгоритмах весь этот мусор?
И ещё. Я не представляю, как можно на Обероне, как представителе ООП ЯП показать например функциональную парадигму программирования (ну разве что ещё наворотить всякого своего велосипедного). А вот на Python можно, потому что он мультипарадигменный (ну с некоторыми оговорками конечно). Вот и получается, выбрали инструмент а вместе с тем выкинули целый пласт и область по алгоритмике, которую хотя бы обзорно, но показать было бы неплохо начинающим программистам.
И последнее: можно сколько угодно хвалить Оберон, но я тут на stackoverflow залез и по слову Oberon выдало 3 страницы по 50 сообщений, а по слову Python — 3000+. Вот столкнулся студент вдали от преподавателя с проблемой, которую не в состоянии пока разрешить — кури бомбук? А у Python и комьюнити больше, и книг и пр. материалов (качество правда не всегда на высоте, но они хотя бы есть). Да и вообще Python — коммерчески успешный продукт на котором ещё и пофриланчить потом можно. А Оберон что?
Вот зачем студента загонять в рамки языка, с которым у него будет столько проблем — не понимаю :(
Но самое для меня непонятное это то, что вы по сути берёте статически-типизированный язык, упрощаете его до состояния ложноножки тем, что не даёте использовать весь спектр типов, и говорите, что на этом нужно преподавать.
При этом статика лезет из всех щелей, приходится прописывать кучу дополнительного непонятного пока для студента и потому кажущегося ему шлаком текста. Может конечно Оберон действительно что-то такое невероятное предлагает, что на нём это вообще не видно. Честно — не знаю — не очень вникал в синтаксис на том, что сумел найти на просторах интернета.
Почему бы сразу не взять какой-нибудь язык, который будет ближе всего к простому псевдоязыку, где не будет кучи мусора и непонятных для студента ошибок, потому что как раз привязки к типу не будет и не преподавать на нём. И студент больше будет сосредоточен именно на алгоритмах, потому что нет привязки к типу. Есть только простое разделение: строки и числа, потом объекты (они же структуры), которые по сути указывают друг на друга, и не воплотить все ваши задумки через эту идеологию. Да, студент пока не столкнётся лицом к лицу с таким понятием как указатель, он будет только знать, что один объект может указывать на другой через ссылки. Но в вашем случае по сути то же самое: арифметики нет, поэтому как не назови, а просто один объект ссылается или указывает на другой.
Что такое record'ы — не понял. Объясните?
А так получается, вы берёте статически-типизированный ЯП, по сути запрещаете использовать мощь статической типизации, потому что сводите всё к нескольким типам, указателей как таковых нет, т.е. и смысл именно их, а не ссылки использовать? А проблемы приведения наверняка будут возникать постоянно, потому что там забыл, тут не доглядел… Вот зачем в алгоритмах весь этот мусор?
И ещё. Я не представляю, как можно на Обероне, как представителе ООП ЯП показать например функциональную парадигму программирования (ну разве что ещё наворотить всякого своего велосипедного). А вот на Python можно, потому что он мультипарадигменный (ну с некоторыми оговорками конечно). Вот и получается, выбрали инструмент а вместе с тем выкинули целый пласт и область по алгоритмике, которую хотя бы обзорно, но показать было бы неплохо начинающим программистам.
И последнее: можно сколько угодно хвалить Оберон, но я тут на stackoverflow залез и по слову Oberon выдало 3 страницы по 50 сообщений, а по слову Python — 3000+. Вот столкнулся студент вдали от преподавателя с проблемой, которую не в состоянии пока разрешить — кури бомбук? А у Python и комьюнити больше, и книг и пр. материалов (качество правда не всегда на высоте, но они хотя бы есть). Да и вообще Python — коммерчески успешный продукт на котором ещё и пофриланчить потом можно. А Оберон что?
Вот зачем студента загонять в рамки языка, с которым у него будет столько проблем — не понимаю :(
на мой взгляд чем меньше нужно для реализации простых программ тем лучше, но…
питон это практический язык, т.е освоив начало можно худо бедно писать нормальные программы, а оберон это нечто вроде коня в вакууме. Взяв же оберон — научится азам кодинга, а что дальше? учить другой ЯП? «НИХАЧУ НИБУДЮ», и будет дальше городить на обероне что сможет.
Я уже не говорю о хорошем built-in в питоне.
питон это практический язык, т.е освоив начало можно худо бедно писать нормальные программы, а оберон это нечто вроде коня в вакууме. Взяв же оберон — научится азам кодинга, а что дальше? учить другой ЯП? «НИХАЧУ НИБУДЮ», и будет дальше городить на обероне что сможет.
Я уже не говорю о хорошем built-in в питоне.
Программист должен не должен намертво привязваться к одному единственному языку. Так или иначе в течение своей карьеры приходится переходить с языка на язык. Поэтому будет очень хорошо, если после оберона человек изучит и попробует что-то еще.
Если первый язык большой. тяжелый и фичастый, при его изучении было потрачено много сил, и вроде бы нет повода с него переходить на какой-то другой, то тогда, когда программисту таки придется поменять язык (лет через 15 возможно), это сделать ему будет очень сложно. Я наблюдал как народ проработавший в делфях по 10-15 лет потом переходил на другие языки — им было тяжко.
Поэтому один из уроков который должен обучающийся вынести — нельзя зацикливаться на одном единственном языке.
Если первый язык большой. тяжелый и фичастый, при его изучении было потрачено много сил, и вроде бы нет повода с него переходить на какой-то другой, то тогда, когда программисту таки придется поменять язык (лет через 15 возможно), это сделать ему будет очень сложно. Я наблюдал как народ проработавший в делфях по 10-15 лет потом переходил на другие языки — им было тяжко.
Поэтому один из уроков который должен обучающийся вынести — нельзя зацикливаться на одном единственном языке.
А в чём тяжесть была пр переходе с Delphi? Синтаксис сильно разнится? IDE непривычна?
Добавлю ещё: не нужно зацикливаться на одной концепции разработки и нужно всячески стараться пробовать и применять, учить и развиваться в смежных областях, не сидеть ровно попой на ООП, а попробовать функциональное программирование, глянуть на АОП, не тараиться в дебаггер сутками, а попробовать применять юнит-тестирование, да в конце концов стараться становиться эффективнее и многогранней, а не думать, что текущее состояние — потолок.
Добавлю ещё: не нужно зацикливаться на одной концепции разработки и нужно всячески стараться пробовать и применять, учить и развиваться в смежных областях, не сидеть ровно попой на ООП, а попробовать функциональное программирование, глянуть на АОП, не тараиться в дебаггер сутками, а попробовать применять юнит-тестирование, да в конце концов стараться становиться эффективнее и многогранней, а не думать, что текущее состояние — потолок.
Для обучения, конечно, можно взять Кнута, и на листочке учить. Компьютер как таковой вообще не нужен.
Любые основы бесполезны, если их нельзя применить, вот прямо сейчас и прямо здесь. Каковы бы ни были просты и прозрачны основы, но без «батареек» в комплекте, они не останутся в памяти.
Любые основы бесполезны, если их нельзя применить, вот прямо сейчас и прямо здесь. Каковы бы ни были просты и прозрачны основы, но без «батареек» в комплекте, они не останутся в памяти.
Именно! И тот же BB CB (для примера) и является теми самыми батарейками.
Последний раз смотрел на BB давно, да, там было с чего начать.
Но в том-же питоне батарейки настолько хороши, что начиная с обучения можно решать вполне актуальные современные промышленные задачи.
Лично у меня, уже давно мнение, что для современных инструментов «широкого применения», наличие адекватного набора библиотек (развитости системной библиотеки) — основной критерий. Для более нишевых — возможны варианты, конечно.
Уходя немного в сторону обучения — в уже классическом курсе SICP выбор LISP (а потом Schema) хорошо обоснован. И переход на Python, кстати, тоже был сделан не просто так, «ради моды», а для достижения вполне конкретных целей. И вообще, говорят, студент должен уметь выучить язык за выходные http://www.cs.berkeley.edu/~bh/proglang.html
;)))
Но в том-же питоне батарейки настолько хороши, что начиная с обучения можно решать вполне актуальные современные промышленные задачи.
Лично у меня, уже давно мнение, что для современных инструментов «широкого применения», наличие адекватного набора библиотек (развитости системной библиотеки) — основной критерий. Для более нишевых — возможны варианты, конечно.
Уходя немного в сторону обучения — в уже классическом курсе SICP выбор LISP (а потом Schema) хорошо обоснован. И переход на Python, кстати, тоже был сделан не просто так, «ради моды», а для достижения вполне конкретных целей. И вообще, говорят, студент должен уметь выучить язык за выходные http://www.cs.berkeley.edu/~bh/proglang.html
;)))
Хм. А я первые программы писал и отлаживал на листочке, на компе они не запускались (ну, уже значительно позже запускал). Считаю, что было очень полезно для меня.
у нас в школе информатика читалась с примерами на языке РАПИРА, который мне тогда казался «русским закосом под паскаль», и это нигде не запускалось живьем (доступа в рамках школьной программы к ЭВМ не было — максимум раз в две недели к умирающим ДВК-3, где даже не помню что работало).
При наличии «за дверьми школы» железяки с гордым названием «Специалист» (РК86 как-то мимо меня прошел) с ассемблером, а потом ZX Spectrum с бейсиком, всё это изучение на листочке мне казалось довольно очень странным, и ограниченным. Глядя на прошедшие уже более четверти века, не думаю, что сейчас это имеет практический смысл. Т.е. я знаю зачем труды Кнута на полке стоят, и понимаю почему там «всё на листочке», но совсем не считаю, что Кнут — это хорошее начало изучения программирования.
Был в моей жизни момент, когда нам читали алгоритмы вычислительной математики, как получать рекуррентное соотношение, какой в этом смысл, что такое рекурсия и как её заменять на цикл, и ради чего — в этом всём, да, компьютер как таковой не нужен. Но практика при изучении нужна в любом случае, и сейчас, когда приходится кому-то что-то рассказывать, я начинаю с практической задачи. Подавляющее большинство людей гораздо больше верит своим глазам, нежели своим логическим выводам :)
При наличии «за дверьми школы» железяки с гордым названием «Специалист» (РК86 как-то мимо меня прошел) с ассемблером, а потом ZX Spectrum с бейсиком, всё это изучение на листочке мне казалось довольно очень странным, и ограниченным. Глядя на прошедшие уже более четверти века, не думаю, что сейчас это имеет практический смысл. Т.е. я знаю зачем труды Кнута на полке стоят, и понимаю почему там «всё на листочке», но совсем не считаю, что Кнут — это хорошее начало изучения программирования.
Был в моей жизни момент, когда нам читали алгоритмы вычислительной математики, как получать рекуррентное соотношение, какой в этом смысл, что такое рекурсия и как её заменять на цикл, и ради чего — в этом всём, да, компьютер как таковой не нужен. Но практика при изучении нужна в любом случае, и сейчас, когда приходится кому-то что-то рассказывать, я начинаю с практической задачи. Подавляющее большинство людей гораздо больше верит своим глазам, нежели своим логическим выводам :)
UFO just landed and posted this here
ой, сори, что-то я не то сделал. Это не ответ, а отдельная мысль, которая к вашей ветке обсуждения не имеет отношения… Хотя…
Какие преимущества, говорите. :) И то, что не надо тратить десять лет жизни на освоение C++ и UNIX-way. И то, что мы в школе учились программировать на неструктурном Бейсике, а могли бы — на модульном Обероне. Но самое важное то, что Оберон ближе к корням (Задумывались, почему Windows 8 не написана на C#?). Он не проповедует свою личную очень авторитетную корпорацию, платформу, архитектуру и виртуальную машину. А напротив — легко ложится даже на те аппаратные ниши, которые разрабатывали ни сном ни духом не ведая про Обероны. Ну попробуйте поработать на C# и Дельфи для Z80. Не то? Ушло в молоко. А на Обероне можно, что я и постарался показать в посте. А, вам не нужен Z80. Да и ради бога, юзайте себе ARM или x86-64. Ага, ещё нишка для Оберонов — микроконтроллеры и прочие Raspberry с Arduino. Через 10 лет будут новые платформы. Туда конечно может быть и лягут .NET и JVM (традиция), но Оберон уж ляжет точно, так что наработки не пропадут. И я советую не использовать существующие Оберон-средства для промышленных проектов быстрой разработки, нуждающихся в плотной интеграции с другими средствами. Они пока не готовы для этого. Но вот чтобы стали готовы — нужны энтузиасты. И ведь что такое Хабр, если не Эльдорадо энтузиастов. Да, было бы здорово если бы каждый воспринял посыл «не готовы» не затем, чтобы критиковать: «тут-то этого НЕТУ!», а реализовал те средства, которых ему не хватает в Оберонах.
А ведь не секрет, что многие языки являются не только техническими средствами, но и средствами конкуретной борьбы «за умы» и выживания друг друга с рынка. Ведущие разработчики современных средств сходятся в том, что технические качества на популярность того или иного средства влияют весьма косвенно. Если хотите знать моё мнение, вокруг любого языка программирования часто воздвигнуто много мифов. Например, что C# — самый безопасный, а Java — самая переносимая. Считаю, вокруг Оберона тоже нужны положительные мифы, и таки да: цель статьи — пиар, но на самом деле пиарить Обероны надо без противостояния другим технологиям, что я и постарался сделать своим постом. Рад, что он вызвал такое бурное обсуждение, что уже даже теряюсь на какой коммент ответить. Спасибо всем!
А ведь не секрет, что многие языки являются не только техническими средствами, но и средствами конкуретной борьбы «за умы» и выживания друг друга с рынка. Ведущие разработчики современных средств сходятся в том, что технические качества на популярность того или иного средства влияют весьма косвенно. Если хотите знать моё мнение, вокруг любого языка программирования часто воздвигнуто много мифов. Например, что C# — самый безопасный, а Java — самая переносимая. Считаю, вокруг Оберона тоже нужны положительные мифы, и таки да: цель статьи — пиар, но на самом деле пиарить Обероны надо без противостояния другим технологиям, что я и постарался сделать своим постом. Рад, что он вызвал такое бурное обсуждение, что уже даже теряюсь на какой коммент ответить. Спасибо всем!
Ой! За такой многословный синтаксис да ещё с CAPSLOCK'ом поубивал бы нахрен! И так уже до хрена «специалистов», которые после Бейсика и Фортрана в школе и универе плодят тонны говнокода, который читать ну просто невозможно. Лично я начинаю испытывать рвотные позывы от такого обилия верхнего регистра (воспользовавшись случаем хочу передвать привет всем дизайнерам и проектировщикам внешнего вида последней Visual Studio ;) )
А скажите, а на этом Обероне индексация в массивах тоже, как не у всех (а как в Delphi) — с 1 насинается?
И что вы к языкам с вируальной машиной и прицепились — у них, как и любого инструмента есть свои плюсы и минусы и области применения, и грамотный специалист не ищет серебреную пулю в одном инструменте, а старается грамотно выбрать этот самый инструмент. И да, для этого нужно стараться постоянно быть в теме, постоянно учиться, а не сидеть на месте, пытаясь доказать, что все вокруг неправы, и все просто лес за деревьями не видят…
А скажите, а на этом Обероне индексация в массивах тоже, как не у всех (а как в Delphi) — с 1 насинается?
И что вы к языкам с вируальной машиной и прицепились — у них, как и любого инструмента есть свои плюсы и минусы и области применения, и грамотный специалист не ищет серебреную пулю в одном инструменте, а старается грамотно выбрать этот самый инструмент. И да, для этого нужно стараться постоянно быть в теме, постоянно учиться, а не сидеть на месте, пытаясь доказать, что все вокруг неправы, и все просто лес за деревьями не видят…
А скажите, а на этом Обероне индексация в массивах тоже, как не у всех (а как в Delphi) — с 1 насинается?
Вообще-то в дельфи почти все индексы начинаются с нуля, что немало доставляет при проходе циклом, где из числа элементов приходится вычитать единицу. :) Кроме того, в новой версии дельфи вообще строки наполовину на индексацию с нуля перевели — LLVM-то с нуля хочет. Индексацию с единицы можно объвлять умершей даже в последнем (полу)живом оплоте паскаля.
Во всех оберонах индексация массивов начинается с нуля.
Итого, достоинства оберона:
1. Он проще, чем плюсы. (Нивелируется необходимостью писать всё для оберона самостоятельно — нет ничего. Да и изучение языка — это далеко не самая сложная часть в обучении программированию, даже если речь о невероятно монструозных и выносящих мозги плюсах. А обучение шарпу вообще довольно просто — при огромной спецификации, там сделано всё, чтобы сюрпризов было по минимуму — спецификацию банально никто не читает. А ведь краткость спецификации — это одно из рекламируемых достоинств оберона.)
2. Он ближе к машинному коду, чем шарп и джава. (Нивелируется отсутствием возможности разрабатывать под что-либо, что актуально сейчас. Ну, микроконтроллеры разве что.)
3. Он не зохаван корпорациями. (Идеология ни о чём. Большинство программистов вертится там, где тепло и хорошо. Будет плохо — найдут другое место. И что корпорации обеспечивают тёплые места — это замечательно.)
Всё остальное — пустые обещания в духе «сделаешь сам поддержку андроида — она будет!» Почему пустые? Да потому что опенсорсное копошение в песочнице неспособно привести к серьёзному прорыву. В современном мире рулят корпорации — даже если взять гигантов опенсорса вроде линукса, мускула, файрфокса и далее по списку. Если проект большой, если замыслы грандиозные — то или корпорация, или никак. Без вариантов. Голое опенсорсное сообщество не в состоянии поддерживать и развивать огромный продукт.
В переносимость джавы, по-моему, уже верят всё меньше. :) А что шарп безопасен — слышу впервые. О какой именно безопасности речь?
1. Он проще, чем плюсы. (Нивелируется необходимостью писать всё для оберона самостоятельно — нет ничего. Да и изучение языка — это далеко не самая сложная часть в обучении программированию, даже если речь о невероятно монструозных и выносящих мозги плюсах. А обучение шарпу вообще довольно просто — при огромной спецификации, там сделано всё, чтобы сюрпризов было по минимуму — спецификацию банально никто не читает. А ведь краткость спецификации — это одно из рекламируемых достоинств оберона.)
2. Он ближе к машинному коду, чем шарп и джава. (Нивелируется отсутствием возможности разрабатывать под что-либо, что актуально сейчас. Ну, микроконтроллеры разве что.)
3. Он не зохаван корпорациями. (Идеология ни о чём. Большинство программистов вертится там, где тепло и хорошо. Будет плохо — найдут другое место. И что корпорации обеспечивают тёплые места — это замечательно.)
Всё остальное — пустые обещания в духе «сделаешь сам поддержку андроида — она будет!» Почему пустые? Да потому что опенсорсное копошение в песочнице неспособно привести к серьёзному прорыву. В современном мире рулят корпорации — даже если взять гигантов опенсорса вроде линукса, мускула, файрфокса и далее по списку. Если проект большой, если замыслы грандиозные — то или корпорация, или никак. Без вариантов. Голое опенсорсное сообщество не в состоянии поддерживать и развивать огромный продукт.
Например, что C# — самый безопасный, а Java — самая переносимая.
В переносимость джавы, по-моему, уже верят всё меньше. :) А что шарп безопасен — слышу впервые. О какой именно безопасности речь?
BEGIN sarcasm
Да, и особенно порадовал очередной пример с Тотал Коммандер, который настолько прямо кроссплатформенный, что вааще… И релизы у него настолько частые, что Гугл со своим Хромом курит в сторонке. А где всё те же незыблемые Скайп и AIMP?
END sarcasm
А если серьёзно, Тотал коммандер — это конечно здорово (правда хороший продукт), но хоть какой-нибудь другой коммерчески успешный кроссплатформенный проект по сложности сопоставимый с Хромом или Огненой лисой приводить было бы убедительнее…
Да, и особенно порадовал очередной пример с Тотал Коммандер, который настолько прямо кроссплатформенный, что вааще… И релизы у него настолько частые, что Гугл со своим Хромом курит в сторонке. А где всё те же незыблемые Скайп и AIMP?
END sarcasm
А если серьёзно, Тотал коммандер — это конечно здорово (правда хороший продукт), но хоть какой-нибудь другой коммерчески успешный кроссплатформенный проект по сложности сопоставимый с Хромом или Огненой лисой приводить было бы убедительнее…
Не забываем что тотал — продукт одного человека (плагины не в счёт). А это уже многое и многое значит.
А если хотите коммерческий успех — Fruity Loops, The Bat, Космические рейнджеры и C++ Builder
А если хотите коммерческий успех — Fruity Loops, The Bat, Космические рейнджеры и C++ Builder
а «сопоставимый по сложности» и «кроссплатформенный» это я так просто написал? :) Ну-ну…
И да, я вижу в вашем комментарии «C++ Builder» — тот самый, недавно вышедшая версия которого до сих пор даже основных вещей C++11 (2 года прошло) не поддерживает :) Его тоже один человек делает? :D
И да, я вижу в вашем комментарии «C++ Builder» — тот самый, недавно вышедшая версия которого до сих пор даже основных вещей C++11 (2 года прошло) не поддерживает :) Его тоже один человек делает? :D
Говорят они теперь выкинули свой C++ компилятор и взяли clang, только вот теперь ругаться по этому поводу хочется. Раз они допилили его для винды, в частности наверняка добили недоделки типа поддержки исключений, то почему я не вижу этих патчей в llvm? Почему все нормальные конторы отсылают туда патчи, а они нет?
Сопоставимый по сложности? Например, сама среда Delphi.
блин, специально для вас:
(коммерчески успешный) and (кроссплатформенный) and (по сложности сопоставимый с Google Chrome)
Вообще судя по ответам, у защитников Delphi реально что-то плохо с булевой алгеброй и разбором «сложного» выражения на простые компоненты… Это по-моему лучший показатель, свидетельствующий о многом!
И да, он (Delphi) наверное сопоставим (хотя я не уверен, одна V8 чего стоит, а ядро Blink (WebKit) — это просто сказка — но поверю, так и быть) по сложности, но коммерческим успехом тут и не пахнет, иначе Borland не продались бы нафиг :)
(коммерчески успешный) and (кроссплатформенный) and (по сложности сопоставимый с Google Chrome)
Вообще судя по ответам, у защитников Delphi реально что-то плохо с булевой алгеброй и разбором «сложного» выражения на простые компоненты… Это по-моему лучший показатель, свидетельствующий о многом!
И да, он (Delphi) наверное сопоставим (хотя я не уверен, одна V8 чего стоит, а ядро Blink (WebKit) — это просто сказка — но поверю, так и быть) по сложности, но коммерческим успехом тут и не пахнет, иначе Borland не продались бы нафиг :)
Не вижу смысла в существовании Оберона, и прочих языков на которых пишется менее 1% создаваемых в мире программ. Историческая ценность, разве что… даже латынь более важна, т.к. применяется в биологии для унифицированного обозначения. Думаю, человечеству необходимо не более 10 разных языков программирования — особенно если кроссплатформенность воспринимать не как свойство собственно языка. Язык — это синтаксис, принципы, и т.п. А на какой платформе это работает — детали реализации.
Но это утопичная картинка, увы.
Но это утопичная картинка, увы.
Независимо от вашего желания эти языки существуют и находят своих поклонников.
Кроме того — малоизвестные альтернативные языки и технологии могут через какое-то время стать мэйнстримом. Технологии должны развиваться, прежде всего за счет альтернативных нестандартных подходов.
Кроме того — малоизвестные альтернативные языки и технологии могут через какое-то время стать мэйнстримом. Технологии должны развиваться, прежде всего за счет альтернативных нестандартных подходов.
Коллега, ну ей богу. Где я что-то писал про свои желания? Про то, что эти языки не существуют?
Но с точки зрения сугубо прагматичной, в них толку нет. На мой взгляд, исключительно. Именно это я и написал.
Но с точки зрения сугубо прагматичной, в них толку нет. На мой взгляд, исключительно. Именно это я и написал.
Когда-то и в плюсах никакого толку не было, все писали на Си и АСМе. А над Java все посмеивались, идея виртуальной машины на том уровне технологий казалась глупостью.
Конечно. Но обратите внимание, речь идет о новых языках. А оберону то сколько уже лет, а так и не стрельнул?
Ну вы же про все языки пишете, которые не входят в TOP10. Кроме того из таких академических языков черпают новизну прикладные языки. Пример — smalltalk. Я не знаю, делают ли на нем прикладные программы, но если и делают, то их крайне мало. Тем не менее этот язык стал вдохновителем парадигмы ООП во всех современных языках.
Никто не отменяет развитие языков. Появление новых, конкуренцию со старыми, исчезновение старых — если они хуже. Суть в том, что старые должны исчезать, если новые лучше. Но огромное количество одновременно существующих языков, решающих одни и те же задачи — бесполезно. SQL и С++ это разные сферы применения. А вот, скажем, оберон и паскаль — для чего нужны оба два? Кроме поддержки легаси кода? Какой новый проект начнут писать на обероне? Да и на паскале я б не советовал.
Какой новый проект начнут писать на обероне?Честно — понятия не имею :) Но если он есть — значит кому-то нужен.
Или руководитель проекта совершит такую глупость и примет решение делать на что-то обероне:)
Почему вы так уверены что это решение будет глупым? Вы же не знаете целей этого проекта.
Если цель не «написать что-то на обероне», то я уверен. Когда мне нужно принять подобное решение, я не ищу экзотики или антиквариата — это избавляет от массы проблем в будущем.
Ок, проект — курсовая на тему «Уникальные возможности альтернативных языков программирования». :)
Я согласен, в боевом продакшене нафиг не нужна такая экзотика, я сам всегда придерживаюсь традиционных технологий. Но программирование не ограничивается коммерческими проектами с типовыми целями вроде быстро-качественно-дешево.
Я согласен, в боевом продакшене нафиг не нужна такая экзотика, я сам всегда придерживаюсь традиционных технологий. Но программирование не ограничивается коммерческими проектами с типовыми целями вроде быстро-качественно-дешево.
Ну я смотрю с точки зрения руководителя проектов в ИТ бизнесе, а не с точки зрения студентов ;)
А если б студенты больше учились писать на том, на чем надо в дальнейшем — всем было бы лучше.
А если б студенты больше учились писать на том, на чем надо в дальнейшем — всем было бы лучше.
с точки зрения руководителя проектов в бизнесе, если у соискателя должности, CV будет «опыт использования Smalltalk, Oberon более года», то в моих глазах у него будет приоритет, перед теми, у кого «5 лет Java, пять лет C++» с кучей названий всяких Java/C++ фреймворков.
Как только «вымрут» все люди, которые его используют — умрет и язык. Язык, это не что-то самостоятельное и существующее независимо ни от чего, это способ.
Если одни люди, предпочитают использовать паскаль, для записи того, как компьютер должен работать, а другие — оберон, почему нет? Кому это мешает? Начнут и начнут. Как показывает практика, инструмент можно заменить по ходу дела.
Если одни люди, предпочитают использовать паскаль, для записи того, как компьютер должен работать, а другие — оберон, почему нет? Кому это мешает? Начнут и начнут. Как показывает практика, инструмент можно заменить по ходу дела.
Это мешает, если вдруг люди меняются, а проект остается. Чем меньше разных языков, тем проще менять людей
Язык обычно составляет меньшую проблему при смене людей. Намного важнее предметная область и специфика задачи.
Можно пойти еще дальше — чем более стандартизован вход/выход, тем легче менять реализации задачи.
Но это какой-то очень однобокий взгляд. В целом, я поддержу мнение, что язык — это очень малая проблема. Вон, у нас, проект… Язык — Java, база — Oracle. Не так-то легко найти людей, как оказалось. Или очень много хотят денег (не совсем понятно за что), или не интересно им у нас. хочется-то че-то «о-го-го», а у нас рутинная корпоративщина.
Но это какой-то очень однобокий взгляд. В целом, я поддержу мнение, что язык — это очень малая проблема. Вон, у нас, проект… Язык — Java, база — Oracle. Не так-то легко найти людей, как оказалось. Или очень много хотят денег (не совсем понятно за что), или не интересно им у нас. хочется-то че-то «о-го-го», а у нас рутинная корпоративщина.
Т.е. посмотрев на статистику скажете, что Lisp, Pascal, Bash, SQL, Lua, Matlab и др. не нужны?
Строго говоря, SQL я бы немного в другую категорию выделил, это безальтернативная в принципе вещь в своем роде. Сравнивать SQL и С++ не стоит.
То же касается Matlab. Но зачем миру оберон -понять отказываюсь.
То же касается Matlab. Но зачем миру оберон -понять отказываюсь.
Строго говоря, SQL я бы немного в другую категорию выделил, это безальтернативная в принципе вещь в своем родеНу почему же безальтернативная, сейчас довольно популярны NoSQL решения, разнообразные ORMы. Или вообще нереляционные БД с обработкой данных обычными языками.
Я к этому и подводил. Есть сугубоспецифичные языки. Для них уже критерий 1% никак не подходит. Зачем миру новый язык? Может и не нужен, а может когда-то станет популярным. Или может он окажется полезным для человека, который создаст какой-нибудь Нунбурун, который станет важным или популярным языком.
Коллега, оберон не новый:) Про новые — ничего не говорил. А оберону уже лет ого сколько, а так никому всерьез и не понадобился. Пора хоронить.
Да, я знаю, что не новый (даже Оберон-2 раза в 2 старше C#, емнип), не совсем верно выразился. Но зачем хоронить, если есть люди, которым он нравится? Я бы вот с удовольствием похоронил Pascal, как язык для изучения в школах/университетах. Ибо навязывается, а реальной пользы сейчас не несёт. А Оберон существует и есть не просит.
На обероне в основном идут исследовательские проекты. То есть миру он примерно затем же зачем и Haskell. Оберон каждый год новый. См. Active Oberon & A2.
А по сути-то что? Рассказали бы хотя-бы про синтаксис и семантику Оберона, что-ли…
UFO just landed and posted this here
По отсутствию BEGIN и наличию END он мне Fortran, Basic напомнил. Ещё и капс.
Скорее Модула.
Но выводить свойства языка из его синтаксиса — так себе идейка.
Но выводить свойства языка из его синтаксиса — так себе идейка.
Исходный вопрос был о синтаксисе и семантике. По семантике, да похож на Pascal. А по синтаксису, кроме Pascal, мне напомнил Fortran и Basic. С Modula не знаком, извините.
(Это я к тому, что 2-х слов недостаточно)
(Это я к тому, что 2-х слов недостаточно)
В паскале все же не было наследования у RECORD'ов, да и сборщика мусора не водилось. Кроме того, в Оберонах принято (хотя это и не обязательно) также в рантайме иметь некую метаинформацию о модулях, переменных и прочем — то есть есть рефлексия. Часто также есть возможность динамической загрузки и выгрузки отдельного модуля.
Все это не слишком похоже на Паскаль.
Все это не слишком похоже на Паскаль.
Вот такое и хотелось бы увидеть в топике. А так получается, что Вы в комментариях к данному топику раскрываете суть языка, а автор поста сказал:
Тем самым приравняв Оберон к Паскалю.
Я смело утверждаю: Паскаль сегодня — это не только Дельфи (полученный методом наращивания), но и Оберон-2
Тем самым приравняв Оберон к Паскалю.
Я планировал вдумчивую серию статей на хабре про то откуда взялся оберон (начиная с Оберон ОС), как развивался и на что годится сейчас. С его плюсами и минусами. Объективная такая серия статей, без фанатизма. Это серия статей обсуждалась и готовилась на нашем форуме. А этот вот товарищ, автор данной статьи, увидел идею публикации и быстренько накатал вот это, сильно смахивающее на рекламную брошюру обильно сдобренную ссылками на свой собственный форум, видимо в рассчете на приток новых участников на оный.
Так что мне приходится отдуваться пока в комментах.
Так что мне приходится отдуваться пока в комментах.
О, г-н Веселовский, видимо, желает раскрыть тему о том гадюшнике, который творится у него на его личном блоге субъективных оберононенавистников под названием Oberspace?
Это разумеется, статья на Хабре не планировалась. Так получилось.
Это разумеется, статья на Хабре не планировалась. Так получилось.
Мой личный блог, если что, находится здесь: valexey.blogspot.com
А Oberspace — это, как ни странно, форум. Где любому гарантирована свобода высказываний, в отличае от иных оберон-форумов.
А то что ты эту статью не планировал — оно и видно. По содержанию :-)
А Oberspace — это, как ни странно, форум. Где любому гарантирована свобода высказываний, в отличае от иных оберон-форумов.
А то что ты эту статью не планировал — оно и видно. По содержанию :-)
[skip]
Да там уже сейчас чёрт ногу сломит. Скоро оно рухнет как любая свалка мусора.
P.S. А ещё обещал в шапке структурировать инфу. «И в точности также из негo постепенно будут выделяться обособленные темы в отдельные форумы». Это я, что ли, писал?
И у нас на форуме на свободу слова ещё никто не жаловался. Ты первый. Хоть там и не зареген.
P.S. А ещё обещал в шапке структурировать инфу. «И в точности также из негo постепенно будут выделяться обособленные темы в отдельные форумы». Это я, что ли, писал?
И у нас на форуме на свободу слова ещё никто не жаловался. Ты первый. Хоть там и не зареген.
Объективная такая серия статей, без фанатизма.
Да-да, особенно ты без фанатизма.
А этот вот товарищ, автор данной статьи, увидел идею публикации и быстренько накатал вот это, сильно смахивающее на рекламную брошюру обильно сдобренную ссылками на свой собственный форум, видимо в рассчете на приток новых участников на оный.
Ну Бог его знает, наверное и ваши потуги многим будет интересно увидеть, как взгляд на Обероны с другой колокольни. Но как же моя статья помешает вашим трудам? Я не более чем рассказал здешнему народу о своей Оберон-деятельности, своём взгляде на Обероны и своём опыте, которые, естественно, подкреплены ссылками (нимало не ожидая, что все сразу ломанутся программировать на Обероне), а вы, видимо, намерены сделать компиляцию из готовых цитат из источников по Оберону. Что ж, флаг в руки.
Скажите пожалуйста — планируемая серия так и осталась планируемой? Было бы интересно почитать.
Опять же возвращаясь к исходным комментариям, синтаксис и семантика не раскрыты, сказать, что это Паскаль — тоже недостаточно.
Видимо, нужно готовить новую статью про качественные отличия в семантике Оберонов по сравнению с Delphi и Modula-2. Ага, я ещё ни слова не сказал про моментальную отладку (она в некоторых источниках называется посмертной, но мне больше нравится термин «моментальная», т.к. передаёт суть и лишён некоего налёта некрофилии) и различные полезные фишки Оберонов, как-то: динамическую охрану типов, динамическую модульность, средства для безопасного программирования. Будьте уверены, если бы достоинств у Оберона перед Паскалем и Модулой не было — я бы его точно не юзал. Но на статью нужно время, так что я просто буду иметь это ввиду, отсылая пока что интересующихся к другим источникам. Например, вот моя подборочка документов для быстрого вруливания в Оберон-технологии. Там есть ответы и акценты на полезных отличиях Оберона.
Ну и вот ещё темка: Полезные свойства Оберон-технологий, их преимущества. Критика «мэйнстрим»-языков
P.S. Мы с вами на Хабре делаем посты и вставляем линки в виде A HREF не потому, что это идеальный способ поделиться ссылкой. Просто это традиционно для веб-технологий и для многих (особенно веб-мастеров) это привычнее, чем что-либо другое. И некоторые люди не поменяют этот способ вставки ссылок ни на более простой и удобный, ни на даже другой, потому что он другой. А я бы предпочёл специализированный редактор, и поверьте, он был бы уж точно не похож на браузер. Это касается и критики Оберона — ведь она часто исходит от личного опыта программиста, который не прощает Оберону уже капс лок, дальше просто не вникает. Я вник, но не жалею.
Ну и вот ещё темка: Полезные свойства Оберон-технологий, их преимущества. Критика «мэйнстрим»-языков
P.S. Мы с вами на Хабре делаем посты и вставляем линки в виде A HREF не потому, что это идеальный способ поделиться ссылкой. Просто это традиционно для веб-технологий и для многих (особенно веб-мастеров) это привычнее, чем что-либо другое. И некоторые люди не поменяют этот способ вставки ссылок ни на более простой и удобный, ни на даже другой, потому что он другой. А я бы предпочёл специализированный редактор, и поверьте, он был бы уж точно не похож на браузер. Это касается и критики Оберона — ведь она часто исходит от личного опыта программиста, который не прощает Оберону уже капс лок, дальше просто не вникает. Я вник, но не жалею.
А кроме как для академического программирования Оберон применим? Есть примеры каких-нибудь живых прикладных проектов?
Есть. Программирование под микроконтроллеры: Astrobe. Живой коммерческий продукт.
Мне очень не нравится Ваш стиль изложения, похоже на рекламный буклет. Статью следует викифицировать [x]
Я сам начинал с Паскаля и много лет программировал на Delphi. Потом я узнал, что такое Java, и это было счастье. Помимо самого языка к нему в нагрузку шли отличные инструменты разработки, либы и сообщество. Потом я узнал, что такое Python и я опять стал счастлив. Не суть, с таким же успехом пошли бы .net, ruby, etc. Когда я смотрю на Delphi, даже относительно новых версий, у меня нет к нему теплых чувств и лично у меня вызывает скорее отторжение. Для меня он не теплый ламповый. Конкретно: мне не нравится сам язык (субъективно), концепции создания GUI (его портируемость весьма условна), сама среда далека до уровня современных IDE (в том числе бесплатных), сообщество адептов мало.
Такие энтузиасты, как Вы, заслуживают уважения, но эти языки я бы ограничил чисто академическим интересом. А вообще для обучения лучше всего python. Для коммерческой разработки они не пригодны.
Пример с Total Commander неудачен, т.к. это не мультиплатформенный проект (что очень печалит).
Неужели еще кто-то пишет под Atari, ZX Spectrum, J2ME? Трудно найти людей, которые в Сегу-то играют (я играю), а это развлечение разве что для истинных ретроградов. Уж лучше под GBA, он хоть портативный :)
IMHO
Я сам начинал с Паскаля и много лет программировал на Delphi. Потом я узнал, что такое Java, и это было счастье. Помимо самого языка к нему в нагрузку шли отличные инструменты разработки, либы и сообщество. Потом я узнал, что такое Python и я опять стал счастлив. Не суть, с таким же успехом пошли бы .net, ruby, etc. Когда я смотрю на Delphi, даже относительно новых версий, у меня нет к нему теплых чувств и лично у меня вызывает скорее отторжение. Для меня он не теплый ламповый. Конкретно: мне не нравится сам язык (субъективно), концепции создания GUI (его портируемость весьма условна), сама среда далека до уровня современных IDE (в том числе бесплатных), сообщество адептов мало.
Такие энтузиасты, как Вы, заслуживают уважения, но эти языки я бы ограничил чисто академическим интересом. А вообще для обучения лучше всего python. Для коммерческой разработки они не пригодны.
Пример с Total Commander неудачен, т.к. это не мультиплатформенный проект (что очень печалит).
Неужели еще кто-то пишет под Atari, ZX Spectrum, J2ME? Трудно найти людей, которые в Сегу-то играют (я играю), а это развлечение разве что для истинных ретроградов. Уж лучше под GBA, он хоть портативный :)
IMHO
Последние 10 лет, начиная с моего знакомства с тем самым паскалем для доса, меня всё время волнует только один вопрос: зачем? Теперь вот делфи в школе преподаю, точнее, лазарус — всё ещё мучает тот же вопрос.
Мне, с моей логикой, привыкшей к стройным С, питонам и даже перлам, не понять в делфи ничего, начиная от совершенно странного синтаксиса. Кто вообще додумался делать нечувствительный к регистру язык? Кто в современном мире использует эти громоздкие синтаксические конструкции, жутко мешающие делать лаконичный, стройный и понятный код? Про всякие тупейшие ограничения а-ля невозможность просто так изменить управляющую переменную цикла я уже молчу. Ставшая легендой; перед else — это вообще за гранью понимания. Массивы, указатели, структуры — всё имеет абсолютно идиотические ограничения в совершенно нетривиальных местах.
Оберон в глаза не видел, но если там что-то написано КАПСОМ, то и видеть не хочу.
Язык — это в первую очередь синтаксис. Во вторую — возможности стандартных конструкций. В третью — библиотеки. Всё это у делфи хромает на обе ноги. Вопрос: а зачем тогда вообще нужен такой язык? Его компилятор может быть сколь угодно эффективен, но не лучше сделать тогда другой язык для этого компилятора без абсурдных ограничений столетней давности?
Мне, с моей логикой, привыкшей к стройным С, питонам и даже перлам, не понять в делфи ничего, начиная от совершенно странного синтаксиса. Кто вообще додумался делать нечувствительный к регистру язык? Кто в современном мире использует эти громоздкие синтаксические конструкции, жутко мешающие делать лаконичный, стройный и понятный код? Про всякие тупейшие ограничения а-ля невозможность просто так изменить управляющую переменную цикла я уже молчу. Ставшая легендой; перед else — это вообще за гранью понимания. Массивы, указатели, структуры — всё имеет абсолютно идиотические ограничения в совершенно нетривиальных местах.
Оберон в глаза не видел, но если там что-то написано КАПСОМ, то и видеть не хочу.
Язык — это в первую очередь синтаксис. Во вторую — возможности стандартных конструкций. В третью — библиотеки. Всё это у делфи хромает на обе ноги. Вопрос: а зачем тогда вообще нужен такой язык? Его компилятор может быть сколь угодно эффективен, но не лучше сделать тогда другой язык для этого компилятора без абсурдных ограничений столетней давности?
Вы вроде взрослый человек, неужели до сих пор не осознали, что существует более одного правильного взгляда на вещи?
Мне вот не нравится французский язык. Он ужасен на мой взгляд, слова перегружены лишними буквами, а рода существительных в нем не совпадают с русскими. И что теперь, повесить ярлык «язык — говно»?
Мне вот не нравится французский язык. Он ужасен на мой взгляд, слова перегружены лишними буквами, а рода существительных в нем не совпадают с русскими. И что теперь, повесить ярлык «язык — говно»?
Язык программирования — это прежде всего инструмент. Когда мне вместо цикла for приходится использовать while только потому, что выбранный язык не умеет базовых вещей — это уже повод задуматься о том, что что-то тут не то. Ведь потом этот код читать и обслуживать. Корабль можно построить из дерева с помощью каменных топоров. Вопрос только — зачем? Just for fun разве что. Как и программировать на делфи. Но допускать такой подход в профессиональную среду мягко говоря странно и необдуманно.
А если сравнивать с лингвистическими языками, то тоже возникает резонный вопрос: вот перл, например, умеет на простейшем уровне базовых синтаксических конструкций всё, что угодно, и как угодно. Делфи же является этакой противоположностью перла: не умеет почти ничего, да и то, что умеет делает порой странно.
А если сравнивать с лингвистическими языками, то тоже возникает резонный вопрос: вот перл, например, умеет на простейшем уровне базовых синтаксических конструкций всё, что угодно, и как угодно. Делфи же является этакой противоположностью перла: не умеет почти ничего, да и то, что умеет делает порой странно.
FOR в Обероне-07, Обероне-2, Компонентном Паскале — есть. Так что не вижу проблем.
И он конечно же позволяет задать произвольное выражение инициализации, произвольное условие и произвольный переход, не так ли? В делфи вот не умеет. И для, например, обхода ассоциативного массива приходится использовать while. Потом читаешь код — сплошные while. И думаешь: если в языке действительно есть for, то где же он?
А вообще дискуссия бессмысленна. Возьмите 10 самых популярных языков и сравните их базовые возможности и особенности с этими вашими разновидностями паскалей.
А вообще дискуссия бессмысленна. Возьмите 10 самых популярных языков и сравните их базовые возможности и особенности с этими вашими разновидностями паскалей.
Возьмем Аду? ;-)
2 копейки про for: а какая вообще разница, как именно записывается цикл? На мой взгляд, важнее, как он читается человеком. Глядя на кусок кода, человек должен четко понимать, «по чему этот цикл» — по количеству обрабатываемых элементов, до какого-то значения, и так далее. Если язык представляет выразительную возможность — хорошо. Если нет — ну, бывает.
В том же питоне, далеко не все «сходу читают» list comprehension. И наоборот — любители таких подходов, «задумываются» при чтении for или комплекта функций map/filter/reduce. Но веселее всего в перле — сколько там есть способов записать цикл очень выразительно? Какие из этих способов наиболее популярны на практике?
Из того, что perl позволяет обработку данных писать практически на английском языке (разбавленном символами верхнего ряда), совсем не значит, что исходники на перле обычно приятно читать.
В том же питоне, далеко не все «сходу читают» list comprehension. И наоборот — любители таких подходов, «задумываются» при чтении for или комплекта функций map/filter/reduce. Но веселее всего в перле — сколько там есть способов записать цикл очень выразительно? Какие из этих способов наиболее популярны на практике?
Из того, что perl позволяет обработку данных писать практически на английском языке (разбавленном символами верхнего ряда), совсем не значит, что исходники на перле обычно приятно читать.
Все-таки циклы в Паскале читаются куда проще чем на С, так как имеют однозначную трактовку. Увидев «for i:=0 to 10 do» вы точно знаете что будут перебраны цифры в порядке возрастания, тогда как на С порядок прохода цикла вовсе не гарантирует тот же порядок что записанный в условиях цикла. И это не говоря уже про то, что некоторые программисты умудряются вписывать в параметры С-ишного цикла довольно сложные условия, которые существенно усложняют читаемость кода стороннему человеку. Должен сказать что при написании кода для себя (или в команде которая придерживается одного стандарта) С удобнее за Паскаль, однако когда дело доходит до чтения чужого кода, Паскаль дает куда большую стандартизацию и соответственно его код проще читается.
А по-моему это отличный инструмент для обучения детей программированию. Сам в 12-13 лет начинал программировать на Delphi. Базовый синтаксис изучался по книжке по Turbo Pascal 7.0 (да, с литературой были проблемы), остальное — пара статей в газете да метод научного тыка. Встроенный тип строк и динамических (безразмерных) массивов в Delphi очень упрощает работу с ним для начинающих.
Потом появился интернет, узнал про C++ Builder — начал писать что-то и на нём. Но по сути это тот же Delphi, только с другим синтаксисом. Не было только понятно, почему класс строк назывался AnsiString. А когда попадался какой-то пример кода с std::string или char*, вообще ничего не было понятно. В Delphi же вся работа всегда велась со стандартным типом строк, и единственное «магическое» действие, которое нужно было делать — это вызов PChar(stringname) (если я не ошибаюсь) при передаче строк в функции WinAPI.
Тогда же я попробовал Visual Studio 6.0 и стандартный C++. Но осилить «этот C++» для создания GUI приложений я не смог, только консольные утилитки, создание которых и описывалось в книжке, которая попала мне в руки. Но консольные приложения — мне, как ребёнку, было очень скучно делать. Там же описывалась работа со строками char*, std::string и был пример создания собственного класса строк. Но зачем столько сложностей из-за каких-то строк было совсем не ясно.
На сколько я могу сейчас судить, тогдашний MFC сильно отставал от борландовской VCL. Я уже 7 лет ничего не писал на Delphi, но иногда тоскую по его редактору форм :) Вроде как тот редактор, что сейчас предлагает VS2010 (например, для WinForms) уже и неплох, но всё равно что-то не то. Не хватает «ламповости», наверное :)
Потом появился интернет, узнал про C++ Builder — начал писать что-то и на нём. Но по сути это тот же Delphi, только с другим синтаксисом. Не было только понятно, почему класс строк назывался AnsiString. А когда попадался какой-то пример кода с std::string или char*, вообще ничего не было понятно. В Delphi же вся работа всегда велась со стандартным типом строк, и единственное «магическое» действие, которое нужно было делать — это вызов PChar(stringname) (если я не ошибаюсь) при передаче строк в функции WinAPI.
Тогда же я попробовал Visual Studio 6.0 и стандартный C++. Но осилить «этот C++» для создания GUI приложений я не смог, только консольные утилитки, создание которых и описывалось в книжке, которая попала мне в руки. Но консольные приложения — мне, как ребёнку, было очень скучно делать. Там же описывалась работа со строками char*, std::string и был пример создания собственного класса строк. Но зачем столько сложностей из-за каких-то строк было совсем не ясно.
На сколько я могу сейчас судить, тогдашний MFC сильно отставал от борландовской VCL. Я уже 7 лет ничего не писал на Delphi, но иногда тоскую по его редактору форм :) Вроде как тот редактор, что сейчас предлагает VS2010 (например, для WinForms) уже и неплох, но всё равно что-то не то. Не хватает «ламповости», наверное :)
Вообще, отличным инструментом для обучения является тот инструмент, на котором обучаемый (ну, например ребенок) может (возможно с помощью учителя) быстро сделать что-то интересное (интересное для него) и наглядное. Это дико мотивирует продолжать обучаться дальше.
Так вот, у Оберонов с этим вроде бы как раз все хорошо:
Так вот, у Оберонов с этим вроде бы как раз все хорошо:
- BlackBox CB (Component Pascal) позволяет наглядно (через те самые составные документы) делать интерактивные живые графические штуки, не парясь особо о формах, и прочем. Сделать виртуального робота ездящего по полю и для него же тут рядом сделать пультр управления — да легко!
- Astrobe (Oberon-07/11) позволяет запрограммировать микроконтроллер. И тут уже можно ездить реальным роботом, управлять реальными физическими объектами. Причем алгоритмический код у Компонентного Паскаля и Оберона-07, вообще говоря может быть один и тот же (есть некое базовое подмножество statement'ов, где они совместимы). Скажем программа управления роботом может как управлять им в BlackBox'е так и работать в микроконтроллере и управлять реальной железной штукой.
«Это Оберон — самый красивый из всех минималистичных языков ...»
Посмотрите на лиспы.
Посмотрите на лиспы.
Ну это ж красота — штука весьма субъективная. Равно как и минимализм (где тот порог, где уже не минималистичность, а примитивизм?). Кому то и С++ красиый минималистичный язык :-)
Да смотрел я на Лиспы и на Питоны с Руби. Форт ещё есть, тоже интересный язык. Но положительное отличие от них Оберона в том, что программу на Обероне поймёт любой грамотный инженер, а на скобочных языках надо каждую скобку штудировать с талмудом в руках. И обучать свою племянницу Лиспу я не стал бы.
Я увлекаюсь языками программирования. Если полагаете, что вру и на самом деле не слышал о Лиспе, то вот вам исходник «цветочка», который я когда-то делал на Лиспе. Ещё пытался на нём сделать карточную игру, но, правда, не очень продвинулся. Зато смог насладиться исходниками игры Abuse. Так что представление о Лиспе есть, и, пожалуй, не будем сравнивать вот так вот в лоб императивную и функциональную классику.
Я увлекаюсь языками программирования. Если полагаете, что вру и на самом деле не слышал о Лиспе, то вот вам исходник «цветочка», который я когда-то делал на Лиспе. Ещё пытался на нём сделать карточную игру, но, правда, не очень продвинулся. Зато смог насладиться исходниками игры Abuse. Так что представление о Лиспе есть, и, пожалуй, не будем сравнивать вот так вот в лоб императивную и функциональную классику.
Уж что-что а лисп, а тем более его более легковесные диалекты вроде Scheme, должен понять с лету любой грамотный инженер. Синтаксис там элементарный (ибо он практически отсутствует). А на счет семантики конструкций все равно в доку надо вначале посмотреть. Потому как совершенно интуитивно не ясно что делает например statement WITH в Обероне-2. И что означают именя процедур со звездочкой.
Короче, в доку все равно смотреть надо и там и там. Проще будет то, что больше похоже на то, с чем ты работал. Новичку же — будет одинаково что Оберон, что Scheme, ибо это и будет его начальная точка отсчета.
Короче, в доку все равно смотреть надо и там и там. Проще будет то, что больше похоже на то, с чем ты работал. Новичку же — будет одинаково что Оберон, что Scheme, ибо это и будет его начальная точка отсчета.
А есть ли в природе 64х битный компилятор Оберона под Windows?
Прям таки компилятора который сразу компилит в x86_64 я не припомню. Есть трансляторы из Оберона в Си, и этот код, возможно, можно нормально собрать уже под 64 (но я не помню чтобы кто-то делал такие эксперименты). Ну и есть компиляторы под jvm и .net, и там уже через jit будет 64 битный код.
Но вообще, сейчас потихоньку движется одновременно для нескольких компиляторов работа по прикручиванию llvm-бекенда, как прикрутится, так будет и 64 бита, и вообще кодогенерация станет более качественной.
Но вообще, сейчас потихоньку движется одновременно для нескольких компиляторов работа по прикручиванию llvm-бекенда, как прикрутится, так будет и 64 бита, и вообще кодогенерация станет более качественной.
born2fly> А есть ли в природе 64х битный компилятор Оберона под Windows?
Для x86-64 — пока нет. Но, уверен, что появится в ближайшее время.
Остаётся возможность разрабатывать на Обероне для этой архитектуры через трансляцию в Си.
Для x86-64 — пока нет. Но, уверен, что появится в ближайшее время.
Остаётся возможность разрабатывать на Обероне для этой архитектуры через трансляцию в Си.
Sign up to leave a comment.
Паскаль, Дельфи и Оберон сегодня