ooRexx 4.0 update

The good news is that the Hursley Symposium will take place as planned. The even better news is that it looks like a release of ooRexx 4.0 is going to be ready for the symposium. There is one showstopper still in the Mac version, which is in PULL from the console. This code has been rewritten in its entirety and now sends one of the cpu's sky-high without any further action. I guess it is not recognizing eol - but it is in need of serious debugging. The Symposium, which celebrates 30 years of Rexx, is announced on www.rexxla.org. You should all go!

NetRexx and Open Object Rexx news

Just in time to announce two great developments in the world of Rexx: NetRexx is in the open source process within IBM, and Open Object Rexx 4.0.0 is scheduled to be released not long from now.

For NetRexx this is great news, because the JVM language that was ahead of its time should be able to keep up with new developments, at least annotations, and maybe some more dynamic behaviour than the JVM allowed some 12 years ago.

Open Object Rexx 4.0.0 will solve the long standing shared memory problem (by elimination of shared memory requirements). This is good news because it will make a proper install of ooRexx on the Mac a lot easier. There is a nagging problem with the reading of shell input that needs debugging.

I also have a problem with the 64 bit PPC build: now the 64 bit Rexx interpreter is finally here, my G5 is no more. It fell over after I came back from the US last year, with unclear freezes probably caused by the aging water cooling. Now there is an eight core Xeon MacPro, but that is only good for an Intel 64 bit compile - unless I find how to do a cross compile.

PPC ooRexx

Safari is newer and better and finally supports the Google blogger control, so now I can write in bold and italic without switching to Firefox. The Intel port of ooRexx 3.1.2 is available some time already now; the PowerPC version is late due to the fact that I was not at home for more than two months now (and the PPC resides there).

3.2 has a new problem with BSF - we will be so happy when 4.0 comes out without shared memory for IPC and maybe the new Java 1.6 scripting support built in.

ooRexx 3.1.2

Another year, another Rexx release. Busy with the preparations for 2 (two) presentations at the annual Rexx Language Association Symposium, this year in Tampa, Florida ( http://www.rexxla.org ).

The Mac builds of Open Object Rexx 3.1.2 are going smoothly, as is the testing, and the only lingering problem is that BSF4Rexx fails in an obscure way. Yesterday I added the -e switch to startup the interpreter with a command line script, this was needed in order to integrate ooRexx with the Automator application that is standard on MacOSX Tiger.

I also was experimenting with bridging Applescripts to ooRexx, and had some fun with the Skype API. Finally I can know who are my Friends with a simple API call.

The Automator is a very funny program, allowing you to piece together a workflow (of things to automate) using prefab blocks of functionality with pipes and filters, passing data either through stdin or using command line arguments. Very much like a space age version of VM Pipelines. Polishing in between stages can be done using scripts (be it shell, perl, php, python or ruby - and since yesterday also ooRexx). This is not yet in the release version, but if you really cannot wait, contact me with the react button.

Why I truly, honestly dislike Hibernate

It was such a promise and of course such a letdown. Model driven approach, forward engineer your Java classes, have Hibernate persist them to rdbms behind the scenes. It was the single greatest risk of the project.

First it took ages to incorporate into the generator some of the history and many to many options. Straightforward dog house style classes are easy, the rest requires serious investing in time. So we lost a quarter on that, trying to get it right - and not the smallest minds, but a combination of dbms aces and math majors.

Then - we could not delete objects. Just. Could not delete. Some spooky discord between lazy instantiation and session handling. Some things were not committed. Some things were not really multiuser, and the system balked at having two people working at the same time on an admin screen.

We had it investigated, some of those very highly paid highly focused nerds. It came out our session handling was 'all wrong.' Where you normally, the last 20 years I am in rdbms at least, open a session, have transactions and close it (or have it closed by the OS) when you are done, this thing refused to commit. And had a singleton session object, that forgot about your work when someone else used it. Brrr. So we had a very traumatic rewrite of session handling - ah yes, and the consultant deemed Hibernate2 so bad that we had to fall forward to Hibernate3.

The rewrite literally yielded hundreds of bugs. Simple select from things failed, and the session.iterate calls from their own Hibernate2 manuals were deprecated - it was laughable to use them, they did a select for every row. Presented in a way like we were stupid, only, we were not, because it was all in their own samples and nobody told us about the depth of this stupidity - in their own docs.

Now switched to a default of all lazy instantiation (and yes, the statements from a moderately deep inheritance hierarchy already ran out of DB2's JDBC statement buffer), we had to change SQL Query syntax to very unnatural select from StaffMember left join fetch HisName left join fetch HerSocialSecurityNumber etc. Otherwise you get Null Pointers.

So they managed to change query semantics so that everybody that knows his SQL is a total beginner again and has to adapt to funny quirks. So enough. Out with it. It is the emperors new clothes. Let it sleep.

Now the sad part of it is that in the years before this happened, we had written our own O/R layer, that, erm ... just worked. It was people that did not trust this beautiful small piece of technology that suggested using Hibernate for the big, important project. We thought by giving in, they would help us building the system. They did not. Darn them to Heck. Let them forever Hibernate.

The Workers Movement - Rexx users

Of course I keep my eye on other languages - Java, because its widespread use and excellent VM and Library, Prolog, because it is mighty interesting and lately Ruby, JRuby to be precise. We have seen the enormous inroads Ruby made, and it made me wonder why Object Rexx is not nearly as popular. (Not that I do not know. It is a rethorical wonder).

It is easy to blame IBM, especially because it probably is the guilty party in this. I like some things in Ruby, because they are done in a straightforward, totally consistent way, and I don't mean the Perl-isms that linger. Rexx deserves a clean up with deprecation of old stuff - in the teaching materials at least. Falling through procedures without an exit, 'expose', stem variables. Most of it is done, and we have to take care of a very large installed base. Of which todays vocal programming youth does not know anything.

I failed to see Ruby emerging the way it did, thinking it was a slow, slightly more OO variant of Python, which I sincerely dislike, even coming out of Amsterdam - it must be the indentation levels thing, reminding me of COBOL A-margin and B-Margin, being the last time that I struggled with whitespace, twenty years ago., before Python came around.

Ruby has got a great community and some visible protagonists, like Martin Fowler and Bruce Tate. And Tim Bray. I am afraid the Rexx community does not have this visible array of foremen; we are stronger in the department of system programmers and administrators that were not actually allowed to write applications but did thanks to Rexx. And people of the world, most of your payments go through with some Rexx application, transformation or maintenance program to thank for. We, the Rexx community, are a force of thousands, but thousands that do their work quietly and unnoticed.

The sad thing is that we had most of the things the community opinion leaders of Ruby like in Ruby, in Rexx, NetRexx and ooRexx, years ago.

IBM botched a lot. Moving development, losing some five years in the gestation of Open Object Rexx, charging for it to people. Coupling its name to OS/2 which it hated itself, being bred on very misguided MS cooperative principles - and then letting it drown, ruining its reputation in the process. IBM also saved it by Open Sourcing it in 2004.

We have to publish. Books and Articles. That do not say 'unknown, underrated.' But proud and showing off really advanced working stuff. Unlimited Numeric Precision, Correct handling of decimal numbers, Trace, Parse. Macro support for applications. Metaprogramming, meta classes, builtin Concurrency. At the same time there must be things added to keep up with the times. You would be amazed how many very important systems run on Rexx. Most of which we are not allowed to talk about. Drat.

Integrate Rexx dialects through BSF4Rexx

It's no secret that I would like to see the various dialects of Rexx converge. Object Rexx has done a marvelous job of being backward compatible with Classic Rexx; NetRexx has done wonders for integrating Rexx and Java by making Java classes out of Rexx, and BSF can integrate interpreted Rexx with Java very well. All can integrate with other code by means of external function libraries or JNI.

Unfortunately and unavoidably, there are some differences in syntax between the different dialects. No big problem, but awkward to explain to newcomers and good for the occasional 2 seconds of astonishment. So in NetRexx the method call is by dot (Datum.getDayOfWeek()), and in Object Rexx it is the famous twiddle, as in Datum~getDayOfWeek. As a consequence, NetRexx does not have Classic Rexx's stem notation, a kind of easy multidimensional and possibly associative array.

Now if we would forego the stem, we could have the dot notation for method invocation in Open Object Rexx, like in every other modern language, but it is probably not to be. I suggested this on the last Rexx Language Association Symposium in Austin, but the points of view seem deeply entrenched.

A recent very positive development is that on my suggestion BSF4Rexx now contains integration for calling NetRexx classes from Rexx without having to instantiate an extra NetRexx object - it will consider a NetRexx string a Rexx string and vice versa. Together with another fix for the handling of exceptions from Java in signal on syntax labels, we should be so very happy that our Rexx and NetRexx can at least seamlessly interface using BSF4Rexx.