Безопасность PHP изнутри

>Ты лучше покажи где проекты перешедшие с жабы на руби или со спринга на рор.

Хотя бы книги пишут...

http://www.pragmaticprogrammer.com/titles/fr_j2r/index.html

http://www.pragmaticprogrammer.com/titles/fr_r4j/index.html

Я вот хочу перейти с руби на жабу и с рельсов на спринг, но сложно так просто это сделать. Хотелось бы статьи вроде "в рельсах вы делали так[пример] и это не тру т.к. [причины], а в жабе всё зачетно и сделано так [пример]"

>Ну подскажи язык, в котором можно сделать прозрачным обращение к несуществующим методам и свойствам (в PHP это возможно)

Ну хотя бы ruby, хотя это умеет любой нормальный ОО язык. Видимо для PHP-шников это что-то очень выдающееся :)

def method_missing(name, *args, &block)

puts "called method #{name} with args [#{args.join ', '}]" + if block_given? then "and iterator #{b}" else "" end + "."

end

aaa(123)

xxx("aaa",3) { puts "hello" }

#=>

called method aaa with args [123].

called method xxx with args [aaa, 3]and iterator .

> Ну подскажи язык, в котором можно сделать прозрачным обращение к несуществующим методам и свойствам (в PHP это возможно).

man perlsub и читай раздел "Autoloading". Даже никакого ООП не надо, прям как ты любишь.

Умиляют пыхпыхеры, которые других языков в глаза не видели, а спорить лезут.

> >Вот это нормальное ООП.

>Уши смолтолка торчат во все стороны до сих пор:)))

Всё, уболтали. Следующий язык, который я учу - smalltalk.

> Ну подскажи язык, в котором можно сделать прозрачным обращение к несуществующим методам и свойствам (в PHP это возможно). У меня, поработавшего на ниве реализации спроектированных собой/не собой систем, такие задачи возникали очень часто, а твои --- почему-то нет...

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

>>"Тестовый текст для сохранения в файле".save_as("test.txt") Сохраняет содержимое строки в файл. Вот это нормальное ООП.

>Аааа... Жалость-то какая... Значит, я всё это время писал с использованием ненормального ООП :) Догадаться, что ООП в каждой дырке суть зло, не можешь? :)

То, о чём пишет Cris, - действительно, ОЧЕНЬ удобно.

>1) 5.times {|i| puts i} # => 0 # => 1 # => 2 # => 3 # => 4

>2) 1.upto(5) {|i| puts i} # => 1 # => 2 # => 3 # => 4 # => 5

>Выше в коде у числа есть методы times и upto. Они принимают как параметры (пятерка для 1.upto(5)) так и анонимную функцию( {|i| puts i} ). Анонимная функция передается методу и он при каждой итерации ее вызывает, передавая значение итератора (в данном случае это i).

Итератор для числа - охренеть можно. Вообще то итераторы применяются для перебора элементов коллекции, то есть намного естественнее было бы написать:

for i in 1 .. 5 puts i end

Или (для буйных фанатов ООП):

(1 .. 5).each { |i| puts i }

Сама идея использования анонимных функций в Ruby для реализации итераторов - недурна, но нельзя же её доводить до абсурда. Почему то все рубироиды очень гордятся этими странными методами для чисел, при том что числа проще рассматривать именно как примитивы, а не полноценные объекты.

> Итератор для числа - охренеть можно.

Тот же самый синтаксис один в один применяется для всех итераторов. Кстати, приведённые тобой варианты - тоже. :)

5.times {|i| puts i}
(1 .. 5).each { |i| puts i }

сравни количество символов. Запись с итераторами и короче, и изящньее

> Почему то все рубироиды очень гордятся этими странными методами для чисел, при том что числа проще рассматривать именно как примитивы, а не полноценные объекты.

Во-первых, я не вполне понял, как можно гордиться тем, что сделал не ты. :) Во-вторых, рассматривай как примитивы, пожалуйста. Где проблема-то? Тебя ж никто не вызывает вызывать each и прочие upto для чисел.

Фишка, однако, в том, что оно не для чисел, а для всех объектов, подсосавших соответствующий модуль.

>5.times {|i| puts i} >(1 .. 5).each { |i| puts i }

>сравни количество символов. Запись с итераторами и короче, и изящньее

Да и там, и там итераторы! Просто в первом случае - итератор для объекта Integer (глупость несусветная), во втором - для объекта Range (который есть коллекция и итерация по нему вполне естественна).

>Фишка, однако, в том, что оно не для чисел, а для всех объектов, подсосавших соответствующий модуль.

Добавлю что ещё здесь есть фишка в улучшении читаемости кода: five times do ... и яркий пример расширяемости языка.

5.times do LOR.flame(:topics => /PHP/) end

>Фишка, однако, в том, что оно не для чисел, а для всех объектов, подсосавших соответствующий модуль.

Фишка в том, что класс Integer не подмешивает модуль Enumerable! Все эти upto - это плод больной фантазии Матца.

Слушай, дорогой, я не понимаю, в чём твоя проблема? Не нравится тебе upto в Integer - ну не юзай ты его, да? Тебя кто-то заставляет?

Насчёт того, что Enumerable не входит в Integer, деликатно промолчу. :)

Хм, действительно не входит. :) Впрочем это не меняетосновную мысль моего предыдущего поста.

Зачем называть обычные функциональные приёмы "плодом больной фантазии" - это вообще загадка. Если тебе это непривычно, то так и говори.

> Насчёт того, что Enumerable не входит в Integer, деликатно промолчу.

Ещё бы он входил... Ты ж сам написал, мол класс подсасывает модуль и вперёд. При чём тут только эти псевдоитераторы для чисел? Мне не нравится, что сомнительные фишки Ruby выдают чуть ли не за главные достоинства. Переопределение методов базовых классов - это из той же оперы.

> Зачем называть обычные функциональные приёмы "плодом больной фантазии" - это вообще загадка.

Я разве против итераторов и анонимных функций выступаю? Я против их применения не по делу.

> Мне не нравится, что сомнительные фишки Ruby выдают чуть ли не за главные достоинства.

Мы говорим о языке или о том, кто там чего за что выдаёт?

> Переопределение методов базовых классов - это из той же оперы.

Переопределение методов базовых классов - это очень удобно. Если тебе это не нужно, значит этот язык (ну или данная конкретная его фича) не для тебя, вот и всё. О чём тут спорить? Просто не пользуйся. Оно ведь не мешает никак.

> Я против их применения не по делу.

Определение "по делу" в студию.

>Зачем называть обычные функциональные приёмы "плодом больной фантазии" - это вообще загадка. Если тебе это непривычно, то так и говори.

А, а я уж забыл, что нахожусь на ЛОРе :) Императивный язык плохой by design, т.к. он не функциональный. Очень логично :)

Короче, тогда я быдлокодер, т.к. не следую заветам святого В.Луговского, а ведь если им не следовать и программировать не на функциональных языках, то настаёт постепенное разложение мозга и наступает фаза существования программиста в виде овоща...

>Если тебе это не нужно, значит этот язык (ну или данная конкретная его фича) не для тебя, вот и всё. О чём тут спорить? Просто не пользуйся. Оно ведь не мешает никак.

Ну как же, ведь Cris и ему подобные в этом топике рассказывают, что если нет такой фичи --- то жизнь не удалась, что во всех языках эта фича должна присутствовать и даже (следует из контекста) её все дролжны использовать.

> А, а я уж забыл, что нахожусь на ЛОРе :) Императивный язык плохой by design, т.к. он не функциональный. Очень логично :)

Покажи, пожалуйста, где я это сказал.

> Ну как же, ведь Cris и ему подобные в этом топике рассказывают, что если нет такой фичи --- то жизнь не удалась

Покажи пожалуйста, где он это сказал. Он всего лишь сказал, что там нет такой удобной штуки.

> и даже (следует из контекста) её все дролжны использовать.

Это даже на домысел не тянет, это уже тот самый "плод больной фантазии". :) Никто вообще ничего никому не должен. Хочешь писать длиннее - ради бога, кто против-то. Только не надо называть средства, позволяющие писать короче, всякими нехорошими словами. :)

>Я практически не использую ООП в вебе - так как почти никогда не вижу ему там применения.

А как мсье борется со сложностью проектов? (Если есть действительно сложные конечно :) ). Без иронии, просто интересно.

>К функциональному программированию равнодушен

5 страниц, а слово "лисп" так никто не произнес еще. На ЛОР не похоже...

Привет всем!!!

Перевожу довольно сложный проект написанный моим предшедственником с Python/Django на PHP. Чего посоветуете?

Забыл сказать, что перевожу для совместимости проекта (интернет-магазин) с хостерами, которые ни в какую не хотят поддерживать mod_python. Только PHP и больше ни о чём не хотят слушать. PHP знаю уже года четыре, а вот питон пришлось немного выучить, чтобы перевести проект на PHP. Заранее спасибо.

>Перевожу довольно сложный проект написанный моим предшедственником с Python/Django на PHP. Чего посоветуете?

Гм. Я бы посоветовал найти ближайшую стену... Если уж случай слишком запущен - без биореактора не обойтись...

>с хостерами, которые ни в какую не хотят поддерживать mod_python

А других хостеров не существует? Если завтра они на альтернативную платформу перейдут, вы снова переписывать будете?

Вообще-то PHP - это банальное Personal Home Page (Tools), если вспомнить историю. Одного это уже достаточно, чтобы им не пользоваться ;-)

>Перевожу довольно сложный проект написанный моим предшедственником с >Python/Django на PHP. Чего посоветуете?

Увольняйся

>Parser

Гроб, хуже чем php

Уж сколько раз твердили миру... Распространенность php вызвана легкостью установки его на сервере, малым количеством парадигм, заложенным в язык (императив + недо-ооп) -> легкость изучения а т.ж. тем, что это именно узко-нишевый язык, заточенный под веб, в отличие от java, ruby, python, perl - языков общего назначения, сравните распространенность php и perl/python на десктопе и все станет на свои места.. По большому счету это не язык, это всего лишь _препроцессор текста_, у него нет даже виртуальной машины, он не приспособлен для long-running-processes, на нем даже не напишешь stand-alone сервер, нет потоков, это паталогически _не правильный_ язык (если все же рассматривать его как язык), который подобает использовать ясно осознавая эту всю его неправильность - отсутствие модулей (пакетов, неймспейсов), отсутствие высокоуровневых типов данных, огромное количество глобальных не очень системно названных функций вида another_this_very_useful_function (ввиду отсутствия модулей), перемешивание логики работы и отображения, не способствующее MVC, отсутствие такого полезного высокоуровневого средства как исключения... Все попытки как то окультурить это дело (Smarty, всякие ORM-ы) производят впечатление мягко говоря использования средства не по назначению. php идеально подходит для не очень больших обособленных програмных комплексов типа форумов, гостевых, различных других веб-скриптов, кое-как для небольших CMS. Для других более сложных enterprise веб-приложений использование PHP возможно, но не обосновано в виду слабой масштабируемости (как там насчет кластеризации, load-balancing'а), не модульности, отсутствием высокоуровневых средств языка. В этом сигменте гораздо лучше подходят языки общего назначения, позволяющие писать приложения, выполняющиеся на специальном application server'е. А использование PHP CLI это вообще из ряда вон выходящее извращение...

>Покажи, пожалуйста, где я это сказал.

Не с точностью до цитаты, но там, где я отквотил. Уже стало само собой разумеющимся в данном топике, что для программирования обязательна функциональная парадигма. Почему --- мне не понятно.

>Покажи пожалуйста, где он это сказал. Он всего лишь сказал, что там нет такой удобной штуки.

А вот почему-то в C нет такой удобной штуки, как логика предикатов [какого-то] порядка. Я же из-за этого не закидываю топик истеричными сообщениями?

>Это даже на домысел не тянет, это уже тот самый "плод больной фантазии". :) Никто вообще ничего никому не должен. Хочешь писать длиннее - ради бога, кто против-то. Только не надо называть средства, позволяющие писать короче, всякими нехорошими словами. :)

Наверное было неправильным решением включить комментарий про "должны использовать" в ответ конкретно тебе, так как тот контекст, из которого оно вытекало, всё же был создан другими флеймующими. Тут я без претензий :)

>Уж сколько раз твердили миру...

Вау! Первая ИМХО конструктивная критика PHP в этом топике! :)

>Распространенность php вызвана легкостью установки его на сервере, малым количеством парадигм, заложенным в язык (императив + недо-ооп) -> легкость изучения а т.ж. тем, что это именно узко-нишевый язык, заточенный под веб, в отличие от java, ruby, python, perl - языков общего назначения, сравните распространенность php и perl/python на десктопе и все станет на свои места.. По большому счету это не язык, это всего лишь _препроцессор текста_, у него нет даже виртуальной машины, он не приспособлен для long-running-processes, на нем даже не напишешь stand-alone сервер,

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

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

Тут уж почему-то все возмущаются, что PHP их провоцирует на перемешивание логики и отображения. Кроме пока обязательных открывающих и закрывающих скобок, ничего провоцирующего не вижу.

>отсутствие такого полезного высокоуровневого средства как исключения...

А оно есть. Другое дело, может, какие волшебные вещи делать не умеет...

>Все попытки как то окультурить это дело (Smarty, всякие ORM-ы) производят впечатление мягко говоря использования средства не по назначению.

Вполне возможно, что тут всё дело в привычке :) Народ же как-то привыкает к десяткам фреймворков на Java :)

>php идеально подходит для не очень больших обособленных програмных комплексов типа форумов, гостевых, различных других веб-скриптов, кое-как для небольших CMS. Для других более сложных enterprise веб-приложений использование PHP возможно, но не обосновано в виду слабой масштабируемости (как там насчет кластеризации, load-balancing'а),

Точно так же, как и в других языках --- это задача 1) серверов 2) фреймворков.

>не модульности, отсутствием высокоуровневых средств языка.

Каких? Тут я не понял.

>В этом сигменте гораздо лучше подходят языки общего назначения, позволяющие писать приложения, выполняющиеся на специальном application server'е.

Тут же вспомнилась 1С, где в 8й версии приложения могут выполняться на application server'е...

>А использование PHP CLI это вообще из ряда вон выходящее извращение...

Да не совсем :) Для многих вещей можно найти отмазку :)

Вообще-то РНР5 не совсем безнадежен, кто-то даже умудрился сделать на нем аналог RoR

http://thewebsitedoctor.net/trax/doc/PHPonTrax/tutorial_rails_examples.pkg.html

Страшно подумать, как надо было извратиться, чтобы реализовать это на РНР, но они это сделали!

Ну и посмотрев код контроллера или модели сразу видно слабости РНР как языка:

* $this->

* $

* array()

* return

Код просто кишит этими словами, его становится невозможно читать. Если взглянув на исходник на Ruby сразу появляется представление что оно делает, то для понятия, что делает аналогичный код на РНР нужно вчитываться в эти страшные слова, и мысленно обрезать вышеперечисленные слова...

Убрав эти недостатки, РНР станет немного приятнее, однако страшно подумать, что они там сделали с РНР чтобы реализовать этот API, наверняка скорость будет ниже раз в 5-10.

>Вообще-то РНР5 не совсем безнадежен

Он вообще не безнадёжен, он вполне хорош :)

>Ну и посмотрев код контроллера или модели сразу видно слабости РНР как языка:

>* $this->

Согласен, громоздко. Но, с другой стороны, эта конструкция скрыта внутри определения классов.

>* $

Да наоборот, позволяет отфильтровать быстро переменные. Не доведено до такого маразма, как в Perl, но читается гораздо лучше, чем в том же C.

>* array()

Тут фиг знает, я не использую эту функцию.

>* return

А с return-то что не так? :) Или надо в стиле R сделать, типа результатом блока является результат последнего оператора в блоке? :)

Вообще, я использую PHP сейчас как процедурный язык, использующий объекты. И мне он этим очень нравится.

> In order to use the MagickWand For PHP module's functions, you need to install ImageMagick version 6.3.1, or greater, and the MagickWand for PHP extension source code / DLL.

> Ты много хостингов с ИмеджМеджиком видел?

Я угораю.

RMagick is known to run on Linux, FreeBSD, MacOSX, Sun Solaris, Cygwin, and MS Windows. RMagick works with Ruby 1.6 and Ruby 1.8. (RVG requires Ruby 1.8.) If you do not have Ruby, you can get it from www.ruby-lang.org. You __must have___ ImageMagick 6.0.0 or later, or GraphicsMagick 1.0 or later. You only need one of ImageMagick or GraphicsMagick. RMagick works equally well with either. See below for links to the ImageMagick and GraphicsMagick download sites.

> Я угораю.

Смотри, не перегрейся. На все нормальные хостинги с рельсами ставят РМеджик и соответственно ИдеджМеджик. Поэтому хостинг с его поддержкой искать не нужно, любой вменяемый хостинг его поддерживает.

В пхп таким стандартом является gdlib. Но он намного низкоуровневей и реализовывать нужную мне функцию уже придется на уровне пхп.

> Вообще, я использую PHP сейчас как процедурный язык, использующий объекты. И мне он этим очень нравится.

Вообще это тупой спор. Я не зря спросил атруса про то, сколько он пишет на пхп и нравится ли ему это(кстати, он еще не ответил на этот вопрос :)) ).

Семь лет назад, когда я только начинал программировать, мне нравился пхп и я не понимал, почему мой дружбан не переходит с перла на него. И годика три назад, читая флеймы на ЛОРе о пхп я тоже не понимал, почему все так на него гонят и что "на пхп можно написать хорошо и безопасно лишь бы руки прямые".

Позже я стал замечать, что мне не нравится программировать. Стало скучно. Появилась рутина. Попробовал Питон. Питон понравился. Но в нем были некоторые неприятные моменты.

А потом я узнал про Руби. Пишу не нем где-то год. И получаю удовольствие от программирование. В придачу к рельсам получил отличный скиптовый язык, который регулярно использую для повседневных задач.

Поэтому, если вам нравится пхп, и он вам не надоел, о чем может быть речь?

ЗЫ: интересно было бы узнать стаж отметившихся в этом топике и нравится ли им пхп :)

>Согласен, громоздко. Но, с другой стороны, эта конструкция скрыта внутри определения классов.

Зачем же доводить до обсурда? Она нужна, когда параметр перекрывает поле объекта, но в большинстве случаев она излишня

>Да наоборот, позволяет отфильтровать быстро переменные. Не доведено до такого маразма, как в Perl, но читается гораздо лучше, чем в том же C.

До маразма доведена в РНР идея взятая из перла. Читается достаточно уродливо, по сравнению с Perl или Ruby

>Тут фиг знает, я не использую эту функцию.

Ну таким и массивы не нужны, и ООП не нужно. Откройте для себя brainfuck - понравится :)

>А с return-то что не так? :) Или надо в стиле R сделать, типа результатом блока является результат последнего оператора в блоке? :)

А чем не нравится? Вполне логично смотрится, а ретурн следует использовать примерно в тех же случаях что и break

>Вообще, я использую PHP сейчас как процедурный язык, использующий объекты. И мне он этим очень нравится.

А я использую языки для решения задач, а не для того чтобы он был "процедурный и использующий объекты". По совокупности простоты обучения и возможностям лучшим, в большинстве задач, является ruby. Да и популярность набирает, так что работу с ним найти легче чем с lisp/haskell/smalltalk...

>ЗЫ: интересно было бы узнать стаж отметившихся в этом топике и нравится ли им пхп :)

Год перла, два года РНР для веба и перл для скриптов, потом узнал про ruby, и он заменил все упомянутые выше языки. Сейчас на PHP смотрю с ужасом, а по перлу иногда скучаю. Жду шестого перла.

>Поэтому, если вам нравится пхп, и он вам не надоел, о чем может быть речь?

Один знакомый начинает изучать РНР, отговаривать не получается. Основной аргумент - отсутсвие русской документации по Perl/Python

> он не приспособлен для long-running-processes, на нем даже не напишешь stand-alone сервер

А вот недавно пробегала новость про http сервер на пхп и работал такой сервер под неплохой нагрузкой долгое время.

> Основной аргумент - отсутсвие русской документации по Perl/Python

Гнилая отмазка, русская документация есть и её вполне достаточно

> Перевожу довольно сложный проект написанный моим предшедственником с Python/Django на PHP. Чего посоветуете?

Если нет хостеров с джанго, то, помнится, есть VPS за 20у.е в месяц. Ну и поставить туда джанго.

Ох уж эти рубироиды :))

Как по мне синтаксис руби слишком пересыщен, питонский код все-таки более читабелен. Пару месяцев назад это уже тут проверяли (не ваш ли это был сэмпл с тиклевской канвой?). А на самом деле - каждому инструменту своя ниша. Да, эти ниши частично пересекаются, но это не значит что все что есть в вэбе надо ваять только на php/ruby/java etc.

Если провозглашается лозунг "<xxx> - наше все!", значит заранее усложняется какая-то часть работы или изобретается велосипед. Хуже может быть только случай, когда тим выбрав объект разработки настолько усложняет спеку имплементации, что не может ее просто физически потянуть.

> Как по мне синтаксис руби слишком пересыщен, питонский код все-таки более читабелен. Пару месяцев назад это уже тут проверяли (не ваш ли это был сэмпл с тиклевской канвой?).

Уважаемый Linfan немного перекручивает факты :). Тот пример я приводил как демонстрацию возможности, а не как обычная практика в языке (хотя в разметке Маркаби она используется явно и многим нравится http://redhanded.hobix.com/inspect/markabyForRails.html ).

Поэтому "питонский код все-таки более читабелен" тут не проходит, так как в питоне не с чем сравнить данную конструкцию.

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

2boombick:

мля, "ты их в дверь - они в окно". валите уже на свои пых-пых форумы - там вам будет гораздо комфортнее. вам уже не раз и не два намекали, что пых-пых здесь не котируется по многочисленным причинам.

> Да уж, наслышаны про этого Стефана...

еще бы! он - единственный человек в команде девелоперов пых-пых, который пытался исправить положение. теперь у пых-пых нет никаких шансов стать лучше.

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

> сравни количество символов. Запись с итераторами и короче, и изящньее

угодайкин пытается победить перловые однострочники? флаг ему в руки!

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

Угу, значить "это был ваш мальчик" ;)

Что же до сравнений, шановный Cris, то в крупных проектах шо Питон, шо Руби - почти одного поля ягоды, "урылы страшные, спаси господи" (с)Гоблин. У обоих наработок не так уж и много. Разве что Питон постарше, для него чуть больше напедалили.

Жаба в этом поприще - вне конкуреции. К сожалению. А преимущества типа языковых конструкций и компактности кода бруттально сводятся на "нет" мощными IDE типа IDEA и мегатоннами готового кода.

гр.anonymous, я понимаю ваш праведный гнев, но в таком случае подскажите напр. пяток(чтобы был выбор) готовых багтрекеров с открытым кодом на Руби, Питоне или жабе. В последнем случае крайне важно, чтобы аппликуха не зохавывала по гигу памяти, а скромно жила себе в пределах 100-150Mb вместе с БД и вебсервером... Говорите, шо будут? Ну вот когда будут, вот тогда и приходите с критикой, а пока звыняйте, фБабруйск!

Небольшое дополнение по популярности. Поиск проектов написанных на соотв. "езыгах" по SourceForge:

Java: Searching projects gives 13607 results

Python: Searching projects gives 3301 results

Ruby: Searching projects gives 491 results

> гр.anonymous, я понимаю ваш праведный гнев, но в таком случае подскажите напр. пяток(чтобы был выбор) готовых багтрекеров с открытым кодом на Руби, Питоне или жабе.

я, скорее всего, не тот anonymous, которому адресован вызов, но...

пяток, пожалуй, не смогу назвать, но есть, к примеру, trac. хотя, к чему это вы? откуда это магическое число 5? "шура, какое количество денег вам больше всего импонирует?" (за точность цитаты не ручаюсь).

закон переростания количества в качество не работает в случае с пых-пых. необъяснимый феномен, скажете вы? дудки! все вполне закономерно. велосипед никогда не сможет полететь. как минимум, он должен перестать быть велосипедом. бесчисленное количество велосипедов никак не влияет на их способность летать.

> чтобы аппликуха не зохавывала по гигу памяти, а скромно жила себе в пределах 100-150Mb

реальные преблемы с нехваткой памяти в последний раз у меня возникали во времена z80.

на java, которая, по вашим представлвниям, пожирает память, работают устройства, которые обладают объемом памяти, сравнимым с тем, что имели компьютеры тех времен.

>Ruby: Searching projects gives 491 results

у Ruby свой SourceForge -> RubyForge