Maybe breaking compatibility every once in a while is not that bad see cafe.elharo.com/.../java-is-dead-long-live-python

I fail to see why the default expression visitor is such a big deal. First of all, the public code isn't that great: the routines which visit lists of expressions are inefficient and overly complex, the other thing is that it lacks code for several expressions to begin with and it's not focused on extensibility with custom expressions. (e.g. it doesn't really implement the visitor pattern)

I.o.w.: you've to spend time on it anyway, and more than you might think with a public visitor. Furthermore, writing a linq provider takes such a long time that writing the visitor is pretty minor.

Though, if the visitor is seen as an example of a generic point that MS should open up more things to the public as they're writing a framework, not a product... agreed. The only drawback is... is what MS puts in the framework always good? Take the linked list class. It's so horrible, you've to write your own anyway.

In the case of Linq: what would have been much better is a generic linq expression interpreter which provided hooks when things were reduced, as most code of a linq provider is simply generic code unrelated to the o/r mapper used.

I've never really understood the obsession with backwards compatibility. As a developer consuming version 1 of library X, I would prefer version 2 to clean up any crappy APIs even if it forces me to change my code. I see this as a good thing, as long as every breaking change is documented and justified.

Yes, this means that if I write an application against .NET version 2.0, I'd be happy for it not to work against .NET 3.0 until I had migrated it. Happy.

And in those situations where some level of backwards compatibility must be maintained (eg. between a host app and its add-ins) then frameworks such as MAF can provide adapter infrastructure to achieve this compatibility.

Pingback from  Dew Drop - December 10, 2008 | Alvin Ashcraft's Morning Dew

Backwards compatibility is important because in my organization I have to work in 3.5, 3.0, 2.0, and 1.1 because the business isn't going to sponsor the cost of upgrading a 1.1 application to 3.5 'just because', yet when there is a bug we need to fix it, using 1.1 and VS2003.

In fact every organization I have worked in has been this way.   I have a colleague who writes a COTS product that they still have to support VB6 clients - why because if they say 'you must upgrade to our most recent version' those customers are going to say 'no I don't' and go somewhere else because they rather stick with their pricing plan and support plan and internal employees who write modules for the VB6 version than have to deal with make all those changes.

There is a domino effect to all of this, and to say it's 'not a big deal' is extremely myopic.

Brian,

I wasn't suggesting the business should sponsor an upgrade 'just because'. If there is no compelling reason to upgrade, then don't. Your application will continue to run on its target platform just fine, and that's my point. Just because there's a new, shiny version of the platform available doesn't mean you should be building against it.