Python and Limiting Programming Languages
21 January 2021

This year I am adding restrictions on myself in order to free up cognitive space to learn/make other things.

On limitation if have a small list of programming languages I will allow myself to use. C and C++ are already on the list but I have been searching around for a dynamically typed language. Over the past year I have written code in Lisp, Ruby and more recently Python.

I admit to having trouble with Python mostly because I sometimes find it a little dull to code in. Usually I see this as a positive but in the past I found it sapped motivation.

After watching some George Hotz streams I started to realise I was probably using it wrong and should reconsider it. After writing a Pratt parser, messing with Pygame and looking at Nuitka it seems to hit all my requirements.

Python is going to be a tool for learning and maybe other stuff. If I hit some graphics learning then I may use C/C++. After re-reading fluent python I feel reasonably set to start to use it in anger.

## Why limit the number of programming languages?

At a certain level it doesn't make much sense, if programming languages are tools pick the right tool for the job?

While I agree with that sentiment, the reality is there is a start up cost to using a new language. So flipping around is not always a good idea.

Programming languages are often puzzles. While trying to express in the best possible way is a good thing, it often leads to googling that in turn leads to significant lost time. In the context of at home, limited time, programming this approach makes less sense. It is why I didn't put Rust on the list.

## Why C and C++

I programming professionally in C++, as a consequence there is no at home cognitive load in holding it in my head. The dangers of C++, apart from be huge and slow to compile, is a tendency I have seen that lets you pattern match a problem onto what you have in the standard library and stopping.

From a learning perspective this is terrible. Refining the solution to the problem often lead to removing usages of the standard library. Removing std::optional by changing your data structures to be more data orientated would be a good example. Spotting objects that have the same lifetime can alter the way you architect things would be another, as the C++ standard library generally encourages each object to own it's memory. Yes this changed with PMR in C++ 17.

C kind of forces this approach. It's minimal library is not great so you don't have anything to pattern match onto. Developing the infrastructure helps to make these mental leaps.

## Safe Zone.

Learning programming languages is a safe zone for me. I know I can do it and it provides incremental increase in knowledge. My programming style is still evolving and I suspect it will not ever stop.

Did you see incremental in that sentence! When it comes to knowledge that's a scary word. How would I push my knowledge of programming languages in a non incremental way? Well I would create one, designing a language at a human level and compiling (rather than interpreting) it down to machine code.

It is on the list :)

I feel like I should expand on this but I am attempting to not blog too much on the meta side of the things I do. So it will have to wait a month or two.