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

41–50 of 225 posts

Re: The memory safety problem isn't bad coders

#41

Post by Rusky »

_bxg1 wrote: post #15
Rusky wrote: post #12

Earlier quoted context omitted.

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.

Sure, I certainly agree there. I just thought the OP was going a bit overboard- stifled creativity wasn't an issue here at all.

Re: The memory safety problem isn't bad coders

#42

Post by ThrowawayR2 »

leesec wrote: post #17
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.

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

Given that the count of software security incidents and data breaches are skyrocketing by all measures (e.g. https://www.varonis.com/blog/cybersecurity-statistics/), that's not remotely a reasonable view to take.

Re: The memory safety problem isn't bad coders

#43

Post by scarface74 »

jschwartzi wrote: post #33
risubramanian wrote: post #27

Earlier quoted context omitted.

The problem with that reasoning is that nearly every language with static typing also has some kind of type inference. You'll just wind up with a bunch of autos/vars.

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.

This is a valid, strongly typed C# object:

var foo = {bar = 1, baz = “Hello”, boo = “World”};

You get auto complete help and compile time type checking.

foo.bar = “Goodbye”;

Won’t compile. What would it buy you to not use ‘var’ and create a one time use class/struct?

Re: The memory safety problem isn't bad coders

#44

Post by swiley »

_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…

Tools are an absolute must for large codebasses.

Humans struggle with large codebases but by restricting what's allowed to certain well understood and prearranged patterns and by forcing them to write specs and docs they are possible to handle.

Re: The memory safety problem isn't bad coders

#45

Post by jschwartzi »

rabidferret wrote: post #18
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

Yes. Often the difference between a mediocre programmer and an excellent programmer is ability to use tooling effectively to understand how their program works and where it fails.

Re: The memory safety problem isn't bad coders

#46

Post by chongli »

risubramanian wrote: post #27
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…

The problem with that reasoning is that nearly every language with static typing also has some kind of type inference. You'll just wind up with a bunch of autos/vars.

Haskell has very powerful type inference but it also lets you ask the compiler "what type is this expression?" There even exists tooling that lets you automatically insert inferred type annotations. Sometimes the type it infers is more general than what you wanted, so you get the opportunity to fix it in a way that makes sense to you.

Re: The memory safety problem isn't bad coders

#47

Post by hinkley »

jschwartzi wrote: post #39
jaabe wrote: post #28

You 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…

> 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 factors to make it a good example for dynamic programming. Also it simply doesn’t scale to inputs that only take microseconds to calculate.

It’s like those interview questions that leave you with more questions than answers, like “are they bad at interviews or just crazy?”

Re: The memory safety problem isn't bad coders

#48

Post by scarface74 »

hinkley wrote: post #40
jaabe wrote: post #28

You 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…

? The most efficient way it to use iteration...

If I am paying them, the most efficient way is to use Google....

Re: The memory safety problem isn't bad coders

#49

Post by fzeroracer »

tormeh wrote: post #35
rinchik wrote: post #25

Earlier quoted context omitted.

It is NOT good to have bad coders, it's good to have a promising talent. Also when can we finally drop this IQ thing? Your IQ does not guarantee you anything. Attention to details, perseverance, curiosity are the great promising qualities, not your IQ.

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

Re: The memory safety problem isn't bad coders

#50

Post by Verdex »

risubramanian wrote: post #27
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…

The problem with that reasoning is that nearly every language with static typing also has some kind of type inference. You'll just wind up with a bunch of autos/vars.

The problem with eating pizza is nearly every restaurant with pizza also has some kind of ice cream. You'll just wind up with a bunch of people eating ice cream and pizza all over the place.

Like, type inference is pretty widely regarded as a definite good. Additionally, technologies like row polymorphism make it possible to have statically typed and inferred duck typing. To me it's hard to hear this as anything other than mission accomplished. We made a static language that looks and feels like a dynamic one.

If you don't like type inference, you'll need to offer additional explanation as to why it is bad. Because otherwise you're statement only sounds like the one I made above. It sounds weird because one doesn't necessitate the other AND because they're both widely considered good.

Post reply on HN