Ответ на »сообщение 5834« (Axcel)
___________________________

Ответ на »сообщение 5833« (AVC)
___________________________

По поводу массивов. Конечно, Вы правы. С другой стороны, а много ли типовых алгоритмов именно над массивами? Ну, сортировка. А что еще?

Ну, если выражаться "функционально" то, помоему, весь набор: map, reduse, filter. Во всяком случае везде, где определяющим моментом алгоритма является проход по массиву. Собственно, проход по массиву и есть инвариант.

А велика ли потребность в map/reduce?
Разве обычные for или while не решают задачу прохода по массиву?

Ответ на »сообщение 5833« (AVC)
___________________________
С другой стороны, а много ли типовых алгоритмов именно над массивами? Ну, сортировка. А что еще?
Поиск и поэлементная обработка.
Только попрошу присутствующих вспомнить, что один из толстых томов Кнута так и называется: "Сортировка и поиск".
С поэлементной обработкой кажется совсем просто, какие варианты? Но и тут возникает множество алгоритмов, если обрабатывается не по одному элементу.

Ответ на »сообщение 5833« (AVC)
___________________________

По поводу массивов. Конечно, Вы правы. С другой стороны, а много ли типовых алгоритмов именно над массивами? Ну, сортировка. А что еще?

Ну, если выражаться "функционально" то, помоему, весь набор: map, reduse, filter. Во всяком случае везде, где определяющим моментом алгоритма является проход по массиву. Собственно, проход по массиву и есть инвариант.

Ответ на »сообщение 5829« (Axcel)
___________________________

Ответ на »сообщение 5824« (AVC)
___________________________
>>>Вроде бы, согласен.
>>>Но иногда думаю так: а чем, в принципе, обычное ООП не устраивает? Базовый класс (тип записи) определяет класс типов, для которых тот или иной "алгоритм является инвариантным".

Да, конечно, но остаются "не обслуженными" массивы базовых типов (array of integer, array of shortinteger, array of real и т.д.). А ведь это массовые типы, следовательно выигрыш от использования алгоритмов - инвариантов для них наиболее ощутим.

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

По поводу массивов. Конечно, Вы правы. С другой стороны, а много ли типовых алгоритмов именно над массивами? Ну, сортировка. А что еще?

Ответ на »сообщение 5825« (Антон Григорьев)
___________________________
массив элементов любого типа, для которых определены операции
Так "любого типа" или "для которых определены"?
callback-функции и являются тем самым определением операции сравнения без которой сортировка невозможна.
Или речь идет обо всех стандартных типах?

Ответ на »сообщение 5828« (Сергей Перовский)
___________________________

Ответ на »сообщение 5818« (AVC)
___________________________
Наши рюкзаки рюкзакатее -- в большем числе ситуаций
Добро пожаловать на Эверест с рюкзаком, наиболее подходящим в "большинстве ситуаций" :)

А Вы полагаете, что, спустившись с Эвереста и направляясь к Енисею, у Вас будет время заехать домой, отдохнуть, подучиться, сменить рюкзак? :)

Ответ на »сообщение 5821« (Илья Ермаков)
___________________________
К примеру, надёжность, высокоуровневость, компактность, эффективность.
Из всех этих показателей реально померить удается только компактность.
Все остальное оценивается так же субъективно.
Мы остались на уровне нравится/ненравится.

Ответ на »сообщение 5824« (AVC)
___________________________
Вроде бы, согласен.
Но иногда думаю так: а чем, в принципе, обычное ООП не устраивает? Базовый класс (тип записи) определяет класс типов, для которых тот или иной "алгоритм является инвариантным".

Да, конечно, но остаются "не обслуженными" массивы базовых типов (array of integer, array of shortinteger, array of real и т.д.). А ведь это массовые типы, следовательно выигрыш от использования алгоритмов - инвариантов для них наиболее ощутим.

Ответ на »сообщение 5818« (AVC)
___________________________
Наши рюкзаки рюкзакатее -- в большем числе ситуаций
Добро пожаловать на Эверест с рюкзаком, наиболее подходящим в "большинстве ситуаций" :)

Ответ на »сообщение 5825« (Антон Григорьев)
___________________________

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

Насколько я понимаю, речь идет об операциях над базовыми типами, не записями?
Базовых типов немного (BOOLEAN, CHAR, INTEGER, REAL), вполне можно в модуль "Список" добавить и "Список целых" и т.п.

Что касается callback функций, то, если не считать встроенных типов, Вы их все равно пишете.

bool operator <(...)

Получается что-то вроде смеси статической и "утиной" типизации. :)