OberonCore

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

Фигня. Вспомните МАТЕМАТИЧЕСКОЕ определение дерева - это рекурсивное определение. Список (последовательность) - аналогично.

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

Вспомнил: конечный связный граф с выделенной вершиной без циклов. Есть еще индуктивное определение. Причем тут объединение вершины и связей в одну рекурсивную структуру , совершенно не ясно.



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

Например:
http://www.insidepro.com/kk/198r.shtml

Ага... Мы все это читали много лет назад в книжках вроде: структуры данных на фортране...

Видимо забыли. Этот Вирт окружил вам головы приматическим элементом. И как это до Вирта писалося программные комплексы на миллионы строк кода, ума не приложу.

Дык как раз перед паскалем Дейкстра и обозначил кризис программирования. С чего все и понеслось.

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

Кроме того, Дейкстра не владел классификацией. Вот, например, которую я предложил.
даже "боксовые" структуры всякие и то, массивы однородных элементов - "боксов". Хотя содержание бокса может быть любым. Нет необходимости в конструировании паскалеподобных структур. Они действенны только с рекурсией и указателями, записанными явно или неявно. Все эти примочки вроде сборщиков мусора и т.п. - следствие подобного подхода.
Ясно, что сборщик освобождаемую память , в общем случае , не сразу. Т.е. неизвестно, что эффективнее. Указывать сборщику на это - равносильно использованию Dispose, без которого , в противном случае, не обойтись. Если присмотреться к тому, сколько всякого бреда было изобретено в связи с этой "концепцией", то можно подавиться.

Любопытная маразматическая параллель. Паскаль со структурами и sql это два проявления одного и того же процесса: попытки упаковать "сущности" и "связи" в одну коробку. Маразматичность этого занятия хорошо показал коллега ЧАЛ на sql.ru. Это там вызвало приматическую бурю.

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

Рыжий - математик И мозги выносит на раз

Рыжему - ответ. Давно уже не структуры рулят...
А такая крупная сущность как контейнер... А реализация его - дело десятое...

А я помню как:
поставишь 0 в качестве параметра чье-то процедуре, а потом такая хрень лезет, мама не горюй. Оказывается, процедура поменяла этот нуль на какую-то хрень. Причем каждый раз на разную.

Да. Это была "фишка" фортрана... Когда константа-литерал вдруг оказывалась совсем не тем, что написано...

Тут два момента. Во первых , аккуратнее надо быть. Во вторых , языки развиваются и все это учитывается, фортран-90, это не фортран-4. В третьих, и самое главное: да, существуют и имеют право быть, концепции, наподобие этого Вирта. Но, данные идеи относятся к специфическим программным средам и инструментам. Субд Cache, например , реализует богатую объектную модель, приспособленную для тех задач, для которых данная модель изобреталась. Языки же программирования предназначены в первую очередь для вычислений , а не для моделирования бизнесс(или иных)-процессов, все вопросы связанные с моделированием неких структур не должны отражаться на синтаксисе и приоритетных способах использования языка. Должны они выделятся в некие библиотеки. Массив и его более развитые продолжения это естественная структура. Все остальное это надстройки.

Да нормально всё в Обероне . Есть достаточной величины и формы кирпичики, можно строить здания любой архитектуры и с комфортом там жить
И МАМПС с его массивами, и ТО и СЁ. Делать только надо кому-то , единственная трудность у нас

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

Не проектировал на Обероне, но считаю, что ... (Это я про себя)
Нет, действительно, не вижу проблемы навязывания манер.
Оберон - язык универсальный. Типа - любая задача в принципе решаема, но это же не значит, что его (универсальный язык) следует прямо ( тупо, в лоб и т.п.) использовать в разработке, только на голом Обероне и библиотеках. Я понимаю универсальность как возможность создания подходящего инструмента с нужными абстракциями и т.п. , а вот уже потом прикладную задачу и решать. И если качество Оберона позволяет делать качественный инструмент (качественными разработчиками, конечно), так это и есть счастие. Трудность только в разработке инструментов, а это проблема не от Оберона и его мнимых недостатков.
P.S.
Текст перекликается с продолжением цитированного, писали видать параллельно

Оберон - не универсальный язык. Оберон язык основанный на концепции расширяемой записи и указателей. С соответствующим способом построения алгоритмов. С++ , да, относительно универсальная помойка. Возьмите любую простую задачу:
последовательность перекрывающихся прямоугольников с заполнением на экране: z-последовательность. И попытайтесь рассмотреть задачу с точки зрения массивов, и сточки зрения "объектов" , во втором случае еще и связный список из "объектов" организуют, не сомневаюсь.