Lambda the Ultimate

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

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

Right. Sorry.

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

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

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

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

[1] Components, Frameworks, Patterns (1997)

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

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

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

Where's that next post?

I think it's here.