История изменений

Если стандартные функции реализованы в терминах абстракций (например, абстрактных типов данных, спрятанных за некоторым интерфейсом), ты просто реализуешь интерфейсы этих абстракций (условные cons, first и rest для абстрактного списка) в своём типе и откидываешься на спинку кресла, у тебя всё просто работает (тм).

Чтобы мы чуть конкретнее понимали задачу, можем взять, например, сериализацию в поток. Есть стандартный интерфейс сериализуемого объекта, есть стандартный интерфейс потока — что может пойти не так? Дело в том, что в любом случае на одной, второй, или обоих сторонах нужно будет адаптировать имеющиеся структуро-алгоримты к конкретной задаче сериализации, которая имеет свои причудливости в разных случаях. Нужна дополнительная передача по боковому каналу TCP/UDP? Сасаем со стандартными потоками. Нужна неблокирующая асинхронность? Снова сасаем. И так далее, Input/OutputStream в стандартной либе сделан по вполне конкретный спектр задач, и бесполезен за его пределами.

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

Я уже не стал упоминать, как нужно будет гнуть сами объекты для того, чтобы они завернулись в поток — это как бы очевидно, что LinkedList сам себя в JSON не завернет.

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

условные cons, first и rest для абстрактного списка

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

Если стандартные функции реализованы в терминах абстракций (например, абстрактных типов данных, спрятанных за некоторым интерфейсом), ты просто реализуешь интерфейсы этих абстракций (условные cons, first и rest для абстрактного списка) в своём типе и откидываешься на спинку кресла, у тебя всё просто работает (тм).

Чтобы мы чуть конкретнее понимали задачу, можем взять, например, сериализацию в поток. Есть стандартный интерфейс сериализуемого объекта, есть стандартный интерфейсо потока — что может пойти не так? Дело в том, что в любом случае на одноq, второй, или обоих сторонах нужно будет адаптировать имеющиеся структуро-алгоримты к конкретной задаче сериализации, которая имеет свои причудливости в разных случаях. Нужна дополнительная передача по боковому каналу TCP/UDP? Сасаем со стандартными потоками. Нужна неблокирующая асинхронность? Снова сасаем. И так далее, Input/OutputStream в стандартной либе сделан по вполне конкретный спектр задач, и бесполезен за его пределами.

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

Я уже не стал упоминать, как нужно будет гнуть сами объекты для того, чтобы они завернулись в поток — это как бы очевидно, что LinkedList сам себя в JSON не завернет.

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

условные cons, first и rest для абстрактного списка

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