One of the things I'm learning away from is "magic". Magic methods, reflection, and configuration with code (JS world, Gradle). Especially when such magic is powering conventions. The only exception is lisp macro as it's mostly code that produce code with a simple mechanism: quoting.

IDEs are places you'll find such magic. To write a simple mobile app, you'll need GBs of SDK because they couldn't bother coming up with a simple solution first.

Sometimes all I log in for is to upvote the underdog.

I hope people are not dismayed because because they know different microprocessors actually do require different machine code. They've got to look deeper than that :\

As an ex-CEO myself I do appreciate a good executive overview without getting into every little bit & byte ;)

Fortunately it was good to learn from a time when you could expect every dissimilar device to have its own unique higher-level language so you wouldn't have to do any assembly code.

This time I want people to think about what it was like when no choices appeared to be on the horizon yet.

For a while there, without a mainframe, you weren't going to have any choice of language anyway. Most of the time not even then. For early microprocessor devices (like scientific instruments), the language was part of the "firmware" in ROM. Except they didn't call it firmware yet because it was permanent and that's a lot more solid than merely firm. Everything burned into ROM at the factory really did need to reach a level of completion requiring no further updates, of course. To be worth money to begin with. That was table stakes too.

For the foreseeable future. It wasn't supposed to bother you that there were no choices of language.

Not like there was only one mandated language that everyone must adhere to all the time.

Just the opposite, you never knew what kind of syntax and logic chain you might need to get involved with before you could get a new device to fall in line.

You, the programmer, were expected to be agnostic from the get-go so you could program all kinds of equipment using whatever language each manufacturer had come up with.

Hardware can be hard, and at the beginning it was completely incapable of being agnostic itself because the demands were so great.

You were expected to be able to sit down, power up [0] and begin programming, using a particular hardware's single inbuilt language along with the reference manual for syntax, no IDE or anything.

The device as a whole was programmable in whatever language it was supplied with. Otherwise not at all.

Some people were fine only learning how to program one series of hardware device, others could program just about anything that came along. It takes all kinds.

Even if it's a high-level language, if it's the only thing you've got to work with it's by nature the "machine's code", with some of the same strengths and limitations of the unique machinecode that underlies different processor architectures when you have no choice there. If you do zoom in.

[0] No booting involved for the ones that ran from ROM, basically just initialization.

I see your Scheme.

Each passion project should be built in the language most suitable for that project, not based on love.

Im i. the P95 perpetual mid levellers, but I also dont obsess about PL (but would avoid for example a PHP or VB6 job) but yeah Go, Node, C#, Java, python, whatever!

Initial speed matters, but sustainable speed matters as well. Your choice should be based on initial speed and sustainable speed.

Initial speed matters more, but sustainable speed can't be ignored.