Making it stick.

Web shopping in particular, and web user interfaces in general, just got a lot cooler. Clearly, 2005 is now officially the year of the rich thin client.

This is really inspiring work (try it), and the contact information shows Portland, Oregon. Anyone know who is behind this?

(Via Mark Baker)

Avi Bryant writes...

In Smalltalk, however, the only thing that's in C is a tiny virtual machine that understands a very simple set of bytecodes - it knows about pushing and popping objects from the stack, accessing indexed slots, blocks, and method dispatch. What it doesn't know anything about is the language syntax, standard library, compiler, debugger, profiler, thread scheduler, exception system, and so on, and so on - all of these things are implemented in Smalltalk.

[Smalltalk] doesn't support continuations and you want to add them? No problem; 10 lines of [Smalltalk] code and you're there.

...clearly you could implement the Ruby language with a Smalltalk-style VM (hopefully one with a Smalltalk-style JIT as well, which would bring a 20x or so speed increase to the current Ruby interpreter). But really what I'm talking about is a philosophical difference, not a technical one: to Smalltalkers, it's essential that as much of a system as possible be implemented in Smalltalk, whereas this simply isn't a priority for the scripting language community, and it's the priorities rather than the individual implementations that draw me to Smalltalk.

Beware.

Via Blaine Buxton

Gordon Weakliem writes...

Mozilla is still a C++ app though, and seems to be very stable. Architecturally, it seems to be built around JavaScript and XUL though. It's almost like a VM architecture in that respect. I've been messing with Mozilla Extensions lately, and though it's not the greatest development environment ever, it's very easy to write code for once you get your bearings. The XUL architecture seems to extend very far down into the browser, with most of the browser implemented in XUL and script. Again, it seems like an underlying VM is a prerequisite for a modern software architecture.

Which is ironic given not more than ten years ago the programmers using this architecture were fighting heated arguments about the very idea.

I guess if I had to sell someone on Lisp or Scheme today, I might describe it like this:

"Lisp is an XML scripting language."

Phil Windley is connecting language concepts, Scheme, and XML in his BYU programming language concepts course.

He has a simple excercise that makes the connection. The next step would be to blow their minds with SSAX.

Update: Phil Windley has a page for his students for running SSAX. To gauge how similar Lisp is to XML, how natural the mapping, the SSAX translation of Phil's original classroom example is identical except SSAX wraps Phil's translation in a list to indicate that is the top of the document...
(*TOP* (phil's data))

"Naturally dull, I’ve forgotten Zen activities"
- Isshi Bunshu (1608-1646)

Another blog item on testing.

This one asks whether the tests themselves should alter the interface of what's being tested. i.e. should the test have a back door for peeking into the black box.

My opinion is, emphatically, no. Not for the kinds of tests created while test-first programming.

An impulse to check on the internal state of an object while test-first programming is an indication of one or two things:

• The test is being perceived too much as "testing" and not enough as "designing".
• The object itself is probably too complex. Fix the design.

Um...

Avid sailor Craig Venter has trawled for microbes in the Sargasso Sea and discovered more than a million new genes and 1,800 new species. Among them are organisms that thrive on carbon dioxide. Venter hopes to re-engineer some of these unique microbes genetically, into "designed species" that may reduce environmental CO2 levels, as well as provide new foods and energy sources. "Biology can do much more sophisticated chemistry than the best chemists," says Venter.

Hey, I suspect biology can do much more sophisticated *biology* than the best biologists as well!

I'm not sure I want people tinkering with CO2 consuming microbes any more than I want us putting fossil carbon into the atmosphere in the first place.

Frank Sommers writes...

I find myself violating this tenet of XP very often. I do test all my code, but often only after I've already written that code. Why does this one XP rule seem so out of place to me? ...

I like to think of refactoring and testing as editing. When writing an article, most writers first create an outline, then write the content, typically in a few sittings, and without regard to mistakes, typos, sentence structure, etc. Only then does an author spend most of his time on editing, fine-tuning, and polishing the article.

I think this seems out of place when "testing" is perceived to be a testing activity rather than a design activity. Rather than not testing first, try taking on a new perception of what it means to "test" software.

The way I view test-first programming exhibits the same outline -> content -> polish flow. In my perception, the "outline" is the short list of tests I think I want to write over the next hour or so. This list of tests is just a list of names, each name being some *design* feature that needs to be developed. Each name will show up in the design.

Then the "content" is the expansion of a name on the list into code:

1. One or a few function calls or message sends.
2. One or a few assertions about what is true afterwards.
3. The other code needed to setup the calls, implement the assertions, and teardown.
4. Then when this content breaks, the test framework tells me what's wrong.
5. The rest of the content is missing... I have to write the code that implements the calls.
6. When the "test" part of the content does not break, the initial draft is complete.

This content (the calls and assertions) is design information, an expression of a design contract. I am not testing something already conceived. I am in fact conceiving of something, creating something, designing something new: an expression about a system and an assertion about what is true given that expression.

As soon as the content is drafted, immediately I begin to polish that draft, consider how it fits with the other content, and how the content itself could be better expressed through reconsidering the names and parts and assertions.

So I see test-first programming as a way of designing. It happens to be a way of testing as well, which is good because a program has to be tested in ways that an informal text does not.

A note to Sean McGrath from Steve Jensen in Sean's comment section...

Thanks for plugging Erlang: even if it doesn't end up being heavily adopted, it at least moves people in the right direction.

Exactly. I like what else Steve wrote...

We need to move from using semaphores and monitors to lock global state towards thinking of the world as partially ordered and asynchronous.

Someone asked Joe Armstrong at his Lightweight Languages 2002 presentation what synchronization mechanisms Erlang has. Joe responded, "Two. Send and receive."

Exactly.

...is Sharepoint the suckiest thing on this planet?

JSON is the JavaScript Object Notation for writing "smart clients" like GMail in JavaScript without bulky XML messages. JSON-RPC is a simple RPC mechanism like XML-RPC. (Via Slashdot.)

I suppose this could also be based on YAML which is more rich than JSON, yet still not as complex as XML. I've not seen a mapping, in the few minutes I've looked, from JSON to XML, such as what's been defined for YAML.

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.

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, 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.

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.

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

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

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