Coding styles.

As I was looking at my mate's C++ code I spotted the following curious lines:

  TreeDataCIterator it  ( m_treeDataList.begin() ), 
                    end ( m_treeDataList.end() );

Don't you think it's rather unusual for C++? Myself would rather writhe something more mundane like:

  TreeDataCIterator it = m_treeDataList.begin(); 
  TreeDataCIterator end = m_treeDataList.end();

complying with some old coding guidelines of the dark ages (aka 90-ties) which were imposed on the unhappy programmers in some big, iternational, waterfall project. But, you know, habit is the second nature... So I was somehow perplexed by the originality of the code, as I'd rather expected more dull style (like mine) considered C++'s strong C-legacy. But then I rememebred that my mate was originally a LISP programmer (but then his LISP-based company didn't really take off) and everything became clear! Look at this snippet uf LISP code from the SICP book:

  (define (count-leaves x)
      (cond ((null? x) 0)
            ((not (pair? x)) 1)
            (else (+ (count-leaves (car x))
                     (count-leaves (cdr x))))))

isn't it similiar? The love of parenthesis cannot be cured of easily ;-).

On the other hand, this could be as well an exmple if the C++ initalization syntax, and in C++11 we could write as well:

  TreeDataCIterator it  { m_treeDataList.begin() }, 
                    end { m_treeDataList.end() };

Not that LISPy at all (instead maybe a little confusing)! But seriously, don't you think arguing about this is a loss of time? Well, not really, good code should be readable, and if we care about our code, it's does matter. But then I find myself increasingly obsessed with code formatting and visual appeal of my code. It's certainly not wrong, but it robs my brain of its preciuos ressources. Remember? Your brain can hold in memory only 6-7 items at the same time, so decreasing mental load is a blessing for it. Not mentioning that formatting and reformatting your code takes time.

And the worst is, that your favourite formatting style at the moment won't be that in the next year. Myself, I was in projects where the coding styles looken at first insane to me! And I arguend and ranted but complied to them for the greater (i.e. project's) good. An guess what, now I'm using elements of these coding styles in my own code! Ok, not everything, but some parts weren't so nutty at all. What does that mean? Yes, you guessed it: coding styles doen't matter at all. But switching between them does!

So why we just don't stop doing this? Why don't let wo the computer do this and concertrate on more important aspects oif code? There are so many of them! As I first read about Go's policy about code formatting I wasn't too enthusiastic about it. But meanwhile I find it a good idea: only one prescribed layout style automatically imposed on your source code! Let's forget about coding standards and concentrate on problem solving!

Geeky Halloween costumes...

Matching nicely my last post abot the Go language: dress up as a programming language mascot:

(as appeared in  Golang blog).

Any other languages to follow? For Perl it's simple (a camel), for OCAML too (a supercharged camel), but what about C++? Or Assembler?

PS: My favourite C++ pic is this:

. But you really can't dress up like that, can you?

What I did like about Go.

Last week I've read the "Learning Go" book. I did that by sheer coincidence: it happened that I had the (free) book loaded on my eBook reader and just looked for light but interesting read. Why not an intro to a new programming language? So I started to with it and I didn't regret my decision. It was an entertaining and interesting lecture. I'd like to describe here what I liked about the language.

See, normally reviewers concetrate on what they didn't like in a language, but I think that's way too easy! The things we don't like are most probably the things we aren't accustomed with, and with some experience they wouldn't annoy us any more. So don't gripe, just be easy on Go!

As I learned from the book, Plan 9 project*, the (supposed to be) successor of Unix, included a language called Limbo which was a lot like Go already, which built on an earlier langauge called Newsqueak. So surprisingly, there's a lot of history showing up here!

Go itself is like it's mascot (look to the right!): small and quick. It's compiled and statically typed but does type deduction (like OCAML or Haskell). It main claim to fame are (beside garbage collection) goroutines and channels, but I have too little experience with them, so I'd rather concentrate on basic day to day traits of the language. I mean, the small things are the things that annoy us the most, and should a language will be anoying, it will screw them. Additionally, this way we can somehow transmit the "feel" of the language.

So let's start with:

1. multiple assignement

...a la Python:

  x, y := 11, 12
  _, y := 22, 23

As you can see the semicolons are not needed too - gives you a nice Python / F# / Clojure feeling!
If you have mutliple assignament, you get multiple return values for free, as in the following function**:

  func Write(file *File, b []byte)(int, Error)

See? You just specify the returns in parens after the parameters. And that leads us to the next goodie connected to the multiple assignment:

1a. the ok-idiom

it goes like that:

  if ok, x = foobar(y); ok {
    // do sth
    ...
  }

So no more if(foo() == -1)! Instead you can write:

  if nr, err = write(f, buf); err == nil {
    // do sth
    ...
  }  

You can assign and test a value inside of the "if "clause. Additionally the parens can be omitted too with "if" - more Python / F# feeling! Nice, isnt it?

2. named return parameters

We can assign names the return parameters:

  func write(file *File, b []byte)(n int, err Error){
    ...
    
    return
  }

When we name the returns, the compiler will initialize them with defaults (i.e. their zero-values)! We can eithet refer to them inside of the function (!!) or even omit them from the return statement, and then they will be used automatically with the initialized values. One thing less to worry about.

3. maps (and strings)

They are part of the language and not in the library. I wish they'll be that way in C++ too. Come on, D has done that!. Add this to the {} initalization syntax and you can write (almost LISP, Python or Perl style)***:

  var opmap = map[int]string{
    ADD: ”+”,
    SUB: ”-”,
    MUL: ”*”,
    DIV: ”/”,
  }

Well, speaking frankly, the {} initialization is possible in C++ too, alas only as of C++11.

4. defer for destructors

You can define Deferred actions, i.e. actions which are executed on the end of scope only:

  file.Open(”filename.in”)
  defer file.Close()

It's a nice replacement for destructors (see my previous post here). And it looks better that some "using" constructs from  other languages.

5. duck typing

Go has duck typing, but it's not C++ type of template duck typing. You don't have to mention a specific interface (yes, Go has a notion of interfaces!), it suffices to implement them ***:

  type I interface {
    Get() int
    Put(int)
  }

And then you just implement the required functions for a data type (see note ** below), and it will automaticall comply with the interface I:

  type S struct { i int }
  func (p *S) Get() int { return p.i }
  func (p *S) Put(v int) { p.i = v }

like that:

  func f(p I) { p.Put(1) }
  var s S 
  f(&s)

OK, so whats the difference to C++ type duck typing? C++ doesn't care about types: a template with two parameters simply takes two things, and then tests if they have the methods the template code requires:

  template <type T> void foo(T& t)
  {
    if(t.canBark()) t.bark();
  }

How's that different from Go? C++ gets problems with overloading in that context: it sees only a function that takes 1 thing. A totally generic thing! So you cannot define a second template with the same name and a different argument type, because at the definition level there aren't types, only things! That's why there's no range or complete container overloads for SLT algorithms (see H.Sutter's blogpost).

6. generic switch

Just like Groovy, Go has a very flexible switch statement:

  switch c {
    case ’ ’, ’?’, ’&’, ’=’, ’#’, ’+’:   
      return true
    case c < 'a': fallthrough
    case c > 'A':
      return true
    default:
      return false
 }

I mean, ever language needs something like that: case switch for strings and other types! And did you notice that fallthrogh must be stated explicitly? I like that.

7. the go keyword.

I liked the idea of introducing the word "go" as keyword to start a parallel "goroutine":

  int i
  go foobar(i)

I just find it funny :), that's all...

Note:
I admit, I didn't describe the features that make Go to stand out, only a couple of  those which particularly appealed to me. For more info on: function definitions, val notation, control structures, function literals (i.e. lambdas), goroutines, etc please read the book by yourself!

---
* a note aside: as pointed out several times on the web, there's a notable similarity between the logos of Plan 9 and Go. BTW: don't you think they are cute?

** more precise, you'd rather define a function like this:

  func (file *File) Write(b []byte)(int, Error) 

i.e. a function working on the File type, and invoke it like:

  nr, err = f.Write(buf)

But this is the part of the OO stuff so I skipped it in this post.

*** code example from the "Learning Go" book.

2009 Languages Overload

This year (or more to the point, that year, i.e. 2009) was for me a year of languages. Or maybe better, of languages overload! While I'm earning my bacon mainly with C++ (and a bit of Python), this year I had a look at a couple of new languages (adding to my last year's Groovy adventures) like: C# 3.0, Go, Scala, Clojure and even a bit of Haskell. In case of Haskell I'm feeling rather guilty, as I wanted to keep myself busy with Haskell this year but didn't manage more than some superficial reads about monads, and only becaue I needed to explain some Clojure code! Shame!

1. Java

But let me first comment on another language, which is ly dying these days: Java. Is it really dying? Looking at this post by codemonkeyism you'd say so. Why don't we like Java anymore? Let me cite:

Inheritance: outside of frameworks, inheritance is inflexible, leads to tight

coupling and is plain bad. Composition is most often a better choice. As are

mixins and traits

Noisy syntax: Lately there has been the enlightenment that too much noise in a language is a bad thing. Java is especially noisy in closures (anonymous inner classes) and generics.

Null / NPE: Null as the default for object references was a billion dollar mistake. An object should by default need a value. Otherwise NPEs will proliferate through your code. Newer languages prevent nulls or make the null behavior the non default one

List processing: As shown by functional languages, list processing should not be done

in loops. ... Java should have native support for easy list processing, not via the – best we have – constructs in Google Collections.

For me the 2nd problem is the worst, i.e. the noise. It's appalling how much of the Java boilerplate can be thrown away - check this presentation to see how much can be done with Groovy! But each of the new languages does a pretty good job here. Well, to be true, my biggest problem wasn't stated above at all mentionae above - lack of operator overloading! Whatever, the fact is that there's a host of new languages out thre, and the times seem to be more exciting than ever since the 70-ties!

2. Scala

Scala seems to be a language having every single feature from any language known to man. The overall impression was: OK, I know that one from ... One single feature I liked is the solution to the multiple inheritance conundrum (you know, the Deadly Diamond of Death) by linearization of the base classes. Clean, efficient, impressive! From the above list it's solving the Null/NPE, noise and inheritance problems. But the syntax is ML derived! Hate it! if this is a Java replacement, why cannot we stay in the old good C-lands? Another problem with Scala is poor tool support: I wasn't able to get the Eclipse plugin running, despite applying various workarounds found on Scala's homepage and upgrades of both the platform and the plugin. Even Martin Odersky (Scala's creator) is using Emacs for work!

On the other side, I think Groovy solves the list processing more elegantly, and it's DSL capabilites are more convincing too! (example to come)

3. Clojure

I like Clojure! I don't know why. It's not typesafe, has Lisp-y syntax and very complicated mechanism for integration of Java class libraries, but it is somehow elegant and minimalistic. It includes mutithreading primitives in the language definition and it tries to achieve good performance while staying immutable!

As I watched this presentation by Rich Hickey I noticed one important thing: he's an architect who was facing design problems in complex real life systems* (somehow like me, although I must admit that he's been exposed to more complexity than me) an tried to find a solution. And he really knows his stuff - all the conventional wisdom of software architecture! And Clojure (and Clojure's features) is an answer to these problems: it takes from LISP what seems suitable and isn't afraid to change it** otherwise.

Contrast this with Scala - sometimes feeling like an academic exercise in trying implementing all the features known to man in a single programming language just to show that it can be done (caveat: totally subjective opinion here). Maybe this pragmatic legacy is one of reasons why I like Clojure much more then Scala.

4. F# (and C#)

C# seems to be evolving very rapidly. From the ugly duckling it was a couple of years ago, it developed a respectable language with a decent amount of innovation. It has good lambda function support and the LINQ concept is rather interesting. I was surprised!

F# in its turn seems to be syntax-wise another ML derived langage like Scala, but it's not so overloaded with features. Sorry, I'm still not done with the free F# book...

Some (for example Scala Lift's creator here) say that it could be the single one of functional languages to success in the mainstream!

5. Go-lang

I didn't like it that much despite of its heritage. The obligatory, one and only true formatting rules, lack of subclassing... But on the other side, there is a CSP implementation on the language level! And as another programmer, who actually tried it out, stated here, it's much like writing in Python, only without its excruciating slowness. So maybe I should switch from Python to Go? Google Application Engine supports it now!

Update: in the meanwhile I managed to have a look at Go!

6. Summary

Warning: You see, it's not the comprehensive comparision I wanted to write back in 2009/10, but before I ditch the project altogether, I'd rather write this stub and extend it when I find some time. But the summary is already complete now, so... ---->

As I said above, I'd use Scala as a "better Java" as to avoid Java verbosity, lack of operator overloading and multiple inheritance. I'd use Closure for the joy of if (pun intended), I'd like some of my clients to want me to use Go, but wouldn't propose it myself, and I probably won't use C# unless I switch to .NET which is rather unlikely. On the other side, I might install F# on my PC - just to play with it a little.

--
* according to InfoQ "...Rich has worked on scheduling systems, broadcast automation, audio analysis and fingerprinting, database design, yield management, exit poll systems, and machine listening."

** e.g. even the venerable parentheses!