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

81–90 of 225 posts

Re: The memory safety problem isn't bad coders

#81

Post by graphememes »

Verdex wrote: post #62
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…

| You shouldn’t rely on your tools protecting you because they won’t. Strong agree. It's like when your toilet overflows and instead of using a plunger (because sometimes this causes a splash that will get on your shoes) you just reach in with your bare hands. I've used this technique hundreds of times and I've never gotten any toilet water splashes on my shoes. [I get what you're trying to say, but it doesn't come o…

How does a plunger protect you? Does the water harm your shoes or were you negligent to spray protectant on them? At some point, humans are involved and this requires a level of responsibility.

Whether you're responsible for maintaining your tool, so that they don't break, or maintaining your shoes so that when something goes wrong there are safety measures in place to ensure minimal impact.

I'd say these measures and responsibility marker a "good" "coder" and the lack of, marker a "bad" or "inexperienced" "coder".

I'm using quotations because people enjoy to pontificate over language. Huge circle jerks that are a waste of time.

Re: The memory safety problem isn't bad coders

#82

Post by rurp »

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

I don't think the parent comment is saying that developers have a higher IQ than all other professions, just that developers are smarter than average. I personally think that there is a huge range but would bet that the average programmer has a higher IQ than the average non-progammer. Of course, the same could probably be said for a number of professions.

Re: The memory safety problem isn't bad coders

#83

Post by chousuke »

specialist wrote: post #66
_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 human brain wasn't designed to handle the complexity of large codebases." Because I'm a very simple bear, I always try to find the most simple thing that works. Because I'm certain that the next programmer that comes along, which is most likely future me, will see my efforts and think "WTF?!" Another facet is our human mind's propensity to make errors. Instead of blaming stupid users, just deal with it. Design a…

I think that distinction between mental model and abstraction is something I've tried to put into words for a long time with little luck. Thanks for that.

I think that any person working with a system must be able to form a "morally correct" mental model of the entire system from top to bottom (as deep as it practically matters) or the abstractions of that system have failed.

When I read highly abstracted code, the times it gets frustrating is when I can't form a coherent mental model based on the abstraction so that I could understand how the system behaves. Usually that's because the abstraction is too generic or interwoven with a non-local mechanism that I can't predict.

Re: The memory safety problem isn't bad coders

#84

Post by P_I_Staker »

zaphar wrote: post #22
P_I_Staker wrote: post #11

Earlier quoted context omitted.

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

Wanting better, safer, and more intuitive tools does not presume that people don't and shouldn't grow. Even with the tools there are plenty of bugs/challenging problems in just understanding and correctly expressing the problem domain in those safe and intuitive tools. The two positions are not incompatible.

Completely agree. That said, we have what we have, and people tend to be very idealistic about these things (favoring one vs. the other). Example, I use Git and Make in C. Others claim "this is the future, everything should be intuitive and graphical". I honestly don't see a way forward for either technology to be more intuitive; a better Git GUIs would be a plus for new users, but that's just the tip of the iceberg.

I'm not the type that think "you must do everything at the command line, or you're too stupid to be a decent programmer"; those people do exist. On the flip side, complaints about not being intuitive enough might be met with a shrug from me. Do we really want to use Eclipse and SVN, because you don't want to learn how to use the tooling? (of course, I'd never actually put it like that) Personally, I don't think it's a better solution. I'm not holding my breath for a complete overhaul of Git / Make, and am wary of trying something more novel for now.

Re: The memory safety problem isn't bad coders

#85

Post by cm2187 »

The problem isn’t bad coders for security bugs at Microsoft. But outside is the realm of sql injections vulnerabilities, unpatched software, default passwords left unchanged, hardcoded passwords in code, unprotected mongo dbs exposed to the internet, xss vulnerabilities, etc etc.

There the problem lies between the chair and the keyboard.

Re: The memory safety problem isn't bad coders

#86

Post by AdeptusAquinas »

_bxg1 wrote: post #69
phaedrus wrote: post #64

Earlier quoted context omitted.

The comparison with aviation instruments is apt: I remember seeing a TV special that talked about how in the early days of aviation (circa WWI) the pilots' culture of seat-of-the-pants flying and bravado was resistant to suggestions that human senses are just not equipped to differentiate between certain inertial reference frames, of which one leads to getting into a death-spiral. It was not until an early aviation s…

C/C++, and in many cases Lisp, seem to be the most entrenched communities when it comes to the "culture of seat-of-the-pants flying and bravado". For contrast, JavaScript has as much flexibility and nearly as many foot-guns as those languages, but its community has been much more receptive to safety rails and static analysis. (Hopefully this doesn't start a flame-war; that isn't my intention)

How. Dare. You.

More seriously, JS has had its own resistance movements. TypeScript was actively disdained until, as far as I can tell, Angular switched to it. Probably partially because it was MS, but also because there was a lot of resistance to static typing despite the demonstrated safety benefits.

Re: The memory safety problem isn't bad coders

#87

Post by pas »

hombre_fatal wrote: post #72
noir_lord wrote: post #30

Earlier quoted context omitted.

Which isn't bad if the type inference is good . Nearly all the type errors I see are things like var foo = "Hello World"; bar = foo + 10; That should scream it's head off.

To be fair, that's valid in Typescript because it simply uses Javascript's coercion rules. You could imagine it having built-in rules for JS' coercions: string + number -> string number + string -> string Maybe your snippet is provocative to some people, but in real code it would quickly fail once you actually use `bar` and were wrong about your assumptions. At which point it's similar to languages with `Int + Float…

It's not the fall, but the stop that kills you. So in case of TS we don't know what was the intent.

Maybe it was this.

function suffixWith10(s: string) { return s + 10; }

But if the intent can be discovered by analysis of usages of the variable later in the code, then TS will scream loudly.

Re: The memory safety problem isn't bad coders

#88

Post by brianpgordon »

> This wasn’t caught when I finished writing the code. It was caught weeks later, when rebasing against the other changes of the codebase. The invariants of the code I was working with had fundamentally changed out from underneath me between when the code was written and when I was planning to merge it.

Aside from the wider question about bad coders, I don't understand why he didn't catch this when he wrote the code. Didn't it fail to compile?

Re: The memory safety problem isn't bad coders

#89

Post by gcommer »

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

Google for "occupation iq" readily finds many surveys of different occupations with a fairly expected correlation: Professors and scientists on the high end of the spectrum and laborers on the other. Software engineers/CS isn't at the top but tends to rank fairly highly.

However, narrowing these stats to a single person as meaning "if you have a low IQ you can't be a good engineer" is incorrect, as that is totally throwing out: 1) IQ being only a single of many factors (reading about this from people in the field, I often hear IQ cited as the best single predictor we have, but still only accounting for ~30%) 2) IQ can change 3) IQ doesn't include domain knowledge, determination, or any other factors particular to a specific occupation.

Re: The memory safety problem isn't bad coders

#90

Post by nickpsecurity »

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…

Could you name them? Especially those that find more stuff than the others along with how you rate them on false positives?

I try to collect data to pass on to folks interested in trying static analysis.

Post reply on HN