ObjectStudio, VisualStudio, Smalltalk and the CLR

James Robertson writes about potential futures for ObjectStudio Smalltalk.

One option that might be in Microsoft's best interest could be Microsoft throwing a bit of money and expertise toward Cincom to get a Smalltalk running on the CLR. Work with the IronPython and CLR folks on dynamic languages, maybe even on some of the features Jim lists that make Smalltalk as good as it is.

Who knows? Could help Microsoft's dynamic language capabilities in general, and both organizations may benefit from a first-class Smalltalk system on that platform.

Lightweight, Portable, and What, Again?

Updates: From comments...

"for any reasonable success, you need to interoperate intimately with .NET (or Java if you like)"

This will come as a complete surprise to all the Perl, Python, Lisp, Smalltalk, and other developers who have been achieving "reasonable success" very well without such capabilities. Better get a memo to them soon.

"Just put a Smalltalk coprocessor on a removable PC card, add a field gate array processor and upgrade it twice a year. Get the extra registers Smalltalk has been craving that Intel doesn't have. With today's competitive chip manufacturing processes, it's within reach.

The most popular class libraries get put in the VM.

The most used classes in the VM get put into the field gate array."

Not sure the future success of Smalltalk should ride on convincing PC owners everywhere to put a co-processor into their boxes, no matter how cheap it may be.

First of all, this suggestion seems to ignore the reality that Smalltalk execution is very efficient on the processors those PC owners already have in their boxes.

Second of all, putting classes into the VM, not to mention onto hardware, is not a very smart decision. Read a little about the history of Lisp and Smalltalk then look at the CLR for potential improvements that could be made *there*.

"The most used classes in the field gate array get (automatically) submitted to a company that balances cost, demand, distribution, and chip limits to create a run of these PC cards."

Sorry. You flipped the bozo bit.

End of Updates.

Someone's question...

"...Why run Smalltalk on .Net? Seriously, I just don't get it...why would you want to?..."

In a comment on James Robertson's blog, Socinian answers the question...

Access to unique device hardware, network security, code/data security, active directory access, etc. Managed code, because eventually, more than one machine will be executing/managing it. Also connecting to 3rd party applications. You can't just compile/link, DLL call, API function call, or SOAP any more.

You have to look where things are going. Cell CPU's, programmable appliances, utility computing, virtual OS, and large cluster computing. Do you want to rewrite a new VM for each of these and what's ever next? Let someone else do the work, so you can focus on a productive application. It's easy to get stuck in a one CPU perspective of the world. Unfortunately, this will change the way applications are created, used, and migrated, as surely as cell phones changed the time and place that we communicate over distance.

I agree with the vision. The current implementation of dotnet, plus the baggage in all the specific object model stuff, etc. would not lead me to believe this is the vision for that runtime model, however. (N.B. I have been wrong before.)

I would consider Erlang/OTP, Gambit Scheme, Cincom (VW) Smalltalk as better starting places (among several others), for inspiration if not implementation in support of this vision. Note that Gambit Scheme has hosted Erlang in a prototype that appears to be roughly equivalent in scalability. Note that the Cincom Smalltalk VM appears to be scalable for web systems and capable of running Python a good bit faster than CPython. So I am nominating them as candidates for hosting multiple languages on multiple platforms in support of the dynamic vision above. And with a fair bit less overhead than is apparent in the dotnet runtime as per its own definition.

Just a guess, but with some evidence.

Programming and Spreadsheets

Update 3: Anonymous points out that Jim Weirich has an inspired exposition of the spreadsheet implementation in Ruby. Very nice.

Python and Ruby are excellent languages. There are just a few small cracks in these languages where if you look carefully through them toward Smalltalk and Lisp, you can see how truly gifted, or maybe just lucky, the designers of those original dynamic languages were. These are just small cracks though, as Jim pointed out in Ruby and Ian Bicking mentioned about Python, for example, that delaying some of the operators with Formulas is difficult or impossible.

This is a lesson for designers to be as regular as possible. (If you are into the theory of regularity in design: pdf) End of Update 3

I've wondered several times in conversations why the concept of a spreadsheet is not more easily a first-class feature of popular programming languages. There is a long history of constraint programming of various flavors that show up typically as an API in an imperative language or as the dominant style of a new language. (Mozart/Oz comes to mind as a language that emphasizes constraints but does not make them dominant.)

Kimbly points to an approximation in Python...

>>> ss = SpreadSheet()
>>> ss['a1'] = '5'
>>> ss['a2'] = 'a1*6'
>>> ss['a3'] = 'a2*7'
>>> ss['a3']
210

What bothers me about this of course (?) is the "extra-lingual" expressions embedded as text, e.g. 'a1*6'. A first-class implementation would be done entirely in the language per se. After the text 'a1*6' is passed around, which functions assume it is just text and which assume it is a constrained expression? (We like objects.)

When I have seen a "spreadsheet" implemented in a language, invariably the objects are exposed through a user interface primarily, and programmatically through an awkward API at best. (With certain exceptions, in particular Lisp, which make programmatic integration essentially transparent, everything looks the same.)

In Smalltalk, maybe, using points rather than the alphanumeric column/row convention...

ss := Spreadsheet new.
ss cell: 1@1 value: 5.
ss cell: 1@2 value: (ss cell: 1@1) * 6.
ss cell: 1@3 value: (ss cell: 1@2) * 7.
(ss cell: 1@3) value
210

Spreadsheets should be useful without a user interface. Constraints should be a part of contemporary programming languages. Why aren't they?

Update: Matthias Ernst asks in a comment...

Don't you rather want:
ss cell: 1@2 value: [(ss cell: 1@1) * 6]
Add cell value caching and invalidation after change.

The use of a block here is intended to "delay" the computation until a change to a dependency forces a revaluation.

The problem then is the programmer has to know where to put the blocks to delay computation and where to force the revaluations. Instead of blocks, though, my intention is to use some new object, a Formula, say, and to make those objects implicit as much as possible.

So the message Spreadsheet>>cell: aPoint value: aFormula would store the formula at the cell's point in the spreadsheet. If aFormula is not a Formula, then it is assumed to be a constant, and so the spreadsheet would wrap the constant in a subclass of Formula, say ConstantFormula. (Probably the thing to do is to send the argument the message Object>>asFormula which would simply return itself if it is already a formula.)

The result of the message Spreadsheet>>cell: aPoint is a Formula (which may be a ConstantFormula) and so to get its value, send it the message Formula>>value. (e.g. the last expression in the example returns 210.

But what about (ss cell: 1@1) * 6? The expression (ss cell: 1@1) results in the formula at the point 1@1. The result of multiplying a formula by a constant is a new formula that does the obvious multiplication when evaluated. (And since multiplication is commutative and Smalltalk allows you to redefine "system" methods, numbers should understand (through double dispatching) that the result of 6 * (ss cell: 1@1) is also a formula.)

*"is not a formula" does not mean your code should test for the class of the object. Rather a message, say Object>>isFormula, should be sent to the object. the default implementation for all objects returns false. The implementation of Formula>>isFormula returns true. Other implementations may return true as well if they are intended to behave as formulas rather than as constants in a spreadsheet.

**Double Dispatching: Yes, multiple argument dispatching in CLOS is better, and yes, Python has this in 2.4. Maybe something should go into Smalltalk, but the good news is you are free to try it then tell the rest of us. (Dan Ingalls, Ralph Johnson, Andrew Black)

Update 2: Gavin McGovern writes in a comment...

One of my favorite spreadsheets is Levoy's "Spreadsheets for Images",

Bit backwards: he essentially put Tcl (+ image stuff) in a spreadsheet. But a neat example nonetheless of a alternative user interface.

Nice. Thanks. This is kind of like Kurt Piersol's spreadsheet in Smalltalk he presented at OOPSLA '86. He uses image processing as an example of operating on non-numeric data. (Unfortunately or not, he also extends the syntax for operating on spreadsheets. From the examples above, I am not yet convinced this is necessary.)

Bad Architect

Update: More good architecture from FLW via Chris Petrilli.

I was a real architeture student for a couple of years. In the middle of my umpteenth all-nighter getting a drawing acceptable for some reverse-disaffected grad student's criticism, I figured I was never going to make a living making great architecture. Now as it turns out, even the great architects don't make a living making great architecture. What crap is this? Or this? Or this?

Then again there is this, and this, and this. Perhaps this. As in any system, the bigger the badder. Small pieces, loosely joined seems to be a recurring theme. How about this?

Daily Zen

"Ancient sages were like this; who nowadays does not need to practice as they did?"
Dogen, 1227 C.E.

Big Ball of Mud

A gem from Brian Foote. Heed...

People want assembly to be antiseptic, and free. It ain't. It takes time, and skill, to fit materials to the site, and the task, and craft them into an integrated whole. People don't want to live or work in prefab trailer park modules. They want real homes, real stores, real offices.

I've been re-reading some of Christopher Alexander's work, and remain skeptical that either good buildings or good code can be seamlessly, effortlessly conjoured up out of Lego blocks.

Daily Zen

"The real way circulates everywhere"
Dogen, 1227 C.E.

Programming with Boat Anchors

Good dynamic languages (e.g. Lisp, Smalltalk, Python) are dirt simple...

Compared to Java code, XML is agile and flexible. Compared to Python code, XML is a boat anchor, a ball and chain...

If you have a thick skin and don't mind being laughed at, try explaining to a Lisp programmer why your application needs XML!

(via James Robertson)

Language Innovation and Postmodern Computing

I don't want to go too far toward making some classically stupid prediction. But frankly I am not looking for much change in our current programming languages.

We need all new models rather than incremental "improvements". Agile languages can be improved incrementally without a lot of central organization.

This is all dancing around the real problem of making computing more accessible to "end users". Face it, programmers are today's telephone operators and we are simply in the way. We'll continue using our quaint little notations for some time to come, but these efforts should be focused on eliminating what can be automated toward all new concepts in computing.

Sad News?

Doc Searls says IBM's selling of its PC line is sad news. Although I use a Thinkpad at work (and should be getting an upgrade real soon now), I'm not sure this is sad news.

Where is the PC market going? I think it needs a good shake up to bring some creativity back. Maybe this shedding will allow some of that... well, this is IBM we're talking about. But maybe this will shake enough up to jump start the beginning of 21st century consumer computing rather than squeezing out ever finer inefficiencies of a 20th century product line.

Shocked, Shocked

I'm with Dan Gillmor on this steroids topic. Can anyone be surprised at the recent news? "Athletes use performance-enhancing drugs! Read all about it!"

The Oregonian today devoted half of its front page to the topic. Unbelievable priorities in journalism. Is there nothing else more important for us to be aware of? (Interestingly this topic apparently is not important enough to go on their web site.)

Groovy, Scheme

Over in the comments on this item pleading for better closures in Java, a reader suggests Groovy will satisfy some of those needs when it becomes stable. My comment in return is, why wait?

Why wait for Groovy? Scheme is in production already in the JVM.

SISC is a complete and efficient Scheme.

JScheme is less complete and efficient, but simpler and useful for its integration with Java.

Python, Prevayler, and ODBMS

Patrick K. O'Brien, Orbtech, writes in a comment...

Keep your eye out for two Python projects that will have major releases in the next couple of weeks: Pypersyst is a prevayler-style persistence mechanism for Python. Schevo is a full-blown ODBMS and Application Framework written in Python that can store Python objects in Pypersyst, ZODB, or Durus (including the ability to switch between storage backends, and the ability to use different backends for replicas). And it has many other goodies (like incredible support for schema evolution and object migration) that you'll simply have to wait to hear about.

Been There, Done Not Quite That

Edd Dumbill reports on unmet expectations that Binary XML would cause more of a raucous response.

My off the cuff theory is that by now every developer on the planet has implemented at least one kind of kludge for sending their own encoding of XML over the wire more efficiently the default bulky representation format that is XML. Because the problem has been solved just good enough by their own quick hack, developers might easily assume a standard binary format for XML would be trivial.

My favorite approach was, is, and probably ever shall be Lisp. Convert from XML to Lisp format. Convert to binary if necessary. And use an efficient, incrementatal protocol if needed beyond that. (One reasonable example is found in that wonderful journal, Software Practice and Experience, in a paper called "Efficient Binary Transfer of Pointer Structures". (PDF)

In any case, my response is to just kind of chuckle. There are a number of variables in choosing a binary representation of semi-structured data intended for various uses. This is not a one-size fits all problem, XML is a simple idea complicated by a wide range of intentions.

True Data Ways

Ian Bicking writes in a comment to an earlier post about "issues" with certain anachronistic databases (e.g. ZODB and Berkeley DB)...

RDBMSs and flat files are the two true ways, because they are somewhat less broken than other things!

A Smalltalk image works well as a simple object database because it is fairly simple: in-memory, simple process model (e.g. no complicated conflict resolution). Prevayler could become a simple extension of this, and the capability/complexity trade-off grows from there.

I agree with Ian's sentiment. The relational model is better than credit is given from the object-oriented programming community. The main problem is not the relational model per se, but the language implementation (i.e. SQL) is not so compatible with the more modern languages we use (even Smalltalk and Lisp, which pre-date SQL by a fair number of years. I agree with other voices that the Object-Relational Mapping problem is not worth spending too much time worrying about.

Even with SQL's shortcomings, the range of reliable implementations is nothing to shake a stick at. And flat files in basic file systems are tried and true, not a lot of moving parts to worry about for a good many scenarios.

Newer implementations of relational databases do address some of the language issues. (e.g. Derby nee Cloudscape and the even simpler Hypersonic SQL on the language issue, Postgres on the some of the O-R mapping issues). But some down to the roots rethinking of the implementation of relational databases could fuel them up for the years ahead.

By the way Ian...

(By the way Ian, I am interested in this comment and intend to respond. I just haven't taken the time yet to get into the detail required.)

Ian Bicking writes in a comment on my blog...

I really don't see how Smalltalk is better. It has blocks, and that's cool, and you can use them in several interesting ways. But in many ways its model is more rigid. Well, maybe it's more appropriate to say that its representation of source is more rigid, specifically the IDE. I can imagine Smalltalk objects that are completely general and not particularly related to classes. But I can imagine block objects in Python; in both cases, there's no good way to represent them (traditionally) in source.

Python has some flexibility that Smalltalk tends not to because of its imperative style. Since each Python module is a script, you can program how the objects that are constructed. Decorators are one obvious example of this -- and something where syntax was added for aesthetic effect, but the semantics were already well worked out, and fit into Python's model just fine.

Because Smalltalk has declarative source, there's not as much room for building objects on the fly. Again, you can do it, but it's not nearly as comfortable.

In the end, it doesn't seem like Smalltalk is an evolving language, and there's no one to even go to to ask for new features (who would realistically respond in a positive way). So it's hard to compare; in all of these languages, you can cope somehow. You can always do code generation, after all. In evolving languages there are options besides coping; that people respond to that and ask for changes doesn't indicate a more flawed language.

The Image

Update:

Socinian writes in a comment...

[An image is] just not a multi-user database. Make every image multi-user and every running image a server and Smalltalk will soar. Think in terms of the Chandler project. Everyone's a producer, consumer, and database.

Essentially Gemstone/S is a highly scalable, distributed multi-user "image". (And a good bit more.) No doubt there is a lot of value in this concept. But the concurrency complications go way up as well. Maybe the simplest form of this idea is a Smalltalk implementation of Prevayler.

Original:

Ian Bicking writes in a comment on Avi Bryant's blog...

To me, the image seems very challenging from a usability point of view. Images are monolithic, while most version control systems work on filesystems which are rather distributed. You can have two branches or checkouts sitting along side each other, and tools can access either just fine, compare, contrast, etc. In Smalltalk that's two discrete systems. Maybe if you could run select code in a specific branch, while the rest of the system remained in a different branch. But that seems infeasible, and even if it wasn't, since it's utterly inconcrete it's also rather opaque.

Smalltalk-80 was designed to put the tools and the objects they evolve into one image. ANSI Smalltalk was designed to support a "firewall" if desired between the tools and the objects they evolve.

Either way, I think it is not helpful to combine discussions of "the image" too closely with discussions about "version control". Smalltalk version control is typically done independent of the image. The image is where specific versions of things are installed to provide specific executable capabilties (e.g. an application). Various images can have various versions of various things installed in them.

That said, an image *can* contain things which "do version control" and often the things they version are things in that same image. But "the image" and "version control" are really independent things.

Since there can be many images, let's not talk about "the image". Better to think about images as simple, yet powerful object-oriented databases.

Things in an image can be made from specific versions of things that originate in some version control system, just as things in a Zope Object Database can be made from specific versions of things that originate in some version control system.

What if a Zope Object Database were even easier to use than it already is? What if you just had one ready by default and your application was automatically a part of the database, and all your favorite tools were automatically able to inspect and update that database?

That's kind of what should come to mind when thinking about "the image".

Application Protocols

Mark Baker writes...

[If] we want to enable a world of indiscriminate consumption of remote third party services, we need to do so in a manner similar to other systems which have done just that, like the Web, email, instant messaging, etc... Namely, by using a constrained interface, and embracing (application) protocol dependence.

EG => RG

Erann Gat changed his name to Ron Garret and has an oddly interesting story about that. Too bad, I think. "Erann Gat" had much more character.

"Ron Garret" sounds like a guy putting up my new fence.

Not that I'm crazy about "Patrick Logan", but come to think about it, "Erann Gat" is now available!

Science Literacy

Is basic science literacy a necessary foundation for successful citizenship? From Taegan Goddard...

According to a new Gallup poll, "only about a third of Americans believe that Charles Darwin's theory of evolution is a scientific theory that has been well supported by the evidence, while just as many say that it is just one of many theories and has not been supported by the evidence. The rest say they don't know enough to say."

Furthermore, forty-five percent "also believe that God created human beings pretty much in their present form about 10,000 years ago. A third of Americans are biblical literalists who believe that the Bible is the actual word of God and is to be taken literally, word for word."

Here they come

Howard Stern, you can run, but you cannot hide.

Gack, Grady...

...it *is* the 21st century you know. This...

I failed to use Rational's own tools (Purify in this case) and I had a memory leak in my application server. The solution was to reboot that server, which brought the doorbell back to life.

I mean, if you're going to implement your *doorbell* with a network and an application server, at least use some software that doesn't break so easily.

Just Wondering

Mark Watson wonders...

What ever happened to basic old fashion American values that I would summarize as "take what you need and leave something for other people"

Please remind me. Which period in American history did we exhibit this value?

Lisp, Smalltalk, and

Alex Peake writes in a comment...

I would love to use Franz Allegro or Cincom Smalltalk in all their maturity. On the other hand, if I have to write my own infrastructure and GUI components, I will never finish the "real" project.

What do you do in Franz and Cincom for the Infragistics GUI components, ActiveData reporting, GoDiagram...? What do you do for .NET Remoting, Declarative Transactions, MessageQueue, Declarative Code Access and User Security (based on Windows Login)...?

So I'll open this up for others to respond. Generally, these vendors (e.g. Franz and Cincom) have to provide connections to Java and dotnet at least as easily as they did for C. Given these systems are run-time typed, reflective, and garbage collected, the implementations should be easier.

Franz has a set of tools for Java, and so I would expect something similar for dotnet. Cincom has an preliminary interface for dotnet, with a more complete (events, etc.) interface in a few weeks. I guess for Java, Cincom Smalltalk would use the JNI.

Specific capabilities are probably hit-or-miss. Cincom supports an MQ-Series interface apparently. I guess the question for someone in a situation like this would be does the use of some specific product outweigh the benefit of building the majority of a product in a more productive environment? And what the cost is for creating a specific interface to that product from the ground up.

More Problems with Rigid Languages

This from people trying the new Java 1.5 language changes...

And generics: "In a nutshell, I have this to say about Java generics: my code feels more robust, but it's harder to read."

Also an interview with one of the authors of Hibernate: "Well, we are a bit stuck. We can't use many of the new features, because Hibernate needs to stay source-level compatible with older JDKs. The annotations stuff is okay, because we can provide it as an add-on package.

Too bad the language is not simple enough to accomodate change, especially backward compatible change. Agile languages win again.

Update: A question in the comments asks how this is different from Python. My answer is "not much different". Python is a mixed beast when it comes to extension. Here's why...

The big problem is that these changes occur at all.

In Lisp, the core language (e.g. Common Lisp or Scheme) does not have to change much. Change is facilitated by making syntax extension a part of the language. And the core is expressive enough to ward off the need to change.

Smalltalk does not have the same syntax extension, but again is simple, expressive, and mature so that the existing message sending paradigm can be used to define new forms of control.

I am not sure why Python is changing or needs to. But the core language is more limited than Lisp or Smalltalk in the sense that it is "C"-like and distinguishes significantly between function calls, operators, and control structures.

A more uniform language would not have as many of these backward-compatibility issues. This is the main issue I have with Python... it's syntax is OK, but not great for extension.

Whole Program Optimization

Since encountering the Stalin compiler for Scheme about 10-15 years ago I guess (see Flow Directed Lightweight Closure Conversion, PDF), I've been fascinated by the whole-program analysis approach. Starkiller for Python is in the same ballpark.

So this ML compiler called MLton caught my attention.

MLton is a whole-program optimizing Standard ML compiler. It generates standalone executables with excellent runtime performance, supports the full SML 97 language, and has a complete basis library. It also has a fast C FFI, source-level time and allocation profiling, and many useful libraries.

XBOX 2 as a PC

One of three versions of the XBOX 2 is rumored to be "a fully functioning PC".

Interesting, because the XBOX 2 is supposed to be powered by IBM's PowerPC CPU.

C# or Java as Target Languages

An interesting post to comp.lang.lisp on generating code for C# (or Java)...

I am continuing to evolve a system that generates business applications for .NET in C#... it is giving us about a 10-1 productivity gain...

Why do we not just use Lisp as the delivery language? It comes down to components. .NET (and Java) have huge choices of commercially available components for GUI, Infrastructure, Database, ... (not available in Lisp).

Why not deliver Lisp that *connects* to the dotnet runtime? (e.g. Python.Net does this and Cincom Smalltalk is heading in the same direction with their Fall 2004 release.)

Queueing Fits

The Amazon queue service apparently has an undesirable use of HTTP. Seems like the design is aimed at being simple on the surface but not logical down deep.

Josh Sled provides a fairly simple Python implementation that is more RESTful. The implementation as well as the client code gets more complicated if you'd like it to be reliable, but the Amazon service provides no better guarantees.

Queues are nice. Would that they provided a tuple space.

Nonstop Languages

Catching up some more on old items in the queue. The title in this Register article refers to a "forgotten language" being used in "nonstop gadgets". Maybe we should refer to Lisp and Smalltalk as "nonstop" languages.

How does it achieve this magic? OOVM's technology comes in two parts, a VM and a development environment, and it uses Smalltalk, rather than modern-day kludges such as Java, which resembles a modern object-orientated environment in the way that a pub ashtray resembles a cigar store.

He has 18 years experience developing virtual machines. Any useful bit of advice stand out, we wondered?

"You have to make them simpler," he told us.

Appropriate Benchmarks

Catching up on some items, this one came through when I was on vacation a few months ago. Jon Udell wrote...

"When you think about it," Hugunin said, "why would the CLR be worse for dynamic languages than the JVM, given that Microsoft had the second mover advantage?" And in fact, while he had to do plenty of extra work to support dynamic features that the CLR doesn't natively offer, he notes that the massive engineering resources invested in the CLR make it highly optimized along a number of axes. So, for example, the CLR's function call overhead is apparently less than the native-code CPython's function call overhead, and this is one of the reasons why IronPython benchmarks well against CPython.

I am not sure I would use CPython as the benchmark for dynamic language performance.

Candor in Software Development

I love reading stories like these from James Robertson. They teach useful lessons and remind all of us to actually share them.

Not just "patterns" are worth sharing. We've all run into our share of "anti-patterns".

Thanks for demonstrating the value of candor. They are as enjoyable as reading about the ideal aspects of Smalltalk and software development.

Oh, yeah! *This* is good.

Phil Windley makes some sense about the election, and then falls off the deep end with a couple points...

I'm not sorry that Michael Moore was denied a victory. He doesn't need a bigger ego.

Yeah, boy. Good thing Moore's ego is in check. Don't worry about all those voters who believe a vote for Bush was a vote for Jesus.

Good thing that Michael Mooore's ego is in check. That's the real worry this time around.

And then...

The point is that the Democratic party platform is driven by issues that most people who are voting on moral issues simply can't support. That fact that eleven states voted to ban gay marriage yesterday is a case in point.

Yes, that is certainly the moral issue we should be concerned about. People dedicating their lives to each other. Of course, people will still dedicate their lives to each other, whether they are gay or straight. And states will proceed to spend millions of dollars amending these amendments with civil rights for commited couples.

But thank someone's god these moral folks had a chance to show that a vote against gays is a vote for Jesus. I guess Jesus wins double this time!

Are you gay today?

Ian writes about Illinois, Kerry, and gay marriage.

My state went for Kerry as well (Oregon). Unfortunately we also went for the anti-gay vote. After years of defeating moronic anti-gay amendments, the fear mongers found one wrapped in satin the average voter could fall for.

Humorously, one could interpret the amendment as prohibiting a heterosexual from remarrying. I hope someone figures out how to enforce that. Meanwhile we face years and millions of dollars enacting measures piecewise toward providing moderate civil rights for gay couples.

Way to go, Oregon! Smart thinking. Beats solving school funding problems.

The Middle Way

Dan Gillmor writes about the majority of Americans in the center. I hope we exist, organize, and fund ourselves into power.

There's a long row to hoe now.

Yesterday, Today, and Tomorrow

I thought I would be miserable today. I find that I'm not feeling to bad. The majority of voters appear to get what they wanted. (Good luck.)

Those who did not vote will get more of the same.

I sympathize with those who are feeling miserable. However at this point I find myself thinking, at least we get to see Bush having to deal with his own mess. (Good luck.)

Life will go on, we may find each other out in the street again, exercising our freedoms such as they are.

43

Following Kimbly's lead, I've turned my website black. It will remain this way for 43 days.

Principles for Reuse

Keith Ray is capturing some principles for reuse.

Also Robert Martin collected, edited, and augmented a now classic set of principles several years ago. (PDF)

Designing and Analyzing

Jon Udell on source code analysis writes...

TDD (test-driven development) is one increasingly popular approach to finding bugs.

Analysis is taking things apart. Design is putting things together. The tools described by Jon for automated analysis are fine.

But TDD is an approach for developers putting things together in such a way as they need less analysis later. Jon is misleading readers by putting TDD in the same category as automated analysis. TDD prevents bugs rather than find them.

Where more complex analysis is required today if available at all, the tools for design are improving in such a way as to reduce the amount of subsequent, after-the-fact, analysis. Such tools provide truly valuable model-driven development.

A really nice introduction into the theory and practice of these new tools is provided by the book "Concurrency: State Models & Java Programs". The future of TDD and truly advanced modeling is so bright you'll need to wear sunglasses.

Smalltalk and Predicate Dispatch

Danny Ayers writes about implementing Predicate Dispatch or Selective Inheritance in Smalltalk. The concern is the level of detail (VM?) required. Method Wrappers might be the best level of attack, at least initially.

My Choice

This is my choice. I mailed my ballot last week.

More from OOPSLA

Brian Marick writes...

In the Microsoft Research world, we're observers, consumers, secondary participants in an experience someone else has constructed for us. In Alan Kay's vision, we're actors in a world that's actively out there asking us to change it.

I wish the genial humanists like Ward and the obsessive visionaries like Alan Kay had more influence. I worry that the adolescence of computers is almost over, and that we're settling into that stagnant adulthood where you just plod on in the world as others made it, occasionally wistfully remembering the time when you thought endless possibility was all around you.

Harry Shearer on the Campaign

I have not found this on-line yet. It is in today's Observer.

I'm writing from California, where, despite lively ballot disputes on the State and local level, the Presidential election is mainly a rumor, fed by cable news. Poor souls, we only see the barrage of television ads that now constitute the bulk of a modern Presidential campaign when they're excerpted on the news broadcasts--which they increasingly are. In one of this campaign's novel twists, many adverts are now made only to be "released" to the Internet in the hope of garnering free news coverage. America is leading the way into the world of virtual commercials.

Back in the 1950s, fear-mongering cultural critics foresaw a dystopian future in which political leaders would be "sold like soap". They were risibly wrong. Soap advertising rarely stoops to the "In the last nine years, Glisten users have suffered hundreds of mysterious tumors, and yet Mr. Glisten doesn't seem to care" level, the level on which American political advertising, with its creepy background music, grotesque slo-mo footage and fear-inducing voice-over announcers, lives. We have come to the point where selling politicians like soap would be a big step up.

California is on the outside looking in because this state is overwhelmingly pro-Kerry. The polls--pardon me, it's the last time I'll mention them--say so. And so we suffer our lack of inundation, due to this odd confluence of a political antique and the latest technology. The antique is our Electoral College, which distributes votes for President state-by-state, and its accompanying state legislation which, with a couple of exceptions, apportions those votes on a winner-take-all basis. The latest technology, gleaned from advertising, dictates that you focus only on likely prospects. In California, long since relegated to the Kerry column, there are none. A California Bush voter is, in effect, a wasted Bush voter (except for the President's rumored desire to, this time, win the popular vote). So for us, as for you, this excruciating year has been, aside from the fund-raising, mainly a spectator sport.

The local daily newspaper printed an opinion piece last Sunday about the man whom a recent book identified as "Bush's Brain", the White House political swami Karl Rove. In the piece, liberal writer Neal Gabler offers the most dire interpretation of Rove's baleful influence on American politics--even calling him, at one point, Machiavellian. Well, excuse the hell out of me. I thought this was a contest about life-and-death issues, the war, global warming, the future of the United States as the world's most conventionally powerful nation--you know, stuff like that. If you really wanted to win such a momentous campaign, gosh, maybe you'd even like the operation to be run by someone Machievellian. After all, if the toilet stops up, I call the plumber.

Liberals, of the Hollywood variety particularly, evince the most exquisite dismay at the ruthless and unethical behavior of people like Rove. Then they go back to chuckling indulgently at the less ethical, and less explicable, behavior of the often-feral agents and producers in their own midst. At least Karl Rove has the good manners not to behave like a spoiled three-year-old who's been kept up two hours past his bedtime.

Democrats generally revel in the conceit that they're smarter than their opponents, while Republicans assure themselves they're more moral than the other guys. There's your "polarization" right there, along with a fact rarely mentioned by the political yakking class: America is in its twelfth year of a crisis of legitimacy. I know, that's a phrase usually associated with quasi-democracies on the wrong side of the Equator, but both Bill Clinton (who, due to the presence in the race of Ross Perot, didn't win a majority) and G. W. Bush (because of, you know, whatever) have been the objects of opposition fury only explicable by the conviction that they were usurpers.

Now, Bush is not the idiot liberals--and Europeans--like to think. He's got a kind of reptilian cunning, and Karl Rove taps right into that political lizard brain. Combine with fervid Methodism of the dispensationalist variety, and you've got ruthless certainty. Bush also has excellent speech writers, and he knows how to stick to the script (except in the debates, where he flailed in search of a credible persona). Arrayed on the other side is a U.S. Senator (the country hasn't sent a Senator to the White House since John F. Kennedy, a Catholic from Boston with the same initials). Kerry's way of vaulting over the threshhold issue--are you tough enough? --has been to proffer his Vietnam resume. When it was savaged by the "Swift Boats for Truth" ads, he spent the first three weeks of August not defending his own military record. When asked about this strategy, Kerry said that he wanted to respond to the ads, but his advisors wouldn't let him. And liberals smugly cluck at the Americans who can't quite buy him as a reassuring tower of strength.

During that fateful month, Kerry told a questioner at a Grand Canyon photo-op that, knowing what he knows now, he would still have cast his vote in the Senate to authorize the President to use force against Iraq. His partisans swoon over the cortical nuances of that position, but at that moment, the man who, as a youth, both fought in Vietnam and then returned to protest what he saw as a mistaken war, was caught in Bush's trap: He was stuck pledging nothing more than to do a better job of winning this mistaken war.

The Senator also has his own political savant, a seven-time loser (in Presidential campaigns) named Robert Shrum. His signature is a sort of throwback populism--Al Gore's "the people versus the powerful", or John Kerry's "fighting for the middle class". In a recent New York Times Magazine article, Shrum was asked why the Kerry campaign was ignoring the centerpiece of his Senate career--a tough and thorough investigation that led to the closing down of BCCI, an international bank with drug cartel and--how's this for relevance?--terrorism connections. Shrum's answer: it's too complex for "them". Populism in action. So, Kerry's Senatorial life is a self-defined black hole. Fortunately for him, there are no Machiavellians around to define it in more sinister terms.

Bill Clinton has been brought in to--this year's campaign cliche, ripped from the pages of the car dealer's training manual--"make the sale" for Kerry. Arnold Schwarzenegger is doing similar last-minute work for Bush. How do you like your testosterone: straight, or mixed with steroids?

Watching the campaign on the sub-textual level, which (given the English-as-a-second-language proclivities of the incumbent and the Senatorial prolixity of the challenger) may be the appropriate method, one can excuse the still-undecided for thinking this election boils down to a simple question: After the funeral, whom would you rather hang out with, the preacher or the mortician?

For me, it's also a simple question. Bush has run a disastrous war. Kerry has run a feckless campaign. Next Tuesday, the American people can punish only one of them.

Simplicity

The independent minded Knight quipped: "It's interesting they would comment on the simplicity because that's the part I thought was missing."

November Eve

Hopefully tonight will be dry. Last night my 12 year was terrified on a tour of five haunted houses.

Laser Shot to the Retina

Via Slashdot on Virtual Retina Displays from UW, potentially the future of displays for small devices (and aren't they all going to be small?)...

Furness is exploring a method to simplify the VRD and help bring costs down. His latest design dispenses with the mirror entirely. Instead, the tip of a single fiber-optic strand is pointed at the retina and mechanically bent back and forth at very high rates. Essentially, you're staring right down the beam instead of at its reflection. The stripped-down scanner, he says, may not only be less expensive to produce but also paints a prettier picture.

"We could make the image as big as we want and display a huge gamut of a colors," Furness says. "It would be like wearing an IMAX theater in a pair of eyeglasses."

Two Faces of Neutrality

Mark Baker weaves two threads together. Well done.

XML is *not* a Model

Uche Ogbuji writes in response to my remark about XML. Mainly he's concerned about the conflation of XML and WS*.

I would list something more serious... usage models. XML is just a notation. I agree WS* and XML are relatively distinct topics. But XML is used to represent everything from SOAP messages to config files to databases, and it's not particularly good at any of them.

What does it mean to perform an XML query, when XML is just a notation and not a model per se? There is no "there" there when it comes to what an XML model is. XML is a notation for expressing essentially *any* kind of model.

So worse than conflating XML and WS* is the notion that XML is a model of some kind.

Seminar: XML, RDF, Topic Maps, Relational Databases

Update - a comment from Manuel Simoni: Shawn Bower's thesis (PDF).

"XML, RDF, Topic Maps, Relational Databases: So many data models, so little time"

Lois Delcambre, PSU Computer Science / OGI
Monday, November 1, 2004, 12:00pm, FAB 10

One advantage of having different representation schemes and data models is that users can select the right representation and associated tools for their particular need. XML might be a great model to represent some of your information, but maybe sometimes you'd prefer to use RDF for some of your other data. The problem is that multiple representation schemes introduce structural, model-based heterogeneity, making it difficult to combine information from different sources and exploit information using generic tools (e.g., for querying or browsing).

In this work, we are interested in supporting multiple data models and representation schemes in a single, generic representation scheme. We have defined a meta-data-model based representation called the Uni-Level Description (ULD) with a novel architecture to overcome the limitations of typical meta-model based approaches. Unique features of the ULD include:

• The ULD can accurately describe representation schemes, such as XML and RDF where schema is optional, in addition to traditional database models where a schema must be defined before any data can be entered.
• The ULD permits data models that support multiple levels of schema or instance-of relationships.
• The ULD represents the constructs of the data model, schema if present, and data in a single, uniform representation that can be easily used by generic tools.

We have used the ULD to write powerful, generic transformation rules that can even transform data directly from one representation scheme to another. We have also investigated the use of a simple generic browsing capability over information represented in diverse data models and representation schemes.

In this talk, we will motivate and define the ULD and discuss the transformation and browsing applications.

Lois Delcambre is a Professor of Computer Science at Portland State University. She also has a joint appointment as a Professor of Computer Science and Engineering with the OGI School of Science and Engineering at the Oregon Health & Science University. She works in the database field of computer science with a particular interest in database data models as well as other models for structured information including thesaurus models, knowledge representation models, semi-structured models such as XML and RDF, and ontology models.

System Debt

Daniel Hinz writes from OOPSLA on the conference Wiki...

I think the concept of software debt is becoming an increasingly important concept. My experience indicates that way too many developers have a very short idea of the future. They move on often enough that they have no notion of interest coming due.

The Why of XML

James Robertson writes about XML's ubiquity and yet lameness as a notation for configuration.

On the other hand "ini" files are equally lame, being too simplistic. And so we have a simple yet more expressive alternative in YAML which serves as a reasonable data notation that is printable, efficient, readable, streamable, maps well to popular dynamic languages, and so on... several things that XML is not.

As I Suspected

From Greg Vaughn at OOPSLA 2004...

Another topic I’m seeing in various places, tutorials, practitioner reports, etc., is an analysis of what Architecture really is. One tongue in cheek definition given by Douglas Schmidt at a tutorial about the Forgotten Craft of Software Architecture is that architects are those people whose development skills are too oudated to still be developers, but don’t look good enough in suits to be managers.

Principled Design

Roy Fielding writes...

Software development is still driven by fads and fashion. In order to become well known, you need to hire some sexy models and generate press. Personally, I'd rather that people just learn a little more about software architecture and principled design.

Who Cares?

S. Mike Dierken in the rest-discuss Yahoo group...

I've only met two or three people that understand - much less care deeply - about REST. I have met people that quickly recognize the value when I explain the basics, though. Amazon is full of very smart & quick people.

Put me in that latter category. Not that I am very smart or quick, but I recognize the value of the basics. I still get lost in the details when even the people who care deeply debate them.

I like this from Roy Fielding, which may be enough for me...

In short, if you can draw a state machine in which each state is self-described (resident on the client), the transitions from that state are also self-described (instructions for the client to initiate), and each transition is invoked using a self-descriptive message, then you have a RESTful application. All of the rest of the constraints fall out from the need to be self-descriptive...

Note, however, that it isn't necessary for all components to understand all of the semantics. It is only necessary for them to know when they do understand them and also when they do not. That way, applications can be deployed within the subset of the network that does understand without adversely impacting the components that do not (assuming they are implemented according to the communication standards).

And then there's this follow-up from Dave Pawson...

Following this most recent thread makes grabbing eels look easy.

Another Kind of Scaling

Joel captures the anti-institutional aspect of Web 2.0, although he hasn't expressed it this way.

First, Joel on Microsoft...

If I were Bill (Gates), I think I'd fire about three quarters of the people working on that (the presentation system). Not because they are incompetent. But because there are too many people creating too many technologies.

Compare with the Web 2.0 paradigm, e.g. Basecamp...

Aren’t big payrolls and large head counts Web 1.0?

Back to Joel, this time on Google...

One of the mistakes Google is making is applications like Gmail are great on the Google platform. But if Google was really paying attention, they'd say we have to have outside developers writing applications for Google. There should be 27 different e-mail systems using the Google infrastructure.

And finally, Joel on other Web 1.0 institutions...

Nobody's ever going to use SharePoint in college. Ever. So no startup is ever going to use SharePoint because none of the kids who leave college are going to know it. This was BEA's big problem. Kids in college, when they want to learn about Web development, they learn Perl, PHP, maybe Microsoft's (ASP.Net) stack. They don't learn about Domino or BEA...

It's weird Microsoft doesn't recognize this with things like SharePoint and InfoPath. .. the only way those guys [BEA, MSFT, etc.] have hope of getting mind share in the market is to have an extensive sales force.

Half Mast

The computing flag is at half mast. Ken Iverson has died at the age of 83.

As the inventor of APL, Iverson was truly one of just a handful of original thinkers of programming.

The Syntax and Semantics of Coordination

Don Box...

To anticipate Patrick's comments, I'm a huge fan of minimal kernels of abstraction (like lisp) upon which we define entire universes.

SOAP is minimalistic enough for me - it's sad (but not terminal) that SOAP's defun, WSDL/XSD, is as complicated as it is.

Had we started with a simpler basis (perhaps Relax NG + some SOAP-specific extensions), my guess is we'd be having different discussions right now.

This seems to be arguing about syntax, more or less. I think the more interesting argument is about semantics. In particular, the semantics of coordination.

Looking for a minimal *coordination* kernel (a machine) upon which we define entire *coordinated* universes, SOAP is merely a syntax for defining the right machine primitives. SOAP is a general purpose *language* kernel. We still need to define the machine kernel, whether we use SOAP or something other language to describe it.

What would make a good coordination machine kernel?

It should have enough primitives to be useful for the simplest cases. Those primitives should be fixed and yet composable for most of the interesting, complex cases.

RESTful POST's

The rest-discuss Yahoo group is in the midst of a useful discussion of what makes for RESTful uses of HTTP POST. Roy Fielding's description of a RESTful client-based state machine was a point in the conversation that I could latch on to.

From there I was able to go back and forth through the chronology of messages to piece together the points of discussion. Mark Baker's arguing for a more strict definition of RESTful POST (I think) than Roy, but I'm not sure yet whether this is a communication issue or a technical issue with HTTP itself.

IBM and Smalltalk, Dynamic Languages

Is IBM blowing their Smalltalk ship out of the water just when the tide is heading again for dynamic languages?

Mosaic

A creative mosaic memorial.

I am not an economist...

...so this could either concern me or lull me to sleep...

The Chinese currency is currently overheated, with inflation there approaching double-digit levels and threatening to lead to economic collapse. Prevailing view is that if China doesn't immediately revalue its currency upwards by 20-25% (so much for the benefits of offshoring!), it will suffer a hard correction and severe recession. The consequences of that will be a sharp, inflationary increase in the cost of Chinese goods, and great difficulties for the many, many American companies that are now utterly dependent on cheap Chinese goods for their survival. Thanks, Wal-Mart!

Who'da thunk it?

Cornell University News...

According to a new Cornell University study, Bush's approval rating rises every time the federal government issues a new terrorist warning, by an average margin of 2.75 points.

Email and stardecisions.com is back

My domain as well as email to stardecisions.com has been down and in transition (really limbo) for quite a while. If you've sent email to patrickdlogan at stardecisions.com in the last month or so, I probably haven't seen it.

But now I have the domain running on a hosted user-mode Linux box at linode.com. Postfix is running and email is flowing again, for better or worse.

User-mode Linux is a great way to run at least a low-traffic server where you want full control over the systems you run. And webmin is a convenient way to administer all the typical services you'd want to run.

Going Upriver

The documentary "Going Upriver" is available on-line.

Playing with Fire

Dave Winer writes about the Valerie Plame case, in which one or two senior Bush officials very likely broke significant laws...

If it's true that Bush Administration is using dirty tricks to silence critics, playing with people's lives for crying out loud (something that as far as we know even Nixon didn't do), doesn't the electorate deserve to know?

There is significant evidence the Nixon campaign in 1968 played with lives by interfering with peace talks held by the Johnson administration that might have ended the war half a dozen years than what turned out to be the case. The Nixon campaign apparently was sending backchannel messages to the enemy that if they held out for a Nixon victory, the new administration would cut them a better deal. There is also evidence that Johnson and Humphrey were onto the covert operation, but perhaps did not have enough evidence to go public before the election.

Nixon probably played with about 20,000 American lives with this one since the adminstration found it more profitable to continue rather than end the war. Who knows how many Vietnamese, Cambodians, Laotians, and others would not have died had the peace talks ended the war in 1968.

Should anyone complain I am just an ardent Democrat (I'm not even a registered Democrat!) I will also state the obvious that Johnson also played with tens of thousands of lives (at a minimum), through events the least of which was not the Gulf of Tonkin.

Fascism

Fascism: [n] a political theory advocating an authoritarian hierarchical government (as opposed to democracy or liberalism)

From Bend, Oregon, via the Associated Press...

“We chose this phrase specifically because we didn't think it would be offensive or degrading or obscene," said Tania Tong, 34, a special education teacher.

Thursday’s event in Oregon sets a new bar for a Bush/Cheney campaign that has taken extraordinary measures to screen the opinions of those who attend Bush and Cheney speeches. For months, the Bush/Cheney campaign has limited event access to those willing to volunteer in Bush/Cheney campaign offices. In recent weeks, the Bush/Cheney campaign has gone so far as to have those who voice dissenting viewpoints at their events arrested and charged as criminals.

Thursday’s actions in Oregon set a new standard even for Bush/Cheney – removing and threatening with arrest citizens who in no way disrupt an event and wear clothing that expresses non-disruptive party-neutral viewpoints such as “Protect Our Civil Liberties.”

It's time to choose, Americans. Do we move closer to fascism or not?

Lisp T-shirts

Get your Lisp t-shirts now. John McCarthy on the front, and a cons cell on the back.

Here.

(Via Lemonodor.)

Angels in America

Chris Sell's started Angels in America and did not go for it. Early this morning as a matter of fact I just completed the second of two DVD's.

I thought it was an amazing script presented by several powerful actors (playing multiple roles), produced and directed beyond belief.

Chris did go for Emma Thompson. She plays more than a classic angel, actually something like a hierodule.

Angles in America is a play simultaneously ancient and modern, set in the 1980's, and created with production values from the 21st century.

Daily Zen

Deep among ten thousand peaks
I sit alone cross-legged
A solitary thought fills
My empty mind
My body is the moon
That lights the winter sky
In rivers and in lakes
Are its only reflections.

- Han-shan Te-ch’ing (1546-1623)

Toward a Discipline of Coordination and Action

Don Box on verbs...

I completely agree with the first two paragraphs.

As for the last paragraph, I would argue that HTTP POST is a "coordination" verb and that WSDL is typically used for defining "action" verbs. It's not clear from Patrick's post whether we agree or disagree.

I don't have a large set of examples of SOAP systems, but I've not seen any except for Ruple (PDF) that distinguish between coordination verbs and action verbs. The uses of POST are typically many clients to one server, where the server coordinates the sessions to perform each request. So I don't see a clean distinction there either, in practice or intent.

A new set of verbs or a new discipline (like this one from Vanessa Williams) will be required to achieve the distinction. Again, Ruple is an example of a new set of verbs for coordination. (Was it just ahead of its time, or would it have been more successful if the implementation was more open?)

WS-Transfer (PDF) , like Ruple, appears to be a set of SOAP verbs for coordination. The intent is not as clear to me (it's new without much to go on save the spec itself), at least not as clear as with Ruple. Assuming the intent, I am then not sure about the relative value of WS-Transfer vs. Ruple. For example, Ruple (based on Linda) uses content-based addressing via XML patterns and queries, while WS-Transfer uses direct addressing, WS-Addressing (PDF).

Is this a problem, given a separate query mechanism that yields a direct address that becomes the target of a transfer method? I would argue that (but experience will tell whether) this complicates the coordination responsibilities of the participants. Consider a query-then-delete sequence. In Ruple this is one atomic method. In WS-Transfer a mechanism or convention outside of the specification itself is necessary to coordinate this sequence.

As referenced above, Vanessa William's Restful Tuple Spaces is such a convention using HTTP methods. As she writes...

Clearly, this isn't as simple as sending a few SOAP messages back and forth over some reliable message service.

Maybe there is a need for one more WS-xxx. (Did I say that out loud?)

BTW, Patrick, I hope you'll be at the SellsCon next week.

I can't make it this time, and the location is perfect. I've stayed there, it's great, so maybe this will become its new home.

Micro-Workflow: Separating Coordination and Action

Dragos Manolescu's Micro-Workflow is another example of separating "coordination verbs" from "action verbs".

Paradigms of Coordination

What I would consider paradigms of coordination: CSP, Linda, Erlang/OTP, and OVAL, nee Object Lens, nee Information Lens. I'm sure there're some good ones I've omitted.

One thing each of these have in common: the separation of verbs for coordination from verbs for action.

Number 24

Three Days of the Condor is 24th on the Netflix Top 25 in Classics. I have to watch this movie several times a year, but I had no idea of its overall popularity.

His name is Joe Turner -- code name, Condor. In the next 24 hours, everyone he trusts will try to kill him. Robert Redford stars as the CIA researcher who returns from lunch to find all his co-workers murdered. Double-crossed and forced to go underground, he kidnaps a young woman (Faye Dunaway) and holds her hostage as he unravels the mystery. Conspiracy films don't come any better.

Verbs for Coordination, Verbs for Action

This is a restatement of the previous item...

I think the fundamental problem is we need to distinguish between verbs for coordination and verbs for action. Verbs for coordination should be a small fixed set that describe the putting of messages into (and taking of messages from) a shared space.

Verbs for action (e.g. to reboot some machine at some time) by their very nature will be larger and less stable. Certain domains have more stable sets of verbs than others, and many others would be expected to stabilize with increased use.

Requesting an action of another participant in the system consists of putting a verb for action in a message, and using a verb for coordination to get that message to the participant. Overloading POST or creating new WSDL definitions are examples of conflating these two kinds of verbs, those for coordination and those for action.

Verbs for Doing One Thing Well

One "take away" from this essay by Bill de Hora on the problems is there are significant problems with overloading POST in HTTP as well as falling back to defining new verbs beyond those in WS-Transfer.

Here's the root of the problem with these vocabularies.

I wrote last year...

Every web site that implements custom behavior using forms with GET or POST is an example of the open ended nature of HTTP per se. The architectural style of REST supports the HTTP transport protocol underlying these forms moving across the web, but the application protocol, that is, the behavior of the forms on the client and especially on the server is defined (at least in code) by each specific instance.

Distributed systems wishing to use HTTP, or more generally REST, to perform coordinated work will therefore require some more specifically defined application interface than that provided by REST, or that provided by HTTP.

(Of course I no longer refer to HTTP as a *transport* layer protocol!)

The problem I believe is that the verbs in HTTP as well as in WS-Transfer are attempting to accomodate not only message coordination, but also participant behavior. The problem is developers, if not the specification authors themselves, are thinking of these protocols as communication between a second-class participant (the "client", if you will) and a first-class participant (the "server", if you will).

Our habit is to attempt to overload the verbs of these protocols with our desired "server-side" behavior. This is what happens in the current Web (Web 1.0) where the client is the browser and the server is assumed in most cases to be a database-backed web site. The web site essentially provides the illusion of trees of static pages, but we allow for dynamic update, mostly through forms.

This does not translate cleanly to Web 2.0 with dynamic networks of peers coordinating nearly autonomous actions through semi-structured messages. Overloading verbs such as POST or extending "fixed" vocabularies such as WS-Transfer, as Bill and others have shown, is not "loosely coupled".

The more clean solution I think is to allow each verb in a small fixed set to do one thing well. And that one thing should not be overloaded. Ever.

A good way to do this is to separate message coordination from participant behavior. This requires at least the conceptual or logical separation of the message store (i.e. what was the tree of pages in Web 1.0) from *all* participants, including that participant we want so much to call "the server".

Again, a tuple space is a model for this separation of concerns. The tuple space is the message store. The verbs for coordinating messages into and out of that store never have anything to do with the behavior of any participant. Each verb does one thing well with no overloading and no extension. (There has been a good deal of research into what's the right set of verbs, but the core is pretty solid.)

In this world, the decision of what verb to use for rebooting a machine is moot. The message store is merely a location for storing messages participating in a conversation. If one of those participants choosing to reboot (or reboot something else) then that is the responsibility of the participants in the system.

This side effect is decidedly *not* the responsibility of the verbs used to coordinate messages!

Ingredients for Post Modern Computing

Quoting Sean McGrath from another item...

JVM + dynamic languages + XML + servlets + asynchronous messaging, which, to my way of thinking, are most of what is needed for flexible, scalable Web Services at least for the next century or so.

Let's look at these ingredients:

Asynchronous Messaging

Yes, this is the foundational paradigm.

XML

Well, yes, because that's what's expected. OK.

Servlets

OK, if you take this generically to mean some kind of simple framework for plugging in responders to external requests (e.g. see the design of SmallWiki in this PDF).

Dynamic Languages

Of course. Goes without saying.

JVM

Huh? Nope. I draw the line here. Why is the JVM necessary or desirable, even for cross-platform languages?

Patterns of Rest in Action

Sean McGrath writes...

I'm very dubious about Don's assertion, mentioned by Mark, that once you get (no pun intended) uniform interfaces based on verbs, you see the benefit of creating domain-specific, verb-based interfaces.

Verb-oriented developers should read a couple of foundational books (i.e. this and this) to see "rest-like" counter patterns and examples.

On WS-xxx, CORBA, and DCOM

After demonstrating the simplicity of CORBA under Smalltalk, James writes...

The main reason that WS* is succeeding where CORBA failed? Port 80

I would agree that WS-xxx succeeded in capturing the imagination of the industry because of port 80. I am not sure WS-xxx could be considered a technical success at all yet. (If you think it is, then I'd like to see the list of success stories to judge for myself.)

I'm not crazy about CORBA, but implementations were getting good performance, less expensive, and open sourced before WS-xxx came along. (Note that IIOP did not come along until late in CORBA's history.) There is no reason CORBA could not have worked on port 80. WS-xxx is simply a more successful (broader) diversion than DCOM, because technically DCOM was even worse. As Don Box pointed out, would have been hell to get running on Unix. (They tried.)

But WS-xxx has a long way to go to be a technical or industry success.

Uniter or Divider?

Maybe we should determine the request of another term from Mr. Bush on the answer to one question. In 2000, Mr. Bush clearly claimed to be "a uniter, not a divider."

Well, is he a uniter or a divider? (Arm twisting shouldn't count.)

Kingdomality

Another survey is making the rounds. Here I am...

Your distinct personality, The Dreamer-Minstrel might be found in most of the thriving kingdoms of the time. You can always see the "Silver Lining" to every dark and dreary cloud. Look at the bright side is your motto and understanding why everything happens for the best is your goal. You are the positive optimist of the world who provides the hope for all humankind. There is nothing so terrible that you can not find some good within it. On the positive side, you are spontaneous, charismatic, idealistic and empathic. On the negative side, you may be a sentimental dreamer who is emotionally impractical. Interestingly, your preference is just as applicable in today's corporate kingdoms.

Daily Zen

Daily Zen...

Because you grasp labels and slogans,
You are hindered by those labels and slogans,
Both those used in ordinary life and those
Considered sacred.
Thus they obstruct your perception
Of objective truth,
And you cannot understand clearly.

- Linji (d. 867)

Not Innocuous

Mark Baker responds...

"innocuous"? I wouldn't say that. I think it's actively harmful as a name for an architectural style. As I see it, "SOA" means different things to different people...it does nothing to constrain how one might go about building distributed systems.

Fair enough. I've not seen the harm yet, but there's still time. 8^/

REST and SOA

Mark Baker writes...

Gartner's claim that REST proponents rag on SOAP is backwards; we like SOAP, mostly. We just don't like SOA.

I consider myself a REST convert, to the extent I think I understand it and its incarnation in HTTP. Though I don't understand the position above. Is there even a concrete definition of SOA with which to make this statement?

I thought SOA was a fairly innocuous term, being so vaguely defined that an SOA could be built using REST and HTTP.

Deleted Post

Radovan Janecek writes...

Patrick's post looked like I don't like criticism or discussion. Btw, it seems he removed his 'Criticism', entry. Hmm.

Yes, I was in a hurry, saw your comment that I misinterpreted you, and took the fast route of just deleting the post, leaving no trail. Worked in a pinch, rather than leaving my misrepresentation up on the site for a day.

MBF and WinFS: a False Dichotomy?

Tim Brookins writes more about MBF and WinFS. This pleases me because I want to like MBF and WinFS. But it concerns me because I'm uncomfortable with the direction they're taking. I should say I like the high-level intent to support building domain-driven designs and flexible databases. But...

Wouldn't it be fantastic to finally let users see their Customers and Orders in the shell?

I think these days they want to see them easily from any device, any location. That would mean the Internet browser rather than the Windows shell. Why the shell? That's outdated. I don't even want to see the shell, period.

ISVs really need one combined platform which merges the best of the WinFS and MBF data persistence stories.

Most ISVs are building world-wide web applications these days, aren't they? They need a simple user interface and a flexible database. In tomorrow's mobile world, a flexible database will not have a single location...

While WinFS synchronization is great for keeping your pictures synced across machines, it really isn't going to be viable to build a multi-user business application. So you need the server-side N-Tier capabilities that MBF provides.

This seems to be a false dichotomy. I've seen too many domain-driven systems become prematurely obsolete from built-in dependencies on specific underlying mechanisms. We need objects that can live a dozen years or more. This is demonstrably *not* the way to do so.

MBF should be an arms distance from WinFS, Indigo, Avalon, SQL Server, etc. I've already stated WinFS should be a more flexible database rather than an elaborate file system.

Nukes

Ted Leung points to a rosy article in Wired about pebble-bed nuclear reactors as a "safe" way out of the energy crisis.

Even if this approach is safer, is it safe?

The article does not address a couple of, well, problems:

• Security ("dirty" bombs, anyone?)
• Waste Management.

Oh, the article *does* address waste management...

And with the fuel sealed inside layers of graphite and impermeable silicon carbide - designed to last 1 million years - there's no steaming pool for spent fuel rods. Depleted balls can go straight into lead-lined steel bins in the basement.

Looking around at our world's politics, not to mention science, I have to sigh just a little at the phrase "designed to last 1 million years". We have no true concept of this.

Python and Code Blocks

Hans Nowak is wondering about code blocks in Python. While Python's anonymous (lambda) functions are fairly awkward, Python does do a kind of "Currying" over self. The following code shows the simpler mechanism Hans is looking for...

Jython 2.1 on java1.4.1_01 (JIT: null)
Type "copyright", "credits" or "license" for more information.
>>> class FooBar:
...   def foo(self):
...     print self
...     print "OK?"
...
>>> fb = FooBar()
>>> fb.foo()
__main__.FooBar instance at 17493979
OK?
>>> fb2 = FooBar()
>>> fb2
__main__.FooBar instance at 24940415
>>> fb2.foo()
__main__.FooBar instance at 24940415
OK?
>> fb2.foo()
__main__.FooBar instance at 24940415
OK?
>>> fb.foo
method FooBar.foo of FooBar instance at 17493979
>>> fb2.foo
method FooBar.foo of FooBar instance at 24940415
>>> 

WS-Transfer Comments Elsewhere

Update: Other useful quotes from Tim Bray...

I’m deeply suspicious of “standards” built by committees in advance of industry experience, and I’m deeply suspicious of... multiple layers of abstraction that try to get between me and the messages full of angle-bracketed text that I push around to get work done.

And Sean McGrath writes...

The whole WS standards thing has more moving parts than a 747. Much of it recently invented, untested and unproven in the real world... there are no exceptions to Gall's Law:

"A complex system that works is invariably found to have evolved from a simple system that worked."

Originally I quoted jeff schneider writing...

I am of the opinion that the WS-* spec teams are doing a severe disservice to the community by releasing these specifications without also identifying the best practices. In my opinion, it is no longer acceptable to release paradigm changing specifications without also releasing an implementation or best practice guide to go with it.

I could not agree more. The argument could be made there is a good bit of experience with these particular verbs. I think that argument is implicit (read below). But such an argument would be invalid. By far the majority of experiences with these verbs is unrelated to the kinds of systems this spec is intended for. Clearly this kind of a shift should be accompanied by references, examples, and best practices.

Standardizing verbs is good. I was a bit curious why the group didn't create a 'verb extension' or 'verb introduction' mechanism, but rather just 'hardcoded' a handful of verbs.

I am thankful they did not. Better to get experience with a fixed set and expand on that later if warranted.

WS-Transfer

Web Service Transfer (WS-Transfer)

Sorry. For some reason MSDN decided not to put tags inside the page. If you scroll down a few screensful, you will find the definition in a PDF and this abstract...

WS-Transfer defines how to invoke a simple set of familiar verbs (Get, Post, Put, and Delete) using SOAP. An application protocol may be constructed to perform these operations over resources.

Why, yes, these verbs do seem familiar. This makes them easier to adopt into a brand new spec, I guess. But does that make them the right set of verbs?

These verbs are workable in HTTP. But are they desirable when starting over? Do they facilitate automated coordination of distributed, asynchronous resources as well as any other set of verbs?

This spec looks to me like the easy way out of the job of hypothesizing, discovering, and validating something potentially more useful. Curious HTTP is not listed in the references. Neither are any landmark writings in the history of coordination mechanisms.

Sigh. While this could be seen as a simplified path out of the deep, dark woods of the WS-xxx, instead it is a cheap short cut avoiding or at least lacking much evidence of deep thought. Typical for WS-xxx then.

Florida Power & Light and Gemstone

A story from Charles Monteiro about FP&L's use of Smalltalk and Gemstone in their call center and trouble management systems.

I was pleased to know that the call center systems I had helped build were still standing and so was the trouble call management system among others.

Me too, then, I guess, in a smaller way. I wrote the Gem multiplexor that removed the "1 user / 1 OS process" restriction, to scale up the number of client connections to numbers approaching those claimed by the sales people years before. FP&L was one of the first customers to use it. Supposedly there was one situation where the Gemstone system kept running on Unix while IBM had to come in and patch the TCP/IP stack on the mainframe part of the system. Gemstone then cranked back up to full speed.

I am glad that so far those systems have weathered the Java marketing hype hurricane.

Yeah, that's great. Unfortunately Gemstone had barely developed federated Stones, multiplexed Gems, and better DB connections just before putting those efforts on the shelf in favor of the Java grail which not surprisingly never materialized. They continued making money from Smalltalk.

GNU Smalltalk and GTK+

From OS News...

"Hey - did you know that GNU Smalltalk now has GTK+ bindings? This is pretty sweet."

Wandering About in the Past

I miss the Greater Boston Chapter of the ACM, in particular their in-depth workshops like the one coming up on Parrot.

About twenty years ago, Adele Goldberg was president of the ACM. She gave a talk to the GBC-ACM, and a Saturday before or after someone held one of those all-day Saturday workshops on Smalltalk. That was my first exposure to Smalltalk and circuitously led to the Mainsail programming language being ported to the Data General 32-bit Eclipse CPU.

The Alto was based on the DG Nova, and Data General was one of the first licensees of Smalltalk, but I never saw Smalltalk running on any DG hardware. Mainsail (a "managed runtime" in today's dry terminology) almost became the primary application development language for DG's workstations. Unfortunately C and Unix had captured a lot of imagination in the early 1980s and DG followed that road, ultimately to destruction, as HP did to Apollo.

Hmm... Synchronization

Steve Gillmor wites:

Hmmm…synchronization. That rings a bell. Oh yes, the Alchemy stuff that Adam Bosworth was working on at BEA before he left to join Google. The Alchemy framework establishes an intelligent cache layer between the server and the browser client, allowing robust support for transactions and off-line support within standards-based browsers, just what Google needs to extend Gmail and other services to enterprise customers to G-Spot.

And Starring Pancho Villa as Himself

I recently saw "And Starring Pancho Villa as Himself" on DVD. The movie is good, I'd like to read more about Pancho Villa now.

The main disappointment was the DVD's extras. I would have wanted more historical background on Pancho Villa. Larry Gelbart's running commentary is interesting.

Services and Data

A pretty good exposition of services and data within and across service bouindaries from Microsoft. Something is lacking though...

SQL makes a great tool for representing data on the inside of services. These strengths are inextricably linked to the bounded nature in both space and time of SQL, which make it fantastic for representing data on the "inside". Unlike XML, SQL has strong querying capabilities. SQL's makes comparisons between almost anything within the bounds of the database. Because of SQL's bounded nature, however, it is incapable of the strengths of XML in the "outside". SQL does not offer independent definition of schema as it depends heavily on a centralized and tightly coupled DDL.

What's wrong with this? It's out of focus.

At some point though developers will have to address data models as opposed to data notations. What are good models within and across service boundaries, whatever the notations used to representation and query? I have some ideas, but I'd like to see these ideas addressed more broadly and deeply.