Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The memory safety problem isn't bad coders

medium.com

Post reply on HN
Print view View original

111–120 of 225 posts

Re: The memory safety problem isn't bad coders

#111

Post by sgt101 »

moosey wrote: post #74
_bxg1 wrote: post #6

I 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 contrarian argumentation that I see on HN is always something to behold (I view it as a positive!). An article comes out yesterday about programmers being a problem: comment section points in another direction. An article comes out today that says that programmers aren't the main problem: comment section points out how awful all of us were, if we just go back far enough in time. My main takeaway: Programming is h…

Are you talking about monoliths vs microservices from yesterday? If so then I think that the points made are somewhat different; there is little reason to believe (that I have seen) that microservices are "better" than monoliths, but there is a lot of reason to believe that strong type systems (an other tools) provide long term benefits.

Re: The memory safety problem isn't bad coders

#112

Post by bunderbunder »

mhink wrote: post #76
wheelie_boy wrote: post #9

In 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." - https://t…

Although I mostly agree with you, it's worth noting that static typing only goes so far. When I worked in a large-scale Java codebase, it always seemed like half the code only existed in order to "work around" the type system. (Don't even get me started on Spring, which might as well be a whole additional language on TOP of the actual application code.) I'm perfectly willing to grant that might just be a Java thing,…

I am beginning to suspect that Java is almost singlehandedly responsible for the prevailing opinion that static typing doesn't do anything useful and mostly gets in the way. Which is sad, because I'm also hard-pressed to think of a worse poster child for static typing than Java. It's like a stereotypical bureaucrat, asking you to fill out a mountain of paperwork before it can proceed to do a whole lot of nothing useful.

There is better out there. Sadly, for the longest time, the best examples didn't receive much interest outside of academia, on account of languages like Java being so entrenched. But it is worth spending some time with a member of the ML family to get a taste of what static typing could have been like.

Re: The memory safety problem isn't bad coders

#113

Post by pron »

burntsushi wrote: post #99
pron wrote: post #91

Contrasting C and Rust completely misses the issue. Yes, obviously Rust will do away with some important classes of bugs and security vulnerabilities, but it's got nothing to do with addressing the problem. The problem is that there are billions of lines of C out there, and it will take many decades to replace them with software that's written in a memory-safe language. The issue is what do we do with all that existi…

No, it is the issue. Before one can even consider the proposition that it might not be wise to write X in C, you first need to convince people that the tool (that is, C) is actually a problem. That's what the OP is targeting: people think the problem isn't the tooling, but the programmer. The task of figuring out how to actually use the language is an entirely separate, though valid, problem. But it's not some giant…

But even if (assuming that safe languages have reached a point where they can be a suitable replacement to C in all circumstances, which they haven't yet) not a single new project is written in C from now on, it will take decades for our software to become more secure. The question is what do we do until then. There are some excellent tools that can be used, but aren't.

Re: The memory safety problem isn't bad coders

#114

Post by gowld »

fzeroracer wrote: post #49
tormeh wrote: post #35

Earlier quoted context omitted.

Coding is essentially a series of IQ tests. Seeing patterns easily, having lots of working memory... You're not going to be good without it. Life is unfair, and some get this given to them, and some don't. To be fair that probably partly applies to the qualities you listed as well. So it's true, IQ is not a promising quality, it's a requirement .

Is there any proof of developers having higher average IQ than other career paths or are we just assuming that because we're developers we're naturally more intelligent (with a dash of dunning-kruger for flavor).

You don't have to be dumb to stock groceries or be a line cook, but you don't have to be very smart either, and if you are smart you won't get a lot of intellectual challenge from work.

Re: The memory safety problem isn't bad coders

#115

Post by geofft »

FilterSweep wrote: post #19

> “The problem isn’t the use of a memory unsafe language, but that the programmers who wrote this code are bad.” This really goes to show how anti-worker the media is even among high-skill jobs. In my mid 20s I now mentor a bit in coding. I’ve worked with young devs that inherently know many of the obvious security pitfalls that have caused massive security breaches a la Equifax. Are devs at the front of these breach…

> This really goes to show how anti-worker the media is even among high-skill jobs.

The quote was regarding "social media" as in mostly the workers themselves, not "the media" as in the independent journalists reporting on the workers.

I think you're agreeing with the article in the end, and I also agree with it, but I'd like to note two things:

- Grueling interviews are not necessarily correlated with skill. In particular, I've done a lot of whiteboard coding and a handful of take-home exercises, and not one has anyone cared either if I was writing buffer overflows or if I was reaching to a buffer-overflow-prone style. On the whiteboard, on either side of an interview, it's generally a loose pseudocode with the understanding that errors are not to be checked, that syntax doesn't need to be exact, and the point of the exercise is not whether you had an off-by-one in a calculation. So the skills of either being awesome enough to write bug-free code in security-sensitive environments or humble enough to use tools (languages, analyzers, sandboxes, whatever) to protect yourself from inevitable mistakes are not tested at all.

- "Lack of tech talent" generally refers to the number of people being insufficient for the job, not the quality of the existing people. It is entirely possible to believe that the problems of insecure code are not a level-of-talent issue and that we still face a lack of tech talent. (I have certainly never heard it claimed that the problems we face with insecure code are that too many Americans are bad at coding and we need to hire smarter foreigners who don't write bugs.)

Re: The memory safety problem isn't bad coders

#116

Post by kelnos »

adrianmonk wrote: post #53

One thing that clouds the issue here is that it really is true that better coders do write fewer of these kinds of bugs. That's a real correlation and not a fictional thing. So I think what we need to do is acknowledge that but keep it in perspective. While better coders write fewer security bugs, even the best programmers still write some. So it can't be our only line of defense. Also, suppose for the sake of discus…

And to take it further, let's just consider that we as programmers have a lot of work to do. The current scope of "things people are writing code for" is nowhere near the total scope of possible useful things we could be working on. We want to enable more people, even if they are not "the best" programmers, to build software, safely.

People who suggest "well, just hire better programmers" are incredibly naive and probably have never actually had to deal with the challenges around hiring programmers.

Re: The memory safety problem isn't bad coders

#117

Post by burntsushi »

pron wrote: post #113
burntsushi wrote: post #99

Earlier quoted context omitted.

No, it is the issue. Before one can even consider the proposition that it might not be wise to write X in C, you first need to convince people that the tool (that is, C) is actually a problem. That's what the OP is targeting: people think the problem isn't the tooling, but the programmer. The task of figuring out how to actually use the language is an entirely separate, though valid, problem. But it's not some giant…

But even if (assuming that safe languages have reached a point where they can be a suitable replacement to C in all circumstances, which they haven't yet) not a single new project is written in C from now on, it will take decades for our software to become more secure. The question is what do we do until then. There are some excellent tools that can be used, but aren't.

Who are you arguing with? Not me, because I didn't claim otherwise. And certainly not the OP. You're missing the part where people don't even recognize the problem in the first place. You have to fix that first.

Re: The memory safety problem isn't bad coders

#118

Post by acdha »

gowld wrote: post #104
mhink wrote: post #76

Earlier quoted context omitted.

Although I mostly agree with you, it's worth noting that static typing only goes so far. When I worked in a large-scale Java codebase, it always seemed like half the code only existed in order to "work around" the type system. (Don't even get me started on Spring, which might as well be a whole additional language on TOP of the actual application code.) I'm perfectly willing to grant that might just be a Java thing,…

It seems strange to say that something (types) isn't worth anything more than nothing just because it isn't everything (complete documentation)

You should consider overhead and completeness. If people spend lots of time writing boilerplate and coding around the type system but aren't saving a corresponding amount of time, there's a fair cost to that, especially if this means end up writing different classes of bugs but not really fewer of them. (This is basically an enterprise Java bingo card)

There's a certain argument that this is the sign of an inadequate type system: you're getting the overhead but it's not rich enough to be self-documenting or provide really rich analysis tools.

Re: The memory safety problem isn't bad coders

#119

Post by [deleted] »

mort96 wrote: post #105
wheelie_boy wrote: post #9

In 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." - https://t…

Having used a bunch of libraries which seem to think that their source code with types (or auto-generated docs based on the types) is enough to be considered documentation... source code with types or auto-generated docs based on types isn't enough to be considered documentation.

[deleted]

Re: The memory safety problem isn't bad coders

#120

Post by pron »

burntsushi wrote: post #117
pron wrote: post #113

Earlier quoted context omitted.

But even if (assuming that safe languages have reached a point where they can be a suitable replacement to C in all circumstances, which they haven't yet) not a single new project is written in C from now on, it will take decades for our software to become more secure. The question is what do we do until then. There are some excellent tools that can be used, but aren't.

Who are you arguing with? Not me, because I didn't claim otherwise. And certainly not the OP. You're missing the part where people don't even recognize the problem in the first place. You have to fix that first.

I think enough people recognize the problem with C. But a rewrite is just not a relevant solution to the actual problem we're facing. It's a long-term solution, but that's not what we need now.
Post reply on HN