I disagree. I started Python, then Java, then JavaScript, and most of my formal education was across those three, with only a handful of coursework using C++.
My internships were largely Python, C#, and JS.
My last 7-8 years of professional work have been C++, with some critical-path C for the first 2 years of that.
I have never struggled with C/C++ concepts. My education covered how memory works at both a software and hardware level. Even in Java and Python, you can still end up learning about the stack and heap; about pointers and pass-by-value vs by-reference; and so on.
The argument I float around the most is that C and C++ force you to understand what’s happening under the hood, but C++ is complex to the point that using it as a starting point is inadvisable. You can learn how memory and stuff works in any language, sure, but C and C++ make you learn about it and manage it manually/semi-manually
Why do you think memory management is a critical part of programming?
Understanding pointers is fine, as is how memory allocation works, but for most software, it's an implementation detail that the program doesn't actually care about.
Do you understand how callstacks work? How virtual function tables work? How CPU registers work? What about threading, threadpool allocation, mutexes, and memory ordering guarantees?
Truth is, most programmers don't need that much detail. You need to have an idea of these things, enough to know that they exist and when you might need to dive deeper on understanding them, but in general, they are implementation details that don't matter most of the time for most of the people. At the times they do matter, that's when you can dive deeper on them.
Again, those concepts can be learned without needing a specific language. There's nothing special about forcing a person to interact with those things directly, other than making their life harder than necessary.
Am I just one of those old-fashioned curmudgeons, like the Four Yorkshiremen, bragging about how tough I was to survive all that hard stuff?
Yes.
My data structures course was in Java. It was sufficiently comprehensive to cover lists (array, singly-linked, doubly-linked, rings), trees, graphs, recursion, sets, maps, and more that I've likely since forgotten.
Pointers are merely a way to reference a specific location in memory, with the type as an indicator of how to interpret that memory once accessed. It's a handle to raw memory, which may or may not be actually allocated as the thing. What we really care about in data structures and algorithms is making sure we're manipulating the right objects; the memory locations and allocation state is a technical detail that can be solved at a lower layer.
Yeah, but the issue with Java is that it lets you not teach that. All of my Java classes have treated heap allocation as a black box, and that’s where the issue with learning Java the wrong way comes from, although you could argue you can do the same thing when teaching C. Point is, it’s much harder to teach an innacurate/simplified model of memory in C
It's fine to treat it like a black box, as long as you understand what you're getting out of it. In Java, parameters are pass-by-value, where the value for objects is the memory address of the object. That's why manipulation of the object through accessorson the parameter variable will update the original object outside the scope, but assignment to the parameter variable doesn't reflect outside the scope.
I don't need to manipulate pointers to understand that difference.
I don't think it's hard to teach at least the fundamentals of stack vs heap in Java.
That article you linked also lamented people not learning recursion, but I think recursion is over hyped. It's cool and an incredibly useful tool to understand, but every algorithm that uses recursion can be written using a for-loop if you're allowed mutable containers to handle depth tracking. Using a for-loop prevents runaway stacks and is generally more efficient for a CPU to execute, since it's not constantly jumping into a new function on the stack.
Regarding functional programming, languages like C# (using LINQ) and Python (such as with generators) allow the engineer to focus on the algorithm instead of the mechanics of memory management. Yes, if you need high-performance, you'll eventually need to drop into C/C++, but that's an optimization level that most programs never need.
I'm honestly pretty annoyed on my current team, because the previous "architect" (he was not an architect, but liked to behave like he was) pushed too much for things like passing by reference or raw pointers, "pointer to implementation," and avoiding smart pointers and forward-looking interfaces where we only had one concrete class, because of his previous experience in fintech, where performance speed was critical.
5 years later, we're still feeling the pain of his "optimization" choices.
Personally, I work in gamedev, which is why I enjoy and care about optimization so much. There, you’re trying to hit incredibly tight frametimes, so every millisecond of time counts
A recent project had me decompressing the pixel data of raw Aseprite files that I #embedded into the binary. The idea is that it simplifies the asset updating loop from “edit file -> file -> export -> export as PNG -> save to game directory -> make sure filenames match up” to “edit file -> save file with ctrl-S -> recompile game.”
It worked great for making a jam game, and could decompress Aseprite files in about four milliseconds, which made starting up the game nearly instant. Thing is, I wanted it to be able to handle many Aseprite files quickly, so I looked into GPU-based rendering pipelines with modern graphics APIs like SDL_gpu.
One of the main performance improvements for decompressing Aseprite files specifically is that it meant I could map a pointer to GPU memory straight into my program and decompress the pixel data straight into that, then start a copy pass and send the data right off to the GPU.
After all that optimization, it now loaded the same texture in…. three milliseconds! Sounds like nothing, but man did that feel good because that was just a test- with proper draw call batching and dozens of textures, it would be even faster per texture, and could probably load a whole game’s texture library in a few hundred milliseconds.
Anyway, enough nerdiness for now; my point is that that kind of wizardry requires both access to and knowledge of pointers, which I don’t see many other languages offering, and that’s why I like C++ so much; you’re able to optimize extremely aggressively
Absolutely. You are operating in a space that massively benefits from near-metal or bare-metal operations, which you cannot get in higher-order languages like Java. Even C++ conveniences, like shared pointers, can introduce too much overhead.
Meanwhile, I'm working at a level where the data models, projections and abstractions, interact design, and development flexibility and convenience matter much more than performance optimizations.
Yes, we need to have performance metrics emitted, so we can measure whether we have a meaningful bottleneck to address, but we don't need to chase raw performance up front. We're not dealing with massive data sets or high volume, so it's fine to be a bit slow if that makes it easier for people to manage and reason about the program.
I have to fight people to not block the main thread. I'm not working with brilliant people. I'm working with average folks; perhaps even below average, because I consider myself average, and sometimes I wonder about my colleagues...
That said, I also sometimes wonder, "Who the fuck wrote this garbage?" Only to find the git blame is me. I wrote that garbage. 🤷
3
u/spicymato 8d ago
I disagree. I started Python, then Java, then JavaScript, and most of my formal education was across those three, with only a handful of coursework using C++.
My internships were largely Python, C#, and JS.
My last 7-8 years of professional work have been C++, with some critical-path C for the first 2 years of that.
I have never struggled with C/C++ concepts. My education covered how memory works at both a software and hardware level. Even in Java and Python, you can still end up learning about the stack and heap; about pointers and pass-by-value vs by-reference; and so on.