The ROI of Optional Type Annotations

From comments below...

How is the argument from reliability of Lisp and Erlang systems an argument against optional static type declarations?

The real question is, should optional type annotations be added to Python? I'd say no, the return on investment is not nearly as great as investing in several other implementation features.

In the Lisp world, you program with dynamic typing initially until the program stabilizes and the hot spots are known. You then type annotate just the hot spots to improve code generation of those hot spots (Lisp code is generally compiled), with the option to go to C to improve the hottest of the hot spots.

Optional type annotations were added to Common Lisp in the early 1980's. Compiler strategies have improved a lot since then, as have machine capabilities. I think a better return would come from investing in the implementation of the current Python language rather than changing the Python language itself.

Basically, type annotations in Lisp (and, one presumes, Python) are an upside option that you can but don't have to use. Writing Python code (or Lisp code) from scratch with type annotations would be pretty silly. (Or, to put this another way, in Lisp type annotation is a performance, not a reliability feature).

I think the downside of having every Python programmer have to understand the best practices of optional type annotations would be far worse than the upside of having them. To repeat myself, the investment should be made "under the hood" of the current Python language.

Sadness and Grief

Everytime a take a look at the news, the death toll has risen another thousand or so people. The number as I write this is around 22,000 deaths. That also implies so many tens of thousands of injuries.

How can these numbers be comprehended? Almost nothing I can recall, related to one single event compares. The map of impact includes Sri Lanka, the entire eastern seaboard of India, as well as Thailand, Indonesia, Malaysia.

Incomprehensible sadness and grief.

Ways to help.

About Myself

Anonymous (Sam?) wonders...

So the world wants to know...

Actually I doubt very few in the world want to know this.

...have you ever shipped a real commercial product ever (even better a scalable one) or are you just a play with esoteric languages complaining whiner?

The last few years I've just been playing with *agile* (not so esoteric) languages and been a complaining whiner. I've actually taken a new position where most of my time will be spent developing again, so for your benefit I may not have as much time to simply complain and whine!

But I have been developing software professionally for 20+ years, beginning when I was an undergrad CS major developing a payroll and materials management system in BASIC (not the visual kind) on an IBM 5100. I've also developed software for electronics design and simulation using PL/1, C, C++, Pascal, Mainsail (a Pascal-like language with garbage collection, etc.), and Lisp. I've developed factory automation systems in C, C++, and Lisp. I've developed conferencing systems in C++ and Smalltalk; business and web systems in Smalltalk and Java; and systems programming in C, Smalltalk, and Java. I developed a mechanism in Smalltalk that doubled the number of concurrent users for Gemstone Smalltalk systems using HTML and applet front-ends. One of the applications for this was a dispatching system developed at Florida Power and Light where the Gemstone portion of the system outlasted the IBM mainframe portion in a real production scenario. (When IBM patched their mainframe's TPC/IP stack, the Gemstone portion was reliably processing what it could, and then picked back up to full speed as usual.) I did not work on the end application, but designed and implemented the underlying mechanism.

Hardware these have run on include the aforementioned IBM 5100, IBM PC's, Macintosh, Lisp machines (Texas Instruments and Symbolics), various Unix systems (DEC, Sun, VAX, IBM, HP, perhaps others I've forgotten), the Tektronix 4406 Smalltalk workstation (which I am surprised there is not much on the web), Apollo workstations, Data General Eclipse, and something else which I probably can't mention to this day.

Have you ever shipped products that people have used or are you a washed up academic?

I have shipped many products and have never been an academic, although I may in fact be washed up. Fair questions.

Even More on Reliability and Static Types

I answer some recent comments on static type annotations and reliability...

"Great programmers produce great programs."

I agree this is the number one factor. But they're better off using better tools.

"Surely you mean static type annotations"

Yes. As for languages like Haskell and ML that infer types, I only have experience writing a few very small programs. I think this approach has potential, but would like to see evidence of large, evolving, dynamic systems built this way.

"It seemed smug in its assumptions, assumptions which I don't think are certain in any way."

Fair enough, I can be fairly smug. 8^)

I agree with you in terms of absolute certainty. All we have are stories, but I think they are worth telling if for no other reason than to root out contrary stories (which I have not see).

"This post seems much better"

Thanks for getting me to write it.

"Live updating is a powerful feature, one that is possible in python but easy in smalltalk, and a point to be argued in this debate."

I think the language and runtime have to (and should be designed to) deliberately support this. I'd rather see the Python community focus on this than on optional static typing.

"I don't yet understand erlang's concurrency, or whatever other language features it has that support reliability, but it's something I've been meaning to study in detail. I will try to read the thesis you referenced; the abstract is interesting."

That's great, if I can get others to try new ideas. The basic idea is that Erlang is designed to be a simple, concurrency-oriented language. You might want to begin with Joe Armstrong's invited talk at Lightweight Languages 2 (http://ll2.ai.mit.edu), the slides and the video (morning session).

"I admit that I played devil's advocate"

I appreciate that.

"Erlang systems are reliable because the language does not have static-type-checking; or because the language is a single-assignment functional language designed around process-isolation?"

Erlang systems are reliable for a variety of reasons. The original argument in this thread was that static type annotations are not necessary for reliability, and could very well be at a disadvantage compared to languages like Erlang, Smalltalk, Lisp, and Python that do not have statictype annotations. This is an argument against adding optional static type annotations to Python, a "feature" which is currently under investigation in the Python community.

"How about Smalltalk? I've seen superb Smalltalk systems and dreadful ones."

Yes, see the quote above about great programmers.

"How about Orbitz? Hmmm iirc a large part of their system is built around Jini..."

I'm sure Orbitz is a very large post-modern system with a variety of moving parts. I would note that Jini's coordination mechanism (JavaSpaces) is asynchronous and dynamically typed (content-based, pattern-matched, addressing). If I were to build a significant system in Java, I would put this consideration high on my list.

The basic coordination mechanism in Erlang also is asynchronous, dynamically typed, and based on pattern matching. I don't consider this a coincidence.

More on Reliability and Agile vs. Rigid Languages

The author of a previous quote comments...

It is logically flawed to say that because one lightweight language system has been running very reliably, that static typing doesn't help with reliability.

If you read through Joe Armstrong's thesis, he describes several large and small systems built using Erlang. More about the software itself and other conference reports are at the Erlang open source site.

If the Erlang examples are not enough, let's consider other languages.

How about Smalltalk? Read on James Robertson's blog how he's able to debug and update live servers. Read Jay Almarode's articles on Gemstone Smalltalk (index to PDF's), how it provides multiple users a distributed, persistent, versioned dynamic system that's kept applications running in finance, insurance, medical, manufacturing, etc. Read about JP Morgan's use of Smalltalk in their financial management system which won a 2004 Computerworld award.

Maybe you'd like to know about Lisp and how it's used by Orbitz for travel planning. There are many similar successes with Lisp.

The list goes on.

I want dynamic languages to succeed in this scenario too (I'm a python fan), but I don't see any evidence, other than partisan flag waving, which demonstrates the superiority of either methodology in creating reliable systems.

There is sufficient evidence that dynamic languages succeed in creating reliable systems. I have not seen a reasonably supported hypothesis for static languages in these situations. That is, I have seen claims that they will catch more errors, or catch them sooner, or reduce testing, but I have never seen substantial evidence in support of these claims.

If you have any such evidence, please let me know. My own experience includes building significant systems in several agile and rigid languages over twenty-four years. Based on that experience I would only choose a dynamic, agile language.

Do you have any actual evidence as to why dynamic languages are better for creating very reliable systems than are statically-typed languages, or just that one anecdote?

Read about the systems above. These languages are *agile* in that they support flexibility and evolution of dynamic systems. Static type checking tends to be *rigid* which, in the small without a test-driven approach, provides the illusion of security. As systems get larger, statically specified information become even less important and even more of a hindrance to change.

Our initial intuition is that reliable systems must be specified up front, and since static type information is easy to specify up front, then this must be the foundation of reliable systems. Almost the opposite is the case. We do need up front specifications, but they should be simple expressions of small parts of the ultimate system. Those specifications should be in the form of tests and dynamic (and concurrent) models, and simple solutions that fail fast.

Read about the systems above. The wisdom is not entirely intuitive relative to many of today's popular programming languages and tools. But the history of computing is inevitably moving in this direction.

A Simple One

Sam Gentile asks a simple question...

So some people are always bemoaning why no one pays attention to their technologies. Why is it that Microsoft can command such loyalty that when a new CTP of Whidbey comes out they'll drop everything and install it even on Xmas Eve (besides being a hapless geek)?

A picture paints a thousand words...

Happy New Year! Where do you want to go today?

Concurrency Oriented Programming

The Marquee de Sells writes...

We'll have to have much better language-level support for concurrent programming. What we have now sucks.

And concurrently, Tim Bray writes...

Almost by definition, the slow media-centric apps should be able to deploy parallelism to good effect. But this deployment work is not for the faint of heart, because thread-aware programming is, well, hard...

If we’re going to empower application programmers to get the most out of the high-TLP chips, we need big advances in development and debugging technology...

Once we figure out some design patterns, there are grounds for hope that we can do some tooling around it.

Agreed then. We need better languages and runtimes (example1, example2), better tools (example1, example2, example3), and better patterns (example1, example2, example3).

Generics in Java too!

Ted Leung writing on generics in Java. They're just as much a pain as in C#...

As I listened to the generics discussion, my mind was thinking something like this:

Generics extends the amount of static type checking that you can do.

Static typing checking is good because you make fewer mistakes.

But wait, now you have to worry about wildcards and type bounds.

It seems that for average programmers this could be more work than writing the code itself.

So now you can make a mistake in writing the specification (type) that is supposed to keep you from making a mistake.

Doesn't sound like a bargain to me.

"Partial Classes" for Smalltalk

Sometime in the (near?) future, dotnet (or just C#?) will have "partial classes", but from what I've seen, they're these rigidly textual file-based things. Essentially they allow "code generators" to generate some of the code for you.

The other thing to note is that there's no way in hell you'd be able to build this mechanism yourself. The language and it's tools are too complex, overdependent, and rigid. On the other hand...

Even 25 years ago, programmers have been able to add features such as multiple inheritance into Smalltalk by themselves. In the last couple of years, some programmers added a very expressive kind of "partial classes" called "traits" to Smalltalk, again by themselves. And they provided integrated tool support within the existing IDE.

Note that Microsoft Research is funding research for traits with C#. You can bet this is a pain in the ass. Give up and use Smalltalk!

I'm reminded of all this by James Robertson's item on traits being ported from Squeak to Cincom Smalltalk.

Nine Nines, so much for Intuition

In this specific example, that means 99.9999999 percent reliability, 1.7 million lines of an agile language ("dynamic types") handling 30-40 million calls per week with only 31 milliseconds of downtime per year. The figures are from Joe Armstrong's talk to the Lightweight Languages 2002 conference.

I am reminded of these figures due to a quote...

Mainly, I would want strong type checking in an application which had to run unattended, had to never crash, and had to always be right.

As it turns out, this may be one of the least desirable scenarios for strong typing! So much for intuition.

Later in the comments on that blog...

What we need is for ML, be it O'Caml, SML, or some other variant, to become ridiculously popular. In fact, any language with implicit typing would suffice. Implicit types are the way to go: all the supposed security of statically typed languages, without the feeling you're talking to an autistic child.

This may be. I am interested in these languages, and I've done some toy programming in Haskell and ML. But this claim for what "we need" smells suspiciously untested. I have yet to see evidence on the order of what has been achieved many times in production scenarios with dynamic languages. I remain a fascinated skeptic who would be eager to see real results being reported.

Chris Petrilli adds...

Static typing is simply a false meme promulgated by people who are stuck with it.

Rather than the dubious benefits of static type checking, I believe more effort should be put into dynamic, concurrent model checking. A good introduction using Java is available.

This is the future of "checking" things in programs. Another book I'd recommend is "Logic in Computer Science: Modelling and Reasoning About Systems". The deep reasoning capabilities we should be developing is about the dynamic, concurrent nature of systems.

[T]his material is rarely taught to computer scientists and electrical engineers who will need to use it as part of their jobs in the near future. Instead, engineers avoid using formal methods in situations where the methods would be of genuine benefit...

Logic in Computer Science by Huth and Ryan is an exceptional book. I was amazed when I looked through it for the first time. In addition to propositional and predicate logic, it has a particularly thorough treatment of temporal logic and model checking. In fact, the book is quite remarkable in how much of this material it is able to cover: linear and branching time temporal logic, explicit state model checking, fairness...

The book is a wonderful example of what a modern text on logic for computer science should be like. I recommend it to the reader with greatest enthusiasm...

Adding static types to Python should be the last thing on the list to do.

Quote of the Day

Charles Ferguson in the MIT Technology Review quotes...

“Bill Gates is desperate to prove that he can innovate,” commented a Microsoft executive who prefers to remain anonymous. “And it just might kill us.” He pointed to the ambitious goals and long delays that have plagued Longhorn, Microsoft’s future (and search-centric) version of Windows.

Bleak House

Dickens wrote Bleak House as a satire on England's complex legal system. Try reading through these bleak rules (BCLTeam's weblog via James Robertson) and wonder about the difference a production-worthy IronPython and other dynamic languages could make in this universe...

The name of a generic type must encode the number of type parameters declared on the type. The name of a nested generic type must encode the number of type parameters newly introduced to the type. Typically done by the compiler automatically, you may encounter these "mangled" names when using Reflection over generic types.

Nested types shall have at least as many generic parameters as the enclosing type. Generic parameters in a nested type correspond by position to the generic parameters in its enclosing type. Typically done by the compiler automatically, this essentially means that nested types "inherit" the type parameters from their enclosing type.

A generic type must declare sufficient constraints to guarantee that any constraints on the base type or interfaces would be satisfied by the generic type constraints. The C# & VB.NET language already requires re-declaration of type constraints in this manner.

Types used as constraints on generic parameters must themselves be CLS-compliant. The natural continuation of existing CLS rule 11.

The visibility and accessibility of members (including nested types) in an instantiated generic type shall be considered to be scoped to the specific instantiation rather than the generic type declaration as a whole. This rule ensures languages with different accessibility rules for generic instantiation can interoperate.

For each abstract or virtual generic method, there shall be a default concrete (non-abstract) implementation. If you provide an abstract or virtual generic method, provide a concrete implementation so languages which can't define new generic methods can consume your API.

Time to change back to white.

The style of this blog is supposed to change back now. (43 days.) Done.

Science Publishing and RSS

If TBL had jumped directly to RSS and HTTP for science publishing, could the mechanism have launched the World Wide Web the way HTML and HTTP have?

Would this approach have launched World Wide Anything, or would it still be used in isolation within some smaller community? Maybe the result would be even better. I guess we'll never know. Oh well, back to whatever you were doing before this thought.

Programming Language and Trust

Ian Bicking writes about trust...

In general, Python requires you trust your programmers. People give Java grief about its restricted environment and static typing, but if you don't trust the programmer to do a good job, at least with Java they (maybe) can't mess things up as badly for everyone else working on a project. You can mess things up royally with Python...

Python is not the language for companies who expect mediocrity in their programmers, and I think that outsourcing is for companies that expect mediocrity.

Having programmed serious systems (each with multiple developers) in several languages (at least six), I can say without a doubt that you can mess things up royally in *any* of these languages, whether the languages are rigid or agile.

Ian comes around to this by the end of the piece...

...shitty code is always shitty (even in Java)

OOPSLA => PSLA

"Pee Slaw"? Is that the new name for OOPSLA ("Oops Lah")?

I like the concept, though.

Our vision is for OOPSLA to become a conference that we affectionately call “PSLA”: Programming, Systems, Languages, and Applications. OO(PSLA) will be one of the themes of the conference, which would welcome everything about programming qua programming. But we cannot move there right away nor in large steps. So we start slowly and see how it goes.

Two Remarkable JVM Dynamic Languages

Sean McGrath points to a poll on JVM dynamic languages.

Two problems. No JScheme and no SISC! These are remarkable gaps for a several reasons.

JScheme has an innovative and exceedingly easy to use integration with the Java language (Javadot notation). The dialect is not full Scheme, but represents a sufficient choice of useful features. Other innovations include support for easy web applications and easy GUI applications.

SISC is remarkable at almost the other end of the spectrum, a complete and efficient implementation of Scheme. This is a *better* than most textbook case of how to implement an interpreter (via an intermediate form, not byte code). You'd probably have to stick with one essential textbook to receive this level of education.

If you are unfamiliar with the rich differences between Java, the JVM, and full Scheme, then appreciating the feat of this implementation. SISC also includes generic methods and an object system.

Google Raising the Web UI Ante

Charles Miller tells how Google is raising the ante on web user interfaces...

if you develop web applications and you aren’t looking today for ways to include dynamic interface techniques like those made practical by XmlHttpRequest, you’re going to end up losing to someone who is.

The good news is creativity will be unleashed. The bad news is we'll get to experience some wrong paths. Such is life.

Communication Makes It Happen

Ian Bicking in a comment on James Robertson's blog...

Alan Kay is doing a bad job getting his ideas out. Which is weird, since it's not that he isn't trying. There's a lot of writing about Kay on the web, but very little by him. From what I can tell, he doesn't even have a web page; "Alan Kay" on Google produces 10 biographies. These days primary sources are the norm. I think his ideas are being overlooked as a result.

Daily Zen

My only shame,
It’s autumn,
And I have no poem.

- Szu K’ung-t’u (837-908)

Google and Web User Interfaces

Like Joel Spolsky, when I tried Google Suggest for the first time, I immediately set it to be my home page. Was Google, now Google Suggest.

Google is very publicly raising the bar on the quality of interfaces that people will expect from web pages.

Some insight into what it's doing.

Integration

Sean McGrath, dynamic language advocate and Jython provocateur (!?), writes...

Psssssst: every time you use a JAR/CLASS you don't control, you have yourself an integration problem :-)

Heed the call. Consider a recent topic in this blog...

I asked the question about the dotnet CLR (or CLS or something), why would you want one way to integrate outside the VM and another way to integrate inside the VM?

The counter example to this dichotomous approach is Erlang/OTP which is a scalable, robust, productized demonstration that a simple integration mechanism is suitable to both integration scenarios.

Let's complete this post by repeating Sean's message...

Every time you use a JAR/Assembly/Class/Object/API you don't control, you have an integration problem!

And even when you do control them, if they are heavily used, you have essentially the same integration problem, which is the reluctance, cost, time, perhaps inability, to change them with agility.

You Aren't Gonna Need It

A fun, insightful explanation from Tim Bray on a really big problem you're not going to need to solve...

You... don’t want to have to temporarily store millions of values while you do the sort.

Here’s the trick: nobody will ever look at more than the first hundred or so results. So you don’t have to sort at all, you just have to find the highest relevance values. Here’s the algorithm...

Interesting Speculation

I wrote a few days ago that the sale of IBM's PC organization might benefit the industry by shaking things up, and motivating overdue innovation.

Robert X. Cringely takes this into a very interesting scenario that if true, certainly would force a good bit of out-of-the-box thinking!

Thoroughly Modern Millie

Anonymous writes in yet another comment...

what exactly is the benefit of being able to run a variety of dynamic languages on either of those platforms? It seems to me that moving forward the most meaningful common runtime environment, for any application written in any programming language, is the network and its associated protocols (TCP/IP, HTTP, etc.)

I agree. Then what *is* the benefit of dynamic languages on these platforms?

Personally, if I am asked to use the CLR or the JVM, I want to be able to use a dynamic language. I've used Jython, JScheme, and SISC a good bit.

Generally, remember when most programmers eschewed garbage collection? Those of us using dynamic languages then had a more difficult time integrating with "non-managed" (how droll) run-time than we do now intgrating with the JVM and the CLR. (So welcome thus far!)

When these systems go completely dynamic, integration becomes that much easier. In fact end-of-life'ing the JVM and the CLR become real possibilities. So my ultimate motivation for promoting this migration is to rid the world once and for all of the JVM and the CLR, those regressive monstrosities that they are!

Cooperation Makes It Happen

Edd Dumbill on dynamic languages...

The ongoing silence from IronPython quarters does not encourage me at all.

It's time that the free software and academic worlds stopped waiting for Microsoft... Novell needs to take Mono to the academics and get them working with it.

I'd prefer that academics work on advanced systems rather than re-engineering the industry's past mistakes. OK, just give them a grad student or two.

Smalltalk Success in Business

James Robertson reports on this interesting success story...

The insurance system - the rate of change drove them to build a meta-data system. It grew to handle hundreds of insurance products. Once it wa sin place, it was easy to add new ones. It was handled by a team of about 10 developers. After a merger, they were faced with another team that had 700 hand coded forms that dealt with only 9 insurance products. In theory, the merger was in part to acquire the leading edge advantage of the Smalltalk insurance products. Politically, the larger team won and forced a re-write in C# (a political compromise).

What they discovered was that Smalltalk's pure object model makes it far easier to deal with meta-models. C# and Java stand in the way. It's very hard to come up with patterns that would map the existing design onto C#. C# and Java are physically designed against meta approaches. The upshot - if you need to deliver a meta-model driven system, then expect to fail in C# or Java...

You can argue about how easy it is to integrate with some specific reporting package or XML parser. But Smalltalk can access all kinds of reporting packages and XML parsers, and has a few of its own.

The real question is how well the language supports your business *ideas*.

With the [Smalltalk] system, changes were delivered immediately - the replacement C# system delivered them much more slowly - and it also required a larger team. The Smalltalk system was also faster.

D'oh.

Read about other business successes with Smalltalk at Jim's site.

Something Different

Ian Bicking in a comment captures the problem better than I have...

The CLR is trying to do something difficult. It's not just the kernel upon which languages can be built, but an infrastructure so that languages can be intimately combined. I suspect that there are some combinations that are poorly thought out. For instance, I don't think cross-language inheritance is useful or productive -- better to provide good alternatives (e.g., delegation); language implementations can pretend those alternatives are subclassing if they really desire to.

But cross-language data sharing, including the sharing of objects, is quite important. You can't do that without some significant spec. Now, it might be a better, more evolutionary approach to put different languages on the same VM, and let them figure out the interoperability issues later. But even though that's a different process, it just delays the work, it doesn't remove it.

Data sharing is important. But why this way with the VM and another way outside the VM? The essence of running a common runtime was interesting about 15 years ago. See the late Mark Weiser's work at Xerox on the Portable Common Runtime. This approach addressed the *critical* issues of sharing a common runtime. There may be one or two other critical issues, but they don't require a common object model. The CLS object model in practice turns out to have some uncommon and subtle anomalies; it's a hard problem for questionable results.

A third approach to language interoperability is to standardize on a common intermediate form. This is a variation on the privileged language approach, permitting different languages to interoperate as long as they use a common back-end. In spite of several attempts in this direction, the restrictions on language designers and implementors have proven too severe for wide adoption. We hope our more modest approach (agreement on important parts of the runtime environment), by analogy with the success of common operating systems, will prove better in practice...

PCR itself is about 20,000 lines of C and about 200 lines of assembler.

A good bit simpler than the CLR. Someone didn't get the memo.

The problem with the complexity in dotnet's CLR is that it's not addressing the *right* problem. Compare this to Erlang, Indigo, REST, and other simplifying approaches to "postmodern" programming. Agile software demands we keep our options open and avoid premature commitment to unnecessary complexities.

To repeat a quote from Dan Ingalls, below, "You clearly want the kernel to be as small as possible, so that you encounter barriers to change as infrequently as possible."

I agree with everything Ian writes here... and at the same time I don't feel Microsoft should get kudos for tackling the problem itself. They made the wrong choice to address the problem by overcommitting the kernel of the solution to ideas that just don't pay off in practice.

Simplicity, stratified design, regularity, small pieces loosely joined.

Really Good Ideas

Ward Cunningham...

There are a lot of ideas, but really good ideas are hard to snatch because they look so humble when you first see them. You expect the solution to be beautifully complex and a good solution is pretty plain until you see how that plainness plays in a complicated way to make something better than you could get in your head all at once.

Java, JVM, and Dynamic Languages

Tin Bray reports on a dynamic languages summit at Sun...

It’s pretty clear that dynamic languages are a hot area, maybe the hottest, in the world of software development. We need to do more to make them easily usable by people in the Java ecosystem...

I confidently predict that as time goes by, more and more of the code written in the Java ecosystem won’t be in Java. This is a good thing.

Looks good, based on the people who've managed to implement good dynamic languages on the JVM, and who've used them. The missing ingredient I'm wondering about is, did they try to invite some really experienced implementors of *high-performance* dynamic languages? Sun did have Gilad Bracha there with Anamorphic/Strongtalk experience.

Baggage

Anonymous (you again?) writes in a comment...

Not sure what you mean by the "baggage in all the specific object model stuff".

Consider the Common Language Specification. There is a lot of unnecessary stuff there. The design is begging to be more stratified. (See "Lisp: a Language for Stratified Design (ps))

Reading from "Smalltak-80: Bits of History, Words of Advice" (1983, pdf), Dan Ingalls writes...

You clearly want the kernel to be as small as possible, so that you encounter barriers to change as infrequently as possible.

Given todays computational power relative to 20 years ago, reducing barriers to change is a nearly universal overriding quality we want in software systems. Certainly that is why dotnet itself has replaced C++ as Microsoft's vehicle for software development. Before that, a popular Microsoft combination was to use VB for most of the flexibility and C++ for the "services" available to VB to munge about.

The gravitational pull of this progression is centered in Lisp and Smalltalk. Undeniably the progression of the popular languages is essentially toward these spheres of influence. Along the way, ML and Haskell and other systems of course. (But even ML and Haskell come out of the *Lisp* and functional programming community.)

If you are looking for true enlightenment, read Richard Kelsey's "Realistic Compilation by Program Transformation" (1989). And if you get hooked and need a deeper fix, read the original lambda papers by Guy Steele.

Yes, the CLR has some baggage.

Ours Go to Eleven

Considered Opinion writes in a comment...

Perl > Python > Lisp > Smalltalk - and none are well suited to typical business applications (good at all of: Security, GUI, RDBMS, Reporting, Distributed Computing, Reasonable Performance...)

Ignorance is bliss.

On a much lesser note -- all have much smaller populations than MS or Java.

At least you got that going for you. Ours go to eleven.

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.