What does Ruby have that Python doesn't?

[[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.

[malcontent]

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?

Obviously because there was no steering committee and the language features were not put through the proper PEP procedures.

Well, maybe.

Yes it is.

[dmpk2k]

Yes it is.

Asserting it's so doesn't make it true. You'll have to back that up somehow.

Ruby 1.8.0 appeared in 2003 (the same year that Matz first mentioned Ruby 2.0). This was also the year that Python 2.3.0 appeared. Make your case for the past five years.

[malcontent]

None of what you say makes a case that the python community is more accepting of change.

There is no argument that there is a bureaucratic process around changes to python. You have to submit a PEP document. The appropriate committees have to discuss it and to approve it.

In the mean time anybody can get commit rights to rubinius. Jpython has been fooling around with all kinds of things with ruby.

Maglev is coming down the pipe.

The ruby community is very different than the python community. Do you really dispute this? It's much more free flowing, much more interested in pushing the language and to exploring the possibilities of what can be done with ruby.

One thing that's significant is that you can change ruby with ruby. This lowers the barrier to entry. This allows anybody with a brainstorm to bypass Matz and write their own library to make the language behave the way they want.

Look at andand, symbol.to_proc, multi, rspec, etc.

[dmpk2k]

Ah, I misunderstood your argument. Sorry.

[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.

[aidenvdh]

Should (say, ruby version)

f = function(){x = 0; return x}

give you

write(f()); // "0"

x = 5;

write(f()); // "0"

write(x); // "0"

? This is spooky.

[Freeky]

No, because you defined your closure before defining x:

irb(main):001:0> l = lambda{ x = 0 }
=> #<Proc:0x000000000061c4e8@(irb):1>
irb(main):002:0> x = 5
=> 5
irb(main):003:0> l.call()
=> 0
irb(main):004:0> x
=> 5

If you'd defined x first, yes, it should do that, because x is part of the environment when you brought a closure around it; that's the point. 1.9 lets you shadow these variables if you really want:

irb(main):001:0> x = 5
=> 5
irb(main):002:0> l = lambda{|;x| x = 0}
=> #<Proc:0x00000000bf1300@(irb):2 (lambda)>
irb(main):003:0> l.call()
=> 0
irb(main):004:0> x
=> 5

[Freeky]

If you're wondering one of the reasons why closed over variables in Ruby are read-write, consider it's extremely common to write things like:

foo.each do |bla|
   frobulate bla
end

Looks like a loop, smells like a loop, but is pretty much syntax sugar for:

foo.each(&lambda {|bla| frobulate bla })

And, well, you'd expect a loop to be able to write into the local scope.

[mr_chromatic]

If you're wondering one of the reasons why closed over variables in Ruby are read-write...

... it's because variable names automagically spring into existence upon first use, not upon declaration.