Making it stick.
Why Unix?
Better Living's
take on software the doesn't stink is fine, but this is a controversial paragraph that caught my attention...
For what its's worth, I think that open-source is no panacea, and in fact is one of the biggest black-holes sucking away human talent needlessly these days. How many man-hours have been spent building a clone of the 30 year-old Unix operating system? There are many better areas for us to be applying talent. And I don't mean to diminish the professionalism of Microsoft developers. The product teams here are some of the most well-tuned machines I have ever seen, but "best" is not the same as "perfect" or even "as good as possible".
(BTW --- What's the difference between "perfect" and "as good as possible"? Nevermind.)
I agree open source is no panacea, but I think it's a better Cambrian Explosion than the Procrustean Bed that is the Microsoft platform.
And why should one develop an open source Unix clone? For one thing, because one can! The ideas are well known and successful, which makes for the best patterns and lowest risk. That's what's known and now accepted as pattern-oriented software development, and so most software development in general should be like this. See Eric Raymond's book, The Art of Unix Programming.
There are many better areas for us to be applying talent.
But going all the way back to Stallman's instantiation of GNU, clearly (in hindsight!), there is a need for a platform for innovation. The platform should be well known and successful, but also unencumbered by proprietariness or the unspoken requirement to abide the vendor's cash cows.
Why try to innovate on a platform vendor whose not-so-implicit intention is ultimately to own any and every idea that succeeds? Enough said there, even so, "Why Unix?" should be *obvious* to a software developer for many reasons. None of which are, or need to be, "Because it rocks!"
Why PythonNet?
Gordon says Python is complete, so why PythonNet? I agree that Python 2.3 has a lot to offer out of the box. But I'm using PythonNet for the same reason I'm using Jython, as Gordon suspects, to get to the libraries in dotnet and the JVM, respectively.
In particular, in this moment, I want to get to SWT, Java2D, and GDI+ for drawing. I could just use the GDI+ DLL without dotnet, but the dotnet API is better. I also want to use other C# code from Python and vice versa.
By the way, I am also starting to use Cocoa via PyObjC for the Macintosh. Other than a thin layer of low level GUI and graphics, I have a growing capability to do "fully native" write once, run anywhere, from Python. Of course with Jython in the mix you have to be careful, since it is not up to the 2.3 definition of C Python. That's OK for now.
Why not just use WxPython? Because I want to use the native APIs and integrate with other native code and I don't want a layer as big as WxWindows in between. It's really not that hard. When you structure your system like this...
- Domain Model
- UI and Drawing Model
- Native UI and Drawing
...you can make the drawing model fairly rich because all the brushes, pens, clipping regions, and graphics contexts are at roughly the same level of detail and capability. But for the UI model I'm finding it's better to keep the abstract UI model very simple, essentially just a set of Commands, Tools, and basic Layouts that map to many more detailed UI objects at the lowest native layer.
That is, don't try to create a WxPython. That's too much work with little payoff. Who wants to program at that level of detail even if it is cross-platform? Let the high level UI objects *generate* all the low level GUI objects in a platform-specific way. Details to come, when I have more of it figured out!
Not on the Up and Up: Oil in the Caspian region
Also from Fresh Air on the 12th, listen to journalist Lutz Kleveman talk about his new book, The New Great Game. Pay attention to which side we're (the USA) on in the "game" for Caspian oil, then tell me we're in Iraq to liberate the people from an evil dictator.
Worse is to come: disgusted with the US's cynical alliances with their corrupt and despotic rulers, the region's impoverished populaces increasingly embrace virulent anti-Americanism and militant Islam. As in Iraq, America's brazen energy imperialism in Central Asia jeopardizes the few successes in the war on terror because the resentment it causes makes it ever easier for terrorist groups to recruit angry young men. It is all very well to pursue oil interests, but is it worth mortgaging our security to do so?
On the Up and Up: More evidence against the Semantic Web
Listen to the segment on this page with the linguist Geoff Nunberg. He addresses misunderstanding in conversations (the human-human kind). This is interesting unto itself, but throw in a machine and see what happpens.
640k: This memory needs error correction
Update: Jon Udell addresses this today from another angle, i.e. the query language instead of the data model. Here's his conclusion: It's about smooth interop between the next-gen Windows filesystem and the larger ecosystem it will play in. If Microsoft will be getting into the role of "schema provider" they'll have to do better than their recent Office XML provisions. The rest of us want multiple platforms and an unencumbered standard.
Ray Ozzie writes glowingly about the officially years-away WinFS file system. ...
Microsoft will obviously drive the initial schemas required by the core system - such as Contact - but where will it go from there?
Nothing two years away in the computer industry is obvious to me. One thing that is not obvious at all to me is why wait two years?
For one thing, Macromedia has a pretty good story with Central, which is based on Flash, is in beta already, and already includes a growing list of initial schemas, such as Contact. A second example is Chandler, which will also have a repository of arbitrary types of Items, including an initial set for the functionality that will come out of the box. Both Central and Chandler are attempts at a multi-application framework for "rich clients" bases on semi-structured information.
I could guess how such a set of schemas could be aided by WinFS, but is Microsoft making this point themselves? How do we know they'll get it right? Is there a convincing reason to wait for WinFS to begin?
Consider instead Google, Google Sets, and Syncato. These are all ways of structuring, searching, and organizing information in various bits and pieces. None of them require a new kind of file system.
I think we have what we need for the back end and front end of a new ecosystem of semi-structured information. I don't see how waiting two years or so for Microsoft is going to help. The key will be evolving these multiple attempts to be more aware of each other, not to wait for Microsoft to eventually get around to duplicating these ideas in some singular vision.
