Talk:Ruby (programming language)/Archive 1

From Wikipedia, the free encyclopedia
Jump to: navigation, search

POV issues

Some of the text of this article seems non-NPOV. For example "clean syntax" and "obvious syntax" seem rather subjective. It doesn't bother me too much, but someone who is familar with the language (and not biased :-) ) might want to NPOV the text. --Frecklefoot 19:08 16 May 2003 (UTC)

In fairness, and with considerable experience of using Ruby after unhappy experiences with many other programming languages, I can only concur with those representations. It is syntactically very clear and also extremely obvious to anyone with an understanding of OO concepts. --Sjc 13:12, 25 Nov 2004 (UTC)
The amount of POV-ish criticism in this article, much of it repetitive, as compared with other language articles like python, lisp, etc, is astounding. (talk)

Hello World!

  1. "Hello World" is already in the article, under "Blocks and iterators".
  1. I disagree about using "Hello World" in every programming language article because it is considered a standard example. It should especially be avoided for a high level language like Ruby in which it consists of a single, straight-forward expression. Any non-trivial example, say a program that (for example) constructs and uses a hash, involving the creation of a string object and printing it to the standard output, provides all information that can be found in a "Hello World" program, and much more.

The question is not whether it can be included in the article, but whether there are not better ways to use the same space. Note also the existence of the Hello world program page, which exists to cover this "standard example". --Fredrik | talk 11:57, 3 May 2005 (UTC)

I'm confused. What change are you proposing? To remove the existing "Hello World" references in the article (under "Blocks...")? I'm all for it, since the code under that section doesn't run by itself anyways (blocks don't work out of the method calling context) and thus can be confusing. And if you want to change "Hello world" to "This is a block", I'd be happy too. Other than that, there aren't another other "Hello World"s in the article, so what exactly were you disagreeing with?
There was a second "Hell World" example. See the article history. --Fredrik | talk 23:45, 13 May 2005 (UTC)
Use the fibonacci numbers. -- 14:23, 20 December 2005 (UTC)


Exact copy of entry posted June 12, 2001 8:02 am by Stephen Gilbert.

Copied to change name from "Ruby language" to "Ruby programming language" to match other language names.

For the record, I had little to do with this article, other then the editing. The original editing history was pruned. --Stephen Gilbert

Swift creation

So this guy created the language in one day? Cool. --AxelBoldt

Of course not :) --Taw

Section removal proposal

That section dealing with mailing lists should be removed, I think. It is not encyclopedic, and most other languages do not have mailing lists as a section. Plus, what does it really inform the reader about? --Maru 05:19, 6 August 2005 (UTC)

I was going to do it, but I checked whether this had already been debated before. Done. --Chealer 02:28, 29 September 2005 (UTC)


I'm not sure that Ruby has ever been compiled yet. AFAIK JRuby is a port of the interpreter to java byte code, but does not compile the underlying ruby? --User:TomCounsell

Correct. But even as an interpreted language it is blindingly fast. --Sjc 13:12, 25 Nov 2004 (UTC)
I like Ruby, but one thing it is not, is fast. 17:04, 17 July 2006 (UTC)
So there's agreement that no Ruby compilers exist? I plan to remove the misleading claim: "It was originally designed as an interpreted language, though in its JRuby implementation it may be compiled." --Ds13 07:31, 19 Feb 2005 (UTC)
Yes, I've done some checking and it should probably be removed. There are a number of projects working on compiler type entities for ruby, but none that are beyond beta yet. --TomCounsell
YARV contains a bytecode compiler. --drbrain 19:00, 4 September 2006 (UTC)
And JRuby now contains a partial compiler that will grow as we continue working on it. In true, we do have a compiler now, but it only handles a subset of Ruby constructs, warning about those it doesn't recognize yet or leaving them to be interpreted. --Headius

There are several projects aimed at creating a Ruby --> Parrot bytecode compiler, namely Ruth, and Ripper. Can't find much on either. Ruby 2's official implementation will use bytecode, see Wootery 18:34, 30 October 2006 (UTC)


Ruby has three main implementations: the official Ruby interpreter, which is the most widely used, JRuby, a Java-based implementation, and RPG Maker XP, a Windows XP program used to create role-playing games.

RPG Maker XP is not a Ruby implementation, although it includes one (RGSS). My understanding of the main Ruby implementation's license is that commercial products like RPG Maker can include the interpreter, provided that they include either the source code or a pointer to Does anyone have this game, and if so, can you tell me whether RGSS is a new implementation? - Beinsane 05:44, 6 October 2005 (UTC)

And to answer my own question...the RPG Maker website [1] has a copyright notice crediting Matsumoto for Ruby. The article will be edited. - Beinsane 05:47, 6 October 2005 (UTC)
also the help-file of the program carries a link to on the first (root) page about RGSS in the About This Document section.

Criticisms and Possible surprises

An anonymous user has come and turned 'Possible surprises' into 'Criticisms and Possible surprises'. If you read the section as it is now, the new items in the list do not really correspond to the list description "some features differ from languages such as C or Perl:". Jogloran 22:25, 8 February 2006 (UTC)

Ruby suffers from unconventional and below-average release management. First, Ruby version numbers are used differently from most other projects. Version 1.8.2 is not compatible with version 1.8.4. With Ruby, point releases are roughly equivalent to major releases of other projects. And since there is only 3 digits in the version number, there are no bugfix releases such as, users must rely on snapshots of the repository for which there is no guarantee of backward compatibility. Another example is the release of Ruby 1.8.3 which broke Ruby's most well-known and popular application: Ruby on Rails.

"Omission of parentheses around method arguments may lead to unexpected results." -- like what? First I've heard of it. The fact that get/set methods are indistinguishable from fields is a feature, not a bug. Metamatic 20:46, 8 May 2006 (UTC)

I got some clarification from Matz. The issue is with methods that take multiple arguments, and that's what may be disallowed in the future. I've reworded accordingly. Also, I've never seen a book recommend omitting brackets for multi-argument methods, so I've tightened that wording too. Metamatic 20:49, 16 May 2006 (UTC)
In an expression like "puts 5, nil" the receiver of nil is ambiguous. In future versions such an expression will cause a syntax error. With " 5, nil" the receiver is not ambiguous so parentheses are not necessary. --drbrain 11:54, 18 June 2006 (UTC)

POV Issue

The article states:

The phrase did not originate with Matz and, generally speaking, Ruby may more closely follow a paradigm best termed as "Matz's Least Surprise", though many programmers have found it to be close to their own mental model as well.

In other words, Ruby doesn't follow the principle of least surprise; it's just Matz's idea of least surprise. That sounds seriously like a jab at Matz and POLS.  DavidDouthitt  (Talk) 23:25, 2 March 2006 (UTC)

Matz repeatedly said he designs Ruby in a way that makes him surprise least; for example, see [2] and [3] --Kusunose 05:44, 3 March 2006 (UTC)

Here's the current version of the sentence. "The phrase did not originate with Matz and, generally speaking, Ruby may more closely follow a paradigm best termed as "Matz's Least Surprise", though many programmers have found it to be close to their own mental model as well."

I agree with David, that the sentence sounds like a jab. It's also full of weasel words. But worst of all, it's factually inaccurate: "Matz's Least Surprise" is not an actual design paradigm. My understanding of Matz's statements about POLS in the two interviews cited by Kusunose is that the rules of Ruby are meant to be internally consistent and unambiguous. It doesn't mean that a heterogenious set of programmers will never get confused while learning the language. My read on his "my least surprise" statement is that the language should never be allowed to adopt features that might trip up an experienced user (himself). Once you gain an understanding of how things are done, you should never be puzzled about language behavior.

I'll rework this POLS bit to be more accurate and less weasely. --Loqi T. 17:22, 23 February 2007 (UTC)

Unicode and UTF8 issue

In the article there is the statement

 Ruby currently lacks full support for Unicode, though it has partial support for UTF-8.

I wonder what this means for Ruby 1.8.4 (the current stable) and 1.9 (the current development release)? An example where a file in UTF8 is read, processed and written out again would be helpful. Hannes Hirzel, 3 June 2006

Ruby 1.8's regular expression engine handles multibyte characters correctly depending on what you set $KCODE to. By default it is in ASCII mode. The string library generally treats characters as raw bytes and ignores character encodings (its been a while since I've looked, I seem to recall one or two methods that check for multibyte characters). Ruby 2.0 will contain more multibyte and unicode string features, but the exact nature of those features have not been decided. --drbrain 11:51, 18 June 2006 (UTC)

Bytecode or not

I have read on the bytecode page that Ruby does not use bytecode in the current implementation. Is is true? I believe it is no longer the case. Acaciz 18:04, 3 June 2006 (UTC)

Ruby 1.8 walks an AST. --drbrain 10:17, 18 June 2006 (UTC)

Citing The Computer Language Shootout Benchmarks

This article links to the The Computer Language Shootout Benchmarks, which is not a quality reference for Ruby's performance problems.

The Alioth benchmarks exercise features that are seldom used in real-world Ruby like heavy recursion or enforcing use of a pure-ruby random number generator in the fasta benchmark instead of the built-in random number generator, overly penalizing Ruby's performance. Also, some benchmarks do not contain properly optimized Ruby.

In some areas Ruby is slightly slower than Perl or Python, but in other areas it is faster. The Alioth benchmarks are overly pessimistic due to the artificial restrictions they impose.

I believe this citation should be removed until a proper reference can be found. --drbrain 22:16, 18 June 2006 (UTC)

Links clean-up?

Can someone clean up the external links? It's so long and disorganized that it's practically useless. Just 5 or so really good introductory links would be ideal. Programmers know how to use google. 17:06, 17 July 2006 (UTC)

I think a link cleanup is a great idea; in fact, that's the reason I came to the talk page. Consider this advance notice of a cleanup:
I am planning to remove a bunch of links from the External Links section based on Wikipedia's policy on External links. I don't want to remove all links, but I feel that the external links section is quite bloated and I would like to see it slimmed down a bit; Wikipedia is not meant to be a collection of outside links. If you have a strong feeling about why a particular link should or should not be included, speak now. Please refer to the Wikipedia policy on external links in your arguments. Zukeeper 01:59, 18 July 2006 (UTC)
This has been longstanding and I am now going to categorize the links. Help is needed. --Herraotic 22:37, 2 September 2006 (UTC)
May the deliberations begin. To note before hand I know that some links may not entirely fit under the category I chose but I don't have time to specify where each should be. I hope you all take care of it :D --Herraotic 23:00, 2 September 2006 (UTC)
Thanks. I removed some sketchup stuff, spams, and also did a little shuffling. Why are people obsessed with Sketchup? 18:12, 23 September 2006 (UTC)

Requested move

Ruby programming languageRuby (programming language) – Conformance with WP naming conventions LotLE×talk 22:54, 1 September 2006 (UTC)

The page was moved. Move discussion is here: Wikipedia talk:WikiProject Programming languages/Renaming poll.

The layout is not attractive nor clean.

I am in favour of a new layout. There are too many cluttered examples which need illustrative concepts and also word wrapping. The external links need organization and categorizing such as learning, reference and etc. The implementation section is verbose on the initial description when it's followed with bullet points. And the features section could be more elaborative. --Herraotic 22:36, 2 September 2006 (UTC)

"abc"[0] same as in C?

I don't know Ruby, so I can't answer this question. There is this bullet point about surprises in Ruby:

Lack of a character data type (compare to C, which provides type char for characters). This may cause surprises when slicing strings: "abc"[0] yields 97 (an integer, representing the ASCII code of the first character in the string); to obtain "a" use "abc"[0,1] (a substring of length 1) or "abc"[0].chr.

When I read that, I get confused. "abc"[0] in C is the number 97 too. -- Myria 06:32, 26 September 2006 (UTC)

Nope, "abc"[0] in C yields char 'a' - which happens to be number 97 underneath but you can manipulate it as char type - for example you can write 'if ("abc"[0] == 'a')'. In ruby the char type doesn't exist so when you write 'if ("abc"[0]=="a")' you get 'false' because you're comparing integer against string. You have to therefore write 'if ("abc"[0].chr == "a")' to get expected result. This is certainly unexpected behaviour. - JohnyDog 21:56, 17 October 2006 (UTC)
Unexpected for a C programmer, at least. — Xaonon (Talk) 05:50, 3 November 2006 (UTC)
You can write "abc"[0] == ?a in Ruby. --Fukumoto 02:34, 18 October 2006 (UTC)

The Applications section ends with jibberish

The application section needs editing:

"An example of using RubyGems by installing Ruby on Rails:" is not a sentence.

"Download"  what RubyGems or RoR?
"(extract, then run "ruby setup.rb")"

Why are these in a box anyway? Only one is an actual command the rest are just a word with no explanation. Is there link that be provided which walks through the install or would a few lines with a bit more detail provide just what is needed.

Something like:

Installing Ruby On Rail illustrates a good use of RubyGems. The procedure would be as follows....

First you need RubyGems

Download it from
tar or unzip depending on which OS you are using
> ruby setup.rb

That is all there is to instally RubyGems. Now you are ready to use Gem to keep your Ruby packages up to date

> gem install rails --include-dependencies

New versions of Rails can be installed in the same way.

Question:  Can new version of RubyGems be updated the same way?
I made it better. This isn't the place for a tutorial on installing Rails anyway. Perle 07:05, 3 October 2006 (UTC)

I can't find an official Ruby logo at this point. What do you all think?

I should think that the closest thing Ruby has is the cartoon foxes. But they're more mascots than a logo. :) Quamaretto 20:47, 23 February 2006 (UTC)
Ruby doesn't have an official logo. --drbrain 10:09, 18 June 2006 (UTC)
We should get license permission to use the logo from the redesigned Ruby-lang page. I can't imagine it would be hard to get permission but I couldn't find any obvious license posted so for now it's under copyright. 18:02, 23 September 2006 (UTC)
You can also use Ruby Logo —Preceding unsigned comment added by (talk) 19:42, 28 January 2008 (UTC)
As it appears that this is correctly the official Ruby language logo I've added it to the page --Heyseuss (talk) 23:42, 15 August 2008 (UTC)

Ruby Strongly typed?

Anybody cares to join in and explain: Template_talk:Type_system_cross_reference_list#Ruby_Strongly_typed.3F?

--Krischik T 07:29, 24 February 2006 (UTC)

Ruby is strongly and dynamically typed, it does not have implicit type conversions like C, which is weakly typed. --drbrain 10:14, 18 June 2006 (UTC)
Don't just point to a wiki page which points out that "there is no commonly agreed-upon meaning for 'strongly typed language'" and assume the case is closed. Almost all of the points on Strongly-typed programming language are describing the opposite of Ruby. The only ones possibly matching are:
  • The absence of ways to evade the type system. Such evasions are possible in languages that allow programmers to get at the underlying representation of values (ie, their bit-pattern).
Well, as Ruby has a highly flexible type system by design there are really no ways to evade it.
  • A complex, fine-grained type system with compound types.
Not sure here.
In conclusion, I don't know where the idea comes from that Ruby is a Strongly-typed programming language. There might be other definitions of Strongly Typed, but Wikipedia's definition does not match at all. --
Citations for Ruby's strongly-typed'ness:
Hope this helps. --Kusunose 03:39, 13 December 2006 (UTC)
So Matz says that Ruby is strongly-typed. This of course should not be ignored, but the problem remains that Strongly-typed programming language does not match Ruby at all. How to proceed from here? --
This part of the article just mixes static typing and strong typing. C is statically typed but weakly typed. While Ruby is dynamically typed but strongly typed. But I would recognize that even these distinctions sometimes blur: take a look at the type checking article. —Preceding unsigned comment added by (talk) 14:09, 5 March 2008 (UTC)
Why should Matz' assertion that Ruby is strongly typed "of course" be ignored - he wrote the language I'd say he's probably one of the best people to tell us about the language itself. More importantly this part of the article confuses weak v strong and static v dynamic. Ruby is obviously dynamic rather than static - is it strongly typed though? It's not really weakly typed. —Preceding unsigned comment added by (talk) 20:44, 21 August 2008 (UTC)

POV issue with "surprises" section

The section "Gotchas and possible surprises" section is POV, starting with its section name. It would be more accurately titled "Possible surprises for C and Perl programmers", but then that's still POV and getting away from what an objective, non-tutorial encyclopedic article should be. I think removal of this section should be considered. It's certainly useful information (as are reviews and tutorials), but that doesn't mean it belongs in an encyclopedia. Anyone else agree? --Ds13 21:32, 15 June 2006 (UTC)

The first four bullet points could be moved into the examples section. I believe the method parentheses problem refers to an expression like "puts 5, nil", where the method that should receive nil is ambiguous. "puts 5, nil" is never ambiguous. --drbrain 10:41, 18 June 2006 (UTC)
I agree - it's a "gotcha" that that zero evaluates to true, but it's equally surprising to any naive entity which is not a computer that a number of any kind would evaluate as being false. Is zero a falsehood? I think not. And the final decimal to make a number floating point is just C shorthand (and possibly others), not a universal convention. We could convert this section to "Possible surprises for C and Perl programmers", but I think that any yokel could come up with a section like "Possible surprises for LISP and Scheme programmers", but I think that would make the article a bit cumbersome. Of course, instead, we could waste our precious server space on long-winded discussions of it. Either way Chicago 13:48, 4 January 2007 (UTC)

Change of Hash keys from strings to symbols by KMeyer (Jul 1)

KMeyer made some changes on July 1st to the hash examples. Rather than, say, { 'a' => 'b', 'c' => 'd' }.. it has become { :a => 'b', :c => 'd' } .. While the symbol syntax is now becoming more popular, I feel this is a poor demonstration of hash tables generally since readers may be confused as to why, say { :my string here => 'x' } doesn't work. Symbols have a prescribed purpose, and in a general hash table, they are not necessarily usable as keys. --Coop 14:27, 2 July 2006 (UTC)

I agree. At the very least it should show that a basic hash maps keys (which are strings, even if you use symbols) to a value (strings, symbols, ints, or whatever else you want). Maybe an example such as: {'a' => 5, 'b' => 'string', :c => 'other_string'}? --Luminousbit 17:01, 8 August 2006 (UTC)
You can use any object you like as a Hash key in Ruby. On occasion I've used Time, Array, Symbol, String, and Integer and even my own Objects. Using a Symbol is more space and time efficient than using a String key because the there is only one instance of a Symbol and the #hash for a Symbol is an O(0) operation and is prefered for these reasons. --drbrain 19:11, 4 September 2006 (UTC)


Would it be worth having a short mention of documentation for Ruby? Matz has stated that the documentation for Ruby is poor. The only up to date english manual that exists is the Pickaxe (Programming Ruby - The Pragmatic Programmer's Guide 2nd Ed.). I think this would be useful information to anyone reading the article that is looking to find more detailed information on the language. Maybe this ties into the links clean-up discussed above. JRavn 20:40, 21 July 2006 (UTC)

I have referenced to some Ruby documentation and also put major learning links under Learning Ruby. --Herraotic 23:01, 2 September 2006 (UTC)

Links to, the primary Ruby documentation and tutorial site, have been added. —Preceding unsigned comment added by James Britt (talkcontribs) 03:01, 18 February 2008 (UTC)

Does it use GNU Bison?

On Talk:GNU bison, someone said that the build system for the Ruby interpreter uses GNU Bison. Can someone confirm this? and/or provide a source? and/or expand further on the details? and/or add a mention of this to the Ruby article and the GNU Bison article? Just a suggestion, thanks for listening. Gronky 19:03, 4 February 2007 (UTC)

Yes, I confirm that Ruby's parser uses bison. I'm not sure how to cite. Does this link [4] to Ruby's source suffice? Sanxiyn 05:51, 20 August 2007 (UTC)
Ruby 1.8 uses yacc or bison. Ruby 1.9+ requires bison. drbrain —The preceding signed but undated comment was added at 04:58, August 21, 2007 (UTC).


The notation "statement until expression", despite the English-language implication that statement would be executed at least once, and precedent in other languages' equivalent statements (e.g. "do { statement } while (not(expression));" in C/C++/...), actually never runs the statement if the expression is already true.

This does highlight a bit of a surprise in the "statement until expression" construction in Ruby for people coming from many other languages, but it isn't quite accurate the way it is phrased, since Ruby has an exact equivalent of "do { statement } while (not(expression));", and that is "until expression { statement }" which works exactly like the C/C++ version and is the closest structural parallel as well. Cmdicely 06:32, 9 August 2007 (UTC)

Can I just add that the claim that there is an "English-language implication that [the] statement would be executed at least once" is exceedingly dubious. If I say to someone, "Please can you do X until Y happens", then if Y has already happened, I don't expect them to do X at all, and they won't - they'll simply say "Actually Y has already happened" and I'll be perfectly happy with that. -09:17, 20 September 2007 (UTC)~ —Preceding unsigned comment added by (talk)

Ruby and characters

Versions prior to 1.9 lack a character data type (compare to C, which provides type char for characters). This may cause surprises when slicing strings: "abc"[0] yields 97 (an integer, representing the ASCII code of the first character in the string); to obtain "a" use "abc"[0,1] (a substring of length 1) or "abc"[0].chr.

So what's "Φ"[0]? Does Ruby support Unicode? Does it mandate a particular character set? (And yes, I'm too lazy to install Ruby and find out, as I imagine our readers are too.)

Also, if you want to drag in C, it's more accurate to say that Ruby does not have character literals. In C, the type "char" is not special -- it's just an integer type. It's notable that 'a' has type int, not char (this is unlike C++), but of course C has implicit conversion between these types. In C, the value of "abc"[0] is implementation-defined, but if the underlying system is ASCII, the result will be an integer with value 97, just as in Ruby. The only difference is that in C, there is an implementation-independent way of writing this value, namely 'a'. 14:08, 11 August 2007 (UTC)

I agree completely with the second paragraph. I do not think that Ruby supports Unicode, however. Many see this as one of it's major weaknesses, especially compared to Python. I believe that version 1.9 may have Unicode support, but I'm not sure. --Kinghajj 22:07, 11 August 2007 (UTC)

Gotchas again

As this article currently stands, you can only add gotchas that are suprises for C programmers. For example, the biggest gotcha for me is that 'and' and 'or' don't follow the normal rules of mathematical precedence; but since C doesn't have 'and' and 'or', I can't add it to the gotchas.

(To expand: given a = true; b = false; c = false; the statement puts "yes" if a or b and c does nothing. puts "yes" if a || b && c works fine.) (talk) 20:38, 6 January 2008 (UTC)

I've had a go at fixing this now, but I don't feel dogmatic about it -- people should feel free to fiddle. (talk) 14:51, 1 February 2008 (UTC)

Type system section and its relevancy

Hi, the 'Type system' section currently reads very poorly. I think it's at best uninforming but probably more to the point is unnecessary in the Ruby article. I'd like to suggest either:

  1. Summarise the discussion (as in, delete 90% of what's written) in another relevant section
  2. Delete it

-- (talk) 08:31, 15 April 2008 (UTC)

Criticism section made by other language supporters ?


I just read this new section and it feels like it has been written by a supporter of some other languages. Why there is no criticism section in the python or perl article for example ?

There are far from perfect and personally, if the developer is not able to spell correctly its variable, it's the developer's fault; not a bug in the language ... In fact, almost all criticisms in this section are against aspects that make Ruby, Ruby (reflection, meta programming, dynamic typing).

I think this section should be removed ... —Preceding unsigned comment added by (talk) 09:55, 16 April 2008 (UTC)

Agreed. I noticed the absence of such a section in other language pages, and also agree that the example given which is effectively saying the interpreter doesn't protect the developer from a typo isn't a particularly strong criticism of the Ruby language. I vote to either delete this section, or at least remove the example of the typo in the class name. -- (talk) 12:29, 17 April 2008 (UTC)
It is not Wikipedia's job to validate the criticisms. If it has been criticized by someone with enough authority to add significant weight to the criticism, we report it. Complete with verifiable, reliable references. We do not go judging it ourselves and censoring it if we feel like it doesn't deserve to be here. We simply report it. If reliable third parties, criticize the criticism, we report that too. We don't take sides promoting one over other. So, if the criticism is properly referenced, it stays. --soum talk 13:10, 17 April 2008 (UTC)
I agree, look for example at the (very extensive) criticism section for the Java language. Hervegirod (talk) 20:46, 17 April 2008 (UTC)
Thanks. I didn't realise the process. For what it's worth, I think the current edit is bordering on the ridiculous where there is a lengthy code section in the criticisms section that ultimately ends with because of the misspelling of "@car_brand" as "@carbrand". If there is a process of reporting this then I think it should be done. -- (talk) 12:07, 18 April 2008 (UTC)
I partially agree - it's very useful to have criticisms of a language in its article, and I've written some sections myself, but criticisms of an entire class of languages (such as those relying on metaprogramming or dynamic typing) is better delegated to the more general article, rather than spelled out in painful detail here. Criticisms here should focus on those unique to Ruby. Dcoetzee 01:33, 19 April 2008 (UTC)

We should separate Ruby (the language) from Ruby (the C main implementation)

There's a lot of complete / near complete / partial / beginning implementation of Ruby out there, not only the C reference. I think that the fact that the C implementation and the language are in the same article is confusing for readers. For example, 1.9.0 is the last version of the language, but it is not implemented by any production-ready implementation yet (1.9.0 is stated in ruby's site as experimental, and it still crash on some tests in the shootout, or is not able to run Rails yet, for example). We should separate Ruby (the language), which is the actual article, from C's Ruby main implementation (the software). Hervegirod (talk) 15:05, 1 May 2008 (UTC)

or at least create a new page for Ruby MRI. Hervegirod (talk) 15:06, 1 May 2008 (UTC)
Done, it turned out that there was enough facts to put in a separate article. Hervegirod (talk) 13:02, 2 May 2008 (UTC)

Small issues with POV

There are a couple of sections here which use a question and answer type format. I haven't seen this elsewhere on wp, but I'm thinking this information would better represented in the normal way; an explanation. Additionally, there isn't any need to try and talk about strong typing in detail on this page; that would be better left the the strong typing page (the same is true, really, for the concept of "type safe"). A short sentence explaining the situation on Ruby would suffice.

In the criticism section, there's no need for a laundry list of general points of criticism; it would be better to say something like "many of the criticisms of OOP/Dynamic typing/Strong typing/whatever-other-criticisms-that-are-applicable-to-the-general-design-of-ruby-and-languages-like-it, and in addition, there is also criticism of the current threading model/backward compatibility issues/whatever-other-criticisms-that-are-applicable-to-the-specifics-of-ruby. There doesn't seem to be a lot of point including criticisms like "no declarations", when they would probably apply to all dynamically/weakly typed languages. We may as well add a criticism for "not being C".

Anyone mind if I start making some of these changes?

--CalPaterson (talk) 19:44, 10 May 2008 (UTC)

I'd like to see some changes made to this section. There's lots of parts of this article that are currently untidy and not very relevant, which is a pity. It used to be a well written article. I'm happy for someone to work on tidying it up. --Heyseuss (talk) 03:31, 21 May 2008 (UTC)
I agree with your points here. Criticism over strong/weakly typed is almost a mute point because the people who love Ruby do so because it is not like C. (talk) —Preceding comment was added at 15:54, 31 May 2008 (UTC)


The 3 last criticisms about Ruby productivity aren't really backed by their sources:

  • they are not about Ruby, but about Rails, so they rather belong to the Rails article.
  • The first critic does not say anything about Ruby productivity.
  • the notoriously difficult to deploy is unsourced.
  • I deleted the third critic, because it was obviously a clone of the first.

I'm not a Rails aficionado at all, and I agree that some critics were made about Rails resource consuming, and how it was a nightmare if you did not use it in its comfort zone, etc... but we should present all the faces of the story, not only one of them. Hervegirod (talk) 00:12, 14 May 2008 (UTC)

I think the point is that it belongs in the Ruby on Rails article and not the Ruby article. I vote to remove the remaining last point which is Rails-specific: "Although Ruby's most popular framework has some high traffic sites, Ruby on Rails applications have been notoriously difficult to deploy and consume a lot of server resources in handling heavy traffic[citation needed]." --Heyseuss (talk) 03:34, 21 May 2008 (UTC)

It would be nice if development IDEs were enumerated - both free and commercial ? —Preceding unsigned comment added by (talk) 10:40, 26 December 2008 (UTC)

Type safety

Type safety is usually defined as progress and preservation (see also Wiki page on the topic). W.r.t. ruby is clearly not type safe as it does not guarantee progress. As a matter of fact, Ruby seems to have no type system at all. Therefore even preservation is not really (or only trivially) adhered to.

Ericbodden (talk) 19:44, 18 May 2008 (UTC)

The article you linked to appears to me to suggest that Ruby is type safe. It suggests that Smalltalk is type safe. Ruby has types, they're enforced, TypeError exceptions will be raised. I think your reading of that article is subjective. --Heyseuss (talk) 00:49, 31 January 2009 (UTC)

Threads are implementation specific

The criticism section states that ruby has green threads. To my knowledge, this might be true for most of the known interpreters but not all! For example Rubinius seems to have 'real' threads. (AFAIS). Could someone proof and note that fact? —Preceding unsigned comment added by (talk) 18:01, 24 June 2008 (UTC)

Strongly typed? W.R.T. point 5

5. Def: A language is strongly typed if conversions between different types must be indicated explicitly. If implicit conversions are performed, it is weakly typed. => Ruby is weakly typed. (Examples: (2+3.5) (implicit conversion Fixnum to Float) and (if 42 then "a" else "b" end) (implicit conversion from Fixnum to TrueClass))

Those examples are flimsy at best.

By the first one, pretty much any high-level language in use today is weakly typed. This is why I'm bringing this point here for discussion: is that really what was intended?

The second one is downright misleading: there's no statement that conditions in Ruby have to be booleans. Someone is applying the semantics of some other language (maybe Java?) to Ruby. Under no active implementation there's an internal conversion to TrueClass happening, even, so there's just no basis for this argument. Thus, I'm removing this one.

--Kamek (talk) 05:34, 6 July 2008 (UTC)

Another point is, Numeric objects are converted implicitly for performance reasons, which makes 2 + 3.5 somewhat misleading. It should be Numeric objects are weakly typed, perhaps?

class X
  def coerce y
    [y, 42]

x =
puts(2 + x)  # => 44

--Fukumoto (talk) 15:15, 6 July 2008 (UTC)

History of Ruby

It would be wonderful to flesh the history section out a lot more. There's little pieces of the history of Ruby around, but it would be great to make this article a definitive history and pull the information together.

-- (talk) 02:58, 14 August 2008 (UTC)

Error in array iterator example?

The second array iteration example results in a TypeError in 1.8.6 (which may be a clue for me to upgrade). Assuming 1.8.7 yields the same error, in the current form of the example, the array[index] expression must also call to_s:

array.each_index { |index| puts index.to_s + ": " + array[index].to_s }

Alternatively, one can use a "formatted" string without calling to_s explicitly:

array.each_index { |index| puts "#{index}: #{array[index]}" }

More compact, but perhaps less readable. Either way is a correct way to get the desired result, but I think I'll let the wikipedians decide on which. (talk) 22:58, 29 August 2008 (UTC)

I've changed it to your second suggestion. Nicely pointed out. I suspect it's probably never been valid code. -- (talk) 22:25, 12 September 2008 (UTC)


Is Ruby a standardized language with a full formal specification, or is it just defined by whatever the current official interpreter supports? This information needs to be stated in the article, just as such info can be found in the articles for most other programming languages. Looking around on the official website, I can't find anything referring to a specification. Herorev 07:36, 1 January 2007 (UTC)

There's no spec of Ruby for the moment. It is now stated in the "Criticism" section. Hervegirod 22:34, 9 May 2007 (UTC)

This is wrong now: An ISO standard is in the works, and hopefully will come out in 2010. —Preceding unsigned comment added by (talk) 13:27, 13 January 2010 (UTC)

Java comparison for constants

From Gotchas:

For example, Greeting << " world!" if Greeting == "Hello" does not generate an error or warning. This is similar to final variables in Java...

This is a poor comparison in my opinion, as Strings in Java are immutable, and a variable of type String would generally point to an instance in the String pool. The only way to "change" the String in Java would be to create a new instance and assign the variable to point to that, eg.:

 final String greeting = "Hello";
 greeting += " world!";

Which attempts to assign a new String instance to a final variable, and gives a compile error. Using a StringBuilder would solve the problem, but is most likely outside the knowledge of someone unfamiliar with Java, eg.:

 final StringBuilder greeting = new StringBuilder("Hello");
 greeting.append(" world");

Just a thought...

Samahnub (talk) 00:47, 24 September 2008 (UTC)

Hello, but in Java putting final on the String is a bit like using const in C's straightforward cases. There is nothing unusual in the fact that the code above is not allowed (in short if you declare something as final, it is not allowed to change). And if I'm not wrong this code works without problems:
 String greeting = "Hello";
 greeting += " world!";

However, I do think that the comparison is not clear for this case for the reader. Hervegirod (talk) 21:58, 25 September 2008 (UTC)

Block example

do puts "Hello, World!" end does not work in 1.8.6; does it refer to 1.9.0? -- Giorgio Gonnella, 15:04, 25 November 2008 (UTC)

You need ";" between puts "Hello, World!" and end if they are in the same line. --Kusunose 15:27, 25 November 2008 (UTC)
OK forget it, I misunderstood the meaning of the sentence (of course a block can't live by itself). --Giorgio Gonnella (talk) 16:11, 25 November 2008 (UTC)
(P.S. and if you do a lambda on it, you really even don't need the semicolon, i.e. lambda do puts "Hi" #=> Hi) —Preceding unsigned comment added by Ggonnell (talkcontribs) 16:13, 25 November 2008 (UTC)
My previous comment was incorrect; it works fine without a semicolon. Other examples: quit = proc do exit end; begin puts "Hi" end #=> Hi --Kusunose 16:36, 25 November 2008 (UTC)

Principle of least surprise

"And after two years of C++ programming, it still surprises me." 

What surprises me is that one would call himself a C++ programmer after just 2 years of practice. (talk) 07:14, 10 September 2009 (UTC)

  • That's a failing of C++, not Ruby. --Einstein9073 (talk) 01:33, 11 June 2010 (UTC)

Etymology of the name "Ruby"

We read under this heading: "CORAL 66 was used many years earlier by Digital Equipment Corporation as the name for a real-time ALGOL-like language". That isn't so, CORAL 66 was invented, and named, at the Royal Radar Establishment. If no one fixes this in, say, the next month I'll fix it myself. —Preceding unsigned comment added by (talk) 10:58, 9 October 2009 (UTC)

You're absolutely right. Thanks for that. Fixed, I think. All the necessary information, and more, was in the Coral 66 article. --Nigelj (talk) 18:42, 9 October 2009 (UTC)

Features section

Even if the change is generally informative, part of the new features section is a little WP:POV or WP:OR. For example:

  • Deeply object-oriented,
  • Sparse and flexible syntax that minimizes syntactic noise,
  • Lexical closures with an elegant block syntax

Some other parts aren't explained and are a little cryptic to the reader, such as:

  • Interpolation of arbitrary expressions in strings
  • Custom dynamic dispatch (through method_missing and const_missing)

And more, there are practically no references in this paragraph. Hervegirod (talk) 16:09, 11 October 2009 (UTC)

I wasn't trying to express my own POV but rather what Ruby programmers commonly claim to like about the language and/or what the design of the language was striving for e.g. the block syntax was intended to be a more elegant approach to higher order function syntax. Admittedly, this should be supported by references, which is the real problem with this section currently. References should be easy to find for all of these points and I had planned to do it myself when I get a chance.
WRT crypticness, some programmers might need to do a bit of background research to understand a few of the features but I didn't want to ramble. I couldn't find a helpful link for the custom dispatch thing but I figured "method_missing" would make it fairly obvious, or at least give the reader something to google.
Jedediah Smith (talk) 12:38, 12 October 2009 (UTC)

* I have a problem with the term Deeply object-oriented. It seems imprecise and unnecessary
* Sparse and flexible language to me does seem legitimate, though, as this is an intended "feature" of Ruby after all (saying beautiful would be POV)
* The term elegant seems to have been removed already
* The last 2 technical descriptions sound perfectly fine to me
-- (talk) 21:08, 15 October 2009 (UTC)
A bit late now, but it is useful to distinguish between object-oriented languages in terms of how "deep" the OO goes - you could say that Ruby is more object-oriented than Python and Java. The phrase "in Ruby, everything is an object" seems to crop up a lot. For example, numeric literals are officially objects, unlike in Java, so we can write:
5.downto(1) {|count| puts "T-minus #{count}"}
and we can add methods to classes on the fly quite easily. That said, Java's reflection capabilities have improved in the last while. Anyway, I'm not suggesting that "deeply" object-oriented is the right description, just that may be a reason to be more elaborate than simply saying "Ruby is object-oriented". Destynova (talk) 12:03, 22 July 2010 (UTC)

Ruby helping Lisp/Haskell/Smalltalk/Dylan ...?

I have the impression that many of those who try out Ruby go on to try Lisp, Haskell or some of the other 'hard' languages. If this could be confirmed (numbers might be hard to come by), it should show up in the article, because it says some things about the culture of Rubyism etc. I personally certainly am one of those I described.

 —it's certainly made me interested in those two as well, yes.  I wanna learn my C fundamentals and try to read some kind of path through the ruby source itself.  Maybe I'll fall more in love with another language along the way, but for now I enjoy ruby.  I'd say it encourages trying exotic constructs from other languages because it supports some and purports to sponsor more in future versions.  Pimp slap the funk (talk) 04:55, 2 January 2013 (UTC)