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

151–160 of 225 posts

Re: The memory safety problem isn't bad coders

#151

Post by coldtea »

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.

Some languages don't care either way, and will let you add those types.

Re: The memory safety problem isn't bad coders

#152

Post by m4lvin »

_hardwaregeek wrote: post #103
_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…

It's amazing how little we talk about tooling, both in work and in education. I had an internship where I kept on trying to work on better tooling for the developers, only to be told that I should be working on the actual product because that's more important. Except, if I make the other developer's lives even 5-10 percent easier, then that will have a much longer effect than whatever work I can get done in 3 months.…

Hey stranger, thanks for telling me that the lecture I gave last week was the right thing to do, even though I will be told that "those things do not belong to 'Data Structures and Algorithms'" :-)

Re: The memory safety problem isn't bad coders

#153

Post by staticassertion »

chongli wrote: post #46
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.

Haskell has very powerful type inference but it also lets you ask the compiler "what type is this expression?" There even exists tooling that lets you automatically insert inferred type annotations. Sometimes the type it infers is more general than what you wanted, so you get the opportunity to fix it in a way that makes sense to you.

Similarly, the intellij plugin for Rust will reveal implicit type annotations.

Re: The memory safety problem isn't bad coders

#154

Post by AdeptusAquinas »

_bxg1 wrote: post #101
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.

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.

Re: The memory safety problem isn't bad coders

#155

Post by Zarel »

nickpsecurity wrote: post #90
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…

Could you name them? Especially those that find more stuff than the others along with how you rate them on false positives? I try to collect data to pass on to folks interested in trying static analysis.

https://lgtm.com/

LGTM recently came by my project offering to integrate with GitHub. It's found a decent number of bugs other linters and my test suite didn't find, and it didn't require any setup at all; you just open your project on their website.

Their staff also reacted really quickly when I asked them questions or reported bugs.

For the most part, their only false positives are things like unreachable code, which I sometimes used to leave in for future-proofing, but I eventually did things their way, because it does make sense that it could be confusing to a third party.

The only alert I've ever suppressed was a string search for "example.com", which could have matched "example.com.untrusted-attacker.com". It was just code for displaying a reminder, not anything security-critical, so I didn't think it was worth fixing.

Re: The memory safety problem isn't bad coders

#156

Post by cm2187 »

SatvikBeri wrote: post #135
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 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).

Re: The memory safety problem isn't bad coders

#157

Post by scottlamb »

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?

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

Mutexes are supposed to ensure that exactly one thread can accesses resource ("have the lock") at a time. There's no fundamental reason you can't pass the lock from one thread to another, as long as they don't both have it at once. But it may not be supported by the particular mutex implementation. It's not supported by the recursive mutexes the author was using, and I'd bet there are also non-recursive mutex implementations which don't support it. I agree with the author that it's great Rust can catch this sort of mistake.

btw, I think recursive mutexes and handing off locks are bad ideas. Both for the same reason: I want short critical sections to improve contention.

* Code that uses recursive mutexes tends to be sloppy about this; it's unclear from reading a section of code whether it even has the lock or not. (This also sounds like a recipe for deadlock when you need multiple locks.) I'd much rather structure it so a given piece of code is run only with or without the lock. In C++, I use lock annotations [1] for this. If I need something to be callable with or without the lock, I might have a private "DoThingLocked()" bit, and a public "DoThing()" bit that delegates while holding the lock. This should also be more efficient (though maybe it's insignificant) because there's no run-time bookkeeping for the recursive mutex.

* Handing off the mutex to another thread also feels like a smell that you're holding the lock longer than you need. I don't recall a time I've ever needed to do it. From the description here, it seems totally reasonable to hold a mutex while getting a connection from the pool and while returning one to it, but not between. I'd think you could get the connection, then create the new thread (passing the connection to it).

[1] https://clang.llvm.org/docs/ThreadSafetyAnalysis.html

Re: The memory safety problem isn't bad coders

#158

Post by core-questions »

mannykannot wrote: post #141
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…

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.

Re: The memory safety problem isn't bad coders

#159

Post by bunderbunder »

jplayer01 wrote: post #131
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,…

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 underlying platform. Meaning that the set of types that can exist is quite a bit (I'm guessing uncountably infinitely) larger than the set of types that you can non-contortively deal with when doing generic programming.

Scala gets around this by attempting to extend the type system in deeply incompatible ways. Which mostly works, as long as you don't care about compatibility.

Clojure gets around this through a combination of dynamic typing and Rich Hickey including a section titled "I Don't Need Any Sour Grapes" in every lecture he delivers in public.

Of the three, TBH, I think Clojure has the best approach. You can't build proper static typing on top of the JVM without breaking compatibility with the rest of the Java ecosystem. At which point, why bother with the JVM at all?

Re: The memory safety problem isn't bad coders

#160

Post by noir_lord »

nickpsecurity wrote: post #90
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…

Could you name them? Especially those that find more stuff than the others along with how you rate them on false positives? I try to collect data to pass on to folks interested in trying static analysis.

Sure though the line between linter, type checker and static analysis is blurry (so I'll use the "suggest improvements without execution") because of the languages I work in.

For PHP :-

PHP Inspections (EA Extended) (commercial variant, free one is good as well) - Hands down my favourite for PHP because it integrates so well with my IDE, I wouldn't write PHP without it - very few false positives, when it flags something if I don't immediately understand I go look at why it's flagging it, I've learnt stuff I didn't know after nearly a decade of using PHP.

Phan - Very good and getting better all the time.

PHP_CodeSniffer (more useful for making sure you stick to a particular standard say PSR2 - IDE's can do this but code sniffer can be part of you pipeline/commit handling)

PHPStan - Very powerful but if you didn't start with this or are bringing it on an existing codebase..well it'll find a lot, on max it will flag what seems like everything but it's configurable and its most technically correct.

For TypeScript - TSLint w/ tslint-microsoft-contrib.

For C# - ReSharper

For bash - ShellCheck

I also tend to use an IDE that has a decent degree of real time analysis for the languages I use which is nearly always Intellij (with it's PHP, Python plugins) or one of it's spinoffs (eg. Rider on Linux) - I'm a jetbrains fanboy basically, I adore their tools.

Post reply on HN