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

Comments

Re:Former perl, python, java geek gone to Ruby

[MarkusQ]

I just don't like it when a language designer decides which ones he personally likes and includes them, without a possibility for users to create their own.

Agreed. I'm not saying ruby is perfect, just that I like it slightly more than python and a lot more than perl. Its syntax isn't as clean as, say postscript, smalltalk, or scheme, but it's much better than bash, c++ or vb. Maybe somewhere around common lisp?

My biggest gripes:

• Blocks are litteraly a bag hung on the side. Needlessly ugly and limiting.
• The typographic hungarian notation ($ for globals, capitals for constants, etc)
• The premptive binding of literals to built in classes.
• The perl compatibility frosting.

It's still my scripting language of choice though. -- MarkusQ

Re:Former perl, python, java geek gone to Ruby

[Merk]

Someone already mentioned blocks, which is one big difference. The other is the true OO-ness of the language.

irb(main):001:0> 1.type
=> Fixnum
irb(main):002:0> 1.upto(3) {|i| puts i}
1
2
3
=> 1
irb(main):003:0> class MoreThanArray < Array; def is_even?; 0 == length % 2; end; end
=> nil
irb(main):004:0> ma = MoreThanArray.new
=> []
irb(main):005:0> ma[0] = "hello"
=> "hello"
irb(main):006:0> ma.is_even?
=> false
irb(main):007:0> ma[1] = "booga"
=> "booga"
irb(main):008:0> ma.is_even?
=> true

AFAIK, Python doesn't let you subclass built-in types, and it certainly doesn't let you treat integers as objects. At first glance, Ruby does appear similar to python, but if you really look at the OO aspects of the language you'll see some huge differences.

As far as cryptic syntax... the only real similarities I've found between Perl and Ruby are the @ and $ symbols in front of variables. But in Perl @ is an array, and $ is a regular variable. In Ruby, @ is an instance variable of a class (accessible only within the class) and $ is a global variable. Ruby also keeps some of Perl's global variables, which allows for some cryptic looking syntax, but I rarely see or use them.

In summary though, I don't know Python or Ruby well enough to enumerate all the differences between them. I just find that nearly every program I want to write becomes much shorter and easier in Ruby than it was in Python.

Re:Former perl, python, java geek gone to Ruby

[MarkusQ]

*laugh*

I should have read your post before responding to __past__; I could have mostly said "see RevAaron's comment."

The main point on which I disagree with you is that method calls are actually a small part of C++ & perl syntax. Control structures, expressions, etc. are all distinct (and ad hoc), because the types they opperate on (booleans, integers, etc.) are not objects. Conversely, in ruby everything is an object, and (if you want to) you can skip the sugar and write code that only passes messages to objects. This isn't as obvious as it is in (say) smalltalk, but it's at least true in ruby, whereas it's not in c++ or perl.

-- MarkusQ

P.S. I just thought of two even better examples of (syntactically) clean languages: both forth and prolog have very clean basic syntax.

Re:Former perl, python, java geek gone to Ruby

[MarkusQ]

Yes, but it has *loads* less parentheses than scheme. :)

If they bother you too much, try writing a little pre-processor (you can do it in about 20 lines of lex/yacc or so) that takes code with sailent structure (python style indentation) and spits it out with the parens?

-- MarkusQ

That's not what we mean by clean, friend.

[Paradox]

I'm a big fan of Ruby and its clean syntax too, but I think MarkusQ (and subsequent repliers) mistake what that means. Ruby's syntax is clean in that there isn't a lot of stuff in the syntax just to define statements, expressions, lists and whatnot. C++ might be called a "dirty" syntax-or at least a "dirty-er" syntax.

A good example of this is the lack of need for semicolons at the end of each line. Ruby has semicolons for statement separators, but you only need to use them when there are multiple statements on one line. For example:

# No need for ;
puts "Hello World"
puts "Hi mom!"
# On one line, need ;
puts "Hello World" ; puts "Hi mom!"

Another example is that you don't have to use straight brackets to delimit arrays. You only must use them to clarify confusing situations.

myArray = "this", "that", "otherthing"
p myArray # outputs: ["one", "two", "three"]

It's important to differentiate this attribute from the flexibility of the syntax. Ruby allows you to use, or not use, certain pieces of its syntax to help you adjust to it. For instance, when calling sending a message to an object, you need not use parenthesis to delimit the message parameters. In general there is a synonym for most every syntactic feature. One is the common usage (like //) for regexps) and a more flexible, formal usage (like %r for regexps).

One might be tempted to say that is what's wrong with Perl, and to a degree that's true. Ruby however, keeps its core syntax quite small. The synonyms exist for a clear and obvious purpose. Perl seems to lack that purpose, instead citing TIMTOWTDI.

Re:Former perl, python, java geek gone to Ruby

[MarkusQ]

> * Blocks are litteraly a bag hung on the side. Needlessly ugly and limiting.

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.

I don't object to blocks being objects; I object to them being arbitrarily forced into a special-syntax-optional-singleton-parameter gheto. 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?

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

Hungarian notation (as the term is generaly used) encodes metadata into the variable name. Type, class, scope, storage class, etc. are all metadata. None of them should be duct-taped on to variable names (IMHO) because it obscures the intent of the code with a clutter of details about the means.

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.

Sure, and I can imagine cases where it would be handy to have a language require that every variable reference includes a comma seperated list of the line numbers of each reaching assignment. It sure would make it easy to spot uninitialized variables, for example. But in general, it would make the code harder to read and maintain.

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.

-- MarkusQ

Re:Former perl, python, java geek gone to Ruby

[ProfKyne]

AFAIK, Python doesn't let you subclass built-in types, and it certainly doesn't let you treat integers as objects.

>>> class IntegerSubclass(int):
... pass
>>> issubclass(IntegerSubclass, int)
1

In summary though, I don't know Python or Ruby well enough to enumerate all the differences between them. I just find that nearly every program I want to write becomes much shorter and easier in Ruby than it was in Python.

Doesn't sound like you've really spent enough time in Python to make that comparison.

Re:Thanks, IE. Repost that isn't ruined

[Fweeky]

Before someone whinges about named params:

myServer = Server.new(:socket => foo, :something => bar, :security_mode => 2, :logfile_path => "/var/logs/speciallogs/")

Which is syntax sugar for:

myServer = Server.new({:socket => foo, :something => bar, :security_mode => 2, :logfile_path => "/var/logs/speciallogs/"})

Since the { .. }'s can be missed at the end of the argument list.

The { .. }'s are, of course, syntax sugar for:

myServer = Server.new(Hash.new(:socket, foo, :something, bar, :security_mode, 2, :logfile_path, "/var/logs/speciallogs/"))

Ruby's got bit of a sweet tooth, but luckily they're not rotting away like, uhm, certain other languages I could name ;)

And yet another use...

[Luk Fugl]

One of the most useful instances of blocks I've found, and the one that truly converted me to Ruby, is registering them as callbacks.

I was working on a program while learning Ruby where we wanted to filter an incoming stream of events and filter them out to handlers. Some events needed to be dispatched to multiple handlers, others could be ignored.

The traditional approach would be to modify Dispatcher (any capitalized noun will be a class in my example here) and add some filtering logic each time a new filter needed to be added. But with procs (which are real closures, not just anonymous code blocks), I can do this:

class Dispatcher
include Singleton
def initialize
@callbacks = Array.new
end
def register(&callback)
@callbacks.push callback
end
def receive(event)
@callbacks.each.call(event)
end
end

str = $stdout
prefix = 'On STDOUT: '
Dispatcher.instance.register do |event|
str.puts prefix + event.to_s
end

str = $stderr
prefix = 'On STDERR: '
test = proc { |event| event.type == 'error'; }
Dispatcher.instance.register do |event|
return unless test.call(event)
str.puts prefix + event.to_s
end

# ... later
error = ErrorEvent.new('error text')
noterror = NotErrorEvent.new('other text')
Dispatcher.instance.receive(error)
Dispat cher.instance.receive(noterror)

# produces
# "On STDOUT: error text" on stdout
# "On STDERR: error text" on stderr
# "On STDOUT: other text" on stdout

Of course, this example is trivial, but the I'll admit I've since learned a way to do this in Perl, but it's much cleaner and all in all elegant the Ruby way.

Jacob Fugal

(ps. apparently <ecode> doesn't preserve my indentation, sorry...)

Re:Former perl, python, java geek gone to Ruby

[RevAaron]

Common Lisp is another story - I think it's fun to program in, and it can be very productive, but I'm not sure how clean I would say it is. :P It's a *huge* language, very interesting, and with a lot of functionality. It's a beautiful language, in its way- but so is perl (to me). :)

Sure, it's clean compared to C++, but not too much else! :P