Change Programming Language or Human Nature

Erik Engheim
3 min readDec 9, 2020

Awesome that you wrote an IDE for the Color Computer 3. I actually had to look that one up. I don’t believe that brand was ever sold in Norway. I have never programmed 6809 assembly but I did microcontroller programming on 68HC11 in university and from what I can tell from a quick Googling they seem to share some similarities such as the registers available. Not sure how different the opcodes are.

In Norway Commodore 64 and Amiga dominated the market in the 1980s. And there was Norwegian computer brand called Tiki 100 which we had on all the schools, with the weird round orange buttons you see below.

Tiki 100 used in Norwegian education in the 1980s. Based on Z80 microprocessor.

Anyway I wasn’t trying to suggest you didn’t have experience. I was just making sure we where on the same page, because it seemed like you thought I was some kind of twenty-something JavaScript hipster. No, I am pretty old school, but I like trying out new programming languages. I don’t have high thoughts about web development or the latest development fads whether that is Scrum, Lean, Kanban, TDD, BDD or whatever. It is not that there may not be good idea there, but people seem to have a tendency to get all religious about following some ideology to the letter.

Anyway sorry I am making a big detour. Let me get to the key point.

It’s not the languages. It’s the sloppy coders trying to be clever.

The problem is that you have to deal with the programmers you have and not the ones you wish you had. There will always be sloppy coders. It is hard to change human nature. You read some old Greek story 1500 years old and you realize people have not changed that much.

It is quite an endeavor to change human nature. I think it is far easier to simply change the tools we use. I did C++ programming for many years and I was constantly frustrated by the stupid stuff people did. I noticed when learning Go, that a large chunk of the problems I had with other people’s code got eliminated with Go, simply through language design:

  1. We had insane inheritance hierarchies in C++. Problem solves in Go. There are no inheritance hierarchies. You can only implement interfaces.
  2. Circular dependencies. We had some hairy circular dependencies. Go simply makes that illegal. Problem solved.
  3. Basic stuff like strings, maps and arrays re-implemented in different ways. Forcing you to write a bunch of conversion code. Problem solves in Go as it comes with built in standards for this.
  4. Undefined static initialization and de-initialization sequence. No such thing in Go. The closest thing that exists has well defined sequence.

Of course a number of these things are actually not a problem in C either, but then again C starts to be hard to use once you build larger programs. And in particular things like GUI programming gets tricky.

There are a lot of obvious things C makes unnecessarily difficult. E.g. arrays should know their length but in C, you always have to make sure you keep track of the length separately.

Ok, I think I should call it quits there. This isn’t that big of a topic 😉

--

--

Erik Engheim
Erik Engheim

Written by Erik Engheim

Geek dad, living in Oslo, Norway with passion for UX, Julia programming, science, teaching, reading and writing.

No responses yet