Slashdot Mirror
Ruby 1.8.0 Released
waieitch writes "A long-waited new version of the scripting language, Ruby 1.8.0 has just been released. You can download from here, and the changelog is available. With many new libraries, say dRuby, ERB, REXML, this version is doubled by 1.6.8 in size."
Apparently the poster isn't a native English speaker. Anyway, all he meant was that the tarball is about twice as big now. This is almost entirely due to the inclusion of more libs, not an increase in size of the Ruby core.
Here's the link to the changelog.
DNA is the ultimate spaghetti code.
Here's a comparison of Ruby and Python.
The Army reading list
If I'm not mistaken, Ruby is the first language to include built-in support for YAML!
Thanks to Matz for such a great language!
Perl is faster - no denying it. But then text parsing is Perl's forte and I'd be surprised to see any language beat Perl in that arena.
:) Anyway, it really boils down to whether you're willing to trade a little speed for a cleaner overall language. My advice is to at least give it a try.
:)
How much faster really depends on what you're doing, ranging from as little as 10% faster to as much as twice as fast (in my own benchmarks at least). But then as many Perl folks used to be fond of saying, "If you need speed...use C".
On that note, you'll find writing C extensions a helleva lot easier than Perl.
BTW, I should mention that I also used to be a die hard Perl fan....until I found Ruby.
I thought that code blocks were a pretty lame excuse for proper functions-as-data, so I'm a little bit surprised to see them mentioned as a great feature. Did I miss something?
You did.
Code blocks are probably one of the most important features of Ruby that differentiates it from Python.
From what I understand, code blocks are basically anonymous functions that the method they are passed to can only invoke with yield, right?
wrong.
Or is it possible to treat them as any other parameter, i.e. store them, pass them further around, take more than one etc?
Yes. Yes. Yes. Yes (well, that last one is a qualified yes, if I understand your question correctly: you have to convert them to Proc objects before you can pass more than one of them to another method due to the fact that the '&' block delimiter in the method's parameter list can only be on the last parameter - it's not a big limitation).
At first glance, code blocks don't seem that interesting, cool or useful, however, I was able to create a domain-specific hardware description language using them without the need to create any parser for that langauge. It was written in pure Ruby, but to the user it looks like another language in it's own right.
So I could do things like (if you're familiar with VHDL this should look familiar):
process(clk,rst) {
if clk.event and clk == '1'
counter.assign counter + 1
elsif rst == '1'
#do resest:
counter.assign 0
end
}
#
It's all written in pure Ruby. The part between the '{' and '}' is a code block that's being passed to the process method which will execute the block whenever the value of clk or rst changes. So essentially, code blocks allowed me to make Ruby look a lot like VHDL. It looks very natural. AFAIK, this sort of thing is not (easily) doable in Python.
Can you please elaborate on what features Ruby has that Python doesn't?
Two features that come to mind immediately:
1) continuations - Python doesn't have'em. While this is a fairly obscure and difficult to understand feature, I've found it to be vary valuable in a couple of instances where without them I would have had to write a lot more code to get the job done.
2) code blocks - at first they seem trivial, but after you start using them and thinking in terms of passing code blocks around you end up using them a lot. They tend to make your code look very natural (not sure how else to explain it, they're just cool).
I suspect there are other differentiating features as well, but these are the two that come to mind immediately and Python's lack of these two features tipped the scales in favor of Ruby for me.
Oh, I suppose I can add an anti-feature that also tipped the scales in favor of Ruby for me:
Ruby doesn't consider indentation as syntax - I know a lot of Pythonistas seem to like indentation as syntax, but I never got to like it... for example, if I wanted to copy&paste some section of code into another section and they were at different levels of syntax... well, it could just get messy. I don't need those kinds of hassels.
> * Blocks are litteraly a bag hung on the side. Needlessly ugly and limiting.
/^a.*/ and 1..10 for example, but unlike in Perl these are real objects and first class citizens in Ruby.
Why do you feel they are ugly? Ok, they are not real functions like scheme has them, but Ruby wants to be an object oriented language, so it's ok that they are (can be transformed to) objects. Ruby is just consistent in not having any functions but only methods, so you have to use Proc#call(x) or Proc#[x] to call a procedure with arguments.
They are real lexical closures, too, which wasn't mentioned in any thread before:
def make_counter
x = 0
lambda do x += 1 end
end
c1, c2 = make_counter, make_counter
c1.call # => 1
c1.call # => 2
c2.call # => 1
c1.call # => 3
c2.call # => 2
> * The typographic hungarian notation ($ for globals, capitals for constants, etc)
Hungarian notation encodes the type of a variable into the variable name. In Ruby the sigils are used to show the scope of the variables. You can see at one glance that @@foo is class variable, @bar is an instance variable and $baz is a global variable. I found this to be very useful while refactoring code.
> * The premptive binding of literals to built in classes.
In the case of small integers this is more time&space efficient and that's the price you have to pay.
> * The perl compatibility frosting.
There isn't really much left of perl compatibility and lots of perl's "features" are about to be deprecated. In general they aren't used very often by Ruby programmers. It's true that a lot of stuff looks like Perl,
> It's still my scripting language of choice though.
Yeah, all scripting languages suck, Ruby just sucks less. *g*
Don't forget some of the other unique uses of blocks, that make them very, very powerful.
They can be used in unique ways that are pretty darn useful. For instance, you can use them to create configuration blocks for objects, without cluttering the constructor.
A constructor aware of this can use this block to configure the object in ways that normally would require dozens of different constructors, with a relatively unambiguous syntax. Even better, defining those set functions for the configuration block also defines them as instance variables. 2 foe the price of one!With a little thought and use of Ruby's excellent security model, it's possible to even just dump a file into that block, and use the file as the configuration block!
Slashdot. It's Not For Common Sense
Python doesn't let you subclass built-in types, and it certainly doesn't let you treat integers as objects.
This is no longer true. As of Python 2.2, I'm pretty sure that both of these
complaints have been addressed (the first one for sure).
*sigh* back to work...
Why can't I define a method that takes two or more blocks (e.g. if/then/else) with the same syntax I use for methods that take a single block? Why can't I introspect the structure of a block? Why the duality with Proc objects? In short, why aren't blocks first class objects?
To clarify this first: It's always possible to create multiple Proc objects with Proc.new, lambda or proc and pass them to a method.
There are two reasons why there are blocks AND Proc objects:
It would perhaps be possible to have something like that:
But there is an ambiguity because the first block could also be a hash constructor. I am not sure if it would be possible to solve that problem by changing the parser. You could limit yourself to use only doBTW: The if/then/else is not a method call and the selectors consist only of a single word in Ruby unlike in Smalltalk. So it would require a big change to the language and the interpreter if blocks should be used there.
Introspection of blocks is a good idea. Perhaps this will be possible if the new VM for Ruby 2.0, called Rite, is implemented. AFAIK it also should be possible to change code in the parse tree on the fly at arbitrary places then.
More to the point, in ruby I'd like to be able to change the scope or storage class of an object reference without having to rename it.
This is clearly a tradeoff. You can choose between having to look up the variables everytime you want to know their scope or between seeing it easily and change every variable if you want to extract a method. I think to choose the latter is a good choice for a language where you don't usually program in a code browser.
Matz held a talk on his intentions at OSCON (and it's fun to read) named
The Power and Philosophy of Ruby or How to create Babel-17.
Ruby is a cool language, but someone has to break down and document it. There is quite a bit of not-quite-current documentation, including a great online version of Programming Ruby , but the official library reference is for 1.6 and the language reference is for 1.4. The lack of current documentation for 1.8 raises doubts about the consistency of the language's behavior, especially its more Perlish, do-what-I-mean features.
You know, reading over the the information available for Perl 6, I get the idea that a lot of the improvements intended for Perl 6 were actually stolen from Ruby. As much as I love Perl, the OO implementation is a bolted-on, pain-in-the-ass kludge. Ruby's is an integral part of the language, and Ruby is a very nice language.