![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
liam_on_linux> In short, the more somebody sounds off about a language or OS, the
> less they should be trusted. But I think you're reaching the same
> conclusion.
Well, yes...
> First, from a "wisdom of the ancients" POV: what have we lost out
> on?
That's what I am trying to work on elucidating, understanding and finding
out how to explain.
In general, because I don't yet know enough to have any alternative, I
have no recourse except to be vague and hand-wavey:
What we have now are very fast, very capacious, very very stupid
computers. What ought to be arcane internal concepts are exposed at the UI
and users have to learn to manipulate them: files, folders, file *types*,
documents, binaries and executables, source code, interpreters versus
compilers, and so on.
As Stanislav Datskovskiy put it in http://www.loper-os.org/?p=55 :
<<
The computers we now use are descended from 1980s children’s toys. Their
level of bedrock abstraction is an exceedingly low one. This would be
acceptable in a micro with 64K of RAM, but when scaled up to present
proportions it is a nightmare of multi-gigabyte bloat and decay.
>>
We run a big program which we use to navigate among a collection of
different, separate, smaller programs, which we run and then use to open
data files, manipulate their contents, then save them. Then we use client
programs to send messages over network protocols to remote servers.
And ordinary people are expected to keep track of all this, to learn these
concepts and become fluent with them.
To nerds and geeks, it's easy, and we have become so used to this stuff
that we are blind to the fact that it is /profoundly/ arcane and abstruse.
What we have are not the descendants of the big powerful multiuser systems
of the 1960s and 1970s. No, what happened was that the tech got cheap
enough for tiny, rudimentary, simplistic, brain-damaged versions to be
sold as toys. And then those toys have grown and been enlarged and
expanded and made thousands of times faster, without learning any of the
lessons of the computers from pre-toy times.
Those big '60s and '70s machines were horribly clunky, yes, but they had
solved (or at least had answers to) important problems to do with
security, permissions, parallelism, portability and more, none of which
have come across and which are being re-invented on all sides today.
Even obscure failed micro operating systems made important advances that
have been ignored. There is no technical reason why executable programs
should be tied to an underlying CPU architecture; Taos showed this. There
is no technical reason that it should make any difference what machine on
a network a resource (storage, processing, data) is on; that kind of thing
should be transparent to the user. Perhaps not to the admin, no, but users
should not have to know. Plan 9 demonstrated this, and Inferno added
Java-style binary portability to the mix. They still failed.
If the user needs to know about file formats, about markup, about server
names or what program handles what file, about how to move information
between programs, about what kind of computer can run what kind of
program, about any of this kind of low-level techie wank, then we have
failed.
And this means we have all failed. We have all worked at some point in the
chain between making chips and delivering products to buyers. And we have
singularly screwed the pooch. We've taken the easiest, simplest, stupidest
way and delivered sad broken crap that has not actually improved in what
it does since about 1975. All it's done is got cheaper and quicker.
So don't ask about what will it do better that my current computer does.
Don't ask about performance. Performance is not the criterion that
matters. It's like judging a pen by how fast it can lay down ink:
http://www.loper-os.org/?p=300
Now, doubtless, you'll want concrete examples and I can't give them, not
yet. I'm still working on it.
But moving aside from the LispM model, which is a sort of information
appliance for programmers, there's Jef Raskin's work on the Canon Cat and
the Swyft UI:
http://www.jagshouse.com/swyft.html
http://oldcomputers.net/canon-cat.html
It doesn't have programs, it doesn't have files, it has no distinction
between OS and apps. If you type text, you can format it and lay it out.
If you type expressions, you can evaluate them. If you type a grid of
numbers, you can apply operations to blocks of them (i.e., what a
standalone spreadsheet does).
As planned, it would be able to send data to other people, and you could
obtain new methods and capabilities from other vendors and integrate them
into your system... but Canon crippled or removed all that.
A richer, more sophisticated example was the Apple Newton, conceived of as
a pocket info appliance. The original design for the Newton was a pocket
Lisp Machine, but with an algebraic-notation Lisp called Dylan with an
insanely rich desktop development UI that makes Visual Studio look like
Edlin.
It got canned. They then came up with the much simpler NewtonScript and
wrote it in that.
No files, no folders and a UI driven by a pen and natural language. Go to
the "do" box and write "lunch with bob" and it works out, from what you've
done in the past, when you take lunch, who the "Bob" that you most
frequently contact is, adds an appointment in your diary shared with him
and sends him an email with the times in.
Or draw a flowchart and it turns your wobbly freehand lines into neat
crisp shape objects, manipulable with the pen.
Or write text and have it become editable print.
Or any mixture.
In conception, it makes Windows 8 look like a VIC20.
So the big question is, why did all this stuff fail? Why did we get
scaled-up CP/M boxes instead, running "a knockoff of a 1970s operating
system well past its sell-by date." (http://www.loper-os.org/?p=69)
Well, partly, because it was slower and less efficient.
But that doesn't matter that much any more, because now we have vastly
more power and most of it's going unused in idle CPU cores. Now, the
dreams of the 1970s and 1980s are eminently doable, whereas we don't have
any big fresh new ideas. We're reduced to stripping out all the complexity
from our desktop OSes to make them fathomable to ordinary people by
stroking little glass slabs without hardware buttons.
> Second, from the POV of machine architecture, the dominant
> architecture is, compared with some of the older alternatives,
> somewhat RISC-like.
"The aim of Loper is to build a sane computing environment on top of the
ubiquitous yet nauseatingly flawed X86-64 architecture. I believe that it
is possible to abstract away its most damning shortcomings, such as the
lack of direct hardware support for capabilities, orthogonal persistence,
type-checking, and garbage collection."
http://www.loper-os.org/?p=33
> The Big Question is whether something based on
> e.g. an internal Lisp organisation could be equally efficient at
> representing code fragments, and at least as efficient when it came
> to representing a rich OS and application bundle.
Mu.
While it's an interesting question, I'm not sure it's entirely a useful
one. We have what we have; let's see if there's a smarter way to use it.
> Third, from the POV of the existing code corpus, there's a vast
> amount of legacy C and C++ code around, much of it in daily use,
> and most unmaintainable except by the original author. There's a
> smaller amount of BASIC, Pascal, APL, Prolog and so on. The Big
> Question
What, another one? :¬)
> is whether something based on e.g. an internal Lisp
> organisation could be unconditionally compatible with the existing
> corpus, or at the very least with stuff that was expected to run at
> an application level (i.e. ignoring device drivers and so on).
It possibly could - LispMs ran other languages - but I am not proposing
replacing our current CPUs. I'm proposing a different kind of software
environment that replaces our current OSes and apps. It would almost
certainly be worse at doing the sort of stuff current OSes do, and its
likeliest role for most people might be running in a VM under Linux or
something, with the host OS doing mundane stuff like browsing the WWW and
editing MS Word files.
> less they should be trusted. But I think you're reaching the same
> conclusion.
Well, yes...
> First, from a "wisdom of the ancients" POV: what have we lost out
> on?
That's what I am trying to work on elucidating, understanding and finding
out how to explain.
In general, because I don't yet know enough to have any alternative, I
have no recourse except to be vague and hand-wavey:
What we have now are very fast, very capacious, very very stupid
computers. What ought to be arcane internal concepts are exposed at the UI
and users have to learn to manipulate them: files, folders, file *types*,
documents, binaries and executables, source code, interpreters versus
compilers, and so on.
As Stanislav Datskovskiy put it in http://www.loper-os.org/?p=55 :
<<
The computers we now use are descended from 1980s children’s toys. Their
level of bedrock abstraction is an exceedingly low one. This would be
acceptable in a micro with 64K of RAM, but when scaled up to present
proportions it is a nightmare of multi-gigabyte bloat and decay.
>>
We run a big program which we use to navigate among a collection of
different, separate, smaller programs, which we run and then use to open
data files, manipulate their contents, then save them. Then we use client
programs to send messages over network protocols to remote servers.
And ordinary people are expected to keep track of all this, to learn these
concepts and become fluent with them.
To nerds and geeks, it's easy, and we have become so used to this stuff
that we are blind to the fact that it is /profoundly/ arcane and abstruse.
What we have are not the descendants of the big powerful multiuser systems
of the 1960s and 1970s. No, what happened was that the tech got cheap
enough for tiny, rudimentary, simplistic, brain-damaged versions to be
sold as toys. And then those toys have grown and been enlarged and
expanded and made thousands of times faster, without learning any of the
lessons of the computers from pre-toy times.
Those big '60s and '70s machines were horribly clunky, yes, but they had
solved (or at least had answers to) important problems to do with
security, permissions, parallelism, portability and more, none of which
have come across and which are being re-invented on all sides today.
Even obscure failed micro operating systems made important advances that
have been ignored. There is no technical reason why executable programs
should be tied to an underlying CPU architecture; Taos showed this. There
is no technical reason that it should make any difference what machine on
a network a resource (storage, processing, data) is on; that kind of thing
should be transparent to the user. Perhaps not to the admin, no, but users
should not have to know. Plan 9 demonstrated this, and Inferno added
Java-style binary portability to the mix. They still failed.
If the user needs to know about file formats, about markup, about server
names or what program handles what file, about how to move information
between programs, about what kind of computer can run what kind of
program, about any of this kind of low-level techie wank, then we have
failed.
And this means we have all failed. We have all worked at some point in the
chain between making chips and delivering products to buyers. And we have
singularly screwed the pooch. We've taken the easiest, simplest, stupidest
way and delivered sad broken crap that has not actually improved in what
it does since about 1975. All it's done is got cheaper and quicker.
So don't ask about what will it do better that my current computer does.
Don't ask about performance. Performance is not the criterion that
matters. It's like judging a pen by how fast it can lay down ink:
http://www.loper-os.org/?p=300
Now, doubtless, you'll want concrete examples and I can't give them, not
yet. I'm still working on it.
But moving aside from the LispM model, which is a sort of information
appliance for programmers, there's Jef Raskin's work on the Canon Cat and
the Swyft UI:
http://www.jagshouse.com/swyft.html
http://oldcomputers.net/canon-cat.html
It doesn't have programs, it doesn't have files, it has no distinction
between OS and apps. If you type text, you can format it and lay it out.
If you type expressions, you can evaluate them. If you type a grid of
numbers, you can apply operations to blocks of them (i.e., what a
standalone spreadsheet does).
As planned, it would be able to send data to other people, and you could
obtain new methods and capabilities from other vendors and integrate them
into your system... but Canon crippled or removed all that.
A richer, more sophisticated example was the Apple Newton, conceived of as
a pocket info appliance. The original design for the Newton was a pocket
Lisp Machine, but with an algebraic-notation Lisp called Dylan with an
insanely rich desktop development UI that makes Visual Studio look like
Edlin.
It got canned. They then came up with the much simpler NewtonScript and
wrote it in that.
No files, no folders and a UI driven by a pen and natural language. Go to
the "do" box and write "lunch with bob" and it works out, from what you've
done in the past, when you take lunch, who the "Bob" that you most
frequently contact is, adds an appointment in your diary shared with him
and sends him an email with the times in.
Or draw a flowchart and it turns your wobbly freehand lines into neat
crisp shape objects, manipulable with the pen.
Or write text and have it become editable print.
Or any mixture.
In conception, it makes Windows 8 look like a VIC20.
So the big question is, why did all this stuff fail? Why did we get
scaled-up CP/M boxes instead, running "a knockoff of a 1970s operating
system well past its sell-by date." (http://www.loper-os.org/?p=69)
Well, partly, because it was slower and less efficient.
But that doesn't matter that much any more, because now we have vastly
more power and most of it's going unused in idle CPU cores. Now, the
dreams of the 1970s and 1980s are eminently doable, whereas we don't have
any big fresh new ideas. We're reduced to stripping out all the complexity
from our desktop OSes to make them fathomable to ordinary people by
stroking little glass slabs without hardware buttons.
> Second, from the POV of machine architecture, the dominant
> architecture is, compared with some of the older alternatives,
> somewhat RISC-like.
"The aim of Loper is to build a sane computing environment on top of the
ubiquitous yet nauseatingly flawed X86-64 architecture. I believe that it
is possible to abstract away its most damning shortcomings, such as the
lack of direct hardware support for capabilities, orthogonal persistence,
type-checking, and garbage collection."
http://www.loper-os.org/?p=33
> The Big Question is whether something based on
> e.g. an internal Lisp organisation could be equally efficient at
> representing code fragments, and at least as efficient when it came
> to representing a rich OS and application bundle.
Mu.
While it's an interesting question, I'm not sure it's entirely a useful
one. We have what we have; let's see if there's a smarter way to use it.
> Third, from the POV of the existing code corpus, there's a vast
> amount of legacy C and C++ code around, much of it in daily use,
> and most unmaintainable except by the original author. There's a
> smaller amount of BASIC, Pascal, APL, Prolog and so on. The Big
> Question
What, another one? :¬)
> is whether something based on e.g. an internal Lisp
> organisation could be unconditionally compatible with the existing
> corpus, or at the very least with stuff that was expected to run at
> an application level (i.e. ignoring device drivers and so on).
It possibly could - LispMs ran other languages - but I am not proposing
replacing our current CPUs. I'm proposing a different kind of software
environment that replaces our current OSes and apps. It would almost
certainly be worse at doing the sort of stuff current OSes do, and its
likeliest role for most people might be running in a VM under Linux or
something, with the host OS doing mundane stuff like browsing the WWW and
editing MS Word files.
