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

71–80 of 225 posts

Re: The memory safety problem isn't bad coders

#71

Post by kzzzznot »

_bxg1 wrote: post #36
noir_lord wrote: post #29

Earlier quoted context omitted.

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

I too like this about Typescript - allows for fast spiking too, where you don't actually yet know what you want

Re: The memory safety problem isn't bad coders

#72

Post by hombre_fatal »

noir_lord wrote: post #30
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.

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 -> Float` and `Short + Long -> Long` in that perhaps you wish those operators weren't defined but it's at least consistent. And you'd find the error once you've passed those results to a function that expected Int or Short.

Re: The memory safety problem isn't bad coders

#73

Post by chc »

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.

Languages with type inference still require you to give enough information for a type to actually be inferred. Type inference isn't an escape valve for the things named in the GP comment, it's just a shorthand.

Re: The memory safety problem isn't bad coders

#74

Post by moosey »

_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 contrarian argumentation that I see on HN is always something to behold (I view it as a positive!).

An article comes out yesterday about programmers being a problem: comment section points in another direction.

An article comes out today that says that programmers aren't the main problem: comment section points out how awful all of us were, if we just go back far enough in time.

My main takeaway: Programming is hard.

Re: The memory safety problem isn't bad coders

#75

Post by sifoobar »

unionpivo wrote: post #58
bfung wrote: post #16

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

That's the point. There is always something you haven't thought of (or did wrong), once you get to certain level of complexity.

Regardless of language.

You'll have different kinds of bugs, but as long as there are programs they will contain bugs. Or the languages themselves will, or the libraries used, or the OS.

Assuming the presence of bugs/failures and providing powerful tools to deal with them like Erlang is a more realistic option if you ask me.

Re: The memory safety problem isn't bad coders

#76

Post by mhink »

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…

Although I mostly agree with you, it's worth noting that static typing only goes so far. When I worked in a large-scale Java codebase, it always seemed like half the code only existed in order to "work around" the type system. (Don't even get me started on Spring, which might as well be a whole additional language on TOP of the actual application code.) I'm perfectly willing to grant that might just be a Java thing, but still, it was a huge and constant frustration.

Because of the above, types really don't seem like "useful docs" to me. I get extremely irritated when a library links to its API documentation and it's all just autogenerated lists of methods which proudly state their parameter and return types but say absolutely nothing about what they do.

That's one major thing I've always appreciated about the Ruby and Javascript ecosystems: because they can't rely on type information, most libraries go out of their way to describe how they work in depth.

I'm willing to grant that I didn't have a ton of experience with Java before moving on to other languages, and so I could very well be wrong... but one thing that definitely worries me about Typescript is the increasing Java-fication of browser languages.

Now, all that being said, I gave Crystal [0] a spin the other day and it's a freaking dream. Ruby, but with types, and compiled to LLVM? YES PLEASE.

0: https://crystal-lang.org/

Re: The memory safety problem isn't bad coders

#77

Post by chc »

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…

This is more of a knock against the compromises TypeScript's wacky type system has to make for JavaScript compatibility than anything else. It's not possible in a language that was really designed for strong static typing like Haskell or Rust.

Re: The memory safety problem isn't bad coders

#78

Post by amaccuish »

This article hits the nail on the head. When speaking with someone who argues that we don't need memory-safe languages, just better programmers, I always like to ask if they've ever had to use a debugger/ever made a single mistake programming. What you're asking of programmers is that they never make mistake, whether it be a memory-safety bug or just a regular bug. It's simply not possible.

Re: The memory safety problem isn't bad coders

#79

Post by graphememes »

Reading the argument laid before me in this post. I disagree. It most certainly is due to negligence. Human negligence. Poor communication, and project management.

Maybe, you can't correlate this to "bad coders", however, if the coders have the issues described within this post then most certainly I would consider them "bad coders" when paired together.

Re: The memory safety problem isn't bad coders

#80

Post by maxxxxx »

jschwartzi wrote: post #67
maxxxxx wrote: post #56

Earlier quoted context omitted.

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++) {

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.

Makes sense for embedded.
Post reply on HN