I am a bit reluctant to post about this, since many of the issues involved are not programming language related. I hope we can manage to avoid discussing these issues here - there are plenty of better places to discuss them.

Still, many issues that are raised in this multi-blog discussion about the performance of Rails, and Ruby in general, may be of interest from a programming language perspective. More important, in my opinion, is to put this discussion in the context of the recent revival of frameworks. We discussed many of the recent interesting libraries and frameworks. Let me point out that not only are we reaching a point where languages and frameworks are judged together (with "Ruby on Rails" a classic example), but more and more libraries make use of advanced programming techniques that were considered arcane and esoteric not long ago (e.g., jQuery use of closures, metaprogramming and code generation etc.) This is an important development, and an interesting area to keep an eye on.

## Comment viewing options

### In your post, you suggest

In your post, you suggest we

...put this discussion in the context of the recent revival of frameworks.

Can you say more about the 'revival' of frameworks? When were they in use before? By 'frameworks' do you mean 'web frameworks'?

You go on to say that we are

...reaching a point where languages and frameworks are judged together...

but I'm not so sure this is anything special, if 'frameworks' may be taken as 'web frameworks'. We are approaching a time when httpin and httpout are as ubiquitous and necessary as stdin and stdout. How long do we have to wait until 'libwebapp' abstracts this stuff out of the individual application writers' hands all together?

### I am on my way to holiday,

I am on my way to holiday, so I can't get into details. Briefly:

Can you say more about the 'revival' of frameworks? When were they in use before? By 'frameworks' do you mean 'web frameworks'?

Frameworks were seen for a period to be a solution to many of the problems involved in SE. The classic example of a framwork is the MVF framework in ST. See here for more. The current crop of fw consists mostly of web fw, sure.

I'm not so sure this is anything special

I didn't say it was special, I said it was important... More to the point, languages and libraries should not be confused. Confusing the two makes it hard to appreciate which specific semantic features enable the types of libraries/frameworks one is interested in. Being on the lookout for these features is fundamental for advancing the state of the art, in my view. We discussed this issue a lot in the early days of LtU, and it is nice to see it resurface (I again suggest looking at jQuery, and how it evangalizes closures...)

### Frameworks were seen for a

Frameworks were seen for a period to be a solution to many of the problems involved in SE. The classic example of a framework is the MVF framework in ST.
• SE = Software Engineering?
• MVF = ?
• ST = ?

I'm not as familiar with the lingo as I'd like to be.

### typonym?

SE is Software Engineering, yes. I think MVF may have been a typo for the MVC framework in Smalltalk (ST). YMMV, HTH.

### Right. Sorry.

Right. Sorry.

(YMMV= Your Mileage May Vary; HTH = Hope This Helps...)

### Translation

MVF = Model-View-Controller (oops)
ST = SmallTalk

### Frameworks are the new languages

I think frameworks are the new languages in a way. These days only the insane and the academic build programs without leveraging a framework. The framework authors have become the prophets of the language creator, translating the so-called advanced concepts into a form the great unwashed can understand. The best frameworks leave very little need for the application programmer to make decisions about how to best use language features, and hence to mess up. In this way new language features are eased into the wider programming community.

PS: Proudly insane!

PPS: I agree with Avi's points on component based development. I think that's the next big thing in web development. It is kind of amazing it isn't the current big thing.

### Give me not food, but the tool to learn to fish

Frameworks are good up to the point that usage is within their developers' ideas. I prefer to have the tools to make whatever 'framework' I want, rather than either a complex framework or a limited one.

### Sometimes you can have the

Sometimes you can have the cake and eat it too. I guess the consequence of having "too many frameworks" ( a popular complaint ) has lead to WSGI and Paste in the Python community. But then they build again a framework on top of some pieces of infrastructure that glues components together.

### Pylons and Spring

Pylons are Spring are, IMHO, excellent examples of the rediscovery of the original principles behind application frameworks. In particular, that they should consist of small pieces, loosely coupled. It's hard to do in practice, and it doesn't strike me as accidental that WSGI basically specifies a "callable" that takes two arguments, one of which is itself a callable, and you build WSGI-based applications, middleware, etc. by composing these callables and calling them at the appropriate time.

Spring, in the Java world, does something essentially as clever: by reasserting the value of dependency injection and relying on interfaces rather than concrete classes, they achieve the same end of small pieces (interfaces with few signatures) loosely coupled (they're interfaces, not classes, although Spring provides a ton of concrete classes that play together nicely).

I find it highly suggestive that both Pylons and Spring, object-oriented Python and Java frameworks respectively, aggressively avoid inheritance and aggressively pursue functional composition. There are big lessons in these very pragmatic frameworks!

### Spring

I like Spring; it is lightweight, and certainly helps keep my code documented and easily modifiable.

Using it I tend to view its concepts as prototype based OOP combined with a form of currying. Using an object with a method:

void updateUsers( Connection con, List users );

in Spring we inject the Connection into the Object and just use:

void updateUsers( List users );

Currying also yields a function/closure/object which can perform the action.
(Since I don't know Haskell I will use Javascript):

function updateUsers()
{
var con = arguments[0];
if ( arguments.length==1 ) return function(x){ updateUsers(con,x) }
//.. update users here...
}

### Do you have any references

Do you have any references regarding "original principles behind application frameworks"? I ask because my understanding is that frameworks are supposed to encapsulate one specific design for reuse. Quoting Ralph Johnson, "a framework is the skeleton of an application that can be customized by an application developer"[1]. This seems to imply that loose coupling is not a primary feature of frameworks.

### Unfortunately...

...my information about that period of framework history is largely anecdotal, based on early exposure to Smalltalk-80, Symbolics Lisp Machines, and MacApp. My grasp of the principles as I understand them derives a lot more from MacApp than from Smalltalk or the Lisp Machines, perhaps because Apple actively sold MacApp and tried to help developers understand how to use it.

There are multiple degrees of, and multiple ways of implementing, loose coupling in frameworks—so much so that I think one can credibly claim that, in order to support Ralph Johnson's "can be customized by an application developer," a framework must be loosely coupled at least to that degree, otherwise all you have is an application skeleton whose source code must be altered in arbitrary ways to implement any application.

What I was alluding to in my comment regarding Spring, in particular, was its aggressive support for what is currently called "dependency injection" or, sometimes, "inversion of control," and we old-time MacAppers called the "Hollywood Pattern" (I still have my "Don't call us; we'll call you" t-shirt around somewhere). Here we have "loose coupling" by virtue of inclusion polymorphism: the framework code contains references to base classes; those references are initialized with instances of subclasses that hopefully adhere to the Liskov Substitutability Principle. But as long as they do, the framework neither knows nor cares what concrete class is being used—that's "loose coupling" in the context of a traditional object-oriented framework.

Java and Spring add a couple of nice wrinkles to this venerable approach, thanks to supporting interfaces, reflection, and dynamic loading. Spring Core and Spring Bean give you a dependency injection container for JavaBeans. Reflection gives you the means of setting properties on them. An abstract factory class configured with a simple XML file lets you identify what concrete classes are associated with which interfaces, wire up your object graph, identify which objects are to be singletons, etc. Taken to an extreme, your application could be altered by replacing a .jar file that contained the single class you wished to update, and/or updating the XML file establishing the interface -> concrete class mapping.

So I think my claim about "loose coupling" is reasonable, but primarily because it's a bit too vacuuous not to be! It's important, I think, to keep in mind as a 50,000-foot goal, but the details about how to achieve this loose coupling are inevitably going to be specific to the combination of language and framework architecture in question.

### We actually moved from Rails to Erlang

Sometime in the fall of last year, we moved from Ruby on Rails to a pure Erlang stack. We recently (today!!) wrote up a blog post on this..
From Python to Ruby to Erlang
Vijay

### How much code did you have

How much code did you have to rewrite on your trip through languages and frameworks on each iteration?

### In my next post...

"In my next post, Iâ€™ll tell you whether Erlang lived up to our expectationsâ€¦"
The blog post doesn't say anything about "...Ruby to Erlang", it doesn't say anything much about your experience or technical reasons for moving from Python to Ruby - "Rails has a much larger following..."

### So...

Where's that next post?

### All things come...

I think it's here.