It's Like Déjà Vu All Over Again
"You could probably waste an entire day on the preceding links alone. But why take chances? We also give you Paul Snively..." — John Wiseman, lemonodor
In what is likely to be an unsurprising announcement for many, Bungie.net will close its doors to players of Myth II: Soulblighter on February 15th. This will mark the end of Bungie's involvement with the game, though they have decided to release the server source code to the general public. Though slightly modified to remove some proprietary code, the source will enable anyone with the drive to set up their own servers for players.
Developers of intelligent applications face a problem today, since
none of the currently ``healthy'' languages such as C++ or Java
provide adequate environments to support symbolic programming tasks.
While Common-Lisp would probably still be the best language choice for
many of these tasks, its dwindling vendor support and user base make
it more and more difficult to justify its use.
When we embarked on the task of developing PowerLoom which had
to be delivered in C++, we were faced with exactly this problem. Our
response was to invent a new programming language, called STELLA, that
incorporates those aspects of Common Lisp that we deemed essential
into a language that can still be translated into efficient, conventional
and readable C++ and Java code.
Overview
STELLA is a strongly typed, object-oriented, Lisp-like language,
designed to facilitate symbolic programming tasks in artificial
intelligence applications. STELLA preserves those features of Common
Lisp deemed essential for symbolic programming such as built-in
support for dynamic data structures, heterogeneous collections,
first-class symbols, powerful iteration constructs, name spaces, an
object-oriented type system with a meta-object protocol, exception
handling, and language extensibility through macros, but without
compromising execution speed, interoperability with non-STELLA
programs, and platform independence. STELLA programs are translated
into a target language such as C++, Common Lisp, or Java, and then
compiled with the native target language compiler to generate
executable code. The language constructs of STELLA are restricted to
those that can be translated directly into native constructs of the
intended target languages, thus enabling the generation of highly
efficient as well as readable code.
Wow! This is amazingly hot stuff! What Robert MacGregor and team have realized is that you can enjoy the benefits of a dynamic development environment (in this case, a good Common Lisp environment such as Macintosh Common Lisp) with respect to rapid development, but then easily and efficiently deploy in the two most popular mainstream languages. And they've eaten their own dogfood by using the language to develop a large, extremely complex system, namely PowerLoom. Awesome!
9:57:56 AM
Although Roger Session's reasoning sometimes escapes me, I have never been a big fan of J2EE's EJB. Tim Hyde's email (first link above) hits the nail right on the head.
One gap is that Tim's mail fails to mention JMS, which is one of the brighter spots in J2EE. It also receives the least amount of attention for some reason. I like the SwiftMQ implementation, which, like standard GLUE, is, amazingly, free. SwitMQ reminds me a little bit of Jabber.
I can't say enough good things about SwiftMQ. I had been hearing about the wondrous benefits of Message-Oriented Middleware for years, but it was always described in terms that could only be called "magical:" your messages always get queued, always get delivered, only get delivered once, etc. Oh, and the messaging system is like the mailman: neither rain nor sleet nor dead of night, etc. But most messaging systems I've seen just sit on top of a standard relational database, with everything that implies in terms of fault-tolerance, fail-over, discoverability, etc. SwiftMQ gets a lot closer to being magic by using a reliable IP multicast protocol among a group of federated message routers, none of which needs a costly database license behind it. They also provide a JNDI implementation that uses that same IP multicast protocol, so with a little aliasing, client fail-over becomes automatic as well. And since the current release is free of charge, it's very inexpensive to build a high-availability JMS system around SwiftMQ: it costs as much as the hardware costs. So it's true that JMS is the often-overlooked crown jewel of J2EE.
I wrote this about EJB a couple of years ago...
What I believe is immature and, moreover, largely unnecessary for many applications is the concept of Entity Beans in EJB. The cases where they work OK in current servers don't seem to be the cases where they are much of an advantage, i.e. the simple cases. Beyond that it seems to me you begin to lock yourself into vendor-specific solutions in order to get them to work well, or to work at all.
It just seemed to me that the part of EJB that worked well at all essentially overlapped what servlets do, and now SOAP and XML-RPC.
I continued with this to say about EJB's emphasis on declarative transactions and two-phase commits...
The two-phase protocol itself is well understood, but not well supported, and not typically supported nearly as efficiently as using a single resource's transaction mechanism directly such as an RDBMS'. Most applications just use one resource, or *could* use one resource in a pinch.
I would say that Patrick is correct here, and beg anyone who has an interest to check out Resin-EJB from Caucho Technologies. They concentrate on CMP first, and distribution only if you want or need it. And they have a couple of excellent lightweight RPC protocols in case you do need to go distributed. Check 'em out!
I was able to review drafts of EJB from the very beginning. It was curiously funny to see the wide swings in features being described from version to version before 1.0. It seemed doomed to me from the start because its purpose was to serve as Sun's wedgie to Microsoft. The people involved had good intentions, but standards should evolve from proven practices that address a specific problem.
I think the people creating the EJB standards thought they were doing exactly that, and I think a lot of good actually has come out of the process (JNDI, JMS, JMX, JSSE, JAAS...) And I even think that EJB can be good, but you have to approach it a bit upside down (CMP first, distribution later) to really reap the benefits, and it helps if your app server takes the same inverted approach (so don't use WebLogic, WebSphere, etc.)
The discussions about static vs. dynamic typing re: SOAP/WSDL are ironic for those of us who witnessed (or even participated in) the establishment of CORBA about ten years ago.
The proposals for what became CORBA were whittled down to two:
The HP/Sun proposal, which was statically typed with an IDL.
The Digital/Hyperdesk proposal, which was dynamically typed.
The result was a combination of the two.
It's worth pointing out that what this boiled down to was the C culture of HP/Sun vs. the Lisp culture of Digital/Hyperdesk.
Years later, mature CORBA ORBs were available. Usually they supported at least the static IDL aspects. The dynamic aspects were not always recognized as valuable.
The argument that I always heard was that supporting DSI, DII, and DynAny would make the ORB radically less efficient. Which is, of course, a crock.
The Smalltalk ORBs that were available (and dynamic) required a fraction of the code and effort of the C++ ORBs (which were primarily static).
Sure; it's always convenient not to have to say so much; "a word to the wise is sufficient." And there is, let's admit, some trade-off in runtime performance. But Lisp and Smalltalk have had some 25 years to address those issues, and have done so extremely well.
Perhaps CORBA would be alive and well today if the OMG has emphasized the dynamic aspects more. Maybe the same could be said for EJB.
Ah, but Patrick, no matter how much you may dislike EJB, it in fact is alive and well in the marketplace. And if you want an EJB implementation that isn't an unwieldy mess, once again, I recommend Resin-EJB from Caucho Technologies. Their EJB container is implemented as a servlet, is very simple to configure and deploy, and focuses on Container Managed Persistence first (which I would argue is EJB 2.0's big win) and distribution only if and when you need it. And they prefer a simple XML wire format for distribution rather than either IIOP or RMI. Excellent stuff, as always.
9:32:37 AM
STELLA 3.1
now available for 