Gack, Grady...

...it *is* the 21st century you know. This...

I failed to use Rational's own tools (Purify in this case) and I had a memory leak in my application server. The solution was to reboot that server, which brought the doorbell back to life.

I mean, if you're going to implement your *doorbell* with a network and an application server, at least use some software that doesn't break so easily.

Just Wondering

Mark Watson wonders...

What ever happened to basic old fashion American values that I would summarize as "take what you need and leave something for other people"

Please remind me. Which period in American history did we exhibit this value?

Lisp, Smalltalk, and

Alex Peake writes in a comment...

I would love to use Franz Allegro or Cincom Smalltalk in all their maturity. On the other hand, if I have to write my own infrastructure and GUI components, I will never finish the "real" project.

What do you do in Franz and Cincom for the Infragistics GUI components, ActiveData reporting, GoDiagram...? What do you do for .NET Remoting, Declarative Transactions, MessageQueue, Declarative Code Access and User Security (based on Windows Login)...?

So I'll open this up for others to respond. Generally, these vendors (e.g. Franz and Cincom) have to provide connections to Java and dotnet at least as easily as they did for C. Given these systems are run-time typed, reflective, and garbage collected, the implementations should be easier.

Franz has a set of tools for Java, and so I would expect something similar for dotnet. Cincom has an preliminary interface for dotnet, with a more complete (events, etc.) interface in a few weeks. I guess for Java, Cincom Smalltalk would use the JNI.

Specific capabilities are probably hit-or-miss. Cincom supports an MQ-Series interface apparently. I guess the question for someone in a situation like this would be does the use of some specific product outweigh the benefit of building the majority of a product in a more productive environment? And what the cost is for creating a specific interface to that product from the ground up.

More Problems with Rigid Languages

This from people trying the new Java 1.5 language changes...

And generics: "In a nutshell, I have this to say about Java generics: my code feels more robust, but it's harder to read."

Also an interview with one of the authors of Hibernate: "Well, we are a bit stuck. We can't use many of the new features, because Hibernate needs to stay source-level compatible with older JDKs. The annotations stuff is okay, because we can provide it as an add-on package.

Too bad the language is not simple enough to accomodate change, especially backward compatible change. Agile languages win again.

Update: A question in the comments asks how this is different from Python. My answer is "not much different". Python is a mixed beast when it comes to extension. Here's why...

The big problem is that these changes occur at all.

In Lisp, the core language (e.g. Common Lisp or Scheme) does not have to change much. Change is facilitated by making syntax extension a part of the language. And the core is expressive enough to ward off the need to change.

Smalltalk does not have the same syntax extension, but again is simple, expressive, and mature so that the existing message sending paradigm can be used to define new forms of control.

I am not sure why Python is changing or needs to. But the core language is more limited than Lisp or Smalltalk in the sense that it is "C"-like and distinguishes significantly between function calls, operators, and control structures.

A more uniform language would not have as many of these backward-compatibility issues. This is the main issue I have with Python... it's syntax is OK, but not great for extension.