(Smiling at you right now. Innocently.)
Why not learn Haskell, too? It’s not like it’s going to affect your productivity negatively, right?
(Stares intently and then smiles a little bit wider.)
It has garbage collection so it is unsuitable for real-time systems.
This line is confusing for me. Wouldn’t garbage collection make it “suitable” for real-time systems, or does he mean something different from “real-time systems”?
The common understanding of garbage collection implementation is that they use the stop the world approach, which is a no-no for a system that has to output control data constantly, without pauses.
I’m not sure on GHC’s implementation specifics so I can’t tell you if that’s a bogus concern or not.
It’s a real concern. GHC’s GC is pretty smart, but it’s not hard realtime.
He’s using the strict definition of real-time here, meaning “if this process doesn’t run a hundred times a second, the vehicle crashes.” Garbage collection pauses make this hard to guarantee.
I would need lots of tests, which would be slow and tedious to write.
Stop right there. You’ve already lost me.
It seems difficult to communicate that Haskell programs generally require fewer tests without also giving the impression that tests are somehow unimportant. The last major Haskell project I’ve worked on has one of the largest and most comprehensive test suites I’ve ever seen, for example.
The type system is simply expressive enough to let you encode more machine-enforceable invariants into the program itself. It simultaneously aids development in that it helps you understand your code and susses out weird corner cases - like a good test suite is supposed to do.
So, you generally just need fewer tests.
Have you written much Haskell?
The last major Haskell project I’ve worked on has one of the largest and most comprehensive test suites I’ve ever seen, for example.
This sounds great. My point here is no matter what language you use, you need to write good tests. I think it’s bizarre to claim that you picked a langauge to avoid writing tests. But you could, as in your case, say you will have an easier time writing good tests because of your langauge and tool choices. And if that’s the case you’d probably end up with more tests written, not fewer.
Wasnt the idea simply that haskell’s type system eliminates the need for a certain class of test (Since the compiler is basically a bunch of tests in itself). For the same program in python that would tend to mean you have to write less tests.
Unless I’ve misundestood something, that does seem like a reason to pick a language.
no matter what language you use, you need to write good tests
I don’t think there’s much of a need in Coq, Idris, or TLA+. :)
I figure that’s tongue-in-cheek, but it looks like there are unittesting frameworks for Coq. Poking around, Idris has some testing infrastructure as well. I have no idea about TLA+.
It’s great that these tools can catch more errors earlier, but they’re still just a variant of type checkers and compilers. Let’s not forget that compilers and type checkers have bugs, too. Wacky ones like this.
I don’t believe there is any better proof of program correctness than running the code and seeing the result you expected. Maybe the author of this post and other readers on this thread don’t agree.
Idris and Coq replace tests by using proofs I believe, a proof would catch holes even a thousand tests couldnt.
And as far as I know, the existence of a unittesting in coq or idris doesnt invalidate the concept of prooving your software works, just means some people dont want to write a proof for eveything.
Please tell us more.
This quote is an assertion that static typing and/or functional languages actually require fewer tests overall. In my experience, the cost of testing is primarily derived from the complexity of the problem being solved, not from the choice of tools.
I can totally accept that Haskell helps with solving problems and refactoring. It may also reduce certain classes of bugs. But you still need to test your code a proportional amount no matter what language you’re using. I think it’s weird to claim otherwise.
I think one thing that (a) Haskell helps a project do, (b) other languages help with less, and © leads to a need for more tests is setting up the design of data with redundancy. A common mantra in the Haskell community is that you should “make illegal states unrepresentable” which is to say use types to statically eliminate not just simple bugs but large regions of potential state spaces which are just universally incorrect. In a lot of projects, a huge amount of the required testing essentially goes in to ensuring that these boundaries are never crossed in live code paths, but with good typing you can just ensure that’s the case across the board.
I was impressed with the overall quality of the candidates we saw at Better (formerly Erudify). Core CS skills and the habits of mind we look for in solid engineers were all in evidence to a surprising degree, and choosing Haskell was a large part of that.
Sometimes you would get people who did some surprising things – like the candidate who wrote a program for a reporting task that generated not a CSV file but another Haskell file with a big array in it. We did end up hiring this candidate…