Running a startup on Haskell

For a different type of background, Bryan O'Sullivan is the author of some of the best Haskell libraries out there. The de facto standard JSON parser/serializer is his doing, for example, and his Riak client is the best I've seen in any language. This guy really knows what he's talking about.

agreed. heart-broken when i realized the next slide wasn't a continuation of that one.

There was a certain condition (~ 10 years ago) where if the source file didn't pass the type checker it would be deleted.

Bryan quickly assured everyone that it had since been resolved. =)

Scala has scala check: http://code.google.com/p/scalacheck/

Ruby, because of non static types, can't be as magical, but people have given their best: https://github.com/IKEGAMIDaisuke/rushcheck

I'm not sure about one that can generate arbitrary data, but Heckle[0] will break your Ruby tests in extravagant ways.

[0] http://ruby.sadi.st/Heckle.html

For Ruby: http://rushcheck.rubyforge.org/about.html

Check out the citations on http://en.wikipedia.org/wiki/QuickCheck for QuickChecks in other languages.

A quick google search returned this:

* qc for python (http://dan.bravender.us/2009/6/21/Simple_Quickcheck_implemen...)

* QuickCheck Wikipedia page with links ot implementation for many languages (http://en.wikipedia.org/wiki/QuickCheck)

Personally I am looking forward to trying out qc for python. Has anyone here used it before?

Go has a QuickCheck-like package distributed with it. It's under testing/quick.

http://golang.org/pkg/testing/quick/

rushcheck is a bit moribund, or was last time i checked. https://github.com/hayeah/rantly is pretty nice.

Very cool, I didn't realize there was a generic version of Pex (the unit test generator for C#). Now if only I could figure out some way to unit test drivers...

There's qc [1] for Javascript.

[1] http://willowbend.cx/2009/12/05/qc-js-quickcheck-javascript/

For C# I in fact thought of what is in the above quote and wrote my own: https://github.com/ane/DotCheck

It's not yet very advanced (sometimes the library is a bit messy), but it provides the basic QuickCheck functionality.

For Perl it's a module called Test::LectroTest

* https://metacpan.org/module/Test::LectroTest

* http://community.moertel.com/ss/space/LectroTest

I haven't used QuickCheck, but read about it. So take this with a grain of salt, but it seems to me that specifying properties that should hold for your functions and then letting QuickCheck throw all kinds of data at them would be more efficient at least, if not more effective, than manually writing a bunch of unit tests and coming up with your own test data.

It's surprising how often people overlook weird edge cases that QuickCheck finds, because it doesn't have as many preconceptions about what kinds of inputs are sensible.

It tends to be best for mathematical code because you can quickly think of invariances.

In any situation where you can state a powerful invariance your code must always be consistent with it's both fast and thorough. The common example is that (= str (reverse (reverse sequences))) for all sequences.

Note that this only tests invertibility. There are lots of ways reversal can be broken without violating this invariance. It's just really easy to write down this invariance and use it to rapidly check gross violations.

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.

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 automated with compiler magic (where possible) to make simple tests really simple to write. QuickCheck will then grind through a bunch of random inputs and see if the invariants hold, finally showing you the failed cases.

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

Yesod is a web framework. It is designed to display web pages with some sort of datastore backing them. If you had a CRUD-type app with a few different data models then Yesod will make it really easy to generate the appropriate HTML and forms and make them type safe. It extends the Haskell all the way down to the application layer, assuming standard HTML as your primary response and a certain data representation and persistence layer.

Snap (I have only looked at it. Please correct me) seems like it only goes as far as the HTTP layer. It's designed so you can implement web services. Those services might return HTML, but they might return JSON or XML. It doesn't care or help you with your data representation. You have to do your own data persistence and display layers.

It's a class in Haskell, not on Haskell.

I'll actually be sitting in on this class if not enrolled in it. I look forward to another good forum where I can improve my Haskell and functional programming skills, particularly with a good instructor like Brian O'Sullivan.

I think the main advantage of a course at Stanford is access to the instructors. Sure, I could just read Real World Haskell and do all the exercises, but with the course I have a space where I can directly talk to Brian or David at least once a week if I have questions.

See Mono.

Not really, as long as they don't use Windows API directly and rely on .NET Framework they should be able to run it on MONO.

He revealed during the talk (after a very small amount of prodding) that it was an Outlook extension (since people on Windows are willing to pay for software... out of company budgets).

The brains are in the cloud though, apparently.

C# lets you make very powerful UIs with very little work (thanks to WPF) which most importantly feel quite native. WPF is also the only widespread framework that I know of that lets you have pretty much any kind of control inside another control (well, other than HTML that is -- the problem with HTML is that you lose the native feeling).

That being said Mono supports System.Windows.Forms (the poor predater to WPF) so there's always that. Or they can code against the (now dying?) Silverlight which actually works on Linux ala Moonlight.

But really, the best user experience is the one that feels the most native. So on Mac that would mean building a Cocoa client, on Windows WPF, on Linux Gtk/Qt (but then again who actually pays for Linux apps?)

Going with a one tech that supports it all just has a higher probability of having something that supports everything poorly, instead of something that supports one thing very well.

Remember that Haskell datatypes are very rich. QuickCheck will generate random instances of any datatype you define. Because Haskell datatypes are so expressive,. t's normal for Haskell programmers to define complex types for their functions to process. Hence you can easily get good coverage of any idiomatic Haskell code with QuickCheck.

If you're working in a datatype poor language, or simply one where the syntax makes defining complex datatypes painful then you're much more likely to pass around datatypes which are in implicitly defined. In this case you'll have to write a QuickCheck function to generate suitable instances in order to test your code. (This is also true for Haskell: there are often a few functions where you have to explain to QuickCheck how to generate appropriate test cases.)

It was something to do with the compiler deleting the source file if there was a type error within it.

It's ReSharper from JetBrains. It's a widely used plugin for Visual Studio providing a handful of refactoring and productivity tools.

Did you know that that was a slideshow? You're seeing the title page, click on it to advance to the next page. repeat.