And Now An Example That Works

Alright then, updating to Actionscript 3 the example linked in the previous post which was Actionscript 2, we get something that works, like this...

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" creationComplete="initApp(event)">
    <mx:Script>
    <![CDATA[
             import flash.events.Event;
             import flash.events.MouseEvent;
             import mx.containers.Panel;
             import mx.controls.Alert;
             import mx.controls.Button;
             import mx.controls.Label;
             import mx.controls.TextInput;

             public var submit_button:Button = null;
             public var first_text:TextInput = null;

             public function initApp(event:Event):void {
                 var panel:Panel = new Panel();
                 panel.title = "Hello World";
                 addChild(panel);

                 var label:Label = new Label();
                 label.text = "First Name";
                 panel.addChild(label);

                 first_text = new TextInput();
                 first_text.text = "Patrick";
                 panel.addChild(first_text);

                 submit_button = new Button();
                 submit_button.label = "Submit";
                 panel.addChild(submit_button);

                 submit_button.addEventListener(MouseEvent.MOUSE_UP, onMouseUp);
             }

             public function onMouseUp(event:MouseEvent):void {
                 Alert.show("Hello " + first_text.text + "!", "Message");
             }
       ]]>
    </mx:Script>
</mx:Application> 

If you have the free Flex 2 SDK you can compile and run it like this...

$ mxmlc something_else.mxml
Loading configuration file /home/patrick/flex2/frameworks/flex-config.xml
/home/patrick/dev/patrick.logan/flashstuff/formstuff/something_else.swf (143036 bytes)
$ flashplayer something_else.swf 

Another Flex Tip

I got another promising tip from Garrett Hart here inside Liberty Mutual...

He sent along this Adobe documentation on "Dynamically Creating User Interface Components". Here we go...

Em, hold off on this one. The code as it is in the article seems to be for ActionScript 2 rather than ActionScript 3. There were substantial changes in the display object class hierarchy.

Back to the drawing board, but the Vista Smalltalk swf example is still a good indicator.

Update

The url Garrett refers to in the comments is this one. Blogger kind of mangled it.

Vista Smalltalk for Flash

A hat tip to Patrick Mueller in the comments of my most recent post on starting up with Flex.

I'd not been paying much attention to Vista Smalltalk. Very nice. And Peter Fisk seems to be using the controls from mx.controls that I had problems with. Now to dig into his code to figure out what if any magic lies behind his Lisp or if I was simply missing something.

Either way, good news. The blogs come through.

My RIA Is Dynamic -pause- Naught

Update: It's been a while but there are some corrections to this post.

• The Flex API *does* support drawing on pixmaps so a MacPaint-like capability using this would be efficient.
• All the controls can be created using the Flex 2 API fr ActionScript 3. There is just a minimal mxml wrapper required around the AS code. I can dig it out here if anyone wants to see it, but I'm too lazy at the moment.

End

I've been playing with Flex2 (I'd go all out with Apollo except it does not run on Linux yet and I don't have steady access to Windows XP or Mac OSX). I have some questions that I've posted to some lists, but maybe this blog can attract some feedback as well.

No Pixmaps?

First some general impressions: Flex could be so good, but I am not sure if it is. The basic display architecture is reasonably what I'd expect. I am kind of surprised there isn't a pixmap level drawing capability. (Or is there and I missed it?)

I created a simple paint program that frequently cycles through colors, transparency, and line width. After a minute of "painting" the retained structured graphics system bogs down and mouse events are handled fewer and farther between.

No Intelligent Redisplay?

Which leads to my next question: even if all graphics have to be retained as heavyweight objects, does the repaint really have to slow down mouse handling so dramatically, so soon? If my program is adding a new line just a few pixels long, shouldn't the damage and repaint occur in a small rectangle around that line? I cannot tell what's going on in the slowdown to be sure.

Since I have not found in the API any smart damage capability (e.g. "invalidate just this region for repainting") and only a display-wide "invalidate" then I might assume the entire display list is being repainted unnecessarily. Since the API does have a reasonable hit detection capability then I would expect that to be used to determine what to repaint, if the system had some understanding of where the damage is.

Controls Must Be Precompiled?

I would really like to generate some UI controls (e.g. labels and input controls) based on some data received from somewhere in the course of the application. I wrote a little app to try this out. Then I ran into an error at runtime when trying to add a label to a vbox... "TypeError: Error #1006: getInstance is not a function."

Apparently all the controls in mx.controls can *only* be created through XML and the Flex mxmlc compiler. Actually this is not strictly true since the -keep switch will keep around the generated ActionScript files. Em, not the most beautiful or concise code considering the app consists of a window, a vbox to stack controls, and one static text control.

All kinds of craps are generated that have *nothing* to do with the app. This can also be seen in the runtime behavior of the XML version of this simple thing. While the few small Flex apps I have written to date come up and are ready very quickly, the XML generated app comes up slowly. Looking at the code it is apparently due to all kinds of initialization of things the app will never use.

Ugh - factories initializing craps - a very heavyweight stretch of code. Generated from XML input run through a compiler. (Apparently in spite of ActionScript having reasonable support for XML *in* the language, mxml code can only be generated from a compiler written in Java that runs at build-time. (Or on a "server" if you want to call out to one that can run the compiler for you!)

The result is "rich" but not very "interactive" -- especially given the heritage of ActionScript as a dynamic language. ActionScript, Flex, and such appear to be based in the developers Java heritage. The result is a Java-ization of what used to be a dynamic browser environment into a fairly static Java webstart/applet-like environment.

So given that mxml generates AS code and I can duplicate that, then to some degree this code could be hand-written and be data-driven at runtime (i.e. be done via a "gui interpreter" of data just like a browser interprets HTML). I am going to look into this some more. The code is readable if not concise. It only needs to be done once.

I'd love to find out Flex provides an easy-to-program, dynamic GUI/graphics capability. Almost the opposite appears to be case so far. Several companies are apparently building apps like word processors for Apollo. They have to be doing some fairly low-level and efficient stuff with the text layout and redisplay. I wonder what level of the API they are using and how much code they've had to write themselves.

I could be missing wide swaths of the API that just isn't covered in the typical documentation aimed at building static GUIs in an IDE via XML.

Gambit / Termite / Erlang

Dominique Boucher compares Erlang with Gambit Scheme, and in particular Termite, which is an Erlang-like system the runs on Gambit. His conclusion...

I would choose Erlang over Gambit-C+Termite for the development of a new scalable and robust distributed application. That being said, Gambit-C is a nice piece of software (in fact my preferred Scheme system), it has a great debugger, and the Scheme Now! project will certainly lead to a number of good portable libraries for Scheme. But from the perspective of an industrial developer, Erlang wins easily.

I would have to go along with this conclusion for almost any system that might have to be "production-ready" in the next couple two, three years. On the other hand I think Gambit Scheme is the better investment for the long haul. Erlang is a great language, and OTP is a solid framework for distributed systems. But Scheme is the better "foundation" language and Gambit has all the qualities of Erlang to become a solid foundation for all kinds of distributed systems, even an Erlang system, as exhibited by ETOS (Erlang-to-Scheme).

And In The Darkness Bind Them

secretgeek is a bit more tongue in cheek about this than the Church would recommend...

Lisp is so simple that you can implement it in any language in just a few pages of code. This might never happen though, because once you've learnt lisp you'd never want to write anything in any language other than lisp, so you wouldn't bother implementing lisp in any language other than lisp.

Lisp can be fully implemented in lisp in just a handful of lines. I just implemented lisp in lisp, fully, while i was hopping onto a bus and paying for my bus ticket all at the same time...

Only lispers have a true definition of fun.

Dichotomies

Jim Waldo comments on a resurrected Jini and OSGi thing...

In fact, OSGi and Jini are service architectures built for completely different contexts. OSGi is a service architecture for services that are in the same address space. It allows you to build programs out of cooperating services. And for that sort of thing, it is pretty good.

Exactly what makes Erlang so nice as a "service-oriented" programming language:

• Invoking services in another process is easy.
• There is no distinction between a service in the same address space and one in another address space.
• There are no guaranteed service behaviors, i.e. Erlang faces head-on the problems inherent in distributed systems.

Practice Begets Simplicity

Smalltalk is a much simpler language than Ruby. The ideal implementation is correspondingly simple. This has several positive implications, as Avi Bryant points out...

Dan Ingalls did a lovely binary compatible re-implementation of the Squeak VM in Java as an exercise to learn the language, in a tiny fraction of the time that JRuby has taken, because everything important, down to the parser, compiler, process scheduler, windowing system, and IDE, were implemented in Smalltalk anyway and so could be reused. That’s the kind of trick I’d like to see Ruby able to pull off.

There are a number of idiosyncracies in Ruby, in spite of its relative simplicity. Part of the problem is Ruby has been around well over a decade with just one implementation by essentially one developer.

Consider that in Smalltalk's first decade it changed fairly drastically and did not settle until toward the end of that decade. Also consider during that time there were a handful of implementors, many users, and the intent was to change the language for the better.

Not For Long?

Yes, Seaside is mighty nice. But for two reasons:

• Browsers still suck as an application platform after so many years.
• Programming languages still suck at distributed processing after so many years.

Tweny years ago had someone suggested that in 2007 something like Seaside would be the leading edge of developing distributed systems for end-user interaction, I would have blown my coffee out through my nostrils.

Yes, Seaside is mighty nice. Sadly.

Iraq - That's Right

MoveOn is holding a virtual town hall on the Iraq catastrophe.

You can attend a local house party and view/participate from there if you'd like.

Here is a banner and link you can put on your blog if you'd like.

They are asking which candidate has the best position on Iraq in your opinion. Here is my opinion, which I don't believe is so very far off from many opinions, if not expressed in the same way...

It is a *fucking* mess and getting out of it won't be easy, but I hope several people eventually go to jail because of it. I won't vote for anyone who does not admit it was a mistake, should never have occurred, and vows to apologize to the world as the next president of the United States. Enough bullshit.

That's right. I probably will not vote for president in 2008 unless I change my mind of this.

Innovation Happened Elsewhere

Paul Snively on language innovation...

Ironically, I think it's exactly Sun's hanging onto the Java language spec for so long that's led to the level of experimentation in other languages targeting the JVM that we're seeing. I find it fascinating that the JVM hosts a Scheme as good as SISC and a statically-typed OO/functional language as good as Scala.

Stem Cell Therapy May Combat Type 1 Diabetes

In the any news is good news dept....

A pilot study of people newly diagnosed with type 1 diabetes found that stem cell therapy eliminated the need for insulin therapy for varying periods of time.

This is the first trial to look at stem cell therapy in humans with this form of the disease. But experts stressed that the research is preliminary and urged caution when interpreting the results, which are published in the April 11 issue of theJournal of the American Medical Association...

Type 1 diabetes develops when the body's immune system attacks the pancreatic beta cells, which produce insulin -- the hormone that transports sugar from the blood to cells for energy.

"In type 1 diabetes, the immune system is out of balance," Skyler explained. "Ordinarily, all of us have some cells with the potential to destroy the pancreas, but the regulatory immune system prevents those cells from becoming sufficiently active. In type 1 (diabetes), there's a greater proportion of activity of the destroying cells and lesser activity of the regulatory cells. The goal is to try to bring that back into balance."

Dynamic Language Symposium 2007

Montreal? October? Dynamic languages? I am *for* it.

How To Tell Stuff To A Computer

Some interesting things happening on knowledge representation, by way of Bill Clementson.

Paul's Cliff Notes

Paul Graham continues...

When I wrote that Microsoft was dead, I didn't mean it literally. I couldn't have. Companies aren't alive, so they can't die.

In fact "Microsoft is Dead" was what we in the trade call a metaphor. I meant something else. Over the last couple days there has been some disagreement about what I meant....

So maybe I'd better explain exactly what I did mean...

Technology companies are projectiles. And because of that you can call them dead long before any problems show up on the balance sheet. Relevance may lead revenues by five or even ten years.

Rock

This Rock thing from Sun looks interesting. From the blog of Jonathan Schwartz...

Rock is 16 cores - we haven't said how many threads per core. Nor have we said why this chip heralds the golden age of effortless parallel programming, or how it brings fault tolerance to the masses. But stay tuned, I think we're planning on talking up both in the next few weeks.

Yeah, I think there'd be some cool software to write for these.

Rediscovering Smalltalk Kind Of

Rubyists are rediscovering Smalltalk, or at least its idioms, often one at a time...

>> class A
>>   def a_whole_new_me
>>     self.class.new
>>   end
>> end
>> a = A.new
>> a.class
=> A
>> a.a_whole_new_me.class
=> A
>> class B < A; end
>> b = B.new
>> b.class
=> B
>> b.a_whole_new_me.class
=> B

Attention all Rubyists, buy these books...

• Smalltalk Best Practice Patterns
• Smalltalk With Style

April Portland Smalltalk Users Group

James Foster and Dale Henrichs of GemStone will present a beta version of the talk on running Seaside in GemStone that they'll be giving at IT360 / Smalltalk Solutions in three weeks...

What: Portland Smalltalk Users' Group
When: Tuesday, April 10, 7:00 - 9:00PM
Where: GemStone Systems

See Eric Winger's blog for more information. From the blurb...

The Seaside framework provides a layered set of abstractions over HTTP and HTML that can be used for developing sophisticated web applications in Smalltalk. Seaside was developed in Squeak and ports are available for VisualWorks and for Dolphin. While the Seaside framework elegantly addresses HTML generation and application flow-of-control issues, it still leaves a few challenges for the developer-including persistence and multi-user coordination. In this seminar we will demonstrate a port of Seaside to a new dialect: GemStone/S. As a multi-user, persistent Smalltalk implementation that has no native user interface, GemStone/S provides an excellent environment for serving HTML and keeping domain objects persistent.

Subscribe yourself to the email list for the Portland Smalltalk User Group for main-lining the fun directly into your inbox.

Gambit Wiki

Gambit Scheme now has a public wiki.

No Comment

Bill de hÓra writes...

I found myself strangely unmoved, unsurprised, unshocked, unconcerned. I saw that a firestorm has not been lit across weblogs, as would have been the case not even a year ago. It seems that no-one cares anymore

Success By Failure

James Robertson notes...

Failure is way, way safer than trying something that isn't "mainstream".

I have seen many people succeed personally essentially by enabling the failure of their organizations. I guess I shouldn't knock it.

Latent Technical Complexity

James Robertson's notes from SPA 2007, speaker Dave Thomas (the longtime Smalltalker Dave Thomas)...

The problem: we're in an incredible complexity mess due to the badness of the current languages. This has generated a plethora of tools to try and compensate for that, but it only makes for a bigger pile. We have what Dave calls "Latent Technical Complexity".

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.

Minimalism

Dan Creswell writes about the various directions Javaspaces could be taken...

I’m a minimalist, I like my JavaSpaces nice and simple and I like being able to construct cleanly layered frameworks on top of JavaSpaces. This allows me to have nicely separated responsibilities at each layer leading to (IMHO) better, more understandable, more maintainable design in my systems. I also like to avoid building such layers on top of JavaSpaces if there’s something out there already that can do the job better in a specific scenario.

How Far The Browser

I've not done anything with Flex yet. Some co-workers have. It seems kind of nice relative to the current state of Ajax or the Java/C#-based "rich clients".

Web browsers really suck when you look back at their history. They've been around too long to be so bad.

More Erlang

Over on Lambda the Ultimate a growing thread on concurrency, Erlang, Lisp, and such. The thread centers around another successul use of Erlang in the real world, the online game "Vendetta Online"...

The new erlang based system is now in production. For those who haven't been following, we ran into problems with our existing Lisp-based system (named "Deliverator") which handles high-level AI behaviour.. large groups of NPCs, large battles and the like. Over the last couple of months, we've been in the process of migrating to a much more scalable architecture (named "Kourier") based on Erlang, an elegant distributed-programming platform.

Concurrently, a new book by Joe Armstrong is in the works (available now as a beta PDF) published by Pragmatic Programmers. The table of contents looks good. I bought the PDF but who knows when I'll have time to dig into it. There is an older book online that's pretty good, but somewhat out of date, "Erlang in Real Time".

The original book, "Concurrent Programming in Erlang", is a smaller effort, fine for beginning, but the two mentioned above get into more details required for building complete systems.

call-with-current-continuation and java

Fuzzy sent a link to this piece on adding continuations to Java, more or less. The article mentions a potential JSR, but from reading through it, I'd expect a good bit of experience should be racked up before that would be practical. Apparently the implementation works now but plays some tricks to do so.

Continuations have been incorporated into several Web application frameworks, including RIFE and WebWork. In this interview with Artima, RIFE project founder Geert Bevin discusses how continuations can simplify complex workflows, and how they are implemented in RIFE.

A BIG Snow -- Scheme Now!

Snow (short, for Scheme Now!) is something the Scheme programming language community has needed for a long time. Snow is a packaging specification and repository that has been ported across multiple Scheme implementations. Yow. Marc Feeley, long-time implementer of Gambit Scheme, is one of the primary forces.

Snow is a general framework for developing and distributing portable Scheme packages. Snow comes with a set of core packages that provide portable APIs for practical programming features such as networking, cryptography, data compression, file system access, etc. Snow packages can export procedures, macros and records.

While Snow depends on non-standard features of the host Scheme system, the APIs Snow provides can be used in most R4RS Scheme systems. The Snow framework is a specification of a package structure and a package distribution protocol. The framework is not biased toward an existing Scheme module system, but can be mapped fairly directly to many existing module systems allowing Snow packages to be used from code that is Scheme system specific as well as from other Snow packages.

Such specialized Snow framework implementations have already been written for some of the popular Scheme systems and efforts are underway to implement more. We have also written a generic Snow framework implementation that works on most Scheme systems but that does not achieve the same level of integration with the host Scheme system. It provides features which are helpful for testing portability of newly written packages and it is useful when a specialized implementation of Snow is not yet available for the host Scheme system. The generic Snow framework implementation currently supports a dozen host Scheme systems.

Non-Symbolic Languages

Gilad Bracha writes...

Java was actually designed to have tuples from the start, but they never quite got in. At one point, I tried to add a tuple-like construct as part of JSR-65. We wanted to extend array initializers to full blown expressions. Eventually, that effort got quashed; I didn’t really resist, since the extension was painful, as such things always are in Java. We should have just done straight tuples as a separate construct - but at the time, that was frowned upon too.

This is because Java's syntax and the better part of its semantics are derived from the C family. Ironically Java is essentially a "symbolic language" underneath (i.e. the implementation is derived from the Lisp/Smalltalk family.)

Arguably both of these choices increased Java's popularity. Unfortunately the choice of syntax and semantics has stunted Java's expressiveness and will never overcome that beyond incremental improvements.

Update

I am asked in a comment what I mean by "symbolic language". I could have written "dynamic language". Essentially I mean the languages that have evolved from or were greatly influenced by the original Lisp implementations from the 1960s. The "symbolic" part goes back to Lisp's fundamental data types: symbols and lists (or symbols). Of course it has numbers and all kinds of data types now, but originally Lisp was intended for manipulation of symbols more than numbers, and so was called a "symbolic language".

End

Rotten Apple

Katie Dean wonders "if Apple lost Jobs"...

Apple has said that Jobs knew of backdated option grants but "was unaware of the accounting implications," and an internal investigation cleared him of misconduct.

Hypothetical satire follows...

Steve Jobs: "Gee, yeah, I knew we were backdating stock options to ideal dates where we could capitalize on changes in stock price that already occurred in order to enrich ourselves, but... you mean to say there is a problem with that?"

AlgoKit

Like Process One, Joel Reymont is also going at it with Erlang (and OCaml)...

AlgoKit is the high-frequency automated trading platform that I’m developing in Erlang.

My focus is futures and I’m not planning to use technical analysis. I want to capture and replay ticks, build a “Depth of Market screen” in software and make it simple to write, test and execute strategies that rely on volume, market delta and depth of market. Once the trading bot is ready I want to be able to co-locate it near the exchange, run it 24/7 and monitor it remotely via web or instant messaging. I’m after low to ultra-low latency so performance is definitely something I keep in mind...

I can receive a market quote, make a decision, execute a trade and receive a comfirmation within 5-10ms if I co-locate near the exchange. I would need to monitor the health of my algorithms, though, and would want to receive periodic updates. Erlang has both a web server and a Jabber/XMPP server so I can modify parameters of my algorithms using a web browser and check up on things via instant messaging...

The ideal solution is to marry the best of Erlang with the best of OCaml and write the algorithms themselves in OCaml while receiving market data from Erlang and feeding trades back to it for execution. AMQP and RabbitMQ (written in Erlang!) may just be the connection.

Outer Limits

Mickaël Rémond writes in the Process One blog how they are taking ejabberd to the outer limits...

At Process-one, we have always been performance freaks. ejabberd is without a doubt one of the most scalable XMPP server around and we have a strong reputation among our customers...

Angie is our internal codename for our program to move ejabberd to gigantic scale and make it able to support millions of users in a single domain...

We have reached 600,000 simultaneously connected users in benchmark, but we now want to increase the performance to be able to pass the 1 million users mark on the same hardware (We can probably go further, but we would need more machine).

Memorablies

Among the several artifacts from my 24 hour rant I will always treasure are the following quotes...

• "Refactoring for factuality, I think he means something more like..."
• "I've seen synchronized markers employed like pixie dust until the problem seems to go away."
• "I have a hard time telling what's really going on on that blog page."
• "Blimey, that’s gonna cause a bit of a ruckus."
• "It's an apples and rhinos comparison."
• "Lots of dodgy assertions and straw-man--bashing, but there are some lucid moments."
• "You're looking at premium car-wax, retina burning shine'y"
• "Right now the post is so heavily edited that it looks worse than a wiki page on thread mode during a flame war."

Yes, and I edited that page by myself. No help. 8-)

Classics. Thank you for the quotes and the arguments one way or the other.

On Complexity

The question is asked over on LtU about my transactional memory rant...

why is the under-the-covers complexity of STM bad, when the under-the-covers complexity of garbage collection is good?

There is a glaringly obvious answer to this...

A garbage collector eliminates tons of complexity from the application developer's burden, allowing the app developer to focus more on the true problem domain.

Transactional memory does no such thing. Application developers have to think about shared memory, potential conflicts, how to express them as transactions, and as mental points out: ultimately how to *recover* from a transaction failure.

On comments from Mental...

I don't know that you're really forced to deal with conflict resolution -- most of the popular STM implementations deal with conflict for you by terminating the conflicted transactions and automatically retrying (perhaps with backoff). Conflict resolution is taken care of (or, if you want to be pessimistic, taken out of your hands).

Common optimistic concurrency control techniques make matters a little sticky in that regard: you can easily end up in a situation where a long-running transaction is starved by a steady stream of shorter transactions whose successful commits conflict with it.

It's a slippery slope. New kinds of conflict resolution will be thought up and implemented. I've seen this with transactional systems like Gemstone for Smalltalk and Java. The "reduced conflict" classes take various strategies during the commit process to turn bitwise conflicts into logical successes. There is an arbitrary number of retries before the transaction service just gives up and fails the transaction. Then it is back in the app developers hands to figure out what to do.

This is not unlike the "fallacies of distributed programming" where some system attempts to hide failures that can arise through distribution. No, that illusion can always be broken somewhere and cannot be fully ignored.

Without the ability to reserve objects to the longer-running transaction (i.e. locking), it's hard to resolve such a one-sided conflict.

And that's another problem. Once this thing is implemented in software (and hardware), as Nat Pryce pointed out earlier, there is still the whole coordination thing.

All that said, STM still has composition properties that other shared-state techniques do not, and there are always going to be situations where shared state is most appropriate. I think it can be a useful technique where shared state is required, and transaction sizes would be modest and relatively consistent.

And at the end of the day I am not arguing against the mechanism per se so much as I am arguing against its widespread use. Although I do believe the number of appropriate uses is so small that 90 some percent of us should not even have to pay attention to it. My fear is this will: (1) draw attention away from getting the majority of us running on simple shared-nothing message passing systems, and (2) end up in the average programmer's toolkit as a shiny fob to get out and play with all the time.

Something that may help limit STM to those situations are its practical restrictions on non-transactional effects -- even if you're not in a language where you're forced into an STM monad, any non-transactional effects need to be idempotent because the transaction may be retried arbitrarily many times. (On the other hand, cue novice programmers wondering why the output from their giant transaction occasionally gets duplicated several times...)

Yeah. It's a slippery slope that is just way to shiny. We all get fascinated by it, end up on that slope, and before you know it, smelly messes everywhere. The alternatives are just so much more promising for the majority of cases.

It's Fiddly

"Mental" writes in a comment (i've started a new post) to my rant on transactional memory...

I was having fun implementing STM until I realized that I was able to implement the Actor model correctly in a few hours, versus several weeks for getting the fiddly aspects of STM down.

Good tag line... "Transactional Memory: It's Fiddly!!!"

Here's the entire comment because I like it...

Having written several implementations of both STM and various message-passing-based concurrency models for Ruby lately, I'm a lot less sunny on STM than I used to be even a few weeks ago.

I was having fun implementing STM until I realized that I was able to implement the Actor model correctly in a few hours, versus several weeks for getting the fiddly aspects of STM down.

The biggest immediate problem for STM is starvation -- a large transaction can just keep retrying, and I'm not sure there is a way to address that without breaking composability. ...and composability is the whole raison d'etre of STM in the first place.

Misguided: The Road Not To Be Travelled

Update:This is turning into a lot of work. Why did I start this?

Oh, I remember. Because this is a really bad feature that could screw up a lot of software for years to come.

Quote of the Day

...from Phil Dawes...

Blimey, that’s gonna cause a bit of a ruckus.

Wrong Programming Model

Not much love over at LtU. So LtU readers -- here's the gist of my diatribe -- the programming model is simply not needed and will lead to shared memory code at least as complex as the stuff we're writing today. Should everyone switch to Erlang? Well that is the general direction general purpose languages should go. Switching from today's monitors to transactional memory is not going to be a baby step either! It's a huge step. In the wrong direction. So, yeah, as long as we have to step this way or that way to get into a multiprocessor, multinode, concurrent world -- let's do step in a direction that is a good bit simpler than the one we're in today *and* far simpler than the one proposed by the transactional memory folks.

Meanwhile back at the comments...

Guillaume Germain, the author of Termite, a really nice Scheme-like, pretty much shared-nothing, concurrent programming system, comments...

I think STM has some very attractive aspects, most notably efficiency and composability. I see it as a better replacement for other low-level concurrency constructs, but not for large scale systems.

The efficiency of a mechanism may not translate into efficient *use* of the mechanism. As for composability, I think that could very well turn out to be an academic attribute. Is this something most programmers should be composing concurrent threads with? No. Absolutely not. Most programmers should not be using shared memory threads at all.

Then Guillaume comes to his senses, 8^)...

I have a few concerns about it...

The first concern is that I'm not sure how much the composability of STM will scale. If layers upon layers of transactions are built, I fear some dependencies between layers might start surfacing at upper levels, causing surprising conflicts. It could become hard to get it right. I can see misguided programmers starting to sprinkle their code with 'atomic' statements ("just in case"), a bit like one would do with 'yield' statements in a non-preemptive concurrent system. Also, 'atomic' statements could be forgotten, causing nasty bugs...

But my main concern with it is that after all, STM is still shared-state concurrency. It mixes together the control flows of programs in ways that can be hard to visualize and comprehend. Erlang doesn't have that problem, because every "connection point" of a process with the exterior is obvious and well-defined...

in the end, it seems to only solve a small part of the problem, and it doesn't really help with the actual design of concurrent systems.

rektide then comments...

the one thing i really like about STM is that good implementations are exactly like ZFS, copy on update

And hey, if you want to build a persistent file system, by all means the mechanisms in ZFS are neat. But does this automatically transfer over to main memory shared everything concurrent programming as a desired programming model for most applications? No way. I can't make that leap so easily. At all really.

And he writes...

currently, any place where data over time is relevant requires user implementation to store history, which usually means debugging tools and printf(). to me, history is just a series of transactional states, and being able to lookup old states seems like second nature. i would really like to see more Saga like transactions available in the mainstream.

And I am all for making the history of state available and first-class. Yet there are many ways to do this within a sequential process, not requiring main memory shared everything concurrent programming.

if you've got magic bullets for [distributed shared state], the world is always buying.

No. Avoid distributed shared state. That doesn't mean all concurrent, distributed problems go away. It just means they are that much more manageable. This shared everything transaction thingy makes the problem much worse than it has to be. I think the starry-eyed admirers see how hard shared memory monitor-based programming is. But that programming model should *never* have been admitted into the Java language to begin with. There are already better solutions than this proposed garble.

End

From the ACM Queue, "Multicore Programming With Transactional Memory"...

Transactional memory brings to mainstream... programming proven concurrency-control concepts used for decades by the database community... Under the hood, a combination of software and hardware must guarantee that concurrent transactions from multiple threads execute atomically and in isolation. The key mechanisms for a transactional memory system are data versioning and conflict detection.

By the way there are a few folks at Gemstone Systems who've done this far better than anyone else. They've been doing it for over two decades and it's in production in heavy use at financial institutions, factories, shipping, and so on. They've got it working in distributed shared, multi-user transactions with efficient distributed garbage collection. I pointed some researches that way. Not the ones in this paper.

That said, this would be the most tragic turn imaginable for programming in the 21st century. There is no way I would want to do this in the small on one machine or in the large in a Gemstone-like system. That is the wrong way to program concurrency for most systems.

Very wrong. And it is scaring me how shiny this thingy looks in so many people's eyes right now. I don't think it will be so long before this shows up in Java and C#.

Wrong, Wrong, Misguided, and So Wrong

We need to be headed primarily toward shared *nothing*. Sharing at the level prescribed in this paper, whether with locks or transactions, is simply uncalled for 99% of the time. Sequential processes with shared-nothing message passing should be the direction.

Get better isolation mechanisms for conceptually multiple JVMs and dotnet runtimes in a single OS process. Better yet, turn these systems into legacies and just move onto something better for future work.

You can hold me to this: transactional memory if turned out into the wild will turn out to be a *mess*.

Damien Katz writes in the comments (and since he agrees with me so well, I promote it here)...

I *completely* agree. Shared state threading is a hack built on to existing languages. A useful and fairly efficient one, but a hack nonetheless. And like raw pointers and unprotected memory, it's hard to justify it's use for most programming tasks. Compared to languages like Erlang, it's nearly impossible to justify it on efficiency or performance concerns.

Transaction memory is another hack bolted on to all the previous concurrency hacks, and somehow it's going to make all the other concurrency hacks to work reliably. Yeah right.

In another comment worth displaying up front, Dan Creswell expresses, well, let's have Dan's quote. It even deserves its own subtitles...

It's Deadly Shine'y

You're looking at premium car-wax, retina burning shine'y

I read the same article and it just frightened me. All that magic hidden under the covers, bleuch.

It's deadly shine'y because at the surface it appears like it just makes all the concurrency stuff such as locks "go away" in line with many a programmers desire to ignore such details. Couple that with the familiarity most have with transactions and you're looking at premium car-wax, retina burning shine'y.

I don't even want to imagine debugging one of these systems. You're going to be confronted with some strange behaviors due to transaction conflict or whatever and because it's all supposed to be done by magic under the covers wading in there to understand what's broken will be a nightmare. It'll make debugging from Java thread-dumps look like a holiday.

8^)

More comments. This is great.

Here's part of one from Nat Pryce...

Does software transactional memory support coordination? Or must that be supported by other primitives, such as semaphores or monitor condition variables?

From what I can tell you still have to build up from the basic transaction mechanism and the shared variables. But it is worse than that.

Most systems today should be ignorant of the "inside my OS process", "on my same node", and "on some other node". The benefits of that can be seen in Erlang, which Damien pointed out. This mechanism is still an "inside my OS process" mechanism.

Well, at the lowest level of runtime implementation of an OS process, you need some mechanisms like this. I would argue all the machinery, hard and soft, for transactions, is way overkill for that level of systems programming.

But to continue to have application programmers deal with this mess for the next umpteen years is nothing but ludicrous. As Damien also wrote, it's like continuing to have today's programmers deal with raw points and memory. No way -- very few programmers should be dealing with that level of complexity.

Nat also writes...

The interaction between distributed (and therefore concurrent) activities involves two things: data transfer and coordination. Synchronisation to avoid race conditions is just one form of coordination. Systems also need to coordinate activities that don't share data.

Yes, absolutely. Let's focus on the real problem for software development. Transactional memory is *not* it.

And now sigfpe (Dan Piponi?) writes...

it's nice to know that there are other people in the world having issues with STM.

Yes, now's the time to raise a ruckus.

And Cale Gibbard comes to the defense of the dang thing...

The major advantage of STM as a system is that it gives you certain guarantees about composability of already working systems. It's not magical, it doesn't always ensure that things will play nicely together, but it does give you far more guarantees about the correctness of compositions than previous systems have.

But Cale, there's not that much Haskell code out there yet anyway. Don't lets have the Haskell people start in with transactional memory just because there still trying to demonstrate they can do imperative programming better than the rest of us.

The world is getting ready for shared nothing, semi-functional programming. Get out of the backwater and catch up to your audience.

And if some group is going to retrofit transactional memory into some significant Java or C# system, well, they would be far better off investing that time into a simpler, shared-nothing rewrite into a language like Erlang, a simpler language like Smalltalk, or even a better shared-nothing coordination mechanism like Javaspaces.

All that low-level monitor-based garble? Just leave it will it is now. Walk away from it slowly. Turn your back, and run.

Cale again...

That being said, if you understand the additional compositionality guarantees, what exactly is it that you find lacking?

Em, simplicity? Em, elimination of totally unnecessary mechanisms too far removed from the domain problem?

And on...

Limiting shared state is obviously good -- there's nothing in this system which prevents that. However, it's a system for cleanly sharing any state which should be shared.

Yeah, right. People would abuse that mechanism all to bloody hell. If a relatively small group of programmers can develop the various soft real time Erlang systems we've seen over the last several years, there is no indication in my mind the effort required to implement and teach this transactional memory thingy would benefit anywhere near 90 some percent of programmers on this earth. No evidence whatsoever.

Other forms of communication, including those in Erlang still have this problem to deal with.

Yes, complex problems remain with implementing concurrent systems. But mechanisms like Erlang's raises them to a higher level, closer to the problem domain. This transactional memory is a false hope covering a bottomless pit that could have easily been walked around in the first place. Stay on the path.

Suppose you have a bank server with clients happily communicating deposits and withdrawals to it, and everything is working. How do clients implement a transfer between accounts safely?

First let's not turn every little data structure into a bank account transfer problem. That's just not the case. Second, these cases that really do exist should be well isolated and the mechanisms not put in every programmers' hands. Third, account transfers have been occurring quite a bit over the years without this new transactional main memory thingy. Why complicate everything for everybody, even if this were the best way to transfer funds???

Sorry, that is just a *really* unconvincing example.

Anyway, this is getting long and I probably can't do as good of a job of it as the paper can, so everyone please check it out before writing more gibberish about transactional memory.

Yep, read 'em. This is not the first time I've commented on it. Just now it seems like it is gaining momentum. The people writing the gibberish are those inventing these things without comprehending the damage it will do.

WS-DCOM

Tim Bray writes...

WS-*? In the real world, it’s about being able to interoperate with WCF, and while that’s a worthwhile thing, that’s all it’s about. It’s not like HTTP or TCP/IP, truly interoperable frameworks, it’s like DCOM; the piece of Windows’ network-facing surface that Microsoft would like you to code to. For now, anyhow; it’ll be at least as easy as DCOM to walk away from when the embarrassment gets too great.

Which is the way it should be, since SOAP essentially exists because DCOM was even worse.

TSS: Using Javaspaces

There is a so-so article on Javaspaces over at TSS but it has spawned a long, interesting thread of multiple topics. After undergoing a substantial signup process and clicking on the url in their email, TSS still refuses to allow me to participate. That sucks, but I'll just put my various responses here. Sites that create barriers to participate irk me.

Going down the comments, pulling out what catches my eye. Some of my responses are clarifications, some are educated guesses. Too bad these are not able to be in-line for others to correct.

"public fields"

The top level object written to a space implements Entry. Only the public fields are marshalled to/from the space. This strikes people as funny at first. Ken Arnold has a rationale. This is another of those things that should be in the core documentation.

First of all, the objects those public fields refer to have all their data serialized. (They implement Serializable.) This is only the top-level Entry that considers just public fields.

The analogy Ken gives is that an Entry's public fields are like the parameters to an asynchronous procedure call. Read his explanation. It works for me. This choice also ties into keeping things simple for the application developer and the space implementor. More elaborate choices bring more complexity.

"[spaces] works best when the problem is... 'data-centric'... as opposed to 'process-centric'"

I am not sure what this means. Spaces are good for distributed processes as well as data. An Entry and its referenced data is marshalled along with their codebase so that systems reading and taking them can use their code without it being on that system's classpath a priori. That is very powerful.

"Javaspaces is a poor model for building large-scale... non-holistic data-intensive compute work-loads"

Maybe. I don't know. What the heck does this even mean?

"I'm assuming that when you are altering something in a space, there's some sort of locking on it"

Nothing can be altered while in a space. Those things are not in a JVM per se. (Although a JVM may be used in the implementation.) Each public field is marshalled independently on a write, and then marshalled back into a JVM on a read or take. Object identity is not preserved. So if JVM #1 does a write and then a take of some Entry and its data, there is now the original Entry and data, plus a new deep copy of the Entry and data.

And so you can see clearly that a Javaspace is *not* a cache, and it is *not* an OODB for Java objects. It is something else altogether that can serve many purposes. The way to exclusively modify something is to take it, update it, and write (a copy of it) back to the space.

"what, if any, value JavaSpaces has vs. messaging"

I think if you want widespread, anonymous publish/subscribe of data across many disperate business processes, then something like JMS or AMQP is a good choice.

JavaSpaces can be used to implement pub/sub-like behavior but that is not its only, or even core, strength. Likewise a space can be used to implement queue-like structures with topics (i.e. the public fields of an Entry acting like topic information as well as payloads).

The big message is JavaSpaces can be used to more quickly create a wider variety of coordination conventions like sparse, distributed arrays of objects, hierarchies of objects, and so on. Moreover, those objects are marshalled with their *codebase* urls for other participants to load. JMS has no such capability to my knowledge.

There is less setup, and more options, e.g. a JavaSpace can look more like a simple database with a JVM doing the writing and taking of its own Entry instances.

"[JavaSpaces] guarantees persistent storage"

More accurately, I hope, a JavaSpace *leases* storage. Leases can expire, not be renewed, etc. So there is no guarantee of persistent storage forever, although in some cases this could be provided.

"How does Coherence relate to this"

I don't know that much about it, but it seems to me Coherence implements various forms of distributed, shared java.util.Map implementations. Based on the choice, more or less of the Map exists in the application JVM, and locks, etc. are used to updated entries more or less atomically.

A JavaSpace exists outside of any of the participating JVMs. Locks are used to get an Entry to/from a space, but there is no update in place at all. Neither are there key/value pairs. Just Entry instances with public fields.

"a Java only solution"

Yes, unless you go with Gigaspaces which has support for C/C++ and dotnet.

Or if you can take a "Java in the middle" position then the Jini parts of Jini/Javaspaces allow integration with other languages and protocols. But Java does have to show up in the middle of everything, and everything else is essentially second-class.

"why are relational databases so dominant?"

Query languages and long-lived support for static data that survives multiple generations of programming languages, etc. Not great, but they've been around for the better part of 30 years.

"no booleans, ints, or doubles"

True, the public fields of an Entry have to be Objects. An Entry is used to "query by example" in a very simple way, and null means "don't care" for that field.

This is not such a big deal, especially with Java 5 which has better support for mixing primitive types and their Object equivalents.

"What Gelernter envisioned..."

I think it is only fair to say that Tuple Spaces was an *influence* on JavaSpaces. I do not believe that the intention was to implement the strict definition of Linda.

"Croquet"

My understanding of Croquet and TeaTime is the intention is to keep shared objects in sync while allowing concurrent modifications among all the participants. A space is different in that participants may come and go, only one participant can update an object, and moreover the update only occurs on the *copy* that was read or taken from the space. When the update is written back, it will be a new thing, not an update.

"why is open source risk free"

I don't think it is risk free. It reduces some risks. e.g. it reduces the risk of having to update on a vendor's schedule. It also reduces the risk not deploying as many instances as desired, when desired, i.e. potential negative results of a combination of licensing structures (e.g. per CPU) and IT budgest (e.g. not wanting to license a lot of development and test environments, or more than a minimum number of production machines).

It is not just about source code. I've worked for vendors and have been a customer of vendors, where source code was part of escrow agreements... if something goes wrong, the code is in escrow and should become available to the customer.

Many commercial vendors such as Confluence (wiki) and Cincom Smalltalk, provide access to, even modification of, their source code within limits.

Rabbit, Run: RabbitMQ

In the too cool category, those LShift wizards come up with a doozy...

We’re proud to announce that the project we’ve been working on for the past few months, RabbitMQ, has been released. RabbitMQ is an AMQP server written using Erlang/OTP. Check it out at http://www.rabbitmq.com/ - or you can go straight to the downloads page for sources and binaries.

What a great combination: Erlang is perfect for scaling out, reliability, persistence, and so on. Plus with AMQP's binary message format and Erlang's bit pattern matching, another, em, match made in heaven.

This could end up kicking some enterprise ass. What's Iona going to use? C++? Java?

Here is the RabbitMQ Java API documentation. Erlang itself has good support for integration with Java and C.

Validating Dynamic Systems

Let's pull our heads out of our enterprisey IDEs, code generators, and J2EE containers. Consider this from Gregor Hohpe...

During our talk we mention an "advanced" technique that would not just render an image of the system model, but also examines the model and alerts the user about potential problems. It does so by applying known rules for "do's" and "don'ts" to the model. These rules could be as simple as "circles in your dependency graph are bad" or one of those sophisticated self-learning AI algorithms that we never quite understand...

One of the key messages we are trying to highlight during our talk is the importance of mapping the captured data to a model that is suited to answering the questions you are interested in. This model can be a graph, a process or any other abstract representation of your system. Making a model is important for a number of reasons...

Which reminds me I forgot to mention a few weeks ago, the second edition of Concurrency: State Models and Java Programs is available. This is a really nice book whether you are a Java programmer or not. Chances are you are using concurrency if not distribution, or will soon.

The second edition has more support for dynamic events and systems.

Not So Bad

Jim Washington compares Python implementations of JSON, including my now-quite-old json.py. It's slow relative to the fastest implementation, but the intent always was to have a fairly clear implementation without trickery or dependence on other modules.

Bugwise it holds up pretty well to Jim's tests. I've not worked on it since JSON adopted scientific notation, and so all those exceptions about finding an "e" when parsing a number.

There are a few other problems, but it holds up pretty well.

Discouraging Words

There are many things I like about Jini/Javaspaces, but as I wrote over on Dan Creswell's blog recently, the documentation...

...needs some work...

Hopefully the long time participants understand just how bad it is. It is discouragingly bad.

Especially for software that's been around for the better part of a decade. Do you want more Jini adoption? Get better documentation for it.

I hope to help. I currently need to build software for enterprise Java programmers, and this is some of the best stuff going.

Jabber and SOAP

I was just finding my way around the "new" blogger tools. Until now blogger could not upgrade my blog given all the old cruft I guess. That's been fixed and so I hope to find interesting features. I think it handles uploading better.

Aaaaaaaanyway.

I was poking around a big long list of drafts the new tool made easier to find. Then I went to my oldest posts and browsed around.

Here is one that is short and sweet from April 15, 2003...

A question: if you have Jabber, do you need SOAP?

That SOAP thing has really taken off since then, hasn't it.

Cruft

Steve Loughran notices there's some cruft in there...

On a related note, the JRE is full of unwanted legacy cruft like an inadequate CORBA runtime, AWT, etc. While something like an XML parser is ubiquitous and stable, choosing SOAP is itself a decision, and choosing Sun's SOAP stack over more popular alternatives is a serious decision. Hard coding Sun's client may seem like a good thing, but in fact just makes it that much harder to upgrade to JAX-WS 2.1

Whole Value

This piece on getters and setters by Allen Holub...

...is a reminder to use the Whole Value pattern if you have an object-oriented language.

Ward Cunningham observes...

I see people refuse to use the abstracting capability of their language and then say that objects don't really work that well. Grrrr.

PL/I

I saw this in the Programming Language News blog...

PL/I for GCC 0.0.14 has been released. It is a PL/I front-end for the GNU Compiler Collection.

I wonder who's using it for what. Which computers ran PL/I in the past? IBM had an implementation for mainframes. Maybe for other mid-range systems as well?

PL/I was the systems programming language for Data General's mini and supermini computers. That's where I used it. I understand this was not quite *all* of IBM's PL/I specification. The language is fairly large.

It is somewhat more attractive than COBOL from my limited experience with both languages. It was straightforwardly procedural and recursive, with a reasonable exception handling mechanism. I'm not sure why PL/I did not win out over COBOL, unless it was the shear momentum of COBOL before PL/I was ready.

Update

Doug Landauer adds some interesting history in the comments. I forgot about Gary Kildall and PL/M.

End

One More Thing

Dan Creswell writes...

the last thing to do is to extend the language

He's speaking about Java in particular but it could apply to all kinds of languages that were never intended for much extension.

Do you want extension? Use Lisp, or Ruby, or Smalltalk. They've proven themselves very well for extensions to one degree or another. Certainly Lisp.

Otherwise choose a reasonable language(s) and use them. Don't pile more stuff on them than they can bear.

Squeeze Box

Another piece on the squeezing of everything into a language and/or a runtime, neither of which were designed well enough to take them on. Keep trying, but this quickly is becoming such a very wrong path.

There's got to be a better way. In fact I know there is.

Just Because You Can

In a subsequent post to the one I mentioned below, Steve Loughran writes...

The only place SOAP survives is in the enterprise, because if you can control both ends of the conversation, you can use the same toolkit and eliminate interop. The key selling point of most SOAP stacks -reverse generation of WSDL from your classes- is actually viable in this context...

He goes on to provide his own hypothetical position statement if he were to attend the aforementioned "Oh Really?" conference...

1. How to provide a client programming model that accesses REST endpoints with the same ease of use as same-stack-SOAP-development?

2. How to integrate Atom feeds and APP into the enterprise as an alternate communications pattern; polling over posting?

3. What is the best programming paradigm for this. Ruby on Rails shows how a dynamic language with continuations and the ActiveRecord database binding makes server-side web development easy. What can we do with clients?

4. How to keep Web 2.0 style applications providing a back end 'service' architecture that meets the needs and business models of providers and consumers.

5. How best to transition legacy middleware -including SOAP systems- to the new world

So what is so great about #1 even within the enterprise? (I've not seen much evidence in a small number of data centers I've seen). There is always a community of IT people fascinated by shiny code generators. IDE support for SOAP is just that. There is no more "architecture" built around these code generators than the CASE tools of the past.

Still on #1, from what I've seen of the SOAP/WSDL approach to using HTTP is total ruin. HTTP is a dynamic, duck-typed approach to "messaging" (ok, "resource transfer" -- HTTP says some things about what's been transferred but that's independent of this point).

Figuring out how to place a code generator for a static language in between the HTTP client and server will likely just gum up the whole works. Better to figure out how to develop HTTP applications in various languages and libraries as simply and *dynamically* as possible.

Which leads to #2. There is a lot of room for HTTP and XMPP to develop in the enterprise. Meanwhile there are open source tools for using these and more API/language-centric tools for coordination/messaging in the enterprise. The real big key is to allow various parts of the enterprise to evolve independently. If the data center can generally be updated incrementally without unduly updating too many parts at once (unlikely from what I've seen), then incrementally moving HTTP and XMPP into the data center should not be such a big deal.

On the other hand if the data center is typical then there are all kinds of unnecessary dependencies preventing *anything* from evolving efficiently. This is the bigger problem that should be addressed first.

Number 3 is a doozy -- the browser has to come around to reality -- it is a *platform* for applications. Multiple, concurrent, independent, and secure applications. Unfortunately even under the best of conditions, the most modern browser is a half-assed piece of work. Coming to terms with that is crucial. Nothing proprietary though.

Dynamic coordination protocols still require contracts. They just aren't used for code generation. So #4 implies the need for contracts that support understanding and change, but clearly not WSDL that only pretends to be a contract.

Finally #5, the transition. See my response to #2. Ease of transition is the key any sort of data center sanity, which explains why the data center is so insane, nine times out of ten. Isolating crap like SOAP and ultimately removing it are steps toward sanity and successful transition.

The Oh Really? Conference: Or, I know a dead parrot when I see one

Steve Loughran lists some of the presentations at an upcoming "Web Services: Not Really. Oh Really?" conference. Look at the list.

The big SOAP boys are now admitting they f'd up big time.

Let's see how they try to make a dime off of HTTP and other really open and already proven and relatively simple technologies. Good luck with that.

That Sinking Feeling

Bill de hÓra writes about the umpteen billion dollars sunk into Vista...

more backseat driving - does anyone outside MSFT understand what it takes to get the OS done at all?

I don't think it is a matter of comprehending how difficult the work is. It is a matter of comprehending the value of doing that work. They are on the wrong track. There is little value in what they've done. The real losers will be those who will have no choice but to fork over big bucks to MSFT.

Far and away MSFT will recover its costs through "update-by-force" rather than "update-by-choice".

I would hate to have *that* as my customer base.

(Update: fixed broken link to Bill's post. Thanks James.)

None Too Soon

Don Box closely reflects my stance on JSON, Lisp, and XML...

JSON has actually eclipsed S-expressions for me as the most obvious way to structure data. JSON effectively gives into the lure of alists and commits to them in a pretty obvious way.

Also, in both JSON and S expressions, the concrete syntax is so trivial (and orthogonal to the model) that it doesn't really get in my way.

I can't say the same for XML.

Although he thinks more favorably about XML than I do. XML could not go away soon enough for me.

Surprisingly I do prefer JSON as an exchange format that Lisp (sexprs). For the reason Don gives above... it is very easy to see the alists and the arrays (true lists) in JSON than it is in Lisp.

So while I would dearly prefer to program in Lisp (Scheme) than any other language, I would want to exchange data via JSON.

Not a problem... in Common Lisp, Gambit Scheme, and several others, the neat thing to do is create the read-table syntax for JSON.

Late To The Table Again

Update:

The evidence this time has caused Microsoft to withdraw the patent over the last few days. The BlueJ Java people, who already credited Smalltalk, had been in recent contact with Microsoft prior to the application and were very upset about the patent application. Bad press was visibly having a negative affect.

Would that it were this way with the less direct instances of prior art. No kudos to Microsoft here -- this is a case of one's back to the wall and the spotlight shining down from the police helicopter -- you're about to be on a reality show.

End

James Robertson writes about another Microsoft patent application in the 21st century that consists of prior art from the 1990s if not earlier.

Here are some other candidates for prior art from what I can tell. (I can only read so much about Visual Studio and then I begin to lose my lunch.)

• The Smalltalk "diagramming debugger" is from the 1980s. Ironically the author, Ward Cunningham, worked for Microsoft for a few years.
• The Smalltalk "Object Explorer" is currently included as a goodie with VisualWorks Smalltalk I think. This is by Kent Beck and goes back to the same time frame when Ward and Kent were at Tektronix.

Maybe someone more at peace with Visual Studio can say whether these diagrams resemble what has been patented. (I am sure the newer tools have much more suckage.)

Diagramming Debugger

Object Explorer

Semantic Agnostics?

There's a comment over on James' blog stating a key part of the Microsoft patent may be it's "language semantics agnostic". Get over it. All the languages that can participate in this diagrammer have to share the dotnet object model and enough of the dotnet runtime to get the bits to the display. If that's not "semantics" then what is it? Well, it's actually pretty *bad* semantics to make all these languages use the same (pretty awful) object model.

Fighting The Good Fight

Fuzzy has a good idea: a site for bad software patents with the details, prior art, etc.

Cadence and Smalltalk, Sun and Cincom

So, what the heck is going on over at Cadence? They've hired the Smalltalk/StrongTalk/Java-HotSpot wizard from Sun (Gilad Bracha) and a couple of key Smalltalk folks from Cincom. One of whom (Eliot Miranda, at least) is like Bracha, a very knowledgeable person at the compiler/hotspot optimization level.

Visual Works has a pretty mature compiler/runtime, but that has to be a loss.

Sun is just getting started with dynamic languages on the JVM... that seems like more of a loss.

And Cadence is hiring more Smalltalkers.

Interesting. Cadence has been one of the leaders in computer-aided electronics design for 15+ years. Way back when they were one of the first to incorporate a dialect of Scheme into their design tools. That led to or was closely associated with EDIF, the Electronic Design Interchange Format, based on Scheme/Lisp syntax. (Way better than today's XML, but... another day.)

Monothickic

The Pragmatic Dan Creswell (Dictator?) writes...

Java is getting heavyweight...

Java is designed to be dynamically extensible not monolithic and static as is the prevailing pattern pursued by Sun’s JDK development team and the world of J2EE. Remember, Java in it’s early days was all about code-downloading and dynamic extension...

To Schwarz, Sun and the Java masses, stop leading Java down the path of static, ever-larger, monolithic bloatware.

It's Mainframey!