The memory safety problem isn't bad coders • Hacker News Board

Re: The memory safety problem isn't bad coders

#31

Post by alexanderdmitri » Tue, Feb 12, 2019, 6:24 PM UTC

DannyB2 wrote: post #7

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…

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

The devil is in the details usually here. Bloat can absolutely affect your bottomline in many ways.

Re: The memory safety problem isn't bad coders

#32

Post by wvenable » Tue, Feb 12, 2019, 6:26 PM UTC

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.

Type inference is perfectly ok; it's still statically type checked and all the parameters and return-types are properly typed.

Type inference takes away the main argument against static typing: That static typing requires you type in a bunch of useless obvious types.

Re: The memory safety problem isn't bad coders

#33

Post by jschwartzi » Tue, Feb 12, 2019, 6:27 PM UTC

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.

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.

Re: The memory safety problem isn't bad coders

#34

Post by hinkley » Tue, Feb 12, 2019, 6:27 PM UTC

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

In race cars (though maybe not F1), I’m told that the inertia of the driver would throw them out of the car on those turns if not for the safety equipment.

I think you can make the analogy work for professional drivers, but not for amateurs.

Re: The memory safety problem isn't bad coders

#35

Post by tormeh » Tue, Feb 12, 2019, 6:29 PM UTC

rinchik wrote: post #25

xiphias2 wrote: post #10

Earlier quoted context omitted.

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.

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.

Re: The memory safety problem isn't bad coders

#36

Post by _bxg1 » Tue, Feb 12, 2019, 6:29 PM UTC

noir_lord wrote: post #29

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

I couldn't agree with your post more if I tried. The first time I ran a static analyser over an old codebase of mine it was deeply humbling. I'm a competent programmer who works deliberately and carefully and the tool still went "did you really mean to do this stupid thing? ". Of course sometimes you do mean to do stupid thing because there is a good reason for it and as long as the tool gives you the ability to say…

Yeah. That's one thing I love about Flow/TypeScript as opposed to "real" compiled languages: you can actually leave type errors present if you don't know how to take care of them at the moment, and do a successful build. Or, if you know you're doing something safe and the analyzer just can't understand that, you can literally comment-out the error.

And of course, Rust has "unsafe" mode. In my experience it's important to have tiered strictness; start out with the highest constraints, but provide mechanisms for stepping that down in special cases where you really have to, without giving up safety completely if possible.

Re: The memory safety problem isn't bad coders

#37

Post by scarface74 » Tue, Feb 12, 2019, 6:30 PM UTC

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.

Type inference for static languages are just syntactic sugar.

The IDE and the compiler will both scream if you try something like

var x = “John Smith”;

x = 5;

Re: The memory safety problem isn't bad coders

#38

Post by srean » Tue, Feb 12, 2019, 6:30 PM UTC

weliketocode wrote: post #21

No need to say 'bad', but there is definitely a shortage of experienced coders. - Competition/Compensation for experienced coders has risen sharply - There are many more inexperienced SDE's coming from colleges/bootcamps/etc - Senior titles are often given to individuals who are still very early in their careers Now, these factors might be necessary/good in the short term as software continues to eat the world. But,…

[flagged]

Re: The memory safety problem isn't bad coders

#39

Post by jschwartzi » Tue, Feb 12, 2019, 6:32 PM UTC

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 ever going to use the first 16 Fibonacci numbers I don't really care if they're brute-force computed recursively. I'd much rather spend valuable engineering time on optimizing something that actually matters. Requiring students to prematurely optimize some ivory tower algorithm as a precondition to working in the real world is precisely why we have a shortage in the first place. You should be training the students to optimize the algorithm when it needs to be optimized, and not just hiring people who've memorized a few very specific algorithms and can bark them on command during your interview.

Re: The memory safety problem isn't bad coders

#40

Post by hinkley » Tue, Feb 12, 2019, 6:35 PM UTC

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