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.

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.

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.

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.

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.

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.

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.

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.

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...

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).

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.

@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.

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.

@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.

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.

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.

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).

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.

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.

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? ;)

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?

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.

Sean,

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

Symbols
Blocks/Iterators
Extending base classes
Metaprogramming
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.

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.

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.

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.

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.

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".

I'm going to have to agree with chromatic on this one.

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.

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!).

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.

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.

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

Ruby is free of the historic mindshare baggage that bedevils Perl and (to a lesser extent) Python.DHH came from PHP and was not biased towards web development the way it was done in Perl and Python at the time.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?

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...

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.

Wow, I wish I could have written that... very well said, Jeremiah!

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.

@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.

This has been a really good comment thread. I really appreciate all of the thoughtful posts.

You can't make Ruby on Rails without Ruby because Ruby is right there in the name!

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. :-)

Merlyn likes to joke about Perl on Planks. :-)

@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.

@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.

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?

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?

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.

chromatic said:> Ruby offers one semantic advantage over Perl: intrinsic OO even on primitives

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

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.

Daniel Berger said: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 suggest you take a look at the latest Jifty trunk. It uses plain Perl for the template language. (And yes, you can still use Mason.)

Here is a small example:

http://svn.jifty.org/index.cgi/jifty/view/jifty/trunk/examples/Doxory/lib/Doxory/View.pm

"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 find it telling that you would want that - fine, if you're working in a small team of ruby-literate cross-skilled people, but Ruby isn't so easy to learn that a web designer could pick it up and use it.

One of the key goals of the MVC pattern is to seperate concerns, and if you're putting a load of non-trivial ruby in your templates then it's failed to acheive that goal. Template Toolkit provides all the neccessary power and flexibility you need in a view, with a simple, clear and well documented syntax and the ability to use plugins and use your objects directly.

TT is designed for templating and does that job far better than Ruby, whatever it's advocates claims about it's domain specific language abilities.

Aaron, that (what kind of templating system is desirable) wasn't really Dan's point. The point was Ruby's suitability for creating internal DSLs.

The real question is why Ruby is able to do what it is able to do in Rails. My belief is that it comes down to 1) being extremely dynamic - classes can be changed at runtime 2) completely object oriented 3) blocks 4) have very terse and good syntax for all of the above. There are languages which might be able to do all of these things like 1)IO by Steve Dekorte 2) D digital mars 3) maybe javscript. I excluded Smalltalk because it doesn't have 1), lisp does not have 4), Python does not have 4) since it does not make 3) easy etc

Over in Catalyst land we generally recognise that using real code in your templates encourages you to put too much application logic in the View part of the MVC. This is a bad thing because it breaks separation of concerns. The fact that raw perl is so easy to put in Mason and less so in Template Toolkit is a good reason that it is the most popular Catalyst View.

BTW, Catalyst started life as a fork of Maypole, but was rewritten from the ground up. Vox is written using Catalyst although this is little known. Just like the rest of Perl it has an important role in web infrastructure, but is largely under the radar.

@Daniel Berger

Re: templating

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

I think what this tells is simply that you don't know of them.

Myghty and Mako both use Python.

Django's system is not "third party."

pirate and the pennants pirate and the pennants [link=http://agrecruit.com.au/csv/csvexport/comment-1691.htm]pirate and the pennants[/link] country kitchenware country kitchenware [link=http://gmsenbunitedway.ca/media/zoom_43efb968/pics/delgolfi.html]country kitchenware[/link] virginia child custody lawyers virginia child custody lawyers [link=http://frr.ie/phpMIKEadmin/table/comment802.htm]virginia child custody lawyers[/link]