Оберон-клуб «ВЄДАsoft»

Оберон -- один на всех. Мы за ценой не постоим. А вот реализации Оберона -- своя под каждую задачу. Читай внимательней.



1. Оберон не может в 32-битных задачах выделить 4 млрд 1 байтовых значений. В 32-битных задачах (например, в Windows) доступно всего 2 млрд. байт. К тому же, объект имеет адрес, тип, размер, номер и др. скрытые поля. В лучшем случае 500 млн. Если речь идёт о серверном варианте, то 100 МБ вообще не проблема))
2. Если речь идёт о массиве -- то так не выйдет. Если о цепочке -- то ты никогда не узнаешь в каком порядке они расположены. Система связей может оказаться такой, что чёрт ногу сломит и GC с поколениями или уплотняющий могут затормозить программу до невозможности. На практике, освобождённые блоки помечаются как свободные и дальше используются заново. Это нормальная практика.
3. В реальных задачах точно никто не создаёт и не освобождает массивы в таких объёмах. Либо крайне редко. В самом начал насоздавал, и повторно пользуешь.

Самый лучший оптимизатор памяти и опция компилятора -- мозг программиста.

В целом, я ничего не имею против изощрённых GC, но сть такое понятие как репорт(декларация) языка и реализация. Всё же -- это сильно разные вещи.

_________________
Действия профессионала предсказуемы. Но в мире полно любителей!

Ну ё-моё... Я думал мы тут все серьезные люди. Ну ладно...

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

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

_________________
Действия профессионала предсказуемы. Но в мире полно любителей!

Я думаю, что под задачу скорее не язык, а реализация. Для программирования на обероне нужно две вещи:

1) Прочитать описание реализации, которую предполагается использовать и научиться с ней работать.

2) Иметь представление о целевой платформе, достаточное для разработки.Так, например, я хоть и знаю оберон, но не могу использовать твою реализацию, потому что мое представление о вэб-разработке недостаточно. Точно так же, для работы с другими реализациями необходимо знать микроконтроллеры, API операционных систем и т. д.

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

Именно так, Антон. Как видно по моей цитате сверху -- я именно так изначально и написал.
Влад периодически читает так, как он привык читать))


Я думаю пойти по пути именно расширений языка. Но, всё-таки не ядро ломать, а использовать какие-то сторонние платформо-зависимые библиотеки.

_________________
Действия профессионала предсказуемы. Но в мире полно любителей!

И до какого предела кошерно расширять реализацию? Пока джава не получится?
Вот, например, мой любимый oberonjs - это реализация оберона под задачу или новый язык на основе оберона?

Расширить -- не значит напихать говна.

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

Оберон на жабаскрипте -- это я за. Но я против прикручивания к Оберону тех способов, какими жабаскрипт порождает новые объекты. Это уже не Оберон. Если ну очень надо -- это в либы.

_________________
Действия профессионала предсказуемы. Но в мире полно любителей!

Это в высшей степени субъективно

А где-нибудь описан формат объектов BBCB? Это я к вопросу о консервативности. И сразу ещё один вопрос. Сейчас integer 32-битный. Если вдруг он станет 31-битным, а 32-й бит, равный нулю, будет тегом типа integer, станет ли это катастрофой?