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

11–20 of 225 posts

Re: The memory safety problem isn't bad coders

#11

Post by P_I_Staker »

Derek_MK wrote: post #2

TL;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…

I'm torn on this, because while we can always do better, sometimes there's things you just gotta know; this is the best we can do, so far. There's also lots of lazy programmers, that think everything should be easy and intuitive, when in reality they need to do more to understand the tools they have and hone their craft. I refuse to call them bad, because I think most people can reach expert level. Maybe not master or grandmaster, but experts would do.

Re: The memory safety problem isn't bad coders

#12

Post by Rusky »

rinchik wrote: post #4

I 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.

I don't see how the article is trying to be "comforting," or dismissing the value of skill and education. I also don't see how the `Send` trait featured in the article "doesn't give any freedom for creativity."

I read it as claiming that skill and education are insufficient to prevent these bugs, and that automation is still valuable no matter how skilled the programmer is.

Re: The memory safety problem isn't bad coders

#13

Post by jaggederest »

Even if the problem was "bad coders", the answer is still better tooling.

The tooling we have now is pretty poor, in general. Sure, we can catch certain classes of bugs. Many bugs still occur in areas that aren't covered by those classes, even in the most robust languages.

Obviously memory-safe languages would help enormously. I also think that compilers are still in their infancy.

Re: The memory safety problem isn't bad coders

#14

Post by madhadron »

Derek_MK wrote: post #2

TL;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…

> 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."

Stockholm syndrome? Hazing? Fear that skills that moat off expertise will be devalued?

Saying that I should do something that the computer can do for me is telling me that my time is not worth anything. It's pretty insulting.

Re: The memory safety problem isn't bad coders

#15

Post by _bxg1 »

Rusky wrote: post #12
rinchik wrote: post #4

I 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.

I don't see how the article is trying to be "comforting," or dismissing the value of skill and education. I also don't see how the `Send` trait featured in the article "doesn't give any freedom for creativity." I read it as claiming that skill and education are insufficient to prevent these bugs, and that automation is still valuable no matter how skilled the programmer is.

In a broad sense, the forces of safety and flexibility in a language tend to be at odds. Rust does a lot of clever things that push that curve some, but a big part of what makes it safer than C++ is what you can't do.

Re: The memory safety problem isn't bad coders

#16

Post by bfung »

The problem here is the author’s development process. There’s an “old” programmer adage in regard to version control: merge early, merge often. It addresses the author’s issue directly.

So yes, it’s not the code that’s bad. It the development process. Bad (ok, fine, inexperience) developer.

https://queue.acm.org/detail.cfm?id=1643030

Re: The memory safety problem isn't bad coders

#17

Post by leesec »

rinchik wrote: post #4

I 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.

Another take is that DESPITE there being a lot of 'amateurs' in the industry, the world generally seems to be humming along as normal, if not doing very well.

Re: The memory safety problem isn't bad coders

#18

Post by rabidferret »

metalrain wrote: post #3

As a python user I understand the need for better invariant checking, but should it be encoded in types, contracts or conventions?

My goal wasn't so much to promote any specific answer, just to rebute the argument that the solution to memory safety bugs is to have better C programmers

Re: The memory safety problem isn't bad coders

#19

Post by FilterSweep »

> “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 breaches bad? I don’t believe so. Many went through grueling multi-part interviews to land the position.

No, the issue a management one. Anti-worker is a meme in America and this is just another manifestation of the disingenuous “lack of tech talent” whining used to recruit more H1B.

It’s also why unreleastic growth targets cause gaming tech workers to face layoffs despite record breaking sales.

Re: The memory safety problem isn't bad coders

#20

Post by zaphar »

metalrain wrote: post #3

As a python user I understand the need for better invariant checking, but should it be encoded in types, contracts or conventions?

I vote for all three.

    * Types so I can prevent all the low hanging fruit.
    
    * Contracts so I can encode invariants that the types 
      can't always express.

    * Conventions so that everyone is talking the same 
      language and there is less confusion
Post reply on HN