OberonCore

В общем случае проблема выглядит как несовместимость модулей. Можно предложить ввести не запрет на расширение по умолчанию, а расширение с контролем прав. Тогда EXTENSIBLE не понадобится.

Еще, базовые типы разные. Ну, там INTEGER - в Обероне 16 битный, а в Компонентном Паскале - 32х.

По поводу базовых типов - в Обероне они вообще не зафиксированы, если я не ошибаюсь. А вот в КП привязаны к стандарту Java. Базовые типы - это не слишком большая проблема, на мой взгляд. Они и должны быть плавающими в большую сторону, дабы тот же INTEGER всегда соответствовал разрядности процессора.

Не соглашусь. Достаточно посмотреть на "переносимые" исходники на Ц.

Кстати, переход на 64 бита просто повлечет добавление HUGEINT.
Большинству программ достаточно будет 32-битного INTEGER.
Трудно ожидать, что появится такакя же потребность использовать LONGINT, какая была при 16-битном INTEGER. (Тут зависимость не линейная, а, скорее, логарифмическая.)

--------------
И, кстати, если программа на КП не использует SYSTEM, то она автоматически будет правильно компилироваться на 64-битной платформе. <Имелось в виду, что разрядность указателей нигде в языке не проявляется.>

А может быть даже и не повлечёт. Просто операции с 64-битным LONGINT станут выполнятся (~ в 6 раз) быстрее.

128-битные HUGEINT обычно нужны только тем программистам, которым нужно работать ну с оооочень большими числами, но как раз для них 128 бит - это не такое уж большое число.

Тут еще такой момент: для большинства программ действительно хватает емкости 32-бит. Но там, где объем памяти не имеет значения (ну, те же локальные переменные) лучше всегда использовать родную разрядность процессора. Быстрее работает. То есть, если INTEGER становится 64-битным, то все старые коды (а, если они не используют SYSTEM, то они остаются совместимости) можно без изменений перекомпилировать, и они будут работать быстрее. Но если он остается 32-битным, то такого сильного убыстрения не будет, так как процессор будет работать не со словом, а с полусловом, а это всегда медленней.

Не уверен. С вещами вроде SHORT( ENTIER( real ) ) обязательно будет морока.
Лучше уж пусть немного медленнее программа работает.

При дефиците грамотных программистов и изобилии железа ...



Со всеми кэшами и пайплайнами -- еще неизвестно, насколько медленнее.

Возможно. Сегодня помогал одному знакомому подобрать машину "для дома". Продавец-консультант утверждал, что 64-бит процессор дает серьезный прирост производительности даже на старых приложениях в старой ОС. Не знаю, не знаю, не пробовал...

Почитал ветку форума...

1. Мне кажется, что сейчас остро не хватает модульного компилятора с языка Оберон, который позволяет легко (даже студенту) экспериментировать с синтаксисом, добавляя новые языковые конструкции, ключевые слова и т.д., но при этом не внося никаких изменений в исходные и бинарные модули основного компилятора. Причем (и это принципиальный момент), новые конструкции всегда должны быть выразимы через существующий базовый синтаксис (как оператор using в языке С#). Это бы позволило гарантировать, что чистые Оберон-программы будут работать всегда и школьники и студенты не будут перегружены некоторыми конструкциями, которые со временем отомрут (я имею в виду ООП). С другой стороны, можно будет опробовать некоторые концепции и создавать проблемно-ориентированные языки на базе общих правил построения синтаксиса.

Мне кажется (да простят меня коллеги), что КП -- это уже вчерашний день. Жизнь потихоньку отодвигает ООП со своих позиций. ООП плохо совместим с принципами расширяеющего программирования, а КП проповедует ООП.

2. Не лучше ли от форумов, где тебя всегда могут оплевать противники, перейти к блогам. Блоги всегда именные, там на первой странице твое мнение, а разные комментарии всегда на втором плане. Т.е. острая критика есть, но она не мешает читать ценные мысли автора. Лучше организовать ссылку на блоги на каком-нибудь известном сайте, например http://www.oberon2005.ru.

Дмитрий, расскажите поподробней, пожалуйста, про отмирание ООП.

И про блоги я мысль не понял, кстати...
У нас просто на сайте пока наполнение небогатое. Но сейчас наберем потихоньку. Блок по компонентному программированию (переводной) появится на днях. По модульности планируем добавить.
И учебные материалы.

Про вчерашний день КП... В теоретическом плане - наверное, Вы правы.

А в практическом... Какой там вчерашний, когда индустрия до него еще не допрыгнула? Вот C# только подошел... В производстве КП сейчас "развивай - не хочу". А эксперименты с Обероном - это разговор отдельный и очень интересный.

А я не понял мысль о модульности компилятора. Dmitry, Вы считаете существующий компилятор недостаточно модульным или недостаточно легким для расширения?

[quote="Dmitry"]Мне кажется (да простят меня коллеги), что КП -- это уже вчерашний день. Жизнь потихоньку отодвигает ООП со своих позиций. ООП плохо совместим с принципами расширяеющего программирования, а КП проповедует ООП.[quote]

ООП -- по кр. мере в интерпретации Симулы/Оберона -- абсолютно естественное и развитие обычного процедурного программирования, мотивированное, в сущности, чисто внутренними проблемами последнего. Поэтому нелегко понять, как и куда его можно отодвинуть -- особенно если учесть, что процедурное программирование -- это то, как работает "железо".

Я видимо непонятно изъяснился. Я хотел сказать, что обсуждение некоторых вопросов лучше вести не в форме форумов, а в форме так называемых "блогов" (blogs, Web-blogs), или проще говоря, в форме дневников. Сейчас эта форма общения очень популярна. Суть ее в том, что у каждого пользователя есть свой блог -- страничка, на которой он ведет свои записи, отображаемые в обратном хронологическом порядке (самая свежая заметка -- вверху). К каждой заметке посетители могут добавлять свои комментарии.

Я просто хотел противопоставить блоги форумам. Очевидный недостаток форумов в том, что важные и интересные суждения начинают теряться в ворохе необдуманных (порой неуважительных) ответов и реплик. Происходит заговаривание зубов, отвлечение от темы, переход на личности и т.д. На форумах очень много информационного шума. Кроме того, я за собой заметил такую тенденцию. Я читаю не все, а лишь реплики конкретных людей, которые меня либо раздразнили, либо заинтересовали своим мнением. Вот тут как раз хороши блоги. Это заметки конкретных людей по разным вопросам, причем эти заметки очень трудно "заглушить" информационным шумом.

Про отмирание ООП я опасаюсь говорить на форуме, ибо ожидаю большого потока встречного негатива и попытках увести дискуссию в сторону. А отвечать на каждый укус у меня нет времени. Но тема эта очень стоящая и отдельная, она меня волнует давно. Если говорить коротко, то единственное, что дало ООП -- это... Нет даже не расширение типов данных, как считает Вирт... Это нотация вызова процедур. Вместо формы

ГлаголСуществительное(Существительное, существительное, ...)

программисты стали писать

Существительное.Глагол(существительное, существительное, ...).

Это, конечно, очень важно, но на этом достоинства ООП заканчиваются. Обсуждать эту тему дальше на форуме я бы не хотел, поскольку у меня нет много свободного времени для отражения всех атак, которые наверняка начнутся после столь категоричного заявления.


Вы правы, индустрия до этого еще не доросла. Но если сравнивать с той же технологией .NET, то КП ничего принципиально нового не дает, более того, не лишен тех же пороков. А нужно быть на шаг, а то на два, впереди. Например, следующее десятилетие -- это десятилетие многоядерных многопроцессорных систем и параллельных вычислений. А как на это смотрят разработчики КП? Я опасаюсь, что КП -- это как Линукс -- просто копирование общепринятых, но устаревающих подходов.

Я не против КП, все-таки это модульный Паскале-подобный язык. Но для серьезного успеха этого мало. Необходимо технологическое превосходство, причем именно в области инфраструктуры компилятора. (Я так дамаю )

Сразу оговорюсь, что знаком с ООП с 1989 года, еще с тех пор, когда мне в руки попался TurboPascal 5.5 (c объектами). С тех пор являлся ярым сторонником и пропагандистом ООП. Однако, в последнее время (после разработки ряда систем) мое понимание программирования изменилось и я критически оцениваю ООП. А отодвинуть ООП можно. Например, в Обероне нет ООП в классическом понимании этой концепции, но можно создавать объектно-ориентированные программы.

Вопрос ООП (как я уже писал Илье) слишком тонкий для обсуждения в форумах (нужны блоги). А мысли у меня есть. Причем, не только мысли, а даже идеи. Но они требуют хорошей формулировки (чтобы гнилые помидоры не прилипали).

Обсуждение "языка с динамически мутирующим синтаксисом" перенесоно в отдельную соседнюю тему:

http://blackbox.metasystems.ru/forum/viewtopic.php?t=76

хмм... кое в чем я согласен с Дмитрием...

по ООП - наследование и хорошо и ПЛОХО тем что оно принципиально однонаправленное. конечно при проектировании можно все вытянуть в DAG но... потом? коренные модификации? наследование позволяет реализовать только однонаправленные точки роста. причем эти гнезда должны быть запланированы заранее.
наследование образует в программе недостаточно явные сложные взаимосвязи. теоретические исследования показали что длинные его цепочки притивопоказаны, применять где попало его нельзя. максимум что можно - это реализовать абстрактные гнезда расширяемые один раз, но по-разному (проблема хрупких базовых классов)...
в свете этого заявления о смерти ООП вовсе не еретические, некоторые с самого начала считали что маркетинга мало для придания ему жизни))
так что вообще необходимость поддержки его в языке под вопросом. что на самом деле тут лучше подходит - так это поддержка множественных реализаций одного неизменяемого интерфейса. подобно как в Модуле. опционально отдельные .DEF и .MOD либо нечто через концепцию module-type как в статье "Is Oberon as simple as possible?". явные отдельные интерфейс и реализация так-же дисциплинируют и говорят полезны для командной писанины. стабилизирует архитектуру. заставляет думать до а не после.
LightningOberon?
давно не слышно ничего...
сделать нечто среднее между Модулой и Обероном было бы полезно для увеличения толпы))

более развернутое обсуждение проблемы тут
http://www.modulaware.com/mw64bit.htm
кстати мне кажется что введение уникода тоже представляет собой подобную проблему. Конечно скоро понадобится полная переделка BlackBox (вспомним замечания о некоторой сумбурности его низкого уровня которые тут не раз приводили разные люди, она является возможно просто следствием интерфейса с корявой системой). Так может стоит подумать над обьединением низкого уровня System3 и высокоуровневых частей BlackBox? и силы обероновцев обьединятся и BB портируется на самые разные архитектуры в итоге? Как думаете, какие при этом возникнут проблемы?

Насчет ООП -- мы говорим об одном и том же:
под ООП как продолжением... я имею в виду не ООП как всеобъемлющую философию и "парадигму", а именно "ограниченное" ООП (абстрактный тип <--> несколько конкретных реализаций) -- другое не использую и студентам не учу ... уже забыл давно

Считаем, что есть консенсус.

На этой ссылке пример того, как законный энтуазизьм порождает маниловщину во всех наши планах ...

Кстати, нужно обязательно учитывать, что Модула-2/Оберон с одной стороны, и Компонентный Паскаль с другой -- определены с точки зрения переносимости существенно по-разному.

Для практических целей единственный "горящий" пункт -- 64-битная адресация. Все остальное (особенно LONGSET и т.п.) может спокойно ждать будущих релизов.

С другой стороны, любое инфраструктурное движение, способное привести к объединению сообщества без увеличения энтропии в инструментах, следовало бы приветствовать.

Как-то я оставил без внимание эти замечания -- на мой взгляд, сильно неверные. Сравнивать КП с линуксом в плане копирования "общепринятых, но устаревших подходов" очень, очень странно.

И как раз в области "инфраструктуры компилятора" хотелось бы как можно меньше новшеств...