Я рад этому. Вообще, если переписывать его с умом (в духе STL), то это будет очень круто.

А STL - это круто?

Да, STL это круто. Между прочим, ее создали Alex Stepanov (русский!?) и Meng Lee.

Alex Stepanov - русский, работает в HP, если я не ошибаюсь.

"А STL - это круто?": Вы не поняли иронии...
1). STL - это круто! = вершина ООП.
2). STL - библиотека шаблонов = ФУНКЦИЙ.
3). Вершина ООП - функциональное программирование.
 Не об'екты, не классы, не контейнеры, а функции. Это действительно
 круто! Просто пи@#$%! Да здравствуют обобщенные алгорифмы!
 ДоООПопились! 

> 2). STL - библиотека шаблонов = ФУНКЦИЙ > 3). Вершина ООП - функциональное программирование. > Не об'екты, не классы, не контейнеры, а функции. Это действительно > круто! Просто пи@#$%! Да здравствуют обобщенные алгорифмы! рекомендую все же почитать третьего Страуструпа, прежде чем писать такую чушь. --- *мечтательно* Вот если бы они не только Perl на STL переписали, но и убедили кого следует в STL регулярные выражения ввести...

Дааа, Страус такие крутые книги по ООП пишет, ну прямо как Буч по ассемблеру. Только по нему и изучать.

шаблоны

Бывают еще шаблоны классов. rtfm.

Это критика? Я имел в виду, что если писать в стиле STL, с шаблонами (которые потом прнигодяться не только для Perl'а), и не боясь абстрагироваться используя inline-функции (как например P.J.Plauger - автор PlumHall STL -посталяемой с VC++) то из полученный код будет очень гибким по отношению к изменениям, а также сможет использоваться в других проектах и софтах). А то каждый пишет так целенаправленно, что его код нигде не применишь, трудно редактировать/улучшать/понимать. А насчет библиотке регулярных выражений в STL - они есть во многих коммерческих библиотеках - напр. от Rogue Wave (в самой ихней STL rx нет, а вот в ихних доп. библиотеках). Но в принципе можно напрячься и сделать свою, GPLed реализацию (прикол в том, что шаблоны и LGPL - вещь не совместимая - надо RMS намекнуть).

Дымина!.. Севастопольское сражение!... Кто-нибудь чего-нибудь понял? Собрались мозги, изуродованные Страуструпом. С+плюс = ООП. Подклассы, подтипы, подоб'екты, методы-фабрики. Пришел Штирлиц - я же говорил, сейчас будет драка.

Ничего не понимаю что здесь написано. То что если начинать изучать ООП со Страуструпа и С++, то мозги испортишь навсегда - это не новость. То что STL во многих отношениях НЕ ЯВЛЯЕТСЯ об'ектно-ориентированной - тоже совершенно очевидно: ее обобщенные алгорифмы не зависят от контейнеров и работают с различными типами. Если метод "пошел по рукам" среди многих классов - хороша же инкапсуляция! И вообще, если STL - чистая ОО-паинька, то от чего вокруг нее такой теоретический ажиотаж? От MFC круги по воде почему-то не пошли. То что STL у нас ТАК ПОНИМАЮТ, говорит о качестве тех книжек (и статей в журналах), которые у нас печатают. Но нашим программистам, которые даже на ОО языках пишут так, "что его код нигде не применишь" (цитата из любителя STL), ни книжки, ни STL не нужны. Лучше поучиться писать на "pure C": man qsort, bsearch, hsearch, tsearch, ftw, db_dbm, и много, много других полезных вещей, которые (о чудо!) можно использовать "в других проектах и софтах".

Насчет не полной об[ектной ориентированности STL - все правильно эти Степанов и Ли сделали (IMO). (Они не старались использовать "модный"/стандартный ОО подход, а подошли с практичной точки зрения). Насчет "выдираемости" кода (не подумайте что руки кривые - хорошие программисты то выдерут, а вот плохие не смогут, из-за чего наплодят либо хреновый код, либо вообще бросят попытку чего-то сделать) - конечно из любого софта можно чего-то выдрать (с переменным количеством требуемого геморроя) - но все таки лучше писать так, чтобы гемморой не требовался совсем. Насколько я помню, в Perl6 будут добавлять поддержку Unicode - хотя бы вот это бы неплохо оформить в виде портабельной библиотеки (и сделать из нее надстройку к SGI STL). То же с rx. А насчет qsort, bsearch - они медленнее в несколько раз чем код, использующий STL - если с той же функцией сравнения - в случае с STL функция сравнения может быть inlined. Так что не надо рекомендовать дедушкины способы.

Самое смешное, что кекс, написавший про "Вершина ООП - функциональное программирование" - прав. Только он не понял сам, что сказал. А вообще - худо дело. Perl и раньше стремился к монстрообразности, а теперь точно в мамонта превратится. R.I.P. Все. Дружно переходим на Схему или ML, ибо функциональное программирование рулит до форевы!

Да понял я что сказал, понял - не надо ля-ля.

Ни фига ты не понял

Фраза "функциональное программирование - вершина ООП" никак не может следовать из того, что STL - библиотека функций. Потому как библиотеки функций не имеют ни малейшего отношения к функциональному программированию.

P.S. Блин, что мешает в Perl вставить функциональные возможности?!? Грамотный язычок получился бы...

Базар шематичный и непрактичный...