Car Purchase - SUV = Photovoltaic System

A Maryland resident, who installed a photovoltaic system and now contributes more juice to the grid than he draws, made the point on CSPAN that, at current PV prices, someone making a car purchase could buy a less expensive car instead of an SUV and have enough left over to install a PV for their house.

Given current events at home and abroad, would you recommend to your representatives to increase incentives and funding for making each of us net contributors to the grid?

Independence and self-sufficiency is the American way, no? This should be a federal priority at least as important as the federal highway system. A solar system in New York produces 80% of the output as in the Southwest, so this is more than a regional option, especially combined with insulation and other improvements.

Conversion would make a healthy contribution to the employment situation as well as the environment.

Data Warehouse Review has an RSS feed

Data Warehouse Review has an RSS feed. Have at it.

Update: Thanks to Karl Lewin for pointing out a typo in the URL.

Battery-backed RAM closer on the horizon

With both Motorola and IBM firmly lined up behind a single contender, the five-year search for a "universal RAM" technology offering a combination of non-volatility and high-speed random access appears to be all but over.

Among other things, MRAM is designed to eliminate several of the most infuriating artifacts of the computer age: the interminable wait for devices to boot up and power down, and those irritating operating system messages about "loading" and "saving your settings."

"Currently computers need to load information into local memory from the hard disk when the power is turned on, and that data transfer can't even start until after the hard drive has spun up to speed," Way said. "Whenever you shut down, data has to flow back in the other direction from the volatile memory to the hard drive.

"MRAM is designed to allow programs and data to remain in the local memory and may even, someday, allow us to simply reach out and touch an on/off button to turn off Windows in lieu of going through a ritualized shut-down procedure."

BTW, opportunities for software entrepreneuers abound.

Paper models

http://www.nedbatchelder.com/blog/200309.html#e20030905T073200

"The Factory" vs. "The Studio"

How many of you are software developers working in a location which is referred to as "the factory" by senior management, sales, and marketing? Maybe even by engineering management, since they tend to align more with the rest of the company?

This label always (and I have been hearing it and commenting on it for the last 20 years) struck me as odd and indicated more of a misunderstanding if not a misguided wish on the part of management. The last time I had a sit down discussion with someone on it was 10 years ago. Since then I just shrug it off and work on the bigger issue from other angles.

When I had that discussion I was talking with people who came from Tektronix, a manufacturer of oscilloscopes among other things, including then X Window terminals. (Does anyone remember those? Are they still sold?)

The analogy I made went like this...

TV designers get together in the lab and iterate over ideas. Those ideas take shape, and eventually are ready to be produced on an assembly line. The activities in the lab are design-time. The assembly is factory-time.

Software designers get together in the, well, cubicles, actually. Those ideas take shape, and eventually are ready to be copied to tape. (Remember shipping software on tape?)

The cubicle activities are design-time. The copying to tape is factory-time.

What's the significance? Factory-time is something step-by-step repeatable and can be treated and "optimized" as such. The cubicle time is repeatable in the sense that a carpenter uses basically the same tools and materials every time he builds a kitchen cabinet. But each time the kitchen is a different shape, the wood has different features, and the customer has varying tastes. What gets repeated each time is a creative activity.

The TV lab and the software cubicle are really studios. The only organization I know of that treats software as a studio process is Ken Auer's Role Model Software. The XP bull pens aren't talked about in these terms, but they should be.

Do I need to add that Ken comes from the creative Smalltalk community of the 1980s where software has long been seen as a collaborative, creative set of activities?

Software Factory at ASU

Although the name is horrible, the idea is commendable. Arizona State University has an organization called the "Software Factory". Their mission...

Here, as at other universities, software development is becoming ever more crucial to research. Researchers typically develop software by “ad hoc” methods, hiring students to do their programming. This works out in some cases, but more often than not the students lack experience in software development and the faculty lack experience in software engineering. This leads to a sub-optimal learning experience for the students and poor software products for the researchers.

The software factory idea, then, is simple: Gather these part-time student programmers in a common facility, put them under professional management and mentorship, and use sound software engineering techniques in the development process.

How to win friends and...

Mark Pilgrim writes of the launching of a new MSFT web service...

I’m going to repeat that, in case you missed it: the documentation for the web service is wrapped in a Windows installer which will only install over Visual Studio .NET.

I'd cry if I wasn't laughing so hard that tears are already streaming down my face.

Straight talk on EAI adapters

Sean McGrath gives us the business on EAI adapters. What a breath of fresh air. A truly useful economics of integration that lines up with the EAI vision if your intent on taking proprietariness out of the picture.

Here's how I interpret his hints toward an alternative for 80% of the cases a proprietary EAI solution might be purchased:

• A standards-based exchange format (like XML).
• A commodity TP monitor for simple transactions (like Apache, take your pick) (with a simple means of exchange).
• Commodity persistence (and perhaps some caching) (take your pick based on your budget, needs, and assorted risks).
• Finally a simple set of rules for coordination.

The hard part is already proprietary to your legacy applications and ERPs. Sometimes the term "adapter" seems intended to imply "easy to implement". Unfortunately customization, vendor quality and the "stovepipe" nature of EAI products themselves get in the way.

Distributed (and evolutionary) version control

The build instructions make this system seem a bit fresh yet, but Ted Leung points today to a very interesting version control system, especially for distributed open source evolutionary systems. In particular...

• defining different "acceptance criteria". monotone's update algorithm permits sorting and filtering by certificate; this means you can tell it to ignore changes until someone you trust is willing to attest to their quality, either by code review or test results. simply committing code does not force any other end-users to run it. (this feature is only partly finished -- the UI for it is still wired to one setting).
• decentralizing trust. monotone's operations are all based on checking RSA certificates. there is no central authority to which you must appeal to participate, or to be granted "commit access". on the other hand, nobody has to trust or accept your certificates, unless they happen to like you.

The Road Ahead

Don Box charts the course. If they get this particular item right, there's reason for a good long party...

Contain the growth of platform surface area - it's easy to design a complex framework - it's much harder to design a simple one. Now factor in ~30-50% growth in functionality with each release and my ears start to bleed.

To mix metaphors this is a tough row to hoe. Removing production features is almost impossible. Adding new features that don't conflict with or duplicate in some way existing features is hard enough. Merging features to get more expressiveness (increasing the power/effort ratio) is an art form that few people can even comprehend.

Consider arguably the most famous software framework: Smalltalk-80. The team's focus was on simplicity and a high power/effort ratio. They began (rounding off a bit) about 1970. They remained mostly under wraps for about a decade with significant evolutions about every two years.

Smalltalk-80 really hit the mainstream's awareness with the 1981 Byte articles. By 1984 several books were published and vendors from HP to Tektronix had ported the system to their hardware. In 2003 the Smalltalk-80 system is still recognizable, and even operates, within the many commercial and open source Smalltalk implementations.

The Smalltalk platform is still yielding results. Tektronix has had implementations running in oscilloscopes. Object Technology International (now part of IBM) has had real-time implementations (which have led to IBM's real-time Java implementations). And recently a 128kb real-time implementation has become available, including a TCP stack. How does this stack up to the dotnet "compact" framework?

A tough row to hoe indeed.

There are two classic platforms available today: Smalltalk and Unix (let's say BSD and Linux). Legitimate reasons exist for not building on either of them. But every new system should begin with these questions: Should either of these systems be the foundation for this new system? Why or why not?

Higher Values

An interesting article on "offshore" IT. ("Offshore" if you're in the US at least.)...

Libertarian IT workers who watch their jobs go overseas should derive joy from geographic shifts in employment. Their "dog eat dog" creed requires them to be happy whenever the marketplace finds a way to pay workers less and increase business owners' profits.

I thought this was an insightful connection with the seemingly disproportionate number of self-professed libertarians in the IT industry.

A couple of observations about this "offshore" movement...

• Of course capitalism and libertarianism are idealistic theories. They assume perfect knowledge and model behavior. The real world is not so tidy, and so dislocations have been and continue to be painful for all industries.
• More importantly in my opinion is this: when you choose to move some jobs to a lower cost market, or for that matter, when you choose to buy a product, "offshore" to cheaper labor, in some sense you are making a value statement of another kind. You are saying you don't care that the labor conditions "over there" are worse than they are "here".

What's that? We're talking about IT. How are labor conditions worse for IT workers? Well, for example, I am diabetic. Diabetic care in the US is great* but in lower cost labor markets even well off IT workers suffer from less advanced and available diabetic care. This is just one example that hits home for me.

So employers who move jobs "offshore" without providing equivalent benefits are very much saying they value their workers less. Maybe this is to simply stay competive with everyone else, maybe its to satisfy stockholders who demand growth or as much as possible in a down market. But this is still a value decision that should not be ignored for Adam Smith's sake.

In theory wages and benefits should average out. "Ours" will come down a little and "theirs" will go up. And in theory improved productivity will lead to advances in technology and society as a whole, and we'll all rise with the tide. Of course the difference between theory and practice in theory is small, but in practice it is great.

What do we really value? Are we making good choices that reflect our higher values? Don't they need jobs "offshore" too? Of course. There are no easy answers. Jobs should go "offshore" to capable people.

The real problem is we should be putting our governments (plural) to work to reflect our higher values. Governments should be made effective market shapers when the "natural" course of a market does not appear to be moving in a desired direction. What I think our governments need to be shaping is the development of "appropriate" technology. We cannot deny that we need to do more with less, and concetrate truly scarce resources where they will have the best long term benefit.

Can governments be so efficient as to reflect our higher values?

*(In spite of the fact that vendors are not eager to cure such a money maker, and religious fundementalists are not eager to appear yielding an inch to the abortion/cloning faction, yet stem cell research is neither.)

Use the source!

James provides a response to Danny's bare arse scenario.

I would add two things:

• Type information *does* add value, but it's generally not worth the cost.
• Having all the source code adds even more value, at very little cost.*

*Mark Weiser, "Source Code!," IEEE Computer, November 1987

Windley's gone off the deep end!

I know, you're going to hate this idea. You're going to say "Windley's gone off the deep end!" and "I'll never use Microsoft's ID program!" and "Microsoft will turn it to commercial advantage!" All of those things may be true, but the alternative, in my opinion, is much worse. At some point, legislatures, spurred on by their constituents, will undertake to solve this problem and no matter how well intentioned, you'll lake that solution even less---I promise.

I may not like a legislated solution but it has some advantages:

• I vote for my representatives. (They don't give me the time of day, but they do give me form letters.)
• I don't use Outlook at home. (I have to at work.)
• I don't use Windows at home.

But actually...

• There is no reason Microsoft cannot conform to a standard.
• I don't want this at all, from anybody.

Dell takes customers to a new low

He said he couldn't give me his phone number or mailing address, and that he didn't have a boss who could talk to me.

Who do they think they are, the cable company?

Accounting for Web Services

From Ephraim Schwartz in Infoworld: "From everyone I speak to, it is a foregone conclusion that Web services are a less-costly alternative than other integration technologies."

I sure would like to see some analysis of what these folks are claiming. What costs are they including or excluding? What systems are being integrated? What is the environment (departmental, enterprise, external, global, regional, etc.)? What are the architectural components?

I don't doubt that web services in general are the direction. That's a fete accompli. How people are using them currently, and how they are accounting for their success or difficulty is a topic worth exploring in much depth.

New Stuff, But Still Fun?

Gordon Weakliem's not having fun anymore...

I think I've had it beaten out of me, I've spent too many nights and weekends chasing down stupid quirks, stuff that's not even programming, just accounting and janitorial stuff. I still read programming books in my free time, but most books just depress me. That thought occurred to me while reading one of the Agile process books, so I quit reading about process and started trying to find things that would take me back 12 years, back to when Pascal was neat, and everything seemed easy.

Every time I put fun and programming in the same thought, I go to Ward Cunningham, who still seems to find ways to have fun.

Lately I have been enjoying PragDave's Katas. These get back to the heart of programming and don't require VisualJ2ESharpPlus. Just me, Emacs, and Python.

I am surprised and not surprised at the lack of an outcry for simpler ways to program. My fear is all the good ideas and fun will be left behind.

But XML-RPC is fun. And Chandler looks like it could be the source of fun. Eclipse only looks like fun seen through a Jython lens. (Jython is the best way to get an interactive experience with Java classes!)

dotnet will have the Jython kind of fun eventually.

XML + Java = Lisp?

What I just wrote about interactive programming with various languages brought up an old thought, and I'm not the only one to think on this. But I've not read anyone else with this same angle. I wrote...

Lists, maps, arrays, even self-referencing structures can all be entered end edited in a command loop or workspace using a very simple (i.e. few characters) syntax. There are also the mundane (now that Java brought them to the masses) aspects of these languages like garbage collection and array bounds checking.

How I believe the Java-like family will get even closer to this experience is via XML. Complex structures (i.e. nestedt structures as well as "primitive" values) is fairly simple in XML. The Java family of languages will eventually make the leap from XML constants expressed as strings and DOM'ized via a library. They will leap to the world where the DOM and the expressions are "native". These will be the "self-referencing structures that can be entered and edited in a command loop or workspace" that Lisp programmers have been doing for 40 years.

Then someone will create a Java with transparent persistence with shared paging so the structures don't all have to be in memory. Oh wait, been there, done that (more than once), and literally have several of the T shirts.

Of course these language communities first have to get over their fascination with such things as "generics" and "partial types", etc. Think simple. How simple can you go?

Close, but no cigar

Don Box disagrees with Jon Udell in this dynamic language discussion.

Jon writes: I think dynamic languages and interactive programming environments help make us better explorers and discoverers, and I think that's only going to matter more as time goes on.

Don counters: My confusion comes from Jon's conflation of dynamic languages and interactive programming environments... During the late 1980's, I used Sabre C[++]. Sabre was a highly interactive programming environment for C and C++... It's been almost 15 years since I've used Sabre or Smalltalk, but honestly I'm having a hard time remembering what you could do in say Digitalk's smalltalk environment that you couldn't do in Sabre.

I also used Sabre. Prior to Sabre I used Zeta C, which was a C implementation for Lisp Machines. (Get your head around that! Yes, Lisp Machines had Fortran, Ada, C, and other language compilers.) Zeta was even better than Sabre.

Language design absolutely makes a difference beyond interactive environments. This difference is what makes these languages good for exploration and discovery over more cumbersome Java-like languages.

Lisp, Smalltalk, (dynamic languages I have decades of experience with) as well as Python, Ruby, etc. have good support for not only making prototype code, they also have good support for making prototype objects and data structures.

Lists, maps, arrays, even self-referencing structures can all be entered end edited in a command loop or workspace using a very simple (i.e. few characters) syntax. There are also the mundane (now that Java brought them to the masses) aspects of these languages like garbage collection and array bounds checking.

If I had to do C or C++ programming I'd do everything in my power to use an environment like Sabre or Zeta. At a minimum I would use a conservative garbage collector (e.g. Boehm's) unless the delivery environment really could not support it.

Yes, there are languages and tools that are edging closer to the best dynamic languages. Coming from another angle we have ML, Haskell, etc. with their own advantages. But for overall programming experience, most common situations would benefit from a simple language and toolset like Lisp, Smalltalk, or Python that have been around for 10-40 years!

Is the wiki now just coming into its own?

I believe a case could be made that more innovation is taking place with Wikis today than with weblogs. Clay Shirky writes...

A wiki in the hands of a healthy community works. A wiki in the hands of an indifferent community fails. The software makes no attempt to add 'process' in order to keep people from doing stupid things. Instead, it provides more flexibility, a crazy amount of flexibility, and intoxicating amount of flexibility, allowing massive amounts of stupidity and intentional damage to be done, at will, by roving and anonymous posters. And it provides rollback.

That captures it for me. Supporting evidence of my thesis include the Bliki and the Purple Wiki. Not to mention the Atom wiki.

It's not up to me anymore

Don Box responds... I didn't realize I was a static typing loyalist.

Don't look at me. I rely on my Bayesian categorizer (PDF) for such distinctions. 8^)

Software Development Seen Continuing to Suck in Near Future

Chief Software Architect and Chairman Bill Gates has publicly described the company's goals to add support for model-driven development to Microsoft products leading up to the release of the company's "Longhorn" operating system, expected in 2005.

I am not convinced that IBM bought Rational for UML. The Three Amigos were last seen riding off into the sunset following the ascent of XP.

The IBM deal I think was driven by tools like ClearCase maybe, but more specifically for the embedded market.

Can MSFT make MDA shine? Maybe.

Dynamics: The Language Counts

Don Box continues to come to terms with dynamic languages...

More and more, however, I'm less convinced the problem is with languages per se but rather is related to how dynamic linking and binding works in most modern object systems...

The problem is that we bake a fair amount of non-semantic information into the way their code compiles against those assumptions.

...then steps back with Perl as the red herring...

I don't think the answer is for everyone to adopt Perl - if that's our only hope let's give up now.

By "non-semantic information" I guess he means "syntactic sugar"?

In any case, I think Don is half right. It *is* about how dynamic linking and binding works in a system. But how that works is intimately associated with the language design.

Have you ever used an interactive environment for a Pascal-like language? It is a very different experience from using one for Lisp, Smalltalk, or Python.

I won't mention Perl. That's the red herring for static typing loyalists.

Annoying tuple syntax: partial solution

Victor Ng writes about Python's tuple syntax for length one tuples.

Not that I use a lot of explicit length one tuples, but here's something you can do instead. Redefine the tuple function to accept non-sequences. If so, just put them in a length one tuple.

def tuple(x):
    try:
        return original.tuple(x)
    except TypeError:
        return original.tuple([x])

Then you can express an explicit length one tuple as tuple(x)

Compound Documents

In terms of big picture ideas, open source is running out of things to copy. Here's something that hasn't been done yet.

Interesting claim about big picture ideas. I never thought of that.

I do agree that "smart clients" is a ripe area for innovation. I never used OpenDoc.

I wonder if Eclipse is a good platform for these ideas?

Checked Exceptions and Encapsulation

Are checked exceptions a good thing? Do they break encapsulation?

Consider an analogy.

I don't think checked exceptions are necessary. I think they can provide value.

But the cost of maintenance of static checking in Java is not worth the cost. What is my evidence?

I am more productive in Jython, which is capable of dynamically handling checked exceptions at runtime without the cost of static checking.

Let me illustrate my point with an analogy.

Consider an application command processor. The application has many functional areas. Each functional area has multiple commands that can be processed.

I can define a command abstraction and a command processor that works on the abstraction, independent of the specifics of any one command and any functional area.

In this case the commands are encapsulated and the command processor only has to be written once. New commands can be added at any time.

Now say the commands have names. And say that optionally a command can be designated as "checked", i.e. that at compile time the command processor must declare its awareness that some functional area is providing such commands.

Has encapsulation been broken? No. The problem is that named encapsulations are checked at compile time.

Is this a good thing? You decide the value.

Does it have a cost? Yes. The command processor has to be updated whenever a checked command is added to the system.

Meanwhile FFIs

Microsoft continues to get its dynamic language support going for the CLR.

Meanwhile using foreign function interfaces appears to be a somewhat viable approach for integration when SOAP/XML-RPC won't do...

• Scheme
• Python
• Smalltalk

VM-volution

From James' Cincom Smalltalk blog...

Also of interest is the fact that the JVM remains frozen, making sure that actual progress in Java-land is limited. Microsoft seems to realize that's a mistake, and looks like they will be extending and changing the CLR as time goes by (in particular, they seem interested in adding better support for dynamic languages). Meanwhile, the Java folks are stuck with an early 90's vision of what a VM can and should do....

Funny thing is... there is a fully capable instruction set in silicon underneath each of these VMs. But the source language has to fit through what in these cases are crippled VM instruction set "keyholes", losing all of the useful higher level information on the way, before getting executed in that silicon.

Can we call a halt to this madness yet?

The Wi-Fi Business

Starbucks is just trying to cover its costs. Sure, leasing a broadband connection with a Wi-Fi base is cheap. But add a billing system - secure login server, transactional database, credit card processing, tech staff, customer service operators standing by - and the outlay skyrockets to $30, $50, even $70 a day, particularly if there are lots of support calls. (Ironically, most of those calls will be about problems with the billing system itself.)... Wi-Fi isn't a luxury or even a commodity. It's a condiment.

Let's look at Wi-Fi in a different light. Where's the vision and the leadership? I believe Wi-Fi is the highway system, the printing press, and the bill of rights rolled into one mechanism.

If we leave out any of these three concepts then we lose.

Don't go straight down - curve and bend

When you drill an oil well, you don't go straight down, you curve and bend - maybe later when you find the reservoir, you will go straight down, but not during exploration.

Richard P. Gabriel's Patterns of Software book is now on-line (as a PDF noted in many Internet locations already). My favorite parts are in the autobiography.

GCJ to save Java?

A friend of mine, prominent in the patterns community, told me when the Design Patterns book came out he believed that book would extend the future of C++ by a decade. He may have been right. (Since then other factors such as Boost have had a big influence as well.)

I am here today to make a prediction myself.

I believe that the GCJ compiler for Java will have a substantial influence on that language's future, maybe extending Java's future by a decade. This compiler will itself boost Java on the server, and in conjunction with Eclipse/SWT revitalize Java as a key language for desktop applications.

Moreover a secondary effect will eventually be to influence Microsoft's dotnet approach.

GCJ is a presage of the end of the virtual machine.

Understanding Computers and Cognition

From Loosely Coupled...

speaking the same language as someone else doesn't necessarily imply you'll understand each other

A nice thin book that should be a part of every computer science degree program is Understanding Computers and Cognition: A New Foundation for Design by Winograd and Flores.

And anyone who names his software "SHRDLU" has my vote.

Sharepoint and Wiki

How do you feel about SharePoint? [<-- edit this Wiki page because it's easier than pointing you to a SharePoint page!] Not long ago the product was being considered a Wiki-like replacement.

My limited assessment time so far tells me I'd rather have a Wiki or a Bliki with perhaps a few small thought-out additions.

Using SharePoint results in about a 10x decrease in effectiveness for similar goals. The threshold for just ignoring a tool for me is about 2-3x decrease. I'll use SharePoint because I have to in some cases. But I am saddened that it's just there because it's from MSFT, as opposed to being there as a result of an evaluation.

Corporations don't get Wiki by and large. They're too simple to be understood in an evaluation.

Benefits of the California Experience

From Harry Shearer...

Having every phase of the campaign, from deciding to run to fund-raising to debates to voting, be compressed into a mere eight weeks may turn out to be a fine advertisement for a radical shortening, on the British model, of American election cycles. Don't bother to thank us in California, we're always working on your future.

Video Conferencing vs. Video Applications

When it is hooked to his Mac, Zeedar can use the camcorder as a webcam for video conferencing. But when his TiVo is plugged into the camera, Zeedar can broadcast pay-per-view soccer games to others.

"It's very cool," said Zeedar. "He can watch my soccer channels from his home. Or anywhere, really."

I see a lawsuit on the horizon.

Past that horizon though are video applications. This matches what I experienced when I was developing video conferencing systems about ten years ago.

The big lesson was that people don't want to look at talking heads. They think that is cute, then collapse the video window and get on with the meeting.

People do want to use the video for applications. The primary one used to be to detect "presence". Of course video is not necessary for that today, but it was a convenient mechanism back then. Other applications include sharing some information that is physically not "in" the computer. With better 3D shape recognition watch out.

As video (and video editing BTW) becomes ubiquitous new applications like Zeedar's will change business models and improve communication. "Pure" video conferencing will fall by the wayside though.

Symbol Grounding

Jon Udell writes about RSS, RDF, and XML in general...Stefano's formulation suggests to me that the troubled relationship between RSS and RDF may have been a red herring all along. Either we do or don't need some higher-order model to manage mixed namespaces sanely. Nobody knows yet. That the question arose in the context of RSS may simply have been an unfortunate historical accident -- RSS happened to be a likely candidate for the necessary large-scale experimentation, and got caught in the crossfire...

Shouldn't we then substitute XML for RSS 2.0 in that sentence, and say there is no consistent way to interpret material from other namespaces in any XML document, period?

Shouldn't we then say, there is no reason to create any mixed-namespace XML document that is not RDF?

This is beyond RSS, beyond RDF, even beyond XML.

This is known as The Symbol Grounding Problem.

Namespaces allow you to create unique (enough) symbols. There is no consistent way to interpret them. All XML-based standards should fully support namespaces. The minimum acceptable standards should support distinguished symbols from among various standards.

What those mixtures "mean" in any specific context will be, well, context dependent. All we can hope for from XML alone is an arrangement of symbols. Whoever tells us of the arrangement will also have to tell us how to interpret the arrangement.

Seven Paradoxes of Object-Oriented Programming Languages

David Ungar is giving a keynote at OOPSLA 2003 on the Seven Paradoxes of Object-Oriented Programming Languages. He writes...

Many of these assertions seem nonsensical, misguided, or just plain wrong. Yet, a deeper understanding of these paradoxes can point the way to better designs for object-oriented programming languages.

Apparently this will be a worthy companion to Guy Steele's keynote on growing a language in 1998. I'd like to see their respective points integrated. Growing a language will have varying results depending on where you begin. The beginning and the growing have to respect the paradoxes.

• Because programming languages, development environments, and execution engines are intended for both people and computers, they must both humanize and dehumanize us.
• Adding a richer set of concepts to a programming language impoverishes its universe of discourse.
• Putting a language's cognitive center in a more dynamic place reduces the verbiage needed to accomplish a task, even though less information can be mechanically deduced about the program.
• The most concrete notions are the most abstract, and pursuing comfort or correctness with precision leads to fuzziness.
• Although a language, environment, and execution engine are designed for the users' minds, the experience of use will alter the users' minds.
• Object-oriented programming has its roots in modeling and reuse, yet these notions do not coincide and even conflict with each other.
• A language designed to give programmers what they want may initially succeed but create pernicious problems as it catches on. However, a language designed to give programmers what they really need may never catch fire at all

Transaction Manifesto

I attended a lecture by Maurice Herlihy on the "Transaction Manifesto". The paper on his site called "Software Transactional Memory for Dynamic-sized Data Structures" reflects the same ideas. This was an interesting talk and the rest of this post explains my interest. Moreover I've now added Herlihy to my list of interesting CS thinkers based on a number of papers and software systems available at his site.

The talk was more of a plea to implement a transaction mechanism in hardware. The argument is that "compare and swap" and similar read-modify-write instructions are too low level.

"Too low level" means there is a lot of complexity in the software between the CAS and the mechanisms that programmers desire. The suggested instructions would operate on more than two memory locations and the locations would not necessarily be close to each other.

The ideas are derived from database concurrency mechanisms, i.e. simple transactions with a begin, some instructions, and a commit or rollback. Essentially this treats RAM like a simple database.

A couple of thoughts came to mind:

• Combine these kinds of instructions with battery-backed RAM and you've significantly simplified the implementation and improved the performance of database mechanisms.
• Next, going back to the discussions around virtual machines this past week, this level of concurrency control should at least show up at the virtual machine level. Why emulate a 1970's instruction set?

Much effort is spent ignoring or recreating lessons learned in the database community. Apparently in hardware as well as software. Alan Kay has wondered why Moore's Law, although wildly accurate and beneficial, has not translated more proportionately into software improvements. Here is an example.

Tech Sector or Taliban?

I'm not sure what this means, when joining the Taliban is more attractive than working in the tech sector.

Service Orien... what?

Service Oriented Architecture is the thing, I guess. But I just found myself wondering when the OS vendors are going to make it easy to install new services. It's a mystery unless you have something like the Erlang OTP running.

Any idea?

It's the content that counts

John Robb asks... isn't The Register just a poorly formatted weblog?

Good point. I personally care about...

1. Content
2. Connections
3. Presentation

Weblogs, Wikis, Pages. If it has useful information and I can find it and make sense of it, it's good to me.

Science Matters

There's a discussion on /. about non-professional books for science and math.

Going back a few years the book Science Matters is a really good, broad, but short and readable-on-a-beach survey of science. Just enough of basic science to keep you out of trouble.

Transformation, JIT, and Security

I'd like to elaborate on the interesting ways Kelsey's transformation approach addresses the following features of virtual machines (from Ted Leung).

"Virtual machines get you portability, the ability to do JIT compilation (although this could be done in native code apps), and security (via sandboxes, etc)."

Portability Kelsey's approach gets you portability to any low level instruction set. Language providers translate to a high level intermediate language. In his case this is Scheme, which is essentially the call-by-value lambda calculus.

Only one programmer has to provide the translation to any specific instruction set, whether it is for a virtual machine or actual metal. Everyone else rides for free.

JIT The intermediate language can be passed around (in a concise format such as the one used by SISC) until such time as it makes sense to transform it into a specific low level instruction set. This has the benefit of delaying the commitment of target architecture longer than a virtual machine architecture provides. Specific distributed objects could be migrated to some unspecified target at run-time and compiled to efficient code, along the lines of Kelsey, et al.'s Kali Scheme.

Security This is the most interesting test of all of the high-level transformation approach. Basing the intermediate form on function application is a beneficial form of security. The high-level model of computation can be analyzed and/or encapsulated more effectively than a low level byte code.

Low level virtual machines are an undesirable model for security. Kelsey's mate Jonathan Rees describes how this alternative works in his and Kelsey's implementation of Scheme.

Binary XML == gzip?

I would venture that the resource constrained platforms are going to be passing relatively small documents anyway. Even the more capable systems should be passing multiple small documents instead of huge documents.

Let's just use gzip.

Quote...

As predicted by Dick Cheney on le show, the Dr. David Kelly story has slipped from America's journalistic radar. But it's still big news in the UK, as is the subsequent war between Tony Blair's government (backed by Rupert's newspapers) and the BBC. I have become a believer in reincarnation: Spiro Agnew is alive and working for Tony Blair, and, in this country, Dr. Fred C. Schwarz (of the Christian Anti-Communism Crusade) has come back as a leggy blonde anorexic.

The 64-bit Question

James Robertson asks the 64-bit question for Smalltalk.

Implementing dynamic languages with 64-bit words always had an appeal to me for this reason:

You can encode 64-bit floats as literals. Everything else can be encoded within a NaN. The result is that arrays of large floats are more efficient in space and time, enabling more efficient analytical computing. You can also encode more information in an immediate object, like characters with styles, full 32-bit integers without shifting tag bits, etc.

Jython

I am beginning to believe this sincerely. Note that it does not say "only weapon", but it does say "most compelling"...

Jython, lest you do not know of it, is the most compelling weapon the Java platform has for its survival into the 21st century

SOAP for Lisp at last

Franz now has a SOAP implementation for Common Lisp. Great news.

"When I last looked at SOAP it was annoyingly complex. But that doesn't mean it's not important..."

What assumptions are *you* making right now?

Perl 6 looks to be delivered on the Parrot virtual machine, which looks to be more and more suitable as a target for the full Scheme language.

If the goal is truly to provide a universal base for executing any language then toss out the virtual machine altogether. Or at least abstract it away for language providers.

Don't make them twiddle with bits just because they implement "compilers". Let them simply translate to another higher level language, as Richard Kelsey demonstrated well over ten years ago!

We (the industry) seem to be stuck in a virtual machine rut. Has anyone asked why that's a good idea?

My track coach in high school told me what "assume" means 25 years ago. We base soooo much on unproven assumptions in this industry.

"Perl 6 to Scheme. Come in, Scheme."

Multiple Canonical Models: Databases or Messages?

Martin Fowler urges the data people and messaging people to talk, but not to define a single model.

This makes sense whether you are talking about enterprise databases or enterprise messages. I would add two points. The final one, if you want to cut to the chase, is addressed pretty well by Cutter's Doug Barry.

The first is that although enterprise models are not easily "big designed upfront" there are proven techniques for supporting their emergence. The best I know of comes from Ralph Kimball, who I've written about before in the context of enterprise integration.

The other point I would add is that Martin is really addressing at least two significant issues. In addition to the perils of enterprise modeling, he's made an implicit point about messaging and databases. I'm not going to put words in his mouth but he could have pointed to his peers efforts to illustrate what he means by enterprise messaging.

I am not sold on the idea of general messaging. There are special cases where a high performance message product makes sense, e.g. broadcasting large volumes of financial information on a trading floor is the motivating example.

In the general case, messaging is just too much like a crippled database that assumes the consumer is not the provider. You end up with an additional product and all the associated costs. I think there is a lot of room for improving 80 percent of the cases a relational database is applied to, but not at the expense of an entirely new and yet severely limited product like messaging. (Hint: every messaging product has some kind of simple persistence mechanism you can't get to in a general way. Why?)

I would choose either low cost databases for Martin's integration scenarios, or, more ideally, a simple XML-based tuple space-like database. Either approach can be used in a myriad ways without assuming the consumer is not also the provider.

Doug Barry kind of addresses this issue in a Cutter report. He is a fellow traveller from the Object Oriented Database market. A full OODB is overkill. So is a full relational database, but at least they are commodity and not so esoteric.

This second point is we need simpler database products rather than messaging products.

Less Code == More Productivity

Via Lambda the Ultimate we see Don Box wanting less code to espress a simple concept. This makes sense and corresponds to the conventional wisdom that programmers can get X lines of code running per day no matter what the language.

Reading between the lines the argument is that *explicit* static typing is just not a good idea, period. Dynamic languages and static languages based on type inferencing are the result of taking this direction to the limit.

I am not convinced static typed delegates vs. static typed classes in and of itself is that significant. Why not simply be able to pass methods around as first class objects without having to declare somewhere that it takes no arguments and returns a boolean? In a large post-modern system there will be at least a half dozen different such explicit declarations for programmers to keep track of.

Jython provides an example of how anonymous classes can be replaced by simple functions rather than pre-declared "delegates"...

In Java...

Button button = new Button(parent, style);
button.addActionListener(new ActionListener() {
    void actionPerformed(ActionEvent e) {
        // Take some action here.
        }});

In Jython, this can be replaced with a keyword parameter and function argument...

    button = Button(parent, style, actionPerformed=self.actionPerformed)
    ...
def actionPerformed(self, event):
    ## Take some action here.

John Robb's New Location

John Robb's new site is up. Great.

Jess in Action

I came across a new book on rule-based expert systems with Java and Jess. No review yet.

Agile Concurrency

From the Manageability weblog comes the question and some answers about the ability to hide concurrency issues through one form of abstraction or another.

Functional programming is dinged for not having a concept of state or time. This is a misstatement. There are several ways to represent state and time in functional languages. It's just that none of them are that much better than they are in other styles of programming.

Toward the end of the item there are some subtle observations...

In short, it's all about coordination, and if you can build effective coordination mechanisms then you're on the right track to solving the real problem. To say that it can be abstracted away isn't solving the problem, it's denying the problem exists.

Ah, but what the item does not address is what are the various ways of abstracting concurrency. Abstracting does not always mean "hiding 100 percent".

The key is to build appropriate abstractions for representing concurrency, rather than hiding concurrency. For example an effective technique for avoiding deadlock is to assign an order for aquiring resources.

The difficult attempt would be to hide the fact that multiple consumers are competing for multiple shared resources. The typical attempt would be to explicitly code the competition using some low level locking mechanism.

The "just right" attempt would be to evolve an API that describes the desired order of consumption, holding on to multiple resources (or not), and the exceptional behavior for waiting.

One thing we need are better modeling and testing frameworks for concurrency scenarios.

We can also simplify the API evolution through higher level concurrency mechanisms like tuple spaces. Tuple spaces provide a few simple operations that act as building blocks for a wide variety of scenarios. They can be applied to in-process, multi-process, and persistent or transitory scenarios.

Python and Open Office

Python just became that much more interesting for programmers not sold on it yet.

Word comes from Kevin Altis on work done by Ralph Thomas, Joerg Budischewski, and Christian Zagrodnick on "Python-UNO bridge for OO1.1", a Python integration with the Open Office API.

Great news for open source desktop software and developers.

Jython half-assed? Nah. It's full-assed.

Russell Batie is learning Python, but I wonder if he has really tried Jython...

Basically, I can't help thinking that Java could be made to work more like Python. I mean, there's Jython, but I don't want to talk about half-ass implementing Python on Java, I'm talking about making Java more programmer friendly like Python.

Jython is a complete Python. (Full-assed?) I would argue that Jython can also be considered a "Java made to work more like Python".

Java is established. I don't want to see the language change (much) at all. Jython is the Python way of programming with the Java class libraries. The two work together well, but one should not become too much like the other.

The distinction is beneficial and harmonious.

There's More to Menus...

...and more to Henry Lieberman, himself one of the seven (or so) wonders of the software world.

A favorite from 1986's first and perhaps best OOPSLA, "Using Prototypical Objects to Implement Shared Behavior".

Another Lieberman classic not given nearly enough exposure, "There's More to Menus than Meets the Screen".

Appreciating PLATO

PLATO is one of the seven (or so) wonders of the software world. Not given nearly enough attention.

Subtle Lessons About Architecture, Planning, and Design

More than one of my favorite stories about programming comes from WyCash.

Hypercard

Hypercard (see Ward's stacks) is still high on my list of good ideas.

The number one item from the OSCON session by Robert Lefkowitz (r0ml) on "The Missing Open Source Projects" is...

Distributed CRON

I would look to the Erlang framework for this. Simple, distributed, robust, persistent, monitored, and integrated. I'd guess the Erlang OLTP is well above 80 percent of what is needed for an industrial strength distributed CRON.

More systems should be emulating the Erlang framework for distributed systems development. (Assuming programmers by and large are not going to adopt the Erlang language per se.)

Test-first is a command line interpreter for non-interactive languages.

Jon Udell is investigating Test-First (aka Test-Driven) Programming...

Test-first is quite radically different from test-later. And the most important difference I've discovered so far is that test-first... is as much a tool... exploration of the problem domain... as it is a way of protecting against regression.

You've got it Jon. I think of it this way...

Test-driven design tools are "command line interpreters" for Java, C#, and other "non-interactive" programming languages.

Programmers using Lisp, Smalltalk, APL, and other "interpreted" languages have been doing test-driven design for decades. The pattern here is to type little snippets of code for an idea, get immediate feedback, then gradually incorporate those snippets into a whole program.

Lisp has its read-eval-print loop. So does Python. Smalltalk traditionally has "workspaces" which are text editors that also evaluate highlighted code.

In either case, the end of a programming episode results in a transcript of code that is then allocated to two destinations... some of the code in the transcript are the objects or functions that go into the program itself. The rest of the code is edited into regression tests.

Looking at a test-driven incremental programming session using junit or nunit you see the very same result... the shell is the command line and xUnit is the "interpreter". You get a small idea, test it, and repeat.

The tests themselves are the "transcript" of the session, and are also the preserved regression tests.

This approach is so successful that it provides discipline for Lisp and Smalltalk programmers too. I think Kent Beck originated sunit (for Smalltalk) as a way to demonstrate to new Smalltalk programmers how to use workspaces effectively.

Award for best proposal at OSCON...

...goes to Kevin Altis for pushing hard for Jython as a scripting language plugin for the Eclipse IDE.

Award for best Bigco using OSS...

...goes to Ticketmaster for a very plainspoken description of their use and relationship with OSS software and people.

All I know is what was presented, asked, and answered in the session. That said, they appear to use OSS to their advantage, manage it well, and give back to the community including hiring good OSS developers to implement features they need and that the community at large can also benefit from.

Award for most unexpected OSCON demo...

...goes to DJ Adams and Piers Harding for their servlet written in ABAP, the programming language inside SAP R/3.

Maps on the Wire

Yesterday at the Applied XML conference an involved discussion took place about complex types, specifically a Map (aka Dictionary, associative array, property list). I was thinking about the origins of the problem more than the problem itself, because it didn't seem like such a problem in the first place.

Only in languages derived from C could Map be considered a complex type. (I translate "complex" to "unusual"). The major scripting languages (Perl, Python, Ruby) being discussed this week at OSCON have this type as the bread and butter of their existence. There is nothing complex about it, and you couldn't dream of connecting processes with these languages without passing Maps around.

The Great Ancestors of these languages, Lisp and Smalltalk, were created by the Gods themselves (MCarthy, Kay, et al.) fashioned out of the true primal matter, which is not int, but association.

When Dave Winer froze XML-RPC (I don't know much of the details), it's most notable that it consists of two fundamental structuring capabilities: a list of things (called Array) and an association of things (called Struct).

No one argues over this. Every language has an XML-RPC implementation. It's funny that three or four years later the descendent, SOAP, is still wrestling with such a fundamental construct.

I think has more to do with ancestry than technology.

Subversion from Within: Python in a Java World

Attended Dana Moore's session on Python and other dynamic languages in a Java/dotnet world.

Fun demo manipulating the Microsoft clippy guy from Jython via XML-RPC to CPython manipulating the clippy guy's active X thinga-ma-thing.

All is love when it comes to dynamic languages.

Paul Buck, IBM, Eclipse keynote

November 2001 - Eclipse launch

Tools don't work well together. Tool vendors reinvent wheels. No vendor can do everything.

In Java no platform with strength of MSFT's Visual Studio.

Eclipse is a platform - extensible. Works out of the box. Companies contributed tools right away.

OSS chosen to support platform adoption.

"Tool stacks" per language type innefficient.

Eclipse is not a tool with an API. It is a platform for plug ins. Turns the picture upside down.

Small runtime + plugins. Plugins extend other plugins.

Architecture and demo (John Wiggin?)... internal team plays by same rules... plugins on small kernel... as all developers.

Team facility, repository support in OSS and commercial... (I guess this ties in to O'Relly's network collaboration talk)

Debug component... (who debugs programs?)

(Eclipse if you have not seen it is a Visual Studio look alike to my untrained eyes. Lots of panes with information here and there. People like these, I've not used them. Interesting challenge... I wonder how simple the UI could be made and still take advantage of useful plugins. How tied are the plugins to the UI look and feel? COuld you build Emacs in Eclipse?

(Talked with Kevin Altis last night... he's big on getting Jython into Eclipse as a scripting language. I've been doing a good bit of SWT programming in Jython outside of Eclipse... I think this would be a good idea and would lend toward getting an Emacs like capability into Eclipse, and could thus support a simpler interface Look and Feel for Emacs die hards at least. I'll look these guys up afterwards... this would be a good test of the plugin architecture, so maybe a few folks would like to collaborate (phrase of the day))

(Paul Buck is talking again...) COBOL development environment. Hades test framework. Eclipse modeling framework - abstract data types.

Technology PMC - further out, independent, experimental work, academics. "Coy" project (?) led by Instantiations (Portland!) doing something interesting... didn't say what. They're Smalltalk people, though and have done good tools stuff there.

New project for J2EE tools started last month looking for collaborators. See Eclipse.org

Next big step is moving beyond IDE into rich client platform. (Hmm.) SWT GUI toolkit for desktop Java applications.

(Hey - and desktop Jython applications!)

So new set of challenges... (well what are they?)

In closing... Websphere studio workbench is branded supported version from IBM. THE END

Tim O'Reilly's Keynote OSCON 2003

The value of Amazon, Google, etc. is the constant update via the people.

Network collaboration - Usenet is the mother.

Ad hocracy (Doctorow) - OSS is one.

Software paradigm of the future => *Collaboration* paradigm of the future.

Collabnet puts in OSS infrastructure inside organization's firewall, e.g. HP's printer drivers.

ASP.net reengineered ASP for XML - denied, backward compatibility. Six weeks time to hack it anyway. People took pieces of code here and there they liked then Gates annointed.

Network + Developers == OSS-like behavior.

"Listening to Napster" - keynote at a P2P conference. People can build a collective work as a by-product of their own self-interest.

Watching connections in Google, Amazon, elsewhere e.g. - we contribute with every link, book, etc.

Linus - essay in Open Sources - architecture of Linux and Internet supports individual contributions that add up.

Just now in throws of figuring out new business models. IBM Websphere, Mac OS X look like the Compaq business model. Selling commodity with add-in value.

Who will come along with the Dell model - "build commodity to suit." Key is the process of assembling the product, not what the product is.

Cable TV - pay per view not as successful as subscription. Aggregating larger packages of OSS.

Professional services business model not the most interesting thing.

UUNET made money with services - low margin ISP w/billions in revenue. Not by packaging UUNET software.

Network Solutions did not want DNS registration - then found the business model and did not want to give up the monopoly. Another ISP.

OSS developers need to pay attention to things not central... P2P, Rendezvous, Hydra, wireless, "social software"... all about network enabled collaboration. Or you will get behind the curve.

Increased customization - not just software. Look for hidden service business models. Collaboration beyond software.

Mapping software has not figured out use collaboration yet... location based services, individual contributors of data points into what's happening on the map.

Watch the alpha geeks - prefiguring larger movements. Screen scraping predicted web services. Rethink OSS in context of web services and network computing.

Who owns the data? License implications of data relationships. What will the bill or rights be for web services?

Kurzweil - long term thinking. Build out into the future. THE END

Award for best OSCON line on a Wiki or web page...

...so far goes to Kevin Altis for:

Note to those of you not used to the lawns west of the Rockies; there are no chiggers here, so sitting on the grass is fine :)

So true. I used to hate those damned itchy bastards. Which reminds me to stay of the grass in shorts when I go to Ohio in a couple of weeks.

Argh.

From the referenced web page...

Probably no creature on earth can cause as much torment for its size than the tiny chigger... Their bites produce small, reddish welts on the skin accompanied by intense itching as irritating as acute cases of poison ivory or poison sumac. These symptoms often are the only way of learning that an outdoor area is infested since chiggers are so small that most cannot be seen without a magnifying glass.

First post from OSCON

Wireless is working, thanks O'Reilly, et al.

Attended the first couple hours of OSCAMP this afternoon.

1:30 The Economics of Open Source (Stormy Peters)
2:00 Linux in the Enterprise - An IBM Perspective (Dan Frye)
2:30 Legal Framework for Open Source (Larry Rosen)

If you're reasonably up on Linux and OSS then the first two sessions were nothing new. These sessions are mainly for people and businesses just dipping their big toe in the water.

Dan Frye was asked (by me, actually) when the vendors will smooth out their differences. I ask because he made a big point about the hardware portability of Linux, but nothing about the differences among distros, which can be a big problem as well for businesses and individuals. And can result in hefty support fees, etc. because of vendor lock-in, which is not what OSS is about, is it?

Anyway his answer is progress is being made, it gets better over time, but no commitment to a timeline from the vendors.

Larry Rosen gave an interesting talk about OSS licenses and in particular his own license, which addresses concerns he has with the several dozen others that are available.

Came out last year at OSCON, but this is new to me.

Took a walk over to the Marriott to take care of some business... now back for the last hour of OSCAMP.

Adaptive Blogging

I will be showing a very simple start toward an adaptive blog tool at the Applied XML conference on Thursday, as an example of using XML, Python, and XPath.

The intersection between blogs, Wikis, semi-structured data, and more structured data is extremely rich. Something like Infopath is just scratching the surface, I'm sure.

OSCON Wiki

The OSCON Wiki is a great idea, and another convincing demo of the utility of Wiki webs. Bring on the Bliki = Blog + Wiki.

Yes, this is me.

I'll be at OSCON and Applied XML this week looking not much different.

Language Interoperability

Mark Watson writes...

I use OS X a lot and I am pleased that Apple by default installs usefull scripting languages like Python, Ruby, and Perl by default.

I use Jython with the Java Platform. It's a nice combination since a lot of "CPython" runs in Jython too, combining the two platforms with the ease of "scripting".

It really is a combination since Jython classes can be used in Java as well as the other way around.

I'd like to see this philosophy continue with dotnet as well. The scripting languages don't seem to be coming along as quickly. At least I don't see as much attention paid there. Smalltalk is coming along slowly with three implementations I know of.

Also I'm curious about the direction of SOAP, et al. Over time I would expect easier language integration across runtime engines and less attention paid to language integration within runtime engines.

This has to be easy and inexpensive to program to be truly effective. The hardware will make it fast.

Blogger feed down, now back

If you use blogger, check your feed. My feed was turned off the last couple of days somehow, perhaps as part of their recent upgrade.

Anyway, I had to go back to the settings and turn it on. Everything seems fine.

OSCON & What's Next

Ted and others, re: OSCON...

I'm still interested in Patrick Logan's "What's Next" discussion. Can we do this Tuesday or Wednesday night?

Great. I am available Tuesday around 6:30. Wednesday is not as good. It looks like 6-7 or after 9.

If Sam is still interested, looks like he's not in town until Wednesday or Thursday.

James was interested too. Maybe he'll chime in.

The Politics of Thirst

Some say that by 2025, water shortages will plague as much as half the world's population.

Do we have any real sense of the value of water?

Bloggers at OSCON

Ted writes about OSCON: Should we organize a blogger's gathering?

I might be able to attend, but my time is stretched already.

'Bring Them On'

Is Bush being cavalier with US troops in Iraq?

'Bring them on' is not exactly 'Let's Roll,' is it?

Parliamentary or Presidential System?

Sometimes I wonder if the USA would be better off with a parliamentary system. The US government (a kind of presidential system) is never really supported or forced into having truly vigorous debates.

The other thing I admire about parliamentary systems is the quickness of the elections. Bam! There's an election and Bam! it's over.

In the US we've already started the 2004 presidential campaign. Fundraising and the deliberately stilted primary firewall will take care to preserve and further polarize the two party system...

"In '84, primaries were spaced farther apart and big expensive media states came later. Now, the schedule is compressed and expensive states are holding primaries earlier, favoring establishment candidates."

A Birthday Wish

No, not my birthday. Tomorrow is Independence Day in the USA.

I wish for a reasonable third party candidate.

Not a third party candidate for the far left, like Ralph Nader. Not a third party candidate for the far right, like Pat Buchanan.

Most people are middle of the road, by definition. The Democrat and Republican parties force most people to swing to the left or the right on all issues for better or worse. There is increasingly less room to be reasonable about anything. The parties don't mind dividing you in order to build a large enough coalition to get into or stay in office. They don't mind rigging election politics together to rule out strong middle of the road candidates. That's one of the few remaining issues they can agree on.

We need a third party candidate for the middle of the road. Most people are reasonable. A reasonably effective candidate with an effective (web-based?) fund raising plan should be able to pull people back to the center.

Or maybe one of the two parties will realize that the middle of the road is the best place to be.

Python, simplicity, and XML-RPC

Dave Winer embeds a reference to the simplicity of Python...

I have expressed an opinion that was rejected, that what matters is what the XML-RPC call looks like in your programming language. I still strongly believe that... It's also the reason Python is one of the more popular languages for XML-RPC apps, because it has a very flexible way of creating remote procedure calls that look much like local ones.

I have taken a liking to Python over the last several months. I used to be more of a snob. Python seemed to be a grab bag of reasonable ideas that were better expressed elsewhere. The thing about Python though is it seems to work well in practice.

18 different things

Andreessen went on to call the state of browser navigation "an embarrassment."

"We had about 18 different things...in mind for the browser," he said.

1 in 5 US citizens believe Iraq *used* WMD in the war

Disturbing stats for the state of democracy from the Miami Herald.

A third of the American public believes U.S. forces found weapons of mass destruction in Iraq, according to a recent poll. And 22 percent said Iraq actually used chemical or biological weapons.

With amazingly misinformed statistics like this, how can the American population in general be concerned about "nuances" such as that either the CIA or the administration (or both) has "mishandled" evidence in support of the Iraq war?

What do statistics like this say about the "Information Age" or the potential contribution of weblogs to supplant the traditional press?

[The] poll's data showed that the mistaken belief that weapons of mass destruction had been found "is substantially greater among those who favored the war.''

...Before the war, the U.S. media often reported as fact the assertions by the Bush administration that Iraq possessed large stockpiles of illegal weapons. CBS News in December reported how Bush officials were "threatening war against Iraq and its weapons of mass destruction.''

Shouldn't supporters of the war be even more concerned than the detractors? Do we have to be "right" so badly, we're willing to be ignorant? How bad is it that these facts were "mishandled"? From MSNBC...

[A] senior CIA analyst said the case “is indicative of larger problems” involving the handling of intelligence about Iraq’s alleged chemical, biological and nuclear weapons programs and its links to al Qaeda, which the administration cited as justification for war. “Information not consistent with the administration agenda was discarded and information that was [consistent] was not seriously scrutinized,” the analyst said.

That's Politics

From the Register. They usually shoot pretty straight.

[While politicians] are a peculiar and varied breed, there are three things you can be fairly certain will not hold much sway with them:

Ideological argument. Politicians are nothing if not pragmatic. Their very survival is based on seeing which way the wind is blowing and adjusting accordingly

Little-man defence. Politicians will not risk upsetting rich and powerful people and companies unless there is a principle at stake: that principle being that the government ultimately decides. Therefore arguing a point on the basis that it will restrict or impair a powerful body is counterproductive

Criticism. Politicians do not respond well to criticism. In fact, the more they get, the more stubborn they become. Flattery is the surest route to their heart, and this means making them feel important. Wining and dining, listening, applauding their insight and then putting your point across

This sucks

This sucks as of the time I am writing.

RSS/Echo Inconveniences

Danny Ayers says "Sure there will be inconveniences in a transition period, but that is often a side effect of progress."

It seems to be a poor choice of timing to start such a transition. Maybe this is progress, maybe not. Time will tell how significant the progress is relative to the chaos.

Many people are just beginning to be familiar with blogs and RSS. The RSS/Echo affair may complicate whatever confidence they otherwise would have had investing in RSS for applications they don't get free. For example, if someone is building an RSS feed for some internal source of data, do they stop and wait for Echo? You may feel there is a right answer to this question. Someone else may be uncomfortable enough to stop development.

Time cannot tell whether there would have been a better way to go about this. Kind of funny all the fuss. Fairly innocuous geek thrash sometimes has real monitary damage. We may never know some of the damage that's been done, even though the end result may appear generally to be a success.

Breaking Bread in July?

Maybe next week will be a time to break bread so we can get on with the business of building better applications.

Weblogs and RSS: What's the big deal? The Wiki Wiki Web

Weblogs are sub-optimal. RSS is sub-optimal.

The best thing to come of this recent RSS/Echo issue is that Sam Ruby has demonstrated the value of the Wiki Wiki Web.

Funny that Echo could not have been designed very well with weblogs and RSS, er, Echo.

What's the best thing about aggregators? The fact they mainly visit weblogs? No. The fact they use RSS? No.

The best thing about aggregators is that they are better user interfaces for browsing the web than Mosaic, which is really what we're still using when we use IE.

Well at least Mozilla and Safari have tabs, for crying out loud.

What do we need, another Echo? Nope. We really need better applications. What happened to that Web Services revolution anyway, that the heat generated in 2003 is about HTTP.

Agile development methods are being credited with increasing numbers of successful software projects. Can you find them mentioned in the SWEBOK? I did not read all 200+ pages. But I searched for several terms I would have expected.

I can't either. Via James' blog, Cem Kaner has some serious concerns about the implications of SWEBOK. This work is almost frozen, having been developed in parallel over the last few years alongside the agile approaches.

I would have assumed a SWEBOK-like effort would be intended to eradicate ignorance, not institutionalize it. Sponsored by the IEEE, which has published a fair bit about agile approaches, this gap should be considered a deal breaker for adoption.

I am genuinely surprised and will look a little more closely at their proposal to see what I missed just by searching.

Capabilities vs. Access Control Lists

Phil Windley presents another effort (or two or three) to take some existing functionality and express it as an XML-based standard.

XACML is the language of the Policy Decision Point, of PDP. The PDP is the chunk of code that recieves access requests, checks to see whether they should be granted, and returns an appropriate response. The PDP is not necessarily the same as the place where credentials are stored. It merely needs access to that service, ideally via SPML. The PDP could be a module running in the local system or a remote system accessed over the Internet.

Again I have to plead ignorance and plea for the principles, guidelines, and scenarios for when to use this functionality. Why is this the right thing to do? Is it ready to use? When would I choose something else? I hope I can dig into the references and find this information.

For example why are ACLs the right model? A capability-based model might be more appropriate, e.g. as provided by Waterken.

SOAP Opera: There's really not much mystery about this stuff

Update: John Robb's FUDeflection. Or redirection. Too soon to tell. The SOAP opera continues.

As someone with zero investment in RSS or Echo, I have enjoyed the past week or so from afar. Mostly waiting for Dave Winer to speak up, which he did, and did well. Now Jon Udell adds his take, which is not surprisingly insightful, but is surprisingly sarcastic.

He pulls it off. Here's the crux, though, in his more typically pragmatic style...

Anyway, Dave showed everybody how to use RSS. That's his crowning achievement in my book. Not the format...

Now that the dam has broken, Dave has endorsed the new effort. It must have been an incredibly hard thing to do. I have a teenage daughter and when it's time for her to leave the nest, in a couple of years, I hope I'll handle that transition as graciously as Dave is handling this one. Meanwhile, the Echo designers are -- not surprisingly -- converging on a core that looks a lot like RSS. So far they've discovered that a blog entry has a link, an author, a publication date, and one or more semantically-equivalent content items. Any day now, they'll conclude that it also has a description. There's really not much mystery about this stuff.

I did not realize what was coming with Echo when I reacted positively to Steve Gillmor's take on Microsoft and RSS a couple weeks ago. Of course when I was suggesting RSS might be supplanted over time, I did not think it would be for apparently political reasons. I certainly did not think the effort would begin any time soon.

My reaction to Echo is along the lines of many others: RSS (regardless of its many forms and politics, I mean the collective sense of "RSS") has just in the last months taken a spot in the zeitgeist. My god, it takes ages for these concepts to make their way into large corporations. And now we have to explain Echo? I'm not going to rush that one.

"We need to be more like the auto industry." (SAP)

Henning Kagermann, CEO of SAP, says "We need to be more like the auto industry..."

Prague: Judith Owen (piano, vocals) and Harry Shearer (Le Show, Spinal Tap, A Mighty Wind)

Harry Shearer...

Just in case you know anybody in Prague:

"Teddy Bears' Picnic" plays this Sunday, Monday and Tuesday at KINO OKO

Frantiska Krizka 15
170 00 Prague 7
Czech Republic

Judith Owen plays, with Harry Shearer on bass, Monday night at Zelezna Jazz Club

Zelezna 16
Praha 1
Czech Rep

Chris Sell's Applied XML Conference

Speaking of speaking at conferences, I will be doing that again at Chris Sell's Applied XML Conference in a couple of weeks. This time I'm using Python, which I consider a kissing cousin to the Lisp family along with Smalltalk, Ruby, and some others. Look at the code a couple messages below. You could wrap some parentheses around those statements and never blink.

Corrupting Influence

Gordon Weakliem swears I turned him on to Lisp...

What led you to try Lisp?

I heard Patrick Logan speak at a conference about building web services with Scheme, which sounded interesting, so I read "The Little Schemer". Later, Paul Graham's writings, esp. "Beating the Averages", but also because I was feeling the limitations of the Java / C# family of languages.

Wow, Gordon. If only it were that easy with everyone else!

Jython and JXPath

I recently started using JXPath, an XPath implementation for multiple underlying data models in Java. It works out of the box for DOM, JDOM, java.util.Map, servlet contexts, and Java Beans. Probably others.

I wanted to use XPath to query Jython objects. The really cool thing is the amount of code it takes to do so. It's so short I include it right here...

from java.lang import String
from org.apache.commons.jxpath import JXPathIntrospector
from org.apache.commons.jxpath import DynamicPropertyHandler
import jarray

class JythonPropertyHandler (DynamicPropertyHandler):
    def getPropertyNames (self, py_object):
        keys = py_object.__dict__.keys()
        return jarray.array(keys, String)
    def getProperty(self, py_object, property):
        if py_object.__dict__.has_key(property):
            return py_object.__dict__[property]
        else:
            return None
    def setProperty(self, py_object, property, value):
        py_object.__dict__[property] = value

def registerJythonPropertyHandler():
    JXPathIntrospector.registerDynamicClass(PyInstance, JythonPropertyHandler)

And so...

>>> context = JXPathContext.newContext(some_object)
>>> context.getValue("frob[abc > 1]")
<__main__.Foo instance at 3278971>

Virtual Databases and Enterprise Integration

Enterprise IT environments are a mess primarily because they've grown piecemeal by function and technology. Every business unit and indeed every project is "empowered" to make their own decisions. And so they rightly make the best decision for their purposes. Every vendor has some hook in their technology to bring you back to the trough.

Even if some Enterprise Resource Planner (ERP) met all your needs, how long before you could actually get to "All Your Base Are Belong To Us" nirvana? And so we have "Enterprise Application Integration" (EAI) and (new to me...) "Enterprise Information Integration" (EII). One approach to EII in the past has been to build a massive Enterprise Data Warehouse (EDW).

Another approach, Phil Windley writes in his blog item on virtual databases, "The biggest hurdle... is creating the... data model." and includes some useful references.

Another pragmatic source of inspiration is Ralph Kimball. First some history...

A significant contributor to the Xerox Star in the 1970s (which influenced the Mac, which influenced...), Kimball and peers at Metaphor in the 1980s pioneered data integration, iconic capsule programming, and end-user data analysis. Metaphor was sold to IBM and languished under the shadow of OS/2 politics.

In the 1990s Kimball went on to pioneer data warehousing design principles and the Red Brick OLAP database (also sold to IBM via Informix). He is now an independent consultant and popular author on data integration topics for OLAP.

His keys to an effective virtual database (or data bus architecture in his words) is conformed dimensions, smallest grain facts, etc. Most of these principles apply to the largest data warehouses or the smallest databases, and would benefit any Enterprise Information Integration effort.

Microsoft and RSS?

Steve Gillmor on Microsoft and RSS.

Interesting ideas. But what is interesting about RSS? What is interesting about any protocol?

Maybe it's just that developers are using RSS and Microsoft likes developers. The protocol itself is nothing special, but that in itself is its advantage... witness the number of applications that implement it. It was designed by developers.

So simple protocols are good. Has RSS been through the scalability ringer yet? Does it matter? Another protocol will come along soon if necessary. The interesting questions are what to do with the protocol. That's what Steve Gillmor is getting at, perhaps.

Driving in Boston

Driving in Boston... Dave Winer has excellent advice...

That way a wrong turn, while it will still take you miles out of your way, won't waste hours of your time.

My first night in Boston (a Friday) my buddy and I spent driving all over town. Not deliberately. We were trying to find something, a specific restaurant I think, near Fenway, because we also wanted to see Fenway Park.

The next morning I looked at a map to see where we had been. Ommagod.

I learned pretty quickly to use the T.

I learned the next best tip when I met the woman who is now my wife. In particular this: get a '62 Ford Falcon and practice getting around the Fresh Pond rotary as quickly as you can.

She named hers "Buzzy".