Предварительный релиз Python 2.5

>А проектов всегда хватало:

Пардон, про webmin из головы вылетело. Но, во-первых, это динозавр :) Во-вторых - следом идут не крупные проекты, а продукты "уровня тулзы" - всевозможные mrtg, awstats и т.п.

Новых проектов такого уровня давно нет.

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

Да, на Perl можно писать большие проекты. Но - неудобно.

Не расчитан он на это.

# find /usr/libexec/webmin -name '*.pl'|wc -l
895

И это - один из самых крупных, наверное, проектов...

А, ведь даже
# find /usr/share/webapps/mediawiki/ -name '*.php'|wc -l
1016

# find /usr/share/webapps/phpmyadmin/ -name '*.php'|wc -l
1263

Скажешь, что PHP - для неучей и ламеров - так дай ссылки на Perl-CMS уровня Mediawiki хотя бы.

Даже написанная мною "в одно рыло"
# find /var/www/bal.aviaport.ru/htdocs/cms -name '*.php'|wc -l
625

При чём PHP изначально был выбран мною только из-за того, что в момент выбора mysql-запросы в PHP выполнялись в 9(!) раз быстрее, чем на Perl/DBI. И это не смотря на то, что в то время я как раз интенсивно программировал на Perl а PHP не знал вообще.

А вот проект из другого лагеря, написанный по большому счёту, командой дилетантов:

$ find ~/work/L2J_Fortress/ -name '*.java'|wc -l
2569

Дай ссылку на проект такого уровня на Перле. Который бы был написан с нуля за полтора года десятком программистов среднего уровня :)

> При чём PHP изначально был выбран мною только из-за того, что в момент выбора mysql-запросы в PHP выполнялись в 9(!) раз быстрее, чем на Perl/DBI. И это не смотря на то, что в то время я как раз интенсивно программировал на Perl а PHP не знал вообще. Это был какой-то баг, судя по всему. Я использую ровно одну тулзу на Си (Pro*C) для быстрой выгрузки данных из базы, на Perl'е в лоб работает медленнее.

> Да, на Perl можно писать большие проекты. Но - неудобно.

Да нормально, в общем-то. (один внутренний проект)

$ wc -l `find -name '*.pl' `

18618 total

> $ wc -l `find -name '*.pl' `

> 18618 total

> $ find ~/work/L2J_Fortress/ -name '*.java'|wc -l

> 2569

Однако, от перестановки мест операндов сумма изменилась, причём не кисло. :-)

P.S. Тебе посчитали файлы. А ты посчитал строки :-)

>Тебе посчитали файлы. А ты посчитал строки :-)

Да нет, вроде, те же файлы.

Но всё равно вопрос об открытых проектах на Perl, сопоставимых с массовыми проектами на PHP или Java остаётся открытым :)

А ты проверь :-)

Таки строки. Так что вопрос об открытых проектах на Перл не просто остаётся открытым, но и встаёт ещё более остро чем казалось :-)

Хих, так забавно: ускорили работу со строками на 30%. Вопрос: как же гавёно это было сделано ДО оптимизации??? Не, ребята в маркетинге явно слабоваты. :)

Доказывать красоту и удобство Perl человеку его незнающему, всё равно, что доказывать красоту классической музыки неимеющему слух или любящему лишь попсу. Как (а главное зачем) объяснить, что Бах - это божественно? :)

> P.S. Тебе посчитали файлы. А ты посчитал строки :-)

Я знаю. я просто не понимаю прикола считать файлы. Сравнивать строки на Perl со строками на Java, впрочем, тоже не понимаю.

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

Я бы порекомендовал Perl. Это если скриптами интересуешься. Если вообще, то лучше С и C++.

> и какую среду разработки использовать?

bash, вестимо. IDE для скриптовых языков - IMHO, больше вреда приносят.

> ИМХО на питоне можно написать всё

В принципе - да. Только будет тормозить и сожрёт всю память. А потом будете искать "фанатегов" для правки дикого кода. :)

> чего в питоне не хватает по части удобства и практичности, кроме спец. синтаксиса для регэкспов?

Вам по синтаксису или реализации? :)

> Это по скорости.

Ага, только не надо нам рассказывать сказки. Я лично перешёл на Mandriva 2006, поскольку смотреть без слёз на быстродействие anaconda, yum и up2date невозможно. urpmi на Perl почему-то не тормозит и не жрёт память.

> А так - покажи мне на Perl ... ну, например, Jabber-клиент уровня Gajim.

Извращение. Чем Gajim лучше gaim или kopete (на C и C++ соответственно)?

>Доказывать красоту и удобство Perl человеку его незнающему

А где ты тут видишь человека, не знающего Perl?

> 18618 total
...
>Я знаю. я просто не понимаю прикола считать файлы.

Хм. Ну, тогда так:
# wc -l `find -name '*.php'`
...
57511 итого

# wc -l `find -name '*.java'`
...
142636 итого

Это для CMS и L2J, соответственно.

Действительно, цифры другие выходят ;)

>Ага, только не надо нам рассказывать сказки.

Сказки рассказыват тот, кто не приводит в подержку своих слов цифры.

>Чем Gajim лучше gaim или kopete (на C и C++ соответственно)?

1. А мы тут Питон с Си уже сравниваем? Вроде, только что Питон с Перлом сравнивался.

2. Копыто - это вообще небзабельная поделка, даже рассматрвать смысла нет. Gaim - пытался к нему приспособиться неели две. В первую очерель из-за удобного для меня формата логов. Но буквально позавчера не вынес и вернулся на gajim. Причин на то - вагон. Начиная от отстутвия работы с muc, кончая кривым нативным ICQ и глючной работой с ICQ-транспортами. Gajim тоже не фонтан, но там я хотя бы могу посмотреть инфо по тому, кто у меня авториз запрашивает. В отличии от Gaim 2.0 :)

по поводу "питон сожрёт всю память" - бред, памяти он ест не намного больше перла и жабы(хоты бы если судить по тестам), а в некоторых случаях и меньше, да и не стоит забывать, что в питоне все переменные - объекты, а эт тож расход на память... и хватит сравнивать питон с С/С++, надо быть идиотом чтоб их сравнивать В)

> чего в питоне не хватает по части удобства и практичности, кроме спец. синтаксиса для регэкспов?

> Вам по синтаксису или реализации? :)

по "удобству и практичности" ((c) anonymous (*) (25.06.2006 1:02:35))

> Впрочем, не один я это понимаю, сложных проектов на Perl всегда было мало, а чем дальше, тем их остаётся меньше...

Но те, которые есть, весьма и весьма хороши. Достаточно сравнить Bugzilla и Zope. :)

> Дай ссылку на проект такого уровня на Перле.

Мерять надо по функционалу. Ну или хотя бы по количеству строк. Всем известно, что проекты на PHP и Java содержат большое количество маленьких файликов.

Кстати, есть полноценный аналог Bugzilla на PHP?

ну ты сравнил жопу с пальцем

полноценный сервер приложений и (довольно посредственный кстати) багтрекер

багзиллу надо тогда уж сравнивать с mailman

> Сказки рассказыват тот, кто не приводит в подержку своих слов цифры.

time yum search kdeaddons
real 0m22.950s
user 0m8.497s
sys 0m1.126s

time urpmq kdeaddons
0.95user 0.07system 0:01.14elapsed

Удивительное - рядом. :)

> 1. А мы тут Питон с Си уже сравниваем? Вроде, только что Питон с Перлом сравнивался.

Я хотел сказать о том, что прикладные приложения для пользователей на скриптовых языках по функционалу сдают позиции приложениям на C/C++. :)

> 2. Копыто - это вообще небзабельная поделка, даже рассматрвать смысла нет.

Потрясающая аргументация! Почему тогда народ использует и не плачется? Я уже года 2 как использую. Может, обсудим более конкретно? :)

> по поводу "питон сожрёт всю память" - бред, памяти он ест не намного больше перла и жабы(хоты бы если судить по тестам)

Если крохотные приложения - да. А если yum, то
5214 cas 25 0 78624 67m 10m R 99.6 13.5 0:07.00 yum
Это не предел, доходило и до 120 МБ. :)

> и хватит сравнивать питон с С/С++, надо быть идиотом чтоб их сравнивать В)

Сравним с CLIP? :)

> по "удобству и практичности" ((c) anonymous (*) (25.06.2006 1:02:35))

По "удобству и практичности" для разработчика или пользователя? Для пользователя я уже писал выше. :)

> полноценный сервер приложений и (довольно посредственный кстати) багтрекер

Ага, только это багтрекер работает весьма шустро в крупных проектах. А где используется Zope? Я пытался с ним поработать - глюк на глюке. Не считая слёз про быстродействие и использование памяти. :)

> Ага, только это багтрекер работает весьма шустро в крупных проектах

все те же проекты шустро используют mailman.

>> Впрочем, не один я это понимаю, сложных проектов на Perl всегда было мало, а чем дальше, тем их остаётся меньше...

> Но те, которые есть, весьма и весьма хороши. Достаточно сравнить Bugzilla и Zope. :)

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

что там у нас в багзилле соответствует, например, zodb? :)

Да забудьте вы блин про эту зопу! Прогрессивное человечество давно поклало на её и придумало Django.

> Действительно, цифры другие выходят ;)

Извини, но это бред. Одна строка на Perl не соответствует одной строке на PHP/Java практически никогда. Точнее, можно добиться, если на Perl писать как на PHP|Java, но это будет тем ещё уродством. Приведи пример на Java:

my @cards = sort {$b->get_card <=> $a->get_card} @{$self->{Cards}};

Ну и так далее. (я могу много привести подобных моментов). В Perl есть _много_ мелочей, которые позволяют писать код короче и понятнее [чем на PHP/Java]. Не могу сказать про Python, не знаю его.

>Кстати, есть полноценный аналог Bugzilla на PHP?

Полно разных :)

Правда, я предпочитаю Trac на Питоне, хотя это не совсем то.

>Извини, но это бред. Одна строка на Perl не соответствует одной строке на PHP/Java

А про строки - это не я начал. Просто в ответ на мои примеры с числом файлов ответили примером с числом строк.

Как ещё сравнивать тёплое с мягким - не знаю :)

>my @cards = sort {$b->get_card <=> $a->get_card} @{$self->{Cards}};

А за такие вещи - нужно от программирования отлучать. Ибо через год ты сам будешь в коде таком путаться.

Есть элементарная культура программирования.

>Почему тогда народ использует и не плачется?

Это у народа спрашивать нужно. Кто-то - потому что не видел ничего лучше. Кто-то из врождённой маргинальности. Кто-то - ещё по какой-нибудь причине :)

Из приличных "нескриптовых" альтернатив Gajim могу назвать тольк Psi и только за его экономичость. По функционалу он весьма уступает.

Кстати, надо ли напоминать, что самый функциональный Jabber-клиент на сегодня - это Tkabber, который, опять же - скриптовый.

>по поводу "питон сожрёт всю память" - бред, памяти он ест не намного больше перла и жабы(хоты бы если судить по тестам)

Если посмотреть на http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all&... то видно, что Питон заметно экономнее в памяти, чем Java и намного экономнее, чем Perl.

> Я хотел сказать о том, что прикладные приложения для пользователей на скриптовых языках по функционалу сдают позиции приложениям на C/C++.

Сравнить хотя бы quod libet и rhythmbox (или xmms).

А Emacs Lisp вы к скриптовым языкам относите? Если да, то жду аналога Emacs'а _полностью_ на C/C++ (В GNU Emacs на C фактически написана специализированная лисп-машина + платформенно зависимый код).

Расширения Firefox тоже не на C/C++ пишутся.

> Я бы порекомендовал Perl. Это если скриптами интересуешься. Если вообще, то лучше С и C++.

Угу для новичка самое то... Или может лучше SNOBOL или APL? Хотя нет, whitespace и unlambda - лучше всех.

Хуже C/C++ для новичка найти сложно (из mainstream'а - разве что C#) - он будет изучать ЯЗЫК, а не ПРОГРАММИРОВАНИЕ. Ну а хорошие языки как для обучания, так и для практического использования здесь уже неоднократно назывались.

>> и какую среду разработки использовать?

> bash, вестимо.

$ cat > foo.c ... ...... ^D

на
http://shootout.alioth.debian.org/
никогда не надо смотреть
ибо врет - безбожно врет
нагло и откровенно

> По "удобству и практичности" для разработчика или пользователя? Для пользователя я уже писал выше.

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

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

> Я бы порекомендовал Perl. Это если скриптами интересуешься. Если вообще, то лучше С и C++.

угу, и потом вместо дела страдать вот такой фигнёй: http://www.linux.org.ru/profile/anonynous/view-message.jsp?msgid=1466217

> А за такие вещи - нужно от программирования отлучать.

А? А за использование STL в С++ может тогда кастрировать? Приведённый код _читабельный_. Более того, в реальном проекте всё прокомментировано. И, да, у меня есть проекты, которые приходится делать/сопровождать годами, и, как показывает практика, не путаюсь. А вот если расписать на отдельную функцию сравнения, да убрать её из экранной области видимости, тогда может стать и не читабельно, да.

В общем, как можно заметить, я не противник Python, я просто не понимаю его "прелестей", в сравнении с Perl, применительно к моим задачам. И какие-то суперпроекты, которые сделаны на Python, меня не впечатляют. Есть подозрение, что Python выбран как язык, который даёт меньше возможностей "прострелить себе ногу".

>Есть подозрение, что Python выбран как язык, который даёт меньше возможностей "прострелить себе ногу".

Можно тогда поинтересоваться, почему ты предпочитаешь Перл а не, скажем, Ассемблер или даже Форт? :) Кстати, могу порекламировать мой JBForth. Работает, где-то, раз в 7 быстрее Перла, при этом несравнимо гибче и имеет доступ к методам JVM :)

>ибо врет - безбожно врет

Что конкретно врёт? Исходные тексты выложены, условия тестирования расписаны. Опровергни своими цифрами. Без этого - демагогия.

>> my @cards = sort {$b->get_card <=> $a->get_card} @{$self->{Cards}};

>> Ну и так далее. (я могу много привести подобных моментов). В Perl есть _много_ мелочей, которые позволяют писать код короче и понятнее [чем на PHP/Java]. Не могу сказать про Python, не знаю его.

если это сортировка по ключу (насколько я понял), то на питоне это будет выглядеть так:

cards_by_key = sorted(self.cards, key=lambda a: a.get_card())

а если точно известно что все элементы списка -- объекты класса Card, то короче:

cards_by_key = sorted(self.cards, key=Card.get_card)

> Приведённый код _читабельный_

ну да, при известной привычке к идиомам языка.

после питона первое впечатление от чтения кода на перле -- очень много "синтаксического шума"

но лучше уж шум, чем бесконечные повторения ДлинныхСлов на яве

Bugzilla нужно сравнивать с Trac

> а если точно известно что все элементы списка -- объекты класса Card, то короче:
> cards_by_key = sorted(self.cards, key=Card.get_card)

Поскольку я подозревал, что в Python есть что-то подобное, то кивал в сторону PHP/Java,
которые были приведены как подходящие для "больших проектов" языки, и что с ними
сравнение сложности проектов построчно просто некорректно.

В Python мне в _первую_ очередь не нравится отсутствие специального синтаксиса для regexp. И отсутствие очевидных преимуществ перед Perl.
"Куча проектов на Python" для меня не очевидное преимущество.

> Можно тогда поинтересоваться, почему ты предпочитаешь Перл а не, скажем, Ассемблер или даже Форт? :)

Исторически сложилось, что мне достаточно Perl + (C|C++) + (Oracle|MySQL). Когда мне надо "стрелять в ногу" -- я стреляю :) По поводу форта -- зачем он реально может быть мне нужен? JVM/платформонезависимость мне не нужны, мои задачи всегда конкретны, вплоть до того, что могу сказать на какой версии апача должно всё работать. Когда мне нужна независимость от платформы, то клиентское приложение будет работать или через браузер, или Flash, или ещё на чём-то. Но Java, Fort -- зачем они?...

> А Emacs Lisp вы к скриптовым языкам относите? Если да, то жду аналога Emacs'а _полностью_ на C/C++

Вы бы ещё попросили ./configure скрипты переписать на C/C++. Нам Vim и Kate хватает. :)

> Расширения Firefox тоже не на C/C++ пишутся.

Лучше пойти и сразу застрелиться. Посмотрел - вырвало. Я уж молчу про поедание памяти и тормоза Firefox. Уж что тормознее Python - так это Firefox и OpenOffice.org. :)

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

Ага, ему есть дело до тормозов и использования памяти. Пример я приводил выше. :)

> Вы бы ещё попросили ./configure скрипты переписать на C/C++.

Изначально речь шла о больших приложениях, написанных не на С/С++.

> Нам Vim и Kate хватает. :)

Это понимать как признание превосходства Emacs'а?

> Уж что тормознее Python - так это Firefox и OpenOffice.org.

OOo всегда был на С++ написан... И ведь тормоз...

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

> Ага, ему есть дело до тормозов и использования памяти. Пример я приводил выше.

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

> OOo всегда был на С++ написан... И ведь тормоз...

Боюсь, что там всё сложно на самом деле. Примерно как Emacs: он тоже на Си написан. Кого волнует, что внутри у него elisp?...