So what languages are the hip young developers writing in today?
Not so incidentally, this makes Rocket's recent announcements that their U2 products will be adding support for one of those languages - Python - all the more interesting.
Of course, nothing is new in IT. Right now, dynamic is hot. Currently, dynamic languages are very much the in thing , with two hairy old contenders - Ruby and Python - leading the field. These languages are made for an impatient generation who want quick and easy results. They are blessed with the horsepower to deliver to those who are not easily wooed by the cleverness of a short and cryptic C function. And that is not a bad thing, since focusing on delivery is something that should strike a chord with many readers of this magazine - it is, after all, a chief benefit of our own technology niche.
Python is mature , having first been designed in the 1980s, and open since 1991. It has hooks which allow you to extend it using C, as well as hooks to bind it into other environments. Iron Python, the version for .NET using DLR, increased its popularity with another, more skeptical, group of programmers and did much to inject new excitement around it as a scripting language. Because it is a dynamic, untyped language, it should work well with the vicissitudes of MultiValue data. The large number of extension libraries (or 'modules') bring a wide range of new functionality to the table.
But do we need it? Surely the existing languages have stood the test of time, haven't they?
Python Does Not Have GOTO
Consider UniBasic. Now I'm the first to expound on its advantages as a simple, clean way to express clear business intention. In the server world, clarity is king - especially when supporting the latest arbitrary business changes foisted on developers with few resources and fewer hours. But UniBasic has a problem - several problems in fact - that makes it a hard sell.
The first problem lies in the name. The only thing we can all agree about - whether we use UniBasic, UniVerse Basic, PICK Basic, DATA/BASIC, mvBasic or whatever - is that it has the word 'Basic' in it. That's not a selling point: you only have to look at the way Microsoft pitches its two .NET languages, VB.NET vs. C#, to see the problem. VB.NET (the BASIC one) is a language for hobbyists; C# is a language for professionals, even though what can be achieved is 99% the same. They pretty much compile to the same code.
Having a well known and loved language may well prove more attractive. That must be Rocket's hope. They know their customers need to attract new programmers.
Then, even for those who wish to use mvBASIC, there are problems of implementation when using the various flavors. There's no unified standard: not only does the name differ between platforms, but, while I can write robust software for any one flavor, it is impossible to write anything, outside of the simplest CRUD style application, in a portable fashion. That is understandable, to an extent, between competing manufacturers. It makes no sense when multiple platforms are all owned by a single vendor. Writing for UniVerse, UniData and D3 as I do, the differences are a constant — unnecessary — overhead when it comes to releasing code. I wonder how hard it would really have been for Rocket to harmonize the language into a super-set that worked across at least the two U2 platforms, even if they held D3 aside. Implementing Python uniformly is an alternative to unifying mvBASIC.
Finally, we come to the question of inherited code. It is possible to write beautiful, clean, modern, well structured, legible, fully tested, high quality, highly supportable and effective code in any flavor of mvBasic. But if mvBasic (or whatever you want to call it) has a bad reputation, it is primarily for a galling reason: It allows for the creation of some truly terrible code. Python gives us a reason to rewrite things instead of pouring even more badly-formed, ugly-looking hacks into the Charybdis of a legacy base.
The irony is of course, that in a very real sense, Python is the new BASIC. Beginners' All-purpose Symbolic Instruction Code - BASIC - was conceived as a language for teaching programming to non-technical students. Today, Python inhabits this same niche. The shelves at Amazon and other bookstores are full of works with titles such as Python for Complete Noobs Who Have Never Seen A Computer Let Alone Programmed One and Learn Python In Even Less Time Than That Other Book Promises. Raspberry Pi focuses on Python. Next year, England will become the first country in the world to mandate the teaching of programming to children from the age of five. Python is being touted as a possible choice for primary schools. Hackers are rumored to prefer Python for real-time attacks. Are we swapping one dirty hobby language for another?
What Is Python Good For?
Python certainly has many features that will be familiar to MultiValue programmers and to those who support MultiValue applications. It is compiled into intermediate byte-code and interpreted by a cross-platform virtual machine, just like mvBasic, with garbage collection and reference typing. Variables do not need to be declared before use because it has dynamic variable typing. And more subtle things that speak well to MultiValue integration: strings can be single or double quoted, Boolean values are zero (false) or non-zero (true). That matches the way MultiValue databases work, unlike the more common 'true is -1 and 1 is false' other languages use.
Python is designed for rapid development and scripting. It is designed to produce highly legible code. Python aims squarely at the same people who historically would have been users of other non-technical languages (in the strict sense): business owners and rule makers. Its mantras, as set out by Tim Peters in The Zen of Python (PEP_20) <intl-spectrum.com/s/19z4F> , should strike a cord with MultiValue developers:
- Beautiful is better than ugly.
- Explicit is better than implicit.
- Simple is better than complex.
- Complex is better than complicated.
- Flat is better than nested.
- Sparse is better than dense.
- Readability counts.
Python has very good documentation and tutorials. It runs on Windows, OSX and UNIX. And it's named after Monty Python's Flying Circus. What more could you want?
A MultiValue developer, wanting to try their hand at Python, will find as many differences as there are similarities. Some of these are subtle. For example, strings are immutable as they are in C#, so any changes to a string must create a new copy. Also, strings and array types, such as lists, are indexed from zero. And most programmers are, at least anecdotally, accustomed to the strangest feature of Python: the use of indentation for statement blocks. Never ever reformat a Python script!
There are other things which are, possibly, more welcome. Python has simple object orientation, with classes that bind together both functions and locally defined data. Python does it without the more formal aspects of other OO languages. There are no private methods, for example, and all methods are essentially class methods. Named arguments provide more flexibility in method calling, though they can be difficult to get your head around at first. Namespaces are used liberally to import functionality from other modules, leading to easy-to-follow and easy-to-extend scripts. But its biggest strength lies in the huge library of packages that can extend it. There are, as of the time of writing, nearly 50,000 packages on the Python Package Index < intl-spectrum.com/s/19z81>. They cover everything from web communications to unit testing to image handling.
And it has a style guide: PEP 8 <intl-spectrum.com/s/19z6t/>.
Ministry of Funny Walks
So Python is well-liked, extensible, and an easy step for existing developers versed in MultiValue development. Is that enough to extend the appeal of U2 to a new generation?
In my opinion Python is a safe bet. And, if the integration is done well, the same hooks could be used to accommodate other languages in the future. Rocket has worked hard to pack functionality into their databases. They have targeted the front end through an ever-broadening raft of interfacing technologies and APIs. However, Rocket has been more reticent in their approach to the fundamental elements of the languages.
Their version of local functions, released last year, preferred legacy over innovation. While adding support for JSON style objects (UDOs) was a great step, it was marred by hiding it behind an ugly and obfuscating set of function calls rather than making it a first-class part of the language. They have never added the sort of object-oriented BASIC extensions found in OpenQM. Set against such a conservative background, in a conservative industry, any radical enhancement to our programming options should be applauded. The chance to bring in a new language, any new language, is a good thing.
The integration of Python with U2 is an interesting concept, and one that works both ways. Python developers (and therefore, Rocket customers hiring Python developers) get the ability to call into the U2 databases, execute subroutines and commands, and generally interact with the database in a sensible fashion. MultiValue developers get the ability to call out to Python from within their applications in a way which allows them use all the features of the extensive Python package library. Even if nobody is about to re-code their cherished applications in Python tomorrow, it is a good move that gives U2 sites a lot of benefits for free.
And maybe, for once, we can hang out with the cool kids.