> Это будет уже создание нового языка. Как показывает практика, это происходит очень редко
> и весьма трудоёмко.

Вам не приходилось писать на lisp'е? Думаю нет, иначе бы вы не употребляли бы слово "редко". Слово "трудоёмко" тут более уместно, но мне почему-то кажется, что вы переоцениваете трудоёмкость этого процесса. Если исключить из рассмотрения создание языков внутри lisp'а, то создать язык конечно сложнее, чем написать библиотеку, но нельзя сказать чтобы это было бы как-то невероятно сложно. Сложно написать *сильный* оптимизирующий компилятор, но это не так уж и критично, как может показаться на первый взгляд. Новые языки появляются реже, чем новые библиотеки лишь из-за недостатка хороших идей, которые можно было бы заложить в основу нового языка.

Что представляет из себя R я не скажу -- не вдавался в подробности. Думаю на неделе книжку почитаю, а пока -- не знаю. Но, отмечу, что класс задач выбранный для R достаточно обширен для того, чтобы под него создать самостоятельный язык.

> А поводу математических библиотек - их можно не только с нуля писать, но и подключать
> чужие через всякие интерфейсы. Это позволяет использовать legacy библиотеки, написанные
> на R и фортране. Только зачем писать на этих языках новые библиотеки?

Чужие и через интерфейсы -- это хорошо звучит ровно до тех пор, пока не возникнет желания использовать какую-нибудь библиотеку низкоуровневого языка, типа C/C++, из языка высокоуровневого. Подобные попытки рельефно демонстрируют убогость API низкоуровневых языков, загоняют в угол и вынуждают либо писать низкоуровневый код на высокоуровневом языке (если он позволяет подобное извращение), либо писать крайне неэффективный код, который, например, постоянно преобразовывает "высокоуровневые" массивы в "низкоуровневые" и обратно. Осознание этого незамедлительно порождает сильный приступ NiH-синдрома. Или желание отказаться от высокоуровневого языка в пользу низкоуровневого, потому что низкоуровневый код проще писать на низкоуровневом языке.