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.
No comments:
Post a Comment