For instance, in ASP.NET, managing what access users have to what pages is very simple. You define the roles for a folder, and use either Windows or your own custom security handler. ASP.NET just does it for you. You don’t have to tell it to call a subroutine in each page, it’s done for you.

A framework should be another level of abstraction, not just a bunch of libraries, but a whole way of working. When you wrote BASIC, you didn’t have to worry about pointers. It was hidden from you. You could just get on with the problem that was one level higher.

So in the case of Rails, I don’t see it as something that makes programming easier…I see it as something that makes it easier to talk to the web with Ruby…and to integrate Ruby with html, javascript, etc. more smoothly.

Sure, you could do it without the framework…just like you could buy the parts and build your own blender from scratch.

And it’s about time! There is so much sloppy, ugly code out there (and I’ve made some of it), and it’s nice that methods for organizing and structuring that code are gaining exposure.

Overall, it seems like the majority of web sites and web programmers are about 8 years behind the rest of the software development world. For example, it’s only been within the last year or two that design patterns have started to receive attention in the PHP world. Ask most PHP’ers if they know what test-driven development is, and you’ll get a blank look.

Anyway – the expanded definition given by Aristotle really is great, as is Mr. Meyer’s :) I would add, then, that frameworks are designed to meet some specialized need. In the case of Ruby on Rails, the need is building web apps.

Last thing- Mr. Meyer is actually a bit accurate in his conception of RoR as hiding actual code, only it often hides Javascript and not Ruby.

There are no silver bullets, but there are tools, and tools can be spectacularly useful if used in the right circumstances. You can”t even open a can with your bare hands, f.ex., but look how easy it is with a can opener. That sure doesn”t make the can opener an übertool capable of doing any job at any place in anyone”s hands.

So it is with web frameworks. For some things, they are spectacularly useful; but the solution to every problem they aren”t. No surprises there.

Some languages like Lisp and I believe Ruby make it easy to create little languages that can be parsed within the language interpreter/compiler itself, so you can freely mix in code from the original language with the little language. (People do this in Perl, too, though implementing the little language is trickier.)

Does this simplify your programming? Maybe, maybe not. Some people claim spectacular success. Some of them are bloody awful, and the learning curve is usually a major career move.

It is certainly true for Rails and Catalyst, and from what I know about it, I”d be surprised if it wasn”t true for CakePHP.