Imperative curlies 8: Why Am I Writing This Stuff

A bit over one year ago I started working on my first Groovy/GRAILS/lots of Java Script project.  Before, I worked with Java,  C#,  C++ and I was a very, very imperative programmer.  I was so imperative that I even did not know what imperative programming means (I did not know there can be something else out there).

I think I am not the only one who is going trough this change.  I am writing these posts to help myself by clarifying my thoughts on declarative program design and maybe to help someone make the transition I am trying to make.

How did my first Groovy or Java Script code looked like?  Obviously I jumped to using closures ASAP,  but using closures for the sake of using closures does not create a beautiful code.    I read Groovy in Action by Koning at al.   The book sure showed a lot of cool stuff you can do with Groovy,  but I was still thinking in Java and just applying more groovy syntax when coding.   In parallel to the groovy book,  I read Java ScriptThe Good Parts by Crockford.   Sometime during reading these 2 books,  I realized that to be good in these languages, I need to change the way I think.   I also sensed that, today's programming coolness maxims: dynamic typing, fluent programming, terseness,  are not really it.

Reading the Programming Scala by Wampler and Payne was a great learning and an eye opening experience for me.  I think I learned more about Java, JS and Groovy reading this book than I learned reading anything else and this book is not even about Java, JS or Groovy.   I think that learning Java made me a better programmer in whatever language I was using in 1997-98.  Learning SCALA makes me a better programmer in any of the languages I am using today (that includes Java, Java Script and Groovy).  To get better in SCALA I will need to broaden my functional horizons and probably will need to learn haskell.   So I have a full queue of reading waiting for me.  That will definitely include reading on haskell and reading more on SCALA.

So why am I writing these posts?  I got fascinated by the benefits of declarative programming.  Yet declarative programming is not something the community pays much attention to. 

If you ask a developer in the next office about what functional programming is about, you may hear a lot about immutable state (great) but declarative aspect is probably not going to make it into the conversation.   

There are many reasons why you may not want SCALA on your next project, but, what I hear a lot is that, developers do not like SCALA syntax, they miss not having curly brackets around function implementations.  This is yet another proof that software community has conditioned itself into imperative thinking.

Most developers want to program in Ruby or Groovy,  few are left who still prefer Java.  The most quoted reasons are the new programming coolness maxims (dynamic typing, fluent programming, and terseness).

One by one, if you drill into these maxims of today, they are all questionable.

Dynamic Typing:  You need dynamic language to have cool features of Ruby and Groovy:   You find a lot of opinions like this.  In particular, my current reading (RESTfull web services by Ritchardson and Ruby - an otherwise excellent book) keeps claiming that the Ruby goodness stems from its dynamic nature. The same stuff can be done equally well or better in SCALA which is, of course, statically typed.

Fluent programming:  One often acknowledged problem with this type of approach is that it is easy to use but HARD to implement.  Somewhat overlooked fact is that immutable collections in a functional language are ready for fluent programming.  Functional programming implies fluent!  Think functional!

Terseness:  Java is bad because it is verbose, Groovy is good because it is terse.  This over-simplifies the issue. Ideally language works towards better code.  The fact that code is short does not mean it is good.  I like when language supports terseness as a reward for doing something right.  SCALA allows you to define short one-liner functions without curlies. This allows for declarative definitions of functions similar to how you would declare a function in math (good).  SCALA or Groovy support of pattern matching is another example of good terse syntax complementing good programming style.   But is the # or ## method name in SCALA such a great thing?

How about Groovy Elvis operator?:  it simplifies the code around handling of nulls.  But then is null such a great language concept?  It has been called a billion dollar mistake by the guy to invented it...  Elvis it is better than nothing, but an even better solution would be to get rid of the concept of null.

As I try to become a better programmer,  I would love to have a rule of thumb on what makes my programs good and what does not.  Declarative programming became such as guide for me.  At least for now.

To make this guide even more explicit I came up with a quantitive measure: count the number of curly braces in your code, the fewer the better.

To me it is not about dynamic typing, fluent programming or terseness.  It is about how declarative my code is.