Ruby 1.9.0 Released

sciurus0 writes "The 1.9.0 development version of the Ruby programming language has been released. This version has many changes, including a new virtual machine that provides great speed improvements."

Comments

No comments yet, but...

[VGPowerlord]

No comments yet (or at least not when I started typing this comment) and the second link is already /.ed.

Firehose blurp

[pembo13]

Why does this look like an unedited blurp from the Firehose?

Re:Firehose blurp

[Anonymous Coward]

Don't complain! The editors might try to edit it, and then we'll really be hosed.

Re:Firehose blurp

[smittyoneeach]

Well, they could have added a nearly-canonical "...this is primarily a bug-fix release."
It goes without saying that an open source project is always fixing bugs, hopefully at a slightly higher rate than they are introduced.

Benchmarks mean nothing, specially these ones.

[rgo]

Well, it seems that Ruby 1.9.0 is the fastest implementation available, it also is reflects the newest version of the language... but I would really like to see benchmarks based on real apps based on things like Mephisto,Radiant CMS and/or Mongrel. Also, does someone have a list with the most important features? The summary is way too poor.

Re:Benchmarks mean nothing, specially these ones.

[sciurus0]

According to Chu Yeow, Mongrel doesn't run on 1.9.0 yet. Neither does Rails. The release of 1.9.0 coincided with the API freeze for 1.9.x, so hopefully projects that were holding off on porting to 1.9 will do so now. The situation is complicated by 1.9's transitional nature; you should stick with 1.8 if you absolutely need stability.

Re:Benchmarks mean nothing, specially these ones.

[Sean Cribbs]

Radiant CMS has no immediate plans to move to 1.9. Obviously, Rails will need to support it first, and even then Ruby 1.9 is a development release, not a stable one.

Re:Benchmarks mean nothing, specially these ones.

[Matrix9180]

The plans are to have Rails 2.1 ruby 1.9 compatible.

Re:Benchmarks mean nothing, specially these ones.

[Anonymous Coward]

Couldn't find the benchmarks for all the advertisements ... hmmmm.

Why Ruby?

[Just Some Guy]

Alright, I know this is going to be flame fodder, but I'm genuinely curious: does Ruby have anything to offer for someone who's already very proficient in Python (and Django, so Rails is already covered)? Basically, I've been using Python for quite a while and work with a largish codebase at the office. Is there any reason why I should give Ruby a try other than the standard - and very valid - "because it's there"? From what I've heard it seems that the two languages occupy roughly the same niche and are approximately as expressive.

Again, I know that sounds flamebait-like but I'm asking sincerely. My available time is pretty limited these days and don't have the luxury of branching out nearly so much as I used to.

Re:Why Ruby?

[Anonymous Coward]

Is there any reason why I should give Ruby a try?

Speaking as a ruby developer, if you're happy with python - not really! Python's also great. It's just a matter of which suits your style. Personally, I couldn't get over Python's syntactically significant whitespace - many people would laugh at that, but for me it's just unthinkable. So Python was just ruled out for me totally because of that.

Python and Ruby are both competing to be the most beautiful next-gen languages .. but beauty's in the eye of the beholder. I've found mine, and it sounds a lot like you've found yours. So .. that was the long way to say, again, "not really" ! : )

Re:Why Ruby?

[Anonymous Coward]

As someone in the same general situation as you -- I also work on Python code -- my conclusion when I asked myself the same question, was an emphatic no. There's little Ruby can do that Python cannot, and vice versa. As well, I looked through a Ruby tutorial; it can be a really strange language. I'm sure it works for people who put in the time to learn it, but it didn't click with my Pythonic mindset.

I think Ruby is really an evolution of Perl. There are a lot of Perlisms in its syntax, and I bet it'd be very easy for a Perl programmer looking for something new to learn Ruby. I resisted learning Perl in the first place and picked up Python instead; I have never regretted this decision, and I don't think I'll regret not learning Ruby either.

Re:Why Ruby?

[Foofoobar]

Answer: No. Ruby doesn't scale as well as PHP, Python, or PERL. The number of responses per second it can handle quickly drops off in comparison to the other languages; tack on Rails and it's even worse. Honestly, any MVC framework in Perl, PHP or Python is going to be more scalable and faster than RUBY; it may have a bit steeper of a learning curve for a newbie but so what.

Re:Why Ruby?

[Tyler Eaves]

Ruby is a neat language. Basically imagine a language that can do all of the great hacks you can do in perl (and then some) but with a sane syntax. Python is a very very good language, I've written quite a bit of code in it. Ruby is nicer, at least from a syntax standpoint. It's just SO expressive, even beating python. But, at least until now, the speed always SUCKED balls. Maybe this new release will get it roughly on par with python.

Re:Why Ruby?

[sciurus0]

Alright, I know this is going to be flame fodder, but I'm genuinely curious: does Ruby have anything to offer for someone who's already very proficient in Python (and Django, so Rails is already covered)?

Take a glance at Ruby from other languages. This page highlights some of the things that make Ruby Ruby.

Re:Why Ruby?

[PaulK]

Try it if you can find the time, and maybe pick up a copy of Ruby for Rails.

Python currently has larger library support.

Personally I see no need for you to reinvent your wheel, but you'll probably not be gratified as to the validity of your decision until you dig a little.

Re:Why Ruby?

[corsec67]

Yeah, same here for why I don't like Python.
I find myself adding additional if/loop statements around a block of code often enough that I just couldn't imagine working with python where it isn't trivial to automatically indent the block of code, since the indent is the block of code. Copying/pasting code is another case where the indentation is not necessairly correct. I am not talking about duplicating code here, but something like taking a chunk of code and making it into a function call.

I really like how quite often the single-line if/then statements in Ruby could be read aloud directly and they would make sense, like:
puts "hi there" if debug == true

Re:Why Ruby?

[aldheorte]

I'd like to see some statistics backing up this claim with code samples. I have never seen a performance problem in Ruby or any other language that was not fixed within an hour by generally simple code improvements. The developer is the cause of 99% of performance problems in any mainstream language today.

Re:Why Ruby?

[Yath]

Ruby has some differences that are important to some people.

* The built-in classes support functional-style programming. That is, the default action is generally to return a modified copy of the object being acted upon, so you can chain method calls together. This doesn't work well in Python, because methods frequently act like "procedures", modifying the object and returning nothing. Sometimes, Python programmers work around this by explicitly copying objects and then calling such methods. Other times, modifying the persistent object is just what they wanted; in Ruby, you would use a method which ends in "?", which is how Ruby identifies (by convention) methods that modify the object.

Thus, to combine two dictionaries in Python, without modifying either of them:

  dcombined = d1.copy()
  dcombined.update(d2)

In Ruby:

  dcombined = d1.merge(d2)

Obviously the Python code is fine, but from a functional programming viewpoint, it looks awkward.

* It's entirely predictable whether a built-in class's method will modify the object, because of the "?" suffix convention. In Python, you don't have such an explicit convention, which can sometimes make more work for the programmer.
* Ruby doesn't rely on global functions as much, or "builtins" as they're called in Python. If you want to know the length of something, or convert a string into a list of characters, you call a method of the object rather than a global function. Some people find this to be easier, given that you only need to focus on one paradigm (object-oriented) and not two (e.g., object-oriented and imperative).
* The print statement in Ruby prints only what you tell it to, rather than adding whitespace in various cases. Since this is the behavior of print or printf in most languages, this is nice. Ruby offers the puts method for those times you want whitespace helpfully added (like Perl 5.10's say).
* regular expressions are more tightly integrated. Some people consider this a disadvantage of Ruby though, because you can write less explicit code.
* Ruby gives you fewer types of quotes to learn, because ' and " are multiline.

Re:Why Ruby?

[eosp]

I thought that the ? suffix meant "this makes no modifications and only returns a certain property, usually boolean" and ! meant "this modifies the "self" object. Example: foo.gsub!(/f/, 'g') would modify 'foo' directly, where foo.gsub(/f/, 'g') would return a new string but leave the old one unmodified.

Re:Why Ruby?

[mini me]

The thing that makes Ruby stand out above the languages I'm well versed in (unfortunately Python isn't one of them) is its metaprogramming abilities. For lack of a better way to describe it: You don't write Ruby programs. You write Ruby programs that write Ruby programs. If Python is the same in this regard, then I guess probably nothing.

Re:Why Ruby?

[Yath]

Oops, you're right. Thanks for the correction.

Re:Why Ruby?

[fjolliton]

Using Emacs, editing Python code with correct indentation is not difficult. I use a lot the following keybindings:

;; Functions to shift a region. Useful for Python.
(defun region-shift-left ()
(interactive)
(if mark-active
(indent-rigidly (region-beginning)
(region-end)
(- (or current-prefix-arg 1)))))

(defun region-shift-right ()
(interactive)
(if mark-active
(indent-rigidly (region-beginning)
(region-end)
(or current-prefix-arg 1))))

(global-set-key (kbd "A-<left>") 'region-shift-left)
(global-set-key (kbd "A-<right>") 'region-shift-right)

Select the block to shift, then alt-right arrow or alt-left arrow to indent/unindent the block. Very convenient! And it just work after pasting. I can't imagine editing Python code without these bindings.

Re:Why Ruby?

[fjolliton]

With Python (>=2.4 I think):

>>> a = { 'x' : 3 }
>>> b = { 'y' : 7 }
>>> c = dict( a , **b )
>>> a , b , c
({'x': 3}, {'y': 7}, {'y': 7, 'x': 3})

To merge more than 2 dictionnaries this way, you need dict(dict(a, **b), **c), and so on.

Re:Why Ruby?

[Anonymous Coward]

I think you have your punctuation confused.

"?" indicates a method returning a boolean value. "!" indicates a "dangerous" method.

Re:Why Ruby?

[jhol13]

That is not the whole point.

Problem 1: You cannot reliably copy-paste.
Problem 2: You cannot add easy to notice debug output lines, or whatever, e.g.
        if (foo){
printf("did foo\n"); // remove this line later
            do_foo(bar);
        }
Problem 3: prone to user errors
        if (bar())
            strFoo +=
"<xml>"
    "long lines indented according to xml rules for clarity" ... add 100 lines
"</xml>"
            strFoo += "OOP"; // What "level" is this?
        bar(); // Or this?
Problem 4: indent-region is much better than your hack, in every sense.
Problem 5: It just makes me (and the GP/GGP) uncomfortable. So why bother as there clearly are enough other languages for us?

Re:Why Ruby?

[Anonymous Coward]

Alright, I know this is going to be flame fodder, but I'm genuinely curious: does Ruby have anything to offer for someone who's already very proficient in Python (and Django, so Rails is already covered)?

Yes, it's a different way of programming. In general, even if it had no features more powerful than Python, I've found that learning a new language causes you to get better at the ones you already know.

Ruby does offer some advantages over Python. If you can't remember what all the __codes__ are (like me), Ruby is great, because you can just write "def [](i) ...". If you hate not being able to write lambdas that do anything non-trivial, Ruby is great, because you can pass real blocks to any method (though I hear Python 2.5 context managers do a similar thing, if not as concisely). There are a bunch of little things that are just the same in both, and a bunch of little things that are nicer, and a bunch of little things that are worse. I've written OO code in CLOS and C++ and Java and Python, and Ruby has yet another object model, which may break your brain in new and interesting ways.

Basically, I've been using Python for quite a while and work with a largish codebase at the office. Is there any reason why I should give Ruby a try other than the standard - and very valid - "because it's there"? From what I've heard it seems that the two languages occupy roughly the same niche and are approximately as expressive.

Alright, I know this is going to be flame fodder, but do you program for a paycheck, or do you program to get great at writing programs? If the former, don't bother with Ruby, because your company has already picked Python and you probably won't get fired for not knowing Ruby.

Again, I know that sounds flamebait-like but I'm asking sincerely. My available time is pretty limited these days and don't have the luxury of branching out nearly so much as I used to.

It's been said that programmers should learn a new language every year. If you haven't done one yet this year, Ruby is a fine one to go with. If you already have, and want to put off Ruby until next year, I think you'll live. If you don't know many languages yet, you might be better served by picking something further from Python, like SML or IO or Forth.

But whatever you do, learn a new language that doesn't have "++" or "#" or "J" or "Microsoft" in the name. (Well, except for "J". I meant to exclude Java, not J.)

Re:Why Ruby?

[vrt3]

Unfortunately that only works if the keys are strings.

Re:Why Ruby?

[fjolliton]

Have you tried it?

>>> a = { 1 : 2 }
>>> b = { ( 'foo' , 'bar' ) : 4 }
>>> c = dict( a , **b )
>>> a , b , c
({1: 2}, {('foo', 'bar'): 4}, {1: 2, ('foo', 'bar'): 4})

Re:Why Ruby?

[vrt3]

Oops, I was too fast. You're right and I'm wrong.

Sorry.

Re:Why Ruby?

[jo42]

syntactically significant whitespace That definitely falls under "WTF where they thinking?!?" where a single, invisible, space can bork up your code.

Re:Why Ruby?

[Haeleth]

I'm genuinely curious: does Ruby have anything to offer for someone who's already very proficient in Python (and Django, so Rails is already covered)?

Yes. As a Python user, a follower of that very serpent who brought about the fall of Adam, your soul is forfeit and you face an eternity screaming in the fires of Hell. But there is hope at this season of Christalmas! For Matz so loved the world that He sent His only begotten language Ruby, that all who program in It shall not die, but have eternal life! Repent of your sins, accept Ruby Christal as your Language and Saviour, and you too can live forever with It in Paradise.

(Seriously, that's about the only real difference: the level of evangelistic fervour each language's advocates hold. Perl and Python have users; Ruby has missionaries.)

Re:Why Ruby?

[WNight]

To actually do any given thing, no.

To program in for fun, yes. To do things you'd never have thought of doing, yes.

Blocks and iterators: [1,2,3].collect {|x| x ** 3 }.each {|x| puts x.to_i }

It's like specifying arguments that contain code. Functions you otherwise would have to pass a ton of arguments to, or provide a call-back function for, take an anonymous block.

Ruby's a very quick language. You can get something done quickly like Perl, and it has nice shortcuts like "foobar" =~ /Foo/i for regexps, etc.

If you dislike modifying built-in classes, class Array ; def to_s ; #new behavior ; super ; end ; end then you might not like Ruby.

If you want type checking, you might not like Ruby. Or, you might like duck-typing (obj.respond_to? :desired_method and then treat the object like it's what you want regardless of which actual class it is).

If you like to program, give it a try. If it's just a work thing, as someone else said, stick with what works for you.

Re:Why Ruby?

[Anonymous Coward]

Bad try - Ruby 1.9.0 does not "handle Requests", as it has nothing to do with web. It is a general purpose scripting language like python (not PHP).

You are talking about RAILS - which is something completely different.

Re:Why Ruby?

[Haeleth]

The built-in classes support functional-style programming. That is, the default action is generally to return a modified copy of the object being acted upon, so you can chain method calls together.
[...]
Obviously the Python code is fine, but from a functional programming viewpoint, it looks awkward.

This is indeed a useful feature, but it's not really functional programming, just a different style of object oriented design. The complete absence of any functions in your example might have served as a clue. :)

Functional programming has nothing to do with objects: it's when you take advantage of first-class functions and higher-order functions in your code. In Ruby this is usually done with code blocks. In Perl it's done with anonymous subs. It can be done in Python with lambdas (which are rather limited) or by using a scoped named function, so Python's support is slightly less convenient than Ruby's or Perl's, though its list comprehensions (another functional feature) are rather nice.

Re:Why Ruby?

[Anonymous Coward]

boring - shudda picked a different example. python also has list operations:

$ ruby
[1,2,3].collect {|x| x ** 3 }.each {|x| puts x.to_i }
1
8
27

$ python
Python 2.3.3 (#1, Dec 30 2003, 08:29:25)
[GCC 3.3.1 (cygming special)] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> [x**3 for x in [1,2,3]]
[1, 8, 27]

Re:Why Ruby?

[smittyoneeach]

The emacs rectangular editing features make 'sculpting' text a no-brainer: (here is the C-h a rectangle output, noting that registers are a really powerful emacs feature):

calc-grab-rectangle M-x ... RET
Command: Parse a rectangle as a matrix of numbers and push it on the Calculator stack.
clear-rectangle C-x r c
Command: Blank out the region-rectangle.
close-rectangle M-x ... RET
Command: Delete all whitespace following a specified column in each line.
copy-rectangle-to-register C-x r r
Command: Copy rectangular region into register REGISTER.
delete-rectangle C-x r d
Command: Delete (don't save) text in the region-rectangle.
delete-whitespace-rectangle M-x ... RET
Command: Delete all whitespace following a specified column in each line.
delimit-columns-rectangle M-x ... RET
Command: Prettify all columns in a text rectangle.
kill-rectangle C-x r k
Command: Delete the region-rectangle and save it as the last killed one.
open-rectangle C-x r o
Command: Blank out the region-rectangle, shifting text right.
replace-rectangle M-x ... RET
Command: Replace rectangle contents with STRING on each line.
string-insert-rectangle M-x ... RET
Command: Insert STRING on each line of region-rectangle, shifting text right.
string-rectangle C-x r t
Command: Replace rectangle contents with STRING on each line.
yank-rectangle C-x r y
Command: Yank the last killed rectangle with upper left corner at point.

The most compelling argument against significant whitespace in Python is that it makes generating code rather tricky, but then, how often do you do that, and is it really so hard to add another "indent" call in there to tidy matters?

Re:Why Ruby?

[smittyoneeach]

I think that the rather vast body of python code freely available moves the design choice out of "WTF" territory.
Love it or hate it, it's simply not a show-stopper.
Haskell, too, has significant whitespace, though, unlike Python, you can relax the whitespace significance in Haskell.

Re:Why Ruby?

[smittyoneeach]

If performance is an issue, don't you move the code to something in a compiled langauge once a) the requirements are settled and b) you're sure you actually need to do so?

Re:Why Ruby?

[pebs]

(Seriously, that's about the only real difference: the level of evangelistic fervour each language's advocates hold. Perl and Python have users; Ruby has missionaries.)

Perl = Hinduism
Python = Buddhism
Ruby = Christianity??!??

Re:Why Ruby?

[Anonymous Coward]

Ruby 1.9 has a completely new interpreter which is much faster than the old one. "Responses per second" makes no sense, because it's not a web language.

Re:Why Ruby?

[Just Some Guy]

That definitely falls under "WTF where they thinking?!?" where a single, invisible, space can bork up your code.

OK, does anyone really write significant amounts of code in Notepad? That's the only editor I'm aware of that doesn't have any form of Python syntax highlighting available. Emacs or Vim or Kate or Eclipse will cheerfully steer you around that single, invisible space so this only seems to be a problem in the minds of people who want to invent reasons to dislike it.

Re:Why Ruby?

[Just Some Guy]

I really like how quite often the single-line if/then statements in Ruby could be read aloud directly and they would make sense

I don't like Perl so much anymore, but it had a really cool feature where instead of writing "object.method(args)", you could write "method object args". Instead of a construct like

if not value: output.log("value isn't set")

you could write

log output "value isn't test" unless value

It was kind of a pain in the ass for maintenance because if you want to change the test for value from false to true, you'd have to re-write that as "unless not value" and mentally parse the double-negative each time, or replace "unless" with "if". Still, I always that that was a pretty construct.

Re:Why Ruby?

[renoX]

[[does Ruby have anything to offer for someone who's already very proficient in Python]]

Not much in my opinion: while I was looking for a language I'd like I found both Python and Ruby and had quite some difficulty to find one that I'd like better than the other one: in fact those language are very similar.

So as you're already using Python, I doubt that you'd see much benefit going to Ruby.

Myself finally I chose Ruby, unfortunately I'm doing much more Perl (bleach) than Ruby.. :-(

Re:Why Ruby?

[Just Some Guy]

Ouch. Try this one:

>>> a
{1: 2, 'foo': 'bar'}
>>> b
{3: 4, 'foo': 'qux'}
>>> dict(a.items() + b.items())
{3: 4, 1: 2, 'foo': 'qux'}

It scales easily (add "+ c.items()" to mix in another dict) and doesn't have any restriction's on the keys' datatypes.

Re:Why Ruby?

[astrashe]

I don't know Python, and I don't want to try to compare Ruby with it. And I'm not a real programmer, just an amateur, so take this with a big grain of salt. I could be completely wrong here.

The heart of Ruby is its use of idiom. It's a difficult thing to describe, and I don't know how you'd find some metric to measure it, or to compare it to another language. But it's very clean, and very sensible, and surprisingly simple, at least on the surface.

There's a kind of aesthetic pleasure to be had in the syntax of Ruby. I was about to write that in that sense it's kind of an anti-perl, but that's flame bait, and I never connected with perl, and lots of people probably find perl beautiful. But Ruby is really great.

You can do things like:

1.upto(10) {|x| puts x }

Which does:

1
2
3 ...

This thing looks a lot like an old fashioned for/each loop, but it's an iterator, and the code in the curly brackets is a closure. So under the hood, it's fairly different from a for/each loop.

There are a few things to mention about this.

First, because there are lots of iterators on the shelf, and because you can write your own iterators if you want, this thing is a lot more powerful than looping constructs in many other languages.

Second -- and this is the sort of thing I was trying to get at above -- the syntax for closures is tweaked so it makes human intuitive sense when you're using closures with iterators. In your head, you might be thinking in for/each terms, and the syntax colludes with you if you want to hang on to that useful fiction.

In Lisp, you can never forget about the lambdas. In Ruby, you just sort of do what you want, and the lambdas are there under the hood, but they're not jumping out at you in the same way. Ruby's syntax fits the way a lot of people think, and it hides the stuff that it makes sense to hide, and exposes the stuff that it makes sense to expose.

And when you write out that line of code, its meaning is very clear and easy to grab a hold of, and it turns out that it's usually very concise and compact as well.

This is a little redundant, but I want to stress it, that line of code really is a pretty thing, in a sense. It's not so remarkable if you think of it as a for/each loop, but it's not a for/each loop -- it's an iterator and a closure, and that's a somewhat complicated thing, but here it isn't complicated, or opaque. It's clean, and it makes sense, and it's concise, but most of all, the shape of the code conforms to the shape of the idea in your head. That's what Ruby is all about, and you see that over and over and over again.

Third, this approach to idiom is a real dual edged blade for me, because there's a culture in Ruby books that sort of says, "You know what this line of code is doing, so don't worry too much about the lambdas." For a long time, I felt lost in Ruby -- like, I kind of knew what the code was going to do, but I wasn't exactly sure what was going to happen under the hood. That's a really uncomfortable place to be. I had to watch the SICP lectures to really grab hold of Ruby.

It's always dangerous to talk about some other culture -- I could be way off base here, and I hope I don't say anything really dumb. But it feels Japanese to me -- it reminds me of a drawing where there aren't many lines, but all the lines are kind of perfect and clean. It's got that same sense of elegance to it. Let's boil this big thing down to its essence, and make it beautiful and sparse.

I can't tell you that Ruby is better than some other language. But I can tell you that it's very beautiful, and that the beauty lives in lots of small little details. The experience of learning and using Ruby is one of noticing these little things and saying, "Wow, how great is that?"

I used to live in an apartment building that had been designed by a famous architect -- Mies van der Rohe. The design made a difference -- I can't tell you why or how, exactly, but it d

Re:Why Ruby?

[Just Some Guy]

You don't write Ruby programs. You write Ruby programs that write Ruby programs.

I have a Python class that contains a list of functions that must all eval to True before certain actions can take place. If a test failed, I wanted to return an explanation to the user, and decided to store that in the function's docstring. In Python that's an unlinked string at the very beginning of a function definition:

>>> def foo():
... "This doesn't do anything useful"
...
>>> print foo.__doc__
This doesn't do anything useful

By the way, Python's self-documenting system uses these docstrings to dynamically build it's man page equivalents. But I digress. Anyway, the problem is that I wanted functions to only have one argument: the single value that was being validated. So, I wrote a function that created a function, complete with docstring, and returned it:

.def shippingweightlessthan(threshold):
. """Return a function that returns an error if the given value is not less than the threshold"""
. testfunc = lambda x: x < threshold
. testfunc.__doc__ = """%%s must be less than %d""" % threshold
. return testfunc

Finally, the list of requirements inside this validation class looks like inthepresent, destinationexists, hasphonenumber, shippingweightlessthan(5000).

This isn't something you do all the time in Python, but it's definitely possible. The function creation syntax certainly isn't as simple as Lisp's, but it's still easy enough that you don't ever want to avoid it or have to look up how to do it.

BTW, Slashdot: your <ecode> tags are the only place where Python's whitespace is a pain in the butt. Please get them to honor the snake. Please?

Re:Why Ruby?

[siride]

It's funny because I basically use Python indenting rules for all of my programming, and everyone should anyways. I've had no problem with copy and paste (any good editor will take care of fixing the indentation for you, like Eclipse's editor), or adding in one off lines, or any of the other stuff you've complained about.

Re:Why Ruby?

[Just Some Guy]

Alright, I know this is going to be flame fodder, but do you program for a paycheck, or do you program to get great at writing programs? If the former, don't bother with Ruby, because your company has already picked Python and you probably won't get fired for not knowing Ruby.

Actually, my company picked Python because I kept insisting that it was better suited for us than FoxPro or VB.NET.

It's been said that programmers should learn a new language every year.

I learned enough Lisp to write my son's birth announcement in it a few months ago. Previous announcements were in Python, Perl, and C - pretty much following my career path. We're not having another kid, but if we did I promise you the announcement wouldn't be called "baby.4th". Dang, actually that might've been cool for the fourth kid. Rats.

Re:Why Ruby?

[Just Some Guy]

Myself finally I chose Ruby, unfortunately I'm doing much more Perl (bleach) than Ruby.. :-(

Bleached Perl?

Re:Why Ruby?

[Fweeky]

They're not really list operations like Python's, that just happens to be what the method calls do.

def bla(&foo) # you could also skip the &foo and use block_given? and yield
  puts "Before foo"
  foo.call(moo, woo) # in 1.9 you can write foo.(moo,woo)
  puts "After foo"
ensure
  cleanup_after_foo
end
 
bla {|a,b| b.frob!(a) }

Methods can receive blocks of code, or not, and call them whenever they want, however many times they want, pass them around, whatever. With Ruby2Ruby you can even get an AST out of it (which at least one SQL abstraction library uses to build SQL statements). They're pervasive; want to fork or thread? Pass the fork method or Thread.new the code you want them to execute. Want to open a file? Pass it a code block and it'll autoclose when your block exits. Run some code to handle each match in a string search/replace? Pass String#gsub the block.

Yes, you can get much the same behavior in Python by passing about lambdas, ala Ruby's foo(lambda {|bla| bla.moo }), but it's not so natural that you find yourself doing it everywhere with the blessing of your standard library.

Re:Why Ruby?

[jdinkel]

And if you are talking about "scalability" then that statement is absolutely false. It is trivially easy to scale Ruby apps and especially easy to scale Rails apps using the standard mongrel with mongrel_cluster. As a server admin, the biggest draw to Rails for me is it's ease of scalability, much much easier than scaling php web applications. Now, "performance" is another story.

Re:Why Ruby?

[Just Some Guy]

bla {|a,b| b.frob!(a) }

OK, time for the original poster to interject a pet peeve. Please do not optimize your examples for inscrutability! As a non-Ruby programmer, I have no idea whatsoever where to begin deciphering the above. Maybe, |a,b| is a list and you're calling b.frob! with a as an argument, then passing the results to bla? Or assigning them to bla? I have no idea.

It has nothing directly to do with Ruby (as far as I know), but its proponents seem to pick the most obtuse examples imaginable, at least for people who are completely unfamiliar with its syntax. It's like, "hey, look how much I can do with one line!", except the people seeing it for the first time have no idea how that would even parse.

Re:Why Ruby?

[Anonymous Coward]

I learned enough Lisp to write my son's birth announcement in it a few months ago. Previous announcements were in Python, Perl, and C - pretty much following my career path.

Um, you seemingly learned enough Lisp to write some Python, Perl and C code in it... not the world's greatest educational experience.

Re:Why Ruby?

[nuzak]

> I don't like Perl so much anymore, but it had a really cool feature where instead of writing "object.method(args)", you could write "method object args".

This is called "indirect object" syntax, and it's really frowned upon in modern perl code due to the ambiguities it causes. Construction with my $x = new Foo was one of the last holdouts, but even that has largely given way to my $x = Foo->new.

Re:Why Ruby?

[Anonymous Coward]

The example was perfectly normal idiomatic ruby, not obfuscated in any way other than the fact that it doesn't actually do anything (as you'd expect from examples using metasyntax like "foo", "bar", "blah" etc). When I ask for code samples, I do want to see what the real world code tends to look like, warts and all. That's the difference between examples and a tutorial.

Re:Why Ruby?

[chromatic]

... the code in the curly brackets is a closure.

It is? What does it close over?

Re:Why Ruby?

[Just Some Guy]

Probably true. I'd picked up "Practical Common Lisp" about two weeks earlier and hadn't had a chance to really field-test it yet.

Re:Why Ruby?

[Just Some Guy]

The example was perfectly normal idiomatic ruby, not obfuscated in any way other than the fact that it doesn't actually do anything (as you'd expect from examples using metasyntax like "foo", "bar", "blah" etc).

I totally disagree. How hard would it have been to write that like:

inputlist {|value,object| object.method!(value) }

or similar where an experienced programmer can at least figure out which parts of speech are involved? Metasyntactic variables are fine, but not to the point that you can't tell which are objects, methods, and parameters - especially when the syntax involved doesn't closely mirror other popular languages.

Re:Why Ruby?

[midnighttoadstool]

I doubt it. They're so nearly equivalent that proficiency in one disqualifies the other. In the case of Rails/Django, I'm finding that Rails' poor docs (ambiguities, the lack-of, and little cross-referencing) is a pain in the butt. Further Rails has no support for prepared statements (does Django?). And rails hosting options (mongrel etc) are not solid. It is possible that if you are a meta-programming addict that Ruby might be worth learning as it goes quite a lot further than Python.

Re:Why Ruby?

[Anonymous Coward]

Python has a special syntax for list comprehensions (and IIRC, more recently, generator comprehensions). The syntax is a hardcoded, built-in primitive of the language, and can only do one or two things (mapping and filtering).

Ruby has a generic coroutine dispatch mechanism that allows any method invocation to be associated with a code of block that the method may invoke however it chooses. You can implement mapping and filtering with it, but that's just the start of things, because you can use it for all other kinds of purposes.

Re:Why Ruby?

[Fweeky]

|a,b| are a block arguments list, like (a,b) are method arguments in def bla(a,b).

The block of code in {..} is passed to bla as an argument; bla(&foo) says "If you're passed a block, turn it into a Proc object and put it in the variable foo". foo.call then calls the block with whatever arguments you pass it. The example is just to show that block passing is a general purpose construct, not a special case for list processing, hence all the nonsense variables.

e.g. if you add:

def cleanup_after_foo
  puts "Cleaning up"
end
def moo() end
def woo() end

You get:

Before foo
Cleaning up
NoMethodError: undefined method `frob!' for nil:NilClass Note that even though the code block raised an exception, the bla method caught it and hid the details of cleaning up afterwards, while still letting the exception propagate (which is what File#open(..) { .. } and other resource-allocation based methods tend to do). It could also catch the exception and retry, or it could call the block multiple times over a collection (thus you get each()), put the results into another collection (and thus provide map()/collect()), or just save the block for later use elsewhere (e.g. you can have a block to calculate the default value for any unset key in a hash).

A simplified real-world example may be more useful than generalized foo/bar/baz/moo:

run_once do
  server do |client|
    category,title = client.gets.chomp.split(/\t/,2)
    client.puts lookup(category.to_i, title).map {|record| record.id }.join(",")
  end
end

run_once() wraps a bunch of setup code; pidfile handling, config file reading etc. server() spawns off a bunch of worker threads, and uses the code block in those workers to handle each client. Both have their own resource control (server ensures the client gets closed and logged cleanly, for instance) and exception handling (server logs and keeps going, run_once logs/prints and exits with a >1 return code). map { } just modifies the array lookup() returns to only contain the record ID's.

Obviously you could achieve the same sort of effect using callbacks, either by making more methods or defining lambdas, but you just need to see how rarely array_map() in PHP is used compared with map/collect in Ruby to see that doesn't exactly encourage use; you'd normally tediously write yet another foreach() and do it yourself.

Re:Why Ruby?

[jwilcox154]

Bad try - Ruby 1.9.0 does not "handle Requests", as it has nothing to do with web. It is a general purpose scripting language like python (not PHP).

You are talking about RAILS - which is something completely different. So true. Ruby is used for scripting in many applications. One example is the RPG Maker Series. RPG Maker XP uses the Ruby Game Scripting System (RGSS), which is a modified version Ruby for the specific task of RPG creation. With such scripting, the possibilities are endless depending on someone's coding skills in RGSS. RPG Maker VX will use RGSS2. Although RGSS scripts can be used in RPG Maker VX, RGSS2 scripts can't be used in RPG Maker XP.

Ruby on Rails, much like RGSS, is a modified version of Ruby. Unlike RGSS, Ruby on Rails is modified to utilize the Rails framework for web applications.

As a result, someone just needs to learn Ruby to learn the basics of RGSS/RGSS2 or Ruby on Rails.

Sources
http://www.enterbrain.co.jp/tkool/RPG_XP/eng/
http://www.enterbrain.co.jp/tkool/products/rpgvx/eng/index.html
http://www.rpgrevolution.com/script/rgss.php
http://www.rpgrevolution.com/script/rgss2.php
http://en.wikipedia.org/wiki/Ruby_on_Rails

Re:Why Ruby?

[Foofoobar]

Tell it to the ruby.com or rubyonrails.com websites. Tell it to 43things. They all rely upon PHP to scale their sites. This is a well known fact stated over and over again and that the RUBY maintainers are aware of but that the RUBY community calls a flame or FUD. Test it yourself if you think it's a lie; check those sites yourself if you think it's a lie (Note: some of the RUBY sites have turned 'show PHP' off in their php.ini config so it may not be showing anymore in Netcraft or with PHP hidden cookies but if asked, they will tell you that they are running it as it performs some things better than RUBY- and that's their official response).

Re:Why Ruby?

[Anonymous Coward]

Ruby, you would use a method which ends in "?", which is how Ruby identifies (by convention) methods that modify the object.

I assume you mean "!" here. And sadly, I've found that Ruby is less consistent than Scheme (from which it gets this nifty convention). In Scheme, every destructive function ends in "!". In Ruby, only destructive methods which also have a nondestructive alternative are suffixed with "!".

It's entirely predictable whether a built-in class's method will modify the object, because of the "?"

Not true. Hash#clear and Hash#delete modify the object, but contain no suffix. I hate this about Ruby: you can't skim the method list for methods ending in "!". You have to also know if there exists a nondestructive version of it, and if you knew that, you'd already know its name.

Ruby doesn't rely on global functions as much, or "builtins" as they're called in Python. If you want to know the length of something, or convert a string into a list of characters, you call a method of the object rather than a global function. Some people find this to be easier, given that you only need to focus on one paradigm (object-oriented) and not two (e.g., object-oriented and imperative).

Python: list(foo)
Ruby: Array(foo)
The real difference is that Rubyists will say "oh, but Array here is a method on Kernel, and methods with no explicit object get sent to Kernel". How this is different from global functions is beyond me.

Ruby gives you fewer types of quotes to learn, because ' and " are multiline.

Ruby also has << and %w (for multiple strings). While Ruby may have slightly fewer quote characters to learn, every one of them does something very different. In Python, IIRC, there's really only "single line" and "multi line".

I like Ruby, but you picked some of the weirdest (or falsest) reasons I could have imagined. How about symbols? How about blocks? How about everything being an expression? Open classes, method_missing, operators as simply syntactic sugar? Let's try to sell people on the *good* parts of Ruby. :-)

Re:Why Ruby?

[jhol13]

Just a question: how often did you, in C/C++/... mismatch a brace?

In Python it will quietly kill your program - in run time.

Point 3 cannot make any intendation "no-brainer", at least not for me. I still, even in C++, have problems. Why, just why, should I have to feel uncomfortable with the language I use (last point)?

P.S. I have nothing against Python, it just ain't for me(tm).

Re:Why Ruby?

[jhol13]

In C++ I often copy non-braced region on purpose, because I can re-indent it as it should, trivially with indent-region. This operation is impossible very hard with Python.

This does not make Python a bad language, it makes it a langueage against my instinct. Nothing more, nothing less.

Re:Why Ruby?

[spacmunke]

It's unfortunate that most people who praise Ruby as being this groundbreaking language in terms of features and usability neglect to look back 30 years at its roots in the smalltalk language. In fact, the smalltalk syntax to do the same thing is surprisingly similar.

1 to: 10 do: [:x | x printNl]!

For those of you unfamiliar with smalltalk, I'd really urge you to look into it. Squeak is a very mature implementation http://www.squeak.org/. In either case, you're right the syntax is powerful and beautiful, and in my opinion its a real shame that it has taken 30 some odd years for people to realize its potential. Even the java language is moving in towards adding closures as a language feature http://www.javac.info/ .

Re:Why Ruby?

[Anonymous Coward]

And how about DSL-style programming? How would Python implement something like this:

html do
  head do
    title 'Ruby'
  end
 
  body do
    h1 'Hello World!'
    p 'Ruby is fun.'
  end
end

Something like this, behind the scenes, will do the leg work:

class HTML
  undef p
 
  def initialize(&block)
    @result = []
 
    content_tag :html do
      instance_eval(&block)
    end
  end
 
  def method_missing(method, *args)
    content_tag(method) do
      @result << args.flatten
      yield if block_given?
    end
  end
 
  def to_s
    @result.join
  end
 
  protected
    def content_tag(tag_name)
      @result << "<#{tag_name}>"
      yield
      @result << "</#{tag_name}>"
    end
end
 
def html(&block)
  puts HTML.new(&block)
end

Re:Why Ruby?

[Estanislao Mart�nez]

This isn't something you do all the time in Python, but it's definitely possible.

...and this actually provides a decent answer to your original question as to what's different between Ruby and Python. It's less in the feature lists than in the programming styles implied by the libraries and the way the communities use the languages. This is something you do all the time in Ruby.

Re:Why Ruby?

[Yath]

Not true. Hash#clear and Hash#delete modify the object, but contain no suffix. I hate this about Ruby: you can't skim the method list for methods ending in "!". You have to also know if there exists a nondestructive version of it, and if you knew that, you'd already know its name.

You've got me there. Ruby could stand to clean up its act and be more consistent here. It still has quite an advantage, though.

Python: list(foo)
Ruby: Array(foo)
The real difference is that Rubyists will say "oh, but Array here is a method on Kernel, and methods with no explicit object get sent to Kernel". How this is different from global functions is beyond me.

As a Rubyist, I find the important question to be "is there a method to do this". In Ruby, if something can be made into an array, you use the to_a method. In Python, you won't be using a method. Ruby's Kernel.Array is an interesting bit of syntactic sugar (granted, Ruby has a bit much of that), but it isn't particularly relevant here.

Ruby also has << and %w (for multiple strings). While Ruby may have slightly fewer quote characters to learn, every one of them does something very different. In Python, IIRC, there's really only "single line" and "multi line".

The question, however, is why? Why do you need to learn more syntax to enter multiline strings?

I like Ruby, but you picked some of the weirdest (or falsest) reasons I could have imagined. How about symbols? How about blocks? How about everything being an expression? Open classes, method_missing, operators as simply syntactic sugar? Let's try to sell people on the *good* parts of Ruby. :-)

I've focused on my pet peeves: arbitrary syntax and broken paradigms. These things require a programmer to work harder. A language shouldn't do that. I believe that the power of open classes is important too, but I can't write everything.

Re:Why Ruby?

[Anonymous Coward]

Python currently has larger library support. Actually, Ruby has about twice as many libraries as Python.

Re:Why Ruby?

[iluvcapra]

It is? What does it close over?

The binding of given block, particularly the binding of x? When the upto calls the block for each number in the range, it can't see the implementation or any of the variables in the block. It only knows the block takes a single variable, it doesn't even know the name of it, and the variables in the block scope stay bound to the. This might be a better example:

def createErrorReporter(outputStream)
return Proc.new{|str| outputStream.puts(str)}
end

myReporter = createErrorReporter($stderr)
myOtherReporter = createErrorReporter($stdout)

myReporter.call("hello world") # "hello world" appears on stderr
myOtherReporter.call("goodbye world") #"goodbye world" appears on stdout

Re:Why Ruby?

[chromatic]

The binding of given block, particularly the binding of x?

By that definition, all subroutines that take arguments are closures. I could certainly write a language that implemented them as closures, but that doesn't make them closures per the language's semantics.

Your createErrorReporter does indeed return a closure though.

Re:Why Ruby?

[iluvcapra]

I regret that I couldn't think of a non-contrived example that worked in the context of the GPs post. But the principle is right: when you pass a block to a method in ruby, using the block_given?/yield idiom, it's captured as a Proc and retains its original binding, so it can always refer to names in its originating scope.

Re:Why Ruby?

[smittyoneeach]

I think a better question is why were the braces not mismatched: because people who code much tend to indent meticulously.
The 'lightbulb' moment for Guido was when he said "well, if everyone indents, why not codify it?"
No one is out to force anyone to use anything (with the possible exception of MicroSoft).

Re:Why Ruby?

[Atzanteol]

Personally, I couldn't get over Python's syntactically significant whitespace - many people would laugh at that, but for me it's just unthinkable

Agreed! Why in the *hell* in the 20th century should I worry so much about spacing? Let the editor handle that for me. Python developers have to create all sorts of tricks (emacs bindings mostly) to work around this flawed design just to work with the language. Frankly no modern language should have 'column' constraints.

Fortran is dead! Long live Python!

Re:Why Ruby?

[Atzanteol]

I'm going to disagree with you. It *does* make Python a bad language. It's a horrible language that requires such attention to the trivial and mundane without a good reason. And "pretty code" is not a good reason. Give me badly formatted Java and I have a myriad of tools ready to reformat it properly (in ViM it's simply "gg=G", in Eclipse it's ctrl+f, etc.). Let the editors concern themselves with formatting - I just wanna code.

It's absolutely asinine to *require* proper indentation when it's so *easy* (at least with curly-bracket delimited blocks) to have a program handle indentation for you.

Re:Why Ruby?

[Atzanteol]

Hah! This troll comes up time and time again. Let me know when you get (a) - I want to prepare for the end of the world that will surely follow...

Re:Why Ruby?

[smittyoneeach]

It's not so much a troll as an observation that the usual complaints about performance and scripting languages are, themselves, the troll.
I work with a large number of folks who don't seem to think that anything useful can be done unless it's done in Java, irrespective of the number of worked counter-examples presented.

Re:Why Ruby?

[Atzanteol]

But you can't simply brush off performance concerns as a non-issue simply because some folks have an impression that all scripting languages are slow. Performance is always a concern. And it sounds like Ruby has had real performance problems that need to be addressed, and it sounds like they are.

It's trollish to claim that requirements have ever been completely defined, and that development is ever actually finished (you never finish, you simply pick a time to 'stop' writing more). Though perhaps 'flamebait' would be more accurate...

Re:Why Ruby?

[Anonymous Coward]

It was kind of a pain in the ass for maintenance because [...] or replace "unless" with "if".

Aw, poor baby.

Re:Why Ruby?

[smittyoneeach]

I never said you can brush off performance. My contention is that, in the overall priority of concerns, performance sorts lower than many claim.
Your point that it is trollish/flamebait to claim that requirements are ever completely defined is well taken, but actually argues in favor of a scripting language like Ruby. The fatter runtime supports a more flexible approach to following those flexible requirements, especially when the customer can't differentiate between his bottom and a hat rack. (Oh god, that was a hellish project).

Re:Why Ruby?

[chromatic]

... it can always refer to names in its originating scope.

If it does, it's a closure. If it doesn't, it's not.

Re:Why Ruby?

[Just Some Guy]

It's absolutely asinine to *require* proper indentation when it's so *easy* (at least with curly-bracket delimited blocks) to have a program handle indentation for you.

Well put! And that's why every programmer's editor supports Python's indentation so that you never have to think about it.

Re:Why Ruby?

[Atzanteol]

And how does it sort it out when I copy/paste from some forum that doesn't support correct indenting (slashdot, others)? Or an old email where there is a ton of "> > > >" on many lines?

From what I've seen developers use Python in *spite* of the indentation, not because of it. It's a bug, not a feature. And you needlessly work around it.

Re:Why Ruby?

[Ambidisastrous]

It's even cleaner in Scheme. (Just saying.) And, your code doesn't handle attributes or empty tags properly. But it's true that the Python equivalent would need to make some compromises to avoid getting completely hairy -- starting by either putting the HTML pseudocode into a string or throwing parentheses all over the place.

DSLs aren't Python's strong point. Some options are:
- Some string transformations, then eval()
- A recursive operation on a dictionary, since HTML in particular kind of fits that model
- Just use a library like xml.etree for whatever you were actually trying to do (I know, that's just what a Java programmer would say)
- Full-blown parser and interpreter, with some help from the standard library

But the specific case isn't that interesting. Almost all of the capabilities (not necessarily basic features) are the same between the latest incarnations of Ruby, Python, Perl, and JavaScript -- where one's missing a feature, there tends to be at least a workaround.

The main difference between Ruby and Python is that Guido doesn't like functional programming, but really likes structured C, Unix, and teaching languages. Matz seems to really like Common Lisp and Smalltalk, but recognizes the need to git 'er done, Perl-style, too. Guido's background is in big organizations; Matz's is in compilers. They're both brilliant.

So Python code looks almost exactly like C pseudocode, and the real-world code often looks just as clean as the tutorial examples (in contrast to, say, C++). If you write something that runs correctly and efficiently in Python, it will generally look reasonable to any other programmer, too.

Ruby instead takes every standard programming style and makes it easy to express an idea that way. If you already understand FP, OOP, etc., it's incredibly expressive. I think an experienced, well-rounded hacker tends towards Ruby... but a company like Google is sane for mandating that their gargantuan codebase, written by thousands of adventurous coders with differing styles and tastes, should be mostly Python.

Re:Why Ruby?

[DragonWriter]

Tell it to the ruby.com or rubyonrails.com websites.

Are you perhaps thinking of ruby-lang.org? Ruby.com has nothing to do with the Ruby language.

They all rely upon PHP to scale their sites. This is a well known fact stated over and over again and that the RUBY maintainers are aware of but that the RUBY community calls a flame or FUD.

IIRC, ruby-lang.org used PHP before Radiant CMS was developed, and rubyonrails.(org/com) uses, or used, PHP for some peripheral roles, but is mostly (maybe entirely now) Rails.

But, if you've got actual evidence that they currently use PHP for scaling, as you claim, on either of those sites, please, present it. But I'm not going to take claims about the main ruby or rails websites on faith, especially from someone who doesn't know where one of those sites is located.

Re:Why Ruby?

[Anonymous Coward]

As a Rubyist, I find the important question to be "is there a method to do this". In Ruby, if something can be made into an array, you use the to_a method. In Python, you won't be using a method. Ruby's Kernel.Array is an interesting bit of syntactic sugar (granted, Ruby has a bit much of that), but it isn't particularly relevant here.

As a Rubyist, I find this is a useless question, in the absolute; in the pathological case, you could add every method to every object and call it perfect.

The question, however, is why? Why do you need to learn more syntax to enter multiline strings?

You don't. You can use triple-quoted strings in Python for everything. You only need to learn one syntax to write a string, in either language.

Why do you need to learn 4 completely different syntaxes (<<, ", ', and %w) in order to *read* a string constant in Ruby? Ask any newbie Rubyist to tell the difference between these. In my experience, they're clueless about %w (and there's not even really an easy place to look it up!), and can't tell you the difference between the others reliably.

Re:Why Ruby?

[iluvcapra]

Something particularly hazardous is the difference in ruby between a proc and a lambda. A Proc will execute using its creating context's binding, and if you use a return keyword, the return is bound to the creating continuation, not the calling one, more like an exception throw than a return (I guess this is why people rarely use a return in a Proc, and just let the last evaluated line speak for itself!) The return keyword in a lambda, however, is bound to the lambda's local continuation, and simply makes program flow leave the lambda back to the caller.

Re:Why Ruby?

[Foofoobar]

Evidence? sure... here you go. Here's a prime example. http://shiflett.org/blog/2006/feb/php-easter-eggs

If you can no longer see them it's because they have show_php turned off in their php.ini. You can still spot what they are running on Netcraft and ask them why they are running PHP and they will tell you; they have responded in the past to such inquiries with what I am telling you.

Re:Why Ruby?

[DragonWriter]

Why do you need to learn 4 completely different syntaxes (<<, ", ', and %w) in order to *read* a string constant in Ruby?

The string literal types in Ruby, then they are single-quoted (', %q), double-quoted (", %Q, %), non-indentable here document with double-quoting rules (<<), non-indentable here document with single-quoting rules (<<'), indentable here document with double-quoting rules (<<-), and indentable here document with single-quoting rules(<<-'). That's either 6 or 4, depending on whether you consider the difference between indentable and non-indentable here documents significant, but not the 4 you refer to.

%w and %W are two (different exactly as single- and double-quoted string literal syntaxes are) array literal syntaxes.

Ask any newbie Rubyist to tell the difference between these. In my experience, they're clueless about %w (and there's not even really an easy place to look it up!)

What is that parenthetical supposed to mean? I mean, look in the index of the pickaxe under "%w". What's the problem?

Re:Why Ruby?

[mr_mischief]

Trailing 'if' as a statement modifier works just as well as trailing 'unless' does. :s/unless/if/

That's not so hard in a proper editor. I'm sure Emacs has its own sensible way to replace text, too.

Re:Why Ruby?

[aevans]

Does Zope? Or Slashdot? Or Wikipedia? Or any web app?

Re:Why Ruby?

[poopingman]

As a Python programmer who learned Ruby to develop Rails applications, I have to agree. If you know some Perl and are happy with it, you will probably feel at home with a lot of Ruby's conventions. That being said, Ruby has some cool features language features that aren't in Perl or Python. (The code yielding stuff and passing code blocks, I'm thinking.)

If you don't like or know Perl and are happy with Python, it's probably not worth your time to learn Ruby unless there's some killer app you really want to play with (like Rails). To people like me with whom Perl never really clicked, certain conventions in Ruby might seem frustrating. (I'm looking at you, regex syntax! Instead of returning match values, let's put them in some arbitrarily named global variables! Yay!) They are both great languages, though, as long as you are willing to spend the time necessary to get to know them.

Re:Why Ruby?

[jadavis]

I disregarded python for the same reason... until I actually tried it.

Re:Why Ruby?

[jadavis]

I think Ruby is really an evolution of Perl. There are a lot of Perlisms in its syntax, and I bet it'd be very easy for a Perl programmer looking for something new to learn Ruby.

That's what I thought at first, but now I would disagree strongly with that statement. I learned perl, then python, then ruby, in that order.

Ruby appears very superficially similar to perl, but it's very different. There are many things perl is great at ruby is horrible at, and it's really hard for a perl programmer to get past that (at least for those problem domains).

For instance, perl has great documentation for almost everything you could want to do, particularly for CPAN modules. Even if something is not "officially" documented well, you can almost always find examples in abundance from google, and that makes the turnaround time on a working product very fast (and a lot of the reason people love perl). Additionally, there are many available modules, and they are often well-designed. In Ruby, documentation is sparse, often incorrect, and modules are often unstable or poorly designed.

This isn't meant to mean that perl is better than ruby, I really like ruby. I'm just saying that it's very hard for a perl or python programmer to accept those shortcomings. Once I realized that, I was able to start using ruby for the things it's great at. I think the ruby language is good enough that it could be great in many problem domains, but that will require a huge amount of focus on quality, stability, and documentation for a wide range of modules.

Re:Why Ruby?

[darrinallen]

I like Python. I am new to Ruby. I am checking out a book from the library to learn Ruby. It should be easy to learn

FFI

[r6144]

Back then Ruby's C interface appeared much easier to use than Python's reference-counting mess (I don't know about recent developments). Apart from that, both are good as far as scripting languages go.

Scalability?

[Foofoobar]

Yes but th question that everyone will be asking is can it scale yet. To date, RUBY has been great with hype but most professional developers (once adopting RUBY) find out it's limitations within a matter of weeks. So while it may have improved upon speed, the question still is whether it can scale without having to rely upon PHP and JAVA and PYTHON consistently to help it out in this regard.

Re:Scalability?

[bladesjester]

So while it may have improved upon speed, the question still is whether it can scale without having to rely upon PHP and JAVA and PYTHON consistently to help it out in this regard.

You seem to be thinking of Rails, which is a framework for Ruby used for making web apps.

Ruby itself is quite nice for general development work.

Re:Scalability?

[PaulK]

That is entirely accurate. There are situations where your Python proficiency will be called upon to support Ruby, (DBF handling comes to mind).

Re:Scalability?

[Foofoobar]

No, talking about the language not the MVC architecture. RUBY itself has trouble scaling; RAILS makes the problem a bit worse but if the problem wasn't there to begin with, it wouldn't be that noticeable with a good MVC framework.

But RUBY always seems to have to rely upon other languages to scale. The RUBY website uses PHP. The Rails website uses PHP.Seems every place that RUBY has to scale requires it to use another language and the RUBY maintainers have not tried to excuse this but the RUBY community has.

This is why most developer say that RUBY is still developing as a language as is good for small implementations that never ever intend to get bigger. But for those that want their applications to grow with them, they should implement in a language that can grow with them.

Re:Scalability?

[sciurus0]

Since you don't begin to define what you mean by scalability, I'll take that as FUD. However, scalability is one of the problems Ruby is trying to tackle. 1.9.0 marked the switch from green threads to os threads, but it' going to take awhile before extensions written in C are thread-safe. If you prefer the lightweight approach of green threads, take a look at fibers.

Re:Scalability?

[aldheorte]

You must be a troll or never used Ruby. In all languages today, Ruby, or Python, etc., performance is a problem with the developer, not the language. Also, languages are not by themselves slow, the virtual machines or interpreters are, so saying a language is slow is nonsensical.

Re:Scalability?

[Foofoobar]

Since you don't begin to define what you mean by scalability, I'll take that as FUD. However, scalability is one of the problems Ruby is trying to tackle

Um... so you agree that scalability is a problem but you say it's FUD?? By scalability, you must have a pretty good idea of what I am talking about to be able to agree with me and say it's a problem as well.

Re:Scalability?

[JanneM]

Ruby is not a web development language. It is a general scripting language, like Perl or Python. You still seem to conflate the language with the specific use case of Rails - dynamic website scripting.

I use it heavily as my general scripting language; where I would have used Perl for small utilities, file munging or what have you before, I now use Ruby. Not because Perl is bad - it isn't - but Ruby really is in many respects Perl done right, with many of the benefits and without the syntactic quirkiness. Scaling just isn't a factor for most uses of a script language.

Re:Scalability?

[bladesjester]

It seems like far too many people think that Ruby is just for web stuff because of Rails. They don't realize that it's a really good general purpose scripting language.

I think my two favorite things about Ruby when compared to Perl (which, like you, I used to use for scripting) are:
1) I can actually *read* it because it doesn't look like I rolled my head around on the keyboard
2) It behaves in Windows the same way it does in Linux (with the obvious exception of having to change any hard-coded filenames you use). Perl had a few quirks in that regard. Heck, let's be honest - the Windows implementation was not what you'd call complete (or at least wasn't the last time I bothered to check).

Re:Scalability?

[Anonymous Coward]

Why do you keep capitalizing the names of languages and frameworks that aren't acronyms? It's Ruby, Rails, Python, and Java. Capital letter at the beginning, since they're proper nouns, then lower case the rest of the way. You're just making yourself look like you really don't know what you're talking about.

Re:Scalability?

[mindsuck]

Excuse me but http://www.ruby-lang.org/ runs on Radiant CMS, which is written in ruby, not on php.

Re:Scalability?

[chromatic]

Heck, let's be honest - the Windows implementation was not what you'd call complete (or at least wasn't the last time I bothered to check).

Was this 1999? Perl's had first-class support on Windows since at least 5.6.0.

Re:Scalability?

[mini me]

What inherit flaw in Ruby prevents it from scaling? Do keep in mind that performance and scalability are not the same thing.

Re:Scalability?

[Anonymous Coward]

The performance of the Ruby website has gotten much worse since they switched from PHP.

Re:Scalability?

[Anonymous Coward]

As someone who has written a highly scalable website in Ruby (not Rails), I can attest that while Rails isn't inherently scalable, Ruby is very capable of being used in scalable apps.

Re:Scalability?

[Anonymous Coward]

Where to begin?

1. It doesn't even have a compiler. Sure, with enough boxes (if you're writing a server), it can go fast -- assuming your code can be parallelized. But this kind of stops you from being within a factor of 10 of compiled code. Matz famously said that it's a bad rip-off of Lisp, but "nicer to ordinary people". Most days, I really don't mind putting in some parens if it makes my code 10x faster.

2. It isn't well-defined. Virtually all of the high-performance, scalable language implementations available today have competing implementations, and I do not believe this to be a coincidence. I've never found a copy of the Ruby grammar, and from what I've heard, it doesn't really exist, except "what the ruby binary accepts" (am I supposed to read parse.y?). Not being well-defined means it's really hard for alternative implementations to appear. (I know about JRuby and Rubinius. Can you run any Ruby program on them out-of-the-box? I can compile any ANSI C or Fortran or Lisp code on any compiler that meets the spec.) How can anybody hope to fix any scalability problems in Ruby if the existing behavior is defined only by its current behavior? Have you *seen* a Ruby AST? Not pretty!

3. Scalability today means using the multiple cores that my processor has. Ruby provides no real means for doing this (e.g., native threads). Sure, you can launch multiple ruby processes, and chat between them with IPC, but look at the overhead of a ruby process: do you really want users to pay that 2 times, 4 times, 8 times?

If you want to go far enough back, then no, there's nothing "inherent" that means the Ruby language can't ever be scalable. (There's a project called "The Ruby Grammar Project" which aims to figure out and document the grammar, for example! It's "pre-alpha".) The point is that they've done kind of a lousy job with performance, specification, compilation, and so on up to this point. To expect scaling to become a priority any time in the near future (especially when seemingly large features like real Unicode support are soon to be added) seems foolishly optimistic.

Disclaimer: I make a living writing Ruby code. The above is intended to be friendly criticism, not a condemnation of Ruby. Most other languages are just as bad, if not in these ways, then in others. But I'd be lying if I said Ruby got an A+ in scaling today, or is even within shooting distance of it.

Re:Scalability?

[WNight]

1) Depends on what you're writing. big_array.collect {|x| x.expensive_file_io }.sort_by {|x| x.to_s } is going to be stuck in library code far more than interpreting Ruby.

2) Granted. Yet the Ruby community seems more cohesive than other languages. JRuby and Rubinius are intentionally staying close to Ruby. Of course, in JRuby, much of what you do wouldn't work without the J, so it's not back-portable, but technically would be.

3) See 1. A ruby process only wastes the time interpreting and garbage collecting that you design it to. IPC does take longer than inter-thread, but most server type projects I've written in Ruby are meant to scale across machines as well as CPUs, so they tend to synchronize via a DB or filesystem rather than directly anyways. Lack of native threads is a pain, but doesn't seem to actually impact performance if you design for processes vs threads.

I agree with your concerns re Ruby's spec itself. Lack of defined grammar, etc. But I don't think Ruby's performance problems are as serious as people say. Sure, any given component might have horrible problems, and might be too hackish to fix (Camping), but that's more a reflection of how easy it is to write a web framework (Camping, under 4k of code, intentionally) and how they aren't as well developed as a larger project would be.

Ruby's odd inconsistencies and little failures (eg. no real x.become y, even with evil.rb) often make me want to learn Smalltalk though.

Re:Scalability?

[KieranElby]

Also, languages are not by themselves slow, the virtual machines or interpreters are, so saying a language is slow is nonsensical.

Well, yes and no. One can meaningfully say that "Language Foo is harder for an implementation to optimise than language Bar". In practice "harder" will often been completely infeasible.

Here's some examples I've plucked out of the air:

• 32-bit integers with silent wrap-around (e.g. Java) generally map much closer to the hardware than do unbounded integers (e.g. Tcl 8.5).
• A compiler / interpreter can infer many things about a C++ function (whether it has side-effects, names and types of all the local variables it uses) which it can't about a Ruby method since a Ruby method can always call "eval" (or call a method which calls eval).
• I'll pick on C for a change - a headache for C compiler writers is pointer aliasing; the compiler cannot safely make some optimisations since it cannot be sure whether two pointers could be referencing the same thing. This is generally less of a problem in FORTRAN.

Having said all that, I'd far rather develop in Python, Tcl or Ruby than in C++, Java or C#, despite that fact that programs written in the latter languages are likely to run faster on most conceivable implementations.

IMHO, Clarity and expressiveness is far more important than performance for at least 95% of code written (and the other 5% can always be done in something from the C family if it's not an algorithmic performance problem).

Re:Scalability?

[KieranElby]

Scalability today means using the multiple cores that my processor has. Ruby provides no real means for doing this (e.g., native threads). Sure, you can launch multiple ruby processes, and chat between them with IPC, but look at the overhead of a ruby process ...

Umm, you seem to be confusing performance with scalability here.

I'd say that a program based on processes communicating via IPC is far far more scalable that a program based on threads sharing memory.

The processes + IPC program can be distributed across several machines; the threaded program cannot. The fact that the threaded application is slightly faster is irrelevant since it cannot scale beyond a certain point.

It's easy to forget that hardware costs very little compared to developers' time.

Disclaimer: I make a large part of my living writing server-side Tcl code (which is about on a par with Ruby performance-wise I believe).

Re:Scalability?

[Anonymous Coward]

Being one of the guys doing the german translation of ruby-lang.org: this is incorrect.

The ruby site uses Radiant, which is a CMS based on Rails.

Both Ruby and Rails are production ready and is ready for large implementations (as you can see on... for example... mtv.com ? ) The "scalability discussion" is a leftover from twitter.com whining that their traffic shot through the roof and them hoping that their framework would fix that (instead of buying new hardware).

Re:Scalability?

[Anonymous Coward]

1. Performance and scalability are different things.

2. Performance and scalability are different things.

3. Performance and scalability are different things.

You've made some nice arguments as to why Ruby is slow, but I'm not sure anyone has ever claimed Ruby is fast. On the scalability front, however, it does just fine.

Re:Scalability?

[chromatic]

But this kind of stops you from being within a factor of 10 of compiled code.

I've written a few IO-bound applications. C doesn't select(2) measurably faster or slower than Ruby or Perl or Python.

Re:Scalability?

[Count Fenring]

Now I'm no fancy-pants city programmer, but I do believe that the sole (or "reference and 90% of all implementations use it," in this case) interpreter being slow kinda counts as the language being slow, or near as makes no difference. As for trolling, well, you did seem to be deliberately misinterpreting a pretty clear statement, for purposes of raining on this fellow's parade.

Re:Scalability?

[lazyatdayjob]

Ummm... No...

If you would bother to read, the Ruby language website runs on Radian CMS, a Rails based CMS. The Ruby on Rails website uses instiki, another Ruby on Rails based application that was also developed by DHH.

Rather that spreading FUD, put some facts behind your statements. Because I know many large scale sites that I have worked on or helped, that use rails, and we have moved past scaling issues.

Re:Scalability?

[ctzan]

Also, languages are not by themselves slow, the virtual machines or interpreters are, so saying a language is slow is nonsensical.

Maybe in theory. For instance, there is only one implementation of Perl, there's no formal specification of the Perl language (the language is defined by its standard implementation), and there's absolute 0% hope of someone being ever able to do another bug-a-bug compatible interpreter. The same applies to Ruby, I think.

Then, most dynamic languages are forcing the implementors to keep type information at run-time, to do garbage collecting, etc. All that comes at a price. It's simply impossible to get it as fast as a static language like C or Fortran, even if you were to design special hardware for it (like Lisp machines).

Re:Scalability?

[Foofoobar]

Never said it was written in PHP. Said they USE PHP in order to scale and that is their official response.

Re:Scalability?

[DragonWriter]

Um... so you agree that scalability is a problem but you say it's FUD?

Scalability is a general problem, and one that Ruby's development is seeking to address. But its FUD to say its a particular problem with Ruby without some actual measures or other evidence of particular scaling problems that are actually connected to Ruby. Usually, if people are pressed on these kind of accusations, they point back to the twitter thing which:
1) At the outset was suggested to be a problem with the Rails framework, not Ruby,
2) Twitter developers eventually stated wasn't really a particular problem with either Rails or Ruby.

Re:Scalability?

[DragonWriter]

Maybe in theory. For instance, there is only one implementation of Perl, there's no formal specification of the Perl language (the language is defined by its standard implementation), and there's absolute 0% hope of someone being ever able to do another bug-a-bug compatible interpreter. The same applies to Ruby, I think.

To a certain extent, though mitigating that seems to be the focus of some effort. JRuby is, as I understand, mostly compatible with some important caveats, and there are other alternative Ruby implementations that are more-or-less compatible. One of the big pushes with 1.9.0 seems to be working toward a clear delineation of what features are necessary to generalized Ruby and what are specific, less-portable features of the principal implementation, with a particular eye to what is practically implementable in, e.g., JVM and CLR (and maybe Parrot) based implementations.

Then, most dynamic languages are forcing the implementors to keep type information at run-time, to do garbage collecting, etc. All that comes at a price. It's simply impossible to get it as fast as a static language like C or Fortran, even if you were to design special hardware for it (like Lisp machines).

Lisp machines were abandoned, IIRC, because they had become slower than Lisp implementations on more conventional hardware of the day, because most of the investment was going into development of conventional processors. But, yeah, while mature dynamic languages (like many Lisps), from what I've heard, can be very fast, there is some inevitable overhead. So if speed given fixed hardware constraints is an overwhelming issue, C may be the only choice. In most real world situations the constraint is money, so if a dynamic language for all or part of a system reduces development and/or maintenance costs, you can afford to throw more hardware at it to address performance issues, provided the implementation can make effective use of the hardware.

Re:Scalability?

[midnighttoadstool]

A highly dynamic, introspective language, like ruby, is by its nature going to be a slower language. And Ruby is one of the most dynamic, and one of the slowest. Python is also dynamic, and is also slow for it. These languages are NEVER going to be fast. Whereas Java's dynamic/introspective languages features are so limited they have no practical performance penalty.

Who's the troll here?

I'd like something else.

[jd]

Faster is good, but faster is not enough. Parallelization, these days, involves multi-LAN, multi-node, multi-CPU, multi-core systems where each core may or may not also be a vector processor. Modern libraries for handling such code tends to be usually too primitive to effectively handle anything but simple cases of even very narrowly-focussed software. If you want to parallelize across a combination of types, forget it. There are ways to do it - such as CORBA - but they're too slow and/or too complex. There are also languages modified to handle the complexities of parallelization, such as Unified Parallel C, Parlog or Occam, but they're usually much too complex to use in practice.

Is parallelization the only niche that isn't supported well? No. There are other areas languages generally do badly in. There are very few languages which handle internationalization efficiently. There are very few languages which handle graphical interfaces efficiently or logically. Languages are typically either good at handling very complicated data structures OR handling structures that are defined just-in-time, typically not both.

My interest in Ruby would be greatly increased if I saw it do something that very few other languages could do, preferably no language that was in mainstream use.

Re:I'd like something else.

[fat_mike]

Aww, you sound like a sweet, naive student who just posted from the notes his bitter Comp Sci professor gave him.

Never mind, this sounds like a "hey guys, check out my term and look at my conclusion" post.

Read your post again, and ask yourself if you made any attempt at supporting yourself, listed any facts, or did your "My interest in Ruby would be greatly increased if I saw it do something that very few other languages could do, preferably no language that was in mainstream use" just for the purpose of us validating it.

I mean, that is the most blatant conclusion, guaranteed not to piss off a Comp Sci professor and not point any attention to yourself...Fuck it, you'll get an A.

Re:I'd like something else.

[Anonymous Coward]

Faster is good, but faster is not enough. Parallelization, these days, involves multi-LAN, multi-node, multi-CPU, multi-core systems where each core may or may not also be a vector processor. Modern libraries for handling such code tends to be usually too primitive to effectively handle anything but simple cases of even very narrowly-focussed software. If you want to parallelize across a combination of types, forget it. There are ways to do it - such as CORBA - but they're too slow and/or too complex. There are also languages modified to handle the complexities of parallelization, such as Unified Parallel C, Parlog or Occam, but they're usually much too complex to use in practice.

Have you tried Erlang? I'm guessing you have, but thought I'd ask just in case.

Re:I'd like something else.

[jd]

My BSc was over 16 years ago, my MPhil was over 11 years ago. Much of my professional career has involved client/server systems, distributed computing, grid computing, embedded computing and high-performance computing. My open source contributions include a MIPS port of an open source MPI package, work on clustering and multicast-based CORBA technology. My protocol standards contributions include work on using scalable reliable multicast alongside RDMA to do efficient one-to-all and all-to-all operations (ie: not sequentially, as is implemented in most open source MPI implementations). My hardware experience has included programming meshes of T800 Transputers, UltraSPARC clusters, Broadcom BCM1250 clusters and high-end multi-core x86 processors. Amateur projects have included using distributed computing to perform signal processing and data analysis from ground-penetrating RADAR and magnetometers being used by an archaeological group.

If you want the evidence, the data, the background, I've no objections to stating it. Well, with the exception of commercial projects still covered by non-disclosure agreements. Even if the company betrayed not only me but also the other software engineers there, resulting in engineers being deprived of rightful wages, forced out or removed under false pretenses. I have ethics, even if they do not. The bulk of my experience is NOT covered by any NDA, but is a little on the lengthy side. People get paid good money for writing books with less content. If you actually want to know, I have no objections, but it's not something anyone would be willing to read on Slashdot as a reply or even as a main article.

Re:I'd like something else.

[jd]

Erlang is good, and is an example of a language that is very usable in some of the niches that are under-developed. There are a few projects written in Erlang, and I would expect that to increase over time as Erlang technology improves and as more people become aware of it. It would probably help if there was more reference to it on Slashdot, LWN and Freshmeat.

Re:I'd like something else.

[dkf]

Erlang is good, and is an example of a language that is very usable in some of the niches that are under-developed. There are a few projects written in Erlang, and I would expect that to increase over time as Erlang technology improves and as more people become aware of it. It would probably help if there was more reference to it on Slashdot, LWN and Freshmeat. All that takes is writing good articles about news that people want to read. Really.

Re:I'd like something else.

[Anonymous Coward]

Check out Haskell, specifically GHC's parallel library, which has an occam-like 'par' and 'pseq' commands. There's also Erlang, which has recently had a very good book entitled "Programming Erlang" released by the Pragmatic Programmers.

Re:I'd like something else.

[jd]

I will. I, for one, would be more aware of the brilliant features in Haskell programs (and Haskell in general) if information on it was a little better circulated. (A few of the records on Freshmeat had gathered so many cobwebs and so much dust that they looked like something from a 60s horror movie.) The same is true of Erlang, and many other "obscure" languages - obscure because it's below the radar of many who would be interested.

Now, I would not call myself remotely qualified to write an article (or a book) on Haskell, Erlang, Pi-Occam, or any of the other fascinating languages out there, but I'm bothered by the rarity (and sometimes total lack) of any such text from people who are qualified. At this point, I'm tempted to write such disgracefully bad books on these subjects that the experts are compelled to write stuff worth reading out of sheer disgust. Or maybe the mere threat of me writing will be sufficient.

Re:I'd like something else.

[chromatic]

Programming in Haskell by Graham Hutton is a good introduction to the language. I'm waiting for Real World Haskell too.

Re:I'd like something else.

[sporkmonger]

It's probably not what you're looking for, but Ruby's standard library provides a Linda-like approach to distributed computing. It's works quite well, though it's certainly no Erlang.

Re:I'd like something else.

[Anonymous Coward]

haskell.org is a great portal for all things Haskell, including the weekly news, Hackage (SF for Haskell) Planet Haskell, language reference etc.

There's are a few books on Haskell out there. Haskell: The Craft Of Functional Programming by Simon Thompson is decent enough and Programming in Haskell by Graham Hutton is well-reviewed (I haven't had a chance to read it as I'm broke). Free-content wise, the Wikibooks Haskell tutorial (known as YAHT - Yet Another Haskell Tutorial) and Write Yourself A Scheme in 21 days are both supposed to be worth a read.

As previously mentioned, Programming Erlang is really the book that Erlang has been crying out for, much like Programming Ruby was for Ruby.

I don't think there's much out there for Occam-PI, particularly when the main compiler (KRoC) isn't even packaged for most distros (notably Debian). Occam is pretty much a dead language, like it or not. "Programming in occam2" is out there and freely available though, but I don't think it's worth using at this point in time, sadly.

Re:I'd like something else.

[bill_mcgonigle]

My interest in Ruby would be greatly increased if I saw it do something that very few other languages could do, preferably no language that was in mainstream use.

I'm waiting for somebody to write a Ruby to Erlang-bytecode compiler. Heck, even a Parrot compiler would be welcome, so I can write in Ruby and use CPAN. *That* would be something no languages can do now (efficiently, anyway). It wouldn't be for just one language, though, they'd all win.

Re:I'd like something else.

[chromatic]

There's a Ruby implementation on Parrot called Cardinal. It stalled for a while until the Parrot 0.5.0 release in November, but that should have cleared the next few roadblocks.

Re:I'd like something else.

[bill_mcgonigle]

*cool* - thanks!

Linkage for others. Status: "Parser is pretty complete. Generates PIR for basic Ruby programs"

Re:I'd like something else.

[DragonWriter]

All that takes is writing good articles about news that people want to read.

I don't know about LWN or Freshmeat, but for Slashdot the "good", "news", and "that people want to read" features all seem optional.

Re:I'd like something else.

[Tablizer]

Is parallelization the only niche that isn't supported well?

What is it specifically you are trying to do? Couldn't you split the task into separate processes (launch different program instances)? One can use the file system or a relational database to coordinate and communicate between processes.

Temporary URL for the benchmarks

[Anonymous Coward]

The site with the benchmark has been "slashdotted" but should be back up soon. For the moment, if it's down, you can use this Italian translation which has English figures and charts: http://stacktrace.it/articoli/2007/12/ruby-contro-ruby/

Lisp

[Anonymous Coward]

Guido tried Lisp and he didn't understood it.

Matz tried Lisp and he understood a little.

Matz wins.

Different style of programming

[Estanislao Mart�nez]

Alright, I know this is going to be flame fodder, but I'm genuinely curious: does Ruby have anything to offer for someone who's already very proficient in Python (and Django, so Rails is already covered)?

If you look at it from a features and libraries perspective, then you really won't find much different. But you shouldn't look at it that way.

There's a significant programming style difference between the Python and Ruby communities. Python programmers, as a general rule, tend to be more inclined toward imperative programming, while Ruby has much more of the feel of a multi-paradigm language. To understand a lot of Ruby code out there, you need to wrap your head around concepts like functional programming, metaprogramming, and domain-specific languages. Ruby code tends favor higher-order functional combinators over primitive looping syntax (an influence from functional programming), extending the system base classes extensively (an influence from Smalltalk), and a lot of it has the flavor of trying to extend the language to look more like the problem space itself (domain-specific languages; look at something like rake, for example).

Python aims to be "clean" in a very contentious sense of "clean." To put it in a way that will be taken very partisanly: Python is the language that you get when "clean and easy to understand" is taken to mean "only promotes the concepts that are easy to understand to a mediocre imperative programmer." For example, Guido is on the record that higher-order functions like reduce are supposedly hard to understand.

To be fair, yeah, Python is a reasonably clean imperative/OOP dynamic language, which is no mean feat, but many of us folks really would rather have a language that supports a broader range of programming paradigms. (Though I'm not as great of a fan of Ruby as I used to be before I got going on Scheme, I must say...)

Re:Different style of programming

[chromatic]

To understand a lot of Ruby code out there, you need to wrap your head around concepts like functional programming, metaprogramming, and domain-specific languages.

I would have said "blocks, string eval monkeypatching, and vigorous self-handshaking by people far too awesome to write mere APIs". Of those, blocks are the only interesting concept.

Re:Different style of programming

[Estanislao Mart�nez]

I would have said "blocks, string eval monkeypatching, and vigorous self-handshaking by people far too awesome to write mere APIs". Of those, blocks are the only interesting concept.

Nope. I only really think you have a point in the "string eval monkeypatching" bit there. Ruby doesn't have Lisp-style macros, so the way they do metaprogramming with eval is pretty crap. The block syntax isn't as good as having first-class lambdas, either, so you're running a risk of overrating Ruby blocks there.

Domain-specific languages are a widespread technique. The dominant, crappy version is called "XML."

Re:Different style of programming

[chromatic]

The block syntax isn't as good as having first-class lambdas, either, so you're running a risk of overrating Ruby blocks there.

Ruby does have first-class lambdas, but the block/proc distinction can be kind of a problem sometimes.

Domain-specific languages are a widespread technique.

I'm familiar with domain specific languages: m4, regular expressions, procmail. Passing a hash of parameters to a method does not make a DSL. It's an API, no matter how many parentheses you remove from the argument list or how many colons you slap on bare-words.

Re:Different style of programming

[Estanislao Mart�nez]

I'm familiar with domain specific languages: m4, regular expressions, procmail.

You need to learn some Lisp.

Passing a hash of parameters to a method does not make a DSL. It's an API, no matter how many parentheses you remove from the argument list or how many colons you slap on bare-words.

The philosophy behind embedded DSLs is to "build up" your language to the point where your programs read, ideally, like descriptions in the problem domain. It's not possible to give it a very precise definition of what the approach is (even less so than in the case of the notoriously unclear "Object-Oriented Programming"), but one thing is clear: embedded DSLs are a kind of API, and there is no obvious dividing line between "just an API" and an embedded DSL.

The most classic sort of example is embedding a Prolog-like logic programming system into Lisp. Ruby's rake isn't too bad of an example, though; it's not because parentheses were removed, but rather, because rakefiles are declarative descriptions of tasks and dependencies between them.

Re:Different style of programming

[chromatic]

... embedded DSLs are a kind of API, and there is no obvious dividing line between "just an API" and an embedded DSL.

Sure there is. If you have to write a parser, you've written a new language -- you're no longer using a subset of the syntax and semantics of the host language. Merely choosing expressive nouns and verbs where the language already allows you to choose nouns and verbs is not creating a DSL. It may be using language specific to the domain, but it's not creating a new language.

Hygenic macros or manipulating the AST directly is closer to the line, but when you can change the actual semantics of the host language, you have something different.

I haven't ever seen a so-called Ruby DSL that actually did anything other than slap meaningful names on method calls and classes.

Re:Different style of programming

[DragonWriter]

By your standard, it would seem that only what I've heard referred to as an "external DSL" is a real DSL. You can do them in Ruby quite easily, but "internal DSLs" are more useful because then there isn't a firm line between conventional Ruby code and the DSL.

Hygenic macros or manipulating the AST directly is closer to the line, but when you can change the actual semantics of the host language, you have something different.

Anytime you define a new function you are changing the semantics. Are you talking about changing the syntax of the host language? If macros and manipulating the AST directly are only "close to the line", you seem to be really eliminating the idea of internal DSLs (as I suggest above). That's certainly a not-unreasonable way to think of what "Domain Specific Language" might mean to you, but when you define it that way you are well on your way to speaking your own private language.

I haven't ever seen a so-called Ruby DSL that actually did anything other than slap meaningful names on method calls and classes.

The entire reason Ruby is hailed as being good for writing DSLs is that you can do things within Ruby with little more than well-chosen method names, classes, and a few minor hacks (often involve method_missing) that would take writing a parser and doing more complex work in other languages, allowing you to do in internal DSLs what would take an external DSL in many other host languages. Admittedly, you can do more with internal DSLs in some homoiconic languages like Rebol or various Lisps, but the former isn't F/OSS and the latter are (perhaps unfairly) unpopular for other reasons.

Re:Different style of programming

[chromatic]

Anytime you define a new function you are changing the semantics.

I can't see how. Just about every language I've used that supports functions allows you to define your own functions of variadic arity. The semantics are "functions take arguments", and you don't get much choice of whether you pass by reference or value, for example, or whether arity is fixed or checked at compile time or types are checked or what.

The entire reason Ruby is hailed as being good for writing DSLs is that you can do things within Ruby with little more than well-chosen method names, classes, and a few minor hacks (often involve method_missing) that would take writing a parser and doing more complex work in other languages...

... except for languages such as Perl, Smalltalk, PHP, Lisp, Scheme, and I believe Python and Tcl. This list is not exhaustive.

It's amusing and a little disturbing to see all of the fervor in some parts of the Ruby community as if they'd invented something that the rest of us haven't been doing in several other languages for, in some cases, decades. Me, I'm waiting for them to invent LLDD (linked-list driven development) when they get tired of BDD. (I suppose you can link a list of test cases to the desired external non-programmer behavior of a project.)

Re:Different style of programming

[DragonWriter]

... except for languages such as Perl, Smalltalk, PHP, Lisp, Scheme, and I believe Python and Tcl.

Yes, almost all, perhaps all, of the things (including with regard to DSLs) that Ruby is noted for being good for, one or more of those languages is also good at. So what?

It's amusing and a little disturbing to see all of the fervor in some parts of the Ruby community as if they'd invented something that the rest of us haven't been doing in several other languages for

As far as I can tell, no one in the Ruby community is claiming that Ruby or the Ruby community invented most of the things it is known for doing well, only that it does that particular set of things well. Yes, its strengths overlap those of certain other languages. Naturally, Smalltalk, Lisp, and Perl -- which are Ruby's primary inspirations -- will have considerable overlap with Ruby's strengths, and in many cases be stronger in the specific areas from which Ruby borrows from each. And similarly naturally, other dynamic scripting languages which draw inspiration from some of the same sources will also overlap in strengths.

You seem to be irrationally infuriated by claims that no one outside of your imagination is making.

Re:Different style of programming

[chromatic]

As far as I can tell, no one in the Ruby community is claiming that Ruby or the Ruby community invented most of the things it is known for doing well...

Why Use a Language-Powered Domain Specific Language?, by Cosine Jeremiah, or Knowing Ruby and Perl for an even better example.

Cosine didn't use the word invented specifically, but my claim is that there is a very vocal coterie in the Ruby community that seems to pride itself on slapping new names on old, old practices and parading them around as if they were new.

Re:Different style of programming

[chromatic]

I apologize for the second reply, but I just found the post which amused me the most. To wit:

However, once again I was floored by how much less intuitive things are outside of Ruby... Perl is not really capable of DSLs....

— Cosine Jeremiah, Back to Perl.

For fun, try to find out what he means by "DSL".

Re:Different style of programming

[DragonWriter]

Cosine didn't use the word invented specifically,

In fact, he doesn't even imply "invented".

In the first, he discussed his view of Ruby's superiority to Perl in the area of "language-powered" (i.e., internal) DSLs, and some discussion of the advantages of internal DSLs and when using internal DSLs is appropriate vs. external DSLs that (except for the specific examples of the author's experience) isn't particularly Ruby-centric but fairly broadly applicable to most languages where both internal and external DSLs are practical options.

The second (which you claim is a "better" of implicit claims of Ruby's inventing things) is kind of a wandering discussion of things the author didn't realize that Ruby allowed, and whether or not the author really knows Perl better than Ruby. Again, it doesn't even implicitly make any reference to Ruby inventing or innovating compared to the whole palette of other languages available, or even make comparisons, explicitly or implicitly, between Ruby and any language other than Perl (or, I suppose, if you squint at it right, C).

my claim is that there is a very vocal coterie in the Ruby community that seems to pride itself on slapping new names on old, old practices and parading them around as if they were new.

Maybe there is such a "very vocal coterie", but if the two examples you point to are the best examples you can present, I don't think you have a very good basis for that claim. Now, certainly, I've seen lots of examples (with any new language) of people who don't have lots of experience with its antecedents seeing something for the first time in the new language that exist in its inspirations and pointing to that as something the new language brought to them and, less often, to programming in general. I've seen it with Ruby, with Python, with Java, with C++ (which, back when it was trendy and relatively new rather than stodgy and old, I saw people credit with OOP as if it was a C++ innovation), etc. So I'm hardly surprised that users of a language mistake the things it revealed to them with innovations. But, really, so what? Is it a bad thing that a language provides and introduces useful techniques to people who for one reason or another missed the preceding language that provided support for the technique, or were turned off by some other feature of that language before they discovered the technique?

Re:Different style of programming

[DragonWriter]

For fun, try to find out what he means by "DSL".

I don't know why you suggest that looking up his coherent response to what appears to be you (or at least, someone in the Perl community who uses the same handle you do here) on the topic, which is focussed on external DSLs here. And, of course, the posts you pointed to earlier discussing Cosine's view of Ruby's superiority are further developments of that post focussing more on internal ("Language-powered") DSLs.

So, apparently, you are a Perl-fan upset because a Rubyist has said that Ruby has better than Perl for DSLs, and has blown that up into a fantasy that the entire Ruby community is obsessed with claiming that Ruby invented everything.

I mean, seriously, you've so far posted three examples of this supposed trend in the Ruby community, and all three are posts from one blogger that aren't about Ruby inventing anything (in fact, in the post you point to in the parent, he specifically credits the feature going back to Lisp), but simply about that one particular blogger's view of Ruby's utility in that domain vs. Perl's.

Re:Different style of programming

[chromatic]

... the entire Ruby community...

If you had read my posts with any degree of caution whatsoever, you would have noticed that I was very careful to suggest that only a small portion of the entire Ruby community exhibits this behavior.

Re:Different style of programming

[DragonWriter]

If you had read my posts with any degree of caution whatsoever, you would have noticed that I was very careful to suggest that only a small portion of the entire Ruby community exhibits this behavior.

Even so, the examples you've posted are all the same one person, and none of them exhibit anything even remotely resembling the behavior you have described. None of them involve even so much as an implicit suggestion that Ruby invented any of the practices or features described. They simply argue that Ruby supports a technique (or two techniques, if you consider internal and external DSLs distinct approaches) with considerable history (the author specifically credits Lisp) better than Perl.

Re:Different style of programming

[mr_mischief]

On what grounds is the claim made that ruby supports DSLs better than Perl?

Does the author mention any of:

Parse::RecDescent, Parse::Yapp, Parse::Earley, Parse::EBNF, Parse::Plain, Tree::Parser, Text::Diff::Parser, Parse::NMap, Mail::Address, Parse::Tinymush, Lingua::TokenParse, Parse::MediaWikiDump, Rosetta, Apache::ConfigFile, WWW::RobotuRules::Parser, Graph::Easy::Parser, Parse::Tokens, Metacode::Reader, MIME-tools, Config::Seting::IniParser, Config::Setting::XMLParser, Data::SExpression, Mail::Cap, BIND::Config::Parser, Parse::Flex, MRTG::Parse, YAML, Email::Received, Gnus::Newsrc, Parse::YALALR, Parse::CLex, Parse::Lex, Parse::Token, Parse::YYLex, CSS::Parse, PDF::Parse, Text::Template, the Template Toolkit, HTML::Template, OODoc::Template, XML::Template

or many other parser tools, specific implementations of support for prexisting little languages, whole new little languages, or the strengths of Perl as a parsing and text munging language?

The whole "internal DSL" moniker just sounds like flexible and intuitive syntax. That's a good thing, but does not constitute a DSL as any other definition I've seen describes them. Perhaps it does need terminology, but you might find that with regular expressions, source filters (considered questionable practice, but still), formats, an interesting prototype system, eval, and the above modules that Perl has pretty darn good "external DSL" and "internal DSL" support. So do Lisp, Scheme, Haskell, and many other languages.

Forth is built on your idea of "internal DSLs", BTW. Data stacks, postfix syntax, and an executable library are the three basics idea of the language.

Is it a point-by-point comparison or just the author's unqualified opinion? Which points does the author consider, on which of those does Ruby score better than Perl, and why?

If you're wanting Perl programmers to concede that Ruby is better based on a simple opinion, I think you're kidding yourself. If you (or the author alluded to) can give good reasons, you'll likely find many in the Perl community willing to listen.

As for me, I'm still not sure why I'd mess with either Python or Ruby as long as Perl work holds out. If I want some variation in languages, there are ones out there that vary much more than Perl, Python, and Ruby. I tried ABC years ago and didn't like it then, so Python already has one strike. Ruby looks to be an interesting mix of Perl, Smalltalk, and Lisp alright, but I can use those three independently or together without it. I can get Perl to act more like either of the other two.

Ruby might be worthwhile for its specific blending of them, but so far all I hear is how cool Rails is and how much better of a Perl Ruby is supposed to than Perl 5. Well, we have Catalyst, Mason, CGI::Application, and a hundred other web toolkits. Perl 5 is still being developed, and Perl 6 has useful stuff being written in it even though it's not completely finished just yet. Perl is much more mature, performs generally better from what I've seen, is much more widely supported, and has a much broader base of publicly available modules. I have no doubts that Ruby is a better Ruby than Perl is, but I think people who say Ruby is a better Perl than Perl 5 wanted Ruby in the first place.

Re:Different style of programming

[DragonWriter]

On what grounds is the claim made that ruby supports DSLs better than Perl?

Uh, read the links given.

The whole "internal DSL" moniker just sounds like flexible and intuitive syntax.

"Internal" or "Language-powered" DSLs are, indeed, an application of flexible syntax to produce intuitive constructs.

That's a good thing, but does not constitute a DSL as any other definition I've seen describes them.

This article claims to have coined the terminology, and certainly using "Domain Specific Language" to refer to such languages implemented through, e.g., Lisp macro systems which operated in the manner of what Fowler calls an "internal" DSL is not new.

Perhaps it does need terminology, but you might find that with regular expressions, source filters (considered questionable practice, but still), formats, an interesting prototype system, eval, and the above modules that Perl has pretty darn good "external DSL" and "internal DSL" support.

I might, indeed. So?

So do Lisp, Scheme, Haskell, and many other languages.

Not familiar with Haskell, but Lisp/Scheme certainly does, as does REBOL and, yes, many other languages.

Forth is built on your idea of "internal DSLs", BTW.

Its not my idea, but, sure. So?

Data stacks, postfix syntax, and an executable library are the three basics idea of the language.

Yes, they are. So?

Is it a point-by-point comparison or just the author's unqualified opinion? Which points does the author consider, on which of those does Ruby score better than Perl, and why?

If you want answers to those questions, read the links provided. Since I'm not endorsing or recommending the author's position (I don't know much Perl, and don't really have a position in the Ruby v. Perl argument -- I'm only pointing out that what the author did in the links that chromatic provided was make a claim about Ruby v. Perl regarding DSL, not claim that Ruby invented any of the features involved in the discussion) I don't really feel the need to regurgitate everything he writes in detail for you instead of allowing you to read it for yourself if you care. If you are just looking for a Ruby v. Perl argument here, well, sorry to disappoint you.

If you're wanting Perl programmers to concede that Ruby is better based on a simple opinion

I don't really give a flying flip whether Perl programmers concede that Ruby is better, either generally or in terms of DSL support, since I don't even have an opinion on those issues myself.

If I want some variation in languages, there are ones out there that vary much more than Perl, Python, and Ruby.

Probably. So?

Ruby might be worthwhile for its specific blending of them, but so far all I hear is how cool Rails is and how much better of a Perl Ruby is supposed to than Perl 5.

while certainly I've heard both of those, if that's all you've heard, you haven't really been listening to very much. But then again, I'm not trying to sell you on Ruby, so it doesn't really bother me.

Well, we have Catalyst, Mason, CGI::Application, and a hundred other web toolkits.

No doubt you do. So?

Perl 5 is still being developed, and Perl 6 has useful stuff being written in it even though it's not completely finished just yet.

Okay. So?

Perl is much more mature, performs generally better from what I've seen, is much more widely supported, and has a much broader base of publicly available modules.

No doubt. Though having more modules doesn't mean that it has better

Re:Different style of programming

[mr_mischief]

"Read the link given."? I ask for the examples the author gives of a specific point, and you want me to read all his rantings?

Keep in mind this author is the same guy who says, "Maybe there is some aspect of Perl I do not understand that makes it easier than I thought in Perl, and if so I would love to know. I still have to use Perl occasionally and so any advancement of that knowledge is useful, too. :) And actually, even though I still find it much easier to write DSLs in Ruby than in Perl, in writing this post's examples I discovered that writing a DSL in Perl was a lot easier than I thought it was."

I personally have never seen the use of Lisp macros referred to as a DSL. It's not a language specific to the domain, as it's still Lisp. The terminology might be in use somewhere but it makes little sense. Some other references where it's used that way might help the argument.

As for the tautological nature of my closing statement, I was simply keeping it in the terms I hear repeatedly from the promoters or Ruby. They claim to have a better version of Perl than the Perl folks. In some ways they may even be right. It's not a very good way to promote it to people who've already invested years in Perl. Specific examples of why it's better would be a good start. Fluff pieces, industry buzz, and the latest slick but narrowly focused toolkit don't mean much compared to programmer productivity in general.

I'm sure it's a great language for some, and might be better for someone with no Python, Perl, or Ruby experience to start with than Python or Perl. The authors who promote it as better than something else without reasons or with admittedly awkward use of the other languages only help to reinforce happy feelings inside the community. They do nothing to sway people who notice how awkward the author's work in the other language is. I'm sure even a COBOL fanatic can show that his language is more expressive and clear than, say, JavaScript if he picks specific examples and writes the other language poorly. By trying to treat Perl as Ruby and do a straight translation from idiomatic Ruby to non-idiomatic Perl, Cozine does the article and its readers a disservice. Perhaps next time he should ask chromatic to write the Perl example.

Re:Different style of programming

[DragonWriter]

"Read the link given."? I ask for the examples the author gives of a specific point, and you want me to read all his rantings?

The specific point was the central theme of the articles linked to, so, yes, if you want to know the specific arguments he makes for those points, you ought to read the arguments yourself.

Keep in mind this author is the same guy who says, "Maybe there is some aspect of Perl I do not understand that makes it easier than I thought in Perl, and if so I would love to know. I still have to use Perl occasionally and so any advancement of that knowledge is useful, too. :) And actually, even though I still find it much easier to write DSLs in Ruby than in Perl, in writing this post's examples I discovered that writing a DSL in Perl was a lot easier than I thought it was."

So? Again, since I've never endorsed either the thesis of the author's argument nor the argument advanced for it, simply argued that the existence of those posts did not at all illustrate the point about the Ruby community that the poster who linked to them suggested, I don't see why I would need to "keep that in mind", since it is relevant to no point that I have argued for or against. It may be relevant to the point that you are desperately looking for someone to argue with you about but, again, I'm not interested in that point.

I personally have never seen the use of Lisp macros referred to as a DSL.

I've almost never seen a discussion of DSLs that doesn't point to the use of Lisp macros as a key example of their implementation.

As for the tautological nature of my closing statement, I was simply keeping it in the terms I hear repeatedly from the promoters or Ruby.

That you were trying to extend or modify a statement structure you've heard other people use to say something different doesn't change the fact that what you said ended up not saying anything that has any meaning.

Fluff pieces, industry buzz, and the latest slick but narrowly focused toolkit don't mean much compared to programmer productivity in general.

You're right, they don't. So what?

They do nothing to sway people who notice how awkward the author's work in the other language is.

Maybe. So?

I'm sure it's a great language for some, and might be better for someone with no Python, Perl, or Ruby experience to start with than Python or Perl.

Lots of Rubyists did not come to it with no Python or Perl experience, and still find it better for many things. Many without abandoning Python or Perl. Including, for that matter, the author you are trying to get me to defend, who came to it from Perl.

The authors who promote it as better than something else without reasons or with admittedly awkward use of the other languages only help to reinforce happy feelings inside the community.

Actually, I'd think that the authors who admit their limitations when discussing their observations do more to promote useful dialogue that is illuminating for all participants than those that pretend to know everything about the subject and the arguments, especially those who do so without even reading the arguments they are criticizing.

By trying to treat Perl as Ruby and do a straight translation from idiomatic Ruby to non-idiomatic Perl, Cozine does the article and its readers a disservice.

Cosine didn't try to treat Perl as Ruby and do a straight translation from idiomatic Ruby to non-idiomatic Perl. He may have done that in effect, but what he set out to do was to compare the two based on his greater (in his perception) experience of Perl and more recent encounter with Ruby.

Now, it certainly seems that he had a better grasp of the most useful Ruby approach to the matter he was addressing and less so with Perl. But I think it would do a greater disservice to the community if impressions like this weren't discussed and responded to.

Re:Different style of programming

[mr_mischief]

Remind me never to let your summarize anything for me, since you're dismissing the idea that you could do so.

"I've almost never seen a discussion of DSLs that doesn't point to the use of Lisp macros as a key example of their implementation."

Using Lisp macros to implement a DSL and the macros themselves comprising the DSL are two very different things. Having macros that do the work of a feature of a DSL is interpretation of the DSL, sure. Having macros that each translate a feature of the DSL into machine language or add it to an AST would be a good deal of an implementation of a compiler for the DSL. Having macros with names that make sense for what they're doing is not, in itself, any definition of a DSL that I've seen before this thread.

"Ruby is a better Perl than Perl" means exactly nothing. That's exactly the statement I was tugging apart. For the statement to have any meaning, "a better Perl" must be defined. What makes it better? What makes it Perlish? Why would someone wanting Perl want Ruby more? Don't attack my statement as being meaningless and say the statement upon which it plays is meaningful when it clearly is no more meaningful.

The author who claims to come to Ruby with plenty of Perl experience didn't stick with Perl long enough, apparently. He could argue that he learned Ruby much faster than Perl and that Perl therefore was harder for him and people who think like him to learn. That would be a valid comparison. He doesn't say that, and we don't really know how much time he spent with Perl or with Ruby from the article. I can tell you it's generally considered that Perl's learning curve is very long. People who can teach introductory courses in the language could still be learning a great deal from the true masters. Some consider such a long learning curve a bad thing, and in some situations it's true. Others consider that a tool you can use now and continue to use better as time goes on is a good tool.

where's unicode?

[sentientbrendan]

I can't help but notice that there's nothing mentioned about unicode. I don't see how a major web development language, especially one made by Japanese designers, can go so long without adding comprehensive unicode support. After all, it's not like only English speaking people use rails websites...

Re:where's unicode?

[Riemann hypothesis]

There is support for Unicode in Ruby 1.9. An encoding is now associated to a string and you can also perform transcoding, therefore converting a given string amongst different formats (e.g. UTF-8 and ASCII).

Re:where's unicode?

[Anonymous Coward]

Well, to add to what you noticed, I would love to ask, what does it even mean that a language support or doesn't support "Unicode".

Are we talking about the program source code, or the program String objects?

What confuses me even more (I've only done simple scripting stuff) is that never did I see in any language that you have to specifie the encoding of a string object, so I wonder who does the encoding decoding thingie! Is it the OS, the run time (in Ruby's case that would the interpreter I think)

In other words what the heck does it mean Unicode support, who does it, why, when, how does it work?

Re:where's unicode?

[Fweeky]

Traditionally, Ruby's considered a String as being a stream of bytes; with Unicode that breaks down somewhat, especially UTF-8 where each character might be a different length. Unicode support means it's aware of the encoding, and thus can behave sensibly when you ask things like, "how long is this string?" (is that how many bytes or how many characters?), and "give me the character at location 5" (is that 1 byte 5 bytes in, or whatever the encoding says the 5th character is?).

Similarly, Ruby's now using Oniguruma, a very nice multibyte-aware regexp library; and of course that needs to be encoding aware so it knows how much . etc should match and what offsets you're expecting.

I haven't looked at it too closely, but one of the reasons it's taken so long was matz saying he wanted to get it right, and to not just support Unicode but be entirely charset and encoding neutral; yes, it's developed by a lot of people who write using crazy multibyte glyphs, but that doesn't mean they all use Unicode for them.

Re:where's unicode?

[JanneM]

I don't see how a major web development language, especially one made by Japanese designers, can go so long without adding comprehensive unicode support.

Ruby isn't a web development language. It's been used to write a web development framework, which isn't the same thing. And Japan has not picked up Unicode since it has some rather dumb issues with Japanese (missing characters and the like). You preferentially use other encodings.

Re:where's unicode?

[DragonWriter]

I can't help but notice that there's nothing mentioned about unicode. I don't see how a major web development language, especially one made by Japanese designers, can go so long without adding comprehensive unicode support.

Ruby's slow adoption of Unicode is largely because it was developed by a Japanese developer. See, for an overview of the issues, here. And, indeed, that's probably why, while Ruby is gaining more Unicode support, Ruby will probably not be as Unicode-centric as some languages are in the forseeable future.

Speed Improvements Are Nice, But Not Enough

[RAMMS EIN]

It's nice to see that Ruby interpreter speed is improving. Performance and compile time checking (think static types) are about the only areas in which I find Ruby lacking. Looking at the table on the shootout page, though, I find that performance has only improved by a factor 2. That's impressive...but it's not enough.

Last I measured, Ruby was about a factor 300 slower than C on low-level code (measuring the performance of high-level functionality implemented in the interpreter is not so interesting, because that isn't actually implemented in Ruby). That means there is still a long way to go before Ruby is actually competitive with the likes of Common Lisp, OCaml, Haskell, or Lua in terms of performance (I wouldn't compare to C or Fortran, because these languages are much more limited in what abstrations they offer).

Still, Ruby is a great language, and I hope they keep up the great work. I end up writing quite a lot of code in Ruby, because it's very _easy_. The language is mostly very well designed, which means you aren't likely to run into limitations of the language, and there is support (either shipped with the language, or available as a third-party module) for almost everything I want to do. Speed isn't usually an issue. And when it is, it's possible (and easy) to write an extension in C.

The one thing I wish they would get rid of is the distinction between blocks and lambdas.

Re:Speed Improvements Are Nice, But Not Enough

[sohp]

compile time checking (think static types)

Perhaps Ruby is not the language for you?

(Ruby is a dynamic language, static/manifest typing is pretty much 180 degrees opposite the philosophy of the language).

Competitive -- but for what?

[patio11]

Something I always wonder when folks say that Ruby isn't competitive with, e.g., C with respect to speed is what the context for the competition is. In my professional career I worked on precisely one application which was capable of pegging a modern processor. The bottleneck is almost never the CPU these days -- in fact, rarely enough is it ANYTHING technological! Disk space, memory, bandwidth, CPU time, I/O on the bus, all of the things which I learned how to optimize at engineering school are available in huge quantities for unbelievable prices. The bottlenecks that I find myself worrying about these days are a) insufficient number of hours in the day (it seems stuck at 24 and Moore's Law isn't helping -- bugfix, plz) and insufficient customers using my systems to cause resource issues.

I run one web application which is essentially an advertising brochure for software that I created. The software is in Java (which I suppose is slow in the abstract, but none of my users can tell the difference) and the website is Ruby on Rails. ($10k in income in 2007, 10k uniques in the average month, to get a rough idea of scale.) Is Ruby on Rails a slow/poor scaling/resource hogging framework? Maybe. My $20 a month VPS account hosts my application fast enough to take 20k page views in an hour. The economic value per pageview for that site is about 5 cents. Please, God, send me resource issues! Make me regret my choice of a productive but slow framework, as the spigot gets up to $1k an hour and then just resists improvement until I go to the $40 a month server!

Your mileage may vary, if your business model involves sending nation-state scales of traffic at sites and picking for pennies in advertising. If it does, could I humbly suggest spending half as much time worrying about the business model as you do about your technology choices?

Re:Competitive -- but for what?

[Estanislao Mart�nez]

Something I always wonder when folks say that Ruby isn't competitive with, e.g., C with respect to speed is what the context for the competition is.

But note that GP did disclaim that he was not comparing Ruby with C as a competitor; the languages that were mentioned as competitors are Common Lisp, OCaml, Haskell, and Lua. I don't know Lua, and I think OCaml and Haskell aren't fair comparisons (being very static languages), but a performance comparison to Common Lisp certainly is fair; Common Lisp is a more featureful language than Ruby, that has implementations that run a lot faster.

The best comparison, however, would be between Ruby and various Smalltalk implementations.

Heinlein reference, HOOOOOOO!

[Eco-Mono]

Lisp = The Church of All Worlds?

Where's Ruby 2.0?!

[jdinkel]

I'm sorely disappointed. I thought the Christmas release was supposed to be the stable Ruby 2.0. Anybody heard any projection for when the stable Ruby 2.0 is supposed to be released?

Judging languages by their syntax

[Anonymous Coward]

I think Ruby is really an evolution of Perl. There are a lot of Perlisms in its syntax, and I bet it'd be very easy for a Perl programmer looking for something new to learn Ruby. I resisted learning Perl in the first place and picked up Python instead; I have never regretted this decision, and I don't think I'll regret not learning Ruby either.

I see a few Perlisms in the syntax, but mostly I see Lispisms (and Smalltalkisms) in the semantics.

I'm reminded of the Alan Kay line: "Java and C++ make you think that the new ideas are like the old ones. Java is the most distressing thing to hit computing since MS-DOS." Maybe Ruby isn't *quite* as distressing as MS-DOS because it actually is a decent object-oriented system (quite similar to Smalltalk, Alan Kay's baby).

But it is kind of sad that every new language is evaluated primarily on its syntax, and that programmers (being people, who are emotional) see either "it looks like something I already know, so there's no point" or "it looks weird, so I won't use it".

Matz chose to dress his object-oriented language in Perl clothing, which was perhaps a brilliant way for Smalltalk ideas to actually get used, but the price for that was that many people would take one look, assume it's similar to Perl, and brush it off.

Can we get past "OMG curly braces" and start actually discussing ideas instead of the characters used to write them?

Re:Judging languages by their syntax

[chromatic]

Can we get past "OMG curly braces" and start actually discussing ideas instead of the characters used to write them?

Having read a few discussions of Perl, I have to say "Evidently not."

Try Norvig's book

[Anonymous Coward]

If you want to learn Common Lisp in "mind expansion" mode, you should try Norvig's Paradigms of Artificial Intelligence: Case Studies in Common Lisp.

It's a big, fat book, and will take a long time to work through it, but it'll show you a bunch of different techniques and tackle a number of problems you won't see in a Python or C book.

Why Ruby? ... Why Python?

[remitaylor]

I hear you. I've been looking in the opposite direction for awhile now.

I've been using Ruby for a few years and I've been looking for excuses to learn Python. I've gone so far as to buy some books, in case I find the time to go through them ... but I haven't found a reason, as of yet.

They certainly do seem to occupy the same niche, so there may not be very good reasons for learning one if you know the other. If anything, I might learn Python because it appears to be more popular for *nix programming ... but the Ruby community is great and growing.

Either way, I can't see myself leaving Ruby as my language of choice for awhile to come ... I've very much in love with it.

Netcraft confirms it: you're wrong

[DragonWriter]

You can still spot what they are running on Netcraft

Yes, I can. And when I do, I find that contrary to your claims, neither the Ruby language site (which is www.ruby-lang.org, not www.ruby.com) nor 43things.com is running PHP. Rubyonrails.(org/com) is. www.ruby.com doesn't show PHP on Netcraft either, but isn't really relevant to the Ruby programming language in the first place.

and ask them why they are running PHP and they will tell you; they have responded in the past to such inquiries with what I am telling you.

Where? Here's DHH's explanation for Rubyonrails.org's use of PHP (from the rubyonrails.org blog:

PHP, because its a great language for small degrees of dynamic elements. Like, say, including a static footer and header, which is what we use it for here. Firing up Rails to do something so simple just because you think it'll impress people with a single track of all or nothing would have been the nut case way to go.

Just because we love and build Rails, doesn't mean we don't appreciate or use other technologies when they're appropriate. Apart from the performance problems with Trac, we love that too. Even though its, gulp, built in Python! Yeah, I know, I can barely contain the drama either.

Strangely, no mention of using PHP for "scaling", which you claim is the motivation and the explanation that "they" give. So, out of the three Ruby-related sites you claim say they are using PHP for scaling that somehow prove that Ruby can't scale, one isn't the site you seem to think it is, 2 aren't (whether you check the site you give the address for or the actual site you seem to think that address refers to) using PHP based on the source you claim confirms that they are, and the one that is using PHP doesn't explain that use with the explanation you say they give.

It would be hard for you to be more wrong about this.

Re:Netcraft confirms it: you're wrong

[Foofoobar]

As stated, in the php.ini, you can turn 'show_php' off. You can state that I am wrong all you want but the cookies used to show (and in some cases still do), with a TINY amount of legwork, you will find that they still DO run PHP and if you ask them directly, they will state as much.

I'm constantly amazed at the state of denial in the RUBY community when even the maintainers state that they use other languages that their commnity just puts their fingers in their ears and starts going 'LALALALALALA I CAN'T HEAR YOU LALALALALA'.

Seriously, if you want to remain ignorant, it's up to you. I'm not here to convince you of what even the maintainers of the language have stated repeatedly.

Re:Netcraft confirms it: you're wrong

[DragonWriter]

As stated, in the php.ini, you can turn 'show_php' off.

You stated specifically that one could verify that those sites were running PHP with Netcraft. Checking Netcraft shows that you are wrong for all but one of the three. You stated specifically that the reason those sites gave for using PHP was scalability. The one site that uses PHP (rubyonrails.org), in fact, gives an explanation that has nothing to do with scalability.

You can state that I am wrong all you want

Yes, I can. And I'll be right, because you are, demonstrably, wrong.

but the cookies used to show (and in some cases still do), with a TINY amount of legwork, you will find that they still DO run PHP and if you ask them directly, they will state as much.

I'm not inclined to gather your evidence for you, especially given that your last claimed evidence that they used PHP -- that Netcraft showed it -- was false. But even if they did use PHP, you've presented know evidence that they do so for scalability. You've claimed that that's the explanation they give, but for the one site that verifiably does use PHP, that's false, as the explanation rubyonrails.org gives for using PHP is not scalability. If you've got evidence that the others use PHP for scalability, feel free to present it.

I'm constantly amazed at the state of denial in the RUBY community when even the maintainers state that they use other languages

No one is denying that many in the Ruby community, including (perhaps especially) the maintainers/developers of the Ruby language (who have to, at least, use C) use languages other than Ruby.

What is being questioned is your claim that specific web sites use a particular alternative language (PHP) for a particular reason (scalability), a claim for which you have presented no convincing evidence, and for which your claimed sources -- both regarding the use of PHP and the reason -- have shown things other than what you have claimed.

Seriously, if you want to remain ignorant, it's up to you. I'm not here to convince you of what even the maintainers of the language have stated repeatedly.

You have yet to provide any reason to believe that the "maintainers of the language" (which, incidentally, aren't represented by 43things or rubyonrails.org -- 43things is a social networking site, Ruby on Rails is a framework, both make use the Ruby language [among others--RoR includes JavaScript components, too]) have said any such thing, whereas the operators of rubyonrails.org (who you've also claimed have said the same thing about PHP for scalability) have given a different explanation of their use of PHP.

Netcraft confirms it: you're ignorant

[Foofoobar]

I provided plenty. You Only want to see what you want to. If they shut off php.ini, and you don't wish to do your own legwork outside of this tiny little forum, then you don't truly wish to know now do you. You only wish to argue. To that I say feel free to remain ignorant. I have given you the key to free your mind... it is up to you to remain caged or not.

Re:Netcraft confirms it: you're ignorant

[DragonWriter]

I provided plenty.

You provided: (1) a demonstrably false claim about what Netcraft said about the sites, and (2) a claim that, to the extent it is verifiable at all, is also false about statements by the site operators.

If they shut off php.ini, and you don't wish to do your own legwork outside of this tiny little forum, then you don't truly wish to know now do you.

Whether or not they use PHP is mostly peripheral (that Netcraft doesn't show it shows that you were wrong in claiming that it did, but even if they did, that alone doesn't prove anything that matters: no one disputes that people in the Ruby community don't, for the most part, use Ruby exclusively.)

You claim that they use PHP for scalability. You claim that that's what they themselves say. You claimed (though you seem now to back off from it) that their use of PHP can be confirmed through Netcraft.

In point of fact, only one of them can be confirmed through Netcraft to use PHP, and the explanation they offer is not as you have falsely claimed that they do so for scalability, but that they use it because PHP is a good tool for putting small amounts of dynamic content on a largely-static page, which is what they use it for.

You only wish to argue.

No, I wish to know if your claim that they say they use PHP for scalability has any basis. Certainly the research I've done shows that it seems not to for Rubyonrails.org. And you've provided no reason it does for any of the others. The issue isn't whether or not they use PHP (though, of course, if they don't, they clearly don't use it for scalability), it is whether they say that they use it for scalability. So far you've provided no evidence of this claim, despite saying that they've "said it repeatedly" and that it is a "widely known fact".

It seems to me more that it is a rumor you've heard, for which you are aware of no actual substantiation, and that when you are pressed on it, you have nothing to back it up.

Re:Netcraft confirms it: you're ignorant

[Foofoobar]

Call it what you will. If you honestly wanted to know, you'd research it yourself outside of here. Like I said, you made up your mind before even reading this post so nothing that could have been stated or shown would have dissuaded you. You choose to remain blind and so you shall be.

Re:Netcraft confirms it: you're ignorant

[Foofoobar]

And feel free to waste your mod points on me too. It doesn't change anything but if it makes you feel that it does or makes you happier then please indulge. The world will continue as it always has until you wish to acknowledge it.

Re:Netcraft confirms it: you're ignorant

[DragonWriter]

Call it what you will. If you honestly wanted to know, you'd research it yourself outside of here.

I did. I checked Netcraft when you said it supported you, and it didn't. I searched for statements by the operators of those websites that you claimed stated their use of PHP was for scalability, and the only one that I could find -- from the creator of Ruby on Rails on rubyonrails.org's weblog -- stated, as an answer to the "why do you use PHP?" question, a different reason that the one you claimed they give in response to that question. I did research outside of Slashdot to verify for your claims, and that research contradicted your claims.

Re:Netcraft confirms it: you're ignorant

[DragonWriter]

And feel free to waste your mod points on me too.

Nice persecution complex you have there. But just as out of touch with reality as the rest of your posts.

Re:Netcraft confirms it: you're ignorant

[Foofoobar]

And nice god complex. Just as self righteous as ever in the face of your own ignorance.

Re:Netcraft confirms it: you're ignorant

[Foofoobar]

By the way, persecution would be to mean I care about what you think. Sometimes you have to accept that some children don't wish to learn. Does that mean that I feel persecuted by the fact that you wish to remain ignorant? You seem to misunderstand the term persecution as you misunderstand many things. But I'm sure that to you will come to understand in time as well.

Re:Netcraft confirms it: you're ignorant

[DragonWriter]

By the way, persecution would be to mean I care about what you think.

Not really.

Sometimes you have to accept that some children don't wish to learn.

If you believed what you were writing, would you really have gone from responding once to each of my posts to responding twice to each of them?

Does that mean that I feel persecuted by the fact that you wish to remain ignorant?

You apparently think that I am obsessed enough with getting you that I am going to stalk you on other threads and mod you down (or, despite having a UID that's 1/3 of mine, you are grossly ignorant of how Slashdot moderation works and think I'm going to mod you down on this thread for the same reason.) You seem to, therefore, feel persecuted by my pointing out that the verifiable facts are not consistent with the claims you've made.

(Of course, why you describe fact-checking your claims and questioning when the evidence contradicts them as wishing to remain ignorant, I don't know. Care to explain?)

Re:Netcraft confirms it: you're ignorant

[Foofoobar]

LOL. wow. You truly are ignorant. You are willing to debate Merriam Webster now? Amazing. Truly amazing. Well have at it then. Lets see you debate a bunch of Rhodes scholars on the definitions that they establish.

Re:Netcraft confirms it: you're ignorant

[DragonWriter]

You are willing to debate Merriam Webster now?

Well, whether or not I am is irrelevant, since the first definition of "persecute" from Merriam-Webster (see their online dictionary), which is the sense relevant to "persecution complex", doesn't require the victim to care what the persecutor thinks.

When you acted as if you expect me to go on a moderation crusade against you becaus of your expressed opinions in this thread, that is exactly a description of your perception that you are (or are about to be) persecuted (that is, harassed or punished in a manner designed to injure, grieve, or afflicted.)

Re:Netcraft confirms it: you're ignorant

[Foofoobar]

ROFL. Incredible. Truly ignorant. You bring new meaning to knuckle dragger. I applaud your species sir.

Whitespace vs 'end'

[Unoti]

I couldn't get over Python's syntactically significant whitespace - many people would laugh at that, but for me it's just unthinkable. So Python was just ruled out for me totally because of that.

You know what bugs me worse than syntacitcally significant whitespace in Python? Ruby's "end" all over the place. I'd totally rather use syntactically significant whitespace than to have 10% of my lines of code be the single word "end". It just bugs me

Ruby programming language

[darrinallen]

Is Ruby similar to Python? My public library has a really good Ruby programming manual. i am hoping this is an easy language to learn