What programming language do you think in?

cobol

Your thoughts are limited by your vocabulary. When I’m extremely pissed, sometimes English just won’t cut it and I wish I could express my anger in a Germanic tongue. Those who are fluent in multiple languages are able to formulate some really expansive thoughts.

I always wish I had taken the time to learn more languages when I was younger. My dad tried to teach me Japanese and my boyfriend tried to teach me Dutch, but I only learned enough of each to insult one’s mother before getting bored and moving on.

I now try to compensate by learning more programming languages. Each language has its best practices and boundaries. Some ideas are prohibitive in one language but frictionless to express in others. As a result, programmers of a given language will approach problems with the mindset they’ve become accustomed to.

C++ requires programmers to be thoughtful whereas Python encourages hacking. Lisp makes programmers feel like God. Perl is useful if you’re trying to throw off Chinese spies. I formulate my thoughts in Python but I wish I could think more like Lisp. Lately I have been forced to think in Java and it might be making me retarded.

I created a collection of minimum spanning tree solvers (Kruskal’s Algorithm) in 8 programming languages. I present each one as an image to visualize what a language looks like to a non-native speaker.

I gave everyone the benefit of predefined set operations.
I gave everyone the benefit of predefined set operators.

A more rational programmer might compare run time and compile time. But processors are fast enough already. If I’m staring at code 12 hours a day, I want it to be beautiful, because ultimately that’s what my thoughts will look like.

See also:
If programming languages were cars

7 thoughts on “What programming language do you think in?

  1. I don’t think it’s Java itself that rots the brain, but I do think IDEs should come with a health warning – specifically their autocomplete functionality. The reason they’re popular is that they make it quicker to churn out code – the programmer isn’t slowed down by having to do so much typing. The reason they’re bad is that slowing a programmer down gives them time to think – and in my book having programmers think about what they’re doing is generally a good thing.

    My personal opinion is that the visual appearance of code in a particular language is important, but isn’t the most important thing about that language. (Oh, and if you’re really spending 12 hours a day staring at code, then stop. Go outside and look at the clouds in the sky. They’re really cool.) To me, two of the key aspects to consider in a language are what it considers to be a “typical” problem, and what rhythm of development it promotes.

    The latter tends to be a bit more obvious – e.g. languages that require a long compilation step tend to discourage doing development via small experiments.

    The former is interesting because it tends to be more invisible, and can be more associated with the culture of a programming language as its technical features: I remember seeing an argument between a C# and a C programmer, one of whom insisted that ‘most’ programmers did database-backed websites, and the other insisted that ‘most’ programmers worked in embedded systems!

    I can’t make any suggestions on how to think more lispishly, but if you ever wanted to add Prolog to your list then I’d highly recommend “Clause and effect: Prolog programming for the working programmer” by William Clocksin – it’s what “The Little Schemer” should have been, but wasn’t.

Leave a Reply