In the early days of web apps, you could mostly get by with Perl, SQL, HTML and a little bit of Javascript for mouseovers and whatnot. Framework? CGI.pm, baby.

Now you generally need HTML, CSS, Javascript, a Javascript framework, a backend language of choice, a framework of choice in that language, a high-performance backend language of choice for the critical bits, and SQL.

I did web apps from 1997 to 2001 and then picked back up in early 2008. It was pretty dizzying at first just knowing where to start. In the systems / multimedia world where I lived in the 7 years between it was C or C++ and a framework.

So what's the connection to the story? I think it's in the web world, perhaps as a result of its relative infancy, we apparently have to get used to the fact that the right solution to a problem is often using mixed-mode programming where individual tools are selected for individual tasks -- that development abilities in the web world is as much a question of breadth as depth. We shouldn't be so disenfranchised that our tools aren't general purpose.

You don't need frameworks. You can still use CGI.pm if you want to. But doing so will make your web app look and behave like a 1998 dinosaur, and using a framework is just so much easier, more comfortable and less error-prone.

While frameworks add complexity as far as the computer is concerned, they remove complexity as far as the human developer is concerned. I can write a web app in Ruby on Rails much faster than I could ever have with mod_perl, and the result is better-looking and easier to maintain.

"Ruby is probably the most powerful programming language on the planet for creating DSLs, or domain specific languages."

If Ruby has anything over Lisp in the DSL domain (besides popularity), I'd love to know.

"A web development platform as powerful and syntactically concise as Rails could only have been done in Ruby."

Idem.

"This power does not come without a price. Ruby is slow. Ruby is generally recognized as being twice as slow as Python, and at least an order of magnitude slower than C++ or Java. Charles Nutter, one of the creators of the JRuby VM for the Ruby language, recently posted an article about optimizations that could be made to the VM, and he improves Ruby performance by as much as twenty times by removing much of Ruby’s power and breaking compatibility. If anything, it shows us skeptics that there is no such thing as a free lunch."

Lisp has all (?) the crazy features you love so much about Ruby and more, yet it's very fast (try SBCL, it compiles to native x86).

Many programmers like syntax, since coding AST-style can be tedious sometimes. Sure, you can create your own reader macro with Lisp, but that is harder than overriding some methods in Ruby. Rails is an example that opinionated software has an edge sometimes and Ruby compared to Lisp is opinionated in terms of syntax.

There are indeed some people who say "uh, nice syntax, readability, uh, big deal". Those are the folks who fail to grasp the point that programming is a human endeavor and that having your code read by other humans is a crucial element.

Lisp may indeed attract a large group of nice, intelligent people who don't get this. That is a further, fatal problem in the language.

Ruby has many problems itself but it gets that readability is important and it gets that, by extension, the humans relations that a programming language generates are important. Lispers don't seem to see the problem in an exclusive attitude and essentially closed community. The ruby community understands the need to have a good community open to people even if the Ruby community doesn't always succeed at this. It all comes together

I also don't see how "coding AST-style" can be tedious, especially since it's so much easier to automate the process with macros. Granted, you'll want an editor with support for s-expressions.

I agree that Lisp is a better choice for DSLs than Ruby. If you want a very dynamic (late bound) language that is also fantastic for DSLs, have a look at Io (http://iolanguage.com/).

?! Please substantiate. And of course when I say "Lisp" I really mean "Common Lisp".

I'm guessing; I have no numbers on how it compares to actual Java.

http://tinyurl.com/daom93 - shootout numbers rhino v. java

I was under the impression that Rhino was doing some compiling to byte-code (unlike what MRI does, but what perhaps like JRuby does).

Live and learn.

The semantics of javascript are so different to Java (javascript functions are not like java functions everything is dynamic etc.) that you can't really expect the performance of javascript code to be comparable to Java just because it's hosted on the JVM, even if it did compile to Java byte code.

The Javascript equivalent would have to do so much more work than the Java version to support all the crazy crap you can do in javascript (ad hoc adding of properties to almost any object at any time).

For whatever it's worth, I think the problem Javascript is going to have with speed is that it is so dynamic that it makes it difficult for compilers to optimize. If it ever got type hints it would probably be much easier to make fast.

http://news.ycombinator.com/item?id=545859 http://news.ycombinator.com/item?id=545851

Wow; who knew?

The last two statements don't mean the first is true. Ruby's power is not the reason it's slow. Smalltalk VMs are proof by existence that the Ruby model can be fast. (See: Self, Strongtalk, Gemstone.) MagLev showed that Ruby is basically just an alternative Smalltalk syntax.

Charles Nutter, one of the creators of the JRuby VM for the Ruby language, recently posted an article about optimizations that could be made to the VM, and he improves Ruby performance by as much as twenty times by removing much of Ruby’s power and breaking compatibility.

"Remove much of Ruby's power"? Around 0.2% of Charles's speed-up came from removing the ability to override the primitive math operations. Other than that, his speedups removed none of Ruby's power.

(And nit-picking: Ruby is probably the most powerful programming language on the planet for creating DSLs, or domain specific languages. It can do this because any class or object can be extended, any method overridden, any constant undefined and redefined, and so on, and so forth.

Not true:

  >> class StrangeArray < Array; def [](x); x; end; end
  nil
  a = StrangeArray.new(10)
  => [nil, nil, nil, nil, nil, nil, nil, nil, nil, nil]
  >> a.map{|x| x}
  => [nil, nil, nil, nil, nil, nil, nil, nil, nil, nil] # wrong
  >> (0..(a.size - 1)).map{|x| a[x]}
  => [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] # right

(Edited to correct example, as pointed out by hjdivad)

    This power does not come without a price. Ruby is slow.

The one of the biggest misconceptions we have to face in the Computer programming and related professions, is that programmers are on the forefront of technology. Actually, culture lags technology. And in that, I specifically include the culture of computer programmers.

The foundations of OO languages like Ruby and Python were set forth in the 70s and 80s. WYSYWIG word processing, ethernet LANs, desktop publishing existed then in pretty much their current forms at Xerox PARC, only slower. The concepts embodied in Dot-NET and Microsoft's Singularity were bandied about in the 60s, 70s, and 80s.

The sad thing about our profession is, is that to learn what's coming next, and what's possible you still have to do some digging into history. Things have improved, but because programming is also a cultural artifact, it lags technology like any other cultural artifact.

I keep posting this. I used to wonder why it seemed like tilting at windmills. After writing this post, I now realize why.

Alan Kay: "The Computer Revolution Hasn't Happened Yet."

http://video.google.com/videoplay?docid=-2950949730059754521

(1) - In fact, it is homomorphically equivalent. This is precisely why something like Maglev can work. Another interesting thing -- many Lisps are also homomorphically equivalent to at least 90% of the languages out there. And one could probably take just about any Lisp and give it the power of the other 10% (like Erlang) with moderate effort.

And I'll believe Maglev's outlandish performance claims if and when I ever see them realised. If they are anything like those claimed at RailsConf 2008 (50x or thereabouts), I'll eat my hat and any other hats anyone cares to send me.

I say this as someone who would probably seriously consider murder if it would make my Rails apps run 10x faster. I want it to be true. I just don't think it is, unfortunately.

And one could probably take just about any Lisp and give it the power of the other 10% (like Erlang) with moderate effort.

I keep hearing things like this, but no-one ever does it.

And actually, I know that some Smalltalk routines have run faster than the same routine implemented in C. By 3% actually. This was over 5 years ago, and it was a block cipher -- yes, low-level bit slinging. The DLL was the RSA reference implementation. (1)

Also, you should be careful about reasoning about benchmarks as if they applied the same across the board. Anyone who knows a little about them knows that they are very contextual.

BTW, in the Smalltalk community, spelling the language name with a capital T is considered a mark of the PHB.

But if you want a Smalltalk library that's much faster than Ruby 1.8, there are a variety of benchmarks around. Just take some of that code, and declare it to be a library. QED.

(1) - This is the magic of generational GC. if you know what you're doing, this is like getting a Buffer Cache you didn't even have to implement. Also, the implementor got the help of the VM engineer, who provided primitives for handling 32 and 64 bit arrays.

I'll try to restate. You said this:

"There are Lisp and Smalltalk VMs out there that are something like 70X as fast as Ruby 1.8!"

That is what I was trying to argue with. I have never seen any proof, beyond a few cherry-picked examples of Ruby at its worst and Smalltalk at its (presumable) best, where anything like a 70x speed difference is observable. On average, ST (is that ok?) seems to be a mere 5x as fast (or so), coming in at somewhere between 5 and 10 times slower than C.

Ruby 1.8 is in the average case around 30x slower than C. So if Smalltalk can be 70x faster than that, then it is generally twice as fast as C, on average, in everyday use. This is not the case, as far as I am aware. I see this "Smalltalk is SO fast" meme again and again but it just doesn't seem to be grounded in reality.

Sorry for my idiotic error earlier, and for sounding like a PHB ..

The real gain for Ruby, once there are reliable VMs that have good JIT capabilities is the following:

A dynamic web page can then be compiled into a JIT-ed method, with static HTML as data in arrays interspersed function/procedure calls. At this point, you can increase the JIT memory cache so that it can contain your entire web site, and at that point your web pages are machine language routines!

VisualWorks has a framework that does this. It's called Smalltalk Server Pages.

ST is kosher.

If it was, it would be faster - much faster - than C, and if that was the case, games, graphics drivers, hell, operating systems - would be using Smalltalk. They are not. QED.

Smalltalk is great and its VMs are highly advanced. I accept that. I still use Ruby and eat the performance cost because I prefer its syntax and "world". But man, let's keep the performance comparisons grounded in reality. 70x faster is ludicrous.

My point is that VMs that have been around for decades capable of supporting languages of equivalent power, and that these are some silly multiplier faster than Ruby 1.8. This is going to be something like halfway to two orders of magnitude for some silly benchmarks, and much less in real life. Really, there's not much of a problem in practice, especially with the embarrassing wealth we have lying around in terms of processing power.

The real problem -- the thing I am making a point about -- is people going around saying that, "Oh well, you have to give something up to get the power..."

No. You. Do. Not!

Ruby is not that advanced. Yes, I would say that it's a lovely language. It has everything I want, but it's not doing anything that hasn't been done before. It's unique in that it combines lots of elements in a way that's really dandy, but there's nothing magic about it. There's certainly nothing so esoteric, that it couldn't be made to run fast. (There are a few things that were just bad design decisions, like making every Object behave like a little hashtable, which could've been left out and made it much easier to run faster without losing power and expressiveness.)

Oh, and people did implement OSes in Smalltalk and Lisp way back when. Also, ever hear about something called Singularity? That's a recent OS built on top of a VM. In fact, I think that more people should be doing just that -- building OSes that are "turtles all the way down" and built to not only support a particular VM, but to have every single atom of it available to tweaking by a high-level language. (Lua would be great for this.) But this is a digression.

Again, going back to my original point -- the real ludicrous thing is that the programmer community as a whole is still in the thrall of expectations about speed vs. programming language power that date from the 70s. And anyone who thinks you have to give up as much speed as Ruby has to get that power is very much in the thrall of such an idea.

I wasn't claiming you can't tack feature X onto lisp, of course you can, you can implement anything in anything. The point I wanted to make was that "power" is not just some object feature bullet points, it's about ease of use and syntax and libraries as well.

"If you add Traits (library for Mixins) to Smalltalk, it is equivalent to Ruby in power. (1)"

Only for your definition of "power".

Yes, everyone loves Ruby's super-flexible objects and mixins etc but that is only the start of the story. Its syntax is terse, intuitive and good-looking. The rubygems packaging system is effective and ubiquitous. Irb is excellent and "live coding" techniques are invaluable. To me, these are very much part of the real "power" and the main reason I prefer it over, say, Python. You might be able to emulate the object behaviour but it's still "incomprehensible mess of brackets" Lisp.

You might be able to claim that Lisp is 90% "homomorphically equivalent", a phrase I don't think I've heard since Mathematics 2, but who gives a shit? Go ahead and add the last 10% of whatever it is that Ruby has and Lisp doesn't. Now you have just as much power as Ruby? So go ahead and type "require activerecord" (don't forget to compile!) and just try to tap into that power. Oops.

"Language power" is not just some reductive theoretical idea of what features a language has, or could implement. It's the whole package, and how you use it. Sure you can add Ruby's features to C. But a better way is to implement Ruby in it.

Lisp might well be the infinitely flexible meta-language which can be used to describe all others, but that isn't actually useful in itself, as used today. Lisp may be an incredibly powerful tool for something, but it has little advantage for conventional end-user code, not any more anyway. It's pretty exciting to think where it might end up, though.

"And one could probably take just about any Lisp and give it the power of the other 10% (like Erlang) with moderate effort."

Again, only for your definition of "power", which is not what the average programmer who is just interested in getting stuff done is thinking about.

Well, for those who actually have a little intellectual curiosity, the implications are:

    1) Not only can you do anything in langauges X and Y
       that you do in Ruby, you can express it about as 
       concisely
    2) Any libraries in Ruby could be just as beautifully 
       expressed in languages X and Y
    3) There's no reason something that closely resembles
       Ruby but runs *a lot faster* shouldn't exist
    4) Speed is just one factor among many.  There are lots
       of other things Ruby could learn from.  

(For the others, Ruby is awesome, it is the ultimate, there shall be nothing better, yada yada. Now you can rest easy.)

There has been a bajillion hours of awesome work that's gone into Ruby and Rails. There are ways that Ruby and Rails can be changed such that the next bajillion can be several times more awesome. All I'm saying is -- look around and be curious. There's a lot out there to learn!

Consider:

  $ ruby -e "class Array; def pop; self.first; end; end; puts [1,2,3].pop"
  1

http://blog.headius.com/2009/04/how-jruby-makes-ruby-fast.ht...

is really outstanding. It shows you exactly why a language like Ruby is inherently slower than a language like Java. Mainly, because Ruby does a lot more work to give you the cool, dynamic capabilities that make people like Ruby in the first place. Of course, much of the cool work on speeding up dynamic languages like Javascript and Ruby is all about analyzing code to find places where you can safely make assumptions about the code (+ is not overridden here, so I can use the built in integer addition operator, etc.).

(I probably oversimplified that, but I hope it captures the general idea.)

The "Duby" language at the end makes me think of Common Lisp and how you can optionally declare types the compiler can use to compile faster code. Would it be worthwhile to add optional typing to Ruby?

Am I the only one who has never heard of this? I'd definitely be curious to see some relevant benchmarks if anyone has any.

  - C++    | baseline
  - Java   | 2.5x baseline
  - Perl   | 4.5x baseline
  - Python | 6x baseline
  - Ruby   | 14x baseline

Multiple ways to create literal strings so you can save escaping things inside of them or save some other action.

Closures with one block shortcut per method so you can save a little more characters there.

These things encourage the developer to revisit their implementations and cut the redundancies much more.

The p method coupled with the inspect feature that gives you the description of a certain object so you can debug it or at least see its content very easily.

No use comparing Ruby to LISP and Smalltalk in some "power subjectivity"... Ruby is hackish and used by "hackers" alike. It's not perfect of course...

And I liked this article for it put into better words what I wrote in some comments on the original article.

For example, yesterday I caused an infinite loop in my Rails controller because I forgot the "@" in front of a variable that had the same name as the action - so Ruby interpreted it as a method call, not a variable reference. Being able to call methods without "()" is part of the Ruby-DSL stuff, but I wonder if typing "()" would not actually be the lesser pain in the end. I probably lose much more time to hunting such bugs than I lose time typing ().

To your main point, all general purpose languages are good enough at everything. That's how they get to be called "general purpose". But, I would argue that there are 0 languages that are great for everything. There is no language that can be shown to have 0 tradoffs when compared to all other languages.

The thing that often gets over-looked with Ruby is the trade off that many other languages make of developer time and enthusiasm (happiness, comfort, engagement, morale, etc). If you don't believe those factors exist or that they have little value then the trade off the language makes to afford those features is lost in translation.

To make a crude analogy: if I were hiring to get a company off the ground I would love to find a single person to do all of the product concepts, design, implementation, sales, accounting, legal work and support. The problem is that the jack of all trades is master of none and you're likely to get some creative concepting all over your accounting. Languages specialize in thousands of ways over the growth of the language (and hopefully consciously) - much like people do with education and career development. Even at times under the guise of general purposeness.

This is all to say that unfortunately your wanting a language that is great for everything is impossible. But, you might find a language that is good enough at all of the trade-offs you care about without ever trading off all the other things you care about and for all projects for all time.

Of course there are always tradeoffs, but some tradeoffs might not matter (that is, there might be no situations in which the tradeoffs would matter.)

I am not yet convinced that Ruby is so much more pleasant than other languages. I don't know Scala yet, but what if Scala is actually pleasant to use? Then Scala might be better than Ruby in every respect. (Not saying it is, I don't know Scala).

When people talk about power, elegance and abstraction of a language (not compiler, VM, libraries, etc) they are talking about the language platformed on the human brain (something unique to the individual). Ruby targets a certain brain platform while C targets a different one and Scala yet another. Twitter engineers sound like they have brains appropriate for both Ruby and Scala. Scala makes less technical trade-offs toward their end and so there arises a clear winner (for them).

The day we're all using the same brain platform then there could be argued to exist a best language.

I would say though that Ruby is a bit more complex of a language that people advertise. A novice will be bitten by these things, but someone who's worked with it full time for a couple weeks will not.

A language that excels at everything is an incoherent concept. There certainly are languages that are adequate at most things however.

It sounds like ruby did exactly what it should have done. There was a typo and you ended up calling a method. Even if ruby required parens for methods, you could have a typo missing the parens which would make it a local variable reference.

I would guess that a more common confusion with naked ruby methods is that they can be indistinguishable from local variables, and this isn't helped when people completely omit parens when passing params. This is why, despite some critisim of the practice, I pretty consistently use self and, when passing params, use parens.

If I mean instance variable, it is very unlikely that I would forget the @ in a language that always has an @ for instance variables. :-\

Maybe I'm missing something, but I don't see a fundamental distinction between the two purely on the basis of consistency. I think an argument could be made that the parens on a method are a more meaningful and representative syntax element than an @ on an instance variable, making it easier to remember. Then again, someone could argue that braces are a more meaningful syntax element than indentation, and we all know how that goes. :-)

And how about a pony while you are at it?;-) No language does everything, what you want to aim for is one that does as broad a range of things as possible:

http://journal.dedasys.com/2009/03/26/scalable-programming-l...

I think Ruby is 'pretty good' in those terms. Better than Java, IMO, because it lets me do small/quick things easily, something I've always found unpleasant in Java.

It actually slowed down the queue by about a factor of 10.

Maybe the jvm offers GC benefits on massive hardware, but I have not been pleased at all so far.

Benchmarks on the JVM are notoriously tricky...

I haven't given up on it... just posted the above comment b/c I had assumed that Kestrel would just be way faster b/c it's java, which turned out to be quite an erroneous assumption.