Recovery

Really just one hope comes to mind at the top of my list for 2005. That's a recovery to some new definition of peace and normalcy for the people affected by the tsunamis.

There are two local (to me) really great agencies involved in the recovery. They are Northwest Medical Teams and Mercy Corps, both here in Portland.

There are many agencies ready to take donations and hard at work on the recovery. If you're unsure of which agencies would be effective, these two have a long reputation of doing good work efficiently.

Beyond that effort, the rest of my list would be filled with hopes for more freedom, kindness, understanding, and generosity. Less war. Less terrorism. Less fear.

More health.

How's the Blogosphere?

A creative lyrical satire on blogging. I was concerned about the dialog portion going off on blogging in general as "saying nothing". I find "traditional" channels saying nothing lately. I'd rather page through a large number of individual(istic) blogs to keep up with my interests than a limited number of sanctioned channels.

David writes in the comments to this post...

It's not so much that I think blogging in general says nothing -- I read lots of blogs and gain a lot from them. The "random nothingness" stuff is a takeoff on the large number of blogs I've come across (mostly in the Java developer space) that have... disingenuously self-deprecating descriptions for people who certainly do have something to say...

So go for it, bloggers.

A (More?) Positive Outlook?

I consider myself kind of a critic. I think we need a lot more criticism in the industry as well as in society as a whole. I try to be constructive even though I miss that mark and have no editor to question me before I hit "Publish Post".

Given the New Year around the bend (as I write this, I'm about 11 hours away from 2005), I am going to post something positive about the mainstream of the industry. Shock!

Here's to a 2005 where we can learn more about Microsoft's Bigtop...

Bigtop consists of three components, all written in C#, according developers who said they were briefed by Microsoft. These are:

Highwire

Highwire is a technology designed to automate the development of highly parallel applications that distribute work over distributed resources, the aforementioned sources said. Highwire is a programming language/model that will aim to make the testing and compiling of such parallel programs much simpler and more reliable.

Bigparts

Bigparts is code designed to turn inexpensive PC devices into special-purpose servers, according to the sources. Bigparts will enable real-time, device-specific software to be moved off a PC, and instead be managed centrally via some Web-services-like model.

Bigwin

According to sources close to Microsoft, Bigwin sounds like the ultimate manifestation of Microsoft's "software as a service" mantra. In a Bigwin world, applications are just collections of OS services that adhere to certain "behavioral contracts." These OS services can be provided directly by the core OS or even obtained from libraries outside of the core OS.

These are terrific goals. Market forces can detract from goals like this. Perhaps better markets can emerge from staying on track; the benefits could be huge.

More Agility in 2005?

Why didn't they teach us in math that integers can "overflow"...

The most serious of the three vulnerabilities involves the Windows LoadImage API Function.

That bug was described as an integer overflow that could be exploited via browsers or e-mail client software. Users who open an HTML message or Web page bearing the image could face security risks.

Here's to a New Year where more programmers use agile languages where integers behave more like you learned in math class.

*Experience* Music Project

This week I went to the Experience Music Project for the first time. Our family joined for the year because (1) it was about the same cost as general admission considering the Bob Dylan T-Shirt they throw in with the membership; and (2) we are in Seattle a lot and (try to, some of us) play various instruments.

One thing I should not is that I am not a fan of the exterior of the building (or of Frank Gehry's architecture generally), but the interior of the building seems to work pretty well for moving a lot of people through a lot of content in a small amount of square footage. Some of the doorways and passages were inexplicably narrow.

The content is what really matters. I'd like to see a wider emphasis than rock and roll, but if you look around a bit you'll find broader content. I'd like to get back up there for Jazz in January.

The best thing about the "museum" is the experiential opportunities. The sound lab is a great place to learn how to make music on various instruments or just to play around. A number of sound-proof booths and rooms have keyboards, guitars, drums, sound equipment, etc. with guided software for absolute beginners or just for free form fun.

Dang if I wasn't embarrassed as a software developer though. In the few hours I was in the sound lab my family and I experienced a handful of frozen computers and handheld devices. More than once "rebooting the computer" was the recovery method.

These are embedded systems and when they break down they spoil the experience even more than a typicalhome computer problem. There's no reason I can see these systems could not fail fast and recover quickly without falling back to the main screen most of the time.

We need to make great new strides in this as programmers beginning in 2005.

Languages and Data Integration

Years of endless debates about static type annotations regurgitating the same information over again have led me to shy awayfrom them in recent years. I've done pretty well, yet here I am in the gravity field of another one. I'm not sure how long this will last but for this day, I am somewhat interested in continuing.

PJE writes in a comment...

Um, just because a given use case can be accomplished without a given tool, doesn't mean the tool is useless, or isn't useful for that use case. If that were true, we'd never use anything but machine code.

I have not found any useful scenarios where I want static type annotations. There's not much more to say than that. I'd like to hear of scenarios others have found useful so I can compare them to my own.

Meanwhile, I notice you haven't responded to the point that solid integration with statically typed languages often requires type annotation; e.g. jythonc's use of special patterns in docstrings. Integration with other languages, documentation, and runtime introspection/adaptation are my use cases for type annotation.

I'm not sure what you mean by "solid" integration. I have done production-quality integration between "agile" languages like Lisp, Smalltalk, and Python with "rigid" languages like Pascal, C, C++.

There are situations where the more rigid languages have required, say, a 32-bit integer or a specifically formatted sequence of values (i.e. "struct" or "record"). "Agile" languages tend to provide integers that are not limited by the word size of the underlying hardware. In scenarios like this then, on the agile side of the integration a check is necessary that the integer will fit in the rigid size of 32-bits and so on. Likewise a conversion is necessary to actually format the scalar data and structured data into the kind expected on the rigid side.

I would not call these expressions "static type annotations" in the agile language though. Rather they are hoops I'd not have to jump through as much if the rigid language were more agile. The language systems I have used that I can recall have tended to allow me a way to express these in the agile language itself rather than in a comment or doc string, but that's a minor point.

Languages like Java and C# are less rigid and given their capabilities for reflection, integration with more agile languages tend to be more automatic. And so Jython and Python.Net among others tend to do most of the conversion automatically without special annotations or coding.

Corner cases require more programmer attention but that's also a minor point. They could agree on a common model for data exchange such as is done in CORBA and it's descendent WS-xxx. Doing integration via CORBA using Smalltalk is so easy I believe had more programmers been working this way the WS-xxx fiasco would never have been. Rather improvements to CORBA's relationship with HTTP would have been getting all the intention. These are market force issues, not software.

Another source of feedback on this is the Inter-Language Unification work done at Xerox. Related to CORBA but more focused on integration aspects and RPC, where CORBA was beginning to branch out into a variety of distributed programming models.

I don't see how type inference helps with either documentation or introspection, either. If it's pure "duck typing", how is the system going to infer that I want an IAtomicStream, say, versus an IRawStream, if the two have the same methods? Duck typing isn't sufficient to distinguish different *semantics* of a type/interface, only its method signature -- and that is not sufficient for documentation!

If you need an IAtomicStream on the rigid side then there is probably enough information to infer that from the code on the agile side. If the rigid specification is ambiguous (well, then it's not really a "specification" is it?)... then, yes, you need to have some kind of an expression on the agile side to disambiguate.

The point is, this is a burden rather than a feature. Why would I *want* to work at this level of detail?

A good bit of information on the power of inference for agile languages can be found in the implementation of the Stalin Scheme compiler, see "Flow-Directed Lightweight Closure Conversion" by Jeffrey Mark Siskind.

Documentation needs to present the semantics of the interface, so that if you are implementing that interface yourself, you know what semantics to implement.

The documentation I want to see is (1) executable examples or (2) technical memos that augment executable examples. Period.

Likewise, for introspection, I don't see how an implicit signature helps. Let's say I want to create an XML schema for a document format that can contain messages that get converted to method calls on some object. If each of those methods uses a different set of methods on their arguments, I'm going to end up defining new types for each method, which might be okay for the computer to process, but for a human being it's going to be a mess to understand.

I am not sure what this example is about. I agree there are integration scenarios where something like an XML Scheme is required to specify the kinds of messages that can be exchanged between language-independent processes. That does not in any way imply that static type annotations are a benefit to the languages I use to implement the independent processes.

Type inference, IMO, is just type checking. It doesn't seem to me to be useful for anything else -- and like you, I'm not interested in type checking! (I suppose it could be used for optimization in some cases, but only if you can statically prove a concrete type - not just an operation signature.)

Type inference is better than type annotation. The real benefit I see is in getting even more capable agile modeling and inferencing tools by extrapolating from recent work in model checking. Simple, even compound, type checks are uninteresting. We do need a lot of help with concurrent state machines however. Tools that can tell me more about *real* behavior problems rather than simple type checks should be getting all this attention.

Now, perhaps I could be wrong, and there is some other way to accomplish these use cases that's just as clean. If so, I'd sure like to see them. I personally don't see that any of my uses for type annotation *can* be satisfied by inference; there's just not enough information. Heck, I don't see how a *human* could do the inference in the absence of added documentation, let alone a computer. It would be little more than blind guessing.

I think I see one use case here... how to integrate languages that have different data models. I agree system integration requires some kind of agreement on specifying data integration. I'm not sure what else I am seeing here.

OK. I am getting tired of writing about type checking. I think we're in agreement on this use case of language-independent data integration.

Prediction of Hope

Don Box has some predictions for 2005. I like reading people's ideas, but I only have hopes, not predicitions. One of Don's predictions leads to a hope of mine...

The term SOA will have been beaten to death and the software industry will invent or recycle some equally vague term to replace it. The term has zero differentiation value at this point and marketing teams across the globe are looking to coin a replacement that will give them something more interesting to say about their middleware than "we move messages around really well." If "Business Agents" become the buzzword de l'année, I expect Mary Jo Foley to hunt me down and kill me.

Perhaps more end users in 2005 will demand that their programmers find better ways to move messages around really well and dispense with the buzz words.

Another interesting set of predictions from Carlos Perez' Managability blog. Especially those on Rich Internet Applications, Grid Architecture and REST, and Scripting Languages.

Dynamic Types and Naked Objects

PJE writes in a comment...

There *are* other uses for type declarations besides type checking. For example, the Naked Objects framework in Java uses method signatures to figure out what actions might apply when one object is dragged-and-dropped onto another object in a GUI.

Jayson Vantuyl responds in another comment...

In response to the above comment, I would point out that there are other (better) ways to do what the Naked Objects Framework (NOF) is doing in Python.

I wrote and demonstrated a Naked Objects framework in Jython at the 2003 XML DevCon. One reviewer...

14:46 - Patrick Logan - "Point & Click XML Applications" - an interesting discussion and demonstration (using Jython) of point and click application development... to me one of the most interesting points was that at the end of his presentation he pointed out that most of these concepts are extensions of things started 15+ years ago such as Lotus Notes, Agenda, Naked Objects, Tuple Spaces, etc.

I didn't allocate as much time as I'd hoped, and I wasn't so happy with the result. Nevertheless, the system did not require type annotations in the Python. Rather the end user is able to define their own data types in the GUI itself (including "Any").

If I were to continue with that work, I'd consider making these "end user annoations" optional and provide inference as well as modifying the inferred type dynamically as users create more objects. (With some kind of confirmation of the user's intentions.) But I would not think language extensions to Python would be worthwhile.

Back to PJE...

Documentation, of course, is an even more immediately useful use case. A good syntax would be more precise and more brief than docstring explanations.

I think there are more useful kinds of documentation to write other than type annotations. I'd like the system to infer types and tell me what it determines the current types might be for some method. Moreover, I'd like the inferencing mechanism to consider the test code and data as well as the application code.

Given those inferences I could correct my code, add new tests or test data, or have the system keep the inferences around as automatically generated documentation if so desired.

The documentation I write myself would be more useful in the form of technical memos (see the complete Episodes pattern language).

Is there a danger of over-declaration by newbies? Sure. I'd probably find it really annoying to use code with excessive declarations, if those declarations actually restricted anything. However, if they were *just annotations* (or were adaptation specifiers per PEP 246), then I could still pass their code any darn thing I pleased, and we could all continue to be happy.

Yikes! What would be worse, type annotations that *are* enforced or type annotations that are *not* enforced?

Smalltalk Keeps Going

Here's how Michael Lucas-Smith keeps his Smalltalk servers humming with new capabilities.

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!