
Ask HN: What does Ruby have that Python doesn't? - globalrev
About 6 months ago I decided to learn either Python or Ruby because I wanted a language to write webapps and simple computergames fast.<p>I kind of tried both for a while and Python gave the better impression in every way, readability, ease of use, libraries, documentation, expressiveness etc.<p>But there are so many really enthusiastic posts about Ruby and while Python has a lot of users and is very popular and successful I rarely see anyone rave about it. But maybe that just means it has gotten mainstream.<p>But anyway I like the Python philosophy that there should preferrably be one obvious way to do things. 
While similar in most ways, there the languages differ.<p>So, what do you Rubyists like so much about Ruby? Especially what do you think Pythion lacks?
======
tptacek
What the hell, they're only karma points:

I lived with Python for 4 years before I lost an argument at my own company
and had my project moved to Ruby. I've since moved in with Ruby and haven't
looked back.

* Everything in Python feels like a symbol table hack. Private methods? We have those! Just exploit this bug in the class symbol table lookup code!

* First-class symbols. There may be little difference under the hood between a Ruby interned string and a Python string atom, but there's definitely a difference syntactically. This is a difference that is hard to articulate, but if you've written much C, it's like having every "enum" you could ever want predefined for you, and completely eliminates "magic numbers".

* Blocks and lambdas. I've read GvR's take on this. I know he thinks a named function is just as good --- maybe even better! --- than an anonymous function. I had nested named functions/functors in C++ and Java. Even Tcl "uplevel" is better than Python's castrated lambda.

* Method definitions in Ruby don't need to accept a "self" argument. Again: all of Python feels like a symbol table hack to me.

* Ruby has first-class Regexps. Python has an "re" library. You know what else has an "re" library? C.

* I haven't found an expression that is better written as a list comprehension than as a map/reduce/select expression.

There are painful things about Ruby:

* The FFI is immature. Outside of Common Lisp, Python ctypes may be the best FFI out there.

* I never got Python to crash on me (at least, not where it was Python's fault). I crash Ruby once a week.

* Ruby is palpably slower than everything. If performance matters to you and you don't know C, you may be better off in Python.

* The community is led by the nose by Rails developers, which can at times feel like a worst-of-all-worlds grab bag of methodology programmers, web designers, and dabblers.

~~~
ajross
_Blocks and lambdas_

Yeah, but this is an area where both languages are just a mess. If python's
lambda is castrated, ruby's notion of an anonymous function is tumorous. We've
got blocks, procs, lambdas and methods? What's the difference?

Ruby mixes up the syntactic requirements of "passing" some code to a loop to
iterate with with the data requirements of binding a function to a scope. It's
just a huge mess.

LISP and Scheme figured all this out decades ago, and yet only Javascript
(and, almost, perl) among common scripting languages has managed to absorb the
lesson.

~~~
tptacek
You say "both languages are just a mess" as if to equate the two. But there's
no comparison.

Your Ruby problem with blocks and Proc objects is a nit about elegance and
semantics. How often does the difference between an actual Proc object and a
block actually affect you? More importantly, if the cost of fixing that nit is
that we wind up with Lisp's or Javascript's lambda notation, who would accept
that? Javascript has relatively consistent semantics for anonymous functions,
but extremely clumsy syntax.

Python simply doesn't have real lambdas. It has the ability to pass something
called a lambda in place of a function, and that something forces you to think
about things like the difference between a statement and an expression. It
then tells you that you don't in fact want anonymous functions, but instead
you want to define tens of itty bitty named functions and use them instead.
You also "want" that "self" argument to all your methods, and you "want" to
tack two underscores to the front of your method names to make them private.

So, I half agree with you. Yes, it would be nice if there was a (zero-cost)
way of fixing Ruby's block semantics. Yes, I can rely on Lisp's lambda
semantics slightly more than I can on Ruby's, which does start to matter when
you start writing domain-specific language code. But I don't agree that this
has any bearing on the Python vs. Ruby argument. Python lambdas suck.

~~~
aconbere
True python's lambda's suck. And Ruby's lambda's for the most part don't suck.

But ruby's methods really do suck, and so do the complex construction of
Blocks. While I recognize that blocks allow you to do weird things (like use
return on the calling scope), the fact that they necessitate a special form
(yield) and cannot be bound to a variable, and are not passed as standard
function parameters just makes them inconsistent and gross.

Methods which aren't first class functions (but can be transformed into one
with the helpful helper function!) also suck, and passing those around in a
functional way is just a lesson in futility.

All that being said, I have much more faith in these warts being fixed as time
goes on, than python's nasty lambda, and the gross over use of dunders.

~~~
shevy
"the fact that they necessitate a special form (yield) and cannot be bound to
a variable, and are not passed as standard function parameters just makes them
inconsistent and gross."

Which brings us to another point - when exactly do you actually need them? I
have for every 1000 lines of ruby code maybe one line of "yield" code, and
this is only to further extend classes for flexibility. Other languages dont
allow you to choose what you want to have, ruby does.

You simply have to make decisions when to use what.

For me it is simplicity, elegance and beauty. These are my biggest design
criterias.

~~~
aconbere
I'm 100% with you on simplicity, elegance and beauty. I just demand that as
much from the design of the languages I use as from my own code.

I've tried to explain it like this. To me ruby feels Turtles all the way down
with respect to Objects, but some kind of nightmare tunnel of interleaved
beasts down with Functions.

I don't think I should have to make that compromise, so I'll happily go about
writing my ruby when I have to, but I'm waiting for the language that is
consistent all the way down.

If I could replace every yield I've ever written in ruby with a .call() I
would be so much happier :)

~~~
tptacek
Ok, now I'm not sure I follow. Apart from the performance issues, why can't
you replace every method that "yields" with a method that takes the explicit
block parameter, and .call() it?

~~~
aconbere
_sigh_ yeah... you could do that, but you often times you have to deal with
methods that aren't invoked that way.

<http://blog.sidu.in/2007/11/ruby-blocks-gotchas.html>

is a good run down of some of the problems here

~~~
shevy
No it is not. You dodged the question again, by throwing a hardly related blog
of someone else at it.

How many people will use yield _AND_ self.send in the same method please?!
That seems like an awfully complicated and contrived example. Who the heck
does this?

------
davidw
I don't think Python lacks much, if anything. It's a very fine language, with
a great community. Over the years though, I just lost interest in it, and have
come to prefer Ruby after having rediscovered it because of Rails. It's pretty
much a matter of taste: I like the syntax and convenience more.

One (fairly minor) real world case where the syntax makes a difference is in
web templates: you can use Ruby pretty much straight up to do templating, but
Python requires more hoops and hacking, due in part to the whitespace issue. I
like the fact that Ruby is flexible enough to be used as-is for templates as
well as other code. BTW, it also needs to be said that that is the _only_
place I've ever noticed the whitespace issue being any kind of problem: it's
not the big deal that some python detractors make it out to be.

In short: if you're happy with Python...great! Keep using it, you made a good
choice. If you want to learn another language, pick something a bit further
from it... say, Erlang, Tcl, Java, or C, depending on what your needs are.

~~~
gaius
Note that Python is sensitive to _indentation_ not whitespace per se. So long
as your line is at the right level there's no difference between

    
    
        a=1+2
    

and

    
    
        a = 1      + 2
    

In fact I wish Python were _more_ sensitive to whitespace, then I could say
my-variable without it mistaking a hyphen for a minus.

~~~
rbanffy
"then I could say my-variable without it mistaking a hyphen for a minus"

That's something cool. It would involve a new PEP and aggressive enforcement
of PEP 8

~~~
gaius
Reckon it'd break too much existing code, but hyphens are so much nicer than
underscores or interCapping. Using a language that supports that, my hands are
noticeably more comfortable without needing to reach for the shift key all the
time.

~~~
derefr
you could just use a font that renders underscores differently (like, say,
slightly stylized hyphens.) That's the correct approach, semantically--when
you use an underscore, you're basically trying to say "a space, but without
the syntactic meaning of one."

~~~
gaius
It's not about how it appears on screen but about the keystrokes needed to
enter it. If I could I'd find a way to use only square brackets too. Ideally
I'd use only ; or : and only ' or " too, and adjust my keymap accordingly.

~~~
nostrademons
Lisp? ;-)

~~~
eru
Forth?

~~~
gaius
I really like Forth, it seems to me to be very much the right way to do
things, however I've never managed to write an actually useful program in it.

Mostly I use Tcl as a sort of Lisp/Forth mashup :-)

------
raganwald
They're both impressive, modern languages. What I find interesting when
comparing Python to Ruby is how much Python isn't like Lisp. Matz has said
outright that he considers Ruby to be "MatzLisp" and it shows, whereas Guido
has absolutely no problem chucking Lispy things overboard--like multi-line
anonymous functions--if they do not fit the rest of the language.

Instead, Python finds another way, like powerful list comprehensions that can
be used wherever Ruby would use blocks and maps.

So I would say you can learn some very interesting things from either
language, and there's a good chance they will be _different_ interesting
things.

~~~
aconbere
Matz might say that, but doing functional things in Ruby is a pain in the arse
as well. Blocks, Lambdas, Procs, and Methods, all which are slightly different
and require transformative functions to move one into the other. That's about
as far from an s-expression as you can get.

That being said, having the easy ability to create lambdas or blocks is hugely
benefitial. _sighs_ and I wish python would hop on board there, but I don't
think it ever will.

~~~
raganwald
I dig: [http://weblog.raganwald.com/2008/06/what-does-do-when-
used-a...](http://weblog.raganwald.com/2008/06/what-does-do-when-used-as-
unary.html)

~~~
aconbere
Yeah... _sobs_ it's a nice band-aid, but an inelegant solution. I would much
rather that they all just be Proc or all some other mythical procedure class
of the future. I figure that would break the whole ruby method call chain,
though I don't see any reason why blocks couldn't just become straight
syntactic sugar for lambda (I would love that)

~~~
raganwald
A little off-topic, and I apologise to everyone for our exercise in
bikeshedding, but... :-)

The problem is that Ruby blocks were designed to imitate the behaviour of
C-like blocks, while lambdas are true closures. (Don't get me started on why
procs are just like lambdas only different).

The difference between a block and a lambda is most clearly seen by asking
what the return keyword does in a block vs. what it does in a lambda.

So in Ruby you can write something like:

    
    
        def which_answer_is_correct(*answers)
          answers.each_with_index do |answer, index|
            return index + 1 if answer.to_s == '42'
          end
          return 'none of the above'
        end
    
        which_answer_is_correct('black','white',42,:symbolic_logic)
          => 3
    

If blocks were syntactic sugar for lambdas, this method would always return
'none of the above'. Of course, there is another, very elegant way to write
this method that doesn't rely on the return keyword or the semantics of
blocks, and one can easily argue that this would be an improvement.

~~~
aconbere
(though my intention was not to derail the conversation. This is a niggling
difference between ruby and python that irks me :-D)

Right I would be arguing as the latter.

My problem is that these small niggling differences between all the different
types of callable items (including what I think is simply disgusting use of a
special form "yield") confuses the whole mess.

I'm glad that all these different ways to use callables exists. That's "A good
thing" in my opinion. But I can't help but feel that their quirks and
differences couldn't be consolidated into a single experience.

~~~
raganwald
_derail the conversation_

De- _rails_ -ing conversations about Ruby is often an improvement.

~~~
aconbere
Good sir I do say... that was quite the pun :-D

 _takes his hat off_

------
rit
I've always taken the approach of learning both and deciding for myself. If
you're interested in true proficiency and building something for yourself, go
with whatever rings most true to you.

I liked Ruby, but found that Python clicked better for me. That, and call me
crazy - but I prefer quiet competence to foaming at the mouth zealotry. There
are plenty of people who rave about Python - but they've been doing it for a
lot longer than the Ruby people (simply age of language).

Ruby also has gotten lots of people hooked via Rails, and that seems to be
where most of the evangelism is coming from.

(edit: commented to clarify my meaning below, in another comment:
<http://news.ycombinator.com/item?id=283771>)

~~~
ericb
>> but I prefer quiet competence to foaming at the mouth zealotry.

Do you really pick your language by your perception of its users? I'm not sure
that's a great criteria for choosing a tool. If an annoying dinner guest
admired the butter knives, would you butter your roll with a fork?

~~~
iron_ball
Well, working extensively with a language means working with its community, as
a reader of news and documentation if nothing else. The size, expertise, and
helpfulness of the community are all important factors in deciding whether to
adopt a language. If a programmer finds the community annoying, that could be
a legitimate problem.

~~~
gaius
The community also determines what is and isn't easy. This is something that a
lot of otherwise smart people don't seem to get. Everytime someone into a
powerful but obscure language wonders why it isn't more popular the answer is
almost always something like "because Haskell's interface to Oracle is
rubbish". And that's fine, because the Haskell community care about other
things, if they want to be popular tho' they'll have to address that.

Concrete example: The Ruby community is very focussed on the Web, so there's
Rails but they aren't really interested in scientific computing so there isn't
a real equivalent to NumPy.

~~~
mechanical_fish
_Concrete example: The Ruby community is very focussed on the Web, so there's
Rails but they aren't really interested in scientific computing so there isn't
a real equivalent to NumPy._

I'd mod this up more if I could, because this is the best answer to the
original question.

The important thing is the community, not the language. Decide what your
problem is, find the people who are working on that problem, and use whatever
they use.

The importance of community is the reason why the number of people who praise
Lisp as a language is so much larger than the number who _use_ Lisp every day:
The Lisp community is small, unfocused, and arguably broken. Meanwhile, I work
as a professional Drupal developer and am (god help me) gradually becoming an
expert on PHP, but that has nothing to do with my nigh-nonexistent respect for
PHP as a language. I do it because the Drupal community is large and growing
larger, it includes as many noncoders as coders, and it's focused on building
websites rather than obsessing over tools. The result seems to be that
customers like using Drupal for their sites. Rails and the like are focused on
making programmers feel empowered, but Drupal is focused on making _site
admins_ feel empowered.

------
simonw
Two good things and one bad thing. The good things are multi-line lambdas
(which Ruby calls blocks) and loose syntax rules, which I found weird at first
but is the secret behind all of that DSL stuff.

The bad thing is the cultural tendency of the Ruby community towards monkey
patching, which in my opinion trades long term maintainability for short term
convenience.

~~~
aconbere
To be fair... blocks are not lambda's, but things would be a lot better if
they were.

------
iamnirav
I like how this conversation has gone on for so long, but on the whole,
everyone's still polite and detailed in their responses. :-) _warm fuzzy
feeling_

------
subwindow
It isn't so much about language features, as both languages are roughly
equivalent in that sense.

It is about how the language makes you _feel_. If you're going to be spending
>5 hours a day writing in some language, it is of great importance how that
language makes you feel when you write it. Simply said, writing Ruby makes me
happier than I've ever been while writing code.

Python is to German as Ruby is to French. You can get roughly the same message
across equally well in both languages, but French just sounds so much better.

~~~
donw
Two words: "French Engineering".

~~~
gdee
Two counter words: Ariane, Nuclear (as in 80%+ national electricity)... not
too shabby as far as engineering goes... I would add Airbus, LHC, etc... but
two are enough.

------
iamelgringo
_About 6 months ago I decided to learn either Python or Ruby because I wanted
a language to write webapps and simple computergames fast._

If you're after writing simple computer games fast, then you might have a look
at Pygame: <http://www.pygame.org/news.html>

There are also a number of visual effects companies (ILM, Dreamworks) that use
Python as their system scripting language. I don't know if it's because of
that community, but I find a number of graphics/games libraries in Python:
<http://www.vrplumber.com/py3d.py> and <http://vpython.org/>

Blender the open source 3D modeling program used Python as it's scripting
language last I checked: <http://www.blender.org/>

I don't know if Ruby has libraries like that or not. I've only used Ruby to
mess around with Rails.

------
pauljonas
For me, the question isn't so much what Ruby has that Python lacks, but the
extra Python bits I find annoying and/or tedious:

* having to declare "self" in every method argument — reading code, it just clutters up the screen/page

* the big use of of double underscores for special methods (i.e., __init__, __str__, __getattr__, etc...) — IMV, it's gooberish...

* no switch/case statement

In defense of Python over Ruby:

* I prefer the whitespace over the Pascal-ish begin/end, especially for real life code solutions

* the Ruby shorthand syntax IMV at times obfuscates code clarity - is it a method or variable I am looking at?

That said, I'd much rather code in either Ruby or Python than in Java or C...

------
gtani
Well, they're both foundational languages, pretty much, not in the sense of
this blog, i.e. most instructional language

<http://mvanier.livejournal.com/998.html>

but in the sense of can you put up a significant web app in 2 or 3 days, do
lots of companies use it (along with C, java, C#, javascript).

r vs. p can't be reduced to 15 bullet points, but one of the best things i
remember is Alex Martelli in 2003, so he was talking about ruby 1.6 and python
2.3, i believe, but still valid

[http://groups.google.com/group/comp.lang.python/msg/28422d70...](http://groups.google.com/group/comp.lang.python/msg/28422d707512283)

and here's the last thread from May.

<http://news.ycombinator.com/item?id=157269>

There's the other killer apps: Python: twisted, zope, SQLalchemy, mercurial.
Ruby: rake, capistrano, rspec, adhearsion, merb, puppet, metasploit. I'm sure
python has a bunch more, but i've been living in rails-land.

------
waldrews
Though I'm pro-Python on maintainability grounds, there's one Lispish feature
Ruby has that I wish were available in Python, that's not even in the Py3000
spec: continuations. The Ruby community doesn't seem to be too enthusiastic
about using them though. We're just beginning to see continuation-based web
framework experiments on Ruby, in the spirit of Seaside in Smalltalk.

The continuation-based web frameworks make state management on the server
transparent; but they have a scalability problem since state can't move
between servers or even be taken out of memory on the same server.

Now once somebody makes serializable continuations practical - certainly a
hard problem - it would be a jolt to web development on at least the same that
Rails has been.

~~~
LogicHoleFlaw
In Lua, the Pluto serialization library has no problem persisting coroutines,
which are isomorphic to one-shot continuations. Lua isn't terribly active in
the web space, though this feature has been used to good effect in games.

------
eznet
I think that a lot of the popularity of Ruby came not so much from Ruby
itself, but Rails. I think that with the emerging popularity of Django, you
are likely to begin noticing a similar influx of Python enthusiasm...

~~~
rit
Admittedly, Django was what first got me really going with Python (we started
using it for some small projects as a possible replacement for PHP a few jobs
ago).

There are however also some great alternatives within the Python community, in
addition to Django which I no longer tend to use.

Pylons, which is very Rails like including having similar WebHelpers
functions, and a port of the Rails "routes" system.

TurboGears, which is currently re-tooling itself to be based on Pylons.

And a variety of others that I'm probably forgetting.

I'm admittedly ignorant on alternatives on the Ruby side, but would be
interested to see what other web frameworks people have built and the pros
cons vs. Rails.

~~~
jon_dahl
_I'm admittedly ignorant on alternatives on the Ruby side, but would be
interested to see what other web frameworks people have built and the pros
cons vs. Rails._

Merb is the big one. Think Rails, but more lightweight, greater emphasis on
scaling and performance, and open to several ORMs (not just ActiveRecord),
templating languages (not just ERB), and Javascript libraries.

Camping is a Ruby micro-framework that's been around for a while. The
framework itself is 4kb, and Camping apps are designed to sit in one file.
Used a bit on the side, but not especially widely for production work.

Sinatra is a newer microframework that looks similar to web.py, but in Ruby.
Looks useful, and I've been meaning to get around to it.

The nice thing about Rails, Merb, and Camping is that if you know one, the
others will be familiar. They're all MVC frameworks that support ActiveRecord
(and other ORMs, sometimes). They all favor convention over configuration.

~~~
rit
>> Merb is the big one. Think Rails, but more lightweight, greater emphasis on
scaling and performance, and open to several ORMs (not just ActiveRecord),
templating languages (not just ERB), and Javascript libraries.

Sounds exactly like the reasons why I went to Pylons. I found SQLAlchemy to be
a lot more powerful than the Django ORM, and we needed more application
components to be 'detached' from the web interface which got wonky in Django.

I'll have to check these out, thanks.

------
abdelazer
After leaving Ruby (non-Rails) for Python this year, I've mostly noticed the
difference in the obsession about testing. The Ruby crew is very into TDD (and
now BDD)–that isn't to say that Python folks don't test (or do TDD/BDD), but
simply that the tools available in Python aren't quite as polished. Ruby's
RSpec, RCov, Flog, Autotest, & Heckle are all quite wonderful. I do like Nose,
but get annoyed by lack of friendly code coverage tools in Python.

------
Alcides
Rails. but you have Django which is better ;)

Seriously, I envy ruby's blocks and being able to redefine a class later in
your code (monkeypatching-easy-syntax).

Oh, and Shoes :)

~~~
ghiotion
I chose RoR over Python/Django for one simple reason: RoR's tight integration
with the Prototype AJAX javascript library. Personally, I like Python as a
language much better than Ruby. But if I'm going to code up a Web app, I want
easy AJAX integration - I don't want to hand craft a bunch of javascript. It's
not that I've got anything against writing javascript, but I hate, hate, hate
trying to debug it.

~~~
cstejerean
Tight integration with prototype is one of the things I don't like about
Rails, mainly because I don't like Prototype (I'm a big fan of JQuery).

~~~
tptacek
Then what you want is jRails, which subs jQ in for Prototype in all the Rails
helpers and removes Prototype from your project. You "plugin install" it,
forget about Prototype, and use nothing but jQuery from then on.

~~~
cstejerean
very cool, thanks. wish I knew about it a month ago.

------
demallien
There really isn't a huge difference between the two. For what it's worth, I
personally prefer Ruby because it has better support on the Mac - Apple use
ruby a fair bit themselves. For example, the command line tool
gen_bridge_metadata (supplied by Appleto make it possible to access system
frameworks written in C from scripting languages) is itself a ruby script. I
notice that on Linux it's the reverse - python seems to be the preferred
scripting language.

But don't take my comments as saying only ruby is supported on the Mac, or
only python on Linux - in reality it's only a light preference one way or the
other.

~~~
tpherndon
The CalDAV server authored by Apple and included with OS X Server is written
in Python. PyObjC receives a lot of attention from Apple employees. I don't
think there's much preference exhibited by Apple one way or the other.

And vice versa, there must be some Linux distros that have tools written in
Ruby, right? Particularly some of the newer ones, I seem to recall hearing
that their system tools were Ruby.

~~~
evgen
FWIW, the wiki that Apple includes in Leopard Server is also written in
Python. Apple apears to be making much more use of Python than it is of Ruby.

~~~
rcoder
Counter-counter: Podcast Producer is a Rails app. I think Apple is just
letting their employees pick their tools (at least for server apps) as they
see best, rather than arbitrarily enforcing the choice of a single language.

------
maxklein
The languages are similar enough that it does not really matter. Just pick
any, but make sure you balance it out by also knowing a low level language or
a functional language.

Remember this: Every language you learn is a big investment in time and
energy, and I don't think many people can be really proficient in more than 2
or 3 languages. Some can, but not most.

So, choose wisely, because you will likely be using that language for a long
time to come. I personally prefer python because it's more widespread and
right now, you have more available to you when you know it than with ruby.

~~~
tokipin
maybe i'm an incredible genius or something, but give me a week or two and i'm
writing code at an advanced level in any language. it's pretty easy. it more
or less involves making an actual project in that language, which cold turky
sink or swimly requires that you know the language at least decently

i think it's mostly mentality. if you think languages are hard to learn, then
they will probably seem that way because you will allow yourself too much time
to play around with mere _details_ , whereas if you recognize there isn't much
to them, you can accomplish a lot in no time at all

~~~
maxklein
I think it is more likely that you do not recognize your own flaws. It takes a
real genius to be able to learn the little things about C++ in a week or two.

A language is not just the syntax of the language itself, it's also the code
style, the convention, the best practise, the language specific stuff, the API
of the libraries available, the best way of doing things with libraries.

If you use python to write simple number crunching console applications, then
switch to ruby, that is an easy switch.

But if you're writing a Web application using Python and Django and you switch
to writing DirectSound using C++, and you tell me you can do this in a week,
then you are a genius.

The syntax of languages are trivial, but that's like saying you can discover
the colors used in a painting. That's the easy part. The difficult part is
knowing how it works. Let me list a few examples of technologies that I think
differ strongly from each other that make it difficult to switch

\- MFC with C++

\- Django with Python

\- DirectShow with C++

\- VHDL

\- ASM

\- Javascript with JQuery

\- CSS with HTML

\- Helix Framework with C++

\- Quicktime API with C++

\- OpenGL with .NET

\- LISP

Have you ever had to switch between things on that level? Or are you talking
more of a python to ruby switch?

~~~
icey
To go one step further, to be at an "advanced level" in a language also means
to be idiomatic in it.

I have a hard time believing that's achievable in a "couple of weeks",
regardless of the level of someone's "genius".

(Also, just because something compiles doesn't mean you're good at it.)

~~~
tokipin
when programming, if you keep your mind on the structures and on the problems
themselves instead of on the language, you'll naturally reach points where you
will demand that the language do X. sometimes the language will be able to,
and it will seem "advanced." sometimes the language won't be able and you'll
sob quietly for a moment because you have to implement it in another less
elegant way

but if you worry about the details of the language, it will prematurely affect
the structures that you create. in this mode it's harder to write "advanced"
things because you are respecting the language too much, and are more confined
to its syntax/semantics

if you stay above/outside the language, you will naturally pull it up

~~~
maxklein
Well, you prove the point. You are incapable of seeing your own weaknesses in
a language.

One can write every language the same way, but that's not programming. You
can't learn python and then write C the python way. You can't write Python as
you would Java.

Syntactically, it's possible, but that's a different language you are using
then.

Don't confuse syntax or knowing when to use particular constructs with knowing
a language. Call me slow, but it took me 3 years before I felt confident that
I really knew most of C++. I know when to use Boost, when to use STD, What
AtlArray is, how to write an IDL file, what extern 'C' does, what an stdcall
is, how my variables are layed on my stack, what Gui toolkits are available,
how Borland C++ makes properties appear in C++ classes, when one should use an
int64, etc.

It takes time to learn that stuff, but to be really good at a language, you
need to know it.

We're like doctors, you don't need to apply your knowledge all the time, but
when you need it, you need to be aware of what exists and where to look it up.

If they ask me - write a webserver under Windows, I need to instantly be able
to think of 3-4 libraries I could use for the low level stuff, and then decide
which is best. All that takes time.

The syntax is nothing. A language is a whole lot more than that. You can't
stay above a language. You need to delve into the language, you need to have a
feeling for the language, you need to feel inside you how to express things in
a particular programming language.

When you describe a problem to me, I can see the C++ structure in my minds
eye. I can mentally walk through the code, see where I would use templates,
where I would use an interface class, where I would subclass and so on.

I can't do the same with python, because even though I know the syntax, I've
not used it long enough to get an extreme feel for the language. And the
python folks like to reduce stuff down to short lines, and that's something
you don't do in C++.

Learning a programming language is learning a new way to think. Not a new way
to string sentences together.

~~~
nostrademons
> If they ask me - write a webserver under Windows...I can't do the same with
> python

I'd use BaseHTTPServer. Batteries included and all that. ;-)

------
olavk
I prefer Python, but I am somewhat envious of Ruby blocks. Also I like the
idea that method calls are messages.

~~~
pdubroy
I've done quite a bit of Smalltalk programming, and I agree about the blocks.
But what do you mean by "method calls are messages"?

~~~
LogicHoleFlaw
In Ruby calling a method on an object basically sends a message to the object
with the name of the method and the arguments. You can hook into the dispatch
code and do pretty much whatever you want with that message at the class
level. I don't know the internals of Python's method dispatch that well, so I
can't say how it compares in that regard.

~~~
gaius
I believe Python's __getattr__() and __setattr__() allow you do the same
thing, but I don't know enough Ruby to say for sure :-)

~~~
aconbere
You couple those with ruby's method_missing and then you have some interesting
functionality. But basically the way that Ruby handles operator overloading
and function accessing is a lot cleaner than pythons. It would be pretty nice
to get rid of a lot of the dunders.

------
jonhohle
this is never really brought up, but objects in ruby fully encapsulate their
instance and class variables. the only way to get at them from the outside is
by sending an object a message asking for them (like Smalltalk or
Objective-C). what appears to be setting a property on an object, is really
calling a method: `foo.bar = 5` isn't directly setting the property, its
calling a method named `#bar=`

in my opinion, this is powerful and elegant.

that being said, i have little experience with python, but what i've seen
never wowed me. it seems like it has a well written collection of libraries,
but that seems to come from the community more than the language. correct me
if i'm wrong.

~~~
cpr
You can do exactly the same thing using Python descriptors. No advantage to
Ruby here.

~~~
jonhohle
but its not enforced by the language or the object model. advantage ruby ;)

------
DougBTX
_why

------
tokipin
personally i don't like the 'one way' mantra that Python is designed by,
because it seems to imply a couple things. 1, the language is probably not as
flexible and powerful as it could be. and 2, the design goal is similar in
nature to that of production languages, eg Java which forces object
orientation. the intentions are good... to allow the construction of readable,
maintainable software by normal humans, and Python is at least not as retarded
about it as Java, but i have found that languages which constrict aren't for
me

so to me Python seems more of a team production dynamic language than one
where i can get into flow and crank shit out

~~~
nostrademons
The practical benefit of "one true way" is that it eliminates decision points.
Most of the time in a software project is wasted in making decisions; if you
eliminate all decisions that are not relevant to getting the software
finished, you have a huge head start on everyone else.

There's a joke going around that a Python team will finish a project before a
C++ team can decide which brace style to use...

------
thisisnotmyname
The lack of built-in regular expressions is a pain point for me.

------
petercooper
Consistency in class definitions (that is, not two "types" of class). Python's
packaging is less consistent. Oh, and far better community sites.

------
Zak
First class symbols are the big one, I think. Of course, we all know about
Python's brain-damaged function literals.

------
jrsims
I really like Python, but it doesn't have an equivalent to CPAN or RubyGems.

I'm actually quite puzzled by this.

~~~
tpherndon
Read up on setuptools and the Python Package Index, aka the Cheeseshop.
Setuptools hasn't yet been adopted as the one true packaging format by all
library creators, but it gaining acceptance.

~~~
jrsims
Ok, awesome. And that's the same story as RubyGems. I've noticed that Python
peeps are pretty big on "show me the code" anyway, but I think a lot of
untapped potential is lost by not having a dead-simple distribution mechanism,
as good as Python libs tend to be overall.

That's one thing I do like about Ruby; it wasn't always this way, but
RubyForge + GitHub (Oh, GitHub!) + RubyGems combine to make for a very fluid
feedback mechanism and make good use of The Cloud.

The result is that new libs get announced, distributed, tested, and improved
by rabid Rubyists rather... rapidly.

------
gaius
My experience is that the languages are similar in terms of features, but the
communities are very different and there isn't much overlap between them. Ruby
types tend to be younger, focussed on the web, probably employed as full-time
developers. Python types tend to be older and not employed as developers, but
write code as part of their main jobs. Python people often have experienced a
nightmare of unmaintainable Perl, that is why there is the insistence on there
being one right way to do everything (which is the exact opposite of what Perl
people believe). Ruby people (being younger and hence less experienced)
haven't, which is why they talk about expressiveness and do things like
monkey-patching. Neither group is "smarter" and neither language is "better".
The choice is a choice of what community you want to join, not a technical
one.

~~~
DocSavage
From my observation, the ruby community is heavily skewed by the recent influx
of Rails programmers, which is web dev and younger. Old-school ruby folks (the
guys who were ruby gurus when Rails was still an infant) have different
characteristics: older, less confrontational, veteran programmers, Matz-like.
A generalization for sure but my impression.

The python community has done significant development in science/math so they
have stronger libraries in those fields. Python has had an influx of Railsy
people due to Django and might get a shot in the arm from Google App Engine.

From a language perspective, I like the wealth of libraries for python. I like
that many reference/experimental applications on web stuff is in python. The
whitespace issue for me has disappeared and I'm actually leaning toward liking
it more than ruby's block delimiters. The template/erb issue can be diffused
by looking at HAML. (That's a cool way of incorporating pythonic indentation
to templates.) Unicode is solid in python.

Ruby is a better choice if you like to reshape the language into something
that could potentially look un-Ruby. It's possible I haven't gotten far enough
into python yet, but I can see why metaprogramming and DSLs are more prevalent
in ruby than python, and it's not just "one way" culture. (Ruby's optional
parentheses for method calls is an example of a language feature that fosters
DSL use.)

~~~
aristus
I have to agree. Ruby has incredible flexibility, but how it's been used by
"the kids" in things like Rails (and especially Rails extensions) makes my
skin crawl.

This also bugs me to no end: nil.to_i == 0, 0 evals true, but nil evals false.

Python's lack for me is anonymous functions. It's cumbersome to set up 40
slightly different named functions and a hash table (or some "factory pattern"
thing) to do the same job as 3-4 lines of Ruby. Symbols are nice too.

But for my personal work I choose Python for the libraries, cleanliness, and
performance.

~~~
DocSavage
What are you doing that can't be done with python's lambda functions?

~~~
raganwald
What are you doing with Python that can't be done with FORTRAN?

~~~
DocSavage
Running on Google's App Engine :)

Seriously, though, I'm not arguing python's anonymous functions are just as
good as ruby's. I'm curious about his particular situation where "3-4 lines of
Ruby" is all it takes.

~~~
eru
You could run FORTRAN on a virtual machine on Python.

------
mroman
I would love to read pg's thoughts on this question.

Actually, I would love to read more of pg's thoughts on Ruby, what I have read
of his thoughts on it has been brief yet highly positive.

------
pdubroy
Hype? ;-)

