UniVerse and Python - it's here!
Some months back I wrote in Spectrum about Rocket's plans for introducing Python into UniVerse and UniData. Well, the wait is over because the release of UniVerse 11.3.1 — according to some at Rocket the biggest release they have ever done — is here.
So first off — a big 'well done' for getting it out the door.
I know I'm often critical of the product — I carp because I care — so it's great have the chance to give praise where it's due. 11.3 is a milestone release and one that promises interesting times ahead.
Whilst there are other changes, it's the introduction of Python that stands out. Not merely as a client language but as a fully-fledged server language sitting alongside UniBasic. This is a huge step forward not just for Rocket but for MultiValue in general.
Why Python Matters
We have not seen a new language adopted server side — well, not since Dick Pick added mvBasic all those years ago. Some brave souls may have embraced RPL (whose history predates Basic) or ALL in the old days. We have had 4GLs and domain specific languages galore — including my own, of course, in the shape of the mvTest, mvScript and mvStudio products.
We have seen massive improvements to the core mvBASIC language, including extension libraries and syntactic improvements like the object orientation and JSON objects on QM. There have been link-ups like the way jBase can import C functions directly into its cross-compiled variant. And of course the language itself is no more BASIC than VB.NET — we've just been stuck with that name and the negative connotations that surround it. Given how eagerly the vendors have always gone out of their way to rename everything has also increased confusion (PROC to ProVerb, ACCESS to AQL, ENGLISH, INFORM, RetrieVe, UniQuery or jQL) it's amazing that in all that time they haven't renamed the one thing that really needed it!
But a fundamental addition of a new language is a different ball game.
Those of us who work with UniBasic, especially in its UniVerse dialect and with knowledge of other languages, appreciate the clarity and intelligibility it can bring to a business process. Much easier to follow through a well written UniVerse routine than navigate the spaghetti mess of several dozen java classes (why does java never use one class where it could possibly spawn twenty?). Most business processes are essentially linear, and that suits a clear and simple procedural language.
Why then, after all these years, do we need a new language? The answer is simple — recruitment.
Why Python Really Matters
Just last week I was in a meeting with a client whose critical UniVerse application is under threat from senior management . It's a depressingly familiar story — the system must go, not because it fails to meet the needs of the users but because it is an alien technology in their business, not understood by the consultants they increasingly use to outsource and because the have a problem finding and retaining skilled UniVerse developers. The fact that it has, like so many MultiValue systems, been starved of resources for years whilst keeping the business running on a shoestring with only one dedicated chap looking after it, has eluded them. As has the prospect of training up new developers to understand it.
So today we are drafting our response, pointing out all the usual stuff. No, UniVerse is not a legacy technology and is not older than the 'modern' SQL Server you're proposing to replace it (though it may look it, you do realize that "new" system is just Sybase with a pretty front end - you've heard of NoSQL haven't you?) and no, it's not going to disappear next year because you've never heard of the supplier and yes, there are places you can go if it ever did, and yes, the application is old because you haven't funded it responsibly but it will work with a shiny new .NET front end. And we agree, per-user licencing is expensive and archaic in today's world but those licences have already been paid for.
Oh and by the way, your expectations for re-coding it all on SQL are wildly optimistic.
We've seen this all before.
So the technical arguments we know.
But the risk from under-staffing is a real one and ever present. Yes, we understand that your standard recruitment agencies don't have a clue what MultiValue is and so they can't find you new people, but you should know what there are specialist agencies who probably can. But it's still seems to be so much easier, in business minds, to spend a few million rewriting a system in "mainstream technology" than a few thousand training up new developers to understand this one.
But now, there is a new and powerful argument.
Today you can hire Python programmers off the street and, with the knowledge of a simple API and guidance from senior people who do understand UniVerse and the application, put them to work writing UniVerse server code. It really is that simple.
From a perception point of view, this is massive.
'Why would I want to learn BASIC, that's a hobby language (thanks, Microsoft) not for professionals. It's a dead end. If I learn it will I ever get another job?'
Python does not have that legacy. It is used everywhere — from embedded applications on boards such as the Raspberry Pi to large scale websites. It is easy to learn but not frowned upon. And it has a huge and enthusiastic following.
Getting to Grips
When Rocket first announced Python support, my initial reaction was the same as I hear from other people since — why not JavaScript, isn't that the language of the moment? But Python has integrated well and who knows, perhaps having made this leap, (Rocket are you listening) JavaScript may be an option in future. Or perhaps the hip young things wouldn't be seen using JavaScript on a server (except Node.js, which has inexplicably made itself cool).
If you've not used Python before it is weird and will trip you up, but it is easy to learn and there is a huge wealth of materials out there for both beginners and experienced programmers looking to add it to their repertoire.
It is structured, and whilst I appreciate good UniBasic code, it is probably harder to write bad code in Python than it is in UniBasic. At the least, anything written in it will be a fresh start, so no excuses.
Python routines are written in regular files and run using the RUNPY command:
RUNPY filename itemname
There is no catalog equivalent, though that would be nice to see, as would the ability to call a Python function directly from UniObjects. Right now you would have to shim that through a UniBasic subroutine to make the call. UniBasic has been extended to integrate directly with Python.
And nice to see, Rocket has introduced some videos to explain these new features.
The most important thing to note is that this is not a bolted-on client language. The Python integration, whilst presented through UniObjects-like semantics, is in the same memory space. This is important as it means the performance is roughly on a par with UniBasic for such operations as file i/o. The performance tests I have run so far indicate that whilst there is an overhead — as one would expect — it is well within the tolerable range to make this a suitable language for writing server routines. The exact numbers will of course vary with platform specifics, but expect around 25% on a file operation compared to UniBasic. That's actually pretty good going.
To put this in context, just from my laptop:
Writing, reading and deleting 10 x 10,000 items took UniBasic 2.9 seconds, Python 3.8 seconds.
Just for fun, doing the same in PROC took 6 seconds.
I'll be blogging more about this, and the other 11.3 features, over the coming days but for now, grab hold of 11.3 and have a play.
