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

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

почему же не учитывается

то, что реализовано средствами языка еще не означает, что это будет O(1)

потому что нет такого языка, который может, скажем, отсортировать массив за O(1) или даже за O(N)

т.е. это не проблема языка, это т.н. computational problem

Затем что они же не 'настройщика одного фреймворка' ищут, а в первую очередь программиста. Программист все же порой должен думать. Рома правильную оценку ситуации сделал. Вообще для программиста, мне кажется что вопрос "зачем?" некорректен. Его стоило бы заменять вопросом: "какую проблему это решает?". И на такой вопрос вы либо сами себе ответите какую, либо объяснят шире, либо в процессе объяснения придёт понимание что проблему не решить.

для подумать можно найти массу других примеров, помимо объединения массивов

Смысл? Их эта устраивает. Придумают они другую алгоритмическую задачу, что это принципиально поменяет?

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

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

или в объектном?

А как книга называется, можете написать?

not work

Почему руби называют легким языком?

Возможно исходник мало весит

Как строгость типизации связана с отловом ошибок вообще?

Мне не нравится ошибки отлавливать в многопоточных приложениях. Что к руби имеет мало отношения. Разве что используя concurrent-ruby

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

Хотя код писать при этом дольше и сложнее, на мой взгляд