OberonCore

Раньше программисты сортировали так:


Сейчас сортируют вот так:



В большинстве мейнстримовых языков есть стандартные средства для организации контейнеров: вектора-массивы, списки, отображения (хеш-таблицы либо деревья), а также некоторые алгоритмы, применимые для работы с ними: сортировка, удаление дубликатов, двоичный поиск и т.д. Где-то эти механизмы встроены в язык (Python), где-то поставляются с библиотекой. Обобщённые контейнеры могут быть реализованными либо как контейнеры объектов корневого типа Object (ранняя Java), либо как generic’и (C++, поздняя Java, C#). В отличии от Ады (и от поздних извращений стандартной Модулы), в Обероне/КП дженериков нет, значит, по идее, должна быть какая-нибудь библиотека контейнеров, основанная на корневом типе (ANYREC).

Я некоторое время изучал встроенную документацию BlackBox, таковую не нашёл. Не нашёл даже библиотечной функции сортировки (хотя таковая есть даже в C89). Я плохо искал или таковая библиотека, по замыслу создателей, действительно не нужна?

Надо у разработчиков спрашивать

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

У каждого варианта есть свои преимущества, но я, например, сторонник второго пути, поэтому появилась библиотека Lists.

Надо доказывать, и доказательство должно быть очень весомым, почему в язык и компилятор встраивается то, что может быть вынесено в библиотеки.

Любой программист должен знать "Алгоритмы и структуры данных" (например, http://oberoncore.ru/library/algorithms ... structures). Чтобы:
а) уметь адекватно применять готовые средства.
б) уметь сочетать стандартные приёмы, реализуя ориентированные на задачу решения (которые могут в разы повышать эффективность в сравнении комбинированием отдельно взятых стандартных решений).

Готовые компоненты по означенной тематике есть. См. http://oberoncore.ru/bbcc/ и http://oberoncore.ru/projects/cpc

Я говорил про скриптовые языки вроде Python’а, JavaScript. Встраивание тех средств, которые могут быть вынесены в библиотеки, я нахожу допустимым только для скриптовых языков или языков предметной области. Для компилируемых языков общего назначения подобные средства должны быть по максимуму вынесены в отдельные библиотеки. Когда-то, когда я ещё только делал первые шаги в программировании, мне именно этим и понравился язык Си (Си++) — ввод-вывод был независим от языка, в отличие от Паскаля или Бейсика, где для ввода-вывода используются особые синтаксические конструкции: Write(x:10:5), PRINT A$ и т.д.

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


Спасибо за ссылки.

В общем, стандартной библиотеки с такими средствами в Компонентном Паскале нет, есть несколько библиотек от сторонних разработчиков. Можно использовать либо их (тогда нужно тащить соответствующую стороннюю подсистему), либо самому изобретать велосипед.

Да ладно.

У меня много динамических данных в самых разных задачах, но списки почему-то создаются добавлением в голову, а используются -- снятием с головы

Тут любая библиотека сложнее будет.

А если что-то более сложное, то там столько вариантом, что легче учесть конкретную специфику напрямую, чем бороться с библиотекой на все случаи жизни.

Это много раз обсуждалось.

Дело в том, что и стандарта нет. Поэтому и стандартной библиотеки не наблюдается...

Есть In, Out и т.п. См. Oakwood Guidelines. Это и есть стандарт.

Oakwood Guidelines это не стандарт.

Реальный стандарт -- библиотеки ББ.

Кстати, Клеменс Шиперский предлагал (в книге "Component Software: Beyond Object-Oriented Programming") добавить дженерики (параметрическим полиморфизмом кажется называлось) в КП, но идея почему-то не получила развития.

"Почему-то"?

Потому что избыточная сложность.

А в каждый значимый модуль совать новый самодельный итератор/стек не сложно?

"Избыточная сложность" говорите?
А сколько кода придётся налабать на КП/Обероне, что-бы описать подобную структуру данных?И ведь есть языки в которых это можно, и работает весьма эффективно, тот-же ObjectPascal/Delphi...
ЗЫ. И что-бы структура заработала как надо, нужно переопределить всего две простейших функции в TElementsDictionary.
Подсчитаем количество кода?

Душевные мучения по поводу отсутствия списков и хеш-таблиц закончились после чтения "Алгоритмов и структур данных" и написания маленького примера для сравнения производительности дефолтной хеш-функции в python и, выбранной мной для конкретной задачи на КП. Универсальной хеш-функции не может быть, и манипуляции со списками также иногда лучше делать нетривиально. ИМХО, использование "дорогих" по производительности алгоритмов должно обходится "дороже" по времени для программиста, чтобы не забивать микроскопом гвозди, разрабатывать сбалансированные приложения.

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

Лучше последовать примеру И.Д. и научиться программировать по хорошей книжке.
Окупится мультикратно.

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

Ну, написали там тридцать строк, а тут сто, всё равно написание строк не занимает столько мозговых ресурсов, параметр строки/время важен в основном заказчику. Ну, динамичный мир, быстрые бизнесы и прочее.

Ведь подумайте, не важно, на самом деле, когда русские запустили бы человека в космос, в 1961-м или 2001-м, для истории это смешные сроки, это было важно сделать быстро только в условиях конкуренции внутри популяции Хомо.

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

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

Конечно можно, и нужно. Никто не отрицает.
Только вот, отрицание параметрического задания класса сродни отрицанию третьего измерения
Можно так и пыхтеть в двух измерениях, а можно признать существование третьего и получить дополнительную степень свободы.
Ведь параметрический полиморфизм по-сути просто устраняет рутинные операции.
Допустим, нам нужны три списка: список целых, список строк и список вещественных элементов.
В традиционном подходе, описываем+кодируем три разных структуры, реализующих списки - TIntegerList, TStringList и TFloatList.
А параметрический полиморфизм избавляет от этой рутины.
Написали: TIntegerList = TList<Integer>, TStringList = TList<String> и TFloatList = TList<Float>. И... компилятор генерирует готовые классы со всем необходимым функционалом. И строгим статическим контролем типов!

А возможна ли реализация подобного механизма на каком-то приближённом к идеалу уровне, но в виде компонента? Ведь можно допустить, что раз не включено в язык, пусть будет включено в компонент, как составляющая.