Scaling to Thousands of CPUs

From Shahin Khan in the Register...

A major shift is coming. Over the next few years, your ordinary applications will be able to tap into systems with, say, 7,000 CPUs, 50 tera bytes of memory, and 20 peta bytes of storage. In 2005, Azul Systems will ship compute pools with as many as 1,200 CPUs per a single standard rack...

What would change about application design if you could do this? Well, think back to what applications were like when you had just 128K of memory in your PC and a 512KB hard drive. The difference between the capabilities and flexibility of applications in those days and now is the level of improvement that we are talking about.

It may take more than a few years to get to these numbers for most of us, but I think at that point the change will be even more dramatic. Unless once again the software industry (you know, the "agile" industry) once again is too slow to keep up with hardware innovation.

One reason why I'm getting back into Erlang after tinkering with it several years ago. I want to understand how to think in terms of processes being about as cheap to create as objects are in other languages. One neat thing about Erlang is the sequential aspects of the language are so spartan, the programmer is forced to think about processes.

A single Erlang node on a single CPU today can comfortably get into the tens of thousands of dynamic processes. What would your system look like running hundreds of thousands or a million dynamic processes and lot of activity is spent collaborating with other systems also running at that scale?

See "Apache vs. Yaws" (Yaws is an Erlang-based web server)...

Yaws is still functioning at over 80,000 parallel connections.

The Java community is discussing a new protected-private keyword. This reminds me of the saying about rearranging Titanic's deck chairs.

Message to Tim Bray

Larry Maccherone writes in a comment...

I wanted to post this to Tim Bray but his blog didn't allow posts. I've worked with a group here at Carnegie Mellon called the Fluid project. They have developed the ability to statically assure that your concurrency model matches your code. The tools also make it trivial for you to indicate your concurrency model by guiding you in adding minimal annotations in the code (think javadoc).

The fluid web site.

The publications (including Aaron Greenhouse's PhD thesis).

I post it here as a guide to how this might be done in dynamic languages but also to help Tim out with his java concurrency issues. Could someone see that it gets to Tim?
LMaccherone ..at.. cmu ..dot.. edu

Testing Interfaces

Ian raises some concerns about testing interfaces in Python...

Unit tests aren't going to test across the boundaries where people are proposing interfaces -- between loosely coupled components.

I am not sure I understand this point. Say I give you version 1 of a component and the tests deemed "sufficient" for that component. Then I give you version 2 of the component and the tests. If you are able to run version 1 of the tests against version 2 of the component, that should be a reasonable indicator that your own use of version 1 will be compatible with version 2 of the component.

As the provider of the component, I need to know nothing about your own use of that component, for reasonable definitions of "sufficient tests".

Note also that interfaces are more explicit about contracts between components than tests will be. For instance, an interface might demand a method which is not yet being used in your code or your usage; the interface makes it explicit that this method should still be defined, and so predicts future developments, not just current developments (half-implemented dictionary interfaces are a common example in Python, where interfaces would motivate people to finish the work).

The original scenario was an upgrade to a component breaking backward compatibility. If an upgrade provides a new feature then your old code has not used that feature yet. I would not expect that to break backward compatibility.

If an upgrade requires an old feature to require a new method of its old consumers, then that *would* break backward compatibility. However I would expect a reasonable set of tests from the component provider to demonstrate this failure on their part to keep their old customers happy.

Or two interfaces can match methods and signatures, but include extra information about the semantic differences between those interfaces; because it doesn't use duck typing, you won't accidentally mix semantics (you have to explicitly say which, if any, of those interfaces you support). This is particularly a problem with interfaces that define only a small number of methods, or use common methods like __call__. The only way to test these is with system tests, and system tests are always incomplete, there's always some code path or combination you haven't tested.

I guess I would need a specific example that cannot be tested by a unit test. Certainly there are "big" tests that require a lot of "units" to execute. But if each of those units were developed and updated by a series of "unit" tests then I would expect those tests to represent the "differences between those interfaces" as they exist within each unit.

I am having trouble addressing this issue in the abstract. If it is a frequent problem, I would look for ways to avoid it or break it into smaller problems. Maybe this is a scenario where changing the language would solve the problem. I just don't know, but I suspect there are simpler ways to solve the problem on the basis that I have used Python and several languages like Python and I have not run into this scenario. That doesn't mean it isn't real, just that I have not recognized it.

More Ways to Give and Help Children

In addition to my two favorites, Anders Jacobsen is asking bloggers to include these organizations on our blogs. For each of us that does, he'll donate to the British Red Cross. Thanks Anders! I think UNICEF is a good organization to have at the top, reading about their concern for child safety given the number of orphans resulting from the disaster. Pray to change the hearts and minds of people who would take advantage of children like this.

International aid organizations: UNICEF (United Nations Children's Fund) United Nations' World Food Programme Medecins Sans Frontieres / Doctors without Borders (donate!) CARE International The International Federation of Red Cross and Red Crescent Societies UK/Europe: Disasters Emergency Comittee (DEC) - comprises a raft of aid agencies, including the below and others British Red Cross Oxfam Save the Children UK North America: American Red Cross Canadian Red Cross Save The Children Oxfam America Anders Jacobsen: Webloggers: Give to tsunami victims and I'll give too!

Crying Out Loud

All of a sudden blogs are not about an ongoing discussion?

Gordon and Ian both write about the reaction to Guido's posting very preliminary thoughts on what would be a controversial change to the Python language.

The question they raise is this: does the reaction imply that Guido has to be somehow more "careful" with what he chooses to write?

This question puzzles me. I am assuming Guido published his thoughts in order to *get* a reaction. Should the kind of reaction he gets be considered a problem?

Dictators had better have thick skin. Let's assume he can handle it and continue to speculate. That's what blogs are for, right?

You publish your thoughts, I'll publish mine. The result will be a web of thoughts, and presumably this will be better for the whole community as compared to being afraid and secretive.

People don't "need to chill". People need to *write*!

I Must Be a Type Magnet

OK, I'm not resisting responding to some comments on the interface type declaration issue.

Interfaces are something that two of the major "framework" systems in Python (Zope and Twisted) have both found missing and wandered off in search of their own solution. If such a system existing and was codified into Python it would make it a lot easier for myself and others to actually rely upon bits of code crafted by other people; specifically feeling warm and fuzzy about you not going around and changing something deep in the guts of your modules that I am not going to find out about until five weeks after updating to the most recent release.

I have found that framework upgrades work best when there are sufficient tests available with the framework and sufficient tests for the system using the framework. These tests reduce the magnitude of lots of problems, especially the scenario described here.

Are you saying that even with sufficient tests, from the supplier and in your own code, you are still getting surprised a month into an upgrade?

If not, which do you think would be the lowest risk experiment for addressing the problem: writing more tests for the framework and your code, or changing the language?

(Note: I am *not* asking if you think type declarations would in some way address this problem. I *am* asking which of these two alternatives would be the lowest risk experiment.)

Freeze!

A big problem with Guido's considering type declarations for Python is that there are now at least three significant implementations of Python. Disregarding how you or I feel about this specific proposal, any big change in the language will put further distance between the implementations or impose a heavy fine on those implementations that are trying to keep pace.

Given the momentum in favor of Python over the last year, if I were the BDFL of Python, I would freeze the language at the 2.4 specification for a few years. This would allow the other implementations to catch up, and allow the CPython implementation to focus under the hood on implementation improvements.

I'd have to see real evidence of pain and suffering to want to extend the language significantly. Let other languages try new ideas, but Python should probably stay close to the current definition which has brought it to the threshold of something big.

Of course Guido's current thoughts just exist on his blog as far as I know. Real changes to the language based on these are a long way off. They could have an ill effect on the current momentum just the same. At the least they could suck energy away from more immediate concerns.

Comments are enabled for the concept of a moratorium. No type checking debates here please.

The Road to Ruin

The dictator is leading us astray and we're on the road to ruin. Sad just when things were looking up.

I thought I wasn't going to write about this anymore, but I can't believe my eyes. Just as Python is getting to the table with the superpowers.

I don't want to comment on this. Sorry, comments are disabled no matter how much fun more type checking debates might be!

Gartner Buys Meta

From The Register...

"This transaction is an exciting opportunity that will give us increased depth in key sectors, geographies and markets, and an increased ability to seize revenue opportunities with the addition of META Group's well-trained, successful sales force," said Gartner's CEO Gene Hall. "In sum, the acquisition will make Gartner a stronger company with increased opportunities for growth and greater resources to offer clients."

I was impressed with Meta's presence and insight at a conference they held a few years back, and with some recent content. My experience with Gartner has been spotty, but lately I've been finding some interesting white papers in their library.

James Robertson has more perspective on Gartner than I do.

Pimp My IT Ride

Chad Dickerson writes...

Smart IT shops should limit unneeded complexity at every turn, choose their customizations carefully, and turn a deaf ear to the siren song of the perfectly customized solution...

In the heat of the moment, no one thinks about what these one-of-a-kind customizations are going to mean down the road.

Do you think "service oriented architecture" is going to solve this problem? Can solving this problem be profitable?

Process Models

Bill de hOra writes...

There's no question that too much business logic is locked up in middleware and systems programming languages. But we need to avoid the industry standard hype cycle on these technologies and be clear on what they can and cannot do...

Process modeling has to balance agility and formality. We cannot allow to happen to process modeling what has happened to data modeling. And then we have to take back data modeling and fix *that* too. Related note.

Out of the Bottle and Into the Box

Daniel H. Steinberg writes...

Let's ship Jini, JXTA, and the Java APIs for Rendezvous along with the JVM. What if easy dynamic distributed networking was available from and to every Java enabled device.

He expands on this in a larger column.

3MLOC

Via Chris Double...

The runtime source code is 3 million lines of Java and C++. That's way too much for what it does...

This includes a mix of awk, sed, shell scripts, and indeed, Scheme! Yes, the JVM source includes jscheme.jar, used to generate some CORBA classes.

Games

I played a few traditional games with family and friends New Year's Eve and yesterday at a friend's New Year's Day open house.

• Rummy Royal -- We played for a couple of hours on New Year's Eve. It's been a long time since I've played this. The great thing about it is the variety of each round; you start with a chance to choose or bid on an alternate unseen hand. You can bet on an ace showing up in your hand. Then you play a poker hand by choosing five of your cards. Finally you play all your cards in a Rummy-like game. I pretty much broke even for the night.
• Scrabble -- This was about the worst game of Scrabble I ever played. At one point I had all consonants. I foolishly traded *all* of them in, and came up with all *vowels*. At this point I had three of the four 'u' tiles and two of the four 'i' tiles. Why didn't I keep some of the consonants? The biggest problem was the play went from the middle of the board down into the lower corners and none of is had a way to build upward.
• Sequence -- I had never played this game before even though my wife says we have it somewhere! This is a good game for adults and kids to play together. The rules are simple, the pace is moderate, and there's a good bit of chance, but opportunity for strategy to win out.

Some friends were telling me about "Speed Scrabble" but we didn't play. Next time; it sounds fun.

One Startling Sentence

PJE writes in a comment...

He's not saying adding enough negative numbers makes a positive -- although your phrasing sure made me click on the link out of mathematical curiosity!

Which is of course why I wrote that, and is drawn from the idea of One Startling Sentence.

But I chose two startling sentences. (One is the title itself.) I thought of a third, but thought then that was too much.

Take Back Your Data

Again Andrew Newman...

There is a common theme in the IT history towards more freedom. I don't mean free like in free speech, I mean free like in free will.

Lock Free Programming

Andrew Newman points to an article on atomic variables in Doug Lea's concurrent package for Java. Is the attention on concurrent programming going exponential?

More Than Two Wrongs Might Make a Right?

Oliver Steele seems to conclude that adding enough negative numbers may have a positive result. I'm not sure I get all the way to the same conclusion, but the argument is unique.

Update: OK, I definitely do not get to the same conclusion. Saying a type declaration "does a poor job of each scenario, and that means it does a good job of doing them all at once" is a leap I cannot make.

I don't see Oliver addressing the cost side of the equation sufficiently for his benefit side to come out greater. I think the costs can be overcome with creative work, but I'm not sure that's where I'd want my most creative thinkers working. Making type declarations optional alleviates costs, but why bother? I am just one who does not see the benefits.

Since Oliver already points out weaknesses in any one of the scenarios, there is no point attacking them individually. I cannot argue against the whole because I don't see a complete equation that can be analyzed. But I will point out some glaring problems he's passed over.

• Documentation Providing f(a: String, b: Integer): Boolean rather than just f(a, b) is a weak argument. What are f, a, and b? Those names, well chosen, will tell me more than String, Integer, or Boolean. Moreover using Smalltalk's keyword syntax you have even more expressiveness than this Pascal style.
• Early error detection Test-driven development eliminates the gap between coding and testing. There is no "earlier" time for detecting type errors.
• Discouraged from writing tests If your language is so bad that programmers are discouraged from writing tests, my friend, well, type declarations are not going to make up the difference.

This is the last post I will make on type declarations for the foreseeable future. Feel free to comment, but don't expect a response.

I have another post to make responding to PJE, which I have learned is *not* about type declarations per se. Coming soon.

Coming out of the woodwork

Another prediction...

10. Microsoft will increasingly play the patent card when competing with Linux. Although company officials have downplayed the extent to which Microsoft is threatening customers and partners with the risk of patent-infringement lawsuits if they go with Linux, we hear this is an increasingly key piece of Microsoft's competitive strategy. With Microsoft vowing to file 3,000 patent applications during fiscal 2005 alone, we expect the company to rattle the patent sabers even more in 2005.

Some background...

Microsoft has been slowly but surely deemphasizing its Passport digital-identity service for more than a year. But Passport increasingly is being pigeon-holed as a service for Microsoft properties only.

Another definition of the term "long tail"?

More Predictions

From Bill de hOra, tongue in cheek he says. We'll see...

java.util.concurrent will be a talking point and will produce a rash of articles and guidance as developers weep like children in the face of Doug Lea's 3rd edition of CPIJ.

Doug Lea's collection and concurrent packages have been one of my favorite features of Java for years. This would be a great prediction to come true.

Microsoft will try to hire Doug Lea.

I'd be surprised if this has not happened already. Does dotnet have anything like his concurrent package?

Everyone gets bored talking about AOP.

On the other hand, what if everyone realizes AOP is a nightmare from another era and moves to more simpler and expressive programming languages?

[Rich Internet Application] hacking hits the offline/online sweet spot as developers get fed up waiting for browsers, virtual machines and UI toolkits to evolve in response to Web Sites Which Are APIs... 2005 witnesses a revolution in how most developers are prepared to use obscure languages in production scenarios... The terms process-oriented, crash-first, concurrent message passing, and little language enter mainstream developer lingo. By the summer everyone gets closures and they replace IDE support as the popular distinguishing factor between languages. People start fooling with Erlang after they realise EJabberd is written in it and Herb Sutter's Fear and Loathing in Concurrency article scares the beejesus out of everyone.

Great predictions.

IM becomes a viable alternative to the heavier Grid and P2P technologies for integrators and data crunchers working at federation and Internet scales, but will initially be frowned on as a simplistic and inadequate for 'real work' - the debate will initially look like a rerun of WS-* v HTTP/XML

Nice. No tongue in cheek needed.

Finally...

Patrick Logan and Ehud Lamm become superstars.

Hmm. Tongue must be partially in cheek. Ehud certainly deserves credit and publicity for Lambda.

On the other hand, I don't look good in Spandex and I don't have much of a stage presence.

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?