Programming

Until you know a few very different languages, you don't know what a good language is, so just relax on having opinions about which languages are better. You don't need those opinions. They just get in your way.

Don't even worry about what your first language is. The CS snobs used to say BASIC causes brain damage and that us '80s microcomputer kids were permanently ruined ... but that was wrong. JavaScript is fine, C# is fine ... as long as you don't stop there.

(One of my first programming languages after BASIC was ZZT-OOP, the scripting language for Tim Sweeney's first published game, back when Epic Games was called Potomac Computer Systems. It doesn't have numbers. If you want to count something, you can move objects around on the game board to count it. If ZZT-OOP doesn't cause brain damage, no language will.)

Please don't say the new language you're being asked to learn is "unintuitive". That's just a rude word for "not yet familiar to me". So what if the first language you used required curly braces, and the next one you learn doesn't? So what if type inference means that you don't have to write int on your ints? You'll get used to it.

You learned how to use curly braces, and you'll learn how to use something else too. You're smart. You can cope with indentation rules or significant capitalization or funny punctuation. The idea that some features are "unintuitive" rather than merely temporarily unfamiliar is just getting in your way.

Refactoring is something that should be constantly done in a code base, for every story. As soon as people get scared about changing things the codebase is on the road to being legacy.

My take is that no matter which language you are using, and no matter the field you work in, you will always have something to learn.

After 4 years of professional development, I rated my knowledge of C++ at 7/10. After 8 years, I rated it 4/10. After 15 years, I can confidently say 6.5/10.

Shorter code is almost always better.

Should you use a class? Should you use a Factory pattern or some other pattern? Should you reorganize your code? Whichever results in the least code is probably best.

A nice thing about code length is it's objective. We can argue all day about which design pattern makes more sense, but we can agree on which of two implementations is shorter.

It takes a damn good abstraction to beat having shorter code.

Don't be afraid to drop a tool although you've spent years mastering it if there is something new that is much more efficient. Some day you have to switch anyway.

JS is horse shit. Instead of trying to improve it or using that high level scripting language as a compilation target (wtf?!), we should deprecate it entirely and put all efforts into web assembly.

Python is only good for short programs

Most modern software is way too complex for what it actually does.

I find that S-expressions are the best syntax for programming languages. And in general infix operators are inferior to either prefix or postfix notation.

Using single character variable names is always bad practice

Composition over inheritance has become a meme that people repeat without understanding. Both have their uses, but if composition is all you use, then you're using a hammer on everything. There is no silver bullet in life and most undeniably not in programming.

Also, electron has a reason for existing. If it didn't have a use, it wouldn't have the number of users it has. You can't tell me in all seriousness that Qt, Gtk, Swing, Tkinter is easier to use than electron for the common developer.

Dynamically typed languages don’t scale. Large project bases become hard to maintain, read and refactor.

Basic type errors which should be found in compilation become runtime errors or unexpected behavior.