After playing with the library for awhile, I think this has a lot of potentials.
I'd like to give you guys some feedback as I considered how we would integrate this stuff into our codebase (that is, once contracts are under a commercial-friendly license!). Where do we send feedback?
I must admit I was saddened to hear Spec# wouldn't be integrated into C# 4. But this is the next best thing; I'm glad to see design-by-contract getting some attention in the .NET framework itself.
If I may comment on the presentation, it feels like you both should have had your own presentations. It felt too rushed and too crammed.
Having Mike go deeper into the evolution of Spec# and why they chose a library instead of C# langauge integration would've been great. And Nikolai covering more real-world unit testing scenarios with Pex - for example, testing code with dependencies like the
file system or UI using Pex, would have been a great presentation by itself.
Also, the rehearsed Q&A between Mike and Nikolai was cheesy. Too tongue-in-cheek!
Beyond that, great stuff guys! I'm really happy to see DbC getting some real attention, I believe it will help us write code that more clearly expresses our intent and contains fewer bugs. That's something every developer can get behind. Going to go download
and play with the VS2008-integration...
Charles, you said in the interview that parallelism is not a key concern for C# developers.
Parallelism is huge, huge, huge for us. We've fought so many times with locks and deadlock problems and throughput in our code; we want better parallelism abstractions. I'd say it's #1 or #2 on my wishlist for C# vNext.
Guys, for over a year now, I've been telling folks at Microsoft that what we want is language constructs that help you write less buggy code.
It should be obvious, but this is the thing plaguing software teams; we write buggy code and we spend a lot of time writing unit tests, physically testing, debugging, and doing formal code reviews -- all in an attempt to get rid of bugs.
C# 4 should add some constructs that help us write software with fewer bugs in it.
For me, this means integrating some of the excellent research done over the last several years by the Spec# guys. The design-by-contract stuff would help us rid our codebase of mistakes developers often make when working on large, complex, real-world software
Some folks were asking whether PLinq and the ParallelFX library detects accessing shared state between thread and other naughty things. Perpahs Joe can confirm this, but I'm nearly certain it does not.
Plinq is about allowing developers to easily parallelize queries.
ParallelFx is about allowing developers to more easily parallelize common tasks.
Neither, however, prevents you from creating threading issues by using shared mutable state between threads.
The good news, however, is that by using LINQ, we're headed towards a more functional, declarative future. Those who have used functional languages like Haskell will know that concurrency is a breeze because of no or limited mutable state (e.g. all shared state
is readonly, little or nothing has side-effects). As we move forward with Linq, I suspect C# programs will look more and more like functional programs, with less and less shared mutable state.