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

171–180 of 225 posts

Re: The memory safety problem isn't bad coders

#171

Post by jschwartzi »

jcelerier wrote: post #139
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.

why we can't have nice things, in one comment. auto is not a code smell on the contrary, it is used when your type system is easy enough to reason about that you don't need to write the actual type.

If it's so easy to reason about, why can't you just state the type of the variable? Doing so helps me understand what's popping out from the rvalue in assignment so that I can follow what your code is doing.

If you're worried about spending time changing type names during a refactor, look at it instead as an opportunity to evaluate the correctness of the code in the context of your replacement type. Use of the auto keyword avoids doing that and as a result enables you to create new and exciting bugs in your code.

Re: The memory safety problem isn't bad coders

#172

Post by dkarl »

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

It's hard to stereotype the "C/C++ community." The C++ community popularized RAII for safer management of mutex locks, reference counts, and other resources; smart pointers for null checking; and other ergonomic improvements motivated by the knowledge that getting those things right in plain C required an unrealistic and/or wasteful level of vigilance. When I encountered Rust I immediately recognized the same desire for safety and protection that motivated usage of RAII in C++.

And, funnily enough, back in my C++ days I remember dabbling in Common Lisp and loving that there were macros that achieved similar results.

Re: The memory safety problem isn't bad coders

#173

Post by mannykannot »

core-questions wrote: post #158
mannykannot wrote: post #141

Earlier quoted context omitted.

You could probably become a better developer if you did more thinking ahead (or 'planning', as you put it.) If you are writing a bunch of variables, and you don't have a good idea of precisely what data they hold, there is very little chance that your program will work properly first time (not that thinking ahead guarantees it, of course, but it improves your odds.) For every programmer, there comes a point where you…

Respectfully, do I care if my program works the first time, or by the deadline? I don't care if the first ten times I run it, it just bombs out with interpreter errors. Doesn't seem to result in my having slower output than anyone else I'm working with.

If all you aspire to is to be about the same as your co-workers, you will probably do just fine continuing as you are.

What are these 'interpreter errors' that you write of? It is actually quite unusual for someone to find even just one error in the interpreter for each new program he writes. What interpreter are you using?

One thing I can be pretty sure of: Wall, Van Rossum, Matsumoto and Hickey didn't produce their languages without some insightful thinking ahead.

Re: The memory safety problem isn't bad coders

#174

Post by taeric »

brundolf wrote: post #149
taeric wrote: post #134

Earlier quoted context omitted.

Oddly, most of the complaints against lisp just don't acknowledge that they have actually had type safety for a long long time. Not just in racket's types. But common lisp has had valid compilation steps for a long long time.

In fairness, at my company we use a custom dialect of CL which does not have a type system, so I may not have enough perspective to make broad statements about the Lisp community. Though, intuitively, I'd think that in a language all about dynamic data structures and self-modifying code, static analysis would be really hard. But I may just be ignorant in this area.

I can't claim a lack of ignorance in this area. It is always baffling when you see just what some of the older lisp machines were capable of.

Too many posts reduce this to some sort of "magic of lisp" message. Which is certainly fun, in many ways. However, I think most of it is just a lot of hard work that was done by folks. Much of which will never be considered by the rest of us, almost solely on lack of information.

So, yes, I imagine in many ways it is harder. Doesn't make it impossible, though. And indeed, most type checking can be almost trivially done. As an example, typechecking the arguments to a format command. Trivially easy in most invocations. Only when people do build up dynamic programs is this hard. Thing is, those programs are hard to even think of, so most of us don't write them.

Re: The memory safety problem isn't bad coders

#175

Post by Zarel »

_bxg1 wrote: post #161
Zarel wrote: post #145

Earlier quoted context omitted.

I'm actually kind of surprised that programmers, of all people, would oppose guard-rails. At university, it was a meme that no one's C program ever compiled the first time they tried. I can't imagine even the best programmer in the world can avoid that kind of problem, without static analysis and static typing. Maybe you can have a 90% success rate on short programs, I'd believe that (my first-compile success rate on…

> it was a meme that no one's C program ever compiled the first time they tried Ah but see, the compiler is a guard-rail. Technically, it's a static-analyzer. I don't think anyone is against making existing guard rails more helpful via editor integration; the conflict comes with adding new guard rails. Take the following example: let foo = { bar0: 12, bar1: 14, bar2: 16 } // example 1 console.log(foo.bar0); console.l…

> Ah but see, the compiler is a guard-rail.

Yes, I agree. It's a guard-rail which is missing in scripting languages like JavaScript and Ruby, and which some people are resisting adding.

> Example 1 can be statically verified by a JavaScript type checker. Example 2 can't.

With type assertions, it's not really limiting at all. For instance, I'd write example 2 as:

    for (let i = 0; i
If you weren't as experienced with TypeScript, you can also just throw around `any` assertions until the problem goes away:

    let foo: any = {
      bar0: 12,
      bar1: 14,
      bar2: 16
    };
Or if you wanted to be tricky, you could even just assert a specific key:

    for (let i = 0; i
It's true that there are a lot of things typecheckers can't check. But that's no reason to give up on the things they _can_ check.

Re: The memory safety problem isn't bad coders

#177

Post by recursive »

_bxg1 wrote: post #161
Zarel wrote: post #145

Earlier quoted context omitted.

I'm actually kind of surprised that programmers, of all people, would oppose guard-rails. At university, it was a meme that no one's C program ever compiled the first time they tried. I can't imagine even the best programmer in the world can avoid that kind of problem, without static analysis and static typing. Maybe you can have a 90% success rate on short programs, I'd believe that (my first-compile success rate on…

> it was a meme that no one's C program ever compiled the first time they tried Ah but see, the compiler is a guard-rail. Technically, it's a static-analyzer. I don't think anyone is against making existing guard rails more helpful via editor integration; the conflict comes with adding new guard rails. Take the following example: let foo = { bar0: 12, bar1: 14, bar2: 16 } // example 1 console.log(foo.bar0); console.l…

In case anyone missed it, example 2 is allowed in typescript.

Re: The memory safety problem isn't bad coders

#178

Post by msla »

jakevn wrote: post #138
msla wrote: post #110

Earlier quoted context omitted.

The kind of errors I'm interested in preventing are more like this: var foo = 5; var bar = 100; baz = foo + bar; Why is that bad? Well... what do 5 and 100 mean in that program? Did you just add age in years to pixels from edge? How do you know? Appending an integer to a string is comparatively sensible next to adding age in years to pixels from edge.

Then you should not use a general numeric when you really should be using Pixel and Age types.

My broader point is that low-level representation doesn't matter nearly as much as semantics, and yet by default type systems are obsessed with low-level representations.

Appending a number to a string is a perfectly sensible thing to do when you're displaying information to a user, yet adding two numbers or concatenating two strings could be completely senseless and proof that the development process has gone off the rails.

My dream type system is strict about semantics and only handles representation in specific circumstances. The simplest way to talk about this is in terms of units of measure: Height is a type. Whether it's in inches or centimeters is a representation. Whether that representation is a number or a string is another representation. Keeping track of whether you're showing height-in-inches or height-in-centimeters to a user is useful, but burdening your mind with whether this height-in-inches is a string or a number right now when the runtime can just as easily convert between the two is senseless, and fretting over height-in-inches versus height-in-centimeters adding person-height to shoe-sole-height to get height-in-shoes is similarly senseless.

Re: The memory safety problem isn't bad coders

#179

Post by DannyB2 »

alexanderdmitri wrote: post #31
DannyB2 wrote: post #7

Earlier quoted context omitted.

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.

One man's 'bloat' is another man's features.

Consider both Microsoft Word and Notepad.

Which is more bloated? Which is more light weight?

Which has more powerful features, some that you don't even notice right away, like spellcheck, grammar check, etc?

Which has fewer features?

People usually complaining about 'bloat' in a high level language or its runtime are really complaining about features that they either don't use, don't understand, or don't even realize are there.

Re: The memory safety problem isn't bad coders

#180

Post by geoelectric »

AdeptusAquinas wrote: post #154
_bxg1 wrote: post #101

Earlier quoted context omitted.

Yeah. My armchair analysis is that more flexible languages tend to attract smarter people, because they have a higher cap on how much your codebase can benefit from cleverness. Unfortunately those smarter people tend to over-estimate their own cleverness, and trying to take away someone's dynamic language features tends to be analogous to trying to take away Americans' guns. Complex JavaScript codebases used to mostl…

Being very careful not to start a flamewar, my armchair analysis is the opposite: JS has seen a large influx of serious backend developers, who generally have no time for silly arguments against static typing.

My guess is it's some of both, really. There's the old saw about levels of SWE expertise:

* Beginner: doesn't know much and knows it

* Intermediate: knows a lot, hasn't lived with the consequences

* Expert: knows a lot, including when not to use what they know

The two comments here seem to be articulating the community shifting between I->B and I->E respectively. I think it's safe to say we have both a maturing developer base and a huge influx of newbies. That intermediate "look what I can do!" stage still exists, probably as much as ever, but is being professionally tempered by the caution inherent in the other two cohorts.

The Intermediate stage is the most fun to watch, though, and probably a lot of what drives innovation. The coolest projects come from people who ostensibly should've known better than to try that thing.

Post reply on HN