Hacker News Reader

Comment by nickbauman | Hacker News Reader

I don't see this example particularly enlightening. I'm not really ever seeing problems where I'm stuffing an integer into where I wanted a string in dynamic languages. Or stuffing a Person into a Gorilla. These problems seem important and they tickle programmers warm fuzzies (unless you're like me and you've been programming static and dynamic for more than 20 years).

The small amount of scientific study around what type checking and static typing gives you is that you avoid around 3% of bugs but even those 3% are easier to fix than the effort in writing them correctly in the first place. While I agree that the subject needs more study but what we know now: the real win would be to have a dev process that lowers criticality of failure (like TDD, CI and other Agile processes) and dispense with static typing for most projects.

View on HN

While I disagree (static typing is much more than catching type conversion errors), my point was that it makes experimentation and design exploration much easier and faster. Without types, you'd need mock data for even the simplest of programs, and changing mock data structure is much more painful than changing a type somewhere and getting the places (all the places) where your program turns then out to be incoherent. Not to mention that types are much more than Persons or Gorillas, they can be higher order functions too (Person -> Gorilla) that are passed around.

Sure. But does your static typing system allow you to skip writing automated tests? Pretty sure everyone writes tests these days unless they're spiking something. If you're writing tests, you will have to come up with the mock data anyway. And the kind of exploration you're doing I tend to do from a test regardless. Once my exploration is done I also have a test that captures my work. You still have to write one. The question of whether to static or dynamic is moot in this case. It no longer matters much.

Maybe I need to spend some time in Haskell and come over to your way of seeing it. But the studies show that constructing the type system for your problem is very difficult and remains error prone. People routinely make mistakes with types systems of all kinds. I've found I spend more time making the compiler happy that it does making me happy.

> If you're writing tests, you will have to come up with the mock data anyway.

With property based testing, your system will come up with mock data for you.

The sibling comment points out property based testing (see QuickCheck), which is a good idea in any language. And yes - you don't need to write that many unit tests (but still some) when using a type system, because you can encode a lot of invariants in the types.

But still, my point stands - writing tests during early experimentation is a lot harder than just altering some type and letting the compiler infere what needs to be done or what you broke.

I've spent some time writing Clojure and still use dynamic languages a lot for smaller tasks, so I know both sides. This doesn't mean much, but I'd really encourage you to try some ML language and spend some time with a nice type system. Haskell is probably too big a time investment, so maybe try Elm [0] - it's very beginner friendly and a lot of the people using it come from JavaScript.

[0] http://elm-lang.org

I don't think I've ever seen a bug that shouldn't've been a type error. When I encounter a bug that wasn't a type error, it's usually a sign that my model is subtly incorrect. (E.g. I recently found a bug where one codepath wasn't filtering a tree that it should have been. This clued me in that filtered and unfiltered trees need to be different types, and actually making that change simplified a lot of code, since it forced me to figure out the correct point at which to do the filtering so that I could do it in one place)

The data shows that you see 3% bugs that could have been fixed with static typing. 97% are from other things. Mind you this area has not been studied much and needs more research, but that's what we know now.

I simply don't believe that when it's so utterly contrary to my experience. How did they define a bug as not being fixable with static typing?

This seems to be a very common situation with programmers. When presented with evidence to the contrary, we all of us tend to respond in this sort of "it's wrong because it conflicts with my experience". You realize this is essentially the classic flat earther denial. I'm not picking on you: I've done it too. It seems to be an industry hazard.

I think there's a level at which you have to be willing to believe your own eyes over the consensus. And there are levels of how established the consensus is. Perhaps it's particularly common for programmers because the industry moves so quickly, so all of us can quote previous established wisdom that turned out to be utterly wrong.

> I'm not really ever seeing problems where I'm stuffing an integer into where I wanted a string in dynamic languages

Wow, then you are extremely lucky because bugs like that would occasionally consume a whole day of senior developer time at my previous Python job.

I don't think the OP is particularly lucky. I never see errors like that, either. Just because the language doesn't enforce strong types doesn't mean variables don't conceptually have a type.

It seems like a symptom of other problems more than anything, and using a staticly typed language will just make those problems manifest in a different way.

> I'm not really ever seeing problems where I'm stuffing an integer into where I wanted a string in dynamic languages.

If you are writing all of your code from scratch, then it doesn't happen too often. You usually have enough of the current context in your head to avoid most type level mistakes.

The real strengths come from two situations.

The first is refactoring. There is just no contest here. Having every single place where your change affects the test of the program identified automatically is extremely useful.

The second is returning to old code and either trying to understand it or make small changes to it.

I see simple type errors like this ALL THE TIME in legacy code bases I get pulled in to salvage. Even in a dynamic language with a fair amount of static checking like Objective C I find people putting the wrong kinds of objects into arrays etc. So when people tell me now that they just don't make type errors in their code I don't believe them. People make mistakes, particularly when tired and under pressure.

If people are writing code, thinking, "I have no idea what else is stored in this container, so I'll just add an object of type Foo because I can!" then the project has bigger problems than static or dynamic typing.

The reality is that a lot of code is written by average programmers trying to get a lot done in a hurry. A static check is the difference between a subtle bug making it into production and a helpful, specific error at compile time. Most projects do have bigger problems than static or dynamic typing but static typing is even more helpful there than it is on projects staffed only by top-flight coders with plenty of time to do things right.

Except that the evidence points to the contrary.

http://games.greggman.com/game/dynamic-typing-static-typing/

In the three years I've been doing consulting work I've had to clean up a lot of legacy code. Believe me, people do make these mistakes in real-world code all the time.

Reply on news.ycombinator.com