Articles

Language Complexity?

Some languages are complex, others are simple … right?  C++ versus just about anything else is a good example here.  But, it begs the question: what makes a language complex?

So, I’ve just been reading Bruce Eckel’s Artima article on Scala.  It’s actually a nice article, and I enjoyed it.  But, one thing bugged me — and, it’s nicely summarised in this quote:

But you can see from the code above that learning Scala should be a lot easier than learning Java! There’s none of the horrible Java ceremony necessary just to write “Hello, world!” — in Scala you can actually create a one-line script …

Somehow, that’s not the impression of Scala I get from the article.  It’s almost as if removing public static void makes a language easy. I don’t think ceremony has much to do with what makes a language simple or not. Sure, it reduces the amount of finger typing, but that’s something quite different.

From my perspective, a language is easy to work with if there is a clear mental model behind it.  This is something one can draw upon to understand why certain constructs exist, and when they should be used.  Take the idea of traits as covered by Bruce:

We can also mix in behavior using traits. A trait is much like an interface, except that traits can contain method definitions, which can then be combined when creating a class.

This is not helping me to understand what traits really are.  The questions are: why would I use them? when does it make sense to use them? when does it not make sense to use them? Now, I’m not trying to argue that traits are (or are not) a complex feature.  The point is: this explanation does not lead me to conclude that they are “simple”.  That’s because it doesn’t give any insight into the mental model behind them.

Teaching students how to program is a good way to pick up on what concepts are difficult.  To get them to really understand something, you need to build up a mental model. For example, in explaining references/pointers, the old boxes-and-arrows diagram goes a long way.  In Java, however, there are a number of thorny issues:

  • Subtyping.  Understanding when subtyping does or does not apply is a challenge.  Sure, students can memorise the subtype relation for primitives, and you can say “if A extends B then A is a subtype of B”, etc.  But, this doesn’t help construct a mental model of what subtyping is and what it’s for.  For primitives, we have a nice rule-of-thumb: a numeric type T1 can flow into another T2 provided there’s no loss of precision (of course, this isn’t always true though).  But, what’s the mental model here?  Well, the first question that comes out is: why do different types (e.g. short versus int) have different ranges? Unfortunately, this only really makes sense to students who already understand binary representation of numbers!  For objects, you start with a model of static versus dynamic (i.e. runtime) type which, for the most part, I think is easy enough.
  • Dynamic Dispatch.  Given an inheritance hierarchy, understanding which method will be invoked in a given situation is a struggle for many.  This is compounded by the fact that it’s very difficult to give precise rules about it (i.e. have you read the JLS on this topic recently?).  To build a mental model you need to talk about method signatures, static and dynamic types, etc.  Up to a point, it’s not too bad.  But, then throw in generics + erasure and the mental model really starts to get complicated …
  • Interfaces vs Abstract Classes. This is another classic although, again, at least there’s an easy rule-of-thumb: prefer interfaces and use abstract classes only for code reuse.  But, what’s the mental model behind this?  Well, students typically start out with the question: why can you only extend one class? From there, things can quickly get out of hand as you explain the pitfalls of multiple inheritance …

(As I’m sure you know, there are plenty of other interesting examples in Java that we could talk about here)

Anyway, that’s my 2c on language complexity …

9 comments to Language Complexity?

  • Ah! That’s an excellent post Dave. If reducing program size were the only component of language simplicity then we could just design a language X whos syntax is the gzipped form of Lisp/Java/C/etc. :p

    I thoroughly agree that understanding a feature in a programming language is more than knowing its syntax and semantics, it’s also about knowing what it’s for.

  • asi

    As a mediocre programmer I think form is important in a language, specially when I’m seeing the first time, or revisiting a after a long period. I used to dominate Java when I’ve met it, now after some years without using it, it just scares me away for some reason.

  • Hey Ed — Glad you liked it!

    Dave

  • I was interviewed once, and I ended up discussing with one of the people the differences between static and dynamically typed programming languages. This of course being after his initial shock of my being fluent in C. He told me something along the lines of “An idiot can do basic programming in a statically typed language. It takes an articulate person to really be able to grasp dynamic languages.” I disagreed with him then, and I do somewhat now, (as I have a lot more experience with dynamic languages, specifically python, since then). But I think that what we can take away from it is that you are right sir. Vebrocity does not add complexity. Just wanted to point that out.

  • Good post. I think Groovy fits in the breach you describe. It cetainly reduces finger typing, but it’s by no means a simple language.

    There’s an additional point to be made, I believe. Namely that virtually no information (either about syntax or complexity) is usefully illustrated by the ‘hello, world’ example. While most people recognize this (and I’m sure Eckel does too), they seem unable to stop themselves from trotting it out.

  • Yeah, Groovy is very interesting. I like that there’s a typed version as well (Groovy++).

  • Curtis Stanford

    I’ve looked at a LOT of JVM languages (and even thought about writing my own). Whiley has banished that thought from my mind. I really like where you’re going with this. Can’t wait to use it in a project. Are there any plans for IDE support?

    I’m not sure how you’re doing the list/set/map value copying but have you looked at Clojure’s persistent data structures?

  • Hey Curtis,

    So, yes, there are plans for IDE support. Initially, probably only an Eclipse plugin. I have modes for vi and emacs as well already …

    Not sure how long it will take to get the plugin up and running … by all accounts writing an Eclipse plugin is a challenge so it’ll be interesting to see how I go!!!

  • Jon

    I really enjoyed this article and found it to be very much inline with what I have felt about Scala. Coming from the .Net world (and being forced to learn Java in school), I have had some issues with the documentation on Scala’s website and the getting started (Traits and Mixins are one of those things I’ve struggled with) and it is precisely because of the lack of “mental model” as you said. Good work!

Leave a Reply

 

 

 

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>