The Last One, Personal Computer world and me

Still clearing out the office, ready for the move. Still chucking out my life by the recycling-bin load.

But, today, lurking in a corner, I found this 26-year old issue of Personal Computer World:

Boy, did I get it in the neck for this one.  Not from my publisher or my colleagues, but from other journalists and editors. They thought it was a huge joke and that I (at the time, both the writer of the piece and the editor of the magazine) had made a monumental mistake.

It's only now, looking back, that I realise that they probably didn't even read the article. Or, in fact, read the coverline which ends with a question mark. Truth is, they were probably jealous at the attention we were drawing away from their titles.

The program in question was called "The Last One" and it not only worked (eventually) but, for donkey's years, its publisher made money out of a consulting business wrapped around the software.

Marck Pearlstone was the programmer who was called in to rescue the project in the early days, when it was very buggy. He's been my partner (and the programmer) in Brainstorm Software for the past ten or eleven years.

If you're interested, The Last One generated application code for commercial applications.

Comments

[chanel 2.55]

The same system ran at most of ICI's many Chemical plants, completely unchanged (with zero bugs I was later informed!) from 1974-2001. It didn't need to change because the software was effectively "the last one" needed to create ANY spreadsheet application.

[David]

I don't know who you are but you're right about code generation. This was the first I'd seen on a personal computer. It was 1980, after all.

[Drcoddwasright.blogspot.com]

(Just found this from a link in a current post on SQL Server Central.)

A couple of points:
- code generation goes back, at least, to 70's COBOL when it was all the rage. TLO wasn't by any means a New Thing.
- 4GL's, from the 80's and 90's were not, in the main, code generators, rather just simpler languages, generally tied to a particular database. Progress and PowerBuilder are two examples.

Code generation, especially in the database-centric world, is coming back. The driver is the SSD, which makes specifying BCNF/5NF databases feasible, and thus a basis for rational code generation. Modification is then to the schema, and a code re-gen.

[Ken Dakin]

I remember the mega-hype following on from this article. I had been programming for around 12 years already and was, like everybody else, perplexed by the sheer arrogance of the postulation.
It should have been clear to all that no such animal could ever exist and that this was just one more example of marketing speak.
However, as the lead freelance programmer on the 1974 "Works Records System" (a mainframe spreadsheet that predated Dan Bricklin's "Visicalc" by nearly 6 years), for ICI, I knew that it was possible to actually produce a system that, within certain limitations, could almost be described as "the last one". It was probably the first fully interactive, full screen, electronic spreadsheet that not only had user defined rows, columns and formulae linking them - but also stored and automatically summarized, averaged and propagated aged data in its own database. It was written entirely in 360 Assembler, ran under IBM's C.I.C.S. transaction processor and incorporated both a direct access and ADABAS database. It utilized a (home grown and as yet unnamed) "just-in-time compilation" technique (via concatenation of pre-assembled machine code snippets) to achieve faster-than-FORTRAN execution times.
My own career moved on to developing proprietary test/debugging systems after 1974 and it was only looking back - some thirty years later - that I discovered, by accident, that a couple of guys from the USA had claimed the "first electronic spreadsheet" accolade around 1979/80 for their Visicalc product.
In my humble opinion, the ICI Works Records System was in truth the first incarnation of what could truly be termed a new programming paradigm for use by "non-programmers". The same system ran at most of ICI's many Chemical plants, completely unchanged (with zero bugs I was later informed!) from 1974-2001. It didn't need to change because the software was effectively "the last one" needed to create ANY spreadsheet application.

[David Tebbutt]

You can if you like, but only the cognoscenti would know what you're talking about.

[John Clifford]

Can i just add ... "** WORKING PLEASE WAIT **"

[John Clifford]

In those days, "The Last One" was close to a visionary concept - we had no terms like "4GL" or "inner platform effect" - we just wanted to make it EASY .. and it _nearly_ worked!

Even close to 30 years later I have not seen any tool that can really "step-by-step" guide someone through the creation of a _simple_ database type application so easily and fluently.

[David Tebbutt]

Wow. I was the person who organised that trip. It was the West Coast Computer Faire and Personal Computer World (I was editor) organised the trip. I'm pretty sure that it was 1981. And we must have met.

Hope you had fun at the Faire...

[Phil Kingsland]

TLO came to mind recently while I was viewing another product. Googled it to see what came back. Well all very interesting so I think I will add my experience of it.

Way back mid last century I was born in the west country not far from Yarcombe.
In 1978 or 9 I was visiting 'The Personal Computer World Show' in San Francisco, on the flight from LA to SF next seat to me a programmer. Can't remember his name but he was the writer of 'TLO' and was based in a garage at the top of Yarcombe Hill. I'm half way across the world and meet someone I'd never heard of who works a few miles away from home.

Chatted and ended up with an invite to the 'TLO' launch presentation in a hotel in SF.

I owned a major Apple dealership in the Midlands at the time. Tried selling TLO but never managed any volume with TLO.

[Kuba Ober]

The real benefits come from higher level languages and compilers that optimize without the users having to pessimize their code. This was well known even in the 80s.

It's unfortunate that a lot of good programming practices are left at the doorstep of CS departments simply because there are no productized implementations that can perform this stuff well enough. There are numerous cases-in-point. Just look at all the barfs on caml-users list: the language has great features, but some of them have to be dropped in order to get well-performing bytecode output -- that's a limitation of the compiler per se. Or take any LISP book and read about "cons prevention" as a manually applied optimization method. Or see how gcc (and most other C/C++ compilers!) fail to inline functions defined in the same file and passed around as constant function pointers. The list goes on and on, and life becomes full of hacks which are necessary to keep the datacenters from taking up half the country due to overly pessimistically performing code...

I can't be too happy for projects like web2py which tackle real-world, well-known issues of status quo in a certain area (for web2py it's web development), solve real problems (plugging a ton of security holes, for one) and leave you with a result that works no worse than clusterfuck-style hand-coded "manual coding" typical with well-known and well-worn alternatives (here: php, jsp, ...).

Google Web Toolkit is a similarly cool project that applies mainstream CS to mainstream "real life" applications, giving something that is in a class of its own: I can't really name any other typechecking cross-compilers that generate "portable" JavaScript and are ready to be used...

TLO, while solving a real life problem, did very little in bringing approaches from then-modern CS into the mainstream. It was cool, but not overly "bright" in the sense of how much "academic" CS got applied, productized and turned out to the mass consumption...

Cheers, Kuba

[David Tebbutt]

Think of the most boring 80-col monochrome text screen with 'fill in the blanks' menus. And then visualise the most boring character-based business documents. Then you have a clear idea of what The Last One inputs and outputs looked like.

By the way, I've had to redirect enquirers away from the page scans and on to a textual version of the article. (It was machine scanned and edited by a third party. I've not even read it. But no-one's complained yet.)

[chimaera]

Funny to see this again after so long - I remember reading the article in PCW all those years ago, and occasionally I still wonder what happened to TLO. At the time I was sceptical , but nevertheless intrigued. The article, though, is a bit short of detail - it would be interesting to see some screenshots or some sample input and corresponding output.

[David Tebbutt]

Okay I'm not going to fight any more. I never saw the ad'. I thought you were all having a pop at the article - which was written a long time before the program started shipping.

Coupla things:

1) The ad' is stupid.

2) it was twenty seven years ago. Smalltalk and LISP were not remotely mainstream. Anything that made programming easier was a good idea.

3) It was appropriate for simple office-type applications.

I mentioned your notes to the lead programmer this afternoon and this is his response:

"They are talking theories of programming that were not around in '81. For me TLO remains the 1st ever programming wizard. Wrongly advertised and promoted, but inherentlyt a 'good idea'. On an Mdaemon mailing list, a guy once waxed lyrical about a 1 line date validation routine he'd seen in a basic program. I replied to him that it came from a program written by TLO.

Hope this helps.

[Tom]

David, if I'm detecting your feelings accurately then I must apologise for any offense caused, that really wasn't my intention. But honestly, systems like 'The Last One' are routinely held up as examples of design anti-patterns - software development paradigms that are fundamentally flawed. I think this very system actually got mentioned briefly in my CS university course many years ago (as a cautionary tale, of course).

I didn't mean to question your credentials but I honestly feel that a skilled software developer should understand intuitively why this paradigm can only ever accomodate the most trivial of scenarios. I do not know of a single professional software developer who worries about his job being replaced by a piece of software. An IDE and a high level programming language is as good as it's going to get, period. History has largely proven this to be accurate, in the same way it has proven 'The Last One' to be of little real-world use.

Again, sorry for any offence and thank you for the interesting article and comments.

[Horst]

Well obviously Tom came here guided by an article and discussion on thedailywtf.com (see URL).

And honestly, after reading the articles you have scanned, i really cannot found any critical distance to the product you were "reviewing".

As a programmer you must have been aware that this program generator can either only create a very limited type of applications or simply replaces the BASIC programming language with a graphic representation of the BASIC programming language.

Writing " it's almost certain to beat the best programmer for both speed and accuracy!" is advertising BS. It only translates one form of the program into another, at the time the "user" is "entering the flowcharts" he is doing real programming - albeit not in BASIC, but in flowcharts.

And calling programs "error free" because it has correctly translated the errors in the flowcharts into equivalent errors in the generated BASIC is also a bit misleading.

Assuming that it can even do that - why should i believe that the programmer of "The Last One" has made no errors?

So there remains one advantage: Support for an iterative software development process in times where waterfall was the norm.

But that was possible even at that time and the dynamic languages available then (Smalltalk 80, LISP, even BASIC) supported that very well.

[David Tebbutt]

Well I don't know who you are Tom. And you clearly don't know anything about me either. At the time I wrote that piece, I'd been in the computer business for 15 years, many of them as a programmer, writing commercial applications such as payroll, stock control, accounting systems and research analysis. Indeed, I was still programming at the time I wrote the piece and I continued after I left the magazine.

I think that probably placed me better than most to review what these guys were trying to do. Not only that, I actually sat down with the system and started to recreate a sales order processing system.

Hope this information helps.

[Tom]

Software developers tend to call this the "inner platform effect". You try to make a system that is so robust and configurable that you end up replicating the functions of your own design platform. All you end up with is another platform, but one that is considerably less known and supported than the one you started with. Once 'The Last One' had become sufficiently complex it became little more than a custom, improperly supported façade over BASIC. In truth, this was the only possible outcome of their project and had either of them been professional software developers they would have realised this from the outset. Of course, it could well be argued that maybe they did realise this - and understood that the consultancy work from supporting this monster would pay the bills for far longer than actual software sales would.

All things considered, I'm quite surprised at the fawning praise this sytem got in PCW back in the day. I guess that back then, IT journalists invariably had little or no knowledge of actual programming. Must be pretty embarassing to re-read this article with hindsight. Still, thanks for this information and for reproducing the article, it makes for fascinating reading.

[David Tebbutt]

Last I heard, Scotty was living in Alicante.

[Harvey Platter]

I used TLO, as it came to be known, quite a lot in the 'eighties and knew Scotty Banbury pretty well, as I lived in Devon and he was based just over the border in Somerset. TLO was good for those urgent jobs that needed a lot of screen input and reporting but didn't do too much in between. The limitations showed up when the processing got complex but that seemed to me to be as much a function of BASIC's limitations, at the time, as those of the generator.

Over the years, TLO changed from being a form driven tool to a meta-language. Eventually, the meta-language became pretty nearly as complex as the target BASIC, which sort of spoiled the concept.

The original idea was fine and was taken up by a company called System C, who were based on the opposite side of the country, in Kent. Their Sycero product targeted dBase/Clipper as well as C and I used it for some quite large projects. They seem to have learned from TLO's mistakes and built in the ability to handle fairly complex processing from the outset and it had the advantage of being targeted at much more flexible languages than TLO.

The best thing about both Sycero and TLO was that they were, effectively, self documenting; something that the current crop of 4GLs don't seem to have retained, despite having vastly greater resources to play in.

The last time I met Scotty, he was talking about a new version of TLO that would target C but I never heard any more about it.

[David Tebbutt]

Hmm. I think it's in one of those boxes over there...

[Rummage, rummage]

Yep, here it is.

I've made an HTML set. Not the most elegant but it's all more or less there.

http://www.tebbo.com/pix/thelastone/thelastone.html

Sorry about the wordy link.

[Huw Davies]

I had a copy: - 1981/2 - it ran on an Apple II. My basic wasn't up to understanding the output but it did work. I seem to remember that we were going to be swept away by the next version which was going to generate Assembler code. I would like to see any info about the program for old times sake. I found your scanned PCW article on http://www.presshere.com/html/pw8102.htm but the illustrations were not included. Do you have a copy of the original with illustrations?

Huw Davies

[richard mullins]

i remember "the last one". I think I read about in 1981.
I thought the concept was excellent. When I heard no more about it,
I wondered if the concept had been undermined by the coming of
"graphical interfaces".

It might be a very good idea ("the last one") for graphical interfaces. But as the definition of a graphical interface is much more loose than a "command line", we could be a long way from a final version of "the last one" for a graphical interface. The problem is that future graphical interfaces will include VR interfaces or other interfaces equally as complex. Let us however carry on boldly.

Richard Mullins
[email protected]

[David Tebbutt]

Bong!! Seconds out...

Anyone care to comment?

[Andy Roberts]

I had mixed feelings about application generators, or 4GLs as we sometimes called them. I could get something up and running in days rather than months, but then when the requests for enhancements came in it was often frustratingly difficult to deliver, and sometimes impossible under the restraints of the built in fixed logic.
I sometimes wonder if today's Ruby on Rails developers experience similar.