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

121–130 of 225 posts

Re: The memory safety problem isn't bad coders

#121

Post by nickpsecurity »

pron wrote: post #108
nickpsecurity wrote: post #102

Earlier quoted context omitted.

There's a whole segment of CompSci dedicated to doing that. Softbound+CETS and SAFEbound are two of the better examples giving C memory safety. Data Flow Integrity is a newer one thst might be combined to bring security against data-oriented attacks. The big issue with such tools is that C's lack of design and low-level nature make the tools have to be extra careful in ways that add extra overhead vs languages design…

Also https://trust-in-soft.com/

And AbsInt with Astree Analyzer used by Airbus. Those are the three I know. Rosu's group open-sourced K with their language work and publications full of awesome stuff. Since Im a "vote with your wallet" guy, I always mention RV-Match over the others to hook up a company whose people are hooking us up with grest, building blocks for free. Just figured I should be open about that. :)

Re: The memory safety problem isn't bad coders

#122

Post by dx87 »

adrianmonk wrote: post #60
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…

Well, although it could be anti-worker, it could also be one-upmanship among programmers with fragile egos: I'm not a bad programmer; they are. And I think ego is a barrier to accepting tools that prevent errors. To accept the tool is to admit to yourself and others that you are going to make the error (sometimes) without it.

I've seen the ego issue pop up a lot in some communities. The biggest example I can think of is the OpenBSD mailing list. Any time I'd see an outsider bring up Rust or other safer languages, the overwhelming sentiment is that languages with built-in safety features are for people too stupid to write C, and that safety features restrict good coders ability to write performant code.

Re: The memory safety problem isn't bad coders

#123

Post by recursive »

cm2187 wrote: post #92
AdeptusAquinas wrote: post #86

Earlier quoted context omitted.

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.

Doesn’t static analysis requires static typing? There certainly has been a strong resistance to the introduction of static typing in the js community.

`let val = 3;`

This statement can be statically analyzed using the inferred static types that are already present. There is a lot of idiomatic javascript code that already has inferr-able static types in it. In fact, if you turn on the "implicit any" option in the typescript compiler, then you never need to add any types.

Re: The memory safety problem isn't bad coders

#124

Post by gmueckl »

scarface74 wrote: post #43
jschwartzi wrote: post #33

Earlier quoted context omitted.

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?

It would make me ask why you need a one time use struct at all and probably remove it.

Re: The memory safety problem isn't bad coders

#125

Post by mcphage »

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

> 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

I don't think the poster is claiming that programmers are smarter; they're claiming that what IQ tests evaluate, and what programmers do, are similar. But IQ isn't the be-all and end-all of intelligence. If you're a programmer, you might score high on an IQ test, not because of how smart you are, but because the skills being evaluated align. You might not be very intelligent at all, just good at IQ tests.

Re: The memory safety problem isn't bad coders

#126

Post by lmm »

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?

Types because they can be checked mechanically, simply enough that a programmer can understand the checking process and why it fails or succeeds, but are expressive enough (given some relatively cautious/widespread advances - HKT and some level of dependent typing) for every invariant I've ever needed.

Re: The memory safety problem isn't bad coders

#127

Post by xiphias2 »

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

I refuse to acknowledge that C++ is clearly more flexible than Rust. My favourite counterexample is Rayon. Even if you are able to implement something similar in C++ (I tried it), the job of the C++ compiler with understanding when it can inline functions without overhead gets so hard (vs the Rust compiler), that it becomes inpractical.

Generally this has been my experience with higher order programming in C++ actually.

Re: The memory safety problem isn't bad coders

#128

Post by llukas »

gowld wrote: post #109
jschwartzi wrote: post #67

Earlier quoted context omitted.

I try to avoid using STL because it A) throws exceptions, B) has really convoluted type names, and C) dynamically allocates memory. These are all things you avoid in the embedded space.

Any use of templates has the same problem, including templates that are used to generate highly efficient static constants and non-branching-at-runtime code.

Example?

Templates (template metaprogramming) help to avoid exceptions. You can check invariants first and jump into efficient code.

Re: The memory safety problem isn't bad coders

#129

Post by llukas »

maxxxxx wrote: post #56
jschwartzi wrote: post #33

Earlier quoted context omitted.

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.

Not necessarily. The types may just have very long names. In C++ for iterating through STL container auto is a godsend. The types are very straightforward and easy to reason about but just long. for (auto it = s.begin(); it != s.end(); it++) { is much easier to write than for (vector ::iterator it = s.begin(); it!=s.end(); it++) {

or almost like python:

for (auto &element: s){

even better with structured bindings:

for (auto [key, value]: map){

Re: The memory safety problem isn't bad coders

#130

Post by dunefox »

core-questions wrote: post #107
cm2187 wrote: post #92

Earlier quoted context omitted.

Doesn’t static analysis requires static typing? There certainly has been a strong resistance to the introduction of static typing in the js community.

I'm not a very good developer, though I do have plenty of released-and-working-well things out in the world. I will say, it seems to me like static typing would reduce my creativity and flow and require me to spend more time planning stuff, which is not fun, and would make updates take more time as I patch stuff in all over the codebase. It's sort of the polar opposite of Ruby-style "duck typing". Do they really help…

Well, I remember times when my program crashed because I tried to add a dictionary and an integer - so, yeah, they do help.
Post reply on HN