11–20 of 91 posts
and data oriented design with SOA and deferred buffering
for games at least code needs to be highly cache friendly and dumping OOP makes it way easier to reason about program state and code flow
Anti-service oriented architecture: continually asking myself in what way could I solve a problem with less complexity, fewer dependencies, and permitting shitty solutions as long as they are vaguely adequate to customer need.
Functional programming without a doubt. And everything that elixir and Erlang drags along with it. Nothing comes close as yet in terms of what one can do this this.
Never brought any Erlang project to production, I've just toyed around with the language, but I do miss the pattern matching philosophy in the other languages that I most frequently use, that is Python and JS.
When I learned functional programming, in my head, classes suddenly became slightly worse versions of partially applied functions.
When I learned about state machines classes also now seems like a failed attempt at achieving the same thing.
The whole functional programming paradigm made a big change for me. Coming from the 90s you know, we were fed Object Oriented paradigm down the throat up to mid-2000s. If you didn't do OO on your resume, no point applying.
Then slowly the whole industry started looking at global state and considered any kind of shared state bug-prone (which it is). So Object Oriented took a big hit in the face. It wasn't the dream of reusability we were sold.
Some went ape in the functional direction and became obsessed with it. Some like me went into a more pragmatic understanding of what state is and how to keep as simple and compartmentalised as possible. So we still use OO in parts, completely avoiding inheritance if possible, using composable objects instead, with pure functions. That's another big shift I took from game development: choose composition over inheritance.
Code layout-wise, we went from hellish nightmare, to MVC, to MVP (presenters) and finally MVVM (thanks Silverlight).
Then came the reactive UIs. That's also been a big shift, but in the same direction. State is state, and the UI flows from there. As long as you don't get into a spaghetti fest of system-wide events, you're probably going to be OK.
I think we're becoming closer and closer to Model - View, with a bunch of render methods and utility methods on the side.
I'm not sure what the "next" thing is, but we seem to start to have this whole UI thing finally under control. Except tailwind, anyone in their right mind needs to see what a clusterf that is. There definitely needs to be more work done on the design-systems and CSS frameworks side, it still feels like cowboys and indians in this age. You'll see, in a year or two, a monolithic CSS will make a come back, probably partially server rendered. Anyway, this is only for the web.
As for the native stuff, I'm really digging the SwiftUI thing. It took them a while, but it's undeniably amazing to be dealing with a language that is both a rendering DSL and a statically strongly compiled language close to Rust, but very terse. If only they could fix the compiler errors... I could finally drop my deck of tarot cards.
But as far as impressive language goes, I have to give it to Swift now. As a polyglot of most (yes most) languages, Swift takes the cake. Sadly it's biased...
So to sum up? Pure functions, composition over inheritance, reactive rendering, strongly-statically type languages used for both rendering/logic that are as powerful as Rust and as terse as Python.
This sounds kind of trivial, but it entails three very useful techniques:
0. Passing strictly typed immutable data structures (i.e., DTOs) that formalize and enforce the pre- and post- conditions at each such layer of the code;
1. Dependency injecting useful resources, as opposed to keeping them inside god objects/"managers";
2. Allowing each layer to use a different programming style, quality bar, logistics etc.
One caveat: I don't think that modularizing code causes it to require fewer changes when introducing new behaviors. For example, if you add a new data field, you'll have to go through all layers. However it definitely can make each of the piecemeal changes quicker and cheaper.
Anti-service oriented architecture: continually asking myself in what way could I solve a problem with less complexity, fewer dependencies, and permitting shitty solutions as long as they are vaguely adequate to customer need.
Put the data all the way over there. Put the view all the way on the other side over there. And then start tying it togther in the middle. I was pretty young when I learnt about it, but it's been by far the most influential on me.
Also I'm not sure if this is a programming paradigm, or just good practice, but strongly typed parameters + throwing errors if they're not the right type. I thought TypeScript was the bees knees when it came along.
The single responsibility princible gives a good rule of thumb of why and where to split things up, and if you follow it, you will by design get a system which has about enough abstractions for change to be reasonably easy.