Существует много определений «высокого уровня», когда речь идет о языках, но я буду использовать этот термин для обозначения языков, специально созданных для определенного домена ( 4GL кто-нибудь?) , Такие «конкретные домены», как правило, ограничены в области действия, например: создание веб-страницы, написание отчета, запросы к базе данных и т. Д. В этом ограниченном объеме часто не требуется ничего, кроме самых основных структур данных.
Есть ли необходимость?
Давайте рассмотрим случай Javascript. Область применения этого языка изначально была очень ограниченной, поскольку являлась языком сценариев, а не ограничивалась веб-браузером. В первую очередь это касалось обеспечения небольшого количества динамического поведения на статических веб-страницах. Кроме того, ограничения технологии сделали непрактичным написание больших компонентов в этой среде (особенно производительность и модель песочницы).
Поскольку Javascript ограничивался решением «небольших проблем», не было особой необходимости в большом наборе структур данных. Что касается структур данных, карта Javascript очень гибкая. Вы должны помнить, что Basic и FORTRAN прошли долгий путь, предоставляя только массивы - карты значительно более гибкие, чем это. Javascript, похоже, претерпевает трансформацию, избегая песочницы. Некоторые очень амбициозные системы создаются в Javascript как внутри, так и за пределами браузера. И технология развивается, чтобы идти в ногу с ней (посмотрите на новые движки Javascript, модели персистентности и так далее). Я ожидаю, что спрос на более интересные структуры данных увеличится, и что спрос будет удовлетворен.
Возможности библиотеки обычно появляются по мере необходимости. Многие из базовых структур данных настолько просты в реализации, что вряд ли стоит добавлять их в библиотеку, особенно если эта библиотека должна пройти какой-то процесс стандартизации. Вот почему так много языков (всех уровней) не предоставляют их «из коробки». Но я думаю, что есть другая сила, которая изменит все это ... рост мультипрограммирования.
Новая возникающая необходимость?
Не так давно код, написанный большинством разработчиков, работал в пределах одного потока. Но теперь наши системы полны потоков, веб-работников, агентов, сопрограмм, кластеров, облаков и всевозможных параллельных систем. Это меняет весь характер реализации структур данных с нуля.
В однопотоковом контексте легко реализовать связанный список практически на любом языке. Но добавьте параллелизм к миксу, и теперь требуется много усилий, чтобы сделать это правильно. Чтобы действительно иметь шанс, нужно быть специалистом. Вот почему вы видите богатые фреймворки для коллекций на всех последних языках. Необходимость совместного использования структур данных через границы потоков (или, что еще хуже) выполняется.
История ... Но не будущее
Итак, подводя итог, я думаю, что причина, по которой богатые структуры данных явно отсутствуют во многих языках, в значительной степени историческая. Потребность была недостаточно велика, чтобы оправдать усилия. Но работают новые силы в виде систем с высокой степенью параллелизма, которые вынуждают языковые библиотеки обеспечивать промышленную реализацию более богатых структур данных.