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.