Part Three – Scripting Languages and the Web 1995-2008

[Please note: I originally wrote this back in 2011 so my observations some of these things has moved on… I’ll comment as much as I refresh the post!]

So… where was I? Oh, yes… Java and the years of the first Internet bubble.

To recap, back in ‘95 I’d been programming for upwards of 12 years across a variety of systems, from Univac Exec 8 and IBM MVS mainframes through Sun Solaris servers and down onto desktops; CP/M back in the early ‘80s, MS-DOS, OS/2 and, more latterly Windows 3.1/95 and NT 3.51.  I was actively using quite a few languages; assembler for the respective platforms, Visual Basic, C, C++, REXX, CoBOL, Korn shell and Object Pascal (Delphi).  I’d also learned various other languages, such as ProLog, LISP, Forth and Smalltalk but wasn’t a regular practitioner of them – at least not for work-related projects.

Before I get started on Java, which will likely cause you to drop off to sleep, I’ll just mention a few other languages I picked up during this time.  As you’ll see I reduced the uptake of languages quite a bit now.  Although I did still read around a few interesting ones (anyone remember REBOL?) I generally stuck to my favourites to get anything serious done.


Perl is one of those languages that you just keeping running into.  In the same way that C is the lingua franca of structured programming, so Perl is for scripting.  I used it off and on, from the relatively early days of Perl 5 in 1996-97, for nearly a decade primarily as a “glue” language to script various utilities on Solaris, Linux and Windows, generally tying together application elements written in C/C++ and Java (and even acting as a launcher for VB6 COM libraries on Windows).  During this time I never wrote any large scale applications in it.

Then, at one of the places I worked at, I did a couple of years developing elements of a very large system in Perl using object-oriented techniques quite heavily.  This was both for general batch scripting, Perl daemons on Solaris and Linux for near real-time services and as an embedded language for generating web pages using the Embperl framework (so in much the same way that VBScript is used in legacy ASP).

As a “hacking” language, Perl is great and the rich set of libraries available on CPAN makes it very easy to get things up and running very quickly.  This can be a bit of a two-edged sword though.  Perl is one of those flexible languages where, although there is an idiomatic way to write code, it makes it possible to have many different ways to achieve the same objective.  From a sole developer/small team perspective that’s fine, but for enterprise development it means it’s important to have a set of fairly comprehensive coding standards to make sure that everything will integrate when brought together and, from a support perspective, things looks similar enough to not have to learn every developer’s personal style.

Having now worked quite extensively with Perl and got comfortable with it, I still don’t feel as happy using it as I should do.  The class system is obviously retrofitted onto the language but works reasonably well as long as you don’t need to do anything too clever with it.  The main thing I find just awkward are the sigil typing rules which essentially make variable interpretation dependent on how they are inspected (sort of like the way BCPL interpreted a pointer based on what you’re trying to do with it).  I simply prefer my variables to know what they are, and to stay that way!  I’m used to dealing with untyped pointers to storage but, for some reason, with Perl I end up using Data::Dumper far more than I feel I should have to, in order to make sure I’m dereferencing those variables in just the right way. It’s also not helpful if the original authors of the code had a pathological fear of documentation…

I haven’t done anything with Perl 6 and actually have very little interest in it.  I don’t believe that it’s really going to go anywhere.  It’s design has been underway since around 2000 with active development since 2005.  It’s taken so long to get even to this point that the project has splintered into multiple implementations.  There is so much investment in Perl 5 code that the old language line will likely just carry on with some incremental backporting of features from the Perl 6 train.  In my opinion, anyone looking to do some major development on a platform that offers the features of Perl 6 are more likely to jump ship to Ruby, Python, or similar language.


I’d come across Python in around 2001, not too long after the version 2.0 release.  I read about it and it seemed interesting but didn’t really seem to add anything that Perl offered though it was somewhat nicer in terms of being more opinionated in the way things should be done, so I just put it on a back-burner.  Then, in around 2003 or so, I became involved at work with the implementation of BEA Weblogic Server (now owned by Oracle) and that used jython as it’s administration automation language… so out came the books again!

I also started playing a MMORPG called Eve Online and found that their back-end (which had to deal with very high traffic rates in terms of their event messaging out to clients) was written using Stackless Python.  This made me very interested in how that was achieved as Python doesn’t usually multi-thread very well due to the GIL.  I was also introduced to Twisted, a event-driven server and this was great for some lightweight, high-performance server implementations too.

Since then I’ve used Python off and on but not for any major projects – apart from being my main language to explore and learn Qt graphics programming on Ubuntu Linux.  I generally like Python and since the community has grown, eroding Perl’s advantage with CPAN, with Google supporting it on their AppEngine PaaS offering, and the availability of libraries such as SciPy, and NumPy have made it a very powerful language to work in.  It has a nice balance of an being an OO imperative language but with the ability to write declarative functional code too.

[Note: Nov 2016 – Obviously now, with the rise of the Data Scientist profession in the enterprise, Python is now almost de riguer for those teams with pandas, Jupyter, matplotlib and scikit-learn rounding out their portfolio. I would say that Python has now achieved pre-eminence over Perl as the “scripting” system development language of choice for many people. I’d certainly advocate it’s use over Perl for new projects now. With web frameworks such as Django and Flask (good for microservice development) available too, it’s a sound choice in my view.  Interestingly, the popular node.js with it’s event-driven callback architecture is very similar to Twisted – nothing new under the Sun!]


Love it, or hate it, this is one of those languages that you just have to know if you’re doing any website development on Linux “in the wild”.  I’ve not programmed  “professionally” in it, but I have built some small websites using it.  I have seen some dreadful PHP code published but I believe this is due to the nature of the language and it’s broad availability on low-cost web hosts.  The ease of getting started in using it means that people that aren’t experienced in writing structured code can hack together pages combining code and layout.  This problem isn’t unique to PHP – both JSP and ASP suffer from it, and pretty much every CGI-capable language can suffer from it too (though in a somewhat inverted manner).

From a language perspective, it’s quite possible to write good, structured PHP code making sure that common web-app paradigms are paid attention too; Model-2 design, templated pages, modular components, etc. and frameworks/toolsets like the Zend, CakePHP and  Smarty allow this to a great extent.

Admittedly the language does have some deficiencies but it, and the people who work in it day-to-day, don’t deserve the stigma that seems to be heaped on it from the more “academic” programming world.  Like Perl, it’s a pragmatic language to just get a job done in.


I’m still not sure whether HTML actually qualifies as a language – but I certainly err on the side of “No”. I’d done quite a lot with another, somewhat richer variant of SGML as part of a large project at work, creating high-quality financial valuation reports on an electronic publishing platform called Xerox Integrated Composition System (XICS) – now consigned to history it seems.

I was therefore reasonable unimpressed with “Web Pages” and HTML when the web first took off as we’d been doing similar things internally since around 1988-89.

We designed on an XPS701 (essentially a turnkey Dec MicroVax II) and XPIW workstations (connected together over 10Base5 yellow “Thicknet”) and then run in bulk volume on an IBM MVS mainframe before printing on Xerox 9700 and DocuTech laser printers.  This was like mail merge DTP but on a huge scale especially for the technology available at the time.  (This was essentially VERY similar to what XHTML and CSS was to become in later years – though the user-defined mark-up tags could actually contain lightweight conditional code to make simple rendering decisions based on content.)

Image result for xerox xpiw

A Xerox Publishing Illustrators Workstation (XPIW)  running the object-oriented ViewPoint operating system (similar to the concepts of NeXTSTEP but pre-dating it by maybe 4-5 years and, well, let’s face it, monochrome only). Xerox really blew that little opportunity…

I’d also created a REXX-based documentation system, hosted in IBM NetView on the mainframe, that contained tab-selectable “hyperlinks” (or hotspots in the text) through which a keypress could then navigate through to other content.  So, again, I was quite non-plussed by what something like Lynx offered when such things started arriving in the public domain in around 1992.  (I live a life of continual disillusionment – if only I’d been allowed to Open Source my Netview documentation implementation… just wasn’t the sort of thing that happened back in those days.)

But I digress…

HTML has, of course, become a mainstay of web programming and I’ve used it on a regular basis for many years.  This has included extensive DOM manipulation with JavaScript (see below) – I was using what were to become known as “AJAX” techniques for intranet development back in 2000 using XMLHttpRequest (as initially made available for MS Outlook Web Access) and the MSXML parser in IE5.

HTML5 or, at least the menagerie of associated technologies falling under the HTML5 umbrella, is likely going to create another generation of “interesting times” in the world of web browser content delivery just as the excitement was kind of dying off as things standardised on Flash/Silverlight (boo! hiss!) and DHTML/AJAX technologies.  It offers some interesting new capabilities that lets developers treat the browser more like a real client machine with proper persistent storage rather than just cookies and the ability to create persistent socket connections without a prescribed protocol.  The other cat-amongst-the-pigeons is the OpenGL-enabled Canvas.

The thing with Canvas is that it’s just providing a low-level API onto a raw graphics context.  I predict that there will be a slew of browser-hosted frameworks being developed and marketed by both commercial and Open Source interests.  In much the same way that JavaScript libraries such as jQuery, Prototype and Mootools were created to simplify DOM interactions these new frameworks will provide a higher level API with which to create HTML5 applications within a Canvas component in much the same way that ActionScript is used within Flash.  I think it’s likely that these frameworks will be more similar full-blown window-management frameworks creating lightweight components within the Canvas itself, than those that simply wrap the DOM.

So, whilst HTML5 will provide a unified platform (at least in concept), consistent across browsers, it may come to pass that the market fragments onto these other frameworks.

[Note: Nov 2016 – so this has largely happened with respect to creating HTML5 applications using frameworks such as React.js and Angular, etc. and, for example, EaselJS, Fabric.js and paper.js for wrapping the canvas.  In the former case, there have been clearer winners (from Facebook and Google) than in the latter – even so there are a significant number of frameworks for building SPAs (Single Page Applications) and this has split the front-end web development community diluting and polarising available development talent (in my opinion).  The whole wrapping the canvas thing]


As a natural progression to authoring simple HTML pages I started using Javascript, as most people did I suppose, to create the simple sort of animation effects (for button rollovers on web pages) and handling button push & blur events to perform client-side form validation.

As usual, I like to know more about a language than just the scratching the surface and I was very pleasantly surprised with what I found.

Sure, the Javascript implementations were only interpreted and not particularly fast, and DOM manipulation was quite slow but the language itself was sound.  I’d come across prototype-based object languages before in the form of Self  (a research variant of Smalltalk) back in the early ‘90s and had been interested in the concepts, but never used it.  Javascript offered a half-way decent means of implementing a functional style of programming, and even allowed on-the-fly code generation.

The only real disappointments with Javascript were the implementations at the time which were slow and non-uniform across browsers (this was back in the Netscape 4 days – so around 1997-98).  The very fact that Javascript was really only used in the browser venue and they had largely incompatible DOMs meant that it was a bit of a pain to develop in.  This was really just a tooling problem and nothing much to do with the language but, probably due to these issues, it became seen by the majority of people as very much a toy language only useful for page animation.  It does have some language semantic idiosyncrasies that can cause runtime failures but the rigorous testing culture, largely engendered by the Ruby community (another language that can have unexpected runtime problems), combined with some experience to help understand them and build “good practice” habits means that

In one of the places I worked we did builds of some quite substantial single-page applications (using Prototype and Scriptaculous libraries too) for internal use primarily so we didn’t have to worry too much about cross-browser compatibility.  This was at around the time that FireBug became available in Firefox we tended to develop in there and then port as necessary.

Of course, with the standardization of the browser technologies and the rise of AJAX techniques there has been an investment in Javascript tooling.  Both development tools and the runtimes have improved drastically in the last 3-4 years or so.  The developer perception of the language itself has changed too.

As dynamic languages, such as Python and Ruby and, to a lesser extent, functional languages, such as Haskell, have risen in popularity, people have seen the comparison of these with Javascript and realised that, for years, there has been a very capable language, that a lot of people know, being almost totally underused!

(Note: Nov 2016 – Javascript is obviously the current darling language (especially as implemented in Google’s performant V8 engine and hosted in node.js) on the basis that it allows the same language to be used on the back-end as well as in the browser and so facilitate full-stack development.  As use of this has grown and less experienced people are coming to use the language “in the large” for the first time then so use of Javascript transpilers such as TypeScript, CoffeeScript and, now, Google Dart have arisen to put type safety into Javascript and warn against (or prevent) the more common coding gotchas.  The tooling overall has got MUCH better now too and a whole parallel set of package management and deployment tools have sprung up around it as the community “innovates” – or just re-invents – all the usual ecosystem tools but re-written in Javascript.)


I actually consciously avoided Ruby as a language until, in around 2007 I had to support some skunkwork systems written in it – at which point I thought I’d better learn it!  I’d first come across it in the “Pickaxe Book” in early 2005 whilst I was browsing the bookstore.  A quick skim-read through didn’t reveal anything too remarkable as a language and didn’t seem much different to what I might do in OO Perl or Python.  So I left it on the shelf.  This was probably about 6-9 months before Rails hit the headlines and Ruby adoption took off.

When I started working in it out of necessity, I was pleasantly surprised with the language.  It was easy to work in when writing code and I was quickly comfortable with it.  It felt pretty much like Smalltalk from the object perspective (but without the image concept which, I believe, was one of the reasons it’s found broader acceptance) and with a Perl-like syntax.  I wasn’t that impressed by the MRI runtime, in terms of performance or stability, nor with the toolset around it.  Rake and Gem are fine but nothing magic really.  Maybe if you’ve been used to only having Makefiles around they might be an improvement but nothing like some Ruby developers play them up to be assuming you’ve had exposure to Ant+Ivy or Maven from the Java world.

Like Perl, Ruby’s features can be woefully misused by inexperienced developers who seem to want to use every metaprogramming feature under the Sun just because they can.  Try debugging an application where most of its function is held in undocumented 1000 line closures with undocumented, apparently arbitrary values being passed in!  The ability to “monkey-patch” can be useful but can cause problems if the meta-programming is liberally scattered around the codebase.  Even when using “official” RubyGems you can run into problems, e.g. (as I recall) I had a funny problem trying to do a “TOP 10” type query via ActiveRecord.  All looked like it should work, but I was getting some sort of “unsupported function/invalid syntax” type error.  As it turned out, it was because the system had included a rubygem that allowed Compound Keys to be used in ActiveRecord.  It had “monkey patched” the code but it didn’t support the syntax for bounded queries – an undocumented constraint that left me puzzled for quite a while.

As I see it, Ruby is a better-than-decent but otherwise fairly unremarkable language and doesn’t actually perform that well in comparison to Python, Perl, Java and .NET (though it’s perfectly fine less computationally intensive solutions).  If you’d not come across Smalltalk before though, you might think it was more innovative that it actually is (no disrespect to Matz) when compared to C# or Java though because of the meta-programming capability.  It has some nice features but the main selling point is really the Ruby on Rails web framework, which is actually quite a good general purpose toolkit for Ruby development as a whole even if you’re not building web apps.  It wasn’t until Rails was submitted by 37Signals that interest in Ruby really took off (at least not outside of Japan).  As there are now very similar Open Source “convention over configuration” frameworks available for other languages & platforms (CakePHP, Grails, Spring MVC, Pylons, etc.) I wonder if Ruby is going to keep growing its market share in the medium-to-long term the way it has been recently.

I used Ruby 1.8.6 primarily, but have kept an eye on the 1.9.x train too which certainly seems to be gaining some traction now.  I’ll talk a bit more about JRuby and what I think about runtimes when I cover Java.

(Note: Nov 2016 – Ruby has remained popular but the Rails hype has died away somewhat as people found that solutions didn’t scale so well in terms of making most efficient use of hardware and platforms like node.js have increased in popularity.)

So, show me the Java…

Speaking of Java, this post is already FAR too long, so I’ll break here and leave that commentary for another time when I will cover Java and JVM-hosted languages in general, and the .NET platform too.

%d bloggers like this: