а одни заядлые питонщики во всю PyDOR рекламировали. говорили что им оно очень нравица

а ты сам случайно не из их компании ?

> Как правило, на перле хватает наскольких минут что бы написать программу, которую на жабе или си можно писать неделю а то и больше- как в этой ситуации с питоном ?

Конкретнее, что за программа, которая за несколько минут пишется на перле, и недели на Java :) Я регулярно слышу о такой мифической программе, но ни разу не видел ее :)

>насколько он продуктивнее и большие проекты как выглядят

Python is so expressive that it can take far less time for one to write an alternative implementation of a J2EE technology in Python, than it takes to understand that technology in the first place. Это из PEAK Tutorial - т.е. от людей _действительно_ пишущих этот аналог.

>как регекспы и работы с текстом ... и прочими делами

Приемлемо. regexp-ы более многословны чем process($1) if /match/;, но не критично. Остальное во вполне приемлемом состоянии(в 2.2.2, сейчас, возможно, лучше). Пока приходилось сталкиваться с http[s], email, DNS, ldap, xml, Oracle библиотеками - удобно все, кроме "сложного" http - с проксями, паролями (лень было разбираться, обошел), ну и https через proxy CONNECT не работал из коробки.

Производительность - не ураган, но хватает. Особенно если сравнивать с перлом.

>мне нужны более сильные аргументы его преимуществ

А что вы цените? Какие параметры являются существенными?

не удивительно, но и не критично. Главное чтобы развивалось.

https - нет. http с аутентификацией - нет. ftp - крив.

>https - нет

Интересно, как я сдаю 2 проекта сейчас:-)? https не умеет проверять сертификат сервера - да, есть такая буква.

>http с аутентификацией - нет

А это что? class HTTPPasswordMgr() class HTTPPasswordMgrWithDefaultRealm() class HTTPBasicAuthHandler([password_mgr]) class ProxyBasicAuthHandler([password_mgr]) class HTTPDigestAuthHandler([password_mgr]) class ProxyDigestAuthHandler([password_mgr])

Как пользоваться непонятно - но есть.

Про ftp не знаю, не сталкивался.

обработка (лингвистически сформулированных) экспертных знаний

А SMTP авторизация, я чо то не нашёл?

SMTP AUTH: Видать плохо RTFM-ил:-)

11.12.1 SMTP Objects
...
login(user, password)
    Log in on an SMTP server that requires authentication
...

На python стандартная библиотека гораздо лучше чем в perl. Есть и сетевые протоколы, и обработка xml и многое другое. В perl за всем этим пожалуйте на cpan, что далеко не всегда приемлимо.

И вообще, как человек давно пишущий не perl, в том числе и не самые простые вещи, скажу, что после плотного знакомства с python perl кажется кривым и немощным. По крайней мере мне. Правда, при первоначальном знакомстве python вызывает крайне противоречивые эмоции. Один приятель сейчас патался не него перебраться, так все те же аргументы, - встроенных регулярных выражений нет, нельзя записать что нибудь вроде wile a=stdin.readline(): ... и так далее. Тяжело после perl'а на python переходить. Зато потом...

ОК!
Видать после n-го количества пива доку не читают. :-)

Так ведь можно. for a in stdin: ... А в сложных случаях итераторы с генераторами помогут.

акстись. я тут уже 4-ую пагу каким то идиотам мягко пытаюсь объяснить что перл рулит

> нельзя записать что нибудь вроде wile a=stdin.readline():

for line in stdin :

> Я так тоже думал, когда знал одного Питона и писал, мягко скажем программки. Подрастешь - поймешь.

Вот когда подрастёшь ещё на один шаг, если подрастёшь - поймёшь, что я прав.

Дык, невопрос можно и for... Я говорил про перловую/сишную идиому, где while(a=b()) {...}. Честно, когда я пересаживался за python мне ее больше всего не хватало.

> акстись. я тут уже 4-ую пагу каким то идиотам мягко пытаюсь объяснить что перл рулит

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

>где while(a=b()) {...}

Я понял. Мне тоже не хватало. А потом появилось:

for a in iter(b,None): ...

Идеологически другое - но результат тот же. Или с yield-ом можно поработать.

А вот if-у не повезло...

>В каком-то смысле плюсы по отсутствию в них логики местами даже хуже перла - а это надо постараться...

малацца! это он про перегрузку операторов. ха! достойный последователь пророка гослинга.

>Нет. Поэтому его и вытеснила со всех фронтов кроме системного жаба лет так пять тому назад.

это он наверное прото, что весь ендюзер софт сляпан на жабе - типа вордов, экселов, кадов там всяких и т.д., а на плюсах ляпают только иде для тех-же плюсов да глюкодромы типа С++2ЕЕ и ядро ляпикса. и браузер, припомощи которого он эту *УЙНЮ постит тоже на жабе сделан... хе-хе-хе. фанаты мля религиозные.

>C++ - это как раз наглядный пример того, как НЕ надо дизайнить языки.

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

а ведь он большой уже. о С++ слышал наверное понаслышке. не знает, а треплет языком как баба.

> а ведь он большой уже. о С++ слышал наверное понаслышке. не знает, а треплет языком как баба.

Ну он же не виноват, что в ихнем тупом универе ихнии тупые профессора запудрили ему мозги языками, отличными от С++. Учился бы он в родном ПТУ - знал бы про С++ (а еще лучше про дельфи - реальные пацаны используют тока её).

Никто не в курсе, когда Альпекс на питон программить перейдёт? Я бы у него лично спросил, да что-то его давно не видно. Пойду в соседний тред про перл, там посмотрю.

вот как я к питону пришёл
http://www.livejournal.com/users/vadim_kataev

Спасибо, прочёл с большим интересом. Надеюсь не сочтут за личную переписку ;)

Насчет последних строк -- так павианы уже на VB как швейные машинки строчат.

я просто впечатлён возможностями питона !!!
http://www.fortunecity.com/skyscraper/motorola/668/rus/python/essays/graphs.html
за 5 минут можно написать поиск в графе и показать это визуально !
это просто круто !!!

> малацца! это он про перегрузку операторов. ха! достойный последователь пророка гослинга.

Сдохни, мразь. (tm)

Я где-то хоть слово сказал об операторах? Наоборот, я всегда пинал и буду продолжать пинать жабку за отсутствие их перегрузки - мы об этом с svu регулярно воюем =) Нет, речь не о том. А о $#%@# синтаксисе (кто помнит, как различается перегрузка префиксных и постфиксных унарных операторов? вот-вот...). Об ублюдочном убогом препроцессоре. О нестандартизированной мешанине типов. О кривом синтаксисе шаблонов. Об отсутствии нормальной поддержки строк, и не надо мне тыкать в std::string и std::wstring - где юникод? (wstring - не юникод, это всего лишь widechar, в какой он кодировке - не гарантируется) где элементарные вещи типа to_upper() для строк? Где полноценная библиотека потоков (то, что там есть - убого до невозможности)?

C++ - это очень мощный язык, но при этом неимоверно кривой. Причина тому - безудержный feature creep, и желание при этом насколько возможно сохранить совместимость с C. Результат характерный.

> это он наверное прото, что весь ендюзер софт сляпан на жабе - типа вордов, экселов, кадов там всяких и т.д., а на плюсах ляпают только иде для тех-же плюсов да глюкодромы типа С++2ЕЕ и ядро ляпикса. и браузер, припомощи которого он эту *УЙНЮ постит тоже на жабе сделан...

Ты знаешь, "ендюзер софт" с подачи M$ сейчас активно ляпается на C# и VB.NET. А middleware по жизни был на жабке. Нет, конечно, можно извратиться и писать это дело на C++/CORBA, но проще сразу застрелиться.

Да, к сведению: когда я _начал_ впервые ковыряться с явой, я знал C++ два года как. Причем не на уровне cout << "Hello, world!", а на уровне навороченных шаблонов с partial specialization. Еще вопросы есть?

>я просто впечатлён возможностями питона !!!

Дык, хех, для этого сначала 5 лет учить этот питон нада!

> за 5 минут можно написать поиск в графе и показать это визуально ! это просто круто !!!

так это ж ГВР а не хрен собачий

Re6: Вышел python 2.4 final

Много сложных и больших программ на Java тут http://apache.org

BTW тут pure Java web server и сопутствующие инструменты (сам использовал пару лет назад - впечатления только хорошие) http://jakarta.apache.org/

BTW2 если JBoss не нравится то можно на это посмотреть http://geronimo.apache.org/

> где элементарные вещи типа to_upper() для строк?

ГЫЫы, а как же? Ты же сам должен эту процедуру написать, в этом же и есть смысл програмирования, а вдруг тебе первому в голову придет новый гениальный алгаритм перевода строчных букв в верний регистр? Осчастливиш человечество!

>Сдохни, мразь. (tm)

аргументация умственно-неполноценного. интересно, а он лечится не пробовал?

>Ты знаешь, "ендюзер софт" с подачи M$ сейчас активно ляпается на C# и VB.NET

где это он увидел? наверное восне...

>А middleware по жизни был на жабке.

хе-хе... да ему похоже лет 5 от роду или и того меньше.

>можно извратиться и писать это дело на C++/CORBA, но проще сразу застрелиться.

похоже отстрел таких УО как этот экземпляр - это наилучший выход для всех.

>Да, к сведению: когда я _начал_ впервые ковыряться с явой,

похоже этот УО не знает что ковыряются только в ГОВНЕ или в носу.

>я знал C++ два года как. Причем не на уровне cout << "Hello, world!", а на уровне навороченных шаблонов с partial specialization. Еще вопросы есть?

интересно, похоже до того как оно узнало С++, оно было Наполеоном!

>Ну он же не виноват, что в ихнем тупом универе ихнии тупые профессора запудрили ему мозги языками, отличными от С++. Учился бы он в родном ПТУ - знал бы про С++ (а еще лучше про дельфи - реальные пацаны используют тока её).

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

>А о $#%@# синтаксисе (кто помнит, как различается перегрузка префиксных и постфиксных унарных операторов? вот-вот...).

ТОЧНО так как перегружаются и все другие функции. ( количество аргументов и их типы ) или есть предложение сделать ОСОБЕННЫЙ синтаксис для перегрузки постфикса? По моему это дурь.

>Об ублюдочном убогом препроцессоре.

Что в нем ублюдочного? только не нужно говорить, что некоторые могут заменить } на end и сляпать нечитаемую муйню. Или русский язык плох, что на нем одну и туже мысль можно выразить множеством способов и находятся ублюдки, которые могут сморозить матом?

>О нестандартизированной мешанине типов.

С++ стандарт читал?

>О кривом синтаксисе шаблонов.

Я бы с удовольствием посмотрел на прямой и такой же мощный! Недостатки типа невозможности частичной специализации функций - это недостатки а не кривизна. (по моему скромному мнению)

>Об отсутствии нормальной поддержки строк, и не надо мне тыкать в std::string и std::wstring - где юникод?

std::wstring.

>wstring - не юникод, это всего лишь widechar, в какой он кодировке - не гарантируется

э ... как все запущено. а я и незнал, что у юникода бывает кодировка. вам любезный надо на http://www.unicode.org/standard/WhatIsUnicode.html - просветится.

>Где полноценная библиотека потоков (то, что там есть - убого до невозможности)?

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

>C++ - это очень мощный язык, но при этом неимоверно кривой. Причина тому - безудержный feature creep, и желание при этом насколько возможно сохранить совместимость с C. Результат характерный.

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

С++ дествительно уступает жабе в том, что у него нет большой СТАНДАРТНОЙ библиотеки. Ключевые слова СТАНДАРТНОЙ и БИБЛИОТЕКИ. Хотя есть огромная куча "нестандартных". И это объясняется тем, что никто не продвигал (из коммерческих контор) C++ до последнего времени. В последнее время Microsoft с Саттером активно продвигает и разрабатывает новый стандарт С++. С выходом второй версии .net он там будет. И это есть очень хорошо.

> ТОЧНО так как перегружаются и все другие функции. ( количество аргументов и их типы ) или есть предложение сделать ОСОБЕННЫЙ синтаксис для перегрузки постфикса? По моему это дурь.

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

> Что в нем ублюдочного?

Убогость возможностей. См. defmacro, далее везде.

> С++ стандарт читал?

Читал. И ты знаешь, char<=short<=int<=long - это на стандарт не тянет. То-то в каждой второй либе в хедерах видишь #ifdef BLAH/typedef int int32/#else/typedef long int32/... ну и про отсутствие _стандартного_ 64-битного целочисленного типа не забудем...

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

Речь шла прежде всего о синтаксисе, в частности, о гениальной по своей ублюдочности идее использовать для шаблонов и так перегруженные угловые скобки, что приводит к необходимости втыкать между ними кучу лишних пробелов при закрытии. Хотя и в плане фич там все не так гладко - как насчет ограничения по типу для аргументов-классов? Или необходимость регулярно использовать 'typename'?

> std::wstring.

Это не юникод. Это всего лишь std::basic_string<wchar_t>. Нигде в стандарте не сказано, что wchar_t - это юникод. Говорится лишь, что оно должно быть >=short. В частности, это может быть любая multibyte-кодировка, согласно локали.

> где там? в стандарте C++ нет нислова о потоковой модели и потоках

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

> С++ дествительно уступает жабе в том, что у него нет большой СТАНДАРТНОЙ библиотеки. Ключевые слова СТАНДАРТНОЙ и БИБЛИОТЕКИ.

Жаба - это отдельный разговор. Я совершенно согласен насчет библиотеки, но речь велась именно о языках. Так вот как язык, жаба - убога в силу собственной примитивности. А C++ - убог в силу собственного кривого дизайна.

мдя. а вот тех кто защишает питон - бог\эволюция задизайнили ну криво до крику просто

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

не знаешь - не пизди
http://www.joelonsoftware.com/articles/Unicode.html

> И это есть очень хорошо.

хорошо будет когда станет меньше таких мудаков как ты

>хорошо будет когда станет меньше таких мудаков как ты

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

И по теме речь шла о UCS-2 - именно так представлены строки в жабе. (без FEEF к стати). UCS - Universal Character Set и на практике, когда говорят о юникоде - подразумевают именно UCS, в то время как UTF - Unicode Transformation Format - (обычно о UTF говорят как о кодировке) и появилась только для обратной совместимости, т.к. он может мирно сосуществовать с 8-битными кодировками( т.е. строками в UTF могут рулить стандартные строковые функции C в отличие от UCS, а не потому, что кто-то пожалел лишний байт как утверждает Жоэль. )

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

> И по теме речь шла о UCS-2 - именно так представлены строки в жабе. (без FEEF к стати).

ну давай по теме.

во-первых речь шла о widechar в С++.
во-вторых, никого не ебет как представлен юникод внутри jvm, при любом вводе-выводе надо указывать кодировку.
в-третьих UTF-8, UCS-2 и прочая это все-таки кодировки, и ты лишнего взпизданул.

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

1) перегрузка функций в C++, Java, Ada - это свойство языка рассматривать две или более функций (методов класса, объекта) имеющих ОДНО имя и набор формальных параметров, отличающихся по типам или количеству или порядку следования как РАЗЛИЧНЫЕ функции (методы класса, объекта). В Ada к тому же функции (методы класса, объекта) могут быть перегружены и по типу возврата.

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

T operator++(int)

писать что то вроде

T operator preffix(++)()

что по моему выглядит значительно ХУЖЕ.

>Убогость возможностей. См. defmacro, далее везде.

Сделать мощный препроцессор не проблема, к томуже их куча! Хотя бы m4. Однако нынешняя культура состоит в том, чтобы сократить использование препроцессора до минимума. И это правильно.

>Это не юникод. Это всего лишь std::basic_string<wchar_t>. Нигде в стандарте не сказано, что wchar_t - это юникод. Говорится лишь, что оно должно быть >=short.

sizeof(w_char_t) = 2. Это в стандарте СКАЗАНО. И L"Hello" - это UCS2. См. стандарт.

>В частности, это может быть любая multibyte-кодировка, согласно локали.

Конечно. Это может быть все что угодно. Однако как Вы будете работать с UTF-8 например используя std::wstring ? С UCS-2 все ясно:

std::wstring = L"Hello World!";

>Речь шла о тех потоках, которые streams. 


Былобы любопытно узнать, чем они Вас не устраивают? 



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



Откровенная чепуха! Я бы понял, если бы речь шла об Objective-C а так ...


>Читал. И ты знаешь, char<=short<=int<=long - это на стандарт не тянет. То-то в каждой второй либе в хедерах видишь #ifdef BLAH/typedef int int32/#else/typedef long int32/... ну и про отсутствие 


В старом (9x) стандарте этого действительно нет. В новом (как к стати и было де факто) char - 1, short - 2*char, int 2*short, long - 64 на 64-битах и 32 на 32-битах. 


>_стандартного_ 64-битного целочисленного типа не забудем...


На 32 битной платформе. Это правда.



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


Всего один пробел. В любом случае T< A<x>, B<y> > более читабельно чем T<A<x>, B<y>>. Ну а насчет семантической перегружености - согласен, однако замену предложить затрудняюсь. В жабе однако угловые скобки переняли и не смутились семантической многозначностью. В конце концов это проблема компилятора. Надеюсь для Вас это не представляет трудностей? В жабе к стати перегрузили и :, хотя ввести in было логичнее.



>Хотя и в плане фич там все не так гладко - как насчет ограничения по типу для аргументов-классов? 


О чем это Вы? Может о том, что нельзя нельзя использовать шаблонные параметры с ключевым словом class типа


template<typename A, ... >
class SomeClass {
  class A;
  A* xxx;
  friend class A;
}


это действитель раздражает, однако в новом драфте это пофиксено.


>Или необходимость регулярно использовать 'typename'?


Это меня не смущает. Конечно можно было возложить эту работу на компилятор ( и gcc до 3.4.x это успешно делал), но если я знаю, что это тип, а не что то другое - почему не сказать об этом? OCaml например infer-ит типы переменных из выражений - можно сделать и так, только зачем? проблема в скорости компиляции. жаба тоже этого не делает.




Короче шаблоны конечно не без огрех, но насколько мощная штука!
Тоже относится и в целом к С++. Не одно средство программирования не идеально. Опять таки как было сказано выше, Herb Shutter в компании с Microsoft практически закончили разработку C++/CLI стандарта. Почти все чего бы  многие хотели там есть. Будем ждать VS-2005.

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

См. UnrealScript:

preoperator++ (T&); postoperator++ (T&);

> Сделать мощный препроцессор не проблема, к томуже их куча! Хотя бы m4. Однако нынешняя культура состоит в том, чтобы сократить использование препроцессора до минимума. И это правильно.

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

> sizeof(w_char_t) = 2. Это в стандарте СКАЗАНО. И L"Hello" - это UCS2. См. стандарт.

Смотрю. Там написано:

"6. Type wchar_t is a distinct type whose values can represent distinct codes for all members of the largest extended character set specified among the supported locales. Type wchar_t shall have the same size, signedness, and alignment requirements as one of the other integral types, called its underlying type" (ISO/IEC 14822, пункт 3.9.1)

Так что размер wchar_t может совпадать как с short, так и с int, и это совершенно не обязательно UCS2.

> Было бы любопытно узнать, чем они Вас не устраивают?

Отсутствием удобных методов для работы с бинарными данными. Потом сама концепция потока с перопределенным символьным типом (basic_istream<T> и basic_ostream<T>) - имхо ошибочна, поскольку сразу выдает с головой изначальную нацеленность плюсовых потоков на обработку текста, а не бинарных данных; все-таки грамотно на низком уровне иметь потоки, работающие с блоками байт, а над ними уже надстройка, позволяющая оперировать с текстом (скажем, в .NET - Stream и TextReader/Writer соответственно). Отсутствие потоковых классов для работы с сокетами.

> В старом (9x) стандарте этого действительно нет. В новом (как к стати и было де факто) char - 1, short - 2*char, int 2*short, long - 64 на 64-битах и 32 на 32-битах.

Когда успел выйти новый стандарт? И кстати с 64-битным long - не погорячились они? это половину существующих либ сломает...

> Короче шаблоны конечно не без огрех, но насколько мощная штука!

Да не спорю я с этим! Мне нравится набор фичей, заложенный в C++, по сравнению с той же жабой (хотя можно было и больше, тот же препроцессор или pattern matching, а всякий мусор - выбросить нах). Мне не нравится то, в какую обертку это завернуто.

ruby как язык (не считая стандартные библиотеки) делает и perl, и python и все что угодно.

нахуй он сдался без библиотек -- сферический конь в вакууме

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

Через пять лет будет perl6. С во-о-от таким вот цпаном.

А рабби и пистон по прежнему будут ходить в перспективных (если не объявится очередной "по-настоящему продуманный и насквозь {подставить buzzword по вкусу}-ориентированный" язык).

> Через пять лет будет perl6. С во-о-от таким вот цпаном.

если пофлеймить, то ты не по адресу.
в этой теме уже все пиписьки перемеряны.

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

вам шашечки или ехать?

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

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

на перле в любом случае получилось бы на полчаса дольше