Archive for March, 2017

Roy & I

March 11, 2017

Roy Austen (1953-2017), a former colleague, died a few days ago on March 5.

A friend recently told me that Roy had been diagnosed with cancer in January, although he had actually been unwell for months before then.

Not long after the diagnosis, Roy set up a GoFundMe page for medical expenses and for the ongoing care of his son, in preparation for the inevitable.

I really did mean to get in contact, but I got busy and Roy died before I did. At least there was still the fund…

Roy’s main line of work and his passion was photography, but that’s not how we got to know one another.

I bought my first Windows (3.1) PC from his family business, KM Computers.

Then, awhile later, he offered me a job and became my boss…

By the end of 1995 I was in search of my next job after 5 years at the University of Tasmania (UTAS) in Launceston as a computer systems officer then a junior academic in the Department of Applied Computing. A lot of university contracts weren’t being renewed around that time.

Luckily for me, Roy had recently started Vision Internet, one of a small but growing number of competing Internet Service Providers (ISPs) in Tasmania. It was a small business arising from KM Computers at a time when Internet access was still dial-up, ISDN/ISDL was the fastest you could hope for (128 Kbps), but most people just had a dial-up modem, giving up to around 56 Kbps, less in practice. Vision Internet started in Launceston but quickly added points of presence in other parts of the state, including an Internet Cafe.

In 1995 while still at UTAS, I had helped Roy out by writing a basic customer time accounting program in C that read utmp/wtmp logs and generated simple output when someone else had difficulty doing so.

By 1996, Roy needed a programmer and system administrator and I needed a job. Before accepting Roy’s job offer, I was up front with him that I would probably want to do something different after about 18 months. That happened with Karen and I moving to Adelaide in 1997 where I spent 10 years with Motorola. That move was more difficult than I expected, and at least as hard as Karen knew it would be. In the end, it was a good move.

Ironically, UTAS asked me to come back for some occasional part-time tutoring soon after I started working for Roy, which may have been less economical than if they’d just renewed my contract!

Vision Internet was good while it lasted. To be honest, for the first few months, I couldn’t believe I was being paid to write C  (and Perl) code, something I enjoyed doing anyway. 🙂

The compact machine room doubled as my office for the first year or so before we moved down the road to a more spacious building; not as cushy as my office at UTAS. I actually didn’t mind the machine room too much. A terminal with function key accessible “virtual consoles”, the vi editor, command-line shell, a C compiler, and a Perl interpreter kept me pretty happy. Roy was fine with me working from home occasionally as time went by too. He expected me to keep things rolling and solve problems as quickly as possible, but he was good to me and we got along pretty well.

There were only about half a dozen people working at Vision Internet, fewer early on. Everyone pitched in. Roy and I didn’t always see eye to eye though. For example, at one point we disagreed about who should have super-user privileges; more than I would have liked for a brief time. 🙂

I experienced a number of things during my time with Roy at Vision Internet and learned lessons from some:

  • Early mobile phones were fairly bulky. 🙂 Roy gave me my first mobile before I started in the job. Of course, this meant he could contact me whenever. He didn’t abuse that though. A former UTAS colleague took one look at the phone hanging off my belt and declared amusingly: “wanker phone”. 🙂 Even worse when a larger battery was added! Still, I appreciated Roy giving me my first mobile.
  • You can’t always spend time doing what you want in a job, even one you mostly like, unless you’re very lucky. I guess I already knew that from being a nurse in the 80s. I had no real interest in sysadmin tasks like applying security patches to BSD Unix kernels, maintaining backups, chasing hackers, worrying about what dodgy things people might be doing with our systems or customer sales, credit card transactions, help desk (shades of The IT Crowd: “is your modem plugged in?”). I mostly wanted to design, code, and test software. Still do. That’s largely why I told Roy I thought I’d want to move on after about 18 months. Having said that, a fair amount of my time was spent writing software in the form of a suite of customer time usage programs, each prefixed with tu, written in C and Perl. We also eventually sold tu to another local ISP.
  • The practical difference between code that uses a search-based processing algorithm over a linear data structure that runs in polynomial vs logarithmic time – O(n^2) vs O(n log n). This matters a lot as the number of customer records (n) increases when your task is to write a program that processes customer time usage once per day and obviously before the next day starts. To simplify: given a processing time of a second per customer, n≈300 can mean the difference between a run that takes a day instead of an hour. You can make incremental changes to the processing time per customer (t), but eventually you’ll hit a point where n is too large, e.g. when n=1000 and t is 0.1 seconds. Anyway, I don’t recall what our n and t were, but we hit such a limit with a tu program. When I realised what was going on and fixed it, Roy was delighted and relieved. I was pretty happy too and thanked my computer science education, in particular, the discipline of computational complexity.

Before I left to go work at Motorola, I made sure Roy wasn’t going to be left without someone in my role. This gave one of my former UTAS students (Craig Madden) the opportunity he needed to break into the industry; it turned out well for Roy and Vision too.

At the height of Vision Internet, I remember occasional staff gatherings at Roy’s. He was a good host and I think he mostly enjoyed that period, despite the worry that must’ve accompanied running a business. He was generally optimistic and trusted those he employed. He had his moments, like the rest of us, when he was unhappy or angry, but mostly, he was a good guy to be around.

If I could do so, I’d tell him this:

Roy, I’m really sorry you’re gone and that I didn’t make the time to get in contact. In recent years, I should have told you how much I appreciated the opportunity you gave me a long time ago. Upon reflection, after time spent together at Vision and elsewhere, I think we would have used the word “friend” (now distorted by social media) to describe our relationship, not just “colleague”, even if we didn’t say so. I should have told you that too.

Advertisements

On porting an ACE program to HTML5 (among other things)

March 1, 2017

In recent times I’ve been thinking about ACE BASIC, a compiler for the Amiga I stopped working on just over 20 years ago; nostalgia’s setting in I guess. A few years ago wrote a bit about ACE in relation to BASIC’s 50th; there’s more in these 1994 and 1997 articles.

As mentioned in the 50th post, a wonderfully thriving community built up around ACE between 1991 and 1996 centred upon an active mailing list and contributions of ideas, example programs and tools. I have been mildly (but pleasantly) surprised by a couple of things since I stopped development:

  1. Continued use of ACE on Amiga hardware and emulators for at least a decade afterward.
  2. An project to modify the code generator for post mid-90s Amiga operating systems and additional targets such as PowerPC and Intel.

Among other things, I’ve been thinking about a re-write for a modern platform or target, e.g. HTML5. The world of the 90s was still very platform-centric, but in the same year I stopped developing ACE, version 1.0 of the Java Development Kit was released, putting the power of Java and its  virtual machine into the hands of eager programmers. Java and JavaScript helped to consolidate the browser as an important platform and to define the shape of web development in a post-CGI (Common Gateway Interface, not Computer Generated Imagery) world.

A new compiler or interpreter is a non-trivial task, especially in my current spare-time-poor state, but I wanted to explore how an ACE program could be rewritten for an HTML5 context.

One of my favourite ACE programs was an implementation of IFS (Iterated Function Systems) to generate simple 2D structures such as ferns, trees, the Sierpinski Triangle and so on. So I started with this. It’s simple yet complex enough to allow for a comparison of approaches.

Here are a few observations on the original IFS ACE source code (ifs.b) and my initial HTML5 port of the code.

  • JavaScript in the browser appears to be faster than ACE on the Amiga. Sure, processors and clock speeds have improved since the mid-90s but ACE generated native 68000 assembly code. Then again, to think of JavaScript as an interpreted language is very simplistic with just in time compilation in widespread use.
  • The ACE code is quite data-centric. DATA statements containing comma-separated values are read into two dimensional arrays, so the original data is not close to where it’s used and it’s not clear what the numbers are associated with. I could have taken this approach in the port, but chose instead to create a data object, a map, close to the point of use, copying the original array names (bad in some cases: a, b, c, okay in others: xoffset, yscale) from the ACE program for use as map key names, to make a correspondence easier to see.
    • This meant first transposing the data (in Excel) so that DATA columns became rows.
    • Preserving the existing DATA organisation could be accomplished by introducing functions such as data() and read() that create and read, respectively, a pool of data values. For future DATA-centric ACE program ports, I’ll try that approach.
  • In ACE, the creation of a menu and its items is simple as shown by the creation of the Special menu below; this menu name is an Amiga convention. Shortcut key letters are optional.
    • menu 1,0,1,"Project"
      menu 1,1,1,"Sierpinski Triangle"
      menu 1,2,1,"Square"
      menu 1,3,1,"Fern"
      menu 1,4,1,"Tree #1"
      menu 1,5,1,"Tree #2"
      menu 1,6,1,"Sunflower"
      menu 1,7,0,"-------------------"
      menu 1,8,1,"Help...","H"
      menu 1,9,1,"About...","A"
  • Compare this with the odd combination of HTML, CSS and JavaScript in this initial attempt at a port.
  • On the other hand, ACE’s (and so AmigaBASIC’s) reliance upon numeric identifiers is almost as unreadable as a collection of DATA statements. The MENU statements above declare the Project menu to be the first (from the left of a menu bar), with each menu item numbered in order of desired appearance and 1 or 0 enabling or disabling the menu item. Subsequent enable/disable operations on menus must refer to the same combination of numeric IDs, e.g. menu 1,2,0 would disable the Square item. Also, menu item selection handling is a bit awkward in ACE.

The code eventually morphed into what I’ve dubbed ACEjs, in the spirit of some other JavaScript library/frameworks. I’m not claiming any novelty here. The idea was to answer the question: how might ACE code look in a modern context? I’m less concerned with slavishly preserving the look and feel of the program, i.e. I’m not trying to make it look like it’s running on an Amiga. I just want to make it functionally equivalent.

Here’s a screenshot of the simple example ifs.b program in ACEjs form:

IFS in ACEjs

I don’t currently have a screenshot of ifs.b running on an Amiga or an emulator.

In any case, the outcome so far is that I have made progress toward an ACE-inspired JavaScript library for HTML5. Here are some key aspects:

  • CSS, DOM, jQuery (so JavaScript) as web assembly language but only JavaScript code needs to be written.
  • Functions like menu(), window(), dialog() manipulate the DOM to add elements (canvas, list etc) via jQuery under the hood.
    • A menu declaration corresponding to the ACE code’s Project menu (with Help and separator items omitted) follows, a key difference being that menu items are paired with callback functions (e.g. see sierpinski below), another being that there is no support for shortcut keys currently:
      • acejs.menu("Project", [
            ["Sierpinski Triangle", sierpinski],
            ["Square", square],
            ["Fern", fern],
            ["Tree #1", tree1],
            ["Tree #2", tree2],
            ["Sunflower", sunflower],
            ["About...", about]
        ]);
    • A window declaration that adds a framed canvas looks like this:
      • wdw_id = acejs.window("IFS", 640, 400);
    • and operations on the window make use of an ID:
      • acejs.clear(wdw_id);
      • acejs.pset(wdw_id, outX, outY, pixelColor);
    • Multiple menus and windows can be created.
    • acejs.css is almost non-existent currently. I’m sure someone who delights in CSS could make it look suitably dark and brooding with their eyes closed. I make no claim to have any special talent in web design.

There’s arguably no need for a compiler or interpreter. JavaScript’s iteration, selection, and expressions are adequate. Having said that, ACEjs could form the basis of a target if I ever chose to write another ACE compiler or interpreter (with all that spare time of mine).

With ACEjs you only have to write an app.js source file for your application and use a standard index.html that brings in your code and whatever else is needed, in particular acejs.css (trivial right now) and acejs.js. The only special thing you have to do is to define an init() function in app.js to be invoked by the framework. The best way to see how this works is to look at the example.

You can either download the contents of the public_html directory and open index.html in your browser or see the example application running here.

In early 2000 I wrote an article for Sky & Telescope (S&T) magazine’s astronomical computation column entitled Scripting: a programming alternative which proposed JavaScript as a suitable alternative to BASIC for astronomical computation, long used by S&T and others to disseminate programs. Even at that time, JavaScript was arguably the only programming language interpreter available on almost every personal computer, by virtue of the ubiquity of web browsers.

In essence, JavaScript had become the equivalent of the BASIC interpreter every old personal computer (formerly called microcomputers, especially in the 80s) once had. I made the example programs from the article available and experimented further; some examples show the original BASIC listing along with the JavaScript implementation.

A variant of the ideas that led to ACEjs are revealed in what I said on this page:

Peter Girard has suggested the creation of an ECMAScript code library for astronomical algorithms.

An idea I’ve had is to write a BASIC (which dialect: GWBASIC, QBasic, etc?) to ECMAScript translator, written in ECMAScript or Java. One could paste BASIC code into a text area on a web page, and have ECMAScript and HTML code generated on the fly. This would make the BASIC code on Sky & Telescope‘s web site available as interactive programs. Or, it could generate a listing, making Peter Girard’s idea of a code library easier to achieve.

Of course, there are now plenty of examples of BASIC interpreters written in JavaScript, e.g. here’s a QBasic implementation that generates bytecode and uses canvas. Then again, as I have noted, my aim was not to slavishly recreate the exact look & feel of the original platform.

S&T showed some initial interest in JavaScript, again in 2005 regarding an orbit viewer page I wrote that combined JavaScript, a Java applet and cross-domain AJAX while Internet Explorer allowed it, and before CORS was a thing.

Of course since then and for all kinds of reasons, JavaScript has come to dominate rich client browser applications, especially after the introduction of AJAX, and has generally become the assembly language of the web. More recently we’ve seen the rise of Node.js, an explosion of JavaScript web frameworks (Angular, React, …), and mobile JavaScript development frameworks like Apache Cordova. JavaScript has good points and bad along with detractors aplenty, but it’s hard to argue with its success.

History has shown that a programming language does not have to be perfect to succeed. I love C, but it’s far from perfect and holes in its type system allow one to, as the saying goes, “shoot one’s foot off”. Additionally, these same holes are responsible for security vulnerabilities in the operating systems we rely upon. Notice, I’m not saying that C itself is responsible (it’s not a person or a company) for exploits of those vulnerabilities; that’s attributable to the moral barrenness of the people involved. It’s unlikely that we’ll see the sum total of mainstream OS-land rewritten in safer languages (Rust, Haskell, …), to save us from ourselves, anytime soon.

But I digress…

I could repurpose ACE to generate JavaScript, but we are living in a time of “programming language plenty”. Creating a new language today should be considered a last resort. Domain Specific Languages, sure. Libraries and frameworks, perhaps. New languages? Looking at what’s available first before reinventing the wheel should be considered a responsibility. Also, a language is no longer enough by itself. You need an ecosystem of tools (IDE, debugger at least) and libraries for anyone to care enough to want to use your shiny new language beyond very simple programs. ACE had a couple of IDEs but no debugger. Heck, I didn’t even use a debugger when writing the compiler! Now I seem to live in source level debuggers. I’m obviously getting soft. 🙂

When I was a junior academic in the computing department at UTAS in the mid-90s, upon learning about my development of ACE, a senior and sometimes less-than-tactful colleague remarked that creating a new language was, as he so delicately put it, “a wank”. I disagreed. ACE was about providing the power of a compiled language for a particular platform (Amiga) to people who knew an interpreted language (AmigaBASIC), wanted to leverage that experience and existing code and didn’t feel confident enough to learn the dominant systems-level language of the time (C). It was also about improving the precursor language.

Now, I would agree that the decision to create a new programming language or library requires some circumspection, at the very least. But the programming language landscape has expanded a lot since the mid-90s. There is of course value in writing an interpreter or compiler, just for the learning as an end in itself and every computer science or software engineering student should do so.

So, in the end: why ACEjs?

In part because I wanted to explore simple ways to write or port a certain class of application (e.g. old ACE programs) to client-side web applications.

Partly out of a sense of nostalgia.

In part because I want to learn more JavaScript, Canvas, jQuery and jQuery-ui and the subtle differences between JavaScript versions.

Mostly, I wanted to get a bundle of ideas out of my system, which I’ve more or less done.

ACEjs is a simple starting point and if it’s useful to me, I’ll continue to improve it; if not, it will happily fade away. So far, I’ve tested it using Chrome version 56 and Safari version 9 and ECMAScript (the underlying JavaScript standard) 5 and 6.

Finally, look in the About box of the example application for a small dedication, also present in the even simpler About box of ifs.b; my wife spent far too long listening to me talk about programming languages and compilers in the 90s. Now the talk is more likely to be about variable stars. Thanks Karen. We both like ferns as well, IFS generated or natural. 🙂

In any case, enjoy. Feedback welcome.