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

131–140 of 225 posts

Re: The memory safety problem isn't bad coders

#131

Post by jplayer01 »

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

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.

Re: The memory safety problem isn't bad coders

#133

Post by dictum »

dunefox wrote: post #130
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…

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)

Re: The memory safety problem isn't bad coders

#134

Post by taeric »

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

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.

Re: The memory safety problem isn't bad coders

#135

Post by SatvikBeri »

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 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 sometimes much longer), so this is a pretty substantial savings.

Or in other words, static types free me up to be more creative, by requiring me to spend less energy & attention on certain types of errors that were common before.

Re: The memory safety problem isn't bad coders

#136

Post by hectormalot »

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’ve been programming in Ruby for years (as a hobby / small passive income project), and about a year ago decided to reimplement a small part of it in Go. Both for learning and because it was a bottleneck in the application.

Recently I needed to fix some things in the original Ruby code, and it felt like freeclimbing after getting used to ropes... I called a function and started wondering how I could have any guarantees that it returned something useful. Benefits of static typing really ‘clicked’ for me at that moment. I still love ruby though

Re: The memory safety problem isn't bad coders

#137

Post by taeric »

I have argued many times it isn't the language that is the problem, necessarily. Never have I argued against tooling, though. Rather, toolchains can be added to without being replaced.

That is, my problem with this blog and most posts like it. Your tooling should not begin and end with your compiler. It is a vital part of your tooling, no doubt. But if all you did was compile it, you are playing a risky game.

Re: The memory safety problem isn't bad coders

#138

Post by jakevn »

msla wrote: post #110
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.

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.

Re: The memory safety problem isn't bad coders

#139

Post by jcelerier »

jschwartzi wrote: post #33
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.

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.

Re: The memory safety problem isn't bad coders

#140

Post by dfox »

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?

In almost any implementation you don't want to track the owner because it is only an unnecessary overhead and nothing else.

On a similar note the articles strikes me as somewhat contrived example, because the most obvious implementation of reentrant mutex also does not care about the owner thread.

Edit: Another reason why it feel contrived is that in fact reentrant mutex represented as first class datastructure (in contrast to monitor as an language-level construct) is to some extent only an hack to solve issues stemming from improper design.

Post reply on HN