[Веб!] Рубисты, что вы имеете против Пайтона?

Просто это ведь факт, что из-за инструментов руби побеждает всё и вся.
Мне хотелось узнать если ли в руби что ещё «такого».
Я, вместе с несколькими людьми, сейчас занимаюсь написанием динамического фреймворка на пайтоне(вообще, не только для веба), который сможет затмить собой RoR.
Мне хочется знать, пойдут ли люди на Python со своих RoR, PHP(хотя там понятно что пойдут только некоторые люди, всё-таки это ниша специфична, там приходится только поддерживать и дописывать код, поэтому и выбора просто нет) если инструменты позволят.

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

теперь понятно, почему у нас заводы вперде

Вы так говорите, как-будто не знали об этом.
Вообще, это самый знаменитый факт о IT-образовании в рашке: на практику люди идут на _заводы_ и пишут ПО для них на том, чем их обучали.

>«сейчас занимаюсь написанием динамического фреймворка на пайтоне(вообще, не только для веба), который сможет затмить собой RoR»

Хотелось бы глянуть...

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

еще овер 9к хайлоад проектов?

Так на PHP они пишутся не потому, что язык такой клевый, просто, как правило, прототип был написан на нем (или _сам_ господин стартапер ничего другого не знал или нанял команду студентов за еду), а после обрастания мясом, уже поздняк метаться.

> Так на PHP они пишутся не потому, что язык такой клевый, просто,

как правило, прототип был написан на нем

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

Ну не всё же так просто. Ну это крайне наивно просто так думать. Собственно, вы повторяете аргументацию пресловутых «лисперов», что «не осилили». Осилил, многие осилили, но всё равно выбирают PHP и, конечно, не за его языковые свойства, но за возможность эффективного использования на практике с учётом всех реалий.

> Зачем создавать DSL если их тысячи?

На Руби не создают DSL, а просто используют возможности чуднОго синтаксиса Руби. То, что такую манеру записи называют eDSL, никого не должно обманывать.

Собственно, вы повторяете аргументацию пресловутых «лисперов», что «не осилили»

Про «не осилил» я не говорил. Скорее ни о чем другом не знали или не пробовали.

Я этот пример не от балды привел. Работал c подобным highload.

возможность эффективного использования на практике с учётом всех реалий.

Ну рашка тут как всегда, вперде планеты всей.

> Про «не осилил» я не говорил. Скорее ни о чем другом не знали

или не пробовали.

Не суть, это типичная аргументация лиспотролей.

Ну рашка тут как всегда, вперде планеты всей.

Как будто на PHP только у нас пишут. Вообще очень рекомендую к прочтению «Профессиональное программирование на PHP» (Джордж Шлосснейгл) - автор, безусловно, знает и сильно вероятно, что пробовал, но всё равно является сторонником PHP и после прочтения книги у меня создалось чёткое представление почему все языковые недостатки PHP не являются реально значимыми с точки зрения веб-разработки.

Вообще очень рекомендую к прочтению «Профессиональное программирование на PHP»

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

все языковые недостатки PHP не являются реально значимыми с точки зрения веб-разработки

Я где-то говорил про языковые недостатки? Язык как язык, пусть слабая типизация несколько напрягает, но это пустяки. Проблема в имплементации, интепретатор у пхп хреновый, если не сказать больше. Основные две проблемы мешающие жить:

* Плохой gc, что усугубляется еще и отсутствием слабых ссылок

* Нет нормального интерфейса к веб серверам, все содержание скриптов парсится заново при каждом запросе.

>Ну и наличие интерпретатора для моей мобилы тоже радует :)

Дадада, на S60 питон крайне полезен)

> Основные две проблемы мешающие жить

Что-то я не понял, а главное не заметил на практике, как это мешает жить. Скрипты ведь парсятся обычно не каждый раз, ведь есть кэширование. А GC и в Python не сказать, что звезда. А тормоза той же Django в режиме разработки (как, впрочем, и RoR) это вообще жуть.

Что-то я не понял, а главное не заметил на практике, как это мешает жить.

Значит вы не работали с большими проектами.

Скрипты ведь парсятся обычно не каждый раз, ведь есть кэширование

Ладно, не парсятся, а исполняются. Когда я уходил, на поднятие окружения (конфигурация, инициализация контейнера) тратилось по 100ms. Это то время, которое в других языках тратится только один раз, а не при каждом запросе.

А GC и в Python не сказать, что звезда.

На его поведение, по крайней мере можно повлиять. Есть инструменты для анализа графа объектов. А не отcтреливать процессы по достижению лимита, ага.

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

а не при каждом запросе.

Ерунда, по большей части, ибо ключом к высокой производительности является кэширование.

Значит вы не работали с большими проектами.

Может и так, но я знаю что Facebook на PHP, а сколько-нибудь сопоставимого по размаху и нагрузке приложения на Python нет и не предвидится.

Ерунда, по большей части

Среднее время отдачи большинства страниц 300-500ms, и вы хотите сказать что 20-30% это ерунда, сущий пустяк? Только не для highload.

ибо ключом к высокой производительности является кэширование.

Опять мнение человека много не кешировавшего. Кеш это last resort, когда больше ничего нельзя сделать, потому что он усложняет систему и добавляет новых проблем.

Может и так, но я знаю что Facebook на PHP

Скажите, а от хорошей жизни появился hiphop? Я думаю в фейсбуке работают гении, если они могут справиться с такой нагрузкой на PHP.

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

на RoR не нужно писать тонны middleware на каждый чих
потому что все это уже написано
а вот для той же django написано в лучшем случае 10% от того что написано для RoR
никто в здравом уме не станет искать себе дополнительную работу для решения одной и той же задачи
и успех будет зависить от того, насколько рано все это появится в вашем фреймворке, ну и pr конечно же

> Среднее время отдачи большинства страниц 300-500ms, и

вы хотите сказать что 20-30% это ерунда, сущий пустяк?

Конечно, ведь это в любом случае очень долго.

Только не для highload.

Остаётся только удивляться почему там так много PHP.

Кеш это last resort, когда больше ничего нельзя сделать, потому что

он усложняет систему и добавляет новых проблем.

Если вы говорите о highload, то без кэширования никуда, а в прочих случаях вообще о производительности слишком много говорить не стоит и широкое распространение PHP как раз об этом и говорит.

Я думаю в фейсбуке работают гении, если они могут справиться с

такой нагрузкой на PHP.

Хотите сказать, что писать на PHP могу только гении? Собственно, вопрос в том, почему гении выбирают PHP? И почему другим не стоит полагаться на мнения гениев?

Лиспер пытается убедить питониста, что пхп не так уж и плох )))

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

Если вы говорите о highload, то без кэширования никуда

Опять повторюсь, в нагруженных проектах с большим количеством динамики, кеширование добавляет очень много головной боли. И применяется, только в крайнем случае. Так к слову, траффик до мемкеша 100MBit, и это не считая кучи файловых кешей. Я думаю, это дохрена (делая скидку на регион).

Хотите сказать, что писать на PHP могу только гении?

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

Собственно, вопрос в том, почему гении выбирают PHP?

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

И почему другим не стоит полагаться на мнения гениев?

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

Потому что когда так много действительно хороших разработчиков используют PHP, то это не спроста

Тут тупо статистика. PHP девелоперов вообще много, поэтому неудивительно что среди них достаточно хороших.

Ну и ещё, как бы пытаюсь показать, что питонисты используют ту же самую аргументацию,

Можно пруф, где лиспер хает питоновский GC, а вторая моя претензия вообще php-специфична )). А остальное меня в пхп устраивает, так-то.

Я лично вообще не понимаю, как народ на PHP пишет. Неприятный сам по себе язык, да и честно говоря, не язык вовсе в строгом понимании.

Я лично вообще не понимаю, как народ на PHP пишет.

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

Это вы ещё лебедевский «парсер» не видели…

>Какие минусы вы заметили в своём языке(руби или пайтон), которые лучше в другом(руби или пайтон)?

Руби тормозной, пайтон убогий аки жаба.

>Я считаю что руби это тот же пхп ... тормоза, избыточность, одна ниша.

Можно раскрыть тему избыточности?

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

И как насчет раскрытия темы отсутствия обратной совместимости в питоне

Чтоб ты вообще знал? Слышал звон и носишься с ним.

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

Твои смешные попытки применить QTableView как GtkTreeView уже на слуху всея ЛОРа, поэтому читать такое от неосилятора очень грустно.

>Чтоб ты вообще знал?

Что, у вайтспейсника в попке закололо?

Твои смешные попытки применить QTableView как GtkTreeView уже на слуху всея ЛОРа, поэтому читать такое от неосилятора очень грустно.

Твое убогое сознание так и не осилило, что местные рекомендовали QTableView для multicolumn list, в то время, как для этого обычно используют *TreeView?

> И как насчет раскрытия темы отсутствия обратной совместимости в питоне

Всё прекрасно - рабочая ветка 2.x и обратно несовместимая с ней ветка 3.x четко разнесены, с портированием никто не торопит. А как с этим в Руби? используется либо тормозная, но привычная 1.8, либо 1.9, которая побыстрее, но кое-что ломает?

любую серьезную попытку его применения?

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

Это слышал много раз, но нормального объяснения, что не так с ООП в Питоне, не слышал ни разу

Я не говорил что с ООП в Python что - то не так, я сказал что в Ruby оно сделано лучше.

# сохраняем блок кода
# выполняем блок кода

Это не блок, а функция, и даже не анонимная. Если ты настаиваешь на том, что это полноценный аналог блоков из Ruby, перепиши предложенным тобой способом на Python:

[1, 2, 3].inject do |acc, x|
  puts "acc = #{x}"
  acc + x
end

> это хороший вопрос, насколько вообще необходимо метапрограммирование и DSL. Построение хорошего DSL в любом случае - сложная штука

В том и дело, что это зависит от языка. В Python это сложно, в Ruby легко. DSLи однозначно нужны, так как не редко только с их помощью можно снизить сложность кода до приемлимого уровня.

>Всё прекрасно - рабочая ветка 2.x

А, то есть проблемы внутри ветки 2.x все уже забыли? Ну да, 2.7 же финалочка, а проблемы старой админской центоси шерифа не интересуют.

А как с этим в Руби?

Ruby 1.8 -> 1.9 — это примерно как Python 2.x -> Python 3, но в питоне ведь с каждым минорным релизом было.

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

Пробовал. Генерировал swig'ом биндинги к нативному коду и использовал питон для мелких скриптов (вместо C++). Изрядно нахлебался различий между Python 2.3 и Python 2.4 (дада, древнее говно мамонта, но почему-то yum update на боевых машинах делать неохота).

Больше всего мне понравилось, как я начал тренироваться на Python 2.6 на localhost, потом пришлось подрихтовать это для 2.4 версии на одной машине, а потом снова пришлось напильником править скрипт 2.4 версии для работы с 2.3. Такого лютобешаного ахтунга я не видел... Да никогда еще не видел.

Что, у вайтспейсника в попке закололо?

Легкое приятное щекотание, не более, не надо себе льстить.

что местные рекомендовали QTableView для multicolumn list, в то время, как для этого обычно используют *TreeView?

Скажи спасибо, что тебе вообще варианты решения давали на твои желания пограбить корованы и посношать дочку эльфийского короля.

Всё динамично, всё можно сделать

Тогда объясни, почему не работает хваленый питоновский duck-typing

class Foo:
    def bar(self):
        self.append(1)

    def append(self, x):
        print x

Foo.bar([]) # => TypeError

Или попробуй сделать у класса classmethod с тем же именем, что и у одного из instance-методов этого класса В Ruby классы это полноценные объекты, а в Python просто нагрузка к своим экземплярам.

>> Всё прекрасно - рабочая ветка 2.x

А, то есть проблемы внутри ветки 2.x все уже забыли?

напомни.

Изрядно нахлебался различий между Python 2.3 и Python 2.4

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

как я начал тренироваться на Python 2.6 на localhost, потом пришлось подрихтовать это для 2.4 версии на одной машине, а потом снова пришлось напильником править скрипт 2.4 версии для работы с 2.3.

Совместимости назад вообще никто не обещает. Еще яве предъяви претензии за генерики или Си++ за шаблоны и исключения.

>Скажи спасибо, что тебе вообще варианты решения давали

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

Ты хочешь сказать, что в руби твой пример работает? O_O И какова семантика append на объекте-классе?

попробуй сделать у класса classmethod с тем же именем, что и у одного из instance-методов этого класса

Теперь я понимаю, почему у рубисты работают на маках.

>напомни.

Напоминаю: в 2.3 не поддерживается finally и except в одном блоке try.

Совместимости назад вообще никто не обещает.

Okay, но почему 2.3, зарелизенный даже чуть позже двухтысячного года, не умел except и finally в одном блоке try? И почему сообщение об ошибке было... Кхм, малоинформативным.

Тогда объясни, почему не работает хваленый питоновский duck-typing

Чтобы ноги целее были, но если клиент желает, то всегда пожалуйста, у анбаунд метода можно получить ссылку на ничем не замутненную функцию.

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

> Напоминаю: в 2.3 не поддерживается finally и except в одном блоке try.

Ты, походу начал учить Питон с версии 2.6

но почему 2.3, зарелизенный даже чуть позже двухтысячного года, не умел except и finally в одном блоке try?

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

P.S. вот к таким последствиям приводит то, что у программиста на рабочем месте стоит всё самое новое.

Или попробуй сделать у класса classmethod с тем же именем, что и у одного из instance-методов этого класса

class Foo(object):
    @classmethod
    def bar(cls):
        print 'bar'


def street_bar():
    print 'street bar'

foo = Foo()
foo.bar = street_bar
Foo.bar()
foo.bar()

>Ты, походу начал учить Питон с версии 2.6

Да. Но как начал изучать, так и закончил: излишняя многословность, убогие объекты, больной на голову юникод, да просто неприятно на нем писать (это субъективное ощущение).

>Ну да, неудобно было. Но причем тут совместимость?

Если бы в следующей версии libstdc++ vector переобозвали в array, я бы точно знал: мир лишился ума и наступил конец света. Радикальные изменения в стандартной пистоновской библиотеке — это обычное дело при смене циферки.

Python — язык без вектора развития и без будущего. Эдакий FoxPro, хотя кому-то возможно больше польстит сравнение с VisualBasic.

>P.S. вот к таким последствиям приводит то, что у программиста на рабочем месте стоит всё самое новое.

$ python --version
Python 2.6.4

Не похоже на 2.7

>> Ты, походу начал учить Питон с версии 2.6

Да. Но как начал изучать, так и закончил: излишняя многословность, убогие объекты, больной на голову юникод, да просто неприятно на нем писать (это субъективное ощущение).

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

Python — язык без вектора развития и без будущего.

Ты просто мало знаешь о нем // К.О.

P.S. вот к таким последствиям приводит то, что у программиста на рабочем месте стоит всё самое новое.

$ python --version

Python 2.6.4

Не похоже на 2.7

Наверное, ты кое-чему научился.

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

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

Наверное, ты кое-чему научился.

Наверное, в 2009 году в генте не мог стоять 2.3 питон.

И, кстати, я могу использовать плюсовые исключения в gcc-4.x, gcc-3.x, не опасаясь несовместимости на уровне исходного кода. Все это происходит потому, что серьезные языки имеют стандарт, описывающий их. А наколенные поделки бородатых кульхацкеров ведут себя подобно питону.

Или попробуй сделать у класса classmethod с тем же именем, что и у одного из instance-методов этого класса

Или вот такой вариант.

def staticmethod(func):
    class CallDescriptor(object):
        def __get__(self, obj, cls):
            if not obj:
                return func
            else:
                return lambda *args: self.ifunc(obj, *args)

        def samename(self, func):
            self.ifunc = func

    return CallDescriptor()


class Foo(object):
    @staticmethod
    def bar():
        print 'static'

    @bar.samename
    def ibar(self):
        print 'instance'


foo = Foo()
foo.bar()
Foo.bar()

>> Наверное, ты кое-чему научился.

Наверное, в 2009 году в генте не мог стоять 2.3 питон.

Наверное, стоит знать язык, на котором что-то пишешь.

И, кстати, я могу использовать плюсовые исключения в gcc-4.x, gcc-3.x, не опасаясь несовместимости на уровне исходного кода.

Прекрасно подобранный пример. А использовать исключения в Borland C++ 2.0 можешь? А в 3.0 - мог. Какой плохой несовместимый Си++.

Все это происходит потому, что серьезные языки имеют стандарт, описывающий их.

Утипути. Напомнить, в каком году был принят стандарт Си++? Стандарт Си?

>Напомнить, в каком году был принят стандарт Си++?

В 2003?

Стандарт Си?

В 1989 удачно, в 1999 еще раз удачно.

>> Напомнить, в каком году был принят стандарт Си++?

В 2003?

Не 1997 разме? А до того Си++ был несерьезным языком, очевидно.

Стандарт Си?

В 1989 удачно

А до 1989 Си был наколенной поделкой бородатых кульхацкеров?

>И, кстати, я могу использовать плюсовые исключения в gcc-4.x, gcc-3.x, не опасаясь несовместимости на уровне исходного кода.

А вот ABI полетит, придется libstdc++ с собой таскать

Пока только пилится идейная часть, кода не много. Как будет что показать, создам тред здесь.
Но есть решения многих проблем, с которыми приходится сталкиваться что на пайтоне, что на руби. Однако вся идея в том, чтобы решать задачи не набором различных костылей, которые сделаны по-разному и дают разный API, а сделать так, чтобы всё решалось подключением/отключением «кирпичиков».

Рельсы не совсем руби. Основной недостаток Питона - некоторая сумбурность, в Руби все покрасивее сделано, концептуальное единство - все является объектами. С рельсами не знаком, но листинги вообще напоминают текст на естественном языке