Graham's Latest

Speaking of Paul Graham, his latest essay is as entertaining as any...

Microsoft saw the danger of Javascript and tried to keep it broken for as long as they could. But eventually the open source world won, by producing Javascript libraries that grew over the brokenness of Explorer the way a tree grows over barbed wire...

The surprising fact is, brilliant hackers—dangerously brilliant hackers—can be had very cheaply, by the standards of a company as rich as Microsoft. So if they wanted to be a contender again, this is how they could do it:

1. Buy all the good "Web 2.0" startups. They could get substantially all of them for less than they'd have to pay for Facebook.
2. Put them all in a building in Silicon Valley, surrounded by lead shielding to protect them from any contact with Redmond.

I feel safe suggesting this, because they'd never do it. Microsoft's biggest weakness is that they still don't realize how much they suck. They still think they can write software in house. Maybe they can, by the standards of the desktop world. But that world ended a few years ago.

I already know what the reaction to this essay will be...

Lisp: Beating the Averages

I just installed the latest Gambit Scheme, continuing to be the best Lisp on the block. I first used Gambit around 1990 or so, when it was brand spanking new. The thing can really kick some serious ass, if you're looking to beat some averages.

Coming back around to thinking in Lisp, to some of Paul Graham's stuff...

The designers of Lisp didn't put all those parentheses in the language just to be different. To the Blub programmer, Lisp code looks weird. But those parentheses are there for a reason. They are the outward evidence of a fundamental difference between Lisp and other languages.

Lisp code is made out of Lisp data objects. And not in the trivial sense that the source files contain characters, and strings are one of the data types supported by the language. Lisp code, after it's read by the parser, is made of data structures that you can traverse.

If you understand how compilers work, what's really going on is not so much that Lisp has a strange syntax as that Lisp has no syntax. You write programs in the parse trees that get generated within the compiler when other languages are parsed. But these parse trees are fully accessible to your programs. You can write programs that manipulate them. In Lisp, these programs are called macros. They are programs that write programs.

Programs that write programs? When would you ever want to do that? Not very often, if you think in Cobol. All the time, if you think in Lisp.

Way Out

From Javaworld...

Engineers at Sun are eyeing May for the release of a 1.0 version of JRuby , which provides a Java implementation of the Ruby language... The JIT (just in time) compiler will be enabled by default this month. April plans call for deciding on the final features for the 1.0 release as well as a major bug-hunting push...

Future directions for JRuby include Ruby 2.0 bytecode support and leveraging the HotSpot JVM to speed execution.

Running the Numbers

My sister-in-law sent this link to me, using art to convey significant cultural statistics.

Crazy Fuggers

(Via Blaine Buxton) Edward Povazan exclaims...

Initial exposure to Smalltalkers can be rather confusing. At first you think you understand them, after all they are speaking of an object oriented language. Then utter confusion, they are not talking about a language so much as a whole world...

I am starting to understand things and want to be in this lively Smalltalk world.

Systems

Would you rather your body attempt to act as one "logical" cell, or are you happy to survive as a system of cooperating cells with billions dying off and being replaced each day?

Steve Loughran reminding us of a Note on Distributed Computing. From the note...

We look at a number of distributed systems that have attempted to paper over the distinction between local and remote objects, and show that such systems fail to support basic requirements of robustness and reliability. These failures have been masked in the past by the small size of the distributed systems that have been built. In the enterprise-wide distributed systems foreseen in the near future, however, such a masking will be impossible.

A favorite quote from elsewhere by Jim Waldo, one of the authors...

I've been known to claim that there are two kinds of reliable message systems. The first kind are those that come with an asterisk; following the asterisk leads you to the small print, where you find out when the messaging system can fail and so it is not, therefore, reliable. The second kind are those systems that simply lie – they are no more reliable, but they don't tell you that there are circumstances where they can fail.

Scary Cursors

If this story about vulnerable cursors does not tip us over the line, what will? Whoddathunk that a screen cursor could be the gateway for bad things on your PC?

What to do?

Capability-based systems go back to the 1960s. Someday we'll have them on the Internets, a series of tubes.

How many billions spent on broken security mechanisms? And we still have screen cursors with the power over the entire machine.

Bye Agassi

Bill hits the nail on the head writing about the resignation of SAP's Shai Agassi...

And so it goes. The slow death of SOA.

Netweaver was Agassi's baby and was expected to be more revolutionary for the company than it is turning out to be. Several SAP architects I'd spoken to did not even realize that Netweaver included an implementation of JMS, nor did they really understand what JMS is and when it might be used instead of their XI orchestration mechanism (which is built on R3's relatively cumbersome ABAP workflow engine, not on Java/Netweaver).

The most agile mechanism for working with SAP that I have seen remains an open source Perl API demo'd at OSCON several years ago.

I do hope Agassi is successful applying his abilities and resources to the energy industry though. That could be a better move than remaining with SAP.

Flash, Flex, Apollo -- Nice Bits

Via Blaine Buxton, the Omaha Dynamic Language Group will be discussing Flex and ActionScript 3.0.

Other programmers here have been diving into that the last few weeks. I've been reading in my down time from other things, but would like to write some code in the next few days. Flash 9 has a lot of general improvements as an environment for structured graphics applications, and Flex builds on that for GUI front end things that are not so oriented toward animation and graphics as the base Flash api.

Apollo just looks to be a leap ahead of other "Web 2.0" (if you will) front end environments. Busting out of the crappy browser that in spite of AJAX has been mostly languishing for years and years. We're not using Apollo yet here, but for some of the front ends we may need it could be. It's only in an initial alpha release currently. I want to play with "the bits" as they say at an Adobe rival that should be really concerned with the polish Flash, Flex, and Apollo are showing.

FIT Wiki Rules Spaces

Fuzzy writes about the work we're doing...

We beat our rules module into submission.

We're writing FIT tests in our Confluence wiki. A custom FIT runner grabs the tests using some specified label and the Confluence XML-RPC api.

We also have Bamboo up and running, and soon Jira. The Atlassian folks have some nice tools.

As Mike writes, the Javaspaces and JBoss Rules came together well. When I had looked at Drools some time ago I was turned off by its XML nature. Jess is not free, but not expensive, and has good Java integration. Jess also has a good scripting language in its own right (Lisp-based). Back then it would have been a no-brainer.

Since JBoss took on Drools they now have all but done away with XML. In fact none is required from what we've found so far. The Java integration and the rules language itself is not as good as Jess, but it is pretty good and it's free and open.

We've not tried the decision table mechanism. If we're lucky that takes care of most of the Java integration ugliness and if we're *really* lucky our business analyst can use it in whole or in part with little or no programmer intervention. She's very smart, but non-technical. That's the aim of the decision table, I believe. The Jboss site also has something on FIT and JBoss Rules, but we've not tried that yet either. Our FIT tests go through our own fixtures.

On the spaces side we dynamically update and make available all kinds of reference data and object prototypes via a space. When it came time for rules, we did the same thing. Rules are compiled and tested in the build scripts, and stashed away as release artifacts. When the environment is initialized the compiled bytes are sucked out of the files, wrapped in a RulesEntry and written to a space. The rules compiler has all kinds of dependencies but the compiled rules at runtime just depend on one core jar.

We have a mini-grid of sorts that run any kind of TaskEntry.execute() from a space. If such a task happens to need a rules engine, it makes one, takes *reads* (rules are shared, and so, read, not taken) the appropriate RulesEntry from the space, and squirts the bytes into the rule base. If the rules need to be updated then the new bytes in a new RulesEntry simply replace the old bytes in the old RulesEntry. The next time a task tries to read the entry, it gets the new rules. The TaskEntry objects and code can be updated the same way, no worrying about what is or isn't on some arbitrary JVM's classpath.

The "facts" needed by the task also come from a space. The task takes them from a space and assertObject(entry)'s them into the rule engine's working memory.

The "many, flat" nature of entry objects flowing through spaces and the ease of writing rules around "several, flat" facts makes these two mechanisms the good fit Mike describes.

I will repeat: in my experience, Jini and Javaspaces make Java applications as close to a concurrent, distributed, dynamic system experience as can be done. If you would like to use Erlang, but have to use Java, then try using Jini and Javaspaces.

We're just getting started with this experiment, but everyone's seeing the advantages over even the relatively flexible JMS products.

Meet the New Boss

Nati Shalom, not an unbiased, but still an accurate observer...

Oracle's acquisition of Tangosol is one more acquisition in a series that indicates Oracle has finally come to the conclusion that the relational database is no longer a sufficient infrastructure platform for a large class of applications, such as Extreme Transaction Processing (XTP) and real-time analytics.

Let's see how much gas Tangosol has, though. Prior to the acquisition, the head of Tangosol had speculated about the combined advantages of their data cache and the jini, or at least javaspaces, distributed architecture. Now are they back to square one with J2EE?

Massive

Massive.

Massive.

Massive.

Massive.

Delegation and Inheritance

In 1986 Henry Lieberman presented at OOPSLA a really simple object system based on delegation to any other object rather than on inheritance through some fixed tree of definitions.

Confused looks led to friendly arguments, led to the Treaty of Orlando a year later. And then Self, etc. expanded on this, Newton Script, and Javascript. (But the wonder of it has been lost along the way. Javascript is getting "serious" by adding classes and type checking and so on. Bah. Forgive them for they know not...)

As long as we still care about objects then, here comes Ian Piumarta with his new one(s), er, two, no, one: "Pepsi" and "Coke". In a recent addition to Pepsi, Ian has delicately spliced the two worlds together...

Compared to inheritance, delegation is the more flexible and general of the two techniques. However, they both have their place within an object model: inheritance for sharing of implementation state (and the methods that act upon it) for a single prototype (within a hierarchy of related prototype families), and delegation for sideways composition of (independent and previously unrelated) prototypes into a single logical composite object. This is the position adopted (and implemented) for sideways composition of Pepsi objects.

Silver Anniversary

Sometime in the last year or two I passed my Silver Anniversary of using Emacs. That pre-dates even the existence of GNU Emacs. On jwz's Emacs family tree, I have used...

• The original EMACS on a DEC-20 / Twenex
• ZMACS on Symbolics and TI Lisp Machines
• Gosling Emacs -- eh, ok.
• Unipress Emacs -- on a Data General Eclipse, the only Emacs that ever sucked
• MicroEmacs -- from Craig Finseth's family tree.
• GNU Emacs
• Epoch
• Lucid Emacs
• XEmacs

Calling EMACS an editor is like calling Earth a hunk of dirt.

— Chris DiBona

I've had Emacs running for weeks on-end with buffer lists in the dozens. I love Emacs and I am ready to be more than just friends.

How Emacs works.

Game Flow

The interactive "game flow" chart ESPN uses is a great visual overview of a high-scoring sport like basketball. See the game flow chart on this page for the Buckeyes vs. Memphis game this afternoon. (Especially because the Buckeyes won.)

Be sure to roll the cursor over the game flow.

Process Improvement

There are a few things I have been wanting to tie together for the last week or so. Now I guess I am getting around to it. Otherwise another few weeks could fly by.

In no particular order they are:

• Gilad Bracha's ideas on "Service Objects" and their lifecycles.
• Ian Pumierta's (et al.) work on bootstrapping an ideally minimimal, evolvable object system. (video from a Stanford lecture)
• Dan Creswell's thoughts on objects and dependency injection, and concurrent, distributed systems evolution.

Maybe you can see what this is about just from that list. Now I am going to tie in a couple other things.

• Gilad's talk mentions Erlang.
• Everything about objects gets back to Alan Kay sooner or later. One of my favorite quotes of his...

Smalltalk is object-oriented, but it should have been message oriented.

What this means to me is that a system (in the home, in the data center, around the world, whereever) should be able to send messages to each other far more easily than they currently are able. And systems should be far less concerned with what is "on the inside", or that their insides necessarily have anything in common with each other.

Erlang is currently the premier tool for building concurrent systems. And Joe Armstrong is its prophet. Really interesting web servers (yaws and erlyweb), IM servers (ejabberd), mail servers (experimental and commercial), voice servers, data bases, and enterprise message servers exist in Erlang. And a ton of other things. Aside: recently Erlang started taking advantage of multicore and SMP hardware in addition to distributed hardware.

I appreciate the important ideas and work that Gilad, Ian, and others are doing. At the end of the day though that work strikes me as improvements on the current mediocre state of the intraprocess runtimes. The Smalltalk folks have already shown the runtime can be far simpler, stable, and evolvable than the ones most of us use most of the time. (PDF on the Silt server in Smalltalk.) Gilad and Ian's work may ultimately improve on that.

Does your app leave little "pid" files around to indicate something is running with some OS process id? Or can your app actually start up and detect that some other process in the system is running? And begin communicating with it?

Can those various processes come and go, and yet the system continues to run, perhaps after healing itself?

That is *service* oriented and that seems to be more about messages and not so much about objects. We should have a "programmer's holiday" where we all pause our current work and play with Erlang for a week. Not that we should all be using Erlang for everything, but we should all be *influenced* by Erlang for everything.

The Computer Is (on the?) The Network

Dan Creswell writes about the coming onslaught of multicores and multinodes and the prevailing mindset of byte code virtual machines that still closely resemble the UCSD Pascal system from 1980.

For all the attention that multicores are getting from AMD, Intel, Stanford, Berkeley, and elsewhere it is shockingly apparent that on the software side the more things change the more they stay the same. Rather than the other way around.

Apache Meetup

The Apache SOA folks would do themselves a favor to meetup with the Apache River folks.

And vice versa.

Not that I care two hoots and a holler about SOA. I'm just saying.

Dynamic DST

A fairly good indication of software brittleness reared up today in the US, and anywhere else time is computed for the US. Most software has some fairly hard-coded time zone mechanism that never anticipated the federal government's regulation moving Daylight Savings Time this year. Most systems that were upgradable required more manual labor than they should have.

How many other assumptions are baked in that would benefit from a more dynamically loaded aproach?

We want our pieces to be small and loosely joined, but by and large they are far from it. Moving in that direction is not easy. There is so much we have not even considered yet.

State

Dan Creswell writing again, about "state" this time...

Maintenance of state is a shared responsibility for a system. We should seek to place that responsibility in appropriate places at appropriate times and be much more aware of responsibility boundaries and when it’s appropriate, share that responsibility amongst components.

Generally we consider TCP to be responsible for ensuring that state makes it to the other end of the connection. One hands some data to the TCP layer and we expect that it will ensure the data reaches the recipient. But is this true? What happens if we suffer a power outage before TCP transmits the data? When the machine restarts, is TCP going to restart and resend all that unsent data? Clearly not, whoever delegated responsibility to TCP for this data will now need to take steps to recover the situation.