Can Scala bring back the Joy of Programming?
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.
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.
In search of simplicity
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
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
- Dean Wampler
The pioneer spirit in academics
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
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