Mon Oct 31 16:55:50 CET 2016
On Mon, Oct 31, 2016 at 5:28 AM, Richard A. O'Keefe <> wrote:
> On 29/10/16 12:53 AM, Joe Armstrong wrote:
>> I get the impression that GUI programming is actually going
>> backwards - in the 80's there were systems build on languages
>> like TCL that did not need GByte downloads and complex IDEs.
> The first GUI interface I ever programmed was Interlisp-D,
> which was Interlisp running on Xerox 1108s, 1109s, 1185s, and
> 1186s. Everything above the microcode level was Lisp. The
> GUI library occupied two chapters in the manual, and from
> never having programmed a GUI before it took me about 10 days
> to get a multipane debugger going. The machine had a 32MB
> virtual memory and a 4MB physical memory, and it was a couple
> of decades before I had access to a GUI that was as fast in
> From that standpoint: Tcl/Tk is arcane and bloated. (:-)
> One change: colour. The later Xerox D-machines had colour
> displays, the earlier ones didn't.
> Another change: images. The D-machines were *great* at
> styled text (that's where the word processor was invented,
> after all) and vector graphics. They didn't (at least not
> back in 1984) have to deal with a whole lot of image file
> Another change: video.
> Another change: 3D.
> Another change: HTML support. (Which used to work fine on 8MB Macs...)
> The Interlisp-D GUI kit stayed small because it HAD to.
> wxWidgets is big because it CAN be and the incremental cost
> of expanding it is always less than the incremental cost (to
> the developers) of shrinking it (which might require redesign).
Brilliant - you are 100% correct - I'd never thought of it that way.
The marginal cost of adding a feature is low - and can be financed
by the people wanting the additional feature - if it is badly
implemented it won't really matter - since very few people initially
use new features.
The marginal cost of removing a feature is enormous - and will break
any code using the feature - so this does not get done.
In the good 'ol unix days features competed for disk space, and unused
new features were removed to save space - now there are no such restrictions.
Thus systems grow and grow until they become so brittle they cannot be
changed - at this point we wave a magic wand and bake them into a
virtual machine in some fancy container - and then start over.
So this is why something that used to be a few KBytes of code
is now wrapped up in the middle of a GByte download.
Our DNA is roughly 97% junk - evidence of earlier experiments gone
wrong - rather like modern software.
Niklas Wirth used to say that whenever we added a new feature to a system
we should remove some old feature - this is keep the system small, simple
and understandable - but their is no economic incentive to do so.
The soggy mess that we will end up with will be somebody else's
problem and we can happily say we are adding to employment prospects
in the future
by creating a mess that somebody else will clear up :-)
> erlang-questions mailing list
More information about the erlang-questions