OberonCore

А что будет с другими языками через десять лет? Intel уже предупреждает, что тысячеядерные процессоры не за горами. Мэйнстрим готов к такому повороту событий?

Сегодня вызвали метод, завтра чёрт знает что от него унаследуют (только потому, что кому-то показалось чего-то удобным) и т.п.
Есть хорошо известный принцип "разбитого окна": оставь разбитым одно окно в доме - и скоро дом превратится в помойку.

А что будет с Windows?

Я не про языки, как таковые. Я про трансляторы.
Вот Фортран жив до сих пор. Есть современные трансляторы под современные процессоры. Есть куча гигантского кода. Есть гарантия, что транслятор для Фортрана будет. Мейнстрим всегда готов
А насчет оберонов - гарантии нет.


Жива будет. Куда денетесь?

!!! !!! (это на замечание Ярослава Романченко )

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

А видел я следующее: step-by-step и последовательное уточнение шли лесом. Написали, прогнали test case. [Не работает? Нашли, исправили, прогнали test case]*

Словом, никакого проектирования. Или проектирование есть, но оно всё равно никакое : ).

Пропорции могут быть разные. Вот я и спросил.Не понял, чем подмена реализации плоха?Ну вот, теперь целое ещё и через NEW создаётся. С добрым утром, как говорится... Меня тоже, если вы не вдруг не заметили, компилятор в ББ тоже стучит по башке при малейшем намёке на странные действия на уровне языка(SYSTEM не в счёт).Обработать можно по разному. Опять непонятно. Вона, у меня в процессе отладки ассерты сыпятся, я иду в код, исправляю ошибку. А вы как делаете? Пошагово проходите всё подряд? А в ББ насколько я знаю останавливается только текущая ошибочная процедура(сказал утрированно). Можно даже взять и выполнить её ещё раз сразу после этого. Среда такая. Я ни во что не верю, я говорю только то, что вижу, и то, что я по этому поводу думаю. Ваша формулировка вас "сдала". Не "умеют проектировать", не "грамотно продумывают ПО", а "умеют на С++". Думает соответственно кто-то другой. На Оберона МОЖНО писать неправвильные программы, на уровне более высоком чем язык. Я не знаю что такое GC. Ничего про него сказать не могу. Я про языковой сахар говорю.Раз уж тут все Эйнштейна цитируют: Мой закостенелый мозг ленится напрягаться при работе с числами у которых "вдруг" есть метод. И это только частный случай, а ведь есть и другие.Если функция правильная, то в результате вы получите код ошибки и NIL. но это если функция написана правильно. Иначе - программист дураг. Я думаю, популярность плюсов, шарпа и явы обеспечена большим числом ОСей, написанных на Си++, и агрессивной политикой неких компаний, продвигающих шарп и яву. А у Оберона такого нет. Неужели вы думаете что многомиллионная армия программистов сидит и натужно рассуждает о преимуществах того или иного языка? У них просто выбора нет. Вернее - есть. "Выбор без выбора".
Никого я не заставляю. Мне начихать, что вы там вытворяете в шамаке стоя. Я говорю от себя и про себя.Язык определяет реальность. Смеющиеся числа пишущие себя в строку - зазеркалье. Эргономичное, мягкое, удобное, но зазеркалье. И чОрт знает, что там случится в следующий момент.Теперь, поскольку вы в зазеркалье, вы раб вашей среды разработки, а не наоборот. Связали себя очень частными понятиями об числах-объектах и прочем. И привет.Как мне сказал один мейнстримщег: кому нужна неизвестная среда с неизвестной перспективой... и в шутку добавил "без пошагового отладчика" однако язык здесь не причём. А будет вот что: активные объекты, и Микрософт Мидори, которая их якобы выдумала. Ну и ещё возможно РОСА(было бы замечательно). И все станут думать не так как сейчас и утверждать об исключительной верности такого подхода.

Возможный вариант: Интел, после развала DEC-Compaq фактически монополизировал производство фортрановских компиляторов под свою платформу. Если на самом деле (active) Оберон обладает неоспоримыми преимуществами для многоядерных процессоров, то следующим в интеловской линейке компиляторов мог бы быть Intel Visual Oberon Compiler...

Active Oberon - половинчатый шаг. Его достоинство не в "неоспоримых преимуществах", а в отсутствии принципиальных недостатков с точки зрения многопроцессорности. Т.е. от Оберона можно идти вперёд более-менее прямым путём, в отличии от тупиковых веток в виде бегающих ныне всюду динозавров Что и делает группа Гуткнехта.

GС - Garbage Collector. Сборщик мусора.

То есть как это? В Обероне? Тогда индусы и рядом не валяются.

Быстро же тема убежала..

Не очень наглядно получилось с преобразование в ASCII? Можно взамен рассмотреть какое-нибудь преобразование координат. Координата в одной системе - тип "А", в другой - тип "В". Формулы преобразования не отражают сути каждой системы координат(СК), они задают связь между этими системами. Короче, подойдёт любой случай, где преобразование "f" - вычислительного типа. Тогда для преобразователя знание сути типов А и В опять не будет являться необходимым. Не нужно знать преобразователю как вычислить расстояние между 2-мя точками в каждой СК, рассчитать угол между прямыми, плоскостями и т.п.. Также как и не нужно включать в себя координаты всех точек в каждой СК.

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

Нет, базовый тип - это пока "священная корова". Покопал я сериализацию в ББ. В конечном итоге всё втаскивается через SYSTEM.VAL, выливается - через WriteByte(s). Т.е. BYTE оказался "немножко более базовым".Скорее всего это правильно - среди однообразия должно же быть хоть какое-нибудь безобразие , с железным блатом от двоичной системы. Можно придраться только к сильной зависимости от аппаратной платформы - выливать по байтику на 32-разрядной платформе не совсем логично, а на 64-разрядной платформе это будет просто преступлением. Как ни крути, "более базовыми" окажутся типы, "разрядность" которых совпадает с разрядностью представления данных на конкретной целевой платформе. Видимо базовая сущность ещё и нуждается в определении, кто "более базовый".
Теперь посмотрим на это с точки зрения предыдущего абзаца. Может быть для сериализации слишком рано зафиксировали приведение к конкретному базовому типу? А может просто не надо было на данном этапе развития системы закладывать дополнительные слои абстракции, отражающие ещё и приведение к аппаратной платформе. То, что WriteByte(s) абстрактные - видел, но дальше не докопал. Вероятно стоит спросить у более опытных участников.
Хотя Илья Ермаков уже заметил, что при сильно расширенных абстракциях (вроде поиска методов в интерфейсах) "..интеллектуальный контроль за происходящим и прозрачность работы теряется"

Все эти рассуждения к тому, чтобы понять, почему из Вашей абстракции достаточно высокого уровня, "торчат уши" табличного преобразования? На мой взгляд они лишние.

Я тоже так считаю.

Не подмена реализации. На 16 страницах ничего нет про то как перенаправить ASSERT в файл лога и т.д. Но это странно слышать от человека, который больше любит работать с кодом не подокументации, а по исходникам...А вот здесь как раз-таки всё в порядке. Имеем дело с объектом. Теперь пусть хоть shutdownPC() вызывают.Грубо, однако.

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

Вопрос об отношении человека и среды разработки очень глубок и интересен. В полной мере его ещё никто не исследовал, даже теоретически. Есдинственным "противоядием" от сползания в другую крайность я вижу чёткую базовую КОНЦЕПЦИЮ (отнюдь не систему типов какую-нибудь!).
Так вот, представления о числах как объектах лучше вписываются в стройную концепцию, чем жёсткая система "базовых типов" (о подводных камнях которой Вам тут уже написал Рэйлвэй Каген).

Далее, стройная абстрактная концепция - отнюдь не "частное понятие". И, конечно же, не "зазеркалье", а необходимое условие разработки БОЛЬШИХ проектов.
Кстати сказать, "базовые типы" с байтами и интегерами имеют куда меньшее отношение к реальности, чем концепция ООП.

P.S. Такое ощущение, что все наступают на старые грабли и под ООП понимают Программирование. В то время как это Проектирование.

P.P.S. И OOD тоже не панацея, как бы ни хотелось в этом увериться апологетам мэйнстрима и их критикам

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

Скажем, мне надо провести ветку таким путём (семантика), а Дракон-редактор глючит и не позволяет это сделать, но можно обойти так (синтаксис)

Когнитивный аспект важен и сложен. Но это неизбежная (и минимальная) плата.

Если базовая система типов определена не физическим представлением (как в Фортране-Сях), а на алгебраическом уровне - множество значений + совокупность операций (Модула-Оберон), - этого разве не достаточно для стройной концепции? Можно и на шаг дальше, как в Ada - ТД как задание содержательной роли данных (подтипы аля "скорость", "высота" с ограничениями и контролем совместимости). Но всё равно с сохранением границы между моделью данных (в каких терминах-знаках общаются наши подсистемы) и моделью деятельности (чем там мы моделируем подсистемы из предметки, их умения и активности).

не возражаю

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



Ужас просто какой-то... Целое через new - это "new int". А Integer - это сколь угодно специфичный класс. Кому нужен просто int? Вы же сами говорили - это пустая математическая абстракция. Она вообще ничего не отражает. Поэтому вам и приходится лезть в документацию и смотреть: вот в этом интерфейсе int предаставляет собой килограммы, а вот здесь - количество яблок, а вот здесь - номер колонки, а вот здесь - цвет. А мне не надо смотреть документацию и прыгать в реализацию, потому что, например в первой попавшейся подсистеме (64кб .h + .cpp) я только что нашел только 5 (пять) int'ов (и те не в интерфейсах).



Это вы не заметили, что я приводил конкретные примеры, когда компилятор BB ничего не может сделать.



Вы правда думаете, что если человек не пишет на обероне, то и ASSERT'ы он не ставит? Это вы говорили, что видели MFC? Видели сколько там ASSERT'ов? А видели хоть один ASSERT на апишном вызове?



Одно другому противоречит? Мы обсуждали языки, а не софтостроение в целом.



А я говорю про ошибки, которые допускаются людьми при программировании на обероне и которые просто невозможны в других языках.



Очень хорошая цитата. Поработав на языках, которые позволяет выражать вещи в намного более приближенных к предметной области терминах нежели "целое число от 0 до MAX" и "массив символов", на оберон пересесть трудно.



Ага. Об чем и речь. Баги, которые в других языках просто невозможны, оберонщики обходят вручную (только не забыть бы с кодом ошибки вернуть NIL).



Очень в этом сомневаюсь. Может быть "это" и будет называться "активные объекты", но не в том виде, в котором они представлены в Active Oberon.

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