Making it stick.
Crisis? What Crisis?
There really is ONLY one fact any American can be sure about: 9/11/2001 changed everything. Without that, we wouldn't be in the mess we are now.
I agree that the events of 9/11/2001 changed everyone's perception. The situation is really the same it's been since the 1970's oil crisis, let alone since the first attempt to bomb the WTC almost ten years prior.
Had real leadership been able to step up at that time to acknowledge that true security depended on energy independence from oil *and* nuclear sources, we'd have had a thirty year head start toward avoiding this mess we're finally perceiving first hand.
I was a teenager back then, but it was clear to me from the popular culture that the problem was at hand, yet in reality Carter was getting laughed at for establishing solar energy tax credits. In fact his response was pretty weak, but a start. Blinded by greed and lack of will, we are. Putting a man on the moon was trivial. Planning a truly decentralized democracy seems near impossible.
My favorite pop culture quote, from "Three Days of the Condor", 1975...
TURNER: Do we have plans to invade the Middle East?
HIGGINS: We have games, that's all. We play games. "What if...?" "How many men...?" "What would it take...?" "Is there a cheaper way to destabilize a regime?" That's what we're paid to do.
TURNER: So Atwood just took the games too seriously. He was really going to do it, wasn't he? Supposing I hadn't stumbled on the plan? Say nobody had?
HIGGINS: Different ball game. The fact is, there was nothing wrong with the plan. Oh, the plan was alright. The plan woulda worked.
TURNER: Boy, what is it with you people? You think not getting caught in a lie is the same thing as telling the truth?
HIGGINS: No. It's simple economics. Today, it's oil, right? In ten or fifteen years... food. Plutonium. And maybe even sooner. Now, what do you think the people are gonna want us to do then?
TURNER: Ask them.
HIGGINS: Not now. Then. Ask them when they're running out. Ask them when there's no heat in their homes and they're cold. Ask them when their engines stop. Ask them when people who've never known hunger start going hungry. You wanna know something? They won't want us to ask them. They'll just want us to get it for them.
Macromedia's Central
A friend asked via email,
"Isn't Central just for Macromedia developers?" and
"What effect will this have on portals?" My response...
Well, it’s for Macromedia developers in the same sense that Win Forms is for dotNET developers and WebStart is for Java developers. It’s competition, I am sure they want more developers. With a good strategy, they deserve people’s attention. With good delivery of the platform, they could win some. Flash is the #1 plugin on the web, and is the foundation for Central. Central as a vision goes way beyond Win Forms or WebStart.
There is some information in weblogs, not the main site, that Central will be addressing multiple languages. Still Flash is based on a simple component model and JavaScript, so there is familiarity even if a tough row to hoe against the Microsoft hordes.
A service-oriented architecture would be able to plug into server-side and desktop portals. I think this whitepaper expresses the vision of the desktop beyond the browser better than anything else I’ve read. How they deliver on the vision is the key. Portals belong on the desktop, and I think they will get there in the long-run. If Central is successful, maybe it won’t be so long.
I would expect this strategy to shake up Redmond the way Mosaic did almost ten years ago now. Microsoft has not put a vision together like this and will have to respond with more cohesion than what they’ve done lately with InfoPath, Office 11, etc. Whether or not Central succeeds, it should at least move the primary move and shaker up to a new level of vision it probably did not have last Tuesday.
EJB was the downfall of Java on the server
What I mean by "
EJB was the downfall of Java on the server" is that the EJB effort has taken time and resources away from what could have been done otherwise.
What could have been done otherwise? There's no telling. Paul Snively has some suggestions as does IBM's DeveloperWorks.
So broke it can't be fixed
What architectural limitations are in the new version? Is it worth the investment, or will the architecture of Windows 2003 suddenly break when you need a bug fix, but they need the revenue of an upgrade to Windows 2005?
The Register writes about NT 4.0, which is not so old that the architecture should be so different from Windows 2000, XP, or Windows 2003...
In a surprisingly candid admission, the company states that fixing NT4.0 is simply too difficult.
"The architectural limitations of Windows NT 4.0 do not support the changes that would be required to remove this vulnerability," Microsoft says.
RSS file fixed.
Thanks to a number of folks who pointed out my RSS file had bad XML. The URL in a link element had an upset stomach. Removed.
Central
Central has a lot of promise, a great direction. It's innovations could really tick certain people off.
The approach goes right to the heart of points I have been raising with "portal" proponents in IT shops. Occassionally connected computing. Some ideas that seem well thought-out.
BAM! There's some excitement in this as some concepts sink in.
CORBA and SOAP
SOAP is Microsofts second approach (after DCOM) to replace Corba. This time they may succeed, because lot's of companies support it, and lot's of developers believe it's so simple to write distributed applications using SOAP, because it's only XML after all.
Maybe it is not so ironic that just as CORBA was reaching a reasonable level of maturity (including viable open-source implementations), XML-RPC mutated into SOAP and took on a lot more baggage than I believe was originally intended. The CORBA-ish aspects of SOAP will take *years* to mature in terms of the number of usable, interoperable implementations, as well as in terms of well-known, reliable patterns of application usage.
I believe CORBA was more complex than necessary for 80 percent of the use cases. The collection of SOAP-related specifications are even more complex and less proven.
SOAP is inevitable though. I suspect simpler usage models would emerge if the standards committees and large vendors would step aside and let developers compete for real solutions.
Space-Based Programming
Another Java article from
OnJava about space-based programming. Unfortunately the language-independent, SOAP-based Ruple project from Rogue Wave is defunct.
Observing relational database development and object database development way up close for about 20 years, I'd say space-based programming is a simpler, more effective model for 25-75% of the situations where a relational database, object database, or message bus applied. (Yes, that's a pretty wide percentage, but I'm hedging my bets since it is not based on any real statistics. Even 25% of these sitations is a *large* number representing a good deal of time and money.)
Space-based designs are applicable to "application-specific storage", many "workflow" and "web services choreography" situations, many "EAI" or "message-based" situations.
MIME-RPC
Via the
Cincom Smalltalk weblog, discussion of
MIME-RPC.
MIME-RPC seems to have the simplicity of XML-RPC, but with some improvements.
Not very active though... maybe the recent traffic will lead to an few implementations.
Le Show
This week's Le Show is now on the web site. If your public radio station does not carry it, or if the show was pre-empted as it was on Oregon Public Radio, then
this is your link to real satire for the week.
Contents for March 23rd
- Extra Access Tonight: showbiz adjusts to war
- Richard Perle on the death of the UN.
- Apologies of the Week: ABC, BBC.
- Exclusive: Interview with one of Saddam's lookalikes.
A Simple Universal Compiler
Why do
major vendors of virtual machines require every language implementor to understand a low level "virtual CPU" architecture when
techniques like the following have been proven for well over a decade?
ABSTRACT: Realistic Compilation By Program Transformation, R. Kelsey
P. Hudak
Using concepts from denotational semantics, we have produced a very simple compiler that can be used to compile standard programming languages and produces object code as efficient as that of production compilers. The compiler is based entirely on source-to-source transformations performed on programs that have been translated into an intermediate language resembling the lambda calculus. The output of the compiler, while still in the intermediate language, can be trivially translated into machine code for the target machine. The compilation by transformation strategy is simple: the goal is to remove any dependencies on the intermediate language semantics that the target machine cannot implement directly. Front-ends have been written for Pascal, BASIC, and Scheme and the compiler produces code for the MC68020 microprocessor.
Toward Truly Universal Virtual Machines
The discussion of truly universal virtual machines has migrated
back to Lambda the Ultimate.
My thoughts, which I've repeated in a few different forums already:
The underlying mechanisms for the CLR as well as for the JVM *are* dynamic. The problems for making these systems universal are in the necessity to use nearly the entire language model of C# or Java, rspectively, in order to achieve any kind of integration.
A better approach, IMHO, would be to make integration more abstract and more loosely coupled than the "shared object model" of the CLR or JVM.
Components written in various languages should be integrated via a simpler, asynchronous, shared-nothing, message passing model. Then those components could be instantiated in the same OS process, a different OS process, or on a distinctly different host on the network, without having to alter the mechanism for integration.
A virtual machine in this model would offer a reusable implementation of garbage collection, component instantiation, time-sharing, channel discovery, message formatting, optimized "intra-OS-process" message passing, and an instruction set for sequential processing. A universal virtual machine would not require a shared-memory, monitor-based, object model.
I would choose Scheme as the "instruction set" of my virtual machine, and not make language implementors deal with low level CPU models.
