There's also the old story about how memory leaks on missiles don't matter as long as you're leaking slow enough to not run out of memory before they explode.

I worked with a guy — he's long deceased — whose doctoral dissertation was for missile guidance systems back in the 60s. The title was something like "supersonic ballistic landing trajectories for light civilian aircraft"; since, obviously, he couldn't publish it as "... for ICBMs".

He was probably right. When I write small, short-lived programs I mind my memory because it's a muscle I need to retain and I don't want to pick up bad habits.

For an academic writing a one-off program just to get something done, all manner of bad practice is if not desirable, at least acceptable.

My economics-studying roommate had an optimization problem that required a lot of RAM. He had 32 GB (that was >10 years ago). His program crashed with an out of memory exception. He was rich enough to simply upgrade his system to 64 GB.

To my CS eyes, this sounded weird. Turns out he was initializing arrays manually instead of in a loop, so the compiler didn't recognize possible optimizations in the program. I changed his program and it ran twice as fast in half the memory. But he had already fixed his problem without 2 years of studying CS.

Software is about solving problems. Professors in particular have exams, staff, their own work, student requests, external mail and international collaboration to worry about. I bet that once the program stops working, he'll make a student fix the problem within 3 weeks. That's a fine approach and way better than learning C++ yourself.

It's a good example and I think it generalizes. For instance, I'm capable of some minor repairs for appliances, but if some problem seems to be contained in the PCB and I can just replace it for $50 (or whatever) I'll just do that. I don't own an oscilloscope and only barely know how to use it--so yes, I'm sure I've spent $50 when I could have just desoldered some 25 cent part, but it's far more costly for me to learn how to diagnose and fix these sorts of problems than to just buy my way out.

I learned how to do one profession to a high standard and maybe aspects of some others to a lesser standard, but it's just smart to be mindful of how we want to spend our limited skill-development budget.

That is true, but then if you need to debug some memory usage or a memory leak, you have to wade through all the valgrind false positives due to people not bothering to clean up at the end of the program.

About 24 years ago I built a webmail service based on C++ cgi's. FastCGI existed, but that required perfect memory management. CGI let us do what your instructor did, and on one hand it saved us from dealing with leaks at all, and on the other it reduced the performance overhead of going for CGIs - much faster to deallocate the whole heap in one go.

We'd manually deallocate particularly big allocations, but otherwise we knew the process would die within fractions of a second anyway, so the increased memory use was fairly limited.

We served a couple of million users with that using servers with a combined capacity lower than my current desktop.

C++ with CGI is weirdly like a fast PHP with the same teardown/clean slate property.

It got surprisingly fast actually. We also did things like statically link it which drove the overhead of restarting down further (when the dynamic linker is a measurable proportion of your total execution time....), and I really liked knowing we had a fully clean slate on every request.

I mostly do Ruby these days, and the one thing I strongly dislike is the horribly slow startup...