Why was Rails only possible with Ruby?

by Curt Hibbs

I am often asked if I think that clones of Ruby on Rails will become available in insert-your-language-here, and my answer is always "yes and no".

One of the biggest contributions that Rails has made to the industry as a whole was that it challenged the conventional wisdom about the way things should be done. In doing so, it showed that there was a better way by actual demonstration. Many of ideas behind Rails are, in fact, being cloned in other languages and their web frameworks. But it is my firm belief that, while these clone/borrowers can approach the productivity of Rails in their language, they will not be able to match Rails completely. The reason for this is found in one simple word: Ruby.

The Ruby programming language has a unique confluence of features that made Rails possible. Those of us who have been programming in Ruby for a long time intuitively understand what those language features are, and how they synergistically combine to form the programming language that makes Rails possible. We can even tick this feature list off in our sleep. But it is rare that we are able to articulate the gestalt of these features in a way the nubies can truly understand and appreciate. I know that I haven't been able to do it!

Fortunately, the pressure is off because Jacob Harris knows how to do it, and he wrote a short PDF book that does precisely this: Rubyisms in Rails (available from Addison-Wesley for $9.99). This book just made my A-list of books I recommend to people who want to know what makes Ruby so special.

From the book's web page:

Rubyisms is an examination of how the style of Ruby informs the design of Rails. In particular, it looks at a few specific examples of how Rails' internal code is implemented in Ruby to instruct about Ruby's design principles. The main goal is simply aesthetic appreciation. But, if you are a beginning programmer in Rails who is stymied in your understanding of Ruby-or an intermediate Rails developer still writing code that looks like Ruby-tinged PHP or Java-this Short Cut will hopefully impart enlightenment and inspiration about the Ruby way of programming. It also reveals how the revolutionary design of the Rails framework can only be built upon the beauty of Ruby.


The book is also available on O'Reilly's Safari Online service: http://safari.oreilly.com/0321474074/pref01

Very highly recommended!

60 Comments

Daniel Berger
2007-03-29 11:01:47
I'm pretty sure DHH said that he originally tried to develop Rails (or what eventually became Rails) using PHP and failed. That being said, I think there are some Perl and/or Python folks who might take issue.
chromatic
2007-03-29 12:56:00
I indeed take issue; it's a very silly conjecture that Rails was only possible in Ruby.


Without throwing around Turing-this or Turing-that, Ruby offers one semantic advantage over Perl: intrinsic OO even on primitives. All of the other metaprogramming possibilities of Ruby are available in Perl. The opposite is not true; I've found nothing in Ruby that offers the flexibility of import() hooks or code-in-@INC. (Kernel#autoload doesn't even come close.)


That's before you throw in gems or the CPAN for comparison.


Syntactically speaking, Ruby definitely has an advantage over Perl for metaprogramming. I'm not sure how far you want to take that argument, however. Beyond a few warts almost universally acknowledged, syntax is largely a matter of personal preference, not capability.


I haven't used metaprogramming in Python enough to argue either way, but I suspect that the argument that Python couldn't build something like Rails is equally ignorant.

Piers Cawley
2007-03-29 14:19:11
It's certainly easier to start metaprogramming in Ruby than it is in Perl. Perl's levers tend to be somewhat hidden and they don't necessarily move obvious stuff. Perl's not even close to being turtles all the way down in the same way as Smalltalk or Lisp, but Ruby runs out of turtles surprisingly quickly.
Curt Hibbs
2007-03-29 14:21:07
Of course you can build something like Rails in Python (or Perl). I was only contending, however, that you could get "close" with Python or Perl, but no quite go all the way.


Perhaps I titled this post too strongly, because my purpose here was not to inflame another language debate, but rather to say that there is a gestalt to Ruby that I find hard to articulate and that I think Jacob has come the closest to articulating that.

chromatic
2007-03-29 14:27:06
I agree with Piers. I find Ruby definitely more accessible than either Lisp or Smalltalk (for very different reasons), but they're both more consistent in their fundamental building blocks and abstractions than Ruby.


Even still, the gestalt of Ruby is often very pleasant. I have my gripes (implicit variable declaration!), but it's decent.


I'd really like to hear what parts of Rails that Perl and Python can't produce, though.

Curt Hibbs
2007-03-29 14:31:59
I don't think there is any functional part of Rails that could not be done in Python or Perl (or even Java). I think the difference lies in the aesthetics, and not just meaningless aesthetics, but important differences in conciseness and readability that have a definitely impact on both productivity and ease of use.
Ryan Leavengood
2007-03-29 14:33:30
chromatic said:
I'd really like to hear what parts of Rails that Perl and Python can't produce, though.

The problem we have is no Ruby enthusiast who isn't already a Perl or Python programmer will want to take the time to figure this out. The Perl and Python programmers will have the same excuse going in the other direction.


I say who cares, use what you like. But for me Rails and Ruby definitely have a certain QWAN which makes me enjoy using them.

Piers Cawley
2007-03-29 14:48:41
Curt: Have you looked at Jifty (Perl), or Django (Python) recently? Both of 'em excellent, expressive frameworks. Both of them with features that Rails lacks.


Neither of them have Rails' marketing though.


I still like Rails because I like Ruby (though the implicit variable declarations coupled with the strangeness that happens if you shadow a name in a block parameter is annoying) and am fed up of unrolling @_ in every method when I code in Perl.


But, for instance, I can implement the 'extract method' in pure Perl, and the only way I can see to do the same thing in Ruby would involve C level hacks to add extra reflective capabilities to Binding.

Piers Cawley
2007-03-29 14:50:50
Further to that, if Ruby's Binding object did have more reflective capabilities it would be *way* easier to implement the refactoring in Ruby than it is in perl...
Curt Hibbs
2007-03-29 15:02:29
Yes, Django is very nicely done. I don't know about Jifty, but I'll have to take a look (so, I will defer to your judgement).
Daniel Berger
2007-03-29 15:03:56

I'd really like to hear what parts of Rails that Perl and Python can't produce, though.

Template language. I don't know of any Perl or Python frameworks that use their own language for views, which I find rather telling. I imagine it's utterly impractical with Python as a result of the whitepace issue. Both Catalyst and Django, for example, use third party templating solutions. With Rails, on the other hand, I can just use plain Ruby. Hooray for erb in the standard library.


How significant this was for DHH I can only speculate, but there is no doubt in my mind that it has contributed to the success of Rails on the whole. It was certainly a selling point for me. :)


All of the other metaprogramming possibilities of Ruby are available in Perl.

But I don't think that's the point Curt was trying to make. Possible? Yes. Easy? No, especially not for someone coming to the language from scratch as DHH came to Ruby, which is why Rails would not have been possible with Perl. Not for DHH, anyway.


chromatic
2007-03-29 15:19:42
@Daniel, to my knowledge, there was no MySQL or SQLite library in the current standard distribution of Ruby when Rails started, so I point to Embperl and say that the erb point is moot.


I really have no idea on how to respond to the assertion that DHH could not have used string eval in Perl, for example, to do everything that string eval in Ruby does. That's a bit like arguing that it would be impossible for a Mandarin or Catalan speaking hacker to have written Rails because DHH speaks only, I assume, Danish and English.

DHH
2007-03-29 17:02:41
Saying that Rails could have been done in another language than Ruby is missing half the point of both. Rails is more than the result of its use. It's a flavor, it's a feel, a grib, a texture.


Focusing just on cloning the results are akind to saying that Ford could also build a Ferrari. No they couldn't. They could build another _car_ that has four wheels and perhaps goes as fast, but it's not going to be a Ferrari because of that.


But that's totally fine! Trying to out-Rails Rails is probably a loosing proposition from the beginning. And a needless one at that. Choosing to be inspired by some of the techniques used and fitting them within the flavor of another environment is of course totally possible.


That lots of people seem to dismiss flavor and feel in programming is part of why Rails was succesful to begin with. We choose to place both incredibly high on our list of priorities. Other environments have picked other attributes to focus. That's great. We have room for lots of different approaches in this world.

chromatic
2007-03-29 17:31:49
@DHH, it's fine to talk about taste. That's subjective.


Claiming that nothing else can possibly match up to the productivity of Rails isn't subjective. It's well within the realm of technical discussion--and it shouldn't be a surprise that people who know both how Rails works and how to do metaprogramming in another language will argue that point.

Curt Hibbs
2007-03-29 17:51:47
This is my own personal belief, but I don't think that the kind of "taste" that DHH and I are talking about is completely independent from productivity. I believe that there is a connection and that is why I say that clones can come close but not completely match Rails.


Now eventually someone is going to come up with some radically new idea that will blow Rails away... its inevitable.

Piers Cawley
2007-03-30 00:08:08
It's already happened. It's called Seaside. And Avi's just started his bid to take over the world by teaching people how to implement it in Ruby, JavaScript, Python, Perl...


Me? I'm looking forward to a hybrid of Seaside style tasked oriented architectures backed by 'pure four' RESTful ones along the lines of the RADAR architecture PragDave just proposed.

zerohalo
2007-03-30 00:15:28
In addition to Django, Python also has TurboGears which looks pretty nice and it seems more similar in approach to Rails than Django (though I haven't tried it out myself).
Sam Aaron
2007-03-30 04:57:18
Can I step aside from the 'my language/framework is better than yours' debate for just a brief moment, and add my recommendation for Rubyisms in Rails. I read it a while ago, and it was a superb read. Jacob has a wonderful way with metaphors, and is remarkably capable of injecting life into the concepts he's discussing.


In fact, I'm looking forward to reading it again from the perspective of someone that understands more Ruby and Rails than he did when he first read it.

John
2007-03-30 08:47:57
Two factors no one has mentioned here: Rails and Ruby have been joined at the hip from the beginning, and the quality of documentation for Ruby. As far as I can tell, the tutorials and documentation and user support for Rails are better than for the other frameworks. It's not just the code, it's also the user community.
Jacob Harris
2007-03-30 10:43:51
I guess I'll wade in and take some of the heat for Curt (thanks for the plug though), since I'm the one who originally threw some gasoline on the flames. The blurb though is somewhat misleading (I may have written it, or someone from A-W, I don't remember). Here's the corresponding passage from the Ebook though:


This is a surprisingly underappreciated concept. Of course, many people have already written about what they find beautiful in Rails--aspects of style we will explore further--but what the newcomer to Rails might miss is that Rails's design directly reflects Ruby's underlying beauty. Although the name Ruby on Rails suggests that the Rails model could be developed on top of other languages (Perl on Rails? Visual Basic on Rails? Cobol on Rails?), such development is impossible without losing some things in the process. Sure, any Rails port or clone can share certain outward similarities (in the way a cheap lemon and a well-designed automobile both have steering wheels and engines and doors and seats), but Rails's success is as much a measure of Ruby's expressive power as it is of Rails's conventions.


And that's it. Which can lead to a discussion of Ruby's ineffable gestalt, but that's pretty much the extent of where I go with it. I don't really beat up Python in the e-book (indeed, there are some libs I wish Ruby had), but I suppose I do owe Perl an apology there (I do stress Ruby's Perl ancestry later), but the main point of this section and the book as a whole is that you can't really understand how Rails is designed until you understand some of Ruby's prettier features. And those features are what allow Rails to do some powerful things. I don't think this is a contentious statement. And I don't really think that it's contentious to say it's much, much harder to try do something like Rails in a few other languages. It's when we compare to all languages that the gloves come off and we get into these style battles. Ah well, de gustibus non est disputandum.


Can't we all at least agree to hate PHP? ;)

sean
2007-03-30 11:11:21
Although the name Ruby on Rails suggests that the Rails model could be developed on top of other languages..., such development is impossible without losing some things in the process.

Like what?
Sure, any Rails port or clone can share certain outward similarities (in the way a cheap lemon and a well-designed automobile both have steering wheels and engines and doors and seats), but Rails's success is as much a measure of Ruby's expressive power as it is of Rails's conventions.

Again, specifics? With cars, I can point to particular aspects of their construction that make one more reliable and maintenance-free than the other. Can you do that with Ruby?
you can't really understand how Rails is designed until you understand some of Ruby's prettier features.

Which, and how do they affect the design?
Piers Cawley
2007-03-30 11:28:44
Hey, PHP's where DHH did his learning... maybe if he hadn't been using a crippled language he may not have had the need to write Rails.


This could be a good or a bad thing about PHP I suppose. Depends on your point of view.

Jacob Harris
2007-03-30 11:32:36
Sean,


In the case of the book, I look at the following features



  1. Symbols

  2. Blocks/Iterators

  3. Extending base classes

  4. Metaprogramming

  5. Domain-Specific Languages


Each of these are little aspects of Ruby that contribute to the structure of Rails, whether it's little things like 30.minutes.ago or bigger things like associations or validations or the routing DSL.

Curt Hibbs
2007-03-30 12:56:47
Sean, the questions you ask are the topic of Jacob's book. You can't expect a two paragraph summary of a fifty page book to provide satisfactory answers.


My whole point in making this post was tell people who *wanted* an answer to go the book.

Curt Hibbs
2007-03-30 12:58:59
Piers, I think you're right. DHH's thrust has always been to identify the pain-points in his web development and then devised ways to make the pain go away.
sean
2007-03-30 20:28:39
Jacob - Thanks for the explanation. Of your list, I would say that #2 is the most Ruby-specific. #4 and #5 are too broad to be meaningful in a "dynamic" language comparison. #3 is certainly available in Perl with very little syntactic overhead. So is #1, though most people don't think to use typeglobs ("*foo") this way. So in my mind, #2 is a rubyism by necessity, #1 and #3 are rubyisms by convention, and #4 and #5 need to be made more precise.


In fact, the term "domain specific language" has been drained of any meaning over the last few months, having become nearly synonyous with "library". YACC and Make are DSLs. For the rest, it's well past time "DSL" is put out of our misery.


Curt - I think there are two directions you can go when summarizing a book containing "Rails requires ruby for X." The first is to take out the "X" and simply say "rails requires ruby." The second is to say "for example, Y requires Z," giving a small example where a Ruby-specific feature enables some aspect Y of rails. I would rather have read the second.

Curt Hibbs
2007-03-30 23:41:27

sean said:
In fact, the term "domain specific language" has been drained of any meaning over the last few months, having become nearly synonyous with "library". YACC and Make are DSLs. For the rest, it's well past time "DSL" is put out of our misery.


I strongly disagree with this, at least for internal DSLs as used in Rake or Rails (YACC and Make are external DSLs). Far from being meaningless, I think internal DSLs will be a fundamental part of near-term innovations.

Dave Cross
2007-03-30 23:52:18
I don't know of any Perl or Python frameworks that use their own language for views, which I find rather telling.


And, of course, people designing frameworks that use a different language for templating would say that that's a deliberate choice. Personally I far prefer frameworks that use the Template Toolkit for templating (but then I'm rather biased).


Creating templates in your programming language seems to work in a small company like 37 Signals where everyone works on every part of the application. But much of the world doesn't work like that. In much of the world the front-end developers and the back-end developers are two different teams with different skills. The back-end developers know SQL and your programming language of choice (amongst other things) and the front-end developers know HTML, Javascript, CSS and things like that. Why insist the your front-end developers are Perl (or Ruby or Python...) experts too? Why not give them a domain specific language that addresses the specific needs of the domain that they are working in?


Even when I am building "one-man band" sites where I'm developing both the front end and the back end, I still appreciate the paradigm shift that I get when using a different language for a different area of the application. It forces me to change the way I think and helps prevent me from putting business logic in the presentation layer.


You don't expect to use Ruby to program the database. So why use it to program the front end? It almost seems like you're saying "Domain Specific Languages are great - except where we can't be bothered to learn one".

Matthew Sporleder
2007-03-31 06:19:48
I'm going to have to agree with chromatic on this one.
fauigerzigerk
2007-03-31 14:24:54
I have to say, all this talk of esthetics and Ferraris turns me away slightly. For me, language choice is mainly a matter of productivity. If DHH used Ruby productively that's fine. I like many aspects of Rails and dislike others. However, my own Ruby productivity is severely hampered by the need to fall back to C, because unlike a Ferrari, Ruby is incredibly slow. It means a lot of ugly interface coding (even with Swig) and jumping through library compatibility hoops.


It's not just Ruby, it's the whole idea of slow scripting language + C that I'm more skeptical about the more I use it. Yarv should help a bit. But the impressive performance gains (a factor of 4) are less impressive considering Ruby is hundereds of times slower than Java for some algorithmic tasks. I wonder if we should not go the whole way and learn Lisp to get C-like performance AND the advanced language features we miss in Java.

jason
2007-04-01 09:40:11
It is quite silly to say that a Rails like framework was only possible with Ruby. It is something to say that Ruby was the first with the stack, but that is it.


Lets check the list:


Java/Groovy => Grails (which will be better than Rails, I honestly believe...power of Java, flexibility of Ruby, fun of Rails)


Java => Seam


PHP => CakePHP


Python => Django, TurboGears


Perl => Catalyst


Squeak => Seaside (different, but alike enough to compare)


Lisp => Lisp on Lines


.NET => Castle/MonoRail


The point is that it is possible in other languages (it is stupid to suggest otherwise). The real question is whether these frameworks can gain adoption and widespread acceptance.


It looks like django will gain the python users and I suspect that Grails will eventually win out over Seam for rapid development in Java (Groovy is awesome!).



A
2007-04-01 11:25:42
There already is something that feels nearly exactly like Rails out there in Python: it is called Pylons.


Several of Pylons' components are ports of Rails stuff. It has the Routes URL system, it has WebHelpers (helper functions for template), it has the same model, controller, view layout. It uses Myghty (and soon Mako) templates which for all intents and purposes are Python in templates. The only thing it doesn't duplicate is the database system, and that's because Python has several ORM options which are more powerful than ActiveRecord, though there is no reason you can't use modules of SQLAlchemy which make it act a lot like AR.


One thing that is especially cool about Pylons is it is built to be extremely flexible. Everything is made to be swapped out. Want a different templating language than the default? Change a few lines of code. Want a different ORM? No problem. None of that stuff is particularly easy in Rails.


As far as I can tell, Pylons has all of the advantages of Rails without any of the disadvantages (hype, a slow language that doesn't have as many libraries, etc).


So I would very much disagree that Rails couldn't have been done in another language. I used Rails heavily for awhile and Pylons feels a lot like Rails. I'm not sure DHH could have as effectively marketed Rails in another language as he was able with Ruby, but the implementation itself definitely was possible, and DHH has even said that he didn't chose Python for subjective reasons.

Aristotle Pagaltzis
2007-04-01 16:32:23
Daniel Berger:


I don't know of any Perl or Python frameworks that use their own language for views, which I find rather telling.


It's telling that you don't know of any, but not in the way you thought. :-) In Perl-land, it's called Mason, the second-most popular choice for templating with Catalyst (but Mason can also be used as a framework in its own right and Amazon used to depend on it heavily). Over in Python-land, they call it Kid and it's the premier choice for TurboGears folk.

Aristotle Pagaltzis
2007-04-01 16:35:18

I find the discussion somewhat silly. In my view, Rails happened because of three key points:


  1. Ruby is free of the historic mindshare baggage that bedevils Perl and (to a lesser extent) Python.
  2. DHH came from PHP and was not biased towards web development the way it was done in Perl and Python at the time.
  3. Him and 37signals are excellent marketeers.


When it comes to creating maintainable code, we say it's the programmer who matters most, not the language. Why do we then assume it would be any different when it comes to creating adoption success?

izidor
2007-04-01 23:46:34
Very simple: Ruby's motto is "language that makes programmer happy". Rails keeps that motto. On top of that, Rails was built on Mac.


Of course Rails could be implemented/coded in any language, but the act of creation is not coding - it is an interplay of everything, including tools, while building a thing that has never been done before. You need to explore and backtrack and refine and during all that activity the environment impacts the decisions quite a lot.


So building a Ruby on Rails on a Mac by DHH was the combination that resulted in this lovely framework.


Now that it is done to a certain level, any coder can implement it by specification (i.e. framework itself) in any language/environment. And that is exactly what is happening - people who could not create it are now coding it.


The result is of course not the same as Ruby on Rails and development of this Copy on Rails will trail Ruby on Rails while copycats wait for another iteration of creative process to finish. But nevertheless, this Copy on Rails is still better that any existing stuff in those languages/environments. That also tells you something about both RoR and others...

jeremiah foster
2007-04-02 02:05:17
To say Rails wouldn't be Rails without Ruby is a tautology, but one that serves Rails and Ruby aficionados well. That tautology is useful when technical comparisons crop up, as they always do and always will and always should.


I still think there are significant advantages above and beyond frameworks that perl brings to the table, among them CPAN, Templating Toolkit, mod_perl, and much else besides. But perl lacks the compelling back story that RoR has at the moment, and that is why the focus is on Ruby's "gestalt" and not on its technical merits, of which there are many.


Perl has Larry Wall and JPL, but Ruby has Japan, DHH, and the Mac as its tools to spin an intriguing myth. That Ruby has a koan-like syntax, an enforced simplicity, a web 2.0 synergy with Basecamp and Ajax, all lend to its compelling status as the new, new thing.


Technically how could Ruby compete with perl in the ecosystem? i.e. mod_perl, CPAN, etc. Perl has been around much longer and more code has been written so naturally perl has certain advantages. But Ror will survive not just on its myth and backstory but on its technical merits and it will most likely thrive without having to be better than perl.

Curt Hibbs
2007-04-02 04:02:13
Wow, I wish I could have written that... very well said, Jeremiah!
Aristotle Pagaltzis
2007-04-02 15:44:46

Curt: a previous comment of mine got caught in the moderation queue, probably because it had some links in it. Can you approve it please?


izidor:


Ruby's motto is "language that makes programmer happy". Rails keeps that motto.


Larry Wall said of Perl programmers that they walk around with a smile on their face, long before most people had heard of Ruby... :-)


And that is exactly what is happening - people who could not create it are now coding it.


Several of the frameworks that people call Rails copycats are older than Rails. All of them failed to sell the world on the basic ideas that Rails also embodies. (Even today, almost noone has heard of Catalyst. We're struggling to get people to notice there's more to web apps in Perl than CGI.pm.) I'm not sure why people feel the need to make up some magic technical pixie dust that made Rails a success; if anything, it's an insult to DHH's and 37signals' skills as communicators and marketeers.


jeremiah foster:


That Ruby has a koan-like syntax, an enforced simplicity, a web 2.0 synergy with Basecamp and Ajax, all lend to its compelling status as the new, new thing.


... Oh my.


This is the sort of vacuous new-wave-speak that is giving the Rubyistas a bad rep as airheads among the Java folk. What does "a web 2.0 synergy with Basecamp and Ajax" even mean? (Why would random Rails users even care about Basecamp?!) Ruby has plenty of technical merit; it doesn't need this sort of disservice.


As for competing with Perl: as a language, on most counts, it can, and in some in comes out ahead - certainly in terms of being approachable. As for ecosystem, you're right: Ruby couldn't compete with Perl when Rails was first released, and it can't now; it may never completely catch up. But it'll likely mature quite fine. (Python's chances look worse. PHP will never get there, ever; which doesn't matter, as PHP is winning on other merits.)


Overall, I do think Perl is the stronger language - but only by a pretty small margin. Both languages also have their warts, and most of Perl's are much uglier. (Can you list some of Ruby's?)


I wouldn't at all be unhappy to have to write Ruby. Heck, I find Python very annoying for a number of reasons but it wouldn't make me seriously unhappy either. It just seems funny to me when people assume any of these languages has some special sauce that makes it clearly better than its peers.

chromatic
2007-04-02 16:13:10
@Aristotle, I agree.


It also seems funny to me when some people claim that one particular technology makes developers more productive than another. Productivity is, more or less, measurable--if only in the vague sense that one technology makes developers more or less productive than another technology.


Yet if that productivity gain is quantifiable, surely it's repeatable and measurable and identifiable such that it's possible to trace it to certain concrete features of the winning technology.


The lack of identification of those concrete features in any particular technology doesn't mean that they do not exist, but it does make me a little suspicious.

Curt Hibbs
2007-04-02 19:38:12
This has been a really good comment thread. I really appreciate all of the thoughtful posts.
Justin
2007-04-03 16:58:45
You can't make Ruby on Rails without Ruby because Ruby is right there in the name!
Tim O'Brien
2007-04-04 13:38:25
Curt, you know Justin has a good point. It would be something of a stretch to think that Ruby on Rails could've been implemented in something like Python or Perl given that the work "Ruby" is in the title. :-)
Aristotle Pagaltzis
2007-04-05 04:52:16
Merlyn likes to joke about Perl on Planks. :-)
Veldagodroba
2007-04-05 17:26:42
@chromatic
The lack of identification of those concrete features in any particular technology doesn't mean that they do not exist, but it does make me a little suspicious.


But they have been identified: Ruby feels more natural; even in the usage of DSLs it still retains the feel and features of Ruby. for most humans, it is a more enjoyable language to program in than the others. I think you're just not comfortable with that definition because it isn't quantifiable without a degree in psychology. There isn't a technical reason Rails couldn't have happened in Perl, Python, or C++. The reasons are all touchy-feely.

chromatic
2007-04-06 00:18:34
@Veldagodroba, I'm very uncomfortable with the assertion that "for most humans, [Ruby] is a more enjoyable language to program in than the others."


To my knowledge, most humans aren't programmers and don't really care about programming languages.


Per all of the statistics I've seen, most people who are programmers aren't Ruby programmers.


It's difficult enough to have a rational and coherent discussion about the various features and tradeoffs of design decisions in languages and libraries and frameworks and tools--which is my goal here!--without having to wonder where those three billion missing Ruby programmers have been.

Aristotle Pagaltzis
2007-04-06 08:53:27

for most humans, it is a more enjoyable language to program in than the others.


Statistics, please. It is clear which people like programming in Ruby; they are Ruby programmers. How do you measure which people do not like it? Have you heard of terms like “confirmation bias”, “absence of evidence” and the like? Ruby is not a bad language, but “most humans find it more enjoyable than other languages” is rather a big claim.


I know plenty of people who inexplicably like Java better than Ruby (or Perl, or Python). No kidding. Some even prefer C++ over Java! Weird, huh?

sean
2007-04-06 14:08:37
Some even prefer C++ over Java! Weird, huh?

(Raises hand.) And Perl and Octave over Ruby! Does that get me a shunning in these parts?
sean
2007-04-06 14:16:13
I strongly disagree with this, at least for internal DSLs as used in Rake or Rails (YACC and Make are external DSLs). Far from being meaningless, I think internal DSLs will be a fundamental part of near-term innovations.

I should have used "internal" and "external" right away to avoid this confusion. External DSLs are easily identified as such by their externality: if you see a parser for a limited (i.e. domain-specific) language, then you have a DSL.


Internal DSLs lack these clear distinguishing traits (this dreck is what finally drove me to my current view). What features distinguish an "internal DSL" from a "library with a clean interface"? I don't see any, other than the fact that "DSL" has become a sort of pixie-dust people sprinkle on libraries to make them cool, and weblogs to drive up hit-counts.

Alexandr Ciornii
2007-04-07 07:36:58
chromatic said:
> Ruby offers one semantic advantage over Perl: intrinsic OO even on primitives


Adding "use autobox" to your program is very simple.

Aaron 'Teejay' Trevena
2007-04-07 08:21:19
Still pretty clear that Rails could have been done in any language, in fact there were a bunch of MVC around that predated it.


Maypole (perl MVC using Class::DBI and Template Toolkit, both of which are more powerful and predate the ruby equivilents) was released over a year before Rails, Struts was around for years before that.


Rails is pretty good, but other framworks in other languages beat it in many areas, it isn't a huge step forwards, it's just that 37signals had a good team and were able to polish it well and battle test it in their (pretty nice) web applications.


There is no 'revolutionary' design in the rails framework, it's just a matter of Ruby on Rails looking so much better than what it's blinkered fans had seen in their little Java and PHP worlds.