Languages That Make You Think

  • Article

The old joke used to be that “a good FORTRAN programmer can write a good FORTRAN program in any programming language.” The problem and what makes the joke not all that funny is that it involves not taking full advantage of the language in question. It is not a FORTRAN specific problem by any means. I have known many so called C++ programmers who really wrote C programs using a C++ compiler. Many programming languages are designed with an idea towards changing the way programs are written, problems are solved and how people think about problem solving.  Taking on a new programming language without  changing ones thinking is often a missed opportunity, at best, and a cause of serious problems at worst. I recently came across two posts inspired by one of  Alan Perlis's epigrams: "A language that doesn't affect the way you think about programming is not worth knowing." This comes after the same issue from a slightly different point of view.

To some extent programming languages are idiomatic. That is to saw that there are particular ways that the language should be used. While it may be possible to use it the same or similar ways to other languages, the FORTRAN program in any language way, that is not the best most efficient way to use it. To get the most out of a language you have to think a little differently. A lot of languages are pretty similar – Java and C# for example. But there are still differences. Most obviously those differences involve libraries but there are subtle differences in the languages themselves. For example Java and put and set methods which are a little different from properties which are a different form of get and set.. The thinking involved is a little bit different.

Other languages are very different. Scheme and F# are two examples of functional languages which are a completely different paradigm from languages like Java and C#. You’d really run into trouble trying to write FORTRAN programs using one of them.

Visual languages like Scratch, Alice and Kodu are different (from each other and from other more traditional languages) in still more ways. I think we often focus on simple concepts, like loops, that feel the same but miss out on different ways of thinking about things like subroutines and methods. Kodu for example uses pages in much the way that subroutines are used in other languages. They have a a different sort of feel to me though. There isn’t a traditional return statement for example. This changes things. It means that leaving a subroutine doesn’t automatically go back to where it was called from. I’m still thinking about how best to take advantage of that. I am finding that Kodu is changing the way I think about programming. This is a surprise to me but in a good way.

At the high school level there is a tendency to stick with one programming paradigm and even often a single programming language. I wonder it that is too narrow a way to teach programming. Younger students seem to adapt to different languages and paradigms faster then older students – much faster than their teachers all too often.  There isn’t a lot of room in the curriculum at most high schools to cover multiple paradigms in a single course. Over a couple of courses a school might cover a couple of languages perhaps. I recommend at least two and would prefer three. Mostly people tend to concentrate on the similarities between languages rather than the differences. There are advantages to this. The disadvantages are less clear though but I am starting to think that there is some value in talking about the differences. A good education widens ones horizons rather than focusing too narrowly. Something to think about. You know, while we are talking about making people think. Smile

The blog posts that inspired this post are both well worth a good read.