The memory safety problem isn't bad coders
1–10 of 225 posts
Re: The memory safety problem isn't bad coders
#2TL;DR: "[Coding perfectly and anticipating any possible change to how the tools work] are not reasonable expectations of a human being. We need languages with guard rails to protect against these kinds of errors."
I definitely agree with this. And it also applies to a lot more than what the article is focused on (low-level security). It seems that right now the entire programming ecosystem seems to jump to "you just don't understand it" rather than "this should be more intuitive, or at least safer by design."
Re: The memory safety problem isn't bad coders
#3As a python user I understand the need for better invariant checking, but should it be encoded in types, contracts or conventions?
Re: The memory safety problem isn't bad coders
#4I can see how this article might be comforting for some, but "bad coders" is still a problem. There are a lot of amateurs in this industry (even ones with years of "experience").
You can create an extremely opinionated language which doesn't give any freedom for creativity, solutions and expression, and devs will still find a way to duck everything up.
IMHO, OP saw a problem but didn't arrive to the right solution.
Re: The memory safety problem isn't bad coders
#5The main problem is that being secure doesn't increase the revenue of companies substantially, otherwise C/C++ programs would be rushing to Rust. Still, the speed of improvement is great.
I'd love to see Firefox take over Chrome in speed and show that C++ is getting closer to being an outdated language.
Re: The memory safety problem isn't bad coders
#6I 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 implications of everything for us to hold them all in mind at once. The very best coders miss things all the time.
Instead of seatbelts, I would compare tool assistance to aviation instruments. It's not primarily something that just catches you before a disaster; it's something that helps you make the most effective use of your mental resources. We don't ask pilots to fly commercial airliners without advanced software and dozens of readouts and displays to guide their attention and decision-making in an overwhelming sea of information. We shouldn't expect the same of programmers.
Re: The memory safety problem isn't bad coders
#7TL;DR: "[Coding perfectly and anticipating any possible change to how the tools work] are not reasonable expectations of a human being. We need languages with guard rails to protect against these kinds of errors." I definitely agree with this. And it also applies to a lot more than what the article is focused on (low-level security). It seems that right now the entire programming ecosystem seems to jump to "you just…
There are several quasi-related variations. Arguments against higher level languages and abstractions.
Examples:
If you have to use a garbage collected language (eg, just about any modern language) it's because you're too stupid to know how to manage memory properly.
[ various arguments against type safe languages, turning runtime errors into compile time errors ]
Higher level languages and abstractions are just bloat. [or are too bloated, etc]
Managed language runtime systems are too [ big | expensive | bloated | slow ] etc. (eg, the Java runtime, or .NET runtime, to a degree also Python, JavaScript, Lisp(s), etc)
Counter arguments:
Any sufficiently complex program will need the managed runtime, garbage collection, abstractions, type safety, etc.
Greenspun's tenth rule: (https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule)
Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
We could just write everything in assembly language, er, . . . um . . no, in hex code. And key it into the front of the machine on toggle switches with blinking lights. We could! Yes, really! So why aren't we? Why isn't, say, LibreOffice written in assembly language?
I use high level languages, runtime systems, GC, etc because I'm not optimizing for cpu cycles and bytes. I'm optimizing for DOLLARS. A long time ago, in a galaxy far, far away, computer hardware was the most expensive resource. Today developer time is the most expensive resource. Everybody is happy to have their word processor upgrade a year sooner even if it means it uses a mere extra 500 MB of memory.
Re: The memory safety problem isn't bad coders
#8I can see how this article might be comforting for some, but "bad coders" is still a problem. There are a lot of amateurs in this industry (even ones with years of "experience"). You can create an extremely opinionated language which doesn't give any freedom for creativity, solutions and expression, and devs will still find a way to duck everything up. IMHO, OP saw a problem but didn't arrive to the right solution.
The two factors are equally important; it's just that in certain circles, tooling and language assistance are undervalued and already-good programmers are told to "just get good".
Re: The memory safety problem isn't bad coders
#9In general, in favor of as many correctness and other checks at compile time as possible. Make tools as powerful as possible. I really liked this tweet:
"What if...
- your programming language required you to write useful docs,
- using those docs, it checked your program for mistakes,
- it even used the docs to speed up your program,
- this feature already exists!
And what if it was called static typing."
Re: The memory safety problem isn't bad coders
#10I can see how this article might be comforting for some, but "bad coders" is still a problem. There are a lot of amateurs in this industry (even ones with years of "experience"). You can create an extremely opinionated language which doesn't give any freedom for creativity, solutions and expression, and devs will still find a way to duck everything up. IMHO, OP saw a problem but didn't arrive to the right solution.
It's good to have bad coders. Not everybody can have an exceptional IQ.
Not everybody can be good, but everybody deserves a chance to be a coder. There are real problems that can be solved by a bad coder as well, that may help your life some day. Great coders are needed for large, scalable, hard problems, but there are little things they don't have time to work on.