In search of simplicity

Can Scala bring back the Joy of Programming?

Hartmut Schlosser

Much of the work of a Java developer today consists of monotonously cobbling together libraries, integrating frameworks, refactoring, testing and deploying existing code. Maybe the fun comes back in programming in a language which is said to be “purely academic”?

Programming isn’t fun anymore. This is the claim of developer Eric Allman in his latest blog post where he goes on to bemoan that much of the work of a Java developer today consists of monotonously cobbling together libraries, integrating frameworks, refactoring, testing and deploying existing code.

Eric expresses a yearning for bygone days where there was a pioneering spirit, when you had to be creative as a programmer, to solve the logical problems that no-one had done before. Indeed, what happened to the fascination of controlling a machine, i.e. a heap of metal, plastic and silicon, by a mathematically motivated language? Where are the days when people still had the feeling to push forward the craft – some say the art – of programming?

Reddit commentator Deong describes the current situation of the Java community as a cargo cult: Instead of writing good code and deploy it to solve a problem directly, they prefer to deploy their favorite tools that solve the problem for them.

The Java EE mentality
The problem, Deong identifies, lies not in the Java language, but in a certain mentality of the Java EE community, which says: Frameworks in each case are a means to reduce complexity. Frameworks do a task that you would otherwise have to program yourself, however the fact that you may have to deal with a huge tail of dependencies that are difficult to control, is often accepted uncritically.

Often a large library or framework is used in a project just for doing the simplest tasks, instead of holding the code locally – and thus easy to control – they out-source the code and store them into “global” structures which are no longer controllable.

Architects trade local complexity for global complexity, and the bitch of it is, I can fix local complexity. It’s local. Go into the file or function, refactor it, clean up the variable names, etc. Global Complexity kills you.

– Deong

When the lines of code are spread across a huge inheritance hierarchy, replacing simple if statements with polymorphism, or sequencing done by method chaining up the hierarchy, and data structures moved behind some opaque wall the framework puts up to keep prying fingers away your from them, there’s nothing you can do. That is a system that cannot be fixed. In a nutshell, the past 15 years or so of software engineering have been about Ensuring that our inevitable errors are permanent and fatal.

– Deong

In search of simplicity
Given this situation, the cries to come back to the old virtue of simplicity get louder and louder. Do we really need the bloated Java tools and frameworks which can do everything – and nothing – for you? Historically, the Spring Framework actually reduced Java’s arbitrariness in terms of enterprise development and set a first focus on simplicity, but for Scala-evangelist Dean Wampler this is just the beginning on the way back to simplicity.

In his blog, Programming Can Be Fun Again, he advocates that functional programming concepts, which seem to be back en vogue again, are the next step on this path. Moreover, for Wampler the paradigm shift to functional programming has had the effect to rediscover the fun at work. Instead of making adjustments in frameworks and libraries, he has to again deal with the crystal clear logical precision, which once he appreciated so much as a young computer science student.


So, for me, programming did become fun again when I started using functional programming as my main ‘paradigm’. It strips away the cruft, makes reuse actually work, keeps my code concise, and it appeals to the Math / Physics geek inside me that craves rigor and precision.

– Dean Wampler


The pioneer spirit in academics
In the discussions, whether new languages ​​- Scala, Kotlin, Gosu, etc. – are ripe for use in real world industry projects, the argument always comes back to the point that IDE support is still insufficient, the availability of useful libraries is insufficient.

If you take into account the above criticism of the framework and tool-infatuation of the Java EE community, it becomes apparent that many of the arguments against these new languages ​​ are just a reflection of the afore mentioned lethargic Java EE mentality. Someone who is used to relying on frameworks and tools in any situation, will probably have problems with Scala & Co.

They will then describe the new language approaches as “academic” – meaning something like “quixotic” while forgetting the pioneering spirit that for decades, and probably still is, found in universities and other academic settings. Today however, there is a difference to the past: Whereas the academic research was very appreciated for many years and followed by the leading minds in information technologies, it seems that in today´s atmosphere, the word “academic” rather describes a defect:

Who writes today, “language X is purely academic,” says in effect: What has happened here is irrelevant and a waste of resources. What these university professors and subsidized language designers concoct in their ivory towers, is not suitable for industrial use anyway.

Reddit commentator Deong has decided in the face of this situation to retreat from the industry and go into the “diaspora” of academic research. A path that is certainly not feasible for everyone, but perhaps it helps if a Java developer confronts oneself with the “academic” languages and evaluates the benefits they can bring even now in real projects? Who knows, maybe the fun even comes back in programming in a language which is said to be “purely academic”.

Hartmut Schlosser
Hartmut Schlosser is an editor for JAXenter and a specialist in Java Enterprise-Technologies, Eclipse & ALM, Android and Business Technology. Before working at S&S Media he studied Computer Science, Music, Anthropology and French Philology.
comments powered by Disqus