Comment by WalterBright
2 days ago
These days, the bugs I generate in my own code are rarely programming errors. They're misunderstandings of the problem I am trying to solve, or misunderstandings of how to fit it into the rest of the (very complex) code.
For example, I cannot even recall the last time I had a double-free bug, though I used to do it often enough.
The emphasis for me is on a language that makes it easy to express algorithms.
> For example, I cannot even recall the last time I had a double-free bug
Honestly, it's not the double-frees I worry about, since even in a language like C where you have no aids to avoid it, the natural structure of programs tends to give good guidance on who is supposed to free an object (and if it's unclear, risking a memory leak is the safer alternative).
It's the use-after-free I worry about, because this can come about when you have a data structure that hands out a pointer to an element that becomes invalid by some concurrent but unrelated modification to that data structure. That's where having the compiler bonk me on the head for my stupidity is really useful.
+1 I’ve really enjoyed using more declarative languages in recent years.
At work I’ve been helping push “use SQL with the best practices we learned from C++ and Java development” and it’s been working well.
It’s identical to your point. We no longer need to care about pointers. We need to care about defining the algorithms and parallel processing (multi-threaded and/or multi-node).
Fun fact: even porting optimized C++ to SQL has resulted in performance improvements.