Flex Without Frameworks

I have used the Swiz and Mate frameworks for Flex development, as well as an injection-framework of my own devising, and now worry about their use for applications that run on minimal-memory devices like phones and pads.  The libraries take up extra space and the benefits, such as making it "easier" to develop complex applications, not so applicable.

I like to use the presentation model in Web and Air applications but do I need that complexity for Android and IPhone apps?  And what about abstract classes and multiple-inheritance through interfaces?

A lot of apps are so "simple" in flow that having components dispatch events that are handled by their parent screens seems are lot more efficient in development terms.  Efficient in requiring less code and creating no more debugging.

To resolve these conflicts, I intend to develop an application for multiple devices and then re-factor it for the popular frameworks.
  

Digital Equipment Corp PDP-8

The PDP-8 was one of the most popular mini-computers from the mid 60's until the arrival of the first micro computers.  It was a single accumulator design and had from one to three banks of memory, each with 4K of 12-bit memory.

The memory was magnetic-core memory that didn't hold its content when switched off, and there was no ROM available at the time of the PDP-8I, so when you switched it on you had to load the bootstrap code into memory through the switches on the front panel.  This bootstrap read in a paper-tape containing a full paper-tape loader program, which could then be used to load in editors,etc.

The main storage device was a small random-access magnetic-tape unit.  This tape was block-addressable.  My first PDP-8I had the luxury of a 64k disk-drive as well.

I wrote a real-time operating system for the PDP-8i that included a 'database' -- a binary-chop system using the random-access ability of the DECTape.

ICL System 4/50 .... RCA Spectra 70/45

In the late 1960s I  worked  on a project at the Post Office in London that used System 4s and Spectras, both clones of the IBM 360 mainframe.

The hardware had been bought for National Giro, the government's bank-for-the-ordinary-man, based in Bootle, Merseyside.  Unfortunately the bank was not as sucessful as predicted, leaving a lot of spare hardware. 

Rather than admit the Giro's lack of success, the Post Office created a number of new projects and pretended that the hardware had been bought for theses projects. So I ended up as one of the designers of a real-time operating system that was to support a system for managing long-distance phone lines.

The project included about 40 new graduates and, as I was the only one who knew anything about computers, I got to design part of the system and to work on the operating system's memory management.

After the project had been going almost a year we had some minor management changes, including a women who thought that the project seemed a lot like the project that her husband was working on in another Post Office building.  It turns out that the two projects were identical!!

The two projects were chopped in half and the back-end of one merged with the front-end of the other.

This removed the justification for the operating system, so I was re-assigned to lead a team of Cobol programmers. The programmers were sent on a Cobol course while I was given a copy of Daniel McCracken's book on Cobol..

I so enjoyed Cobol programming that I set about looking for someone who needed an operating system designed..

The Elliot 803

The Elliot 803 was the first computer that I did any serious programming with in the 1960s. It came with a massive 4k (yes 4096) words of ferrite core memory Each word was 39bits long, comprising two 19-bit instructions with a single modifier bit in the middle position that enabled instruction modification at run time.


The 803 had only a single address register to point at data and a single accumulator/register for all the processing to take place in.


There is a working example of an 803 at Bletchley Park