Share via

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.

Comments

  • Anonymous
    August 23, 2011
    Regards the writing of C in C++, keep in mind that C++ is C and there are many cases where OO is simply the wrong hammer. Having been a C programmer from very nearly the beginning I am more guilty than most of holding on to my favorite language---that said, I also know exactly what kind of code a given sub produces under the hood and would never hesitate to pick the best one on terms of memory/speed etc.

  • Anonymous
    August 24, 2011
    Don't forget FORTH. It's definitely different.

  • Anonymous
    August 25, 2011
    This is a useless article; what's the point?

  • Anonymous
    August 25, 2011
    The comment has been removed

  • Anonymous
    August 25, 2011
    Very much so. It's vital when learning a new programming language to forget all the others you know while you're learning: just as with human languages, you only really develop a style in any given language once you stop thinking in English and trying to translate it all the time. When I first learned C, back in the days when everybody lived in the forest and nobody lived anywhere else, I spent a good couple of months saying to myself things like, "This means <that> in Algol" and so on... it was only once I let go of Algol and started to realise how low-level C could be that I grasped the kinds of things you could do with it, and actually started to like it rather than to abhor the lack of structure you could present in it if you really felt like it. At that point, I stopped trying to make C programs look like Algol programs with braces, and started writing real C programs instead. Same thing goes for JavaScript: once you realise that you're supposed to break structure and typing rules in JavaScript because therein lies the power, you begin to be able to use the thing properly. All languages have something that no other language has, and it's a question of seeing the design for what it really is, not in terms of what something else is.

  • Anonymous
    August 25, 2011
    Herb, thanks for catching the typos. No matter how much I proof I always seem to miss something.