Try Ruby!

[bascule]

Ruby is the most programmer-friendly language I know of, with a syntax that tries to read like English as much as possible. It has all the features you'd expect of a modern language (strong typing, garbage collection, object orientation) with some nice power features that only language zealots like me seem to care about.

 

If you're interested in learning Ruby you can do it straight from your web browser without installing or configuring any software. Helpful lessons are built straight in, and you can do them all from the web (neato!)

 

http://tryruby.hobix.com/

 

The guy who made this site has some fun downloadable software aimed at younger students designed to teach them their first language (also using Ruby). It's called Hackety Hack and you can try it out here:

 

http://hacketyhack.net/

 

Works for adults as well, if you've gotten through Try Ruby and would like to learn more.

[Dak]

i'm just a noob and can only really code python, so this is a bit of a light-weight comment, but:

 

I like the right-stemmingness, eg:

 

var = 'i am a test 123'

 

print var.to_a.pop.reverse.to_i

eval: 1.........2......3.....4..........5

 

(gives 321)

 

in python would be:

 

print int(list(var).pop().reverse())

eval: 5.....2....1.......3........4

 

(gives 3)

 

(that ignores that the string object has no reverse() function, and that anyway it'd be working on a string of len() == 1, but apart from that that's where reverse() would go )

 

anyhoo, to me ruby reads 'take this, do this, then this, then this etc' which i like, whereas python's more 'do this to the result of doing this to this, and then do this', which can get a tad confusing. is ruby allways right-stemming?

 

cheers for the tutorial link btw

[bascule]

anyhoo, to me ruby reads 'take this, do this, then this, then this etc' which i like, whereas python's more 'do this to the result of doing this to this, and then do this', which can get a tad confusing. is ruby allways right-stemming?

 

Yes, Ruby relies on infix notation almost exclusively (one of the sad few places it doesn't are Rails views), but generally, Ruby prefers:

 

subject.verb object

 

which is what I meant when I said Ruby reads like English. For example, a Ruby testing framework (RSpec) lets you write your tests like:

 

should have_fewer_than(5).records

[Pangloss]

Bascule, do you know any good tutorials/sites for people who want to learn Ruby who are coming specifically from an ASP.NET background? I teach such a course and I'd like to provide more information for the students to widen their horizons a bit. I focus on core concepts so they don't get TOO rooted in the Microsoft stuff, but I'd like to add more, maybe even throw a couple of Ruby or Perl/Python programs together towards the end of the course when time permits.

 

(But especially Ruby, because of the straightforwardness of it.)

 

(I'm specifically focused on web apps that do simple, data-driven web pages for this course, e.g. running reports on an employee database, for example. I want to keep the focus on that kind of app, but broaden to just show how it's done in another language.)

[bascule]

Bascule, do you know any good tutorials/sites for people who want to learn Ruby who are coming specifically from an ASP.NET background?

 

If you're coming from a VB.NET background you'll find Ruby has an imperative syntax much like BASIC. Things like for loops and while loops behave similarly. No variable or type declarations are required. Of course, most Rubyists never use Ruby's imperative syntax and prefer to do everything with blocks, which takes a bit of getting used to.

 

If your background is C# it's quite a bit different. Dynamic typing might take awhile to get used to, and the syntax is going to be quite a bit different.

 

I teach such a course and I'd like to provide more information for the students to widen their horizons a bit. I focus on core concepts so they don't get TOO rooted in the Microsoft stuff, but I'd like to add more, maybe even throw a couple of Ruby or Perl/Python programs together towards the end of the course when time permits.

 

You might have a look at IronPython or IronRuby. These projects both work on the .NET CLR runtime and interoperate with the .NET framework.

 

(But especially Ruby, because of the straightforwardness of it.)

 

(I'm specifically focused on web apps that do simple, data-driven web pages for this course, e.g. running reports on an employee database, for example. I want to keep the focus on that kind of app, but broaden to just show how it's done in another language.)

 

Well, Rails is definitely great for that sort of thing

[Dak]

but generally, Ruby prefers:

 

subject.verb object

 

list.append thing

 

?

 

cool if so... i tend to make a lot of silly syntax mistakes (missing off brackets etc), so a more intuitive english-like language might be cool for what little i use it.

 

now if i could just stop misspelling my variabels...

[Royston]

I had a play last night, during assignment breaks...took me back to my BASIC days, it was fun.

 

As I've decided to get back into programming (starting a Java course through work soon.) Ruby seems like a very intuitive language for somebody who hasn't programmed for as long as I have...thanks for the link

[the tree]

Every now and again, I suddenly decide that I'm going to learn programming language, I download a bunch of compliers or interpreters, I sometimes get as far as the Hello World program but then I loose motivation mostly as a result of not really having a good simple task to aim to.

 

Finally, I actually have to learn a programming language because I'm actually studying it, in this case it's MAPLE. So I suspect that for now, I wont manage to learn Ruby as well. Hopefully when I know one language deeply, I might actually be able to learn others.

[bascule]

list.append thing

 

There's a few ways to do that, for example:

 

>> list = []

=> []

>> list.push :foo

=> [:foo]

>> list += [:bar]

=> [:foo, :bar]

>> list << :baz

=> [:foo, :bar, :baz]

 

(in this case :foo, :bar, and :baz are symbols, also known as atoms. you can think of them like a big global enum)

 

cool if so... i tend to make a lot of silly syntax mistakes (missing off brackets etc), so a more intuitive english-like language might be cool for what little i use it.

 

now if i could just stop misspelling my variabels...

 

Testing helps with that sort of thing

[Pangloss]

Thanks for the tips. The IronX projects look interesting and very productive, but I really want to get the students out of the familiar Visual Studio setting and show them something environmentally different, if I can squeeze it into the tight classroom schedule somehow. What I'll have to come up with is a lecture and lab that put together a simple, data-driven web site in a very short amount of time.

 

Do you have any experience with InstantRails?

http://instantrails.rubyforge.org/wiki/wiki.pl

[bascule]

Nope, I've never used Ruby on Windows. Supposed to work quite well though, completely native and everything.

[pcollins]

Dynamic typing takes a bit of getting used to because its pretty damn easy to loose track of type when piling through highly coupled, large yet poorly documented codebases. This is a problem in most every scripting language and the price you pay for brevity in introspection.

 

That said, I can't agree with bascule that Ruby is especially more programmer friendly than other languages. Semantically it's not introducing anything thing different from Perl and syntactically its extremely close to Python in the 2.1 era. On top of that, Ruby is by far more poorly documented both as a language and in its libraries than either Perl or Python. Disregarding frameworks, I've seen no improvement in the time to deployment or release stability in Ruby projects. Including frameworks, I'd find little advantage in eRuby over any number of Perl or Python templating engines and I'd give preference to DBIC--which merely wraps around a well established, well-supported, enterprise ready database handler--over ActiveRecord. I don't mean to fault the design decisions reached by the Ruby and Rails communities or their issue tracking, but simply noting that language and tools offered often don't offer much to set them apart from competitors and in some key areas fall short.

 

Do you have any experience with InstantRails?

http://instantrails.rubyforge.org/wiki/wiki.pl

 

Only to prototype J2EE apps in Win32 shops. I'm not sure how well bundle solutions work in the small to mid-size space, but I don't know any large company that uses them and I imagine you're eventually going to cut away from the database and webserver in favor of something...well...scalable.

[bascule]

Dynamic typing takes a bit of getting used to because its pretty damn easy to loose track of type when piling through highly coupled, large yet poorly documented codebases. This is a problem in most every scripting language and the price you pay for brevity in introspection.

 

The easy solution here is extensive use of type coersion or methods that check the types of their arguments and respond accordingly.

 

That said, I can't agree with bascule that Ruby is especially more programmer friendly than other languages. Semantically it's not introducing anything thing different from Perl and syntactically its extremely close to Python in the 2.1 era.

 

Blocks come to mind in both cases, specifically from a syntactic standpoint (not to mention procs when talking about full closures). Furthermore, Ruby does smooth over a lot of the ugliness in the Python syntax, namely explicitly passing self as an argument to methods and explicitly referencing self for instance variables. Of course this leads into Python's dicts versus Ruby's metaclass structure, which really comes down to personal preference. From an ideological perspective I'd prefer something like dicts, but the syntax this approach leads to leaves me with something of a bad taste in my mouth. I have similar qualms with Erlang in this regard.

 

All that said, Ruby has a number of features that make it more programmer friendly which you certainly won't find in a language like Perl (5). The "runtime is an open book" approach, with extensive hooks into the method dispatch system, allows for expressive metaprogramming. Modules like ParseTree facilitate parse transforms, certainly not on the order of Lisp macros (unfortunately Ruby does not parse to sexps, but it's close) but enough to facilitate some really powerful transformations, such as translating the Ruby Enumerable interface into SQL:

 

http://errtheblog.com/post/11998

 

On top of that, Ruby is by far more poorly documented both as a language and in its libraries than either Perl or Python.

 

As far as core Ruby and the stdlib go, Pickaxe v2 is an excellent language reference. I'll certainly admit ri leaves a little to be desired, and with gems YMMV, some are immaculately documented (check out anything by Zed Shaw, why, or Evan Weaver) and some are completely undocumented. However, you'll find the same thing with CPAN.

 

Including frameworks, I'd find little advantage in eRuby over any number of Perl or Python templating engines

 

There are dozens of templating engines available. ERb is going for the lowest common denominator approach and targeting people familiar with JSP/PHP. It's also relatively fast, and great for injecting Ruby code into YAML (which of course gets back to Steve Yegge's thing about why are config files written in something other than code which knows how to evaluate itself, but...)

 

Rails real innovations lie in things like its REST abstractions, to where you write one REST interface for all CRUD operations that can be used to facilitate manipulating the resources from an HTML-based interface or a REST-based API (which can return XML, JSON, etc) with similar innovations on the REST client side (ActiveResource). There's effectively one DAO to rule them all, and its interface functions quite similarly to ActiveRecord.

 

I don't mean to fault the design decisions reached by the Ruby and Rails communities or their issue tracking, but simply noting that language and tools offered often don't offer much to set them apart from competitors and in some key areas fall short.

 

You can certainly make that case for Python, however I'd make it specifically against core Ruby. Core Ruby (i.e. the VM) is something of an implementation nightmare, and Ruby has remained quite slow compared to most languages. Its garbage collector is simplistic (mark and sweep only) and has a tendency to mark pages dirty when they really aren't (i.e. it's not copy on write safe when forking). This is supposed to get fixed this Christmas with the 1.9.1 release which includes a new stack machine called YARV, however YARV has been dragging along for many years (I remember discussing its impending release with my roommate some 4 years ago) and I entirely expect that the Christmas deadline won't be met for one reason or another.

 

That said I've been using YARV from the developer trunk and it really is quite impressive. It's substantially faster and there's a number of new concurrency primitives I've been playing with, but they certainly can't hold a candle to Stackless Python (which in turn can't hold a candle to Erlang)

[pcollins]

The easy solution here is extensive use of type coersion or methods that check the types of their arguments and respond accordingly.

 

A solution which sacrifices terseness, imposes legal types on a signature, and dirties up error handling by increasing the number of type exceptions vis a vis functional ones. It also leaves unsolved the readability problem faced by developers new to a large, complicated code-base.

 

Blocks come to mind in both cases, specifically from a syntactic standpoint (not to mention procs when talking about full closures).

 

Not sure what you mean here. Perl and Python both support closures.

 

Furthermore, Ruby does smooth over a lot of the ugliness in the Python syntax, namely explicitly passing self as an argument to methods and explicitly referencing self for instance variables.

 

This is a style choice, and quite frankly an arbitrary one. The most common place you'll find explicitly passing self in Python and Perl is in inheritance and you are offered an explicit way of passing functionality as well as attributes that might be handled instantiation of inherited state. Of course, that pattern is used so infrequently it's simply a matter of habit to write

Parent.Parent(self) or bless $something_to_be_self, $class.

 

Of course this leads into Python's dicts versus Ruby's metaclass structure, which really comes down to personal preference. From an ideological perspective I'd prefer something like dicts, but the syntax this approach leads to leaves me with something of a bad taste in my mouth. I have similar qualms with Erlang in this regard.

 

You're going to have to be a little more specific here.

 

All that said, Ruby has a number of features that make it more programmer friendly which you certainly won't find in a language like Perl (5). The "runtime is an open book" approach, with extensive hooks into the method dispatch system, allows for expressive metaprogramming.

 

"Expressive" is a remarkably subjective term, especially when we're considering that Ruby has to build in hooks into its object model whereas Perl all you have to do is access the appropriate reference to the backing hash. Whether or not it's more appropriate to define some solely legal convention to do this is more a matter of style than anything, and anyone who prefers a clean evolution from primitives to structs to objects is going to appreciate the Perl way more than the Ruby one.

 

Modules like ParseTree facilitate parse transforms, certainly not on the order of Lisp macros (unfortunately Ruby does not parse to sexps, but it's close) but enough to facilitate some really powerful transformations, such as translating the Ruby Enumerable interface into SQL:

 

This is precisely what Perl B and Python parser are for.

 

As far as core Ruby and the stdlib go, Pickaxe v2 is an excellent language reference.

 

Pickaxe is Ruby's Camel with a standard library reference, granted.

 

I'll certainly admit ri leaves a little to be desired, and with gems YMMV, some are immaculately documented (check out anything by Zed Shaw, why, or Evan Weaver) and some are completely undocumented. However, you'll find the same thing with CPAN.

 

Except perldoc isn't CPAN anymore than ri is ruby-forge.

 

There are dozens of templating engines available. ERb is going for the lowest common denominator approach and targeting people familiar with JSP/PHP.

 

The "lowest common denominator" is still the most efficient way to marry UI developers with graphic designers.

 

It's also relatively fast, and great for injecting Ruby code into YAML (which of course gets back to Steve Yegge's thing about why are config files written in something other than code which knows how to evaluate itself, but...)

 

Rails real innovations lie in things like its REST abstractions, to where you write one REST interface for all CRUD operations that can be used to facilitate manipulating the resources from an HTML-based interface or a REST-based API (which can return XML, JSON, etc) with similar innovations on the REST client side (ActiveResource).

 

Yeah. Cocoon-lite. I'll grant you this one.

 

There's effectively one DAO to rule them all, and its interface functions quite similarly to ActiveRecord.

 

Why is it an advantage to have one DAO--or more accurately two similar DAOs--rule them all? For the most part, you want to treat ActiveRecord and ActiveResource as plain old objects with some underlying machinery to grab state.

 

You can certainly make that case for Python, however I'd make it specifically against core Ruby. Core Ruby (i.e. the VM) is something of an implementation nightmare, and Ruby has remained quite slow compared to most languages. Its garbage collector is simplistic (mark and sweep only) and has a tendency to mark pages dirty when they really aren't (i.e. it's not copy on write safe when forking).

 

Process management in most any dynamic language is a nightmare, I'm not going to get so petty as to try and fault or comp one over another in that department.

 

This is supposed to get fixed this Christmas with the 1.9.1 release which includes a new stack machine called YARV, however YARV has been dragging along for many years (I remember discussing its impending release with my roommate some 4 years ago) and I entirely expect that the Christmas deadline won't be met for one reason or another. That said I've been using YARV from the developer trunk and it really is quite impressive. It's substantially faster and there's a number of new concurrency primitives I've been playing with, but they certainly can't hold a candle to Stackless Python (which in turn can't hold a candle to Erlang)

 

I don't expect great things from YARV. For one, its development has dragged on so long I don't expect its pthread support to offer significant improvements over that in Python. In this area, Perl is significantly more mature (which isn't saying much). Bringing Ruby up to speed with Python isn't much of an accomplishment.

[bascule]

I'd rather not derail this thread with an in-depth discussion of Ruby's flaws. Perhaps you'd like to post a thread on Perl vs. Python vs. Ruby?

 

Let me just say that I greatly respect Python and totally agree that for all intents and purposes it is "better" than Ruby, particularly in terms of its implementation. The ruby-core developers are definitely playing catchup at this point, and for now Ruby is one of the slowest languages in existence.