Slashdot Mirror

This was discussed at the Ruby implementor's summit at RubyConf.new(2006), and Charles Nutter has started a ruby spec wiki:

http://www.headius.com/rubyspec

Also discussed was specification through tests (that is, if an implementation passes the unit tests for the most commonly used set of ruby applications/libraries, then it is good enough).

For the notes on the summit:

http://wiki.rubygarden.org/Ruby/page/show/RubyImpl emntersSummit2006Nov
http://www.google.com/search?q=cache:wylYVnj0RpIJ: wiki.rubygarden.org/Ruby/page/show/RubyImplemnters Summit2006Nov&strip=1

I'm overwhelmed by your citation of sources and real-world examples proving your claim of Ruby's slowness!

Rails, not counting rendering or database query, takes anywhere from a few to several millseconds to respond to any web query on a modern Xeon processor.

I'm not sure I understand the argument of "real world examples" when it comes to performance. Either someone cares about performance or they don't. Over the span of the entire life of Rails, the argument has been "the database is the bottleneck anyway" and "well, it's not slow enough for my blog app!" Ok, so when is it slow enough? We live in a world where people still have to bust out ASM to get desired performance for some applications. For web applications, is performance so unimportant compared to development time that we're willing to make any sacrifice necessary? I don't agree with that sentiment, and neither does the developer of Ruby, who's working on a new, performance-oriented interpreter http://www.rubygarden.org/ruby?Rite

This may be more active and more complete: http://rubygarden.org/ruby?RubyUserGroups.

NASA uses Ruby also (and no doubt a few dozen other languages)

see here about NASA Ruby (and Python and Perl and other open source) use and also here for NASA and other companies

Python runs on an amazing number of OS , from embedded ones to mainframe (maybe a couple java can't?). Ruby can run on Windows, Unix/Linux/BSD, OpenVMS, BeOS, amiga. Ruby even runs with threads on MS-DOS.

I just wanted to clarify a few things. Our discussion has had some tangential points about FP but has mostly cnetered around dynamic vs. static typing.

I think functional programming is really neat. However, for all of the time I spent using Lisp I still don't call it up as my programming language of choice in my head. I tend to think OO and Procedural in something akin to Java in my head. Java isn't such a terrible language. I have used it so much and like OO and procedural so much that it has just kind of became my default over the years.

Types are important. I just don't see how specifying the type in code is a requirement. I gain rapid prototyping and a more fluid programming environment which can be really handy when dealing with rapidly changing projects or clients that don't know what they want. This flexibility to bend and stretch and kind of organically grow the software really helps. The whole "I will know what I want when I see it" problem. Sure we start off with a pretty good spec on most projects, but clients and their ideas will always differ from what is written on the spec doc. I have had better experience in dealing with changes in the scope of a project with more dynamic languages.

Ok back to code for a minute. Lets say I have a line of code like this:

thingee = new FooBar();

I now have thingee holding onto a reference to a FooBar object. I know its type. It is of type FooBar. It is very difficult to miss the fact that I just made a FooBar object. So where does that leave me. Well I didn't specify the type thingee can hold. In the world of static typing if I tried to make thingee hold a reference to anything other than a FooBar object I would be really sad. That *CAN* be a good thing. But what if I really wanted thingee to be able to hold references to other objects of any type. In Java I can do this by just making thingee a reference to an Object. Voila now it can hold anything. I just eliminated type safety and gained a little dynamic fun. But you see the language does not like for you to do that. It complains when I do things to the Object that it doesn't think I should be doing. I can only do Object things to and with thingee because it is only an Object. So it does not let me do something like that. Thus it feels like the language is stopping me from doing things that occasionally I may really want to do. In dynamic language world we will just assume the programmer knows what he is doing when he asks the object referred to by thingee to do something. If not you get an error. But then you run into the same problem dealing with generic collections. Java bolted Generics on to deal with this so that you can Type your collections using some compiler syntax. I don't like it as I don't think it really does much to help. Yet you can now have compile time safety when using collections very similar to what you have in C++. I insist that my language let me do just absolutely CRAZY stuff like invoke ANY method on an object. Its my fault if I screwed up and the object referred to by thingee does not have that method. With type safety I don't have the flexibility. With type safety I do have a little extra comfort but I don't have quite as much flexibility about what my references point to.

To me this is great. I can break the rules in the eyes of a strongly typed programming language and it does not freak out. I like being able to do this. It has been immensely helpful. Combine that with things like mixins (Ruby's answer to multiple inheritance) and you can create objects that have different modules mixed in to dynamically tweak an object as it is going. So its less about its type and more about what the object can do at a given point in time. So in my experience so far I start thinking in terms of what a particular INSTANCE of an object can do at the current time. Not what the class can do as a whole. Check out this link on duck typing: Duck Typing(And yell at me if it is broken again) To me this just seems more in

Ruby selectively integrates many good ideas taken from Perl, Python, Smalltalk, Eiffel, ADA, CLU, and LISP.

Yeah, I did some more looking into ties, and the example I gave before is probably not the best one. However, learning about the feature has been a good experience.

As I understand it, ties are essentially ways of intercepting messages to make more complex structures look like standard types. This has a lot of application in databases, but could be used anywhere. It's a lot (if not exactly) like a Proxy Pattern, which I will return to.

However, I think the Ruby language itself removes the need for the need for this, because of the uniformity of objects - there's nothing special about a hash, array, etc. If I wanted to do the same thing, I would just write a simple interception class, and handle this kind of thing with the method_missing functionality.

Take a look at this Ruby implementation of a Proxy Pattern to get an idea of what I'm talking about:
http://www.rubygarden.org/ruby?ProxyPattern

This is an implementation of distributed system calls, but you can imagine (and I have done on several occasions) caching calls to a database abstracted through the same idea, making a database look like an Array. Heck, Ruby is so dynamic, you can even redefine the class method so that your interceptor class appears to have the right type!

Rails has multiple possibilities for caching web content at different granularities. You could at least have googled for "Rails caching" and incorporated the results in your posting to make it look as if you'd made a comparison.

Essentially everything but assembler and C/C++ uses some variant of "managed code that protects from errors", and Ruby is no exception.

The Ruby and Rails communities are very competent and helpful, and Rails itself is actually easy enough that you can read and understand the source code in a few days. I strongly dispute the claim that big real-world applications (that's those containing large amounts of business code, not just a dragged'n'dropped bunch of databound controls) require less code in ASP.NET than in Ruby. Ruby's OOP features and its meta-object protocol (i.e. runtime "hackability" of artifacts of the language itself) make it easy to write very clean, high-level, declarative code.

Let's just say that you may know something about J2EE and ASP.NET but not much else :-p

The way you answer reflects a rigid top-down mindset. After reading some of Paul Graham's essays, I began to question that way of thinking and asked myself if Rails could be built easily outside of Ruby, or alternatively, whether the types of problems that Rails addresses are more efficiently handled by your top-down list of components. Rails is more than a UI framework; it's being grown from the language up towards web app solutions. If you read some of Graham's essays in the light of Ruby on Rails, you might reconsider.

Graham suggests new languages may be trending towards LISP, perhaps because LISP was initially a theoretical exercise by McCarthy, a gedankenexperiment not really designed to be shoehorned into 1958 computational constraints, but rather discovered "when you try to axiomatize computation." (See Graham's full postscript paper The Roots of Lisp .) FORTRAN and C, on the other hand, took a lot of cues from the hardware; they had to be fast. Over time, the lower-level languages have been relegated to handle algorithmically-simple, computationally-needy problems, while the scripting languages - PERL, PHP, Python, Ruby - have been getting fast and moving from simple glue to more complex processing tasks.

Two decades have passed since I looked at LISP code, and I'm wondering if I like Ruby because it's as powerful as that language in my distant memory, yet more aesthetically pleasing syntax-wise since I'd been coding in C, C++, and PHP. It's refreshing to be using a true object-oriented (message-based) language that has strong (as in "walks like a duck") typing, closures, and seemingly dynamic everything (types, open classes). Although I'm relatively new to Ruby and Rails, I can see this is a language I'm going to enjoy using and figuring out.

Graham talks about bottom-up design , changing the language to suit the problem. It suggests one reason why Rails looks so good compared to other web frameworks: Rails looks like souped-up Ruby and not just a bunch of classes, procedure calls, and bolted-on code.

"In Lisp, you don't just write your program down toward the language, you also build the language up toward your program," Graham wrote. "Language and program evolve together... In the end your program will look as if the language had been designed for it. And when language and program fit one another well, you end up with code which is clear, small, and efficient." That's a pretty good description from 1993 on Rails development and points to a not-so-subtle difference between the web frameworks.

Just as standard Ruby lets you use "attr_writer :some_attribute", Rails provides a formalism for defining data relationships like "has_many :data_thing". The Ruby Way seems to run deep. It'll be interesting to see if Rails manages to adhere to that philosophy as it expands.

When answering the question "Could Rails be built without Ruby?", I think you have to address not only the functionality but the aesthetics as well. It's more than the simple lines-of-code metric. It's whether you've built a language up towards a Rails language that solves problems common in web development. As Graham points out, you could build Rails out of any language that's Turing-equivalent; the real question is in your quest to duplicate the aesthetics, whether you'd wind up doing a back-door implementation of a Ruby interpreter in the process. For Python users, the port might not be incredibly difficult. For C users, it might be easier to build a Ruby interpreter.

One of the knocks against Zope 2, a leading Python app and backend server framework, was how un-Pythonic the framework appeared to some developers

Ruby on Rails? Datavision? Basecamp? Instiki?

Take a look at this ad hoc list of Ruby applied. It's a relatively young language, so there aren't as many libraries/apps as something like C or Java, but it's growing.

A categorized collection of ruby links can be found here in a nicer format:

http://www.rubygarden.org/ruby?RubyOnTheNet

Interactive ruby resources:

irc://irc.freenode.net/ruby-lang - the #ruby-lang channel is popular. More info at RubyOnIRC

http://www.ruby-forum.org/bb/ - a forum for ruby novices to ask questions

news://comp.lang.ruby - the ruby newsgroup

Ruby websites:

http://www.ruby-lang.org/ - ruby home

http://www.ruby-doc.org/ - ruby docs and online reference

http://www.rubyforge.org/ - rubyforge ruby projects

http://raa.ruby-lang.org/ - ruby application archive

Ruby Code Examples and Snippets:

http://pleac.sourceforge.net/pleac_ruby/ - ruby pleac

http://www.rubygarden.org/ruby?RubyOnlineCookboo k - ruby cookbook

Popular ruby and ruby-related projects:

http://rubyinstaller.rubyforge.org/wiki/wiki.pl - ruby installer for Windows

http://rubyforge.org/projects/rubygems/ - rubygems ruby package manager

http://www.yaml.org/ - ruby 1.8 includes built-in yaml support

http://www.rubyonrails.com/ - web framework in ruby

http://rubyforge.org/projects/instiki/ - wiki in ruby

Here is how to get started:
Extending Ruby
That is from the 1rst edition, I recommend getting the 2nd.
Also take a look at the README.EXT (come with the ruby source code).

Here are some helpful links (a bit more advanced):
Ruby Source Code Browser
Ruby C API Docs
GC And Extensions
Ruby Talk

I must admit the learning curve for C extensions is a bit steap if you don't have experiance in either language. Also more tutorials are needed.

-Charlie

Here is how to get started:
Extending Ruby
That is from the 1rst edition, I recommend getting the 2nd.
Also take a look at the README.EXT (come with the ruby source code).

Here are some helpful links (a bit more advanced):
Ruby Source Code Browser
Ruby C API Docs
GC And Extensions
Ruby Talk

I must admit the learning curve for C extensions is a bit steap if you don't have experiance in either language. Also more tutorials are needed.

-Charlie

a) See http://www.rubygarden.org/ruby?RealWorldRuby

b) It's a marvelous tool to increase productivity; I wrote something in ~2 hours which parses ~70 XML documents in ~10 directories and creates 150+ static HTML pages (for a help system shipping with the application) from moderately complex business logic off of 5 template files.

Changed or added an XML document? Run the ruby script. Need an HTML tweak? Change one template file and run the script. 3 seconds to parse the XML documents (and apply Textile markup to certain sections) and 3.5 seconds to create the HTML.

Ruby allowed me to very quickly write a complex tool that now saves me a huge amount of time every time I use it. Even *if* no companies were hiring specifically for Ruby skills, having a tool in your belt that makes you stand out is still a Great Thing.

I really think that if you're coming from Perl you'll prefer
Ruby to Python. No indentation hassles with Ruby, for example. You'll also like the way Ruby does OO compared to Perl OO. More Rubilicious links...

Also, The Pragmatic Programmers have released a new edition of Programming Ruby that's a great intro and reference to the language - go buy it from their website.

Ruby: Because I can't wait around for Perl 6 to get finished

NASA, Motorola, and others seem to enjoy riding the cockboat..

but don't talk shit about a language that people actually use

Exactly.

You mean like:

Doc

http://www.ruby-doc.org/

http://www.rubycentral.com/book/

Unit Testing

http://testunit.talbott.ws/

http://www.rubygarden.org/ruby?RubyUnit

Library Repository

http://raa.ruby-lang.org/

Portability
Source compiles on anything vaugely Unix like

Windows binaries available

User Community
comp.lang.ruby

So, what were you on about again?

Ah, now I've found some better explanations and a comparison of Python generators and Ruby iterators. Regardless of their relative merits or precedence, I think C# is following Python not Ruby here, but I may have misunderstood the specification.

Here's a comparison of Ruby and Python.

This troll was plagiarized from http://www.rubygarden.org/article.php?sid=256.

I never encountered an actual application written in Ruby

Check out the RealWorldRuby wiki page for a list of real world applications of Ruby. It's in use at NASA, Intel, HP and Agilent among others.

the latest news item on RubyForge is about a program for sorting (sorry, but it did not impress me very much)

You have to remember that RubyForge has only been up for about a week.
A couple of applications that are coming soon:
* A genetic algorithms package
* A swarm particle optimization package

Well, maybe, until you use Ruby. At that point you realize that Python is by no means OO from the ground up. I like Python, it's one of my favourite languages, and it has been around for years... but while I like Python, I love Ruby because it is the most completely OO language I have ever used, and that is really handy. For a comparison, I'd recommend a page on the ruby site which is linked to from the python site, and contains a posting to comp.lang.python, so I'm guessing it's not too biased either way.

Although I use Ruby all the time at home, I'm stuck using Python for some things at work now, but as soon as Ruby matures a little more, I'll start using it here too.

Ruby 1.8 is supposed to be released Real Soon Now, and it includes a number of significant changes (see Programming Ruby Two, a Wiki page about a hopeful second edition of Programming Ruby covering 1.8.) -austin

for (i = 1; i <= 10; i++) {
j = j + i;
}

for ($i = 1; $i <= 10; $i++) {
$j = $j + 1;
}

for i in range(1,10)
j = j + i

Actually, the entire content of the post is one question and two outright falsehoods.

Check out the ruby-lang pages list of docs there's a lot of good stuff there.

I own Programming Ruby - The Pragmatic Programmer's Guide (available in full online) known as 'The Pickaxe Book' (ie the Ruby Camel) and Ruby in a Nutshell from OReilly by the language designer Yukihiro Matsumoto (known as matz on the mailing list). Hail matz! :)
Then there's a personal favorite dead tree of mine The Ruby Way by Hal Fulton. I haven't finished it yet but it's full of crunchy goodness.

Between, those books and the wealth of tutorials and docs linked from www.ruby-lang.org/en there's a lot more material available than there was for Python when I started using it.

And the fact that these books keep selling and getting published implies to me that people are using Ruby.

When in doubt check the Ruby Book list at www.rubygarden.org to see whats out now and whats in the pipe.

As far as the bindings being buggy - I've only played with a few but they seem as good as I recall pythons bindings from when I used python. (admittedly that was a while ago)

C'mon give Ruby a try - I've found it a delight to play with. You might like it - and if not -well, learning why you dislike it is a valuable type of learning as well :)

I suggest the Pickaxe book (you'll eventually want to buy a hardcopy) and if you don't want to download the interpreter right now - well hold onto your hats. A clever fellow named Clemens Wyss has an 'interactive' version of the Pickaxe with all the code examples live in your browser so you can play with the code a lil. Find it here

In closing:
RubyCentral
RubyGarden
Ruby-Lang
Ruby-Talk Mailinglist

or check out the newsgroup at comp.lang.ruby

Kevin
--
'Just another Ruby Miner'

Actually, the entire content of the post is one question and two outright falsehoods.

Check out the ruby-lang pages list of docs there's a lot of good stuff there.

I own Programming Ruby - The Pragmatic Programmer's Guide (available in full online) known as 'The Pickaxe Book' (ie the Ruby Camel) and Ruby in a Nutshell from OReilly by the language designer Yukihiro Matsumoto (known as matz on the mailing list). Hail matz! :)
Then there's a personal favorite dead tree of mine The Ruby Way by Hal Fulton. I haven't finished it yet but it's full of crunchy goodness.

Between, those books and the wealth of tutorials and docs linked from www.ruby-lang.org/en there's a lot more material available than there was for Python when I started using it.

And the fact that these books keep selling and getting published implies to me that people are using Ruby.

When in doubt check the Ruby Book list at www.rubygarden.org to see whats out now and whats in the pipe.

As far as the bindings being buggy - I've only played with a few but they seem as good as I recall pythons bindings from when I used python. (admittedly that was a while ago)

C'mon give Ruby a try - I've found it a delight to play with. You might like it - and if not -well, learning why you dislike it is a valuable type of learning as well :)

I suggest the Pickaxe book (you'll eventually want to buy a hardcopy) and if you don't want to download the interpreter right now - well hold onto your hats. A clever fellow named Clemens Wyss has an 'interactive' version of the Pickaxe with all the code examples live in your browser so you can play with the code a lil. Find it here

In closing:
RubyCentral
RubyGarden
Ruby-Lang
Ruby-Talk Mailinglist

or check out the newsgroup at comp.lang.ruby

Kevin
--
'Just another Ruby Miner'

It's hard to reply to this -- how could this (obvious) flame get moderated so high? I don't understand why you think that for Ruby to be useful it has to obsolete Python?

I don't know Python, but I suspect the features of both Ruby and Python are similar. The syntax for Ruby is very nice.

What happened to you (switching from Perl to Python) is basically what happened to me, except it was Perl -> Ruby.

Can't you accept that it's possible for someone to actually like one language more than the other? (you obviously do, and are so closed minded to not give Ruby more than a quick look over)

I recommend reading some of the Pickaxe Book, which is available online.

I mainly use Perl, but have written a few utils in Python just to get a feel for the language. I've got to say, while Python appeals aesthetically, I can write anything an order of magnitude quicker in Perl (thought familiarity is doubtlessly an issue here.)

Ruby is, IMHO, even more attractive than Python for its more thoroughgoing object orientation, for example in Python you would write:

Whereas Ruby treats foo as an object with its own methods from the word go:

Add to this other goodies like block iterators and Ruby is looking very good.

What would stop me using Ruby is firstly the relative lack of maturity. (Though for some it would be an attraction to get into a language at the ground storey). And secondly the relative (and related) lack of Ruby programmers. The fact that Ruby can be written in a dialect that can be easily understood by Python (and even Perl) programmers, mitigates against this to some extent.

I'm not sure about support, but the availability of a free on-line text Programing Ruby (you can also but the hard copy), and a discussion group at Ruby Garden might go some way to alleviating your fears in that regard.

All in all Ruby looks like one of the nicest little scripting languages around -- Smalltalk meets Perl meets Python -- and I wish it the best of luck. With a bit of maturity I might even consider applying it in a production environment.

I think as long as it's use is based on it's usefullness (which has been the case with most scripting languages), it's only a matter of time.

Ruby has been as much of a pleasent surprise to me as Perl was back when I first learned it. No, it's not "Perl with Objects"; Perl itself does that quite well. It's more like Smalltalk, only readable, pragmatic rather than idealistic, and as expressive and concise as Perl when you want it to be. Personally, i think Ruby is a much greater threat to Perl than Python is, in the long run. Rather than forcing you to do it Guido's Way, you can do it the Perl Way, or the Smalltalk Way, or the Functional Way... or any combination of the above. No wonder the Pragmatic Programmers wrote a book on it. It does TMTOWTDI better than Perl does TMTOWTDI; while remaining relatively simple and clean.

So just give it time. I think it's well on it's way to world domination.

Oh, and as for a CPAN-like code archive for Ruby, there's a somewhat embrionic one here. There is discussion currently going on at the RubyWiki on how to implement a CPAN-like system for Ruby only avoiding the problems that CPAN has.

--

I think as long as it's use is based on it's usefullness (which has been the case with most scripting languages), it's only a matter of time.

Ruby has been as much of a pleasent surprise to me as Perl was back when I first learned it. No, it's not "Perl with Objects"; Perl itself does that quite well. It's more like Smalltalk, only readable, pragmatic rather than idealistic, and as expressive and concise as Perl when you want it to be. Personally, i think Ruby is a much greater threat to Perl than Python is, in the long run. Rather than forcing you to do it Guido's Way, you can do it the Perl Way, or the Smalltalk Way, or the Functional Way... or any combination of the above. No wonder the Pragmatic Programmers wrote a book on it. It does TMTOWTDI better than Perl does TMTOWTDI; while remaining relatively simple and clean.

So just give it time. I think it's well on it's way to world domination.

Oh, and as for a CPAN-like code archive for Ruby, there's a somewhat embrionic one here. There is discussion currently going on at the RubyWiki on how to implement a CPAN-like system for Ruby only avoiding the problems that CPAN has.

--