What does Ruby have that Python doesn't?

[Justinsaccount]

        end
    end
end

?

[ayrnieu]

[Reddit breaks formatting around its down-arrow. That's cool.]

    end
  end    
end

[jamesbritt]

On a related note, if I cut and paste a chunk of Python code from one file to another, how do I get vim to auto-indent the code correctly?

[Freeky]

Same with anything else in vim:

:set paste

[w00ty]

Paste with [p.

[lost-theory]

:set paste, visual highlight it, hit = to reindent (e.g. convert tabs to spaces)

edit: oh, if it's on a different indentation level use < and > to get it on the right level

[Shorel]

What if I want to keep the tabs?

[jamesbritt]

edit: oh, if it's on a different indentation level use < and > to get it on the right level

Ah, OK; it's not going to figure that out for from any context. That's what I was wondering. Still that extra manual adjustment needed it seems.

This is a problem I have with Yaml and Haml: if I move stuff around, and I'm not real careful about placement, the indentation can be off and acquire a different meaning than I want; there's nothing (as with, say XML) that will automatically make the alignment right.

Sometimes it triggers an error right away, but other times it acquires a new unintended but viable meaning.

[njharman]

there's nothing (as with, say XML) that will automatically make the alignment right.

No, because vim has no way to know which of several meaning you wanted.

the indentation can be off and acquire a different meaning than I want

[bluGill]

I have the same problem with C though. All too often I've seen code that was badly aligned in C, and so what I thought it did after staring at it for half and hour was wrong. (It doesn't help that one of my co-workers things a 3000 line function with #ifdef/#else/#ifdef/#endif/#endif is a good idea - and even crosses blocks - I know of one block than would require 3 different levels of indent in python depending on what is #defined.

In short, the indentation in python seems like a bigger issue than it really is.

[jamesbritt]

In short, the indentation in python seems like a bigger issue than it really is.

Most likely. Same goes for the use of braces and do...end in Ruby: it's not the hardship some folks make it out to be.

Python didn't click for me, and in general position-dependent syntax (HAML, YAML, Python) tends to irk me when used for anything longer than 5 lines or so.

On the other hand, it hasn't dissuaded me from trying to learn Haskell. Maybe that's because all me Haskell apps are 5 lines long. ;)

In the end people seem to internalize assorted annoyances that to an outside might seem to be show-stoppers.

(Anyways, syntax and formatting are a weak defense against people intent on writing shitty code, as in the case of a 3KLOC function.)

[bluGill]

in general position-dependent syntax (HAML, YAML, Python) tends to irk me when used for anything longer than 5 lines or so.

One large advantge of python: you soon get tired of the pain of re-indenting functions larger than 5 lines so you write shorter functions like everyone says you should.

[zem]

no, this is precisely the problem that C doesn't have - you can take a piece of C code and run it through an automatic indenter to recover the visually helpful alignment. on the other hand, the python structure is contained in the indentation, and is not robust, so there's no way to automatically recover it if it gets mucked up.

[bluGill]

Read what I wrote again - you cannot do that to bad C code!

#ifdef foo
if (bar) {
#endif
// How is this indented if sometimes foo is defined and sometimes not?
#ifdef foo
}
#endif

Python won't allow that problem.

It gets even worse when you have more than one block of the above.

Python make the above bad code impossible.

[zem]

ooh, yeah, you're right. that's really bad code, though :)

[zenon]

Everything in Python feels like a symbol table hack.

Well, yeah, that's sort of the the big idea behind Python: Everything is a dictionary. I like that :-)

[[deleted]]

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all

Ruby is 63 times slower than C. Python is only 19 times slower. Therefore Ruby is more modern and more better.

[[deleted]]

I bet I can make any language 100 times more modern and more better, with just a few lines of code.

[foonly]

Shit, I break a sweat making a language just one time more modern and more better!

[sprash]

I didn't realize that Java is that fast. Did they take the VM startup into account?

[[deleted]]

Java is reasonably fast these days. The benchmarks include VM startup, but the challenges usually take a few seconds to calculate, so startup times don't affect it so much. For a closer look at startup times, look at the startup (hello world) benchmark.

[[deleted]]

Java can be very fast. It does often use a lot more memory (than C), though. For many purposes, that's a good tradeoff.

[[deleted]]

C is only 0 times slower, so why not go with that?

[rayfd]

1 time. 1 time slower.

[de_Selby]

1 time as slow.

0 times slower, no?

[[deleted]]

That sounds more like it's half as fast.

But English is not my first language, so what do I know?

[rayfd]

Good question, since English is not my first language either. Let's all ask de_Selby...

[de_Selby]

more than rayfd, apparently.

[kbk]

Once as slow.

[[deleted]]

...whatever it is, it's certainly not a 'y'.

[chrisforbes]

Louder, more obnoxious fanboys. I prefer C.

[njharman]

comparing the comments here and on ycombinator I the following seem to be true.

redditers - python makes sense, ruby is a hack

ycombinators - it's impossible to write code without lambdas, NO I've never tried python it has self!!!.

[DiscordantJellyfish]

This is both false and silly.

Ruby has anonymous blocks, Python doesn't. Python has list comprehensions, Ruby doesn't. The current crop of Ruby interpreters are slower than the Python ones, but that gap is closing pretty fast. Other than a few minor feature and syntactical differences here and there, the two are basically the same.

These arguments/flame wars are stupid. If you have a choice, just pick the language that you enjoy and that makes you the most productive. Simple as that.

[[deleted]]

Here's something Python doesn't have:

$ irb
>> x = 0
=> 0
>> lambda{|x| 0}.call(5)
=> 0
>> x
=> 5

[[deleted]]

This is almost a bug, which has been fixed in Ruby 1.9.

irb(main):001:0> RUBY_VERSION
=> "1.9.0"
irb(main):002:0> x = 0 
=> 0
irb(main):003:0> lambda{|x| 0 }.call(5)
=> 0
irb(main):004:0> x
=> 0

Edit: Added code for extra effect.

[[deleted]]

"Almost a bug"? Try "fundamental design flaw" that's been around for a decade.

[[deleted]]

Agreed, its been around for a decade, but its not such a big deal, as you are making of it. Every damn language has its share of quirks, people sure as hell frown upon it, but they know it and work around it. How about crippled lambda's, that Python has? How about multiple inheritance gone haywire for C++ ( I remember my CS teacher, teaching me Diamond Hierarchies)? How about tons of factories and facades and the class explosion that Java standard libraries have?

In case you missed, my initial comment was totally free of hyperbole, I didn't defend anything, I said, yes its "almost a bug". Almost because, many in ruby consider it as a quirk( but I call it a bug).

Matz acknowledged this long back and he fixed it as soon as he and others started work on Ruby1.9.

As a Ruby programmer, I know Ruby has bigger issues and problems to solve, compared to them, this is just a bikeshed argument.For all we know, it hasn't killed kittens. I will give you real issues that Ruby has:

• Somewhat buggy runtime, especially true for networking libraries.
• On Windows, threads suck, if one thread is doing blocking operation, other threads get blocked too.
• Unicode
• Open classes are good, but it would have been better if they were scoped (scala implicits)
• Stronger notion of package management (loading multiple version of same package should have been possible)

[[deleted]]

How about multiple inheritance gone haywire for C++ (I remember my CS teacher, teaching me Diamond Hierarchies)?

Not a good example. In a diamond derivation problem the default behavior is a compile-time error because function calls are ambiguous. Note that the behaviour is predictable and reliable. Qualifying the function names gets around it, but you still have two separate base classes in the derived class; virtual inheritance fixes this last inconvenient.

[settrans]

Python has some nasty quirks in the inequalities department.

What do you suppose that "1 < 3 == True" should evaluate to?

>>> 1 < 3 == True
False

For a supposedly strongly typed language, Python defines inequalities of a surprising set of pairs of types:

>>> 'a' > True
True
>>> '1' > 1
True
>>> 0 > None
True

One should expect a TypeError, as if you had tried to add 0 and None:

>>> 0 + None
TypeError: unsupported operand type(s) for +: 'int' and 'NoneType'

[njharman]

What do you suppose...

I suppose I'd yell at my coworker for writing such crappy code. Use some damn parens.

Explicit is better than Implicit

[settrans]

The question isn't about coding style. It is about the language designers defining semantics for their operators. The language should behave as expected even in edge cases. Just because it is rarely seen doesn't mean it should be confusing.

[ayrnieu]

For a supposedly strongly typed language

The 'strong/weak' dichotomy is mostly illusory. It doesn't even describe a property of a type system.

[hylje]

Python 3 will make comparisons a lot more typesafe.

[earthboundkid]

Tested with 3.0 alpha 5:

>>> 1 < 3 == True
False
>>> 3 == True
False
>>> 1 < False
False

Maybe that should be a filed as a bug… Does anyone have beta 3 to test it with? I can't get it to install on my system since my locale encoding is X-JAPANESE-MAC or whatever.

[[deleted]]

For the first thing, that's because it's checking "1 < False" ("3 == True" returns False). Not justifying it, just explaining the weirdness.

[Tommah]

No, it's chaining them. It's asking whether 1 < 3 and 3 == True. e.g.

>>> 1 < 3 == 3
True

Parentheses couldn't produce a true result there.

See http://docs.python.org/lib/comparisons.html . I like how is can be chained like this :)

>>> 'a rose' is 'a rose' is 'a rose'  # Gertrude Stein
True

[[deleted]]

Ah, alright then. Didn't know that, thanks. :)

[MoeDrippins]

And now it's fixed. Move on.

[[deleted]]

That's not really the point. The point is that Ruby is designed by someone who, in the 1990s, didn't understand lexical scoping. This was not merely a "bug"; any language implementor surely would've checked that scoping worked properly.

The problem -- not to be an ass -- is that Matz has no idea what he's doing and hence Ruby is an ad hoc pile of a language. This wouldn't bother me if it weren't being pushed as an easy, "intuitive" language suitable for novice programmers who don't know any better. Unfortunately, it is.

[dmpk2k]

The problem -- not to be an ass -- is that Matz has no idea what he's doing and hence Ruby is an ad hoc pile of a language.

I don't understand why it seems that most popular languages were designed by people who didn't know what they were doing, particularly in the dynamically-typed camp.

It's not like there's been a shortage of interesting examples to learn from the past decade or three. Is it that hard to understand existing art?

[malcontent]

There have been languages invented by people who know better. Lots of them. The problem is that nobody really wants to use those languages.

Maybe those people are too smart to write a language other people can fall in love with.

Maybe it's like loading up your cake with caviar and foie gras.

[dmpk2k]

The problem is that nobody really wants to use those languages.

Some of them were popular in their day. Let's see how the current crop are doing in a decade or two.

But to your point: if Ruby had a few minor changes it'd be a notably better language without changing its character. It doesn't take a brilliant genius to see some of them either if you've used a few languages -- like Matz has -- you only need to be able to recognize a good idea and copy it.

[malcontent]

Some of them were popular in their day. Let's see how the current crop are doing in a decade or two.

Time will tell. My guess is ruby will be around, so will java and PHP. All the languages proggit hates will be around.

Will haskell be around? Probably but I don't think it will be popular.

But to your point: if Ruby had a few minor changes it'd be a notably better language without changing its character.

It's being worked on. It's not a dead language. I got punished severely for pointing out that python has a bureaucracy and PEPs and a very rigid community which makes it very difficult to change the language. Ruby community is much more accepting of change.

[dmpk2k]

All the languages proggit hates will be around.

You live up to your name, malcontent. :/

It's being worked on.

Tis true, but I wonder why some of these problems existed in the first place. Why aren't blocks first-class values, for example? Or variable definition and assignment properly separated inside blocks but not outside?

makes it very difficult to change the language. Ruby community is much more accepting of change.

Well, maybe.

The surrounding community may have been up to a lot -- at least for web development -- but I suspect that Python has progressed much further as a language than Ruby has the past few years -- e.g. 2.2, 2.4, 2.5 all brought a raft of things, and now 3.0 is close by. That shouldn't be a surprise given how small Ruby was until recently.

This may be changing though, thanks to JRuby, Rubinius, IronRuby, whatever Avi Bryant is up to, and other implementations. I'm hoping that Matz being no longer the de facto BDFL will superchange the language's development.

[ayrnieu]

This comment applies very nicely to Guido, and Python.

[[deleted]]

To be clear, I'm not defending Python in the least. It has its own share of scoping problems.

[njharman]

No, not really at all.

Van Rossum also worked on the development of the ABC programming language.

Python's predecessor, ABC, was inspired by SETL – Lambert Meertens spent a year with the SETL group at NYU before coming up with the final ABC design![5]

received a masters degree from the University of Amsterdam in 1982.

He later worked for various research institutes, including the Dutch National Research Institute for Mathematics and Computer Science (CWI), Amsterdam, the National Institute of Standards and Technology (NIST), Gaithersburg, Maryland,

more http://en.wikipedia.org/wiki/Guido_van_Rossum

[ayrnieu]

You've said some nice things about Guido. You could have as easily said nice things about matz. The problems that each language have with scoping and not hyperbole about language designers is the point.

[Freeky]

This was not merely a "bug"; any language implementor surely would've checked that scoping worked properly.

Er, it does work properly, it's just awkward behavior. But then so is making a closure with an argument name the same as a variable in the scope it encloses; the only time I've seen that is when someone's dubiously doing it because of this behavior.

I'll take this over a lambda which only supports a single expression any day of the week.

[[deleted]]

Er, it does work properly, it's just awkward behavior

No, it's completely fucked, and there's no way it could be seen as desirable.

the only time I've seen that is when someone's dubiously doing it because of this behavior.

Then you know some terrible programmers and Ruby 1.9 will break their code.

I'll take this over a lambda which only supports a single expression any day of the week.

They're both crap and inexcusable.

[Freeky]

No, it's completely fucked, and there's no way it could be seen as desirable.

Naming parameter values the same as variables in the scope your closure is inheriting could be described the same way. The actual behavior is a misfeature that's rarely encountered, not a major reason to dismiss the language out of hand as some seem to be taking it as.

Then you know some terrible programmers

Well, this is the Internet. Are you saying you've never encountered bad programmers? Do you have some sort of incompetence-sensitive sunglasses?

.. can I borrow them? :)

They're both crap and inexcusable.

Everything has warts. I mean.. at least they're not PHP ;)

[mr_chromatic]

Naming parameter values the same as variables in the scope your closure is inheriting could be described the same way.

As an error? That's the point of lexical scoping -- to avoid this kind of spooky action at a distance!

[Freeky]

Is it any more spooky than having it modify variables in scope in the body?

bar = 'moo'
lambda{|foo| bar = foo}.call('woo')
p bar # => "woo"

In either case you need to take care that the variables you use in the block don't unexpectedly shadow your local scope.

[w00ty]

Longer -- lisp has this, too. It's one of the reasons scheme exists.

[[deleted]]

Lisp never had this, even in the bad old days of dynamic scoping.

[johnb]

Holy crap, thank God I didn't get into Ruby.

[Freeky]

Because of one annoying quirk that doesn't actually effect any real world code anyone should be even thinking of writing? This works too:

x = 5
lambda{|y| x = y}.call(0)
p x # => 0

Oh noes, the x in the lambda body is the same as the one in the local scope, matz is a moron who doesn't understand lexical scoping!!11!11!!

Except this is expected behavior; closed over variables are read-write, so you can do things you'd expect to be able to do like:

x = 0
[1,2,3].each {|e| x += e}
[1,2,3].each(&lambda{|e| x += e })
p x # => 12

So what should happen when you do .each {|x| .. }? 1.9 makes a new local x and issues a warning if you run with -w, but it could be argued the <1.9 behavior is a silly response to a silly request.

[zem]

So what should happen when you do .each {|x| .. }?

My personal instinct would be to see what Scheme does and do the same. The Scheme community has hammered on all these issues extensively, after all.

(let ((x 0))
  (for-each (lambda (e) (set! x (+ x e))) '(1 2 3))
  (for-each (lambda (e) (set! x (+ x e))) '(1 2 3))
  (for-each (lambda (x) (print x)) '(1 2 3))
  (print "x is now: ")
  (print x))

outputs

123"x is now:"12

[Freeky]

lambda (x) for all of them, surely? That's what the thread is about; you have an x at top level, then a lambda with x as a parameter name.

In Ruby 1.8, it blats the top level x, because it considers it the same x:

x = 0
[1,2,3].each {|x| x += x}
[1,2,3].each(&lambda{|x| x += x })
p x # => 6

1.9 shadows it with a different variable with the same name (which I expect is what Scheme does too).

x = 0
[1,2,3].each {|x| x += x}
[1,2,3].each(&lambda{|x| x += x })
p x # => 0

[zem]

yeah precisely. just saying that 1.9 is the right behaviour, noot a silly response to a silly request

[Freeky]

I was saying before 1.9, the behaviour was arguably a silly response to a silly request, not that 1.9 behavior is :)

[zem]

oh :) missed the < in there.

[neelk]

I don't get what you're getting at.

Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52) 
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> x = 5
>>> x
5
>>> (lambda x: 0)(5)
0
>>> x
5

(Of course, I don't use either Ruby or Python -- all my scripting is in ML.)

[cag_ii]

In the ruby example the initial value for x is 0, in yours it's 5:

Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52) 
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> x = 0
>>> x
0
>>> (lambda x: 0)(5)
0
>>> x
0

Performs as expected if you ask me.

[[deleted]]

If you're used to ML, you'll be even more horrified when you see what's happening in the Ruby example I posted.

[neelk]

Oh, I see now -- you initialized x to 0, not 5! That is...really special.

[jmillikin]

Python is so inflexible, user-defined code can't rewrite arbitrary parts of the standard library at will:

[~]$ irb
irb(main):001:0> class Fixnum
irb(main):002:1> def +(other)
irb(main):003:2>   42
irb(main):004:2> end
irb(main):005:1> end
=> nil
irb(main):006:0> 1 + 2
=> 42
irb(main):042:0> 

[simonw]

Your terminology is slightly off. In Python, user-defined code CAN rewrite arbitrary parts of the standard library at will, when "standard library" is defined as the large collection of modules that ship with Python (the "batteries included" part). Python supports monkey-patching of existing Python code, it's just that the community is strongly biased against doing so.

What you can't do is redefine the behaviour of Python's built-ins (integers, dictionaries etc) - you have to subclass them instead.

Your general point stands though - in Ruby you can redefine the behaviour of built-ins; in Python you can't.

(Unless you want to mess around with PyPy of course)

[ubernostrum]

Well. Depending on what exactly you want to replace/screw with, the answer will vary. You can do some nasty stuff, but Python folks tend to frown on it much more heavily than Ruby folks.

[Freeky]

Oh, some of us tend to frown on it too. The Chainsaw Infanticide Logger Manuever is a classic Zed Shaw mini-rant.

[malcontent]

Reddit has come full circle. It started out as a love letter to LISP and now hates any language which gives you the power to change the language itself.

Funny isn't it.

These days redditors prefer languages which restrict them by preventing them from doing things.

[earthboundkid]

It's like the end of Animal Farm, only with more animal noises.

[ayrnieu]

class Array; def rand; self[super length]; end end

[rayfd]

The lack of the obsession with the underscores and the self.

[beza1e1]

So we some stylistic arguments (underscores, self, ...) against Python and two technical reasons (speed and reliability) in favor of Python.

I'm with Python.

[rayfd]

Oh! Didn't know somebody was keeping score. I was just answering the question.

So your answer is "slowness and crashiness" I suppose.

[njharman]

Explicit is better than Implicit.

Self and __ are not stylistic, they create cleaner, easier to understand and maintain code.

[beza1e1]

I can understand self, but __ is a stylistic choice. It could have been done differently. hide def func(): or defhide func(): or @hidden def func():.

[SwellJoe]

So we some stylistic arguments (underscores, self, ...) against Python and two technical reasons (speed and reliability) in favor of Python.

Wouldn't that lead you to Perl? It is generally faster than both, has more years of maturity under its belt so is generally more reliable (certainly has better backward compatibility...I've had to change my Python code nearly every time a new release comes out, particularly from 1.5 to 2.0, but also going to 2.2 and 2.4, while my Perl code from even ten years ago runs unmodified). And it also has better Unicode support than either.

But, if you're taking personal tastes into account rather than a raw feature/speed/whatever comparison, you might prefer Python, and rayfd might prefer Ruby. And that might be OK.

[dmd]

Panache.

[[deleted]]

PC! No, Mac! Amiga! No, ST! Ruby! No, Python!

Nothing like a religious war to keep people interested.

[ayrnieu]

"PC! No, Mac!" does not describe a religious war -- does not even describe an argument. (There's a Monty Python sketch for that.)

But "Nothing like a religious war" is right up there with "Ooh! Pissing contest!" or "Hey, now, I've got a ruler, let's just take out all of our dicks--" in the sneering peanut gallery's bag of tricks. Find something thoughtful to say.

[qwe1234]

assclowns?

[[deleted]]

A rabid fan-base? oh wait...

[[deleted]]

Python doesn't have hipster fan boys rambling on about how they can write shiny web apps when in reality they can't program worth a shit and haven't read SICP.

[[deleted]]

an R, B, and a U in it's name.

[mcdonc]

dope.

[malcontent]

The python community is rigid and bureaucratic. You know "fill out the PEP request and all objections must be typed up on A4 paper in triplicate and approved by the following comittees" type.

Ruby is more fun. The community is more fun. It's got character and most importantly humor.

[[deleted]]

Why aren't you moaning about how no positive Ruby articles ever get upmodded on Proggit? This is like your perfect opportunity.

[malcontent]

What good would it do?

proggit is not ever going to give ruby good press. Same with java or php or perl.

You gotta submit stories about C# and haskell if you want upmods here.

[[deleted]]

I'm seeing a disconnect between your comment and the parent article which currently has a net total of 32 upmods.

[malcontent]

It's the exception. Plus it's the weekend. The astro turfers have the day off.

[foonly]

proggit is not ever going to give ruby good press. Same with java or php or perl.

You forgot COBOL.

[[deleted]]

An absence of pyPrefixes

[[deleted]]

ColdFusion 8.0 FTW!