Programming Can Be Fun Again

September 5th, 2011

Eric Allman’s recent blog post, Programming Isn’t Fun Any More has struck a cord with a lot of people and is enjoying a spirited discussion on reddit. The comments by deong are the best (here, here, and here).

Language environments like Java have a serious problem with bloated tools that get in the way of solving customer problems. The Spring Framework was great in its day, because it cut through the J2EE garbage and introduced a much needed focus on (relative) simplicity.

However, I now see Spring as a local minimum in the quest for simplicity. In the Java world view, Spring minimized complexity, but in a larger world view, you realize we can do better.

Eric Allman’s recent blog post, Programming Isn’t Fun Any More has struck a cord with a lot of people and is enjoying a spirited discussion on reddit. The comments by deong are the best (here, here, and here).

Language environments like Java have a serious problem with bloated tools that get in the way of solving customer problems. The Spring Framework was great in its day, because it cut through the J2EE garbage and introduced a much needed focus on (relative) simplicity.

However, I now see Spring as a local minimum in the quest for simplicity. In the Java world view, Spring minimized complexity, but in a larger world view, you realize we can do better.

One of the most attractive features of functional programming is how concise it tends to be. Reuse is achieved primarily at the level of core data structures with combinator functions for composing behavior, such as map, filter, and the “uber-combinator”, fold. (My recent talk at Agile2011, How Functional Programming Changes Developer Practices introduces these concepts, using Ruby.)

Several commenters on the reddit thread complained about the pervasive reliance on ORM (Object-Relational Mapping) tools. This is an excellent example where the over-reliance on object-oriented purity went wrong. We used these tools to insulate ourselves from the perceived “ugliness” of the relational model and the hassles of using relational databases. What we actually did was incur serious overhead and loss of productivity as we force-fit data structures coming from the database into ad-hoc objects, manipulate them for the business logic, then convert them back into data structures for writing back to the database. Instead, vast simplification is possible if we work directly with the data structures that come out of the database driver layer. They are easy to serialize to and from JSON, which our JavaScript UIs require, and they can be manipulated with the combinator functions mentioned above. (This assumes those data structures implement these combinators; they do in functional languages.) For examples of this more direct approach, see the Anorm persistence API in the Play Framework and LINQ in the .NET world (e.g., see this ACM Queue article by Erik Meijer).

A side note; as a Scala advocate, many developers complain to me that the immature support for Scala in IDEs is a real blocker for introducing the language in their Java environments. I understand the practical issue of meeting this now-typical expectation of Java shops, but I actually don’t really care. I seldom use IDEs anymore. My Scala code is so compact that I use Emacs for it. The ENSIME Scala Emacs mode and the sbt build tool give me all the “fancy” features I need.

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.

I discuss these ideas in more depth in my new book, Functional Programming for Java Developers. See also my recent OSCON tutorial, Become a Better Developer with Functional Programming and the shorter Agile 2011 talk I mentioned above.

13 Responses to “Programming Can Be Fun Again”

  1. Anonymous to avoid the Scala crazies Says:

    I’m not sure what kind of code bases you are building with, but when you have 100s of files, 10s of thousands of lines of Scala code not to mention scores of Java libraries, code navigation and refactoring is basically impossible without the help of an IDE. Maybe your Scala projects are just smaller than your Java applications?

  2. Scott W Says:

    @Anonymous:

    I think the point of the post is that concise languages don’t generate 10s of thousands of lines of code or need 100s of files for the equivalent Java project. First, as the author states, you’re not tied to OO purity, which eliminates a lot of classes that don’t do anything by themselves. Second, the idioms of concise languages lend themselves to easy comprehension in as little space as possible. This allows your head to hold more of the program at once, reducing mental context switches. Last, if your language is so bulky or unusable without an IDE, doesn’t that tell you something about the language?

  3. Rod Says:

    Did you mean Agile2011, rather than Agile2001 (which would not be so recent)

  4. Alex Dean Says:

    On the Anorm documentation page there are 17 commenters flagging that they think the Anorm approach is a really weak idea, and none saying it’s a good idea:

    http://scala.playframework.org/documentation/scala-0.9.1/anorm

    In fact, the ORM model and the FP approach of fold/map/filter work really nicely together (as in Scala Squeryl): the ORM defines the record/type structure and then fold/map/filter etc can be applied to collections of these records. Without that object structure, a purely FP approach would simply be operating on tuples, which would quickly get unmanageable. Even Anorm concedes this with its rather clunky “Magic[T]” case classes.

    Something like Squeryl is also database-agnostic, fully typesafe with a centralised metamodel and completely DRY (because I don’t have to restate the type of a column every time I use it).

    Don’t get me wrong – I’m super-excited by the move to more functional approaches, but modern functional-aware ORMs like Squeryl are part of the solution in a way that Anorm will never be :-)

  5. George Armhold Says:

    While I appreciate the conciseness of languages like Scala, my Java pain points don’t really have much to do with the verboseness of the language. The pain comes from the piles and piles of libraries and configuration that you need in order to build a working app. I’m mostly talking about webapps.

    How many different ways are there to use an ORM in Java? OK, let’s narrow it down to Hibernate.

    How many different versions of Hibernate are there? Which ones work with your app server (because if it’s already bundled with your app server and you try to use a different version, you’re in for a world of pain).

    How many different ways are there to write queries with Hibernate? HQL? JPA QL? HibernateEntityQuery? Criteria queries? There are lots and lots of ways to do the same thing in Hibernate, and every project I encounter seems to reveal a new one.

    How about logging? Log4j or java.util.logging? Or perhaps use Commons Logging as a wrapper. Or maybe SLF4J is a better wrapper? And how to configure logging- XML, or properties files? And where do they go? How do you override the container’s settings? Whatever you end up using, be careful, because if you forget to add the right lib(s) your stack traces will be abbreviated, and it will be very hard to diagnose Hibernate mis-configurations (just had that exact problem yesterday).

    If Scala et al don’t have these problems yet, that’s great. But I wonder if it’s simply that their ecosystems are so new that they haven’t yet had time to develop such library/configuration nightmares.

  6. Anonymous Says:

    @Scott W If you reread my post, you will see I am talking about huge Scala projects.

  7. Aneesh Says:

    As Geroge Armhold points out, the main blocker in programming with java right now is the number of different kinds of tools/libraries. While it seems like “more” seems better, it does take the fun out of real programming. Most of the work that tends to get done in commercial application development seems to be making very ordinary websites. The bulk of them are CRUD applications and most of the challenges involved in building those applications are in figuring out how to use the frameworks that developers tend to throw in. Usually these frameworks do not really add much benefit. The only benefit that people get out of this is an experience in having worked with that framework. And of course then you can compare it with another framework and then fight over constructor injection, setter injection and the likes.Programming as is commonly encountered in commercial applications tend to be more of a “know/configure a framework” type of a job than around actual coding.

    People tend to take a stab at Java being not concise enough and therefore tending to be difficult to maintain and other newer languages being concise and hence easy right out of the box. This is hardly the case. While there are just too many java projects built right and wrong out there, there aren’t too many projects done in the newer languages. So the data that you have for each are very different. And it is not that there is no bad code in the newere languages. There are people finding badly written Ruby code these days. Check out this link about some large ruby codebases where the original developers have moved on http://bit.ly/n7RNO1.

    So till the languages and their ecosystems mature, it is hard to say the problems are eliminated. The newer languages and paradigms might improve on shortcomings of the older languages, but code written without a thought given to idioms and good design will tend to grown into a big ball of mess be it any language.

    And if your project does not have a domain complexity, most of your complexity will be around a framework thrown in thoughtlessly.

  8. Dean Wampler Says:

    @Ron, thanks for the catch, changed to “2011” ;)

    As @Anonymous said, one my assertions is that a functional language, Scala, Clojure, Haskell, etc. will greatly reduce the amount of code you create. That won’t solve the problem of trying to integrate with too many libraries, but you’ll be less tempted. I also believe those libraries will be less bulky, etc.

    @Alex Dean, you’re right that Anorm might not be the best example. Alternatives like Squeryl are worth a post of their own. I hope you’ll blog your views!

  9. Berlin Brown Says:

    “A side note; as a Scala advocate, many developers complain to me that the immature support for Scala in IDEs is a real blocker for introducing the language in their Java environments.”

    I use Eclipse for everything (Java, Haskell and Scala) and has been very productive. I know, I know. Eclipse is supposed to be a resource hog. That just doesn’t matter compared to the productivity gains I get from working with one piece of software that does everything I need.

    With Scala: this had some serious flaws with previous releases. But in the last year, I think the major Scala players got involved and added much improved support.

    With Haskell: Eclipse FP has all of the package management and source syntax highlighting I need.

  10. Jonathan Fuerth Says:

    I have to disagree about the IDE being a crutch for a bad language. I’ve given it a shot with Python, Perl, and JavaScript. I miss:

    • rename (local, function, constant… code is easier to read when things have good names)
    • extract to local variable
    • auto-highlight all usages of current element within the file (especially with other people’s code!)
    • project-wide find usages & call hierarchy
    • help constructing doc comments
    • integrated access to doc comments

    How can you work efficiently in any language without these creature comforts?

    PS: I’ve seen “strike a chord” misusing “cord” several times in the past week. I was starting to doubt myself, but good old brians backs me up: http://public.wsu.edu/~brians/errors/strikecord.html

  11. sebastian Says:

    Yes it can be fun again.

    Like using plain objects without distractions.

    You can have fun thinking functionally (I know how it feels) but our brains are more efficiently wired to think anthropomorphically.

    Thens of thousands years of refined evolution waiting for you to use it.

    What programming language actually use that?

    That’s the ultimate impedance mismatch.

    PD: and that’s why I use smalltalk

  12. Terri Says:

    Lately I’ve been revisiting my favorite technological Utopia: Star Trek. In every episode, the ship is being pummeled and the captain asks to the chief engineer “How long will it take to get the deflector dish reconfigured to…”. Usually within minutes, it’s working; for sure code libraries are being invoked. So it must be to keep the boss happy and the Cardassians at bay.

  13. Hartmut Schlosser Says:

    I´ve posted some refelctions here:

    http://jaxenter.com/can-scala-bring-back-the-joy-of-programming-37821.html

Sorry, comments are closed for this article.