Communication

As seen on the XPDX Yahoo group...

Thanks for all the comments... One respondent said XP depends on communication, but I work in a corporation.

I guess that corporation does not "empower" their employees enough.

We Won't Get Fooled Again?

Scott Rosenberg writes...

The Bush inaugural marked the final transition of the Bush-family ideology from old-school conservatism, with its abhorrence of abstract schemes of human perfectibility, to a messianic idealism so divorced from reality it gives even sympathizers like Noonan the willies. Bush's vision of human perfectibility may be shaped by born-again fervor rather than socialist theory, but that difference doesn't make its collision with reality any less dangerous.

and writes...

This speech wasn't just soaring rhetoric. It was a lighter-than-air burst of helium verbiage -- lofty language untethered from the perplexing world we occupy and from the messy events of the last four years, sentences floating off into an empyrean of millennial vagaries.

The world is a simple place to Bush... His "untamed fire" is the cathartic inferno dreamed of by people who are confounded by a world they know is out of their control.

Thank You, Ken Anderson

Thank you, Ken Anderson, for your contributions to JScheme. There have been many times when I needed access to Java functionality but not the Java language per se. JScheme makes that kind of programming pleasant and productive. One of Ken's contributions was the Javadot notation which is a large part of ease of this Scheme/Java integration.

From Tim Hickey, another of JScheme's creators, via Chris Double...

I'm sorry to bring you the very sad news that Ken Anderson, one of the co-developers of JScheme, died last night...

Ken touched many lives and brought many communities together.

Lisp and Concurrent Programming

Bill Clementson has a huge list of Lisp-related concurrent programming references. And if you haven't looked at Erlang yet, it is a list-based semi-functional language. Too bad it doesn't use Lisp syntax.

Bill refers to Dirk Gerrits, building an Erlang-like concurrency mechanism in Common Lisp. Something like this was done for Python as well, called Candygram.

Also related is the ETOS compiler for Erlang that generates Gambit Scheme, which scales as well as Erlang/OTP.

The mind spins, concurrent thoughts swirling all around.

This and That in Politics

I'm reading this and that near each other in my bloglines. They both alarm me for reasons that are not dissimilar.

PyCon DC 2005: IronPython

I didn't see anything on IronPython at the March conference, but Sam Ruby pointed out the keynote.

Structure and Notation of Computer Programs

Agreed...

We're not so much building on the programming state of the art as continually have each generation of programmers rediscover it.
-Bill de hOra

OOP Is Much Better in Theory Than in Practice?

Lambda the Ultimate discusses the merit of an article as well as its content. Again against the object.

I think OOP is better in practice than in theory. But then I value practice more than theory.

Guessing from the Terminal

Mountains of wisdom from the Mountain of Worthless Information...

Next time you're in a meeting with folks and somebody asks you how long you think it'll take, be sure to tell them whether this is a "from the terminal" sort of guess, or a "from the ground" sort of guess. The difference? Until you've been-there-done-that, and have something against which to measure their requests (meaning you have some kind of experience with the things in question, ideally having built something like it before), your estimates are likely to be all "from the terminal" guesses, and highly likely to be wildly off base.

Smug Lisp Weenies

John Stephen Jacob Anderson, apparently a SmugLispWeenie if there ever was one, writes...

Python was the subset of Lisp that was understandable by C++ programmers.

Being at least a former SmugLispWeenie myself I am having trouble disagreeing. Which is not to say Python is bad, it just loses in certain significant ways that Lisp does not.

Update based comments:
"outside of the CS department"

Ouch.

I think Lisp is safely outside the CS dept. If we could get it *into* the CS dept. maybe things would improve a bit.

"Listing those significant ways"

Syntax extension, syntax itself, closures, continuations (Scheme in this case), to name the top of my list.

I would also include as a result of these, Lisp is a good vehicle for language experimentation (or just defining new object systems), whereas Python provides a simple object system it is more restricted in where you can take it.

Which is not to say that I would not choose Python over 90% of the industry's languages. I would.

Cairo as well as OpenGL

From "The (Re)Architecture of the X Window System" a progress report on Cairo...

This integration of the familiar PostScript operational model within the native application language environments provides a simple and powerful new tool for graphics application development...

Cairo's rendering algorithms use work done in the 1980's by Guibas, Ramshaw, and Stolfi [GRS83] along with work by John Hobby [Hob85], which has never been exploited in Postscript or in Windows. The implementation is fast, precise, and numerically stable, supports hardware acceleration, and is in advance of commercial systems...

Cairo is in the late stages of development and is being widely adopted in the open source community. It includes the ability to render to Postscript and a PDF back end is planned, which should greatly improve applications' printing support. Work to incorporate Cairo in the Gnome and KDE desktop environments is well underway, as are ports to Windows and Apple's MacIntosh, and it is being used by the Mono project. As with Xft2, Cairo works with all X servers, even those without the Render extension.

Also regarding X and OpenGL...

Using OpenGL as the basis for the X server itself will place X objects such as pixmaps and off-screen window contents inside OpenGL objects allowing applications to use the full OpenGL command set to manipulate them...

Whether the "core" X graphics will require any OpenGL extensions is still somewhat an open question.

In concert with the new compositing extensions, conventional X applications can then be integrated into 3D environments such as Croquet, or Sun's Looking Glass. X application contents can be used as textures and mapped onto any surface desired in those environments.

I think this is huge. (Yes, even huger than Avalon). Turning X, per se, into a legacy window system within a portable, modern vector and 3D graphics environment. Just remember, Don't Fidget With Widgets, Draw!

Where did those OpenGL patents go, again? Oh. Yeah. Now I remember.

Via Miguel de Icaza. (Microsoft must be wetting their pants trying to get de Icaza to sign up with them. I'd like to see the offer sheet.)

From the "What's That Again?" Department

From CNN...

"Poll: Nation split on Bush as uniter or divider"

Well then, apparently we have our answer.

Models for Backwards Navigation

Nice alternative implementation of a continuation-like web mechanism for languages without first-class continuations.

Unwittingly explains the *conceptual* model of continuation-based web servers. Languages with continuations offer a better *programming* model by simplifying the web programmer's *mental* model.

If you are familiar with web programming but unfamiliar with continuations, read this one first to get the concept, then read about continuation-based implementations.

Wiki and Comment Spam

I've not written my own wiki or blog system, and not thought about this problem at all. Given that, what if a form of "email authentication" was used to approve wiki edits and blog comments? (I think I've seen this somewhere but can't get google to remind me where.)

1. Someone edits a wiki page or adds a comment.
2. The change is suspended until "authenticated".
3. At this point the person enters an email address (of some determinably accountable, non-transient nature).
4. The change or some indication is sent to the email address.
5. Upon receipt of the response or via an http form in the email, the change is accepted.
6. In addition to other filtering and governing, the site now also has an email address.

Being FIT

Will Stott writes about using FIT via Excel.

Proof Carrying Code

I've only read a surface amount about Proof Carrying Code. In spite of my default stance on types, I am interested in ML and Haskell style type inference. So this book looks interesting, covering both topics and then some.

Via Lambda.

Can You Have It Your Way?

Guido's latest wandering around the world of type checking are disturbingly non-committal. I'd like to see his thinking get back to root causes and work forward to solutions. As it stands he's kind of wandering around the space of semi-solutions to unspecified problems.

Uninteresting and not a good use of my time at this point. If you've read this blog you know I am not interested in types much if at all. But whereever you are on the spectrum you most certainly would benefit from language changes being rooted in clearly outlined problems statements and solution explorations.

Objects are Easy? (Maybe Not)

A comment on Scott Rosenberg's blog post about concurrent programming...

Herb Sutter's analogy to object- oriented programming is completely bogus - OO is a bag of tricks for making it *easier* to write programs (often at the expense of making them a little slower), and especially easier to debug and maintain those programs; parallel programming makes it *harder* to write programs, and dramatically harder to make them correct, debuggable, and maintainable. It's just not going to happen.

First I would argue that programming with objects is not easier. But then the question is easier than what? The commentator does not say.

Objects are a code organization mechanism. As the complexity of a system grows, objects help through organizing the complexity. Progammers can use objects to focus on specific problems without being overwhelmed by uninteresting aspects of the system.

But objects are not easy. However I would agree that concurrency is even more difficult, especially given the languages and tools of the past several decades.

The commentator appears to be making an assumption though that the languages and tools of the past will not improve and there will be no incentive to improve...

As a software engineer with over 20 years experience, including a good deal on highly parallel machines, I can tell you for sure that there is not going to be a revolution in software development. Explicit parallelism is just too difficult to get right in general, and the applications that benefit from it have already been optimized for multi-cpu machines since the 1980's.

This sounds a lot like previous infamous predictions like no one needing more than 640k RAM.

Objects are hard, but they offer better notational organization. Processes are hard too, but they offer better dynamic organization. We just need better notations and tools for processes and someday someone may be writing something like "concurrency is a bag of tricks for making it *easier* to write programs".

The same commentator adds in a subsequent comment...

People don't get smarter, so this problem is not going to be solved no matter how much Intel would like it to be.

The same might have been said about programming sequentially before objects, or even modules and structured procedural improvements. The software industry has gotten smarter, perhaps not as quickly as any of us would like.

The Io Programming Language

A friend has been playing with the language Io. I spent an hour or so with him on it. Very interesting.

Io is small prototype-based programming language. The ideas in Io are mostly inspired by Smalltalk (all values are objects), Self, NewtonScript and Act1 (prototype-based differential inheritance, actors and futures for concurrency), LISP (code is a runtime inspectable/modifiable tree) and Lua (small, embeddable).

The language has an interesting evaluation, reflection, and delegation model. Io has a syntax that does not always require an explicitly denoted receiver for a message. Someone just learning Io can scratch their head once or twice figuring out what's going on.

On the whole though Io is a very simple language with what looks like a simple CPython-like implementation. For programmers looking to understand the "prototypes and delegation" approach to object-oriented programming (as opposed to "classes and inheritance"), then Io seems to be a simple way to dive in deep.

Playing a bit with Io felt a lot like the pre-CLOS days of Lisp in the 1980s when there were a lot of experiments with object systems like ObjVLisp, OakLisp, Loops, etc.

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.