Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Ruby 1.9.0 Released

timothy posted more than 6 years ago | from the facetnating dept.

Programming 199

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

cancel ×

199 comments

Sorry! There are no comments related to the filter you selected.

No comments yet, but... (0)

VGPowerlord (621254) | more than 6 years ago | (#21818508)

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

Firehose blurp (1)

pembo13 (770295) | more than 6 years ago | (#21818546)

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

Re:Firehose blurp (1, Funny)

Anonymous Coward | more than 6 years ago | (#21819542)

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

Re:Firehose blurp (1)

smitty_one_each (243267) | more than 6 years ago | (#21820550)

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. (2, Insightful)

rgo (986711) | more than 6 years ago | (#21818568)

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. (5, Informative)

sciurus0 (894908) | more than 6 years ago | (#21818820)

According to Chu Yeow [codefront.net] , 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.

Why Ruby? (1)

Just Some Guy (3352) | more than 6 years ago | (#21818690)

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? (4, Insightful)

Anonymous Coward | more than 6 years ago | (#21818760)

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? (1)

corsec67 (627446) | more than 6 years ago | (#21819068)

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? (1)

fjolliton (876499) | more than 6 years ago | (#21819742)

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? (1)

jhol13 (1087781) | more than 6 years ago | (#21819822)

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? (1)

smitty_one_each (243267) | more than 6 years ago | (#21820608)

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? (2, Interesting)

siride (974284) | more than 6 years ago | (#21821172)

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? (1)

Just Some Guy (3352) | more than 6 years ago | (#21821016)

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? (1)

nuzak (959558) | more than 6 years ago | (#21822538)

> 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? (1)

jo42 (227475) | more than 6 years ago | (#21820398)

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

Re:Why Ruby? (1)

smitty_one_each (243267) | more than 6 years ago | (#21820620)

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? (1)

Just Some Guy (3352) | more than 6 years ago | (#21821006)

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.

FFI (2, Funny)

r6144 (544027) | more than 6 years ago | (#21818786)

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.

Re:Why Ruby? (2, Insightful)

Anonymous Coward | more than 6 years ago | (#21818788)

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? (1)

Foofoobar (318279) | more than 6 years ago | (#21818818)

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? (1)

aldheorte (162967) | more than 6 years ago | (#21819090)

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? (0)

Anonymous Coward | more than 6 years ago | (#21820520)

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? (1)

jdinkel (1028708) | more than 6 years ago | (#21821932)

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? (0)

Anonymous Coward | more than 6 years ago | (#21820878)

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? (4, Interesting)

Tyler Eaves (344284) | more than 6 years ago | (#21818846)

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? (1)

smitty_one_each (243267) | more than 6 years ago | (#21820630)

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? (4, Informative)

sciurus0 (894908) | more than 6 years ago | (#21818860)

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 [ruby-lang.org] . This page highlights some of the things that make Ruby Ruby.

Re:Why Ruby? (1)

PaulK (85154) | more than 6 years ago | (#21818872)

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

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? (3, Interesting)

Yath (6378) | more than 6 years ago | (#21819150)

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? (3, Informative)

eosp (885380) | more than 6 years ago | (#21819392)

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? (1)

Yath (6378) | more than 6 years ago | (#21819544)

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

Re:Why Ruby? (1)

fjolliton (876499) | more than 6 years ago | (#21819760)

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? (1)

vrt3 (62368) | more than 6 years ago | (#21819954)

Unfortunately that only works if the keys are strings.

Re:Why Ruby? (1)

fjolliton (876499) | more than 6 years ago | (#21819976)

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? (1)

vrt3 (62368) | more than 6 years ago | (#21820034)

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

Sorry.

Re:Why Ruby? (3, Insightful)

Just Some Guy (3352) | more than 6 years ago | (#21821042)

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? (0)

Anonymous Coward | more than 6 years ago | (#21819772)

I think you have your punctuation confused.

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

Re:Why Ruby? (1)

Haeleth (414428) | more than 6 years ago | (#21820532)

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.

Lisp (0)

Anonymous Coward | more than 6 years ago | (#21819276)

Guido tried Lisp and he didn't understood it.

Matz tried Lisp and he understood a little.

Matz wins.

Re:Why Ruby? (2, Interesting)

mini me (132455) | more than 6 years ago | (#21819456)

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? (1)

Just Some Guy (3352) | more than 6 years ago | (#21821158)

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?

Different style of programming (3, Insightful)

Estanislao Martnez (203477) | more than 6 years ago | (#21819514)

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 [martinfowler.com] , 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 [artima.com] .

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 (1)

chromatic (9471) | more than 6 years ago | (#21822606)

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 (1)

Estanislao Martnez (203477) | more than 6 years ago | (#21823088)

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:Why Ruby? (0)

Anonymous Coward | more than 6 years ago | (#21819952)

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? (1)

Just Some Guy (3352) | more than 6 years ago | (#21821214)

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 [honeypot.net] 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? (0)

Anonymous Coward | more than 6 years ago | (#21822330)

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? (1)

Just Some Guy (3352) | more than 6 years ago | (#21822688)

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? (1)

Haeleth (414428) | more than 6 years ago | (#21820474)

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? (1)

pebs (654334) | more than 6 years ago | (#21820812)

(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??!??

Heinlein reference, HOOOOOOO! (1)

Eco-Mono (978899) | more than 6 years ago | (#21822220)

Lisp = The Church of All Worlds?

Re:Why Ruby? (1)

WNight (23683) | more than 6 years ago | (#21820504)

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? (0)

Anonymous Coward | more than 6 years ago | (#21820538)

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? (1)

Fweeky (41046) | more than 6 years ago | (#21821408)

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? (1)

Just Some Guy (3352) | more than 6 years ago | (#21822316)

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? (0)

Anonymous Coward | more than 6 years ago | (#21822626)

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? (1)

Just Some Guy (3352) | more than 6 years ago | (#21822762)

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? (0)

Anonymous Coward | more than 6 years ago | (#21823154)

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? (1)

renoX (11677) | more than 6 years ago | (#21821018)

[[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? (1)

Just Some Guy (3352) | more than 6 years ago | (#21821252)

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

Bleached Perl [cpan.org] ?

Re:Why Ruby? (4, Interesting)

astrashe (7452) | more than 6 years ago | (#21821134)

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 did. Everything sort of fit together, and it was all beautiful, and it was all kind of cool. Mies designed the furniture in the lobby, and it fit.

That's the thing about Ruby. It just has a larger coherence, and a larger consistency, that works. Ruby's great strength is aesthetic. That sounds dumb, or feng-shui touchy-feely, or whatever, but it's real, and I think it makes a difference.

Re:Why Ruby? (1)

chromatic (9471) | more than 6 years ago | (#21822636)

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

It is? What does it close over?

Re:Why Ruby? (1)

midnighttoadstool (703941) | more than 6 years ago | (#21822976)

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.

Scalability? (-1, Flamebait)

Foofoobar (318279) | more than 6 years ago | (#21818792)

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? (1)

bladesjester (774793) | more than 6 years ago | (#21818826)

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? (1)

Foofoobar (318279) | more than 6 years ago | (#21819000)

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? (5, Insightful)

JanneM (7445) | more than 6 years ago | (#21819130)

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? (1)

bladesjester (774793) | more than 6 years ago | (#21819232)

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? (1)

chromatic (9471) | more than 6 years ago | (#21819386)

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? (0)

Anonymous Coward | more than 6 years ago | (#21819266)

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? (2, Insightful)

mindsuck (607395) | more than 6 years ago | (#21819286)

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

Re:Scalability? (0)

Anonymous Coward | more than 6 years ago | (#21819504)

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

Re:Scalability? (2, Insightful)

mini me (132455) | more than 6 years ago | (#21819462)

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

Re:Scalability? (0)

Anonymous Coward | more than 6 years ago | (#21819698)

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? (0)

Anonymous Coward | more than 6 years ago | (#21820074)

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? (1)

WNight (23683) | more than 6 years ago | (#21820436)

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? (1)

KieranElby (315360) | more than 6 years ago | (#21820492)

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? (0)

Anonymous Coward | more than 6 years ago | (#21822680)

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? (0)

Anonymous Coward | more than 6 years ago | (#21820850)

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? (1)

PaulK (85154) | more than 6 years ago | (#21818948)

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? (1)

sciurus0 (894908) | more than 6 years ago | (#21819006)

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 [davidflanagan.com] .

Re:Scalability? (1)

Foofoobar (318279) | more than 6 years ago | (#21819048)

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? (1)

aldheorte (162967) | more than 6 years ago | (#21819018)

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? (1)

KieranElby (315360) | more than 6 years ago | (#21820450)

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

I'd like something else. (2, Insightful)

jd (1658) | more than 6 years ago | (#21819010)

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. (0, Troll)

fat_mike (71855) | more than 6 years ago | (#21819708)

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. (3, Interesting)

jd (1658) | more than 6 years ago | (#21819774)

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

Anonymous Coward | more than 6 years ago | (#21819736)

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. (2, Interesting)

jd (1658) | more than 6 years ago | (#21819790)

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

dkf (304284) | more than 6 years ago | (#21820266)

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

Anonymous Coward | more than 6 years ago | (#21820922)

Check out Haskell, specifically GHC's parallel library [haskell.org] , 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.

Temporary URL for the benchmarks (0)

Anonymous Coward | more than 6 years ago | (#21819230)

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/ [stacktrace.it]

where's unicode? (2, Interesting)

sentientbrendan (316150) | more than 6 years ago | (#21819780)

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? (4, Informative)

Riemann hypothesis (1207970) | more than 6 years ago | (#21819912)

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? (0)

Anonymous Coward | more than 6 years ago | (#21819920)

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? (1)

Fweeky (41046) | more than 6 years ago | (#21821120)

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.

Speed Improvements Are Nice, But Not Enough (1)

RAMMS+EIN (578166) | more than 6 years ago | (#21820384)

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.

Competitive -- but for what? (0)

patio11 (857072) | more than 6 years ago | (#21820580)

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?

Where's Ruby 2.0?! (1)

jdinkel (1028708) | more than 6 years ago | (#21822496)

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?
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>