- cross-posted to:
- aicompanions@lemmy.world
- cross-posted to:
- aicompanions@lemmy.world
A person I watch frequently gave me this gem. Please forgive the annoying thumbnail.
A person I watch frequently gave me this gem. Please forgive the annoying thumbnail.
Manual memory management has about as much applicability these days as assembler did back when I was doing my degree. It should be covered as part of learning How Things Work Under the Hood, it’s still needed for some kinds of specialist work, but many—perhaps even the majority of—people writing code will never need to deal with it in the real world, because the languages in which most code is written these days all have some form of memory management.
There is still an enormous amount of C++ code still in use (and other unsafe languages for that matter). It is still an actively developed and used language, and likely will be for many years to come. Having at least a basic grounding in it is very valuable element of flexibility for any potential programmer, as well as an understanding of the underlying concepts.
Yes, there is C++ code still being written, and it’s a reasonable choice for some lower-level and complex code , but it’s a much smaller percentage of the whole than it was even ten years ago. Web stack stuff tends to be written in memory-managed languages, and it probably accounts for more lines of new code than anything else these days (note that I didn’t specify good code). You can have a whole career without ever getting down into the weeds.
Similarly, assembler still had some practical applications in games and video codecs when I got out of school. These days, I wouldn’t expect to see hand-written assembler outside of an OS kernel or other specialized low-level use. It’s still not gone, but it’s been gradually going for many years now. Languages without memory management likely never will completely disappear, and they have massive inertia because of the sheer number of C utility libraries lying around, but they’re gradually becoming more marginalized.
What it comes down to is: understanding how memory works is useful and broadening for someone who wants to program, but it’s no longer necessary even for a professional. (I think we’re mostly in agreement on everything except relative importance, in other words.)
Memory unsafe languages will always have value in applications where speed and performance mean anything. Embedded programming and video games are the obvious examples, but pretty much any application taken far enough will eventually demand the performance benefits of memory unsafe languages. Some even require writing assembly directly. Contrary to common dogma, the compiler isn’t always best.
I love how you two seem to be arguing or trying to win over each other in some way, whereas you are in fact in agreement, just coming from opposite sides.
Yeah, but that doesn’t mean you should allocate a billion arrays just because the memory is managed for you. It’s still inefficient.
You don’t need to understand the details of how memory is allocated to understand that taking up too much space is bad, and that there’s often a tradeoff between programmer time, machine execution time, and memory allocated, though.
Hmmm.
You’re probably right. But to any student reading this I’d say you’re likely to become a significantly stronger programmer, and thus find it easier to find employment, if you understand and feel comfortable knowing how to use a memory-unsafe language. Eventually you’ll arrive up in a problem that’s caused by it, or a required optimisation that benefits from manual memory management. If you want to work in games, too, there really is no other option.
In that sense it’s the same as assembler. One day you’ll sit there and not understand why something breaks only to realise that the underlying assembler doesn’t quite do what the source alludes to.
So, I’m not sure you need it, but I’m pretty sure you’ll benefit from it.