Angels dancing on heads of pins and all that

We used to see all kinds of analysis of what kind of C code is generated from the original CFront pre-compiler for AT&T's C++. The C programmers were obsessed. We still see the same kind of obsessions in the dotnet world for some reason, much more than we saw in the early days of Java.

In Smalltalk (yeah, I know: it's "nyah! nyah!" time again) all "control flow statements" are done by sending objects messages. This "hard coded" statement...

for (int i = 0; i < foo.Length; i++) {}

becomes this message send (named #to:do: which can be redefined, inherited, etc. as with any message)...

1 to: foo length do: []

...and then we leave it to the compiler to generate efficient code most of the time, and get on with our lives.

If you are worried about the efficiency of a for loop in C#, more than the number of iterations, and more than the efficiency of the body of the loop itself, well, then might I suggest you are either worrying about the wrong thing or you are using the wrong language.

Angels dancing on heads of pins, and all that.

More good stuff bouncing around the blogs on distribution models

Bill de Hora leads to the conclusion (IMHO)...

a transactional blackboard... if we were doing Java middleware over tommorrow, Jini/JXTA would be where to start, not J2EE.

Yes, because even more than "service oriented architecture", I believe developers, at least back in my day, understood the concept of distributed coordination via a database.

"If I put something like this there, then something like that happens, and I can look later to find one of those things."

Continuing...

Todd... says objects are not a good model for services.

Agreed. Objects are a code management mechanism. No more, no less. If you need to manage code on both ends of a connection, then "distributed objects" might be a benefit to you. It's still just about code organization, though.

Relax

Reportedly Microsoft (or I assume some contingent within Microsoft) writes their schemas in RELAX NG and then translates them into W3C XML Schema Language. What's that last step for?

More interesting statements from the XML community via that link...

XML syntax may not be right for all applications

XML is like...

XML is like cardboard (huh?) because it is...

Protective - Cardboard protects the contents in the box and what's more it does not matter what the size of the box is, it is the contents that matter! How many times have you been sent a huge box just for that memory SIMM card, hard drive or other piece of electronic equipment? You have always been glad to have a big protective cardboard box. Same with XML. It does not matter that the format for messages can be verbose; it is the contents of the XML that matters and ensuring that it is safely delivered.

I'm sorry. Pause. How is XML protective? What are they drinking up there in Redmond?

When it rains it pours

Turns out Alan Kay also rec'd the Draper Prize, along with Butler Lampson, et al. Words of wisdom from Lampson, via one of their colleagues...

"The design rule for the machine was that it had to be as simple as possible, Butler (Lampson)'s approach to that was to make something that was too simple and make us argue why we couldn't live with that. And he set the bar high before he would add another feature."

Found on Jim's site. His chosen quote is also a gem and a half...

Kay added: "I have said to powerful computer industrialists: By all means use the ideas, but please try to understand and use the entire idea, otherwise what happens are the gross caricatures so often found in commercial vendor software. The evidence indicates that they didn't understand or heed my request."

And now back to our story on how XML is like cardboard. Sigh.

Language as Mechanism

Perhaps we should ask if this the right road to go down - at what point does the kernel become an interpreter? Maybe what we need is not a middleware container, but a middleware interpreter.

Also found in the same post...

I once described Eclipse as a $40M port of Emacs to an IBMer - which [didn't] go down too well.

Love it.

Glad

Yes, but I am *so* glad it's not CORBA! 8^)

That's the main thing.

They *Are* Your Airwaves

MIT World on the Emerging Media Landscape. Don't be afraid, be active. Portland has a vibrant community radio station.

In commercial radio, mass consolidation has left small towns without local news. When a South Dakota town had to evacuate for a chemical spill, authorities phoned the only local radio station in town only to find the phone being answered in San Antonio, Texas. "After 20 years of thin gruel...the public distrust us. We give people informational comfort food and they don't believe we provide balanced information."

Reasons to be worried

I would be especially worried if updates to my tools were focussed on crippling my designs to protect you from the classes I give you. (And especially vice versa! 8^)

Over the last 30-40 (thirty to forty!) years how many times were crippling features added to Lisp or Smalltalk, or their toolsets?

g00se egg.

Middleware Dark Matter

Jon Udell on middleware, um, "matter" and "anti-matter"(?)...

Plus the middleware universe is ever-evolving. Decisions I'm facing this week are depending on a cascading set of product version availabilities from generations of middleware on the IT roadmap.

There is not today, and probably never will be, a middleware Utopia. Post-modern middleware is how I would characterize this experience and what I think Jon is getting at.

Get the word out

Reasonable advice on subclasses for languages that basically suck.

Which OS are you, again?

Damn. I'd pay money for that one. Even more for the Lisp Machine OS.

An excellent discussion of the Powell Doctrine and the Rumsfeld Doctrine. One a success and one a failure. It also demonstrates the dysfunctional aspects of this administration, the inability of the State Dept. (Powell) and the Defense Dept. (Rumsfeld) to work together in any sort of collaboration. We see it today, when we are sending Richard Armitage to the Middle East to curry favor with the Arab states, days after Sharon gets the administration's blessing and a Hamas leader is assassinated. Should be a nice mission.

I am neither a registered Republican nor Democrat. I "vote the candidate" not the party. This usually translates into a "lesser of two evils" vote.

This year, it's a no brainer. In fact, that's my greatest fear for my children.

Math Joke

From one of my favorite contributors to Lambda the Ultimate...

Frank Atanassow - Re: Tunneling Variables  
4/20/2004; 11:07:06 AM (reads: 101, responses: 0)

The markup language community is notorious for reinventing and duplicating concepts and terminology, sometimes even their own. Thus they have "minimum literals" rather than "string literals", "parameter entities" rather than "macros", "templates" rather than "procedures" or "functions", "validate" rather "type-check", "data binding" rather than "translation", "unmarshal" rather than "parse" et cetera.

I long ago gave up trying to get them to use conventional terminology; for them to acknowledge prior art would require them to acknowledge some unpleasant facts, like that story about the emperor and his new clothes.

OTOH, there are typically a dozen, largely pointless, technical reasons why one should use more conventional names for most of these things; their semantics differ in some corner case, or has been made more convoluted to handle some special situation which could actually have been handled more cleanly and less artificially by generalizing some other construct. (This is what I discovered when I wrote a paper based on a formal semantics of XML Schema.) Probably tunnel variables differ from implicit parameters/dynamic scoping in such a way.

It's really a big mess. I try to stay out of it. Let them build their sand castles where they like. Next year they will publish another twenty W3C recommendations and ISO standards to address the special cases in the corner cases at the fenceposts anyway.

Note: We're all using the wrong tools for SOA

Note that throughout this WSDL, er, CORBA, SOA, er, Distributed Objects, er, Erlang thingy, note one thing:

All the languages we'll be using in this brave new world, er, suck at it, except for, er, Erlang and Lisp.

Smalltalk is not even set up well for this approach. Lisp is as good as Erlang in this regard because:

• The syntax is conducive to extending it for anything, especially pattern matching.
• Classes are not required to define everything.
• Several Lisp implementations support Erlang-scale processes, or nearly so.
• The "core" syntax can be redefined *easily* to handle (or disallow) global references, etc. as desired.

Smalltalk would be a reasonable choice, aside from the somewhat awkward syntax for pattern matching because:

• The syntax is simple.
• Tools can be defined to easily define classes, including patterns, for you.
• The "core" mechanisms, even the compiler, can be redefined easily to handle (or disallow) global references, etc. as desired.

Can't do much of this at all in the popular Java-like languages. They lose again.

Could do some of this in Python and Ruby though. The four better dynamic languages: Lisp, Smalltalk, Python, and Ruby.

WSDL and the New Reality

And now for WSDL in that discussion over there and beyond... I don't know whom to point to in this.

Ironically enough, the same problem faces WSDL right now--particularly with all these vendor toolkits running around, claiming to take your existing Java or .NET interface and create a WSDL document out of it, how can you NOT assume that WSDL == IDL == object interface?

In any case, should we admit that the WSDL and SOAP contingent switched horses mid-stream?

I'll admit this was a good switch, but it was a switch nonetheless.

The interesting question is are programming languages adapting to the new reality?

Java is taking on some steps to support isolated virtual processes. But what about others? What about pattern matching?

Kay to receive the Turing Award

If anyone is due, it would be this person. Alan Kay to receive the ACM Turing Award for his innovation of Smalltalk.

The "Oy" comment in the article: Today, the language is credited as the model for C++ and Java.

Oy.

Nevertheless I cannot wait for his Turing Award lecture. This would be worth attending in person. He tends not to hold back.

Another good introduction to Alan Kay.

XUL-balicious

Jon Udell on Mozilla...

Could InfoPath have been built on a Mozilla foundation instead? You bet. And the result wouldn't just be a great Windows application. It would be a great application, period.

Another apt quote of the day

Sometimes the truth hurts...

Let's be honest; anyone who thinks hype isn't of the essence in the software industry is selling something ;-)

SAP

SAP's Shai Agassi. I like what he's doing for SAP, but I'm not sure from this interview how much he really gets it.

A lot of potential.

Thumbs in the Dike

This story about corrupting firewalls might be a good spot to remember that firewalls are just another thumb in the dike, although we've come to think of them as "the way" to insulate us from the evil on the wild, wild Internet. Note that capability-based security would be the real innovation.

Microsoft?

Our Leader in the U.S.

Bush and science, or ignorance, depending on how you look at things.

Comparing Erlang and Smalltalk

Bill de Hora compares Erlang and Smalltalk message passing...

Joe Armstrong describes Erlang as a concurrent pure message passing language. Which might be characterized as Smalltalk on steroids. There's a lot of confusion around what is meant by 'message passing' in Smalltalk. Conceptually I think Smalltalkers are talking about message queue type messaging and in some cases asynchrony, but physically I understand Smalltalk works like Java or C++, i.e. it's jumptables, and pointers all the way down. Hence the confusion, but I trust someone will correct me if I'm wrong about this.

Yes, in Smalltalk a "message pass" is a synchrononous action. The mechanism is more flexible than with Java-like languages... the receiver has the opportunity to intercept the message. But yes, it is a synchronous "request/reply".

I think this is more a result of the original implementations of Smalltalk in the 1970's rather than a specific desire by Kay, et al. My guess is they were more concerned with encapsulation and less concerned or even knowledgable of the asynchrony issues. Although process classes have been around since then, so I should go back and read the paper. From the early history by Kay, emphasis is mine...

Smalltalk's design--and existence--is due to the insight that everything we can describe can be represented by the recursive composition of a single kind of behavioral building block that hides its combination of state and process inside itself and can be dealt with only through the exchange of messages.

Interesting experiments have been done making deliberately asynchronous Smalltalk-like languages, specifically with the Actors languages at MIT, UIUC, Japan, and elsewhere. (Intersting side note is the prevalence of continuations in these designs.)

Yes, programming in Erlang message loops is a lot like designing cooperative "active objects".

Life as we know it

Something memorable...

"People only change when something is dramatically wrong, forcing them to reassess. Otherwise, dysfunctionality is preferrable."