Leveling the Playing Fields: More for All

And most of all, Cook wants to fix health care. ?When you move the work to India and China you get an immediate $6,000 savings right there,? he says. ?It?s huge.?

Who pays for this savings? Healthcare in these countries is horrible, especially for the millions of poor people who don't work for the elite corporations. The infrastructure, aside from what the elite corporations are building for themselves, is equally horrible,

How can a country, such as the US, that has taken such advantages as to provide at least a reasonable amount of healthcare for most people, as well as sanitation, transportation, and many other services for all, compete with a workforce not based in an equivalent healthy society?

I think there are two imperatives:

• One, corporations moving operations to poorer societies should share half of their savings with those societies at large. This would be an "international tax" for the benefit of lifting up the imbalanced, poorer societies those corporations are *taking advantage* of.
• Two, the governments of the more privileged societies should legislate incentives and investments toward "sustainable" technologies and behaviors. We obviously need to do more with less in privileged societies that currently use more than our fare share of resources that make us "privileged" in the first place, and we need to set the course for those societies that will follow in our path.

These are two ways to "grow the pie" for all of us, to address imbalances that have been falling out of balance for decades with too little leadership. Discuss these ideas and others.

Politics are *about* flip-flops

A list of Bush flip-flops to counter their list of Kerry flip-flops.

Is Oblivity a Word?

Well, at least we don't treat electronic voting any differently than we treat other critical computing activities.

David Hart, chairman of Texas-based Hart InterCivic, which manufactured Orange County's voting system, said it would be impossible to identify which voters cast ballots in the wrong precincts because of steps the company had taken to ensure voter secrecy. For this reason, an exact account of miscast ballots is impossible.

More on Smalltalk's Image

Ian points out...

The image isn't strictly required -- I believe GNU Smalltalk has no image, or at least got along without one at one time, and the Smalltalk-ish Objective C has no image.

And instead of a single-process image, Gemstone Smalltalk uses a multiple-process, optionally distributed obect-oriented database.

The Public Good

Chomsky... claims that in the last 30 years, the economy is working well because of public spending on such technologies as computers, satellites, the Internet and lasers that has fed the economy. And the wealth derived from these technologies has gone primarily into the hands of corporate masters, who represent a fraction of the American people.

I believe we need a public investment in photovoltaics comparable to the investment the US government made in integrated circuits in the 50's, 60's, and 70's. Goals for distributed, local-scale, electricity generation would be far more beneficial for the US and for democracy and freedom than a trip to the moon.

Smalltalk is *too* good for its own good

Begin Update:
Ian continues...

Smalltalk code feels organic and extensible, but it's not well congealed into something as distinct as a "program". The current computing world is a world of programs, not objects. Maybe we'll get to that world of objects, but there needs to be a path leading there that starts here.

So maybe my new conclusion is that Smalltalk is uncompromising in its vision, but the world is not ready for that vision.

Smalltalk is *too* good? I would agree that Smalltalk still (after thirty plus years) seems ahead of its time. But I've seen large programs in C++ and Java become far more unwieldy mostly because they lack the *tools* that make exploration possible.
End Update

There are too many places to begin refuting this critique of Smalltalk, but let's start here as a place holder...

You can't easily map C or other libraries into Smalltalk.

Wrong. It's been a while since I've had to map C to Smalltalk, but even eight years ago it was so easy I was calling SAP R/3 functions from Smalltalk with just a few lines of code, and just an hour or so effort (for the first time I called SAP R/3 from *anything* and SAP R/3 is about the strangest thing I've ever had to call from any language).

It doesn't help either that Smalltalk's OO nature encourages everything to be a framework, instead of building mere libraries, but that's a topic for a different day...

Let's hope Ian gets to this someday. I have no idea where he's going with this.

I think it's wrong to underestimate the problems with Smalltalk's system image...

Maybe listing *one* thing wrong with the image would be a start. One can criticize anything, but an image file is just a convenience that other programmers struggle to emulate more or less in other language systems.

Sorry, I don't see much in Ian's critique to sympathize with. Least of all the "it looks strange" argument. Sorry, get over that one already, or ignore Smalltalk altogether. It's that simple.

Ramkumar Kothandaraman writes about some of the business-level complexities I mentioned a few weeks ago. I wrote...

Although the infrastructure is still immature, the real problems for the enterprise are at the boundary where the services architecture meets the business architecture. The real problems of heading toward a world of rich services is how to get them to play at the business level. How do you keep them agreeing on a correct chart of values, a correctpart and product hierarchy, roles and responsibilities, up-to-date with engineering change notices, etc.

As Rumkumar points out from his experience...

[It] is very easy draw service boundaries that may create data related problems later on...

things started falling apart the moment we started integrating different services. The main problem we faced was that the 'Customer' entity is required by all the systems...

So, we went down the path of building a common module (system of record) for common entities. Things worked for a while, before we got into implementing a scenario that actually required a cross-join between product entity and a related entity owned by order management service...

So, what is the solution? Here is a practical one. "Try to share the database between related services.“...

For example, think of your favorite ERP system (SAP, Peoplesoft etc) as a business service that exposes one more services - one for HR management, one for Inventory, one for Order management, one for Accounting etc. But, they all share single logical data model. Ever wondered, why big ERP systems such as SAP have a single database that contains the tables required by all the modules? I tend to think this is the reason why they did it.

This problem is not insurmountable, but neither is it easily solved. Note this problem has nothing to do with your business and my business agreeing on a common Internet data model. This problem exists solely within the intranet of your business. This is just the tip of the iceberg toward a complete "service oriented architecture".

Note also I suspect vendor consolidation will accompany the move to SOA...

These are not insurmountable. To reiterate I believe the movement toward an SOA will be preceeded by a movement to realign IT for the enterprise architecture and go hand in hand with vendor and product consolidation, and less custom development.

In part this could support "service" vendors to actually gravitate around *databases* as a coordination mechanism rather than pure services, with some services privileged to create and update certain domains of data. Realizing this from experience through vendor agreement and implementation may take some time however.