Any reason to use C# instead of F#, considering F# is more functional?
Wonder if it has something to do with COM...
Running a startup on Haskell
71–76 of 76 posts
Re: Running a startup on Haskell
#72What is Reshaper in slide 35? Google suggests ReSharper, which seems more likely, since searching just for reshaper finds a pretty goofy product.
It's ReSharper from JetBrains. It's a widely used plugin for Visual Studio providing a handful of refactoring and productivity tools.
Re: Running a startup on Haskell
#73Earlier quoted context omitted.
That is great. In my school we only had a class with Ocaml, not quite as mind blowing since it didn't have lazy evaluation, monads, type classes, or any of the other crazy distinctive things in Haskell that don't exist in ML-style languages. Hopefully they cover the theory behind Haskell as much as the practical side of it.
ML's first-class modules let you achieve many of the same things as type classes. In fact, a lot of people in the Haskell community would like something a bit closer to ML (in other words, more powerful) in this regard. Monads can be formulated in any language with first-class functions. Monadic I/O is more distinctively Haskellish, and of course Haskell has syntactic sugar to make using them easier, but as a tool an…
> Monads can be formulated in any language with first-class functions.
Yes, though they only really make sense if you also have static typing, and polymorphism by return type also helps.
Re: Running a startup on Haskell
#74Can anyone comment on the claim "QuickCheck is shockingly more effective at finding bugs than unit tests"? I'd be interested in hearing other opinions.
It's essentially a unit-fuzzing framework, so it can find holes in boundary conditions people generally forget to check, because it's in their blind spot or because "nobody would ever do that". QC does not care, and since it's injecting fuzzed data at the unit leve (~function, generally) it makes it quite easy to see precisely where the failure happens.
Also writing up the laws that the fuzzers checks, is a good exercise in thinking about your API. Read http://donsbot.wordpress.com/2007/05/01/roll-your-own-window... and http://donsbot.wordpress.com/2007/05/17/roll-your-own-window... for some examples.
Quick also not only gives you the failing cases, but tries to simplify and shrink them first.
Re: Running a startup on Haskell
#75Can anyone comment on the claim "QuickCheck is shockingly more effective at finding bugs than unit tests"? I'd be interested in hearing other opinions.
It's worth noting that QuickCheck is used with functional code only. For non-functional code with side effects (e.g. database transactions), Haskell has unit test frameworks that are not too different from unit testing frameworks in other languages. What distingishes QuickCheck from regular unit testing is that you give it a function to test, some invariants that must hold and an input generator. Some of this is auto…
> It's worth noting that QuickCheck is used with functional code only.
That's actually not true. You can use QuickCheck with "normal" code that has side effects, too, and it's every bit as useful there.
Re: Running a startup on Haskell
#76Can anyone comment on the claim "QuickCheck is shockingly more effective at finding bugs than unit tests"? I'd be interested in hearing other opinions.
The claim is true: QuickCheck is surprisingly more effective at finding problems (and documenting expected behavior) than unit tests. When I first tried it, not long after the QuickCheck paper came out at ICFP 2000, it found problems that I never would have thought to test for. [1] (That's why I end up writing something like QuickCheck when I code in environments that don't already have one. [2] It's worth it.)
The key to its effectiveness is that it doesn't suffer from limited human imagination. When I write test cases by hand, it's up to me to think of all the things that could go wrong and write test cases for them. But, being human, I have blind spots. Even when I try to be systematic about detecting edge cases and writing tests for them, I miss some. But when QuickCheck-like tools write the test cases for me, they can dream up corner cases like you wouldn't believe.
And, even better, when I use QuickCheck, my test code doesn't end up looking like an enumeration of corner cases. Instead, it becomes clear, concise, and formal documentation. (For a good example of QuickCheck properties as documentation, see [3].) I just specify the intended general properties of my code, and QuickCheck generates the messy test cases behind the scenes, where they don't become visible noise.
[1] http://blog.moertel.com/pages/seven-lessons-from-the-icfp-pr...
[2] http://search.cpan.org/dist/Test-LectroTest/lib/Test/LectroT...
[3] http://haskell.org/ghc/docs/latest/html/libraries/base/Text-...