41–50 of 99 posts
Things I've learned from 25+ years of programming in C++ (and 5+ years of C before that): 1. not all software is about pushing and pulling to/from a database; if yours isn't, be sure you understand why that's the case. 2. "backends" (not "web backends", but the more general "where the mechanisms are") should know nothing about "frontends" (again, not web, but the more general "user interface of some kind"). This is r…
This is a hot take but: I have a growing sense that one defining feature of some software engineers is that they’re embarrassed by dense logic. I think you see this in the Java world where people seem to hide the core logic of their program amidst a dizzying array of interfaces and deep function call chains. Maybe with enough DI and whatnot, the business logic itself can melt into the structure of the program. In com…
I completely agree. Another similar issue that I see a lot in both Java and C++ codebases is "premature wrapping" of foreign APIs. Basically when building a program that has to consume a certain API that is somewhat incompatible, every single concept of this API is wrapped in a separate class before any planning, to the point each one-line procedure call turns into a 20 line class. Of course, after the wrapper is wri…
Earlier quoted context omitted.
Isn't "Design Patterns" about how to solve problems through an OOP approach, rather than about the strict benefits of OOP?
Article's stated motivation: > I'm looking to gain more confidence in my criticism and understanding of OOP. In the past, I have published multiple posts criticizing Object Oriented Programming ... I always feel this anxiety that... maybe there is such a thing as “good OOP”, maybe all the OOP code I wrote, and the OOP code I keep seeing here and there is just “incorrect OOP”. To that I'm saying read DP and critique t…
Things I've learned from 25+ years of programming in C++ (and 5+ years of C before that): 1. not all software is about pushing and pulling to/from a database; if yours isn't, be sure you understand why that's the case. 2. "backends" (not "web backends", but the more general "where the mechanisms are") should know nothing about "frontends" (again, not web, but the more general "user interface of some kind"). This is r…
This is one I constantly struggle convincing my colleagues about. It becomes much more "obvious" if you are trying to write unit tests in C++ code[1], but unit tests are a mere side benefit. It's more about reducing coupling.
Currently working on a code base that outputs to an Excel file. We recently started dealing with more data than the Excel file can handle easily, and the system came to a crawl. So we had to allow for the option to output to CSV (easily 100x faster in our use cases). At least now some of my colleagues have a bit of appreciation on what I've been harping on.
The Excel library is still intrinsically tied to much of our code. We've been getting over 15GB RAM usage for data that I'm sure would not take more than 2GB if we manage to bypass the Excel library.
[1] Why does my class that computes X need to know that something called email exists? So to write a test for this class I need to instantiate a whole other set of classes just for output? Just have it "ReportMessage" on the Reporter interface and let whatever class that inherits from it figure decide if the message will go out via email or SMS.
This is a hot take but: I have a growing sense that one defining feature of some software engineers is that they’re embarrassed by dense logic. I think you see this in the Java world where people seem to hide the core logic of their program amidst a dizzying array of interfaces and deep function call chains. Maybe with enough DI and whatnot, the business logic itself can melt into the structure of the program. In com…
That said, I've also seen "object-oriented obfuscation" in C, so some people seem to just love complexity and writing tons of code to do a simple task, or were taught "abstraction is great, use as much of it as you can" and never thought about when to stop.
Overabstraction usually increases macro-complexity while decreasing micro-complexity; a function with a single line of code is "simpler" in that its immediate purpose may become obvious, but having to mentally stack from its callers means that the big picture is harder to comprehend.
At the extreme high end of density are languages like the APL family, where the density is so high that the "big picture" becomes a slightly smaller one, and Arthur Whitney has been famously quoted as hating scrolling; but at that density, you can no longer "skim" large portions of code --- instead, each individual character needs to be read and pondered carefully, because each one says a lot.
The part about data is interesting. I remember than in Clean Code, Robert Martin made the distinction between "data structures" (objects that have lots of parameters, few functions) and "objects" (objects that don't have many parameters, lots of functions). The author seems to have rediscovered this distinction here. If people keep rediscovering it, maybe an object is a too abstract building block? Maybe languages sh…
Java offers Records now, which are pretty much that. Pretty cool feature IMO: https://docs.oracle.com/en/java/javase/14/language/records.h...
Earlier quoted context omitted.
I completely agree. Another similar issue that I see a lot in both Java and C++ codebases is "premature wrapping" of foreign APIs. Basically when building a program that has to consume a certain API that is somewhat incompatible, every single concept of this API is wrapped in a separate class before any planning, to the point each one-line procedure call turns into a 20 line class. Of course, after the wrapper is wri…
Ugh same. Very common that I get slightly irritated by folks who blindly wrap something with no real reason other than "somebody else wrapped something similar so I'll wrap this for consistancy". Too many juniors thinking that they need more files/PR due to impostor syndrome...
Most of those never really produce a game, since the authors know how to wrap the libraries, but the engines don't have enough substance to help making a real game.
A notable exception however is Casey Muratori (of Handmade Hero), who actually skipped the wrapping and went for a more direct code. Interestingly he has a nice inversion of control architecture.
Things I've learned from 25+ years of programming in C++ (and 5+ years of C before that): 1. not all software is about pushing and pulling to/from a database; if yours isn't, be sure you understand why that's the case. 2. "backends" (not "web backends", but the more general "where the mechanisms are") should know nothing about "frontends" (again, not web, but the more general "user interface of some kind"). This is r…
> That discovery blew my mind initially. I panicked. “OMG, is this the secret sauce? Is the joke on me? Not only is that not the secret sauce, an OOP program with almost nothing but methods that return nothing (i.e. have some effect without reporting a result), is a giant red idiot flag.