The reviewer was just using the GC issue as an example of how patterns in the book tended to be C++-centric. This is a problem in the pattern community in general - patterns are presented as language-independent chunks of OO design knowledge, but in reality most of them are just the standard ways of getting around limitations of popular OO languages (which tend towards the lowest common denominator, like most popular things).
Don't just take my word for it, go check out Design Patterns in Dynamic Programming in which Peter Norvig shows that 16 of 23 patterns in the canonical Design Patterns book are unnecessary or much simpler in Common Lisp due to the availability of multiple dispatch, first-class types, and real macros.
If anyone in the executive branch had a technical clue, they could have implemented much of what you advocate without involving the Justice department, and should have years ago:
The National Archives could state that they will only accept electronic documents in documented formats, preferrably formats published by national/international standards bodies. Since most Government documents above a certain level, including e-mail and memos, have to end up in the Archives, this would force Microsoft to publish their data formats or lose the Government as a market.
The Government Accounting Office could declare that Microsoft is a single-source vendor, and as such their products require special dispensation to purchase. Along with a decision to require unbundling of software and hardware (they did it for IBM, remember?), this would give Linux an edge as a multi-vendor OS.
By and large, the military already requires documentation of formats for software written for them, up to and including escrowed source code. They have "relaxed" this requirement for off-the-shelf office automation software, and they need to tighten up again.
The operating system should give applications access to standard services via its API. The key word here is standard, as in published, widely available, preferrably with multiple independent implementations.
When Windows 95 came out with TCP/IP built in, nobody threw an anti-trust fit for the poor third-party vendors who had been selling it as an add-on. The reaction I remember was It's about damn time they did that.
This is the reason why "integrating" the browser into the OS is a bad idea. Browsing is too young and the standards are still not settled enough.
If Microsoft had been serious about providing browser services from the OS, they should have published an API that other browsers could hook up to via COM/OLE/flavor-of-the-month. That way they could have claimed to be "open", while extending that API and having Explorer be compatible ahead of the pack, their usual way of leveraging their ownership of Windows. Instead, they made a brain-dead technical decision whose sole purpose was obviously to kill off any other browsers.
Slashdot Mirror
Don't just take my word for it, go check out Design Patterns in Dynamic Programming in which Peter Norvig shows that 16 of 23 patterns in the canonical Design Patterns book are unnecessary or much simpler in Common Lisp due to the availability of multiple dispatch, first-class types, and real macros.
The National Archives could state that they will only accept electronic documents in documented formats, preferrably formats published by national/international standards bodies. Since most Government documents above a certain level, including e-mail and memos, have to end up in the Archives, this would force Microsoft to publish their data formats or lose the Government as a market.
The Government Accounting Office could declare that Microsoft is a single-source vendor, and as such their products require special dispensation to purchase. Along with a decision to require unbundling of software and hardware (they did it for IBM, remember?), this would give Linux an edge as a multi-vendor OS.
By and large, the military already requires documentation of formats for software written for them, up to and including escrowed source code. They have "relaxed" this requirement for off-the-shelf office automation software, and they need to tighten up again.
The operating system should give applications access to standard services via its API. The key word here is standard, as in published, widely available, preferrably with multiple independent implementations.
When Windows 95 came out with TCP/IP built in, nobody threw an anti-trust fit for the poor third-party vendors who had been selling it as an add-on. The reaction I remember was It's about damn time they did that.
This is the reason why "integrating" the browser into the OS is a bad idea. Browsing is too young and the standards are still not settled enough.
If Microsoft had been serious about providing browser services from the OS, they should have published an API that other browsers could hook up to via COM/OLE/flavor-of-the-month. That way they could have claimed to be "open", while extending that API and having Explorer be compatible ahead of the pack, their usual way of leveraging their ownership of Windows. Instead, they made a brain-dead technical decision whose sole purpose was obviously to kill off any other browsers.