The problem often is needing to fight with less technical higher-ups for adequate time and resources for tooling/testing/infrastructure work.
The memory safety problem isn't bad coders
61–70 of 225 posts
Re: The memory safety problem isn't bad coders
#62You shouldn’t rely on your tools protecting you because they won’t. I do part time work as an external examiner, sometimes for first year CS students, so I get to see a lot of silly code. Like the result of having been tasked with doing Fibonacci recursively. Which, as most of you no doubt are aware, can be done correctly in several different ways. The most basic is to simply implement it with its two base cases and…
| You shouldn’t rely on your tools protecting you because they won’t.
Strong agree. It's like when your toilet overflows and instead of using a plunger (because sometimes this causes a splash that will get on your shoes) you just reach in with your bare hands. I've used this technique hundreds of times and I've never gotten any toilet water splashes on my shoes.
[I get what you're trying to say, but it doesn't come off very well. All things being equal, tools are better than not tools. Being able to think and having tools is better yet, but why not give people tools if there are other options.]
Re: The memory safety problem isn't bad coders
#63You shouldn’t rely on your tools protecting you because they won’t. I do part time work as an external examiner, sometimes for first year CS students, so I get to see a lot of silly code. Like the result of having been tasked with doing Fibonacci recursively. Which, as most of you no doubt are aware, can be done correctly in several different ways. The most basic is to simply implement it with its two base cases and…
I don't really understand how this is relevant.
Sure, memoization is more efficient for recursive fibonacci, but in both cases the code is correct.
The author is presenting a case in which code is made demonstrably incorrect by seemingly unrelated changes, because those changes altered invariants about the objects the author was using - making his assumptions about which actions were safe incorrect.
That's a good time for tooling to throw warnings/errors. Where you seem to be proposing... nothing?
Re: The memory safety problem isn't bad coders
#64I remember when I first added ESLint to our large JavaScript codebase, and then again when I added Flow. I'm a perfectionist when I code, but it was shocking to see some of the things I'd written. Mistakes that I thought were so unlike me, but had been sitting there for months anyway, waiting to blow up. The human brain wasn't designed to handle the complexity of large codebases. There are just too many compounding i…
The comparison with aviation instruments is apt: I remember seeing a TV special that talked about how in the early days of aviation (circa WWI) the pilots' culture of seat-of-the-pants flying and bravado was resistant to suggestions that human senses are just not equipped to differentiate between certain inertial reference frames, of which one leads to getting into a death-spiral.
It was not until an early aviation safety pioneer came up with a demonstration on the ground (something like a spinning chair and blindfold - I forget the details) that pilots who went through the demonstration were shocked to discover they "fell for" the physical illusion they believed they were immune to.
I feel like programming is in the same state today. Especially the more C/C++ code I see in my career: I'm absolutely convinced humans should just not expected to manually manage some of the things they try to do now.
Re: The memory safety problem isn't bad coders
#65Earlier quoted context omitted.
> This is a very basic example, but most students solve it the inefficient way, but in most situations you’d really rather have the ones who did it better. I would much rather have the student who solves it the inefficient way but who runs a profiler on their code with a real-world input, determines that their naive algorithm is unacceptably slow for certain inputs, and makes an adjustment to optimize it. If I'm only…
My response would be “just use a loop and get it done so we can move onto the next task”. There are only two pieces of state here. Let’s not drag out the big guns and make something hard to read. Fibonacci is too simple a case to demonstrate the power of recursion, and people have beef with the textbook examples. It has a confounding factors that actually makes recursion an over complicated solution, and not enough f…
Exactly. It's like a golden opportunity for me to demonstrate some engineering chops and instead the interviewer expects me to just whip out some caching implementation for some nebulous reason because that's what they would have done. If there's a real problem with either of our naive implementations the proper thing to do is to tell us what the problem is and leave us free to solve it.
Re: The memory safety problem isn't bad coders
#66I remember when I first added ESLint to our large JavaScript codebase, and then again when I added Flow. I'm a perfectionist when I code, but it was shocking to see some of the things I'd written. Mistakes that I thought were so unlike me, but had been sitting there for months anyway, waiting to blow up. The human brain wasn't designed to handle the complexity of large codebases. There are just too many compounding i…
"The human brain wasn't designed to handle the complexity of large codebases."
Because I'm a very simple bear, I always try to find the most simple thing that works. Because I'm certain that the next programmer that comes along, which is most likely future me, will see my efforts and think "WTF?!"
Another facet is our human mind's propensity to make errors. Instead of blaming stupid users, just deal with it. Design artifacts and systems which prohibit errors.
FWIW, Donald Norman's book Design of Everyday Things completed my transformation from technophile to humanist. (I don't know how well it's held up since. Or what knowledge now supersedes it.)
"I would compare tool assistance to aviation instruments."
Great analogy. Many, many designers (of APIs, frameworks, UIs, simulations) conflate abstractions with mental models. Our tools should make the underlying systems obvious, vs trying to hide the complexity. And if something remains too complex to explain, try again, until a mental model that is simple and obvious is found.
Re: The memory safety problem isn't bad coders
#67Earlier quoted context omitted.
I don't really use auto unless I'm interfacing with some templatized nightmare body of code where the typename is very difficult for my tiny human brain to interpret. Using "auto" is usually a code smell, because it means your type system is too complex for you to reason about.
Not necessarily. The types may just have very long names. In C++ for iterating through STL container auto is a godsend. The types are very straightforward and easy to reason about but just long. for (auto it = s.begin(); it != s.end(); it++) { is much easier to write than for (vector ::iterator it = s.begin(); it!=s.end(); it++) {
I try to avoid using STL because it A) throws exceptions, B) has really convoluted type names, and C) dynamically allocates memory. These are all things you avoid in the embedded space.
Re: The memory safety problem isn't bad coders
#68[deleted]
Re: The memory safety problem isn't bad coders
#69I remember when I first added ESLint to our large JavaScript codebase, and then again when I added Flow. I'm a perfectionist when I code, but it was shocking to see some of the things I'd written. Mistakes that I thought were so unlike me, but had been sitting there for months anyway, waiting to blow up. The human brain wasn't designed to handle the complexity of large codebases. There are just too many compounding i…
The comparison with aviation instruments is apt: I remember seeing a TV special that talked about how in the early days of aviation (circa WWI) the pilots' culture of seat-of-the-pants flying and bravado was resistant to suggestions that human senses are just not equipped to differentiate between certain inertial reference frames, of which one leads to getting into a death-spiral. It was not until an early aviation s…
C/C++, and in many cases Lisp, seem to be the most entrenched communities when it comes to the "culture of seat-of-the-pants flying and bravado". For contrast, JavaScript has as much flexibility and nearly as many foot-guns as those languages, but its community has been much more receptive to safety rails and static analysis. (Hopefully this doesn't start a flame-war; that isn't my intention)
Re: The memory safety problem isn't bad coders
#70What is it with these people and controlling the choices of other, quite possibly more experienced, programmers?
Why is it not enough to offer better tools and let the rest take care of itself? Or to solve problems using a tool that fits your way of thinking? Why do you need a cult/marketing effort if the language is as good as it claims to be?
The more of this bullshit I'm confronted with, the less inclined I am to ever let Rust slip into a project I'm involved in.