Category Archives: cpp

The problem with static typing in programming languages

I remember reading in Paul Grahams excellent hackers and painters book, about how he liked the language he worked in to be dynamically typed as it provided him with more flexibility. The first time I read it I was still very much entrenched in the bondage and discipline language C++, and as so I found the statement wrong, but at the same time interesting. There had to be some deeper insight into this. A couple of years later, which would be the present day it just dawned on me that the biggest problem with statically typed languages are not the typing, you can get used to that. Its rather the fact that it becomes very hard to refactor the code afterwards. And worse, it shifts the burden of figuring out the right data structures and the right types to the beginning of the coding process instead of afterwards. Thus going directly against the good programming practice of writing for clarity first and only rewriting code if it has been deemed inefficient by a profiler.

Python is dynamically typed and after spending a year programming (this was about two years ago) in it I still found the fact that the types where missing to be quite disturbing. Especially the fact that you could have a branch in your program that had a small spelling error and only failing after you had run the program for several hours maybe. Or worse shipped it off to the customer. I realize now that this was mostly contributed to the fact that I was still coding Python as if I was coding c++. Something that the last two programming books (common lisp and programming erlang) I have been reading really have put to light.

There are tricks you can use in statically typed languages that can make the program easier to refactor later on. The var symbol introduced in C# 3.0, using typedefs in C++ and actually the whole standard library in C++ has had this covered quite nicely with the use of iterators. Still I think that maybe something like the duck types in boo brings about some interesting mix of the two styles. My very limited experiences with the boo so far has not been enough to determine if they the implicit type system does more harm that good. I sometimes find myself cursing over the fact that the system can’t detect the types for me, and at other times are happy that the system has found some trivial errors for me for free.

C# from a C++ developer perspective

Been wanting to get this out of my system for a while and since I can’t sleep I might as well do something productive.

During my time in iola I’ve begun writing code in C#. I’ve written quite a lot of C++ in the past and still does, so it was quite interesting for me to see what the next iteration of C would be like when I started out with this. This next section is written in a very practical sense, since at the end of the day, that is really what matters.

The nice stuff:

  • Fast compiler. I really think this is big. The slow compile time in C++ is contributed by several things, templates are really big here. And since they need to live in header files changing them can easily trigger a cascade effect of recompilation that is extremely detrimental to the whole coding experience. There are hacks around this but they are not really optimal solutions. When I did almost all my coding in C++ I didn’t think of this as a big problem, but once you’ve been seduced by the dark side (Take that Siebel ;-)) you really start to notice it a lot. And the fast compile time of C# makes it much more bare able to write in a statically typed language again.
  • Portable library with a lot of useful stuff like threading, network communication, File System abstraction, serialization etc.
  • No more dreaded header files. While this may seems strange at first (since header files are a nice way of describing the interface of the classes with comments that don’t get lost in the smoke of implementations), it’s actually really nice not having the headache of keeping
    the header files in sync with the implementation, making it much easier to move code around. Another big thing here is the whole template thing.
  • Delegates (or function pointers if you will) are extremely powerful and having them built into the language makes them very easy to use.
  • Support for yield.
  • Being able to use the power of .net (Newer in a million years thought utter such words) to mix and match languages. It’s actually quite trivial to write a piece of your program in Boo and have it work with the rest of the code. This is in particularly useful for writing unit tests.
  • Perhaps the biggest improvement, although this varies greatly from ones perspective, is that the whole language raises the bar. In the sense that a lot of the BAD programming practice that has been associated with C++, mostly caused by people simply using the language in the wrong way (char pointers, not taking care of memory management, generally pointers comes to mind here) has been stripped away from the language. A really good example of this is to compare the abomination that is pre .net C++ windows code and .net C# code.
  • C# is constantly improving and is doing so quite rapidly. Compared to the extremely slow pace of C++ (still hoping for a new standard in this decade!) it’s really refreshing to see a lot of good new ideas being pushed out to people.

The bad stuff:

  • Two thumbs up to the designer of C# for stepping up and actually implementing generics in C#. That being said, they are just a shadow of templates in C++ and the whole I-Implement-an-Interface crap is just plain dumb. Templates in C++ compared to generics in C# feels much more like macros in lisp, which if one thinks about it is quite the irony.
  • C# is clearly very proud of their garbage collection and thus sees no problem in demanding that everything must be created using the dreaded new syntax. While writing something like: List<string> l = new List<string>(); is not that big of a problem in something like monodevelop or visual studio. But it’s a big pain in the ass if you’re using the one and true editor. Another thing related to the GC is that needed to invent new syntax (using) to support the good programming practice of RAII instead of just doing it by creating objects on the stack and letting them fall out of scope and thus become deconstructed automatically.
  • C# falls into the trap of thinking that everything must be an object and that object orientation is the true path to righteousness. Namespaces was invented for a reason you know?
  • The built in libraries and especially the documentation is sometimes really really bad. Like methods returning results in different threads than the caller and not writing anything in the documentation about this.

Overall the experience so far has been quite positive and as far as I can see it will only continue to improve. That being said, there are still use cases where C++ is much more optimal and combined with a lot of legacy code C++ will continue to be used for a foreseeable future.

Boost part 2

In the quest for improving the quality of the MMS code in 1.1.0 I’ve done several things, one of which was to convert all the source to the boost foreach statement. Since I liked the result of the foreach cleanup so much, I decided to see what other libraries could be of use. I quickly found the function and bind library which allowed me to remove the internal function pointers framework we have currently been using. While converted I was surprised to see how cleaner the code became. The bind function is truly easy to use and read and made it possible to remove several helper classes which only purpose was to capture state to create a uniform interface.

So instead of:

class FP
  std::list numbers;

  FP(std::list n)
    : numbers(n)

  call(int t)
    int total;
    foreach (int i, numbers)
      total += i*t;
    return total;

(I saved the part of actually creating the function pointer object). One gets:

call(int t, std::list numbers)
  int total;
  foreach (int i, numbers)
    total += i*t;
  return total;

boost::bind(&call, _1, list_of_numbers);

Voila. Now if only the wordpress code formatting didn’t suck so much 😉

The future of C++

Recently I’ve been looking a lot into boost and it’s really a great set of libraries. Although the syntax of some of the libraries could use a helping hand (assign library). Luckily I was watching a presentation by Bjarne Stroustrup on the next C++ standard and it appears that they will finally add a way to construct containers such as vectors with elements as construction time. I think it was called initializer lists and the syntax was the following:

      vector v {1,2,3}

So you can now initialize them just like regular arrays 🙂 Furthermore it appears that we’ll get threads and perhaps a common filesystem + network abstraction. Now if only they could be a little quicker at bringing forward these new standards 😉