C, C++, Java, Haskell?

I’m excited and distressed with my OpenGL adventure. At the same time that learning OpenGL makes me pleased, it also makes me irritated: I’ve dedicated much time learning Haskell and got involved in a way to really like the language and the community. But, doing something in OpenGL was very hard and lonely. There are very few content about it and the majority are already obsolete.

I did put Haskell at the corner for some time and refreshed my C knowledge to learn modern OpenGL, with shaders and buffer objects. The reason was simple: I didn’t manage to do anything in Haskell that actually worked and had no clue if the problem was with my code or with the libraries I was using.

Well, to make a moving camera in a 3D world was difficult, even in C. But, I’ve found lots of good stuff on the internet to help me do it. Using all this help, I’ve managed to make it work.

I’ve decided to get back to Haskell to apply this knowledge I just got.

Oh dear! To make everything fit together and with the right types made me sweat some t-shirts. If I wasn’t so stubborn, I wouldn’t do it. I’ve switched OpenGL by OpenGLRaw because the OpenGL package has no binding for “glUniformMatrix*”; also switched GLFW by GLFW-b because the first one has a dependency with OpenGL package.

I read a post at InfoQ asking if the C language was still suitable. Made me think on lots of stuff, including on to abandon Haskell and get back to pointers, manual memory management, hairy strings, …

Perhaps it’s because I’m new to this world, but I feel kind of unproductive while programming in Haskell. My impression is that, unless it’s something very well consolidated and used by lots of community members, a lot of time will be spent going after libraries that usually are just a binding for one written in C. When that’s not the case, just to take a breath of the library’s API, I need to read some papers trying to remember all the magic about Functors and Monads (I think I’ll need some books to really understand Arrows!).

To understand pointers and memory management in C was difficult too. But back then I was a young boy at the world of programming, my knowledge was very limited, it was based a lot on punching the code until it did what I wanted. I can’t accept this anymore, I need to understand what I’m doing.

I remember I had good reasons to change C for Java. After a while using Java, I started to see the cons of the language too. My undergraduate work was dedicated to point the reasons of this change and the promising future of languages like Haskell.

I believe that this negative feeling happens with every language that you spend some time learning. The propaganda and the first steps are wonderful. You imagine a new world where everyone is rich and can enjoy all the beauties of life. With time, you realize that it’s not like that: every decision the language has made means positive and negative points to us, programmers. I’ve experienced this with C, Python, Java and now with Haskell.

Java has chosen the O.O. way: even if it’s a static function or a global variable, the class wrap will be there. Haskell picked the pure functional way: even I/O operations are wrapped within a monad.

This is not bad at all. The use of monads to model sequential computation was a great discovery that led to a lot of other solutions. All the choices made brings with them some pros and some cons. (Just take caution with the extremism [e.g. Singleton].)

I’m distressed because I don’t know what to pick:

  • C looks flexible but with complexities I’m not wishing to have. C11 may have fixed some (e.g. ), but GCC has no support for it yet;
  • I feel productive in Java but the inherent overhead and the need of a JVM makes me angry;
  • C++ I don’t know well, but I think I’d prefer going into C than this one. Java has shown me good reasons to say no to O.O. But, even GCC is using C++, maybe I’m missing something. The libraries for C++ looks great (e.g. GLM, Boost);
  • Haskell is my favorite, but it’s starting to bother me little, this feeling of being stuck, without delivering anything, makes me tense. Maybe I need to give some more time for it to really kick in. I don’t know if this commitment will worth it or I could make a better use of it enhancing my skills in another language.

The performance difference between C and Haskell don’t bother me much, because I’m not going to do micro-optimizations so early.

The ultimate answer is something like: it depends on your project, choose the right language for the right project. Well, I have no project at all, but I want to get deeper into game development.

What should I do?


13 thoughts on “C, C++, Java, Haskell?

  1. You've chosen three very 'pure' languages, C being minimal and low level (these days), Java being OO without influences from functional programming and Haskell being, well, purely functional.

    I would recommend trying some languages that focus less on a single paradigm, such as C#, Python, Ruby.

    If, as you say, performance is really that important to you that a JIT compiling virtual machine is still too much overhead for you, I guess C++ would be the best option. Just know that C++ is a very big language, so the rigid OO-ness of Java is quite optional there.


  2. My deepest fear with C++ is that it's libraries may looks like the Java ones. With huge frameworks of objects communicating on the background, so you need to write a lot of setup code to make the single function you need to work.

    The Java overhead I dislike is not about the runtime. I really hate to pay a huge cost to have a good design. Everything you model in Java has a cost. Nothing is free on it. There's a lot of bookkeeping of classes, stacks, methods, reflection, …

    Thanks for your tip. I'll take a closer look at C++.


  3. I've been programming enthusiastically for 30 years, but have yet to find a language I really like.

    Scala and C++ are my primary “working” languages, whereas Haskell and Scheme are my favorite languages for little scripts and programs.

    You might find Scala to be much less distasteful than Java — I know I do, though it still reeks a bit of bad JVM. *grin*

    C++ isn't all bad. In fact, if I had to limit myself to a single language, I'd choose C++, because it's the most broadly applicable (after C). And by making use of higher order functions and immutable data (especially const pointers), you can get some of the goodness of functional languages.


  4. I second that you should give Scala a try. It has a less steep learning curve than Haskell and you can use all great libraries available for Java while still have almost the same expressiveness as Haskell. Performance is usually not a big problem, but if needed you can write low level imperative code in Scala. The IDE support is not as good as for Java, but way better than C/C++ and Haskell at least.


  5. I recomend you trying on Scala. I tried all the same languages you used, and with Scala I feel more productive everyday because Java compatibility and the power of the language to manage OO and FP quite helpfully. It's not a pure FP language like Haskell, and maybe that it's a cons, but you can always still programming in a mainly pure way!


  6. Have a look here: HGamer3D. This is a library for writing games in Haskell. It's new, so nobody used it so far. Stability is considered experimental, but for me it's already a lot of fun. Peter Althainz.


  7. I've programmed in some 15+ different programming language from all the major paradigms (with some examples): imperative (BASIC, C, Lisp) , OO (C++, Java, Python, Lisp), logical (Prolog, Lisp), functional (Haskell, Lisp, Scala).

    So what is Lisp doing there. Well, it has all the paradigms. It is a bit awkward in the beginning but you can really do anything in there. Having said that, because you can do everything in Lisp (especially CLisp (Common Lisp)) people have done everything so the community is scattered. Libraries take a while to form.

    I think that there are some strong combinations of languages, and that you should choose the right combination.
    — Scala/Java is strong (but with a JVM, which is no problem if the program is running for a while)
    — Python/C++ is strong, you can start in Python, and anything that is a speed bottleneck you can make a C++ version out of that part of the program (Civilization 4 was created in this manner)
    — Haskell/C is very strong, the typesafety of Haskell is one of its greatest feature but the learning curve is steep, use C for extreme optimizations wherever you want, but often this is not needed if you use the correct Haskell library.
    — CLISP is very strong, but less well with the libraries than the other languages

    After decades of programming I've come to love Haskell. But it takes a long time to really learn it, and then some more time. I'm still reading about Haskell a couple of hours a week.

    Any of the 4 options above is good, but listening to your story, I'd go for the Haskell/C option.


  8. Thanks for your kind reply. I'm having a real good fight in my head. I started poking C++ again just to find out that I still prefer to use C.

    One of the things I really don't like about the O.O. world is the extensive use of exceptions for anything. I still don't like that Haskell has exceptions, but at least I know where they lie (IO monad and partial functions), so I can have them under control.

    So, the above statement discards Java/Python/C++ to some extent. At least I would prefer to avoid the disapointment of trying to use a library that is full of exceptions. I've never done anything on Scala, so I don't know exactly what it's up to.

    Languages that promote more than one paradigm have a tendency to turn into monsters. I've heard some posts about the non-pervasive laziness of Scala causing trouble because some libraries weren't crafted with this in mind and turned out to be a real pain to those trying to use lazyness. Trying to be exception-free on C++ is also difficult. Working on more than one paradigm looks appealing but in the end you'r bound to the each library writter's choice. Don't know if that's the case on CLISP.

    Haskell's FFI is a nice feature. I should take a look on it. I've spent some years doing C programming for personal projects. If the FFI turns out to be easy to use, Haskell/C will probably be my bet.


  9. Hi, I deeply understand your worry and thought when choosing a language. I am using haskell in the field nobody uses it.
    Some years ago, I got to fall in love with haskell and so I tried to do my work with haskell. Every night I thought about whether this was right way, whether I should return to C++ (which is most popular in my field.) In the end, I think choosing haskell turned out an excellent choice and I got lots of productivity boost.

    Specifically, I developed “hoodle,” a pen note-taking program in haskell. see http://ianwookim.org/hoodle Everyone says that building a GUI app in haskell is not a right choice of language. If I follow common wisdom, I would not try to do that. But I just made it and it performs well. Needless to say, there are many missing things and so sometimes I need to make it, and sometimes I need to circumvent, but usually that was not very formidable as I worried before trying to solve in most cases. If you miss some features in openGL binding in haskell, I don't think it's very hard to make that missing part by yourself (any way, knowing how to deal with FFI is just necessary in any language). For any langauge you choose, you will find some glitch and missing features. For me, now I cannot imagine my life without parsec library, so I would regret my decision immediately if I choose different language than haskell.

    I think you just had better follow where your love goes and deal with the problems you encounter. Of course, unless there exist some real constraints. (like development in iOS devices or so.)


  10. Hi Thiago,

    When it comes to game development, I think four languages can compete (if we put aside HTML5/Javascript games):
    – C++
    – JVM languages
    – Haskell
    – Common Lisp (and maybe Racket)

    First, C++. Well it's obvious, every single game studio uses it, so a lot of libraries are available for it, and its position is not subject to debate.
    Then Java. Pretty much for the same reasons: Java is used for game development, notably for Android. So libraries exist, and nice languages to use them (Clojure/Scala) also.
    Now the two “outsiders”:
    Haskell and Common Lisp. Both have same advantages: extremely high-level, with an easy-to-use interface to call C functions. No game libraries to use? No problem! I'll make my graphics code in C/OpenGL and bind it to Haskell!

    I don't think I teach you something if I say that OpenGL development will _always_ be a pain. Reusing what exists in low-level languages (C/C++) — should that be libraries or just tutorials –, designing their interface to be easily callable through Haskell/CLisp [*], and using an FFI like Common Lisp's or Haskell's to code the gameplay mechanics part can be an interesting solution.

    Languages like Python have the drawbacking of providing a C API that's far less convenient than Haskell's or Lisp's FFI. I haven't tried myself Ruby C API, but it didn't look very different.

    Regarding Lua, I know the language, but I've never tried tools like Boost::Lua that may help to integrate it: I used it through Haskell and I was quite nice!
    But I'm not so sure it's that much an interesting solution, as if you're ready to cope with some extra-compilations, Haskell can be a pretty damn good scripting language.
    See XMonad for an example of Haskell application “scripted” in Haskell.

    [*] For instance, Haskell's FFI limitation is that it cannot handle unboxed structures on the stack, it can only handle _pointers_ to structures. I think CFFI (Common Lisp standard FFI) doesn't have this limitation.


  11. > Don't know if that's the case on CLISP.

    You really need to learn CLISP, then. Nothing (not even Haskell) beats it when it comes to error handling, thanks to its powerful conditions/restarts system. (Conditions are more general than exceptions, their purpose is to signal that “something happens”, not necessarily to break the stack, and they enable flexible communication between the high level and the low level of your code. Classic scenario: low level signals something, mid level provides 'restarts' (alternatives, for instance for recovering), and high level calls a restart and feeds it parameters).


  12. Don't use “CLISP” to refer to Common Lisp.

    CLISP is A Lisp implementation, like a dozen others, for Common Lisp. It does not equal Common Lisp. There are other implementations. Common Lisp is usually abbreviated as CL.

    “Liberal” abbreviations like that are doomed to create confusion.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s