What Should I Learn Next? - JavaScript and Python
So what languages are the hip young developers writing in today?
Why JavaScript?
JavaScript obviously is the first language that comes to mind. From humble beginnings, as a means of adding dynamism to web pages, it has escaped the tyranny of the browser. A good example of this is Node.js for server application development and Phonegap for native mobile development. They are both based around JavaScript as their programming language.
Additionally, JavaScript has an ever-growing wealth of frameworks and libraries which have ably expanded its power. It is proving to be not only the world's most popular language, but also, according to Google's benchmarks, extremely fast.
Because it is an interpreted language, it is easier to optimize. JavaScript can outperform even C# for many tasks. Douglas Crockford's excellent books <http://javascript.crockford.com/> have done much to awaken people's understanding of, and respect for, the inherent capabilities of this language. JavaScript expertise has become, for younger techies wanting to show off their skills, a part of their bragging rights. For mass appeal, JavaScript is certainly more than just the flavor of the month.
Why Not JavaScript?
If you look a little deeper, you'll see that this is not the whole story. While JavaScript has a huge impact on the client tier, some impact on app development, and occasional forays into the middle tier through Node.js, it's not really statistically significant for other types of development. 'Real' programmers will still look to C# as the standard today (long gone are the days when C++ was used for anything other than geeky low-level code hacking, and few tears should be shed over that) and Java sadly refuses to die in the corporate world. If you want to see where the interests of the bright young things of today's programming generation lie, you just need to pick up one of the raft of web or app development magazines. Behind the RWD frameworks, lifestyle consumer goods, jQuery tips, designs of the month and how-to-hack-WordPress articles, you will see (admittedly rare) examples of other languages at work.
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.
Why Python?
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.
Why Python? Well, from their stated point of view, Rocket's research points to this being a popular choice; cross-platform and easy to integrate and license. But then, by the same arguments, why not JavaScript, Ruby, Java or that other old workhorse, Perl? If you were going to add support for another language, which one would you choose?
JavaScript would seem to be the clear winner in popularity alone. But here's the rub: it is a fully interpreted, prototypical, enormously flexible language whose code is dynamically extensible at runtime . Halfway through an application you can choose to add or remove methods from an object, arbitrarily discover new code, and inject new properties. These are the very things that make JavaScript a perfect choice for the front end. However, they all ring alarm bells for DBAs.
The potential for error is just too high. Prototypical inheritance and extensible classes are not natural for a generation of developers who grew up with a more standard OO model. JavaScript code, which works in very different ways depending on what has gone before, may be fine in the limited context of a browser or app. But across a large business system, that is the sort of headache that over-stretched support teams can do without. Java is owned by Oracle, so it is hardly a likely choice for another database vendor. C# under Mono would have been a nicer option. And as for Ruby - well that's just weird.
Python may not be every developer's favorite, but it is simple, easy to read, has object orientation, and supports procedural and functional models as well as structured programming. It does allow dynamically adding and subtracting methods and properties to classes, but that is possibly less prevalent with Python than with JavaScript. Libraries like Require.js, in JavaScript, allow the downloading of code on demand. This has evolved as a response to browser speed rather than a need within the language itself.
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.
