[ИМХО]
Мы тут с powerfox'ом решили захоливарить..Суть сабжа. Я утверждаю, что зная основы Ruby, не стоит отвлекаться на такой мусор, как Python. powerfox настаивает на том, что надо знать и Python в том числе...

Были взяты два примера.
(ruby)


и (python)


Одинаковый по действию код. НО. По-моему умножать строку на число не совсем логично...
[/ИМХО]

Далее... Вооружившись книгами по python и ruby... В том же духе, под эгидой "где логика ?!"...

Добавлено @ 16:19
(из книжки !)

Что мы видим ? Нормально. Заменяем в тексте запятую на "zpt", Однако, если глянуть немного "с боку". Что мы видим. Подгружается МОДУЛЬ строка (типа строки не всегда используем). Задается текст (ОК). Далее. Из модуля (!) string вызывается метод replace. Почему не text.replace ?

Добавлено @ 16:22
Про словари.

Думаю всем понятно как ЭТО должно выглядеть в реальной жизни 


Это сообщение отредактировал(а) GrayCardinal - 21.12.2008, 16:27

Так, "навскидку", пока всё   
Короче Python   

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

p -> print.

В питоне 1 в 1.


Не поверишь, но тоже 1 в 1 
В общем, такое можно написать и на С++.


Это сообщение отредактировал(а) powerfox - 21.12.2008, 16:43

Этот же код прекрасно работает и в Руби, а по поводу логичности, так это от контекста зависит.


Оригинальные камменты для кода на Питоне 

P.S. Языков надо знать как можно больше, хотя бы основы, это очевидно для любого программиста, т.к. ни один из существующих на звание silver bullet не тянет, соответственно если не хочешь ограничивать круг подвластных задач жёсткими рамками одного языка, то надо выбирать язык под каждую конкретную задачу. 
Насколько я знаю, особенность Питона в том, что там практически любая задача решается единственно возможным способом, что зачастую проявляет ограничения его интерпретатора, который в некотором смысле приносит удобство в жертву скорости выполнения, а в Ruby наоборот, практически на любую задачу найдётся с десяток разных способов, выбирай какой больше нравится... 

Что-о-о? Нет, насчёт «There should be one—and preferably only one—obvious way to do it.» © Python Zen всё верно. Но отнюдь не в ущерб скорости выполнения, напротив, только YARV недавно позволил Руби как-то тягаться с питоновским интерпретатором байт-кода.
Собственно, с этой позиции и стоит их сравнивать. Руби действительно во многом интереснее как язык, хотя отличия не столь радикальны. Вопрос в бибиотеках, эффективности, поддержке. И персональных вкусах, конечно же.

Ой  

можно по другому:




то-же на руби:

Ну, по поводу умножения строки на число, уже опередили. В Ruby тоже так можно. В этом весь Ruby! There is more than one way to do it! (лозунг для такого подхода, походу, дёрнут у Perl ).


Весь это Zen - словоблудство! И не более.


Python 2.6 vs Ruby 1.8.7. Превосходство (в среднем) - 3-5 раз. Т.е. производительность даже до YARV была одного порядка.


  


Вот это да. Мне вот например C-like синтаксис не по душе, так я когда Python увидел, чуть не  Вот.  

kemiisto, я слышал ты на Delphi программируешь...  
единственное, что сильно не нравится в python, так __вот__ __такие__ __методы___ __и __такие __private __аттрибуты  

Сишники в своё время грызли дотнетчиков за 20 процентов, а ты тут разами кидаешься! Не для холивара стратегия 

примеры какие-то игрушечные, нужен реальный пример  
например такой: есть список целых чисел [1, 2, 5, 3, 7... нужно создать список по следующему правилу, если очередной элемент равен N, то мы добавляем N элементов со значением N, практической пользы в этом нет, но по крайней мере можно увидеть больше возможностей ЯП 

Добавлено через 1 минуту и 40 секунд
вот так 

Добавлено через 4 минуты и 6 секунд
вариант на срр

Точнее - программировал. Delphi - уже в прошлом.  


Сишники вечно всех не по делу грызут!  


Меряться будем?  О! А что будем замерять, скорость? Или холиварить по синтаксису?

ну по скорости мой пример будет сложно побить 

Добавлено через 21 секунду
по скорости написания, читаемости итп

Добавляем, вроде, N - 1 элементов? Один то уже есть. Так?

да, в общем результат - новый список  

Ну, если новый список, то можно, например, так:


Добавлено через 9 минут и 3 секунды
Или так:

 

Добавлено через 2 минуты и 8 секунд
хотя наверное можно и короче... сейчас что нибудь соображу.

Это сообщение отредактировал(а) Lazin - 21.12.2008, 21:09

Нате вам

Мне вариант Void'а понравился.  А Ruby как? Разве не выразительно?

Пока я думал, ты написал похожий пример.

-----
Ой, немного не то делает ))



Это сообщение отредактировал(а) powerfox - 21.12.2008, 21:21

MAKCim,   Нет, это слишком структурно.  

Lazin,  если это

наглядно, то я даже и не знаю, что сказать! Хотя, оно и понятно, синтаксиса то я не знаю питоновского.

Он крут, как всегда 

В споре, что круче, Python или Ruby, правильным ответом будет Void.  

 

Это сообщение отредактировал(а) powerfox - 21.12.2008, 21:54

ну это называется list comprehensions, в принципе ничего сложного тут нет, в общем Python пока впереди  
вообще, что такое есть в руби, чего нет в питоне?

Смотрю на твою аватарку и думаю об этом   

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

в обшем тут создается замыкание(closure),и все работает нормально, но, если попытаться изменить переменную local внутри функции inner то произойдет ошибка: UnboundLocalError: local variable 'local' referenced before assignment. что-бы это обойти нужно извращаться, например так:

а в python3k этой проблемы уже нет, благодаря новой конструкции языка - nonlocal:


Это сообщение отредактировал(а) Lazin - 22.12.2008, 09:33

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

P.S. Вот кстати пример на Ruby, тоже в одну строчку


Это сообщение отредактировал(а) source777 - 22.12.2008, 14:54

source777, перечитал: действительно, заклинило  Как всегда только автор обратил внимание.

От перемены мест слагаемых... Ну, думаю, ты понял.  Языки во многом схожие, так что холивара не будет, холивара нет!  

так совсем неинтересно, неужели никто не знает, что хорошего в этом вашем руби?  

Он модный, имхо.

В Ruby нет нужды в табах.   
Gem'ы которые можно устанавливать с помощи cmd\terminal.

а для питона есть setuptools, а так-же pip  

На всякий случай, ибо в соседнюю тему ее уже прилепил.

nerezus, как только Ruby перейдёт на YARV, хвастаться будет уже нечем. Бенчмарк.  

10-50% прирост производительности, в большинстве тестов, а теперь смотрим еще раз на график 
вообще, дело даже не в производительности а в фичах, python делает руби по фичам  

nerezus, а что мне до твоего Psyco, ты вот сюда посмотри:

  

Это сообщение отредактировал(а) kemiisto - 26.12.2008, 12:45

ну и? все равно быстрее, да и производительность здесь не самое главное  

Да не заметишь ты такого "быстрее". А что да

то без списка фич  - незачёт!  

ну как скажешь... вот то чего точно нет в руби

• - генераторы
• - генераторные выражения
• - сопрограммы
• - декораторы

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

А вообще, у меня складывается впечатление, что:

Не помню, где встретил, но, как говорится, ППКС.  

Это сообщение отредактировал(а) kemiisto - 26.12.2008, 13:58

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



тут переменные tickets, play, prize - генераторы, созданные с помощью генераторных выражений.
Главный прикол генераторов в том, что они ленивы, то-есть не вычисляют всю последовательность сразу, поэтому они позволяют работать с бесконечными последовательностями  
для данного примера это означает, что тогда, когда будет напечатан первый результат, будет создан только один лотерейный билет, а не все 12
про остальное напишу потом

Это сообщение отредактировал(а) Lazin - 26.12.2008, 16:43

Lazin, так ну с генераторами разобрался - есть!

Сейчпс посмотрим, что там за генераторные выражения...

декораторы:


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

Добавлено через 1 минуту и 29 секунд
зы
сдесь logger это декоратор, some_func - декорируемая ф-я

сопрограммы:

в общем это генератор наоборот, ф-я print_value на самом деле не ф-я а сопрограмма, единственно но, нужно сначала вызвать ф-ю next генератора, а потом уже туда что-то отправлять, но это можно обойти использовав декоратор  

Декораторы - так я и не понял, что это, но в Ruby это тоже можно.  

ага, с помощью патча для интерпретатора   

Синтаксический сахар рулит? Давно ли?

Добавлено через 6 минут и 2 секунды

И это тоже есть. Признаться мне очень трудно оценить практическую полезность всех этих "фич". В конечном счёте - всё это синтаксический сахар. Да, Python, наверное, будет послаще... Но, разве в этом суть?

В общем, вот правильная статья! 

Добавлено через 8 минут и 28 секунд
И коменты там тоже ничего.  

Эх народ, как же меня умиляют подобные "беседы". Супер.

Кстати, как опытный холиварщик, могу сказать, что слив типа "а это синтаксичесий сахар" на самом деле означает "блин, а реально нет:(". Тем более из уст приверженца Руби

Daevaorn, ага, сразу видно, что ты "опытный" холиваршик. Не читая, сразу всё "разрулил". Извиняюсь за грубость, но речь шла о том, что декораторы в Python появились вот так:

Тут как раз и говорится, что это синтаксический сахар. И неоднакротно обсуждалось в списке рассылки: 1, 2, ...

Для первого варианта в Ruby есть аналог, чтоб была поддержка Python-like декораторов - нужно патчить интерпретатор. 

Ровным счетом не важно как они появились. При сопоставлении фич языка, ответ вида "синтаксический сахар" не зачетный. Т.к. сахар не сахар, это не важно - важно что эта фича есть.

Кстати, сливы типа "а полезно/нужно ли" тоже в зачет не идут. У всех своя область применения.

если-бы не синтаксический сахар, писать нам всем на асме  

Дык и не было такого "слива". А про синтаксический сахар. Ещё раз: то, что в Python делают декораторы, доступно и без них. Причину введения в язык декораторов я уже приводил:

Ну, коли уж это не по-питоновски, так уберите первую возможность! А то:

Shoul be, should be, а как на деле, так 

 

Добавлено через 1 минуту и 42 секунды

Как любит говорить Akella, Troll Detected!  

Опять повторяю, что это не аргумент. Так можно дойти и до того, что операция умножения тоже синтаксический сахар...Нет, есть фича и её не отнять.

Да ладно там декораторы, в питоне ещё куча вкусностей и дескрипторы, и метаклассы и даже list comprehensions. Так что список набирается хороший.

Вы утрируете. Операция умножения - одна из 4-х простоейших арифметических операций. Никак она не может быть синтаксическим сахаром.


Я и не отнимаю, просто говорю, что такая же или аналогичная по функциональности "фича" найдётся и в Ruby. А если не найдётся, видимо, не нужна. В свете наличия других "фич".


Я не знаю, что это такое. Но либо это есть и в Ruby, либо в нём есть иные "фичи" для достижения аналогичных целей. 


А вот это как раз не аргумент, т.к. если "покопать" Ruby можно набрать аналогичный список.

Просто сначала говорили скорость - оказалось, что уже не аргумент. Python 3 существенно медленнее предшественика, а вот Ruby 1.9 (2.0), напротив, должен существенно прибавить в скорости. Потом был аргумент:

Как оказалось всё это (или как минимум аналоги) в Ruby есть. 

А теперь, посмотрим с чего всё начиналось:

Так вот, если убрать слово мусор, то я, как говорится, ППКС. Т.е. я хочу сказать, что зная Ruby, знать Python не за чем. Обратное то же верно! Языки во многом схожи (перечислять не буду, лень, но думаю понятно). Нет смысла изучать 2 таких похожих языка. Одни и теже задачи на этих языках решаются примерно одинаково (с использованием аналогичных синтаксических конструкций). Если знаешь основы Ruby, значит ты не разочаровался в этом языке по мере его изучения, тебе он по душе, его и надо продолжать изучать. 

Это сообщение отредактировал(а) kemiisto - 27.12.2008, 18:54

Вам? А нам нужна. Странная позиция.

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

Да еще какой! Только вы нам его еще не показали;-)

Не все.

Так основы знают многие и те кто все-таки разочаровался и выбрал питон. Так что каждому свое. Не надо крайностей.

 Т.е. ты сравниваешь нормальную версию руби и новый питон, под которые еще модулей нет, не говоря уже о фреймворках?)
Жжош.

Сравнивай одинаковые версии(в данном случае - продакшн).
А это python 2.5 + psyco и ruby(не 1.9 unstable которая).


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

 Вот когда на него перейдут - тогда и поговорим. Причем когда на него и либы сделают. А пока руби - тормоз(с этим, думаю, не споришь?).

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

Да и вообще компилятор - это синтаксический сахар над бинарным кодом (с) кто-то отсюда

Это сообщение отредактировал(а) nerezus - 28.12.2008, 12:51

Я не знал, извиняюсь. Я думал это уже официально текущая версия.  


Во-первых, топикстартер не делал акцент на веб.
Во-вторых, есть не малое число не "хомпагов" powered by RoR. И ничего, работают.


Тормоз!   Но и Python то не особо впереди.


Я и не говорю, что не помогает...

Это сообщение отредактировал(а) kemiisto - 28.12.2008, 19:28

 В десяток раз - это не особо впереди?)

 На скольки серверах?))

интересно, куда пропал топикстартер?

Добавлено через 18 секунд
и какие выводы он сделал?  

По паре синтетических тестов разве что, на деле максимум на 30%, да и то если звёзды сложатся наилучшим для Питона способом...

Hiden features of python