Hacker News Reader

Comment by wccrawford | Hacker News Reader

Even though I spent a lot of my childhood programming in C, I never understood why people started strong typing was so necessary when Ruby started becoming popular. This article explains that thinking for me, finally.

It's funny that it's the same article that also explains why it's wrong. At least, now it is.

Unit testing not only replaces the need for strong typing, it does so without any extra effort on top of what you'd already do for unit testing. It's not like you have to do extra work on duck-typed languages than you do on strong-typed languages when you're unit testing. (Assuming you're doing it correctly, of course.)

View on HN

Unit testing not only replaces the need for strong typing, it does so without any extra effort on top of what you'd already do for unit testing

That's not true. I work on an e-commerce system. Ensuring that people don't accidentally use Floats where they shouldn't requires quite a bit of additional effort which could be avoided with a type system.

Exactly! And that's just the kind of things the computer should be doing for you, not the other way around.

If you are able to invest some time I highly recommend you take a look at Haskell or OCaml.

I used to think strong typing was something stupid, inconvenient, etc. Then I started learning Haskell and realized I didn't hate strong typing, I just hated sucky implementations of it (Java, C++, I'm looking at you...).

And Haskell is an eye opener in more ways then just the strong typing. This being said I do agree non-strong typed languages can work perfectly fine, Python is for now still my goto language until I get more Haskell experience.

> "[I] realized I didn't hate strong typing, I just hated sucky implementations of it[.]"

Same here (but Lua, not Python). I didn't get the point of static typing until I learned OCaml - the static typing in C, C++, Java, etc. is a joke. (Especially C!) Type inference also singlehandedly removes one of the biggest problems with common static typing - structuring code so that types reflect assumptions (and changing them with the code) is no longer incredibly verbose.

I think the most pragmatic approach is probably dynamic typing with support for static annotations and as much inference as is feasible, though. (As with Common Lisp or Erlang's dialyzer.) Static and dynamic typing is more of a continuum than an absolute fork.

Also, minor point - you mean "static" typing, not "strong" typing. While this is a bit of an oversimplification, static vs. dynamic means compile-time-checked vs. runtime-checked, while strong vs weak means "has enforced typechecks" vs "passing around void pointers and casting freely".

How do you ensure that the unit tests are correct?

Unit tests are "correct" by definition, because they represent the specification for the code that they test.

You aim to encapsulate all the intended behaviour in your tests.

Thus, when you encounter a bug, you start by creating a test that replicates the bug, correct the test to the expected behaviour (so it now fails), then fix the code. That is: red, green, refactor.

Not only do you fix the bug, but you improve the specification and improve the efficacy of your tests.

In the way that you cannot pragmatically prove that code has no bugs, neither can you prove your tests are correct (bug-free). But by having a test suite that can run continuously, and that you add to, you are increasingly improving code quality and, most importantly, ensuring that regressions don't occur.

> Unit tests are "correct" by definition, because they represent the specification for the code that they test.

No, those are acceptance tests. (It's really too bad they can't be the code. Talk about DRY!)

Besides, how does one write tests for bugs they don't know about? (Or can they only be written after the fact?) Wouldn't it be helpful to have some sort of declarative specification so that the compiler itself can generate exhaustive tests?

Reply on news.ycombinator.com