ust to add one minor note: Quicksilver is a Launcher app, as the parent mentions, but it so much more than that. And it's one of those things you can't describe real well, you have to spend some time using it to understand. This is a bit of a catch - I am interested to know exactly what Quicksilver does, but there seem to be few good explanations. Perhaps comparison would be easiest - how does it compare to, say, deskbar for GNOME which lets you launch apps, search files, open webpages, write emails, execute arbitrary commands, and whatever else you can dream up via pluggable backends? I like Deskbar a lot - it is flexible, powerful, and lets me do everything with just a few keystrokes. Since, apparently, there is nothing at all comparable to Quicksilver on Linux I was wondering what sets Quicksilver so far ahead of something like Deskbar?
I don't have access to any Macs, so I simply don't have an opportunity to see Quicksilver in action, so thanks for any explanation you can give - I'm simply curious as to what it actually does.
require
not_full_or_expandable: not full or expandable -- require that elements may be added do
if full then expand end
last_index = last_index + 1
put(new_element, last_index) ensure
last_index_increased: last_index = old(last_index) + 1 -- ensure length of the array has increased by one
new_element_added: item(last_index) = new_element -- ensure new_element is the last element end
Of course with a simple example like this some of the contracts are obvious from looking at the code - but then this is also added to the API documentation, along with the comments, so we don't have look at the code to know what will happen. Better still our documentation isn't going to fall out of date - if code gets refactored such that these constraints aren't met any more then the refactored code will fail testing unless the contracts, and hence the documentation, are also changed.
I agree that throwing asser around isn't gaining you a lot. The point, however, is not to just stick assert in your code, it is to have a DbC system, which means as well as just expressive syntax for expressing constraints you also have tools to make use of those constraints, for docuemntation, for testing (fine grained control over which level of checks are included in compilation), and for the language - that means contracts are inherited, and preconditions cna only be weakened and postconditions strenghtened. Once you have all the extra support to really make use of contracts you start to see their value.
But formalizing these methods seem to required a big, upfront design. In fact it doesn't. DbC can actually help you be more agile. Consider an Agile framework built for Eiffel.
I agree, my point was simply that it needn't cost you any runtime performance in production if you don't want it to. As you say, it is easier to leave checking on for all but the expensive portions which, with a good DbC system, is easy to do.
Design by contract, like most formal method approaches, doesn't scale to interesting levels. If you are working on a 200KLOC project on a tight schedule, the last thing you can afford yourself is increasing time spent per line of code by equipping classes, loops and methods with pre & post conditions. Well obviously if you're doing it post hoc it is going to be expensive, but that's a silly complaint. You should be developing contracts at the same time as you're developing code. That shouldn't be costing you much extra time because you are supposed to be writing documentation and tests for your code anyway, and contracts are as simple as writing the documentation of a function as constraints in the programming language itself (suitably extended with more expressive syntax for riting constraints) instead of in English as a comment. As a bonus you've also just done most of the work of writing a test for the code. If you're finding writing contracts as you go much extra work I have to question how well documented/commented your code is.
At the same time you get immediate benefits from writing contracts as you go that make things easier. When everyone on the team is writing contracts that are automatically getting included in the API documentation then you have a clearer idea, just by reading the docs, and without having to fish through someone elses code, of what a function or method is intended to do - what you have to provide, and what you can expect in return. That makes integrating things much smoother. You also have the huge benefit that, when it comes to testing, any bugs that crop up are very nearly isolated and located by the contract system, allowing you to find the source of the problem much faster. Debugging code that has been well instrumented with contracts is remarkably easy and involves far less time sitting in a debugger stepping through code trying to find the original point where things started going wrong. The time savings in integration and testing more than make up for any minor extra time spent writing the contracts while developing the code. The reality is that in practice for large complex systems something like DbC can allow you to develop code faster, and get it through testing faster - it isn't more expensive, it's cheaper.
assert(condition) is your friend. It's not called a contract, it's not design (but a very good practice!) and it does the job well. I agree that asserts do the job well. I'm just trying to point out that a good DbC system, such as some of the ones mentioned in the article, provide significant tool support which makes contracts considerably better than asserts. For example, DbC systems will have compilers that understand contracts, and extended syntax designed specifically for expressing constraints such and post conditions. A simple postcondition like x > old(x) is harder to manage with assert statements - you need extra code to save the initial value of the variable which gets mixed in with your implementation and things get messy. DbC systems also involve documentation, allowing API documentation to be automatically generated, and including contracst in that documentation. DbC systems also have controls over whether contracts checks are compiled in or not, meaning you don't have to sprinkle your code with ifdefs everywhere. DbC systems also allow for static checking of contracts with theorem provers, something asserts just can't do. In other wors, a good DbC system takes the practice of using asserts, formalises it a little, and then provides excellent tool support to make it more powerful and easier to use. It's the difference between doing OO programming in straight C, or in C++ or Java, both are possible, but the latter languages provide a few extra constructs (that, in Java's case IDEs can mae the most of) that make it easier and more powerful.
By whom? I'd like to look into it for my Java projects. DEC R&D made ESC/Java (Extended Static Checking for Java) that used a theorem prover and specification annotations to verify contracts. Development stopped, but it is now open source as ESC/Java2 which uses JML as annotation markup. I actually listed this as the Java DbC implementation in the article description.
As has been noted, most programmers already do design-by-contract, they just don't call it that. They call it argument checking. The argument against this is that it is confusing implementation and specification. A contract is separate from the code implementing the function, and is automatically included in the API documentation for the function. That makes it easier for other people to use the code (they don't have to have access to the source code, or bother reading through all your code, just to be able to know they are calling your code correctly and what they can expect of the result), and for you to maintain your code. There's also the expressivity issue (particularly true of postconditions): to do certain checks, particularly involving, say, old values of variables (at the time of entry to the function), will involve extra useless implementation code to save variables and other hoop jumping. This is needlessly complicating your implementation. The advantage that having a system specifically designed to handle pre and post conditions is that it provides extra syntax so as to be suitably expressive with regard constraints.
In cases like that, I either omit the check or wrap it in an ifdef so it's only done during development and ignored by the compiler during the release build. And a good DbC system offers the ability to do just that (Eiffel offers excellent fine grained control over what checks get included in compiled code, from everything for testing, to nothing for finalized production code) without having to salt your code with ifdefs.
...they've just added some chrome, filed off the serial numbers and changed the name to keep you from noticing this. No, I'm pretty sure I knew exactly what it was, and no real attempt was made to hide this. The point is that they've added a lot of chrome. A good DbC system takes advantage of the expectation of such checks existing/being written, and provides excellent support to help you write checks, analyse checks, use checks, document your code with checks, etc. Let's face it C is just prettied up assembler and a good IDE is just notepad with a little chrome and the serial numbers filed off. If the chrome actually adds significant value then it is worth using.
DBC has a greater requirement towards designing everything up front. XP allows you to be more flexible in your approach, and supports the need to constantly refactor your code. That DbC is up front design is simply not true. You can do "Contract Driven Design" as well as you can do "Test Driven Design" (though of course combining tests and contracts, using each where they make sense - contrct for constraints, tests for explicit input to output mappings - is the best bet). Indeed there are even frameworks like ESpec which are specifically designed for doing XP in Eiffel using contracts. Try reading one of the ESpec papers on XP programming with ESpec. Think of it this way - DbC is about writing testable constraints early. That doesn't mean those constraints have to be finalised - contracts can evolve and be added to. With DbC you can get your constraints written and tested faster since you don't even have to have written the all code, just the contracts, to be able to test whether the constraints are sufficient to get the output you want (again, I'll refer you to the paper on Agile DbC using ESpec for details).
I don't want my software to fail in the field (at my day job, we write stock trading software - reliability is key because lack of availability can quickly become very expensive). If I could define a number of pre- and post-conditions for each function and have the compiler check these for me, I'd be happy. And indeed, this can be done, and is available for a number of DbC systems. Check out JML which has ESC/Java2 to provide static contract checking for Java, Spec# (C# with contracts) which uses the Spec# verifier for static checking of contracts, and Eiffel with ESpec-Verify for static checking of Eiffel contracts.
If the conditions are only going to be checked at runtime, then I'm going to have to write unit tests anyway - otherwise, the failure's going to be beautifully detected and localised and so forth, but crucially, it's going to be one of my customers that detects it. If I'm writing unit tests anyway, why bother with DbC? The difference between DbC and unit tests (and really, you should be doing both) is that if a test can be expressed as a constraint then it is useful to simply express that as a contract, while if the test is a specific input to output matching test then it is going to be useful as a separate unit test. When you run your unit tests the contract constraints will automatically get checked. More importantly they will help isolate exactly where the error occured when testing integrated systems. Furthermore, by putting constraints as contracts you have improved your API documentation (any decent DbC system includes automated inclusion of contract information in API documentation) which helps other people use your code correctly, and makes maintenance easier.
Finally contracts allow automated testing. That's where you automatically generate data to pass to the code and let the contracts act as a test oracle to catch and locate problems. With something like AutoTest for Eiffel the data generation can be purely random (constrained by preconditions of course), or designed to sample the input according to best coverage via genertic algorithms, etc. The result is that you find corner cases that you might not have anticipated with your unit tests - and you would be surprised how often that happens, AutoTest found a number of subtle bugs in Eiffel's base libraries which had been production code for years.
When there's a DbC language or add-on that checks the contracts at compile time, I'll be interested. Then you really need to check out JML and ESC/Java2, and Spec#, because you would be interested.
Regardless, the theory remains: if you can write pre- and postconditions for a function, you already know what the function is supposed to be doing so you might as well have spent your time writing the function and doing something else. Do you document your code at all? Do you test your code at all? That's all DbC is doing, it is just doing both at once for any tests that can be written as constraints. And remember DbC is as much about other people knowing what a function does as about you knowing - it provides clear conditions for anyone calling your code as to what they must provide, and what they can expect of any returned results, information that, for any decent DbC system, is automatically included in API documentation. You, the original coder, might know what the function does, but it would be useful if someone else who wants to use your code could get that information (or, at the least, soem useful constraints of the function) without having to dig through the source code to try and find out. If you're coding a project entirely by yourself for CS class then you won't see the advantages of DbC. If you're part of a large coding team, where you only ever understand a small part of the entire codebase, and are relying on other peoples code (which you don't have time to read) doing what you expect, then DbC starts to make more and more sense.
The other point is maintenance. You know what the function is supposed to do now, and you'll probably still remember tomorrow. A year from now, or later, however, that might not be so obvious. The code isn't going to help because the code only tells you what it does, not what it was intended to do, so how can you tell whether it is functioning as intended, or not? You could, of course, write comments that help explain this, but then writing a contract that states intention is hardly any more work than a comment, and provides testing and potentially extra static checks into the bargain. DbC only does work that you should be doing anyway (again, if it's a small project you're coding entirely yourself that you don't expect to maintain, then okay, DbC doesn't make sense) in terms of documenting an testing your code, so it shouldn't be any extra work.
Design by contract seems like a lot of extra work and runtime cost for something that might once in a while catch a bug in already-deployed code. Lighter weight methods like static typing catch (certain kinds of) errors before the code is even compiled; unit testing is usually done before code is deployed, and with the express aim of exposing incorrect behavior in corner cases. DbC doesn't incur any runtime cost if you choose not to bother - any good contract system allows you to turn off contract checking for production code. That is, DbC provides a test harness during testing but needn't do any checking of finished code after testing is complete. Moreover good contract systems like JML and Spec# are smart enough to allow static checking which allow you to catch a whole host of errors before compilation that static types just aren't going to be able to catch. And I have to admit that I am unsure how DbC is "a lot of work" given that you should be writing unit tests anyway, and if you have constraints or invariants then you ought to be checking those with unit tests - writing the constraint as a contract is less work than writing the equivalent unit test. Finally DbC enables testing that for which unit tests of corner cases simply can't compare - by using the contracts as a test oracle you can do automated randomised testing of several integrated units. That is to say, you can automatically generate data to search the input space delimited by preconditions, and use postconditions, invariants, and preconditions of any called code, to test that several units all work together correctly and potentially catch weird interelated corner cases that you hadn't anticipated. Honestly, check out AutoTest or Quickcheck sometime, they are suprisingly powerful and have found bugs in established production code that had already undergone extensive standard testing.
Instead of having the intrinsic type-safety checks and the social trust that the code author has run unit tests if necessary and makes the code do something reasonable, design-by-contract formalizes all this and makes you specify conditions on the code manually. DbC doesn't force you to do anything. You can say as much, or as little, as you like for contracts (nothing at all if you prefer). The point, however, is to get benefits out of the situation where things can be expressed as a contract. You suggest that writing unit tests to assure code does something reasonable is a good idea, and it is. Writing contracts is no different, and complementary to unit tests if used properly. If your test an be expressed as a constraint then you write it as a method contract or invariant, and if your test is onl expressible in terms of a particular output given a particular input (that is, as a specific test case) then you write a unit test. Then, when it comes to testing you are still testing everything for each unit - the unit tests fail if there's something wrong for particular test cases, and the contracst fail if the constraint are ever violated. That means writing constracts is no harder than writing unit tests (shorter really, because you don't have to write the boilerplate code involved in a test, just the constraint), and isn't any more indirection than unit tests. The advantage you get is that constraints as contracts can be automatically added to documentation (all good DbC systems support this), are statically checkable (many good DbC systems support this), which provides an extra layer of assurance, and provide a test oracle for randomised/state-space-search based testing (some good DbC systems like Eiffel via Autotest and QUikcheck for Haskell support this).
I think that really depends on what you see school as being for. I would suggest that a part of schooling is to teach students how to think and analyse. Why bother reading all those classic novels and analysing them? It's not like many people are likely to do that in their career. Because it teaches critical analysis of ideas, and rhetoric - understanding how language can influence, move, of otherwise effect us. Likewise, mathematics is the playground for abstract thinking and logic - it is a chance to fully exercise those skills, in much the same way that physics and chemistry classes provide an opportunity to put your mathematics skills to use. I admit that, with the way math is currently taught, logic and abstract thought don't really come into it. That, however, is a failing of how mathematics is taught (mostly by underqualified teachers who don't understand the subject sufficiently themselves to provide the depth of explanation required to elicit these skills), not a failing of teaching mathematics at school. Memorising the quadratic formula is not terribly useful for a lot of people. Understanding why it works, and more importantly the logic required to see that - that is something worth havign, for many many people.
And I would also like to see (more) practical mathematics in school. Currently most students get it shoved down their throats as a merely theoretical 'boring' lesson while mathematics has much more interesting and practical uses which during my time in school, I never or barely got to see (I got to see them a little in my practicum for electronics, but that's about it). Applications of mathematics is something that should be taught in physics class. Certainly a little applied math is useful as motivation, but oddly enough I think one of the things that is lacking from mathematics education at the high school level is pure math. There is plenty of interesting theory to mathematics, but instead of getting taught the theory, and gaining understanding, kids get recipes, formulas and applications with no real instruction as to the underlying principles. Mathematics is, at its heart, applied philosophy and logic - in the same way that physics and chemistry class provide you with a practical place to use your mathematics, mathematics is the subject area where kids get to put their skills in abstract thinking and logic to use. Of course they only do that if they have to think - which means actually teaching theory and understanding rather than recipes out of a textbook...
...Which brings us back to the point: as long as math teachers are not qualified they are in no position to teach deep theory and understanding and just follow the book with no understanding themselves. I would claim that much of mathematics is "boring" because the teachers don't have sufficient understanding to actually explain it well so you can understand and think about the subject. History is boring if you have a teacher who doesn't really know history and just recites names, dates, and events from the textbook. History is interesting if you have a teacher who understands history and can actually explain the depth and richness associated with those dates and events and spur studenbts to really think about history. Math is just the same - except that there are far fewer teachers who have enough understanding to teach it well, so most students come away with little or no understanding of the subject, and just a bunch of poorly memorised formulas.
#1: Parents who don't care if their kids get an education or not. I have to agree. As much as objections to apparently necessary measures to attract enough skilled math teachers do harm, ultimately it is the apathy of parents on these matters that really makes the difference. Were parents honestly and suitably incensed about the low quality of math education it would empower to politicians to ride rough shod over teacher objections - with enough strong feeling in the electorate teachers would get little sympathy for blocking reasonable proposals to incentivize math teaching as a career.
I dont have access to the current figures but isn't the U.S. ranking someone around 20th worldwide in education quality? Something like that. Perhaps this is what you were thinking of? Of course there are various criticisms of that study, so we shouldn't put too much stock in it. Still, it is notable that the top country, Finland, invested significant money and effort in encouraging as many elementary school teachers as possible to take extra math courses. The reality is that, because mathematics is a layered subject, each new topic building upon understanding of the last, falling a little behind can easily lead to an endless game of catch-up. One bad teacher, particularly early on, can have a significant detrimental effect on your entire career in the subject - and the reality is that often those who go into elementary teaching have the least understanding and the greatest dislike of mathematics. Changing that can make a huge difference in outcomes for students down the line in middle school and high school.
What's more important? A perception of equality between teachers of all subjects, or setting the salaries at the level required to attract teachers qualified to properly educate children in each subject? I think a more pertinent question is who is more important, the teachers, or the students? Ultimately it is the students that are losing here and it appears that, based on difference in demand (apparently qualified math teachers are very hard to come by in California), the most effective solution is going to be incentives to attract more qualified math teachers. What is needed, apparently, is some way to manage to sell that to the unions, or, at the least, a way to muzzle the union on this issue. The former is hard, and the latter is going to result in a head on clash with the union, which won't be pretty. In the meantime the kids continue to lose out.
Gutt the union? They're preventing progression and have become too in control. We're letting them run the show. Sure you can say "gut the Teachers' Union", but that simply isn't a practicable solution - it simply isn't going to happen, not in the real world. It might be reasonable to suggest measures that weaken the clout of the union, but one way or another you're going to have to work around unions if you actually want to provide a pragmatic, practical, solution that you can can reasonably expect to see implemented and have noticeable results. One proposal in California would see student loans waived for math and science students if they teach high school for 4 years. Whether that is sufficient incentive is hard to say. Certainly it is a little easier for the union to swallow.
So what is needed is Evolution for Windows eh? Kind of like this? I don't have Windows around anywhere to try it out, but it looks like it runs fine. I expect it still has a few kinks to be worked out, but it is certainly up and running, so not only is a port in progress, it looks like it is even usable already.
Really, is there anyone who has used Office on the Mac and knows anything about Micro$haft who hasn't thought this? I thought of a 5 step plan for Microsoft to crush and virtually eliminate Apple as a Desktop platform (Note, this plan would likely (1) be far to expensive to be worthwhile unless Apple somehow became a huge threat; (2) fall afoul of anti-trust legislation and be stopped before it really ever got started):
Cancel Office for the Mac and cease support and updates for exisiting versions
Buy Adobe
Cancel all Adobe products for the Mac and cease support and updates for existing versions
Buy DigiDesign
Cancel ProTools for the Mac and cease support and updates for existing versions
Technically MS has just enouigh of a war chest to manage those purchases, but of course there is no way they would fork over that much cash, nor be allowed to.
You bring up some good points, but how about taking it even further. Why do we even need the state-run education system? The argument generally runs that, to have an effective functioning democracy you need an educated and informed populace. If the median education level of the populace drops too low then people are too easily lead, and too ill-informed, to provide a well functioning electorate. Therefore there is a requirement, as part of being a democratic society, to have a basic minimum level of education that everyone receives: you can look elsewhere for better education, but the state system should provide an acceptable minimum level. Of course one could argue that US democracy isn't exactly well functioning at the moment, but let's not get into that. Whether you buy the argument or not, certainly an argument can be made, and there is plenty of room to expand upon and further detail the sort of argument I've sketched in precis form here.
So what we are teaching in school is not actually math, but math appreciation. And this continues for most people who have a degree; even teachers typically don't really understand math. This is not a joke. This is not inaccurate. It is the gospel truth. Your children (should you have any) are probably learning math (and science, although I won't go into that discussion since it's so similar) from someone who does not understand it. Thatk you. This is very true, unfortunately, and yes, it really does matter. Even things we consider simple and intuitive, such as numbers and basic arithmetic, have a lot more lying behind them than people give them credit for. Understanding the underlying theory can make quite a difference in terms of actually teaching kids some of the important skills involved in mathematics (abstraction and logic). Once you get to slightly more advanced topics, such as fractions and algebra, there is a surprising amount of subtlety, and more importantly some important concepts that really should be explained. Unless you actually have a deep understanding of mathematics, however, you are unlikely to be able to suitably communicate this, and be left teaching by rote from the textbook, which at least gives kids the skills they require, but not the understanding that is ultimately crucial for any higher mathematics.
Slashdot Mirror
It will be interesting to see how such things fare once both GNOME and KDE are suitably established on D-BUS. The possibilities certainly increase.
Eiffel let's you give contracts names which are then used for documentation and logging of contract violations during testing etc.
I don't have access to any Macs, so I simply don't have an opportunity to see Quicksilver in action, so thanks for any explanation you can give - I'm simply curious as to what it actually does.
I agree that throwing asser around isn't gaining you a lot. The point, however, is not to just stick assert in your code, it is to have a DbC system, which means as well as just expressive syntax for expressing constraints you also have tools to make use of those constraints, for docuemntation, for testing (fine grained control over which level of checks are included in compilation), and for the language - that means contracts are inherited, and preconditions cna only be weakened and postconditions strenghtened. Once you have all the extra support to really make use of contracts you start to see their value.
I agree, my point was simply that it needn't cost you any runtime performance in production if you don't want it to. As you say, it is easier to leave checking on for all but the expensive portions which, with a good DbC system, is easy to do.
At the same time you get immediate benefits from writing contracts as you go that make things easier. When everyone on the team is writing contracts that are automatically getting included in the API documentation then you have a clearer idea, just by reading the docs, and without having to fish through someone elses code, of what a function or method is intended to do - what you have to provide, and what you can expect in return. That makes integrating things much smoother. You also have the huge benefit that, when it comes to testing, any bugs that crop up are very nearly isolated and located by the contract system, allowing you to find the source of the problem much faster. Debugging code that has been well instrumented with contracts is remarkably easy and involves far less time sitting in a debugger stepping through code trying to find the original point where things started going wrong. The time savings in integration and testing more than make up for any minor extra time spent writing the contracts while developing the code. The reality is that in practice for large complex systems something like DbC can allow you to develop code faster, and get it through testing faster - it isn't more expensive, it's cheaper.
...they've just added some chrome, filed off the serial numbers and changed the name to keep you from noticing this. No, I'm pretty sure I knew exactly what it was, and no real attempt was made to hide this. The point is that they've added a lot of chrome. A good DbC system takes advantage of the expectation of such checks existing/being written, and provides excellent support to help you write checks, analyse checks, use checks, document your code with checks, etc. Let's face it C is just prettied up assembler and a good IDE is just notepad with a little chrome and the serial numbers filed off. If the chrome actually adds significant value then it is worth using.Finally contracts allow automated testing. That's where you automatically generate data to pass to the code and let the contracts act as a test oracle to catch and locate problems. With something like AutoTest for Eiffel the data generation can be purely random (constrained by preconditions of course), or designed to sample the input according to best coverage via genertic algorithms, etc. The result is that you find corner cases that you might not have anticipated with your unit tests - and you would be surprised how often that happens, AutoTest found a number of subtle bugs in Eiffel's base libraries which had been production code for years. When there's a DbC language or add-on that checks the contracts at compile time, I'll be interested. Then you really need to check out JML and ESC/Java2, and Spec#, because you would be interested.
The other point is maintenance. You know what the function is supposed to do now, and you'll probably still remember tomorrow. A year from now, or later, however, that might not be so obvious. The code isn't going to help because the code only tells you what it does, not what it was intended to do, so how can you tell whether it is functioning as intended, or not? You could, of course, write comments that help explain this, but then writing a contract that states intention is hardly any more work than a comment, and provides testing and potentially extra static checks into the bargain. DbC only does work that you should be doing anyway (again, if it's a small project you're coding entirely yourself that you don't expect to maintain, then okay, DbC doesn't make sense) in terms of documenting an testing your code, so it shouldn't be any extra work.
I think that really depends on what you see school as being for. I would suggest that a part of schooling is to teach students how to think and analyse. Why bother reading all those classic novels and analysing them? It's not like many people are likely to do that in their career. Because it teaches critical analysis of ideas, and rhetoric - understanding how language can influence, move, of otherwise effect us. Likewise, mathematics is the playground for abstract thinking and logic - it is a chance to fully exercise those skills, in much the same way that physics and chemistry classes provide an opportunity to put your mathematics skills to use. I admit that, with the way math is currently taught, logic and abstract thought don't really come into it. That, however, is a failing of how mathematics is taught (mostly by underqualified teachers who don't understand the subject sufficiently themselves to provide the depth of explanation required to elicit these skills), not a failing of teaching mathematics at school. Memorising the quadratic formula is not terribly useful for a lot of people. Understanding why it works, and more importantly the logic required to see that - that is something worth havign, for many many people.
So what is needed is Evolution for Windows eh? Kind of like this? I don't have Windows around anywhere to try it out, but it looks like it runs fine. I expect it still has a few kinks to be worked out, but it is certainly up and running, so not only is a port in progress, it looks like it is even usable already.
Technically MS has just enouigh of a war chest to manage those purchases, but of course there is no way they would fork over that much cash, nor be allowed to.