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

141–150 of 225 posts

Re: The memory safety problem isn't bad coders

#141

Post by mannykannot »

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…

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 cannot effectively track how everything needs to fit together to work, unless you are doing some sort of planning.

Duck typing only works when it works, which is not as trivial a statement as it might first seem.

Re: The memory safety problem isn't bad coders

#142

Post by amaranth »

applesvsoranges wrote: post #106

>> With a normal mutex we would be fine, since you only one lock can exist and it doesn’t matter if we unlock it on a thread other than the one we locked it from. Sorry if this is a dumb question, but I'm confused. Aren't mutexes always supposed to have ownership which implies that only the locking thread can unlock them?

A reentrant mutex will allow you to unlock it multiple times so long as you're on the same thread. That means if Thread A takes the lock then later some code on Thread A tries to take the lock again to get a connection to pass to Thread B you'll have the connection the mutex was protecting on two threads at the same time. The rust version of the mutex prevents this by making the data the mutex is protecting unable to be sent to other threads. That means you can only share the mutex which will block on Thread B when you try to take the lock, as expected.

Re: The memory safety problem isn't bad coders

#143

Post by zaphar »

P_I_Staker wrote: post #84
zaphar wrote: post #22

Earlier quoted context omitted.

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

Sure work doesn't need to completely halt while we wait for a perfect solution. But I think that where there are safer and more intuitive tools we should use and promote them.

Re: The memory safety problem isn't bad coders

#144

Post by yxhuvud »

gowld wrote: post #104
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,…

It seems strange to say that something (types) isn't worth anything more than nothing just because it isn't everything (complete documentation)

Types gain you some things, but there is an overhead, both of expressibility and of terseness. The costs (and gains for that matter) are different for different languages, and also different languages are used for different things, which make different trade-offs worthwhile.

This means that the trade-off Crystal give could be way better than the one Ruby gives, despite Ruby giving a better trade-off compared to Java (for some use cases). For other problems Rust, Go or C could give a better trade-off.

It is not a discussion about if types, all other things equal, are good or not. The reason behind this is simple: Not all other things are equal and not all type systems are equal.

Re: The memory safety problem isn't bad coders

#145

Post by Zarel »

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…

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 AoC was closer to 50%, and I was like #30 or so on the leaderboard [1]). But to do it perfectly, in real-world code? That I don't believe.

The nice thing about static typing is about catching mistakes earlier, and making it easier to figure out what your mistake was. Without the type annotation on the function, when you get a crash a few days later, it's harder to figure out "is the function wrong, or is the code calling the function wrong?" With it, those questions are automatically answered.

The best I've heard is that for short scripts, static typing doesn't help _enough_ to be worth the extra time it takes. But with modern type inference, it takes very little extra time at all.

And the extra time it does take, to write out interfaces and stuff, you can avoid in TypeScript with type assertions and `any` assertions. But honestly, it's usually worth it: It's not like you _don't_ plan out the interface; you just used to keep them memorized instead of writing them down, and then regret it a few weeks later when you want to make a change.

[1] To be fair, it was 50% because I was optimizing for programming speed for the leaderboard rather than accuracy; I'm sure I could have gotten closer to 90% if I were optimizing for accuracy. But anyone who argues that avoiding static types saves time has to accept that you make a lot more mistakes if you're trying to save time.

Re: The memory safety problem isn't bad coders

#146

Post by mannykannot »

dictum wrote: post #133
dunefox wrote: post #130

Earlier quoted context omitted.

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

The problem lies on enough : the overhead of static typing has to be lower, in the lifespan of a project, to the time spent fixing bugs like this one. (Other things, like liability from bugs and crashes, may give an edge to static typing. The age-old debate is how much )

If you know what sorts of data your variables denote and your functions take and return, being explicit about it is not much of a burden for the benefits it brings.

Re: The memory safety problem isn't bad coders

#147

Post by coldtea »

mhink wrote: post #76
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,…

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

I don't think that's fair.

I'd say that "half the code only existed in order to" use patterns and OO hierarchies for the sake of it.

Java can be programmed as lightly as Python or as a full-on J2EE monstrosity. The difference is cultural ("idiomatic") not brought about by types.

Re: The memory safety problem isn't bad coders

#148

Post by coldtea »

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.

That's still good. In that case the language even writes the documentation for you!

Re: The memory safety problem isn't bad coders

#149

Post by brundolf »

taeric wrote: post #134
_bxg1 wrote: post #69

Earlier quoted context omitted.

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)

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.

Re: The memory safety problem isn't bad coders

#150

Post by scarface74 »

gmueckl wrote: post #124
scarface74 wrote: post #43

Earlier quoted context omitted.

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.

More complicated example:

var seniorMales = from c in customer where c.age > 65 && c.Sex == “male” select new {c.FirstName, c.Lastname, c.Age}

foreach(var customer in seniorMales) { Console.WriteLine(customer.Firstname + “ “ + customer.Lastname); }

Why would I create a class/struct for that use case?

Side note: this is why I find ORMs in most languages besides C# useless. Here, “customers” can represent an in memory List, a Sql table or a MongoDB collection and the LINQ expression will be translated appropriately to the underlying query syntax.

The “ORM” is integrated into the language and yes anyone can write a LINQ provider.

Post reply on HN