As a Java engineer in the web development industry for several years now, having heard multiple times that X is good because of SOLID principles or Y is bad because it breaks SOLID principles, and having to memorize the “good” ways to do everything before an interview etc, I find it harder and harder to do when I really start to dive into the real reason I’m doing something in a particular way.
One example is creating an interface for every goddamn class I make because of “loose coupling” when in reality none of these classes are ever going to have an alternative implementation.
Also the more I get into languages like Rust, the more these doubts are increasing and leading me to believe that most of it is just dogma that has gone far beyond its initial motivations and goals and is now just a mindless OOP circlejerk.
There are definitely occasions when these principles do make sense, especially in an OOP environment, and they can also make some design patterns really satisfying and easy.
What are your opinions on this?
“int” can be different widths on different platforms. If all the compilers you must compile with have standard definitions for specific widths then great use em. That hasn’t always been the case, in which case you must roll your own. I’m sure some projects did it where it was unneeded, but when you have to do it you have to do it
So show me two compatible systems where the int has different sizes.
This is folklore IMO, or incompatible anyways.
Incompatible? It is for cross platform code. Wtf are you even talking about
Okay, then give me an example where this matters. If an int hasn’t the same size, like on a Nintendo DS and Windows (wildly incompatible), I struggle to find a use case where it would help you out.
You can write code that is dependent on using a specific width of data type. You can compile code for different platforms. I have no idea what you’re thinking when you say “wildly incompatible”, but I guarantee you there is code that runs on both Nintendo DS and Windows.
Well cite me one then. I mean there are super niche stuff that could theoretically need that, but 99.99% of software didn’t, and now don’t even more. IMO.
Have you never heard of the concept of serialization? It’s weird for you to bring up the Nintendo DS and not be familiar with that, as it’s a very important topic in game development. Outside of game development, it’s used a lot in network code. Even javascript has ArrayBuffer.
I’ve personally built small homebrew projects that run on both Nintendo DS and Windows/Linux. Is that really so hard to imagine? As long as you design proper abstractions, it’s pretty straightforward.
Generally speaking, the best way to write optimal code is to understand your data first. You can’t do that if you don’t even know what format your data is in!
What on earth did you run on a DS and windows? I’m curious! BTW we used hard coded in memory structures, not serialising stuff, you’d have a hard time doing that perfectly well on the DS IMO.
Still only a small homebrew project so IMO my point still stands.
As for understanding your data, you need to know the size of the int on your system to set up the infamous INT32 to begin with!
A homebrew game, of course! Well, more like a game engine demo. Making game engines is more fun than making games.
I’m not sure why you find it so hard to believe, as it’s pretty straight-forward to build a game on top of APIs like
void DrawRectangle(...); void DrawSprite(...);Then implement them differently on each target platform.
You mean embedded binary data? That’s still serialization, except you’re using the compiler as your serializer. Modern serialization frameworks usually have a DSL that mimics C struct declarations, and it’s not a coincidence. Look up any zero-copy serialization tool and you’ll find that they’re all basically trying to accomplish the same thing: load a binary blob directly into a native C struct, but do it portably (which embedded binary data is not)
Nah, that’s what
int32_tis for. The people who built the toolchain did that for me.I’m done spending time on this. If you are so insistent on being confidently incorrect then have at it.
Lol