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

161–170 of 225 posts

Re: The memory safety problem isn't bad coders

#161

Post by _bxg1 »

Zarel wrote: post #145
core-questions wrote: post #107

Earlier quoted context omitted.

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…

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.log(foo.bar1);
  console.log(foo.bar2);

  // example 2
  for(let i = 0; i
Example 1 can be statically verified by a JavaScript type checker. Example 2 can't. There are advantages of being able to do the second thing - more code reuse, possibly less refactoring needed. But it's impossible to verify that those properties exist on that object without running the code. The argument is that oftentimes, the type checking is more valuable than the loss of "creative" freedom. But it does mean limiting the kinds of things you can do.

Re: The memory safety problem isn't bad coders

#162

Post by SatvikBeri »

cm2187 wrote: post #156
SatvikBeri wrote: post #135

Earlier quoted context omitted.

I regularly work in a statically typed language (Scala) and a dynamic/gradually typed language (Python.) I never find that static types force me to plan more – it's pretty easy to change them on the fly. I frequently find that static types let the IDE highlight an error the second I write it, instead of waiting until running tests. And every codebase I've worked with has taken at least a few minutes to run tests (and…

In fact with the right IDE, static typing makes refactoring much easier. Right click on a parameter, rename, and it will rename anywhere where it is relevant (as opposed to a replace all).

To be fair, you can do that with dynamically typed Python and a good IDE too. I've used PyCharm on Python 2.7 for years and never really had any issues with refactoring.

Re: The memory safety problem isn't bad coders

#163

Post by pjc50 »

hinkley wrote: post #34
_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.

I'm not sure I follow this; are you referring to the great improvements in safety that F1 adopted relutantly, only after a long campaign by Jackie Stewart who'd seen too many friends die?

Re: The memory safety problem isn't bad coders

#164

Post by jplayer01 »

bunderbunder wrote: post #159
jplayer01 wrote: post #131

Earlier quoted context omitted.

Java is really the worst example for a typing system. It's basically the way you shouldn't do it. There are much better type safe languages like Haskell, Erlang, Rust, etc., even just Kotlin because it drops so much of the boilerplate and excessive unnecessary verbosity, while retaining the static typing and its benefits.

Kotlin is an improvement insofar as it does a decent job of resolving insanity like the "object-oriented-but-you-have-to-cross-your-fingers-behind-your-back-when-you-say-it" type system. But it's still not a great example for static typing, insofar as you're still working with Java's half-baked type semantics where the set of types the language understands is a superset of the set of types that are expressible on the…

You're right, yes. Thanks for elaborating.

Re: The memory safety problem isn't bad coders

#165

Post by ecnahc515 »

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 you truly knew what you were doing when you started, then everything would work the first time you tried it. Since that's not the case, you're clearly making mistakes, so why wait until running it to find mistakes when you could find them before even running the program?

Think of it this way: you only ran it 10 times, are you sure you found all the bugs? What about 11 times? Are you sure you found all the problems? Numerically speaking, if the first 9 attempts didn't work, then 90% of the time you ran it after coding, it was still broken. The fact that the program was broken a majority of the time you developed it should make you skeptical if it's even "correct' after you've determined it to be "finished". I understand you picked random examples, but this is still relevant.

It seems to me like you're arguing a common argument about picking tools which is "I've always done it this way, and it works for me, so why look for anything better?"

Re: The memory safety problem isn't bad coders

#166

Post by Karrot_Kream »

bunderbunder wrote: post #112
mhink wrote: post #76

Earlier quoted context omitted.

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

I am beginning to suspect that Java is almost singlehandedly responsible for the prevailing opinion that static typing doesn't do anything useful and mostly gets in the way. Which is sad, because I'm also hard-pressed to think of a worse poster child for static typing than Java. It's like a stereotypical bureaucrat, asking you to fill out a mountain of paperwork before it can proceed to do a whole lot of nothing usef…

Really? There's a ton of boilerplate in Haskell that goes into working around the type system (to the point where people have made alternate Preludes to avoid having to explicitly specify the goop), and I can't count the number of times I've had to massage types in Scala for no other reason than to push a class into a certain cats monad. Lets not get started on error types in Rust. I'm a fan of static typing, but let's stop this incessant drumbeat of propaganda saying that typing is free, and the pain comes from no-true-scotsman implementations.

Re: The memory safety problem isn't bad coders

#167

Post by tomjakubowski »

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

Rust is actually looser than C++ in some respects. For example, there are no type-based aliasing rules to worry about in Rust. This makes writing "type punning" style code less of a headache for me, personally.

Re: The memory safety problem isn't bad coders

#168

Post by mamcx »

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

Not only with dynamic types, where more bugs are of the "very stupid" kind.

I run against my rust code, and damm.

However, this also prove how MUCH better is static typing. The rust linter provide hints about more serious stuff, not things that the type system already avoid!

Re: The memory safety problem isn't bad coders

#169

Post by marcosdumay »

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.

Static types are one kind of static analysis, but there is a lot more that can be done.

A linter can look at anything from micro-quality like "don't use more than one ++ operator at the same line" or "there's an = at this if test, this is probably wrong" to macro ones like "I couldn't prove your program terminates", "I couldn't prove that memory does not leak", or "a deadlock can happen here".

Re: The memory safety problem isn't bad coders

#170

Post by mamcx »

burntsushi wrote: post #99
pron wrote: post #91

Contrasting C and Rust completely misses the issue. Yes, obviously Rust will do away with some important classes of bugs and security vulnerabilities, but it's got nothing to do with addressing the problem. The problem is that there are billions of lines of C out there, and it will take many decades to replace them with software that's written in a memory-safe language. The issue is what do we do with all that existi…

No, it is the issue. Before one can even consider the proposition that it might not be wise to write X in C, you first need to convince people that the tool (that is, C) is actually a problem. That's what the OP is targeting: people think the problem isn't the tooling, but the programmer. The task of figuring out how to actually use the language is an entirely separate, though valid, problem. But it's not some giant…

> people think the problem isn't the tooling, but the programmer

I extend it, and say that choosing a bad tool is a sing of a bad programmer (even if the programmer is so skilled that use C very well!), but the resistance of recognize C/C++/JS to be BAD, REALLY REALLY BAD, PLEASE NOT USE THIS ANYMORE (only in rare exceptions, and still not use it ok?) Make this a full circle.

We need more "good" programmers to express this, alike how say "use of carbon/fuels is bad, and the fact the WHOLE ECONOMY OF THE PLANET is not an excuse to not replace it ASAP!"

And yes, why not make a concerted effort of make real replacement to well chosen libraries? I think using the pareto principle, we can target 20% of the most popular stuff and have a huge impact.

Post reply on HN