My last post was called Java is not Object-Oriented. It's principally about where most of the abstraction in Java takes place and where it will take place in the future. There is one trend, in particular, that I would like to focus on.
Let's call it the paradigm cycle. It goes like this: programmers program using the features of a language. Best practices emerge as to how to use those features to write better code---a paradigm emerges. Programmers discipline themselves to follow the best practices. Then the paradigm becomes integrated into the language itself. Linguistic constructs for the concepts of the best practices start showing up. Programmers get used to their language having those features. Then they take the paradigm for granted.

Take for example structured programming. It came to people's attention that using GOTO's all over your code was actually hard to read and maintain. The languages of the day started to emphasize use of conditionals and formal loop statements instead of GOTO. Now we take structured programming for granted. It is so natural to assume that conditionals exist, we don't go around calling C structure-oriented, even though it is.
And this has happened with OOP, functional, and procedural programming. They have been well-integrated into their respective languages---to the point of becoming ordinary. The languages have assumed the paradigms as given. A Java programmer uses classes, methods, and polymorphism like a C programmer writes new functions. Writing object-oriented in C is non-obvious. You have to write your own object system and stick to a rigorous discipline. But in Java, the language takes care of the details.
If we project this cycle from the past, through the present, and into the future, what do we see? We see that a new paradigm, built on top of Object-Oriented, on top of functional, and on top of procedural is inevitable. And those changes are already happening.
Ronen mentions that the JCP is creating a module system for Java. They want to make a new package system with versioning support, integrity checks, and a distribution mechanism. These are ways to directly support library-oriented programming in the language itself.

Martin Ward coined the term "Language-oriented programming" to describe the paradigm where DSL's are a main abstraction. That shows that people are already building a new abstraction paradigm on top of other languages. Ruby Gems are a neat way to define, recombine, and distribute mini-languages.
So, what is now mainly a discipline of the programmer is being integrated into the language. New features are being experimented with to remove the burden of the programmer from the details of library and language maintenance. Very soon, programming languages will take care of most of the details of the new abstractions---just as they do now with the old ones. And programmers will come up with a new abstraction to build on top of that.
Now is our chance to ride the coming wave. We know it's going to happen as it has happened many times in the past. Become an early adopter. Evolve the language to include the new paradigms. Nature rewards those who further her aims (Buckminster Fuller). The best way to predict the future is to invent it (Alan Kay). You might as well ride the curve out in front of it instead of getting smashed by it and wondering what happened.
So what needs to be done? Abelson and Sussman (SICP) have this to say about programming languages:
* primitive expressions, which represent the simplest entities the language is concerned with,
* means of combination, by which compound elements are built from simpler ones, and
* means of abstraction, by which compound elements can be named and manipulated as units.
A library-oriented language needs libraries as primitives, a way to combine the libraries, and a way to name and manipulate those combinations. The Java Module System defines how libraries are defined (primitive) and a way to combine them (through dependencies). It might define more---the project is not yet complete. But it is obviously a start in this direction. There is still so much to be done.
But has it already happened? I blogged about OMeta a while ago. The language for defining languages. Languages being a primitive of abstraction in the language? Grammars are first-class objects? Grammars can inherit from other grammars (combination)? That sounds like language-oriented programming to me. From the guy who brought you Object-oriented.
New programming paradigms will inevitably emerge. We can already see it happening in Java and other languages. Language-oriented and Library-oriented programming will likely be built on top of the current object-oriented and functional programming paradigms. They will become commonplace. The question is this: what will your favorite language do to participate in this monumental change? Further, what new possibilities will emerge from the new paradigms?
Comments
First I'll say: I tried to
First I'll say: I tried to submit this comment but I got some server error, super sad. Attempt #2.
JavaScript (1.x) is an interesting language in the sense that it comes with no built in library functionality. But without thinking too hard you can make up your own system for it, a simple example would be
GlobalNS.MyModule = (function() { var OtherModule = GlobalNS.OtherModule; /* ...use OtherModule and create MyModule... */ return publicProperties; })();Just like how OOP is taught in SICP, that is :-).
If you have a powerful enough language (Lisp seems to come to mind...) you can implement whatever you want and then use compiler flags or a lint program to enforce how crazy you're allowed to be when writing your regular code.
Yes, and . . .
Yes, and I think you will see that being standardized, if Javascript turns out to favor libraries.
Post new comment