Frameworks insult language designers

Designing a programming language is an difficult task. During my time in academia, I had the great pleasure to meet some language designers. Listening to their stories is highly educating. Things that look simple or arbitrary at first become deep insights into the way humans understand problems and model solutions. There is nothing trivial in deciding names of keywords or punctuation. Object models and type systems are complex beasts. Simple is better than complex is better than primitive.

A book I can highly recommend is called "History of Programming Languages" by Thomas Bergin and Richard Gibson [1]. This book collects papers and slides by language designers from the ACM HOPL-II conference 1993 and is one of the rare documents where you can actually see how languages are created.

Designing a programming language is a game of self-restraint. More interesting than the features added are the discussions on features that have not been included into the language. Niklaus Wirth is well known for kicking out as many concepts as he added between language iterations (Algol-W, Pascal, Modula, Oberon). In 2005, I made the bold claim that nested classes where not added to Eiffel because they were not fashionable at the time, a claim that was directly corrected by Bertrand [2] (unfortunately, the link to the JPG image does not work anymore).

Like a good recipe, a good programming language has just the right combination of components. Through that, it creates a way to think that enables the programmer to understand problems and propose adequate solutions. Like real languages, programming languages are tools for communication, from programmers to machines, and between programmers.

Libraries and Frameworks

All programming languages allow the development of "libraries". A library is a reusable chunk of code. Libraries have interfaces, making it possible to document and understand the library without the need to know too much about implementation details. All programming languages support libraries, and designing the way that libraries are defined and deployed is part of the language design.

Libraries live "within the programming language". They behave the way the designer anticipated his language to be used. Libraries do not change the object model. They define types and functions the way they should be used. They do not circumvent boundaries, they do not add restrictions.

But there are things beyond libraries. There are beasts called "Frameworks". Frameworks are not libraries, even they often disguise as one. The important difference between libraries and frameworks is: frameworks try to modify the programming language. They try to change the object model, add meta-compilation, redefine instance creation or augment the type system. Simply put: they bastardize the language design.

Frameworks change languages

Here are some examples how frameworks change language designs.

Java has a quite refined system of software modules (called packages). The system is small and elegant, providing a global namespace based on DNS to prevent clashes between development groups. The definition of packages needs 15 pages in the 684 page Java language definition. The "Open Services Gateway Initiative framework" is very prominent in the community around the Eclipse RCP and IDE. It introduces the new level of "bundles" on top of packages. Because bundles have new rules for visibility and interface descriptions, OSGi requires a special Java class loader to be used in a JVM. Resolving dependency graphs with OSGi requires a complex computation, that fails often and is not trivial to debug. The current OSGi specification needs 358 pages.

The well-known "Spring Framework" is an other candidate that significantly changes Java. The core platform of the spring framework introduces a new way of creating objects, claiming that it solves fundamental problems of object creation. Actual arguments why this way of creating objects is "better" are rarely found. Instead, programmers have to use a new XML- or annotation-based syntax to create large sets of singletons, called "Beans". Intestingly, singletons are probably the thing closest to non-object-oriented programming in Java next to pure "static" classes.

Because of the ability to use reflection, define annotations and redefine the class loader, Java seems to be the main target for frameworks. But there are other languages as well. The Qt set of libraries for C++ provide, at the core, a system of "Signals" and "Slots" to support event-driven programming. They require a own pre-compilation step (moc - meta-object-compiler) that does type-checking and generation of reflection data. When you develop for Qt, you should use this new, reflectable object model for all your coding.

Its not my language, so why bother?

I think it should be clear by now that I am not a fan of frameworks. Sometimes they do help, for example in the case of C++ and Qt. But if the language is so imperfect that you desperately need a framework, why not change to an other one? There are so many good languages out there, at least one should solve your problem without a framework. Perhaps the fact that some languages do not require frameworks speaks for the language (Hint: ever seen a framework for Eiffel?).

Frameworks undermine the language designers search for simplicity and elegance. These two properties of programming languages enable us to think clear throughts and communicate precise messages. With frameworks we are sacrificying these properties. Often this sacrifice is not worth it.

• [1] Thomas J. Bergin, Richard G. Gibson (ed): History of Programming Languages, 1996, Addison Wesley
• [2] "Nested classes", Bertrand Meyer, Eiffel Studio mailing list: http://eiffel.641255.n2.nabble.com/nested-classes-td648054.html