-
В тредик приглашаются все ненавистники Python, которые срут кирпичами от его существования, у которых Python вызывает butthurt, и которые нереально крутые инженеры, которые лучше знают, как должен выглядеть язык, а не как это себе представляет Гвидо Ван Россум. В общем говно на вентилятор, и так далее. Мне также можно посылать лучи поноса. А я посижу и поржу пока, ОК =)
Replies (90)
-
@lomalkin, я вот тоже не нахожу никаких минусов. Ну интерпретируем. Ну скорость не такая как у компилируемых. Ну нет четкой парадигмы. Ну дык если мозг не может абстрагироваться от каких-то правил четко строгих, и не может действовать вне рамок четко заданных правил, не может искать решения в более гибкой среде — то явно возникает критика таких систем, и надо обязательно сказать, что какая-нить Ada, C, и так далее круче. Сколько лулзов уже было словлено то с критиков утиной типизации. Причем потешались над такой критикой, как питонисты, так и рубисты :D
-
@demiazz, сишников с их "аргументами" я уже давно посылаю нах^Wписать какой-нибудь ERP-проект или нечто подобное, большое. каждый язык для своей области, после этих слов аргументы наивных обладателей "более длинного" (сишников и иже с ним) не воспринимаются или приравневаются к ассемблероебам.
-
@lomalkin, знаешь. порой мне кажется, что все это недовольство вызвано, что люди просто не могут привыкнуть к питону или к другому языку. Потому что, вот на тебе — строгие правила, строгие ограничения. Когда то познакомившись с питоном, я тоже долго не мог привыкнуть. казалось не естественным. а теперь вполне себе логично, и понятно. И я не боюсь как бы своих ошибок, потому что я уверен в том, что я пишу, даже не смотря на то, что типы там могут быть динамически опрделеляемы, или еще что то. Мне уже совершенно не требуется постоянно думать о типах, и я знаю, что у меня где будет делать. Но трудно видимо многим отвыкнуть от привычки типизации — а не привыкнув — легче сказать что гавно. либо чрезвычайно завышено ЧСВ.
-
@demiazz, про сам питон я знаю немного, но из минусов: — течет память (косяк интерпритатора, надеюсь скоро пофиксят), — тяжелый (ну и хуй, лиж бы надежно работало (а утечка памяти надежности не добавляет)), — хуевая обратная совместимость (ну да отказ от нее зачастую неплохой, хоть и неприятный шаг — но может вести к достаточно быстрому развитию, т.к. отказ от костылей, поддерживающих написанное под прошлые версии дает больше времени на разработку новых возможностей/фиксу багов — что априори хорошо)
-
@lomalkin, как я понял сборщик мусора у них не айсовый. Ну тут опять таки. смотря что за приложение. если веб — то вьюха отработала, и чистится. А вот если длительное время работает — то да. может быть. ну и не будем забывать про сишные библиотеки. и вообще либы которые используются в приложении =)
-
@demiazz, stackless.com во =) Stackless Python =)) расширенная версия языка со своими вкусностями
-
@lomalkin, ну да =) да в принципе. утечки могут быть в любой программе. никто не может идеально написать. Только вопрос в другом. если утечки будут в интерпретаторе — и сколько бы не рос проект, утечек не возникнет в коде проекта. Другое дело если это си или плюсы — неверное движение пяткой — и еще один источник утечки памяти. и их количество может расти пропорционально росту проекта
-
@demiazz, вот, именно этим самым волшебные си (а я действительно так считаю, очень мощный же язык) далеко не всегда удобны, а в питоне (да и в чем угодном современном, от явы до точканета) можно не думать хотябы об этом и просто писать код, не заморачиваясь. но опять таки, это тоже не заслуга питона и она этим его не выделяет)
-
@demiazz, не. все же отдельный. в общем — улучшенная производительность по сравнению с CPython. Тут пошли по пути изменения стека вызовов, а также перешли с использования простых потоков ОС на свои микропотоки. Заявлено что, при большом количестве потоков будет работать быстрее. а из за больших изменений в коде — не может стать просто библиотекой. поэтому поставляется как альтернатива CPython
-
@demiazz, Недавно пробегала лекция на тему этого вашего удава. Конкретная проблема — хреновая производительность на многоядерных системах в случае использования тредов. Причём хуже, чем на одноядерных раза в 2-3, из-за кривого механизма, лежащего в питоне с бородатых времён. Вот это — грустно. Хотя плюсов перед тем же руби — фиг найдёшь./45 · Reply
-
@ZiNk, а да. забыл. а как там дела у руби на поле кодировок? =) а то с каждым релизом неимоверно радуются очередному шагу в кодировках. Че та непонятно как то у них с ними дела до сих пор. так то руби сам по себе не плох. есть своя изюминка. но у него пока хватает подводных камней, чтобы не использоваться, ну кроме как рельсы спасают. Просто я особо не встречал проектов на руби.
-
@ZiNk, значит таки да. это у них парад был насчет их иероглифов. Таки я был прав. А рельсы я как то пытался. Но что то не поперли они меня =) не мое. YAML мешать с руби. и все в кучу. я даже от пилонсов открестился по этому. В Djange как то все сразу однородно. Ну и на базе SQLAlchemy также. но это мое личное предпочтение. =))
-
@ZiNk, кстати. насчет рельсов. вот такой вопросик. думал я тут недавно над Redmine. Как там настраиваемые поля сделаны. В джанге поля в таблице намертво крутятся, и базы прикручиваются. без манагеров к таблицам через модели не пролезть. Как в RoR дело то? как там ORM строится? к примеру можно сделать, чтобы была модель, и несколько таблиц по этой модели. И при запросе указывать, какую именно таблицу использовать? =)
-
@ZiNk, если в веб идти, то думаю они равноценны сейчас. к питону давно уже интерес. особенно Django. А руби — тоже на гребне. Правда если руби — то тут уже более строгую ориентацию брать на рельсы и веб придется, как мне кажется. ну и со знанием жабы — излюбленная комбинация сейчас как я замечаю: JRuby + RoR =)
-
@demiazz, Как обычно встаёт вопрос: а что учить лучше и проще. :) Хотя сейчас работы и с явой — за глаза и за уши. А хочется и что-то с прицелом в будущее и для души. Питон ещё радует кучей библиотек и интеграцией с оп. системами — всякие свистоперделки для той же убунты на руби писать уже не будешь. :)