Benefits of Ruby?

[dbj]

are you sure?

[phpPete]

Yeah, it makes you hip. There is massive amount of smugness around rails...sorta like hybrid cars (see that south park?).

Or like Python a few years ago. Give me my curly braces! Reading VB/Python/Ruby is just painful because the syntax is just plain ugly.

[I87]

Yeah, it makes you hip. There is massive amount of smugness around rails...sorta like hybrid cars (see that south park?).

I totally agree
RoR is hyped too much
it's what you're used to
I know I can do the exact same things in PHP with the same amount of code (or maybe a line more)

[vgarcia]

Vgarcia, as someone else pointed out in this discussion, you cannot go and study a new programming language willy nilly with all your projects being sidelined. While learning a new skill is a must, programmers have to make living and therefore have to prioritise what they learn and when they learn. A big influence as to what to learn is the question that "will it be necessary addition to my skillset?". So I am not against learning new stuff. We are all for that. But you cannot learn everything in the short amount of time you could steal from your busy schedule. That is my whole point.

You can learn enough about rails in an hour of playing around with it to know whether you'll enjoy programming in it or not. I played with Rails over a bored Saturday afternoon when I was first learning, and I ended up liking it. I'm not telling you to brush off your paid work to learn it, not by a long shot. But you should be able to devote one hour every once in a while (yes, possibly even on your own unpaid time) to try new things or learn more about the line of work you're being paid to do.

I make a living too and I was able to take out the hour, and I still do make the time every so often to try out new languages. It's really a small time investment for something that could potentially pay off in a big way (increased productivity and happiness in the workplace).

Or like Python a few years ago. Give me my curly braces! Reading VB/Python/Ruby is just painful because the syntax is just plain ugly.

You can make Ruby look a lot like PHP actually, well except for the dollar-signed variables everywhere:

before_save { |p|
  p.expires_at = Time.now + 30.days;
}

See? Curly braces and semicolons. If fluff syntax is all you're missing then that's pretty easy to throw in.

[hannson]

I am also confused about ROR and other frameworks (including php ones). I just don't get it. I've looked through several 'get started' tutorials, and sure, it takes hardly any time to come up with an application... but I just hate the way everything is done for you. I want control over that myself - I don't want to take a short amount of time to come up with an application, and then spend a longer amount of time getting it how I want! It seems to impose certain things on you (editing, deleting, adding, updating are always there - no flexibility), and I don't feel like I'm in control as much as I'd like. Personally, PHP gives me the right level of control - and developing applications using PHP is hardly slow anyway.

Someone please convince me that there is another reason to use ROR than development time - do people just like it because it means they can be lazy and get everything done for them? Or is there a more compelling reason to use it?

Then take a look at Catalyst framework - It put's the control into your hands while allowing you to use helper scripts and others people code. It also embraces best-practices for your code. How ever it's perl so one might have to learn a new syntax...

[Fenrir2]

I work on a lot of algorithms (yes on the web) and currently all the stable ways to run Ruby are pretty slow.

Yes, Ruby is slow, but not slower than PHP/Perl. And Ruby has good C integration

[t3projects]

Let me just put it this way... The Amazon.com guys love Ruby on Rails from what I hear. I have developed a few apps in it and I'm all new to it but I happen to really enjoy working with it.

For hosting I'm with hostingrails.com and I like working with those guys plus the hosting plans are pretty good for getting you started.

What it really comes down to is two things.
1) What does your client need (do they have an already existing app or on a MS hosting...?), and
2) What fits your coding style and are you looking for something a bit more streamlined

Answer those two questions and you're pretty good to go. But to gain a better perspective of the benefits of RoR you will not find it from a getting started tutorial because those don't even BEGIN to scratch the surface. Without a doubt go buy the Agile Web Development on Rails book. Once you get half way through the book you'll say to yourself "Why the HECK did I ever play with any other language?" especially when you get to the ActiveRecord part.

For me, I'm a very busy guy, I typically work about 60-100 hours a week and the thing I need is something that will help me streamline my process, give me a lot of flexibility, and is fun to code in. That's my reason for looking into Rails. Plus a lot of companies and Java developers are jumping ship to go to Rails.

Is it hyped up? Yes and I think it should be. It's new, it's fun, it's refreshing, so why not. Does it solve everyone's problems? No, but neither does ASP.NET, however MS would like to think it does. Last time I saw a video of a MS conference one of the head guys was chanting like a lunatic, it was great fun watching him look like a sweaty ape chanting God knows what.

Here's the other thing, everytime I go to a book store and visit the computer section some one is always looking for Ruby on Rails books, plus it was on Amazon's top ten best sellers for 2006. There's a lot of hype but there's also a lot of corporate movement. It just comes down to what type of shop you are and what type of developer you are. No one solution is the perfect solution, it just might be the best one for you.


- Tony

[Snaily]

Yes, Ruby is slow, but not slower than PHP/Perl

Every benchmark I've seen shows Perl/Python kicking the crap out of Ruby (PHP is a bit closer), take for example:

http://shootout.alioth.debian.org/debian/ruby.php

Do you have any evidence for your claim?

[Sgarissta]

Every benchmark I've seen shows Perl/Python kicking the crap out of Ruby (PHP is a bit closer), take for example:

http://shootout.alioth.debian.org/debian/ruby.php

Do you have any evidence for your claim?

Contrived benchmarks are just that, contrived benchmarks. Is Ruby too slow? Not for me. I use it in a large variety of applications that I would have written otherwise in PHP/Perl/Python. Will Ruby outperform Java/C#/C/C++? Nope, and it doesn't try to.

Since most people in this thread seem far more concerned about Rails the framework, than Ruby the language, I'll add this. The modern web application spends FAR more time waiting on a database, a webservice call, or data from the client, than it EVER spends processing. There are of course exceptions to this, but in general the "speed" of a web application language itself is of very little concern for most applications.

[brandaggio]

My gut reaction is RoR (and using an MVC approach) represents an inherently cleaner, more abstracted style of development that more experienced developers and programmers often favor over .NET. Using reusable "forms" (in the. NET sense) does offer some rapid development (as do drag and drop controls) but this type of environment and method, IMO, encourages a more "inline" style of coding that does not seem to require the same level of attention to structure and planning common to an RoR app.

An analogy:
When you want to expedite some DIY bookshelf project you might use glue instead of screws (with pre-drilled holes for future disassembly - which would involve more planning and tools but have other benefits). Glue might be more than adequate now, but may not offer the flexibility and modularity afforded by using screws.

At the end of the day, I feel strongly that the underlying code generated by most of the MS tools (have you seen how much like old Flash XAML code looks?) is bloated - can you hand code something sparkly and compliant with their new IDE's? Yes - but that stops the second you start doing anything substantive. The new Hotmail Live is an example of a new .NET app - it uses frames and renders HTML worse than any browser I have ever seen - eww would be an understatement.

[Fenrir2]

Every benchmark I've seen shows Perl/Python kicking the crap out of Ruby (PHP is a bit closer), take for example:

http://shootout.alioth.debian.org/debian/ruby.php

Do you have any evidence for your claim?

This for example: http://shootout.alioth.debian.org/de...ruby&lang2=php

Ruby isn't really that much slower than Perl. If a language is too slow for you then that isn't about 5x, but about 100x:

http://shootout.alioth.debian.org/de...perl&lang2=gcc

Code your algorithm in C, the other 95% (or more) in Ruby.

If you're doing algorithmic work then you should know that the algorithm is more important than the language you're using. A Ruby program using a good algorithm easily beats a crappy C algorithm.

[Snaily]

Ruby isn't really that much slower than Perl.

C'mon...on most algorithms its at least 5x faster!

Code your algorithm in C, the other 95% (or more) in Ruby.

Ruby and Perl are the same sort of language, the only reason why Perl is faster is because Perl has a better "interpreter".

A Ruby program using a good algorithm easily beats a crappy C algorithm.

Sure,but so what? If I write the algorithm say in Ruby or write the same algorithm in Java...the difference in speed could be about 20x. Which could mean the difference between waiting 5 minutes for a result to waiting 100 minutes (or more modestly say 30-50 minutes).

Contrived benchmarks are just that, contrived benchmarks. Is Ruby too slow? Not for me

The benchmarks aren't "contrived", they are rather decent. Did you find a particular problem with them?

but in general the "speed" of a web application language itself is of very little concern for most applications.

Really? Then why do people bother with using things op-code caching etc? Also, how far do you take this line, at some point speed will be an issue.
Anyhow, Ruby is slow...its runtime system needs to be fixed its that simple.

[awasson]

Hmmm... Where to start?

Well, I just picked up the aforementioned book and have some experience coding pretty much everything discussed thus far... The short story IMHO is this:

If you've been developing for a while in .NET, JAVA or OOP~anything or even straight spagetti code and you haven't given Rails a good look, you probably should.

I'm suprised to hear the excuses from people about not taking it for a spin. We all work for a living (I think) and yes it takes time to set up the development environment however... If you haven't given it an honest look then your opinion means less than nothing. At least if you learn about it, at the end of the day if you still have a problem with it, you'll know why you don't like it.

Off Topic:

When I first looked at it, I didn't like it much but then again, that was because I didn't do any reading up on it. I just kinda kicked the tires

Top 3 reasons why I like it now that I know a thing or two:
1) Object Oriented (MVC) development with best practices (pretty much) built into the framework. It's so intuitive that you have to do extra work to veer off course. As I mentioned, I'm just getting started with it. My experience has always been with technologies that require a lot more boiler plate code. Even the Ruby boiler plate code I've played with so far is concise and easy to understand/modify.

2) Built in Test Based Development. I've used some Unit Testing with a complicated recursive algorythm written in PHP as well as some minor .NET apps and it seems to me that it was well worth the effort. The only hastle was setting up the testing environment. With RoR, it's all stubbed out when you build the app. Writing the tests so far has been simple and at the moment I've been running them in a terminal window. You can just run the tests and get your response or you can trace the stack and weed through the results to find the problem it one exists.

3) DRY development. Vinnie already mentioned this; It's a Don't Repeat Yourself method of developing your application which makes developing, enhancing and maintaining a whole lot easier. It's a good habit to get into anyway.

* I suppose a 4th reason is if you want to test out an idea, you can make use of automated scripting and temporary scafolds to knock together a prototype application very quickly. The amount of time depends on the complexity of your idea however, it takes less than a minute to stub out any application and the rest is up to you to build the database and decide what it's going to do. If your idea is going to work, you keep the foundation, pull down the scafolds and build the app.

IMO (again) If you're really new to programming, RoR probably isn't going to be enlightening to you. You should get some experience in what I like to call the "physics of coding"; For each action (block of code) there is a reaction. Get your hands dirty with Javascript, PHP or ASP. You'll get the immediate action == response thing going and it'll be easier to grasp OOP and frameworks later.

I'm not sure at this point if RoR will live up to the hype it seems to have gathered but I am looking at new projects I have lined up wondering if they will be good RoR candidates.

Cheers,
Andrew

[Snaily]

I'm suprised to hear the excuses from people about not taking it for a spin.

Some people have more important things to do than spend days trying out new frameworks. Giving Ruby/Rails a spin for a few hours tells you next to nothing about its strengths/weaknesses. My attitude towards things like Ruby/Rails (like many people) is "wait and see what happens with it in 1-2 years".

[awasson]

Some people have more important things to do than spend days trying out new frameworks. Giving Ruby/Rails a spin for a few hours tells you next to nothing about its strengths/weaknesses. My attitude towards things like Ruby/Rails (like many people) is "wait and see what happens with it in 1-2 years".

Off Topic:

If you have time to post on forums throughout the day... You don't have better things to do than learn a new technology

Actually that's my point. It doesn't take days. It literally takes a couple of hours to get an idea of what's going on. Ok, you'll probably have to read a little as well but how did you get this far in the first place.

Yes if you're a drag-n-drop newbie who's never looked in an editor window it's not a simple process but the people posting contempt for taking it for a spin seem to have a good grasp of complex development. It surprises me.

My main point is that before posting an opinion, you should have some knowledge on the subject.

[Snaily]

It literally takes a couple of hours to get an idea of what's going on.

Getting an "idea of what's going on" isn't helpful. I have an "idea of what's going on" with Ruby/Rails what I want to know its strengths/weaknesses and weather it will be a good fit for the sort of work that I do. There is no way I can determine this within a few hours, therefore someone has to first convince me that Rails/Ruby's strengths/weaknesses are a good match for what I'm working on, until then I won't use it (and likewise for most programmers...).

My main point is that before posting an opinion, you should have some knowledge on the subject.

Oh yeah? Whats the point of this comment? Are you suggesting I lack knowledge of some topic that makes me exempt from posting about Ruby/Rails? In fact, I haven't said much about Ruby or Rails (except Ruby is slow, which isn't too hard to show) itself. I'm merely interested in the "benefits of ruby", which haven't in any real sense been clarified (Most of the comments are value theoretic, facts/arguments are more interesting) Feel free to make more substantial contributions to this cause than "take it for a spin".

[Fenrir2]

Ruby is more expressive than PHP, Perl and Java. Here are two simple and important things that Ruby has: clean OO & blocks. Some people say that Java has clean OO but I disagree. Java doesn't have blocks/lambda's/closures either. Perl has blocks/lambda's/closures but not clean OO. PHP has neither. PHP, Perl (5) and Java don't support continuations. Ruby does.

[Sgarissta]

The benchmarks aren't "contrived", they are rather decent. Did you find a particular problem with them?

The problem with them has been discuessed ad nauseum elsewhere, I suggest google. But for a brief answer, the environment in which the tests are run is not always consistent between tests.

Really? Then why do people bother with using things op-code caching etc?

Last I checked opcode caching only applied to languages that generated op-codes to work with. Secondly opcodes don't change the speed of the language, only cut down on compile time per request. If speed were such an incredible issue we wouldn't be using scripting languages at all, hence why I state that it's rarely much of an issue.

Also, how far do you take this line, at some point speed will be an issue.
Anyhow, Ruby is slow...its runtime system needs to be fixed its that simple.

Ruby is slower than other languages, absolutely, never claimed otherwise. But I wouldn't say that the runtime system is broken, or in need of fixing, it's in need of optimization. Ruby was not designed as a web scripting language unlike PHP, and in fact Rails makes up a small portion of the overall use of Ruby. Of course it has some performance and deployment issues in a Web based environment, it wasn't until a couple of years ago that it was even being heavily used in that capacity.

When I use ruby to parse that random CSV file, or do some LDAP lookups, or whatever I used it for today, I didn't care that it was some multiple of X times slower than perl, or php, or C#. What I did care about is that I wrote a script I needed, to accomplish a task in minutes. In this scenario speed of the language wasn't a concern. Is it too slow for you? I don't know, go find out.

And it's runtime system (interpreter) is being actively worked on, there are at least 3 major rewrites of it going on right now, I suggest you look at YARV, Rubinius, or JRuby if you're so inclined.

[Snaily]

Ruby is more expressive than PHP, Perl and Java.

In order for this to be at all meaningful you'd first have to define "more expressive" in a matter that is objective. I think its completely silly to suggest that because language X has more features than language Y its "more expressive" and this is all you seem to suggest. You seem to merely have a bias towards quasi-functional languages and find them "more expressive" (this bias isn't unique to this thread). I have no trouble translating what I do in a functional language like ml or ocaml to a OO language like java, they are merely different ways to do the same thing. I prefer to use functional languages in some contexts and OO in others, but this has nothing to do with one being "more expressive" than the other.

I didn't care that it was some multiple of X times slower than perl, or php, or C#.

Again, its great that Ruby works for you. But to toss out issues of speed as not important, is to ignore a major problem with Ruby. Also, I'm completely aware that people are working to fix matters, but there is currently nothing that is stable and fast. I don't like to waste my time waiting for a script to parse large text files, run an algorithm etc, many people feel the same way. My only point about speed in my previous posts where: Ruby is too slow for what I do. I never said its too slow for you, or the guy down the street.

[awasson]

This is fun and all but maybe we should get back to the question that started this thread.
Are you still waiting matsuko?

I am planning to purchase the new sitepoint Ruby on Rails book. I took a look at the article on the main page and read most of it, however I didn't see why ruby is so beneficial.

Aperantly it reduces code because it incorporates a variety of libraries used for database connectivity, AJAX, and so on.

I am not entirely sure on if this is correct (I have never used the framework before) so could someone please explain the primary benefits of the ROR.

Thanks

Primary benefits....

I guess for me it comes down to a very organized way in which to approach your projects. There is a specific approach each and every time to how your site is organized. The entire directory structure is generated automatically through the "rails" command and boiler plate code is placed in auto-generated files. You can load up a (blank) page within a few seconds or maybe a minute or two of issuing the command.

The testing features are good for more advanced projects but maybe not necessary for beginners. I'm interested in them because I've done a little with other projects and found it invaluable.

The database abstraction shines. It is really quite simple to use/understand and it hold the promise that migrating to more powerful databases will be a painless experience. From experience, I realize that's rarely the case but we'll see.

So far I've been able to generate valid xhtml-strict markup and that's also a pretty nice accomplishment for a very automated framework.

* I'm still not sure if this is the silver bullet for web application development and I'll always work with a variety of programming languages but... I am looking at it a bit differently now whenever I spec out new projects.

I'm sure that there are others following this thread who have a few "Primary" reasons why they would use RoR.

Good luck,
Andrew

[Sgarissta]

Again, its great that Ruby works for you. But to toss out issues of speed as not important, is to ignore a major problem with Ruby.

I've never claimed speed is totally unimportant, just that it isn't the sole deciding factor in choice of language, if it was we'd be writing webapps in assembly. I'm fully aware of the speed problem in Ruby, just as I'm aware of the problems of it's green threads implementation, and interpreter level globals. All of those are problems, but only in certain problem contexts, which is my entire point. You have to weigh all the variables and decide if it works for you.

Also, I'm completely aware that people are working to fix matters, but there is currently nothing that is stable and fast. I don't like to waste my time waiting for a script to parse large text files, run an algorithm etc, many people feel the same way. My only point about speed in my previous posts where: Ruby is too slow for what I do. I never said its too slow for you, or the guy down the street.

Have you used Ruby to "parse large text files" or "run an algorithm", or are you just relying on the opinions of "many people [who] feel the same way"? As I'm sure the guy working for NOAA processing several gigs worth of satellite data constantly probably disagrees that Ruby can't "parse large text files".

I'm done with this discussion, because it's fairly obvious you haven't done much more homework than read a couple of blogs and determine that Rails is too slow, so all of Ruby is useless to you. Fine, I just hope my comments will lead others to doing a bit more research than you have.

[Fenrir2]

In order for this to be at all meaningful you'd first have to define "more expressive" in a matter that is objective. I think its completely silly to suggest that because language X has more features than language Y its "more expressive" and this is all you seem to suggest. You seem to merely have a bias towards quasi-functional languages and find them "more expressive" (this bias isn't unique to this thread). I have no trouble translating what I do in a functional language like ml or ocaml to a OO language like java, they are merely different ways to do the same thing. I prefer to use functional languages in some contexts and OO in others, but this has nothing to do with one being "more expressive" than the other.

Yes I have a bias to towards (quasi)-functional languages. That's because they *are* very expressive. Higher order functions and closures make some things much easier. You can of course simulate closures with objects by assigning all captured variables to an object, but this is very messy.

The features I mentioned are important. Using blocks you can abstract many things much better. Clean OO helps too. Ruby is powerful because you can mix multiple paradigms. The map() function in Ruby is very powerful because Ruby has OO. OO + map means that map is generic:

def times_n(n, collection)
  collection.map{|x| x * n}
end

You can use this procedure for built-in collections and for your own collections. This example uses closures. You can simulate them:

class TimesN
  def initialize(n)
    @n = n
  end

  def call(x)
    return x * @n
  end
end

def times_n(n, collection)
   collection.map(TimesN.new(n))
end

This is why people write this if they don't have a map:

def times_n(n, collection)
  result = collection.class.new
  # note that this is much harder in Java, but we have to 
  # because this should be a generic procedure.
  # also note that this procedure is less generic than the previous procedures
  # because this one doesn't work for trees, for example.
  
  for x in collection
    result << x * n
  end

  return result
end

I think we can agree that closures make a language more expressive. This first program expresses the intent of the programmer more directly.

You *cannot* easily translate Ruby to Java if a program uses continuations. Local changes to the Ruby program that uses continuations require global changes in the same Java program. I agree though that continuations aren't that useful ;-).

[awasson]

Who's using RoR in production?

The reason I ask is that the side discussion regarding the speed of the script although a little off the main topic is interesting and something that I've been looking at since I started compairing ASP.NET(C#) to ASP(VBScript) to PHP.

A side benefit of using RoR is that it keeps a log of activities whenever something happens. A page request, an entry into the database, a refresh, etc... It gets written to a log file and the actual speed with which an event takes is written to the file is recorded. The numbers represented are factual and this removes prejudice, speculation or opinion from the equation.

As I am still "taking it for a spin", I don't have a production application to check out the speed on but maybe Vinnie or someone else can provide us some factual information about what goes on in production. Here's a sample of some test activities to give you an idea of what you might see:

Rendering  within layouts/application
Rendering story/new
Completed in 0.00010 (10000 reqs/sec) 
| Rendering: 0.00000 (0%) 
| DB: 0.01000 (9999%) 
| 200 OK [http://test.host/story/new]

This is just a log entry of automated test of the form that submits simple form information into the database. Not much to see but it does show where the activities are spent; In this case it's all in the mySQL database which on my old XP P4 laptop is a little underpowered.

Processing StoryController#index (for 0.0.0.0 at 2007-02-28 23:03:17) [GET]
Session ID: 
Parameters: {"action"=>"index", "controller"=>"story"}  
Story Load (0.000000)   SELECT * FROM stories ORDER BY RAND() LIMIT 1
Rendering  within layouts/application
Rendering story/index
Completed in 0.00010 (10000 reqs/sec) 
| Rendering: 0.00000 (0%) 
| DB: 0.01000 (9999%) 
| 200 OK [http://test.host/story]

The above represents an automated test of displaying a randomly chosen piece of information. Again, this is too simple an application to get an idea of whatgoes on in the real world so I hope someone who has production experience can provide some factual insight about the efficiencies or inneficiencies of a Rails app.

Cheers,
Andrew

[Sgarissta]

Who's using RoR in production?
[lots of interesting stuff snipped]
The above represents an automated test of displaying a randomly chosen piece of information. Again, this is too simple an application to get an idea of whatgoes on in the real world so I hope someone who has production experience can provide some factual insight about the efficiencies or inneficiencies of a Rails app.

While all of that is very interesting, and goes back to my point about the DB taking longer to process than any portion of the script, Rails IS slower than the competition and here's how/why. Try loading a Rails app, that doesn't even hit the DB, just renders some simple text, a hello world app of sorts. Run ApacheBench or httpperf against it, for say 1000 requests. You will most likely get single digits in requests/sec. This is partially due to the overhead of Rails itself, it does a LOT for you, and that all comes at a price. But the bigger problem is that there STILL isn't a solidly performing deployment scenario for Rails.

The current "winner" is a mongrel (a really cool C/Ruby web server) cluster, behind a load balanced proxy of some sort. While this is well and good, it doesn't scale extremely well. The Ruby interpreter, with the entire Rails stack loaded takes up a good chunk of memory (around or over 20mb if I remember correctly), that's PER instance, a typical mongrel setup is 1 or 2 mongrel instances PER processor, so you can easly have 80-100mb of RAM taken up, for JUST mongrel processes, not even the overhead of the loadbalancer processes to hand them off to mongrel.

Ruby/Rails is a lot closer in deployment currently to .NET/Java than it is to PHP. While Rails apps aren't compiled like .NET/Java, they both require some fairly heavy lifting by some form of application server. Rails problem thus far is that because of the way the Ruby interpreter currently works it's "hard" to have a true application server. But after YARV/Rubinius/JRuby get stable, you'll begin to see some really interesting work being done on the current mess of Rails deployment such as a useful mod_ruby that caches bytecode instead of having to relaunch the interpreter with every request, much like mod_python.

Probably more than you wanted/needed to know to answer your question!

[Snaily]

just that it isn't the sole deciding factor in choice of language,

1.) Its great that you are pointing out the obvious. 2.) Nobody said that its the "sole deciding factor" 3.) I was rather explicit that speed is important to me personally because of what I'm doing, I never claimed once that Ruby is too slow for anybody else.

Have you used Ruby to "parse large text files" or "run an algorithm", or are you just relying on the opinions of "many people [who] feel the same way"? As I'm sure the guy working for NOAA processing several gigs worth of satellite data constantly probably disagrees that Ruby can't "parse large text files".

1. I never said Ruby can't parse large text files, rather its not nearly as efficient as some other languages (e.g., perl). And yes I've experimented with Ruby to this end.
2. If the guy at NOAA is using ruby to process several gigs worth of data he is an utter idiot...and likes to waste time/money (but its the US gov...so it wouldn't suprise me if they were using their pen/paper).

Fine, I just hope my comments will lead others to doing a bit more research than you have.

I have said little about what I've done with Ruby etc, but yeah instead of refuting me claim I'm ignorant about Ruby. My claims about Ruby's speed were: 1.) Its too slow for me, 2.) Its current stable runtime system is slower than other solutions, in some cases dramatically.

Yes I have a bias to towards (quasi)-functional languages. That's because they *are* very expressive.

Yes and cholocate ice cream *is* the best! You claim a fact where there isn't one, and just as you can have a favourite colour you can have a favourite
programming paradigm.

I think we can agree that closures make a language more expressive.

No, I don't agree and I was already explicit about this. Different paradigms fit different situations, no paradigm is universally "more expressive" than another.
Your kiddy examples (you do love these sorts of examples) don't show anything interesting. I personally don't feel either paradigm is better for web development, well actually I do prefer OO or procedural languages for web work. Now, if you are writing algorithms on inductively defined structures than a language like ML is awesome.