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

Best. Clause. Evar.

[gazbo]

this version is doubled by 1.6.8 in size

No more text.

math

[Anonymous Coward]

this version is doubled by 1.6.8 in size.

What?

Re:math

[Anonymous Coward]

It means this version is 1.6.8 times larger than the last one.

Re:math

[PizzaFace]

It means all your base are belong to matz.

Hmmm...

[Anonymous Coward]

It seems to be much more mature than some other language released recently... Well done, folks! It looks like the rip-off can certainly be better than the original... err... total-multi-rip-off. Yeah.

Re:Hmmm...

[Guido von Guido]

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.

Former perl, python, java geek gone to Ruby

[Fished]

For what it's worth, I've been using ruby for about six months, and am totally hooked. It is easily the best language I've ever used. Things that are idiosyncratic and difficult in other languages just flow in ruby. There are also many features to facilitate the way you actually *use* objects (e.g. to do object attributes, all you have to do is add "attr_writer attribute1, attribute2, attribute3" and "attr_reader attribute1, attribute2, attribute3") to the class defs. No more endless get and set functions all of which are more or less identical!

This language is definitely worth a look. It's not just a python knock-off, as many have supposed -- it offers features python doesn't.

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

[Dan Ost]

Can you please elaborate on what features Ruby has that Python doesn't?

I looked at Ruby a year or so ago and determined that it had the same
conceptual structure as Python, but the cryptic syntax of perl. Perhaps
my evaulation was too simplistic.

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

[MarkusQ]

it had the same conceptual structure as Python, but the cryptic syntax of perl

I'm not sure what language you looked at, but it doesn't sound like ruby.

• Ruby is a deeply object oriented in the tradition of smalltalk; python is a superfically object oriented language more in the tradition of C++ or object pascal. Until recently, for example, you could not derive your own classes from the built in classes.
• The basic syntax of ruby is very clean (a fact which is somewhat obscured by the "syntactic sugar" provided for some commonly used features (such as operators) and the provision of aliases for some global objects that are intended to ease the transition from perl). The basic syntax is:

  method_call ::= object.method_name arg1,arg2,...argn

  where object, method_name, and the arguments can all objects and can be given by named constants, literals, variables, or expressions (method calls). The only thing I really miss from python is the indentation (or rather, not having to explicitly delimit blocks, since I indent that way even when I don't have to).

-- MarkusQ

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

[tigersha]

The major improvement in Ruby over Python and C++ and most OO languages (but not Smalltalk) is the inclusion of code blocks that may be passed in as a parameter to a method and its widespread use throughout the libraries.

For a simple example, look at this:

x = [1,2,3,4]

x.each do |e|
puts e
done

This is NOT syntactic sugar. The list class has a each method that takes a piece of code as an argument and executes it for each element in the list. This can do the same as generators now coming into the new Python and is very similar to higher-order functions in functional languages.
Basically the do...done part is a parameter (albeit a special one, a method may only have one).

It is difficult and syntactiucally tricky to do this in most OO languages and trivial to add an each method (or whatever you want to call it) to your own classes. It is also extremely powerful way of doing many thing which requires a lot of messiness in other languages.

This high-erorder code blocks now allow you to really do the everything-is-anobject thing because you MUST have code blocks to implement control structures such as if or while as an object. It is also very pervasively used in all collections and for instance in REXML where you can say

x = some XML...

x.each( xpath expression ) do |element| ...
done

Another example

String.each_regexp( regexp ) do ... done

Does the code for each place where the regexp was found in the string. Same sort of thing can be done for databases and so forth.

Ruby also has things like mix-in classes which are usually dissed by OO theoreticians but turn out to be very useful. Mix-in classes were pioneered by some dialect of LISP and are a form of restricted multiple inheritance,. A class can inherit methods from other modules but not instance variables (except for its parent class). This allows you to this (this is pseudocode)

myclass inherits Ord
implement = and other operators in terms of and = (which are supplied by your class). And now your class implements all of these methods. This is again tricky to implement in traditional top-down inheritance trees. Think of Java's interface system, but with default implementations.

This is used to great effect in the collections to implement many things in terms of some primitve operators.

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

[__past__]

The major improvement in Ruby over Python and C++ and most OO languages (but not Smalltalk) is the inclusion of code blocks that may be passed in as a parameter to a method

From what I understand, code blocks are basically anonymous functions that the method they are passed to can only invoke with yield, right? Or is it possible to treat them as any other parameter, i.e. store them, pass them further around, take more than one etc?

When I looked at Ruby (not in much detail yet), 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?

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

[__past__]

I have to disagree about the clean syntax. For example, a method call is not simply object.method arg1, arg2, ..., it can also be object.method(arg1, arg2, ...), blocks can be do ... end or { ... }. You mention the syntactic sugar yourself - I can't see how that can be separated from the "basic syntax". All in all, Rubys syntax looks quite eclectic to me. Of course, it's still better than a lot of other languages.

Mind you, I don't have any problem with alternative ways to write stuff, or with shortcuts. 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. A language syntax should either be consistent or extensible (or both).

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

[quandrum]

I admit only a superficial knowledge of ruby, but I believe what you are talking about are Proc objects. You can store blocks of code, pass them around, execute them, do anything you could do with any other object. Is this what you mean by "functions-as-data"?

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

[RevAaron]

The basic syntax of ruby is very clean (a fact which is somewhat obscured by the "syntactic sugar" provided for some commonly used features (such as operators) and the provision of aliases for some global objects that are intended to ease the transition from perl). The basic syntax is:

method_call ::= object.method_name arg1,arg2,...argn

Along the same line, you could just as easily say that C++'s basic syntax is:

method_call ::= object.method_name(arg1, arg2,...argn)

and perl's:

method_call ::= object->method_name(arg1, arg2,...argn)

So C++ and Perl must be languages with simple, elegant and clean syntax, right? The method call syntax doesn't mean a thing. (well, if the language was particularily ugly it would- like some OO Cobol implementations)

Ruby has substantially less syntax than Perl and C++, that much is true and pretty commonly known. However, IMHO, Ruby has a bit much syntax, compared to languages like Smalltalk or Scheme. Smalltalk is a language which manages to be expressive, but without the amount of syntax that Ruby has.

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

[Luk Fugl]

Ruby has substantially less syntax than Perl and C++, that much is true and pretty commonly known. However, IMHO, Ruby has a bit much syntax, compared to languages like Smalltalk or Scheme.

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

Jacob Fugal

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

[drlock]

I also have a question. I am a die hard Perl fan. I like Perl, because it is fast, flexible, and powerful. The only thing that really irritates me about Perl is its lack of descent OO.

From all I have read about Ruby, it is flexible and clearly OO, but what about speed. Most of my Perl scripts are for text manipulation. I have seen some benchmarks where Perl has beaten out compiled languages in text manipulation. Where does Ruby fall in the speed spectrum? I did some searching on Google, but the only benchmarks I could find were old or very limited.

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

[tcopeland]

Here's a comparison of Ruby and Python.

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

[addaon]

While you do mention that this is not an advantage over Smalltalk, it should be emphasized how unexcited smalltalkers will be by the reinvention of internal iterators.

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

[Luk Fugl]

From what I understand, code blocks are basically anonymous functions that the method they are passed to can only invoke with yield, right? Or is it possible to treat them as any other parameter, i.e. store them, pass them further around, take more than one etc?

When I looked at Ruby (not in much detail yet), I thought that code blocks were a pretty lame excuse for proper functions-as-data

Ruby is a completely first-class language, as in scheme, smalltalk, et al. In other words, anything can be passed around and modified as an object -- methods, anonymous procs and even classes themselves.

It's true that the code blocks mentioned by my grandparent are limited, as the poster said, but ruby also provides the Proc object (mentioned by my sibling).

But even more exciting than anonymous procs (first class methods to you CS theoreticians) are classes as objects. If I want to, I can provide a class name -- which is really just a handle to an object representing that class -- as an argument to a function call. I can modify that class on the fly, adding or redefining methods. It's true that this extreme power requires extreme care, but IMO it's a verynice feature to have available and used correctly can produce very elegant and readable (and correct!) code.

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

[Anonymous Coward]

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.

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. :) 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.

BTW, I should mention that I also used to be a die hard Perl fan....until I found Ruby. :)

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

[Colonel Panic]

From all I have read about Ruby, it is flexible and clearly OO, but what about speed.

I'm a former Perl programmer myself and my reason for moving to Ruby as my primary development language a couple of years ago was Ruby's great OO features. I tried to like doing OO Perl, I really did, but it hurt too much. I tried to like Python's indention-as-syntax, but that hurt too. But Ruby was just right.

I recently spoke with a developer who is doing a lot of OO Perl (he'd like to be doing a lot of Ruby, but there's too much legacy Perl code where he works.). He told me that he had done some comparisons between OO-Perl and Ruby - Ruby comes out faster apparently because of the overhead that is incurred when you do OO-Perl (method dispatch issues, I suspect).

Of course this is comparing OO-style-Perl with Ruby. Non-OO-style Perl will be faster than Ruby in general.

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

[Colonel Panic]

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.

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

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

[Merk]

From resolv.rb in 1.6.8:

def each_name(address, &proc)
__lazy_initialize
__if @addr2name.include?(address)
____@addr2name[address].each(&proc)
__end
end

The &proc means to convert the block passed to the "each" function to a proc object and assign it to the variable proc. It is then passed down to the next "each" function in turn.

Its treatment of "functions as data" isn't quite as complete as something like Lisp, but Ruby is a language that programmers tend to rave about, not CS theorists. I think the main thing people like about blocks is that they "just work", however they're implemented internally, so people like them.

Btw, Ruby also has method objects which have a .call method, so you can pass those around too.

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

[dbday]

Or even more amazing to me, you can cut out the MoreThanArray subclass and extend the Array class directly:

irb(main):002:0> class Array; def is_even?; 0 == length % 2; end; end
nil
irb(main):003:0> [1,2,3,4].is_even?
true
irb(main):004:0> [1,2,3].is_even?
false

You can even extend instances of classes, rather than the classes themselves:

irb(main):001:0> x=[1,2,3,4]
[1, 2, 3, 4]
irb(main):002:0> x.is_even?
NameError: undefined method `is_even?' for [1, 2, 3, 4]:Array
from (irb):2
irb(main):003:0> def x.is_even?; 0 == length % 2; end
nil
irb(main):004:0> x.is_even?
true
irb(main):005:0> x.pop
4
irb(main):006:0> x.is_even?
false

In this last example, only the Array instance assigned to x has the is_even? method. Other array instances are unaffected.

This really tickles me for some reason. One of the many reasons to love Ruby. It also makes me want to go back and investigate Smalltalk again.

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

[RevAaron]

:)

Indeed- many other languages have tons of syntax past message sending. Incidentally, the syntax I think isn't needed in Ruby doesn't have much to do directly with message sending/method invocation.

Forth and Prolog are two other good examples. I should start using those instead of mentioning Scheme or Lisp. Lisp is a very clean and elegant language, but too many people just make a bad joke about parens being too confusing. Now there's a language pretty much all of the syntax can be summarized in:

function_call ::= (function_name arg1 arg2 ... argn)

Anywho, you're right.

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

[Anonymous Coward]

While you mention how unexcited smalltalkers will be by the reinvention of internal iterators, it should be emphasized how unexcited programmers of every other language will be at yet another smalltalk programmer pining over smalltalk.

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

[Anonymous Coward]

Could this be done on the fly in Emacs? One buffer with parentheses and one without....

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

[RevAaron]

It's kind of funny- McCarthy didn't intend Lisp to keep the ultra-simple paren-based syntax, but to add an algol-ish syntax down the line. Mmmm, parse tree! :)

Also, in the case you anti-parensers don't actually have any experience programming (which is often the case), you can get pre-made packages for a number of Scheme and other Lisp implementations which allow you to use C- or Python-like syntax. There is one for KSM, , and python/haskell/C syntaxes for Scheme, among others.

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

[xteddy]

> * 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. 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, /^a.*/ and 1..10 for example, but unlike in Perl these are real objects and first class citizens in Ruby.

> It's still my scripting language of choice though.

Yeah, all scripting languages suck, Ruby just sucks less. *g*

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

[Merk]

Yeah, cool ain't it? I knew about these other ways but I guess I was stuck on the "Python doesn't let you subclass built-in types" idea. Of course, I'm sure it doesn't let you extend them or modify instances of them either.

That's a pretty funny comment though: You love Ruby so much it makes you want to learn Smalltalk! ;)

As for me, I looked at Smalltalk, hated the syntax, and haven't really felt the interest to go back again.

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

[Dan Ost]

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

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

[MarkusQ]

Lisp is a very clean and elegant language

I used to think that, until I had to do some serious digging through X3J13.

IMHO, common lisp isn't all that clean (unless you are comparing it to something like C).

-- 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:Former perl, python, java geek gone to Ruby

[Merk]

Hrm, interesting. After seeing this I went to the Python home page and found a document on this subject. After initially being overwhelmed with underscores, I tried to understand what was going on. It talked a lot about subclassing things like dictionaries, but I couldn't find anything about subclassing int and such.

Anyhow, I then fired up Python and said dir(1) and it gave me a list of methods. I then tried 1.__add__(2), and it didn't like it. Do I have the syntax wrong? If I do something equivalent in Ruby (1.methods, 1.+(2)) it works like I expect. I admit, I know Ruby much better than Python though so maybe it's just as easy in Python. Is there an easy way to do the equivalent of this in Python?

irb(main):026:0> class Fixnum; def distance_from_42; (self - 42).abs; end; end
=> nil
irb(main):027:0> 3.distance_from_42
=> 39
irb(main):028:0> 43.distance_from_42
=> 1

Anyhow, it's nice to see that Python is slowly becoming more Ruby-like. ;)

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

[Merk]

I spent about 2 months total on Python before I found Ruby and abandoned Python. Ruby was just much easier right from the start.

I admit that there are languages that have really cool features that Ruby lacks (like Smalltalk, Lisp, ...) but I just don't find them easy to use. Python seems to overwhelm me with underscores, and needless use of "self" in method definitions. I personally find Ruby easier to read and to write.

It looks like Python has changed a lot since the last version I used (2.0 I think). If I didn't have Ruby, I'd consider looking at it again, but why now? I have yet to hear of features I want to use that Python has that are lacking in Ruby.

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

[xteddy]

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:

1. To use a block it's not necessary to create an object and that's good for the performance, e. g. if you have to iterate very often over some collection.
2. Blocks are used for iterators and control structures, so Matz wanted them to look like those already did.

It would perhaps be possible to have something like that:

foo { ... } { ... }

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 do ... end with multiple blocks but I thinks that it's better not to have multiple do ... end blocks in one method call.

BTW: 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.

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

[Nucleon500]

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

I think the idea of blocks is wonderful, but the syntax and special handling of blocks is ugly. Since a block can be converted to a Proc, why not just make { |args| body } be a literal for a Proc object, which would have no special meaning or limits in an argument list.

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

[baka_boy]

Code blocks are actually just convenient syntactic sugar for anonymous functions for common uses like iteration, filtering, and callbacks. You still have the option of preceeding the block with a 'proc' or 'lambda' call, to turn it into a full-fledged, 'callable' code object, or of using the 'obj.method(:name)' to explicitly capture (instead of call) an object method, and then pass it around, store it, etc.

I'm surprised no one's mentioned the most significant difference (IMHO, anyway) between Ruby and Perl/Python/Tcl/Lua/etc.: first-class continuations. While most people will probably never touch them, the fact that they're there means that you can add your own call/return or exception-handling operators to the language.

Sure, you don't have macros, like in Lisp/Scheme environments, but you do have extremely flexible string handling, the ability to execure eval in the instance, class, or module level of any term you can name, and the convenience of method invocation being *the* standard syntax in the language, so that something like 'typed_attr :name => String' looks quite natural, and can evaluate to an arbitrary code insertion or update.

Really, the core semantics of Ruby are basically Smalltalk, with richer meta-object features and a much more POSIX-like standard library, but without the persistent heap and standard MVC GUI library. Mix in a bit of Scheme for keywords like 'call_cc' and 'lambda', and then stir in a bit of Perl for regexp and flexible 'if' and 'unless' placement, and you've got a very unique and flexible language.

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

[Nucleon500]

I personally can't wait until Ruby, Perl, and Python all compile to Parrot, which will hopefully be fast, have native threads, rich libraries, and a good C interface. Hopefully in the future, choosing a language will largely be an issue of personal preference for syntax. Thanks, Perl6!

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

[MarkusQ]

Mostly agree, so just responding to selected points:

To use a block it's not necessary to create an object and that's good for the performance, e. g. if you have to iterate very often over some collection.

I suspect that an iterator could reuse the same block without breaking the semantics, but in any case I'm not strongly motivated by perfomance in this context.

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.

Easy. Hashes have "=>"; blocks don't. :)

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.

I suspect my design/coding style leads to less concern with looking up the scope or storage class of variables than some other people's styles do. At least, I hear other people worring about it much more than I ever find myself worring about it.

One way to describe my style: I wear two hats. When I have the "tool maker" hat on, I know all about the scope, etc. because that's what I'm working on. I start from the metadata and work out. When I have the "tool user" hat on, I don't care about things like that, because I'm using the tool and not worrying about how it works inside.

-- MarkusQ

P.S. There are a lot of different thinking-styles out there. I worked in one shop where the style was to initial everything (e.g. identifiers of the form MQR.____) "to avoid name conflicts" and "so you always know who to talk to if it's broken"!

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

[MarkusQ]

Yes! That would solve 95% of my objections (and I'm fighting the urge to bring up the source to see how hard it would be). { || ... } already works for the case you don't need / want args.

-- MarkusQ

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

[SilentStrike]

I don't know how to add a method to an existing class as it seems you are doing in your code. But you can certainly subclass the builtins. Why do you need the parens around the int when it's used like a class in python? I don't know.

>>> (1).__add__(2)
3

>>> class FixNum(int):
... def dist_from_42(self):
... return abs(self-42)
...
>>> b = FixNum(2)
>>> b.dist_from_42()
40

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

[xteddy]

I suspect that an iterator could reuse the same block without breaking the semantics, but in any case I'm not strongly motivated by perfomance in this context.

I'm not sure: a Proc object is a closure and some memory most be allocated for the environment. In a block it's easy because the environment is always the current environment.

Easy. Hashes have "=>"; blocks don't. :)

Not necasserily, {:a,1,:b,2} is also possible and blocks and hashes could also include hashes. One has really to look into the parser source to find out if that's so easy. And then it's necessary to convince Matz which isn't easy either (and this is a good thing I'd say). I think Perl has grown to be such an ugly beast because too much strange, inconsistent and unecessary syntax has been included. I'm not too optimistic that Perl6 does a better job here.

I worked in one shop where the style was to initial everything (e.g. identifiers of the form MQR.____) "to avoid name conflicts" and "so you always know who to talk to if it's broken"!

LOL! That's code ownership! And I suppose people still were cursing programmers that have left the company several years ago.

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

[Merk]

Interesting. The Ruby syntax sure looks cleaner to me though. Fewer underscores and parentheses to worry about. =) I also like that "abs" is a Fixnum method in Ruby, whereas in Python it appears to be a top-level function.

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

[SilentStrike]

abs also works on floats though, so it makes sense for it to be more than just a member of the int class. I guess Fixnum and whatever represents floating point numbers have a common base class with abs?

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

[MarkusQ]

I suspect that an iterator could reuse the same block without breaking the semantics,...

I'm not sure: a Proc object is a closure and some memory most be allocated for the environment. In a block it's easy because the environment is always the current environment.

Hmm. I would think (hope?) that it would be possible to make a Proc which "shared" the current environment in a way that was semantically equivalent to a block. But I haven't looked into it.

Easy. Hashes have "=>"; blocks don't. :)

Not necasserily, {:a,1,:b,2} is also possible...

Caught me (that was the reason for the ":)"). Personally, I'd prohibit the paired list form, but that's a personal bias. Someone else (in a nearby post) has suggested using pipe-as-the-first-character-after-open-brace as the signature for a Proc literal. Seems to me that would work & be dead easy (remember, I'm not as worried about performance as some people, so I'd be willing to loose blocks per se in favour of a more uniform system with just Procs).

I worked in one shop where the style was to initial everything (e.g. identifiers of the form MQR.____) "to avoid name conflicts" and "so you always know who to talk to if it's broken"!

LOL! That's code ownership! And I suppose people still were cursing programmers that have left the company several years ago.

There was a mythical programer named Franklin Ulysses Krammer (IIRC) that seemed to get credit for all the really bad kludges. It also broke down rather badly when someone had to modify someone else's code.

-- MarkusQ

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

[Merk]

Yup, Numeric.

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

[scrytch]

It's kind of funny- McCarthy didn't intend Lisp to keep the ultra-simple paren-based syntax, but to add an algol-ish syntax down the line.

Initially. Once macros came around, there was nothing like it in programming-land, and when you notice how many program structures you can implement with macros, there's still nothing quite like it, except perhaps for stuff like OpenC++ and camlp4, both of which have their *own* nasty syntax that doesn't look like anything else... Sexps became a feature very early on.

That said tho, it is a bit of a shame that there wasn't also a line-based alternate structuring convention and operator set that could elide most of the unnecessary parens. Good enough for haskell (layout rule and $ operator) after all.

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

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

[tigersha]

Nor are us Haskell programmer impressed by the reinvention of higher-order functions. However, to see them used in a mainstreamish language IS exciting and should be for you Smalltalkers too. The ideas of Smalltalk and Haskell are finally penetrating the mainstream. Yipee for that.

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

[Xlucid]

True - but I am excited that there is a language that I can leap straight to from Smalltalk, without feeling I'm losing significant amounts of the niceness of Smalltalk.

Plus, I get all the regexp power of Perl, and a substantial part of the Windows-ness of Smalltalk MT.

Remember, Dave Thomas (the PragmaticProgrammer who co-wrote the first English-language Ruby book, and who helps promote Ruby to the English speaking world) is a Smalltalker.

Leaping back and forth between Ruby and Smalltalk is, IMO, far more straightforward than the back and forth from Smalltalk to Ruby's obvious rivals.

That said, I'm still humming and hawing between Ruby and Smalltalk MT for my Next Big Thingtm

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

[pkhuong]

Only because the standard also defines tons of library. It still is lisp, where the language can be defined with a half-dozen functions. It's just that the half-million other function that MIGHT be needed are also defined by the standard. :D

Gotta love committees, no?

Re:Best. Clause. Evar.

[Anonymous Coward]

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.

Re:Best. Clause. Evar.

[Captain Large Face]

I found that amusing as well. What the hell is wrong with "is twice the size of 1.6.8?"

correct link

[oever]

Here's the link to the changelog.

Re:correct link

[tcopeland]

And a mirror on RubyForge.

Re:Best. Clause. Evar.

[Anonymous Coward]

Not everyone here is ... er ... Welsh, you insensitive clod! ;) Check out his posting history -- he's probably not a native English speaker. Still, his English is a lot better than Taco's.

Includes YAML support

[Colonel Panic]

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!

Re:Includes YAML support

[whytheluckystiff]

Absolutely. Ruby 1.8 contains a C extension (Syck) for parsing YAML. Benchmarks have shown that Ruby's YAML parser is competitive with the marshalling standards of other popular languages. Which is a big win for developers, as YAML is much more readable.

I will also mention that if you'd like to learn YAML, you might head over to the YAML Wiki, where general documentation is starting. There's also a complete manual for the Ruby extension.

Re:Includes YAML support

[Xlucid]

That looks suspiciously like a web-page you've written!

Pretty please, could we have an all-on-one-page, no frames version, so I can read it easily on my PDA?

Many thanks.

A couple of things Python doesn't have

[Anonymous Coward]

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.

Re:A couple of things Python doesn't have

[Genghis Troll]

Can you give an example of your first point? I've looked in the past, and only ever really found Seaside and Borges (a Ruby implementation of Seaside) as real-world examples of the use of callcc.

(I understand CPS as an optimization technique, but that doesn't require or typically use first-class continuations like callcc, so it's something of a different issue, I think.)

Popular at OSCON

[Anonymous Coward]

The Ruby sessions at OSCON this year all seemed to be very well attended. Seemed to be a lot of buzz about Ruby there in certain quarters. After attending one of those sessions, I decided to learn Ruby. I'd really like to be able to quit doing OO-Perl - it's sooo ugly - and I don't think I can wait for Perl6.

Re:Popular at OSCON

[Anonymous Coward]

Buy the sams 21 days book and you will be rocking in just 2 days.

Re:Popular at OSCON

[ubikkibu]

Popular is certainly a relative term. The Ruby day at OSCON did have its fanbase, but I went to two talks (including Matz' introductory one), and I'm still not getting it. He seems charming and intelligent, but gave almost zero information.

Python works and has a powerfully simple syntax. Ruby's syntax is hard to stomach once you're used to Python: I don't want to type extra characters again.

Python evolves to be practical. It adds the most-shouted-about features, with Guido tossing out anything that doesn't keep things simple. Perl evolves similarly, but with the new features being determined by some inscrutable process in Larry's head. Ruby evolves based completely on one man's whim, which is why it still has mostly academic appeal.

Re:Popular at OSCON

[Anonymous Coward]

Funny you take this approach. I find Ruby to be simultaneously very elegant, and insanely practical (with built-in regexes, rich arrays and hashes, and easy File/Net manipulation). After all, I forced myself to learn it when Perl seemed just a little to hackish for a reasonably simple task.

Perl is practical but inelegant. Ruby is practical and elegant. It doesn't have to be one or the other. I bet US$50 that no-one can send me a "practical" Perl program that I can't express in Ruby at least as easily, and more clearly. Of course, there's no real judge to decide the bet, but if anyone wants to give it a go just for fun: gsinclair at soyabean.com.au.

Some Good Resources/Sites

[Anonymous Coward]

For those of you who are interested, some good sites/resources for ruby: RubyForge (http://rubyforge.org)- A site using gforge for hosting project in Ruby RAA (http://raa.ruby-lang.org) - Ruby Application Archive Pragmatic Programmers - (http://www.pragmaticprogrammer.com/ruby/index.htm l) the complete book is online!!

Other uses of blocks

[Paradox]

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. myServer = Server.new( socket, something ) { set_sercurity_mode 2 set_logfile_path "/var/logs/speciallogs/" } /ECO

Thanks, IE. Repost that isn't ruined

[Paradox]

Never try to post on a windows machine, they're out to get you :P

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.

myServer = Server.new( socket, something ) {
set_sercurity_mode 2
set_logfile_path "/var/logs/speciallogs/"
}

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!

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 ;)

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

[aminorex]

which is nice, but not better than Java:

this.addListener(new Listener() {
protected void handleAction() { ...
});

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

[xteddy]

This is much better readable than Java's anonymous inner classes trick:

add_listener do ...
end

Java also forces you to declare variables from the outer environment as final if you want to use them
in your method. So it's NOT possible to do something like that in Java:

called = 0
add_listener do
called += 1
puts "Called " + called + " times."
end

But java is also inconsistent in this respect because at the same time it's possible to work around this arbitrary limitation:

class IntCollection {

private int[] collection = null;

IntCollection(int ary[]) {
collection = ary;
}

public void each(Runnable block) {
for (int i = 0; i < collection.length; i++) { block.run(); }
}

}

class foo {

public static void main(String args[]) {
int[] ary = new int[10];
for (int i = 0; i < 10; i++) { ary[i] = i; }
IntCollection col = new IntCollection(ary);
final int count[] = new int[1];
col.each(new Runnable() {
public void run() { count[0]++; }
});
System.out.println("Counted " + count[0] + " elements.");
}

}

Only God knows why the Java language designers made such an obscure decision.

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

[aminorex]

God, yes ... and his vicar on Earth, Guy Steele.

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:That's not what we mean by clean, friend.

[MarkusQ]

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.

You definition of "clean syntax" doesn't quite work the way you seem to think it does. Ruby does have a lot of stuff to define lists, etc. The fact that these things are optional doesn't mean they aren't there. That's why (rather than using your definition) we've been talking about the core / minimal syntax in terms of the smallest subset of the syntactic rules needed to use the full power of the language, rather than the fact that there are additional rules that let you write uncluttered programs.

Yes, you can write uncluttered programs in ruby. But this ability come at a cost, insofar as it requires a more cluttered syntax (lots of special case rules) to allow it. Having a simple syntax makes a language easier to learn, even if that syntax requires a bit of extra typing (think postscript). Having additional rules (shortcuts) to allow for less cluttered code can make programs written in the language easier to read and maintain (think ruby) but it can also lead to cryptic soup (think perl).

-- MarkusQ

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

[xteddy]

Clean syntax is not an end in itself. It's good for compiler writers because it's easier for them to parse the language. LISP and Brainfuck have a very clean and minimal syntax but the programmers have to pay a price. Ruby was not intended to be a minimal, clean language (like many academic languages are) but was designed to help programmers write better programmes and make them better programmers at the same time.

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.

i18n?

[metamatic]

UNICODE support added yet?

Re:i18n?

[Anonymous Coward]

Unfortunetry, M17N surpport will be done in 1.9.
(Of course, Ruby can handle UTF-8 by default)

Congratulations...

[Ayanami Rei]

you're programming in javascript.

(I kid you not.) Imagine a C++-like language that can do all that (and more). That's javascript.

Re:Congratulations...

[Genghis Troll]

Yea, javascript seems pretty neat, from the little that I've looked at it.

Re:Best. Clause. Evar.

[yomegaman]

That's not what it says. It says that 1.6.8 is twice the size of the new release. At least the submitter has the excuse of being a non-native English speaker. What's yours?

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

Yeah, but...

[Merk]

Have you ever taken a look at the OO syntax of Javascript? It's damn ugly! I was really impressed at things like Function() though. If it weren't for the browser-specific parts of Javascript then it would be a pretty good language... but used to manipulate browsers it's a real pain.

Re:Smalltalk elegance & Ruby elegance

[Xlucid]

Smalltalk is a language which manages to be expressive, but without the amount of syntax that Ruby has.

I'm a Smalltalk-er who likes Ruby for its Smalltalk-eyness.

After all, here are 5 lines of Ruby code that give the count of unique IP numbers listed from a webserver logfile which downloaded a particular file from the server

Ruby code:
anIpNum = Regexp.new(/[0-9.]+/)

aFile = File.open('D:/Savant/copyOfGeneral.txt')

aDicti onary = Hash.new

aFile.each_line { | line | aDictionary[line.slice(anIpNum)] = 1 if line.include?("plastic_1.1_lite-UMLtool-fw.exe") }

puts aDictionary.size

and the equivalent Smalltalk

anIpNum := Regexp new: '[0-9.]+' .

aFile := File open: 'copyOfGeneral.txt' .

aDictionary := Dictionary new .

aFile each:
[ | eachLine |
eachLine include: 'plastic'
ifTrue: [ aDictionary at: anIpNum put: 1 ]
] .

aDictionary size

Of course, in Smalltalk-80 there isn't a standard Regexp class, so I'd have to find one.

But I hope you all agree that Ruby's syntax is not too far off Smalltalk's elegance in this example.

p.s. Apologies for the formatting, but until I selected 'Code', Slashdot's lameness filter kept rejecting this post...

Now will someone please document it?

[PizzaFace]

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.

Re:Now will someone please document it?

[JamesOfTheDesert]

ruby-doc.org has a assorted documentation in a variety of languages and links to numerous online tutorials and articles.

Plus, help for the built-in library is available via the commandline tool ri

Now I know I'm a geek, and not a very good one

[heinousjay]

Finding out that a programming language named "Brainfuck" exists gave me a hard-on. How did I never hear of this before?

Time to learn another language...

Re:Now I know I'm a geek, and not a very good one

[Anonymous Coward]

It's named that way for a reason. Good luck with your learning...

1.8.0 explanations and sample code

[whytheluckystiff]

What's Shiny and New in Ruby 1.8.0?

Brainf**k

[Anonymous Coward]

Despite the whimsical name, there is such a thing. It is based on a kind of string manipulation syntax akin to a Turing machine. I don't think it is meant to be a serious programming language as much as a puzzle or a kind of mental activity, hence the name . . .

last post

[patch-rustem]

last post!

--
Baby Ruby says "bwarghhhhh!"