Ethiopian kids vs GUI (yes, there's an ObSF)

[Cryptoengineer]

Not everyone finds GUIs as difficult as Keith does....

ObSF: Stephenson's "Diamond Age", IRL.

http://dvice.com/archives/2012/10/ethiopian-kids.php
http://www.technologyreview.com/news/506466/given-tablets-but-no-teachers-ethiopian-children-teach-themselves/

- start quote -

Rather than give out laptops (they're actually Motorola Zoom tablets
plus solar chargers running custom software) to kids in schools with
teachers, the OLPC Project decided to try something completely
different: it delivered some boxes of tablets to two villages in
Ethiopia, taped shut, with no instructions whatsoever. Just like, "hey
kids, here's this box, you can open it if you want, see ya!"

[...]

"We left the boxes in the village. Closed. Taped shut. No instruction,
no human being. I thought, the kids will play with the boxes! Within
four minutes, one kid not only opened the box, but found the on/off
switch. He'd never seen an on/off switch. He powered it up. Within
five days, they were using 47 apps per child per day. Within two
weeks, they were singing ABC songs [in English] in the village. And
within five months, they had hacked Android. Some idiot in our
organization or in the Media Lab had disabled the camera! And they
figured out it had a camera, and they hacked Android."

- end quote -

pt

[Christopher J. Henrich]

In article
<e044d3ab-d3d6-4b9f...@m4g2000yqf.googlegroups.com>,

Cryptoengineer <pete...@gmail.com> wrote:

> Not everyone finds GUIs as difficult as Keith does....

ObTomLehrer:

They're so simple -- so very simple --
That only a child can do them!

--
Chris Henrich
http://www.mathinteract.com
"Those readers who are unacquainted with the mathematical technicalities will
find that they can manage quite well by ignoring them."
-- John Nash

[Jette Goldie]

On 01/11/2012 19:12, Christopher J. Henrich wrote:
> In article
> <e044d3ab-d3d6-4b9f...@m4g2000yqf.googlegroups.com>,
> Cryptoengineer <pete...@gmail.com> wrote:
>
>> Not everyone finds GUIs as difficult as Keith does....
> ObTomLehrer:
>
> They're so simple -- so very simple --
> That only a child can do them!
>

of course if you learned to work originally without them, they may not
be as "intuitive" to you. Like AOL - I have several friends whose first
internet experience was with AOL and the AOL interface is "intuitive" to
them - so that they found it hard to learn how to use non-AOL software.
Whereas if you first went online with other systems, the AOL interface
is confusing and hard to learn.


--
Jette Goldie
jgold...@btinternet.com

Living in the Future!

[Philip Chee]

Yesterday at the local mall, Samsung was having an exhibition of their
latest and greatest gadgets (SIII, etc). And there was this girl about
three or four happily tapping and swiping through all the features on a
small Galaxy note with great confidence, almost as if she had been born
with a phablet in her hands.

I don't think she's managed to hack into the camera yet, but it's
probably just a matter of time.

Phil

--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.

[Cryptoengineer]

On Nov 1, 4:21 pm, Jette Goldie <jgoldie...@btinternet.com> wrote:
> On 01/11/2012 19:12, Christopher J. Henrich wrote:
>
> > In article

> > <e044d3ab-d3d6-4b9f-8825-a2b0cdd9f...@m4g2000yqf.googlegroups.com>,

> > Cryptoengineer <petert...@gmail.com> wrote:
>
> >> Not everyone finds GUIs as difficult as Keith does....
> > ObTomLehrer:
>
> > They're so simple -- so very simple --
> > That only a child can do them!
>
> of course if you learned to work originally without them, they may not
> be as "intuitive" to you.  Like AOL - I have several friends whose first
> internet experience was with AOL and the AOL interface is "intuitive" to
> them - so that they found it hard to learn how to use non-AOL software.
>   Whereas if you first went online with other systems, the AOL interface
> is confusing and hard to learn.

'Intuitive' is a very fuzzy term. I've had to deal with several
paradigm shifts in how I use computers over the years. I first learned
programming in BASIC and assembler on a PDP-8, then learned FORTRAN on
a CDC 6600. These are all 'spaghetti code' languages (assembly
slightly less so). I then had to move on to procedural languages, with
SAIL, Pascal, Modula-2, which was a big change (What? No GOTOs?!).
Later, I learned object oriented languages (C++, Java, etc). Now, I'm
getting into functional programming with Haskell, and a custom
language we're creating for my project.

Environmentally, I had to go from TTYs with paper tape, to CLI
interfaces (TOPS-20, Unix, VMS, etal) to GUIs (various flavors of
Windows, MacOS, Gnome, KDE etc), and for programming from the BASIC
interpreter to emacs/gcc/gdb to IDEs.

None of these shifts were 'intuitive'. I too struggled with GUIs when
they first appeared. But I learned, and moved on.

You have to, if you want to stay employed.

pt

[Lowell Gilbert]

Cryptoengineer <pete...@gmail.com> writes:

> 'Intuitive' is a very fuzzy term.

Good grief, yes...

[David Harmon]

On Fri, 2 Nov 2012 07:54:30 -0700 (PDT) in rec.arts.sf.fandom,
Cryptoengineer <pete...@gmail.com> wrote,

>'Intuitive' is a very fuzzy term.

Only because Keith stubbornly insists on getting it wrong. He is
looking for "instinctive", meaning something he is born knowing
(homo sapiens has few of those.) "Intuitive" is, after you learn it
then you no longer have to consciously think about it.

[Paul Dormer]

In article
<eb9baa39-1793-4efe...@c17g2000yqe.googlegroups.com>,

pete...@gmail.com (Cryptoengineer) wrote:

>
> 'Intuitive' is a very fuzzy term. I've had to deal with several
> paradigm shifts in how I use computers over the years. I first learned
> programming in BASIC and assembler on a PDP-8, then learned FORTRAN on
> a CDC 6600. These are all 'spaghetti code' languages (assembly
> slightly less so). I then had to move on to procedural languages, with
> SAIL, Pascal, Modula-2, which was a big change (What? No GOTOs?!).
> Later, I learned object oriented languages (C++, Java, etc). Now, I'm
> getting into functional programming with Haskell, and a custom
> language we're creating for my project.

Back in the late eighties, I was asked to make some modifications to a
program written about ten years earlier. I got a great shock when I
looked at the code. It was written in Coral 66, a language developed in
the UK for real time programming (and similar to Algol 60). It was a
large program. There was only one procedure call in its entirety.

In the ten years between it being written and when I was asked to modify
it, there had been a huge change in how we programmed in our department.
But, I remembered, I used to program like that back then.

As it happened, it wasn't a program I'd worked on back then but I was the
only person still programming who'd been active when it was written. The
guy who did write it was now my boss.

>
> Environmentally, I had to go from TTYs with paper tape, to CLI
> interfaces (TOPS-20, Unix, VMS, etal) to GUIs (various flavors of
> Windows, MacOS, Gnome, KDE etc), and for programming from the BASIC
> interpreter to emacs/gcc/gdb to IDEs.

The reason that the program had to be changed was that it output a paper
tape to be loaded to a device called a PROM blaster. The computer it ran
on was being upgraded, and the new one didn't have a tape punch, but you
could drive a PROM blaster directly.

[David Dyer-Bennet]

p...@pauldormer.cix.co.uk (Paul Dormer) writes:

> In article
> <eb9baa39-1793-4efe...@c17g2000yqe.googlegroups.com>,
> pete...@gmail.com (Cryptoengineer) wrote:
>
>>
>> 'Intuitive' is a very fuzzy term. I've had to deal with several
>> paradigm shifts in how I use computers over the years. I first learned
>> programming in BASIC and assembler on a PDP-8, then learned FORTRAN on
>> a CDC 6600. These are all 'spaghetti code' languages (assembly
>> slightly less so). I then had to move on to procedural languages, with
>> SAIL, Pascal, Modula-2, which was a big change (What? No GOTOs?!).
>> Later, I learned object oriented languages (C++, Java, etc). Now, I'm
>> getting into functional programming with Haskell, and a custom
>> language we're creating for my project.
>
>
> Back in the late eighties, I was asked to make some modifications to a
> program written about ten years earlier. I got a great shock when I
> looked at the code. It was written in Coral 66, a language developed in
> the UK for real time programming (and similar to Algol 60). It was a
> large program. There was only one procedure call in its entirety.
>
> In the ten years between it being written and when I was asked to modify
> it, there had been a huge change in how we programmed in our department.
> But, I remembered, I used to program like that back then.

When was this program written, and what 10 years was that span? I
remember finding pre-existing assembler programs in my first job making
considerable use of subroutines, and we certainly did that a LOT in the
stuff I wrote, and the later BASIC-PLUS code I wrote there. That was
1969-1977.

Structured programming was coming along to put some basis over this
preference, as I recall.

--
Googleproofaddress(account:dd-b provider:dd-b domain:net)
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info

[Paul Dormer]

In article <ylfkk3u3...@dd-b.net>, dd...@dd-b.net (David Dyer-Bennet)
wrote:

>
> > Back in the late eighties, I was asked to make some modifications
> > to a program written about ten years earlier.
>

> When was this program written, and what 10 years was that span?

I did say. To be more precise, I think this would have been about 1988-9
and the program written about 1976-7 but I wasn't involved in the
original project, so I can't be sure about the latter.

[Keith F. Lynch]

David Dyer-Bennet <dd...@dd-b.net> wrote:
> I remember finding pre-existing assembler programs in my first job
> making considerable use of subroutines, and we certainly did that
> a LOT in the stuff I wrote, and the later BASIC-PLUS code I wrote
> there. That was 1969-1977.

The original "Goto Considered Harmful" article dates to 1968. Of
course the ideas behind structured programming were floating around
long before that.
--
Keith F. Lynch - http://keithlynch.net/
Please see http://keithlynch.net/email.html before emailing me.

[Keith F. Lynch]

David Harmon <b...@example.invalid> wrote:
> Cryptoengineer <pete...@gmail.com> wrote,
>> 'Intuitive' is a very fuzzy term.

> Only because Keith stubbornly insists on getting it wrong. He is
> looking for "instinctive", meaning something he is born knowing
> (homo sapiens has few of those.) "Intuitive" is, after you learn
> it then you no longer have to consciously think about it.

Dictionaries disagree with you. Anyhow, by your definition
*everything* is intuitive.

[Scott Dorsey]

Keith F. Lynch <k...@KeithLynch.net> wrote:
>David Dyer-Bennet <dd...@dd-b.net> wrote:
>> I remember finding pre-existing assembler programs in my first job
>> making considerable use of subroutines, and we certainly did that
>> a LOT in the stuff I wrote, and the later BASIC-PLUS code I wrote
>> there. That was 1969-1977.
>
>The original "Goto Considered Harmful" article dates to 1968. Of
>course the ideas behind structured programming were floating around
>long before that.

But, here it is 2012 and half the folks I work with are writing
horrible unreadable spaghetti in Matlab.

And yes, they have figured out functions, but not always optimally.
One of them is prone to making functions which do one of two
unrelated things, predicated on the state of a global variable.
--scott


--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Cryptoengineer]

On Nov 7, 9:50 pm, klu...@panix.com (Scott Dorsey) wrote:
> Keith F. Lynch <k...@KeithLynch.net> wrote:
>

> >David Dyer-Bennet <d...@dd-b.net> wrote:
> >> I remember finding pre-existing assembler programs in my first job
> >> making considerable use of subroutines, and we certainly did that
> >> a LOT in the stuff I wrote, and the later BASIC-PLUS code I wrote
> >> there.  That was 1969-1977.
>
> >The original "Goto Considered Harmful" article dates to 1968.  Of
> >course the ideas behind structured programming were floating around
> >long before that.
>
> But, here it is 2012 and half the folks I work with are writing
> horrible unreadable spaghetti in Matlab.
>
> And yes, they have figured out functions, but not always optimally.
> One of them is prone to making functions which do one of two
> unrelated things, predicated on the state of a global variable.
> --scott

...and yet operator overloading is considered a sane activity in some
circles.....

pt

[Keith F. Lynch]

Scott Dorsey <klu...@panix.com> wrote:
> Keith F. Lynch <k...@KeithLynch.net> wrote:
>> The original "Goto Considered Harmful" article dates to 1968. Of
>> course the ideas behind structured programming were floating around
>> long before that.

> But, here it is 2012 and half the folks I work with are writing
> horrible unreadable spaghetti in Matlab.

I'm not familiar with that language. Does it enable structured
programming? If so, how does your employer decide who to hire
as programmers?

> And yes, they have figured out functions, but not always optimally.
> One of them is prone to making functions which do one of two
> unrelated things, predicated on the state of a global variable.

How unrelated is unrelated? Overloading can be reasonable, e.g.
integer division and floating division. But only when there's some
logical relation.

[Scott Dorsey]

Keith F. Lynch <k...@KeithLynch.net> wrote:
>Scott Dorsey <klu...@panix.com> wrote:
>> Keith F. Lynch <k...@KeithLynch.net> wrote:
>>> The original "Goto Considered Harmful" article dates to 1968. Of
>>> course the ideas behind structured programming were floating around
>>> long before that.
>
>> But, here it is 2012 and half the folks I work with are writing
>> horrible unreadable spaghetti in Matlab.
>
>I'm not familiar with that language. Does it enable structured
>programming? If so, how does your employer decide who to hire
>as programmers?

It's a mathematical analysis package that has a somewhat curious interpreted
language attached to it. It is the dominant prototyping language for
engineering work today. Georgia Tech is now using it in their freshman
programming classes for non-CS students, for example.

It, like every language, enables structured programming. I have taught
structured fortran and structured assembler. Structured programming is
in the way you think about coding, and if your while loop has to be implemented
in code as a CMP and a DJNZ, it's still a while loop.

My employer does not hire programmers any more. My employer hires engineers,
who do their own programming. A decade ago it was routine for the engineer
to be sitting down with a a programmer as a working team, but today that is
gone.

[Keith F. Lynch]

Scott Dorsey <klu...@panix.com> wrote:
> It, like every language, enables structured programming. I have
> taught structured fortran and structured assembler. Structured
> programming is in the way you think about coding, and if your while
> loop has to be implemented in code as a CMP and a DJNZ, it's still a
> while loop.

I recall reading that 6502 machine language was so badly designed that
hardly anyone ever bothered to compile anything into it. Instead they
compiled into something called p-code which was interpreted.

> My employer does not hire programmers any more. My employer hires
> engineers, who do their own programming. A decade ago it was
> routine for the engineer to be sitting down with a a programmer
> as a working team, but today that is gone.

Sounds like a bad decision. Almost as bad as having programmers do
their own (non-software) engineering.

Of course some people are good at both, but most aren't.

[Cryptoengineer]

On Nov 10, 3:55 pm, "Keith F. Lynch" <k...@KeithLynch.net> wrote:
> Scott Dorsey <klu...@panix.com> wrote:
> > It, like every language, enables structured programming.  I have
> > taught structured fortran and structured assembler.  Structured
> > programming is in the way you think about coding, and if your while
> > loop has to be implemented in code as a CMP and a DJNZ, it's still a
> > while loop.
>
> I recall reading that 6502 machine language was so badly designed that
> hardly anyone ever bothered to compile anything into it.  Instead they
> compiled into something called p-code which was interpreted.

My memory of actual programming on the 6502 is at odds with what Keith
'recalls reading'., I agree it was pretty limited, but it was Turing
complete. I was one of the creators the Apple Kermit, written in 6502
assembler.

p-code was used by UCSD Pascal, with the goal of virtual machine, with
a common OS and programming environment the ran on many of the popular
personal computers of the time (the late 70s). No doubt that a p-
machine programmer wrote the article Keith recalls.

pt

[rksh...@rosettacondot.com]

Keith F. Lynch <k...@keithlynch.net> wrote:
> Scott Dorsey <klu...@panix.com> wrote:
>> It, like every language, enables structured programming. I have
>> taught structured fortran and structured assembler. Structured
>> programming is in the way you think about coding, and if your while
>> loop has to be implemented in code as a CMP and a DJNZ, it's still a
>> while loop.
>
> I recall reading that 6502 machine language was so badly designed that
> hardly anyone ever bothered to compile anything into it. Instead they
> compiled into something called p-code which was interpreted.

You're probably thinking of the UCSD p-System. It was designed for
portability rather than to work around any weakness in a specific
processor. Compilers produced machine-indepdent p-code which was fed into
a machine-specific interpreter. I used both UCSD Fortran and Pascal on
the Apple II+/IIe to do all of my intro CS assignments. That would have
been around 1983.
I'm not sure how much, if any, commercial code for the Apple II was
compiled. I used assembly any time I needed speed.

Robert
--
Robert K. Shull Email: rkshull at rosettacon dot com

[Andy Leighton]

On Sat, 10 Nov 2012 13:48:04 -0800 (PST),
Cryptoengineer <pete...@gmail.com> wrote:
> On Nov 10, 3:55 pm, "Keith F. Lynch" <k...@KeithLynch.net> wrote:
>> Scott Dorsey <klu...@panix.com> wrote:
>> > It, like every language, enables structured programming.  I have
>> > taught structured fortran and structured assembler.  Structured
>> > programming is in the way you think about coding, and if your while
>> > loop has to be implemented in code as a CMP and a DJNZ, it's still a
>> > while loop.
>>
>> I recall reading that 6502 machine language was so badly designed that
>> hardly anyone ever bothered to compile anything into it.  Instead they
>> compiled into something called p-code which was interpreted.
>
> My memory of actual programming on the 6502 is at odds with what Keith
> 'recalls reading'., I agree it was pretty limited, but it was Turing
> complete. I was one of the creators the Apple Kermit, written in 6502
> assembler.

There was definitely a native code Pascal compiler for the Beeb.

Generally however the 6502's addressing modes (in particular in relation
to its stack ISTR) made implementing quite a lot of languages (especially
stuff like Pascal and C) rather tricky. You could do it, but the results
were not pretty, and produced rather sub-optimal code.

As writing code in assembler was pretty easy a lot of people didn't
actually need a compiler.

--
Andy Leighton => an...@azaal.plus.com
"The Lord is my shepherd, but we still lost the sheep dog trials"
- Robert Rankin, _They Came And Ate Us_

[Keith F. Lynch]

<rksh...@rosettacondot.com> wrote:
> You're probably thinking of the UCSD p-System. It was designed for
> portability rather than to work around any weakness in a specific
> processor.

Yes. Though with machines as slow as they were in those days, you'd
think speed would be a much higher priority than portability.

I remember when my boss got tired of paying for CPU time on a
mainframe, and had me convert some simulation code to run on his
new Apple ][. I did so, but there were several problems:

* The 6502 didn't have built-in floating point. That had to be
emulated in software. That code was already built in, but it
slowed everything down.

* The system didn't have a trig library, so I had to write my own.
And I didn't know what I was doing, so I coded it using the Taylor
series. Mathematically sound, but painfully slow except for very
small angles. (What can I say? This was more than 30 years ago.
I've long since learned better ways of caculating trig functions.)

* The compiler compiled into p-code, which then had to be interpreted.
That slowed things down a lot.

* The 6502 instruction set was impoverished.

* The machine ran at just 1 Mhz.

I'm sure you can see where this is going.

If at that time, over 30 years ago, I'd started one of the simpler
simulations, one that took about a minute of CPU time on the CDC
Cyber, it would probably still be running today.

[Scott Dorsey]

Cryptoengineer <pete...@gmail.com> wrote:
>
>My memory of actual programming on the 6502 is at odds with what Keith
>'recalls reading'., I agree it was pretty limited, but it was Turing
>complete. I was one of the creators the Apple Kermit, written in 6502
>assembler.

It was not as clean as Z-80 assembler, but it was not horrible to program
in and it was a big step up from PDP-8 assembler.

>p-code was used by UCSD Pascal, with the goal of virtual machine, with
>a common OS and programming environment the ran on many of the popular
>personal computers of the time (the late 70s). No doubt that a p-
>machine programmer wrote the article Keith recalls.

Note that there were some other virtual machines used at the time. The
earlier Apple II intbasic roms came with a 16-bit machine code interpreter
called "Sweet-16." I don't think many people used it seriously for
production code, though.

[Scott Dorsey]

Keith F. Lynch <k...@KeithLynch.net> wrote:

>I remember when my boss got tired of paying for CPU time on a
>mainframe, and had me convert some simulation code to run on his
>new Apple ][. I did so, but there were several problems:
>
>* The 6502 didn't have built-in floating point. That had to be
> emulated in software. That code was already built in, but it
> slowed everything down.

This is true. And, the programming languages most folks used at the
time did not have good features to make fixed-point math easy.

>* The system didn't have a trig library, so I had to write my own.
> And I didn't know what I was doing, so I coded it using the Taylor
> series. Mathematically sound, but painfully slow except for very
> small angles. (What can I say? This was more than 30 years ago.
> I've long since learned better ways of caculating trig functions.)

I gather from the mention of "p-code" that you were using the
Apple Pascal System, which was a port of the UCSD P-code. If this
was the case, you need to use the pragma UNIT TRANSCEND to request
transcendental functions like sine and cosine.

However, the transcendental functions are written in Pascal and compiled
down to p-code so they are not as fast as native versions would be.

>* The compiler compiled into p-code, which then had to be interpreted.
> That slowed things down a lot.

This is true.

>* The 6502 instruction set was impoverished.
>
>* The machine ran at just 1 Mhz.
>
>I'm sure you can see where this is going.

You'd have done much better just to use interpreted BASIC. I did a
satellite tracking system on a Commodore 64... it took about five minutes
to spit out a current position given time and the Keplarian elements,
which was just fine. The BASIC interpreter has the transcendental functions
implemented directly in assembler, and in pretty tightly optimized assembler
too, so in spite of the interpreter overhead it can be a big win if you are
doing something floating-point on an 8-bit micro.

I still do a lot of that today. I am currently calculating air velocity
in three-space given propagation times of an ultrasonic pulse in three
different directions (not parallel to the three axes), using an 8051.
There's plenty of CPU available.

>If at that time, over 30 years ago, I'd started one of the simpler
>simulations, one that took about a minute of CPU time on the CDC
>Cyber, it would probably still be running today.

Well, if you were running it on a Cyber you had a different set of horrible
coding issues there, too.

[rksh...@rosettacondot.com]

Keith F. Lynch <k...@keithlynch.net> wrote:

> <rksh...@rosettacondot.com> wrote:
>> You're probably thinking of the UCSD p-System. It was designed for
>> portability rather than to work around any weakness in a specific
>> processor.
>
> Yes. Though with machines as slow as they were in those days, you'd
> think speed would be a much higher priority than portability.

For production code, yes. But the p-System was designed primarily for
education...generally short programs with very limited execution time
that got thrown away as soon as they were graded. None of the ones I
wrote ran for more than a few seconds.
The p-System meant that only the interpreter needed to be written for a
new platform. The rest of the environment would port over easily.

> I remember when my boss got tired of paying for CPU time on a
> mainframe, and had me convert some simulation code to run on his
> new Apple ][. I did so, but there were several problems:

> ...

> If at that time, over 30 years ago, I'd started one of the simpler
> simulations, one that took about a minute of CPU time on the CDC
> Cyber, it would probably still be running today.

A classic case of wrong tool(s) for the job. Not uncommon...I've spent
(and seen spent) a lot of time, effort and eventually money on
inappropriate hardware and software that happened to be "free".

[Andy Leighton]

On 11 Nov 2012 13:20:23 -0500, Scott Dorsey <klu...@panix.com> wrote:
> Keith F. Lynch <k...@KeithLynch.net> wrote:
>>I remember when my boss got tired of paying for CPU time on a
>>mainframe, and had me convert some simulation code to run on his
>>new Apple ][. I did so, but there were several problems:
>>
>>* The 6502 didn't have built-in floating point. That had to be
>> emulated in software. That code was already built in, but it
>> slowed everything down.
>
> This is true. And, the programming languages most folks used at the
> time did not have good features to make fixed-point math easy.

Although to be honest it wasn't anything remarkable. I cannot think
of any 8 bit micro-processor of the time that had floating point.
On board floating point was quite late to the party. The Motorola
680000 didn't have it until the 68040 in 1990. Intel didn't have it
on the x86 until the 80486 in 1989. The 6502 was a 1975 era chip.

[Keith F. Lynch]

Andy Leighton <an...@azaal.plus.com> wrote:
> Although to be honest it wasn't anything remarkable.

Nobody said it was.

> I cannot think of any 8 bit micro-processor of the time that had
> floating point. On board floating point was quite late to the
> party. The Motorola 680000 didn't have it until the 68040 in 1990.
> Intel didn't have it on the x86 until the 80486 in 1989. The 6502
> was a 1975 era chip.

Indeed. When I bought an 80286 machine in 1985, I made sure it had an
80287 co-processor for floating point arithmetic.

[Scott Dorsey]

Andy Leighton <an...@azaal.plus.com> wrote:
>
>Although to be honest it wasn't anything remarkable. I cannot think
>of any 8 bit micro-processor of the time that had floating point.

Nobody had floating point on a micro until the 8087 came out, and the
8087 was nothing short of a miracle. Lot of folks managed to graft
the 8087 onto the side of microprocessors (such as the Z-80) which were
never intended for it.

>On board floating point was quite late to the party. The Motorola
>680000 didn't have it until the 68040 in 1990. Intel didn't have it
>on the x86 until the 80486 in 1989. The 6502 was a 1975 era chip.

In 1975 there were a million competing floating point standards and
nobody could even agree on how big the exponents and mantissas should
be. The IEEE floating point standard, in conjunction with the 8087,
provided the first real inter-vendor floating point compatibility
anywhere, ever. And the microcomputer industry was first! It was
nothing short of a bloody miracle.

[David Harmon]

On Sat, 10 Nov 2012 13:48:04 -0800 (PST) in rec.arts.sf.fandom,
Cryptoengineer <pete...@gmail.com> wrote,
>

>My memory of actual programming on the 6502 is at odds with what Keith
>'recalls reading'., I agree it was pretty limited, but it was Turing
>complete. I was one of the creators the Apple Kermit, written in 6502
>assembler.

It is surely possible that some idiot wrote such nonsense and Keith
once read it.

[Mark Zenier]

In article <k7mf0v$12g$7...@reader1.panix.com>,

Keith F. Lynch <k...@KeithLynch.net> wrote:

>Scott Dorsey <klu...@panix.com> wrote:
>> It, like every language, enables structured programming. I have
>> taught structured fortran and structured assembler. Structured
>> programming is in the way you think about coding, and if your while
>> loop has to be implemented in code as a CMP and a DJNZ, it's still a
>> while loop.
>
>I recall reading that 6502 machine language was so badly designed that
>hardly anyone ever bothered to compile anything into it. Instead they
>compiled into something called p-code which was interpreted.

(All I ever did was write a cross assembler for it...)

For high level language support, it kind of sucked. As I remember
(I dont' feel like digging out the Mos Technology hardware book), it
only had an 8 bit stack register. And flags that only supported
unsigned arithmetic.

But (at least one faction of) the compulsive puzzle-solving bit-nuts
LOVED it. It had some useful addressing modes and little endian two
byte addresses and other speed ups so that it was 20%-50% faster than
the Motorola 6800 that it was an offshoot from. Add some undocumented*
instructions that did interesting things, and a really cheap price and
it got stuck into a lot of stuff.

* (illegal instruction fault? What illegal instruction fault? We're
talking a chip designed for the minimum area of silicon, here).

Probably the most heroic programming would have been in games for the
Atari and Commodore home computers. (I remember one on the Atari 800
that had a perspective view of a 3D animated chess board with chess
pieces zipping around on it. One of those "How the F*** did they do
that on THAT machine" moments).

Ah, the happy days of drag racing bicycles (~1 microsecond cycle
time processors).

Mark Zenier mze...@eskimo.com
Googleproofaddress(account:mzenier provider:eskimo domain:com)

[Keith F. Lynch]

David Harmon <b...@example.invalid> wrote:
> Cryptoengineer <pete...@gmail.com> wrote,
>> My memory of actual programming on the 6502 is at odds with what
>> Keith 'recalls reading'., I agree it was pretty limited, but it
>> was Turing complete. I was one of the creators the Apple Kermit,
>> written in 6502 assembler.

Obviously it's Turing complete, otherwise an additional level of
abstratction (e.g. p-code) couldn't help.

However, some things that a Turing complete are very difficult to
program in. For instance Intercal. Or Conway's Life.

> It is surely possible that some idiot wrote such nonsense and Keith
> once read it.

I was careful to express no opinion on the subject. I've never
programmed in 6502 assembler.

[Keith F. Lynch]

Scott Dorsey <klu...@panix.com> wrote:
> In 1975 there were a million competing floating point standards
> and nobody could even agree on how big the exponents and mantissas
> should be.

That was no reason not to have floating point. So what if raw
floating point data was in different formats on different machines?

[David Goldfarb]

In article <k7s35d$9d3$1...@reader1.panix.com>,

Keith F. Lynch <k...@KeithLynch.net> wrote:

>I was careful to express no opinion on the subject. I've never
>programmed in 6502 assembler.

Oddly enough, I have, though since I was in grade school at the time
I really don't feel qualified to have an opinion on whether it was
well or poorly designed.

--
David Goldfarb |"Newsgroups trimmed back to rec.arts.sf.written,
goldf...@gmail.com | in the hope of subverting society's traditional
gold...@ocf.berkeley.edu | values in a more focussed, netiquette-aware
| fashion." -- Patrick Nielsen Hayden

[Scott Dorsey]

Keith F. Lynch <k...@KeithLynch.net> wrote:

>Scott Dorsey <klu...@panix.com> wrote:
>> In 1975 there were a million competing floating point standards
>> and nobody could even agree on how big the exponents and mantissas
>> should be.
>
>That was no reason not to have floating point. So what if raw
>floating point data was in different formats on different machines?

You get problems like code that gives totally different answers on
the vax, the /370, and the Cyber, even when the word length is the same.

IEEE p754 was a bloody miracle.

[Keith F. Lynch]

Scott Dorsey <klu...@panix.com> wrote:
> Keith F. Lynch <k...@KeithLynch.net> wrote:
>> That was no reason not to have floating point. So what if raw
>> floating point data was in different formats on different machines?

> You get problems like code that gives totally different answers on
> the vax, the /370, and the Cyber, even when the word length is the
> same.

You should get answers that differ by very little unless you're using
a bad algorithm. In fact, that's a good way of discovering that
you're suffering from total precision loss and that all your answers
are garbage.

You're going to get different answers on the Cyber regardless, as its
word length is *not* the same. Unless you know of some other 60-bit
architecture.

[David Dyer-Bennet]

"Keith F. Lynch" <k...@KeithLynch.net> writes:

> Scott Dorsey <klu...@panix.com> wrote:
>> In 1975 there were a million competing floating point standards
>> and nobody could even agree on how big the exponents and mantissas
>> should be.
>
> That was no reason not to have floating point. So what if raw
> floating point data was in different formats on different machines?

It wasn't feasible to integrate it in the first few generations of
microprocessors; takes too much die space. And for a while after that,
there was still a stronger demand for other uses of the space.

And people went to huge amounts of trouble to avoid floating point in
their algorithms, because it was *so much* slower, like orders of
magnitude. Which reduced the drive to include it in micro-processors.

Especially since using micro-processor as the CPU of a general-purpose
machine was quite unusual.
--
Googleproofaddress(account:dd-b provider:dd-b domain:net)
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info

[Scott Dorsey]

Keith F. Lynch <k...@KeithLynch.net> wrote:
>Scott Dorsey <klu...@panix.com> wrote:
>> Keith F. Lynch <k...@KeithLynch.net> wrote:
>> You get problems like code that gives totally different answers on
>> the vax, the /370, and the Cyber, even when the word length is the
>> same.
>
>You should get answers that differ by very little unless you're using
>a bad algorithm. In fact, that's a good way of discovering that
>you're suffering from total precision loss and that all your answers
>are garbage.

Now, instead we're going to get an underflow, when an underflow occurs.
That is much nicer than silently just getting the wrong answer. Underflow
handling was another one of the big things that came out of p754. It was
an eye-opener to folks porting code from the Vax to the Sun.

>You're going to get different answers on the Cyber regardless, as its
>word length is *not* the same. Unless you know of some other 60-bit
>architecture.

We took the 64-bit route with the Cyber 180 machines, which was not
necessarily the smart thing to do in the Cyber world.

[Scott Dorsey]

David Dyer-Bennet <dd...@dd-b.net> wrote:
>"Keith F. Lynch" <k...@KeithLynch.net> writes:
>
>> Scott Dorsey <klu...@panix.com> wrote:
>>> In 1975 there were a million competing floating point standards
>>> and nobody could even agree on how big the exponents and mantissas
>>> should be.
>>
>> That was no reason not to have floating point. So what if raw
>> floating point data was in different formats on different machines?
>
>It wasn't feasible to integrate it in the first few generations of
>microprocessors; takes too much die space. And for a while after that,
>there was still a stronger demand for other uses of the space.

Well, at the time, microprocessors weren't really taken seriously and the
micro industry was not the dominant force in the computer world. Probably
the first sign of that changing was in floating point.

A beautiful bit of history:
http://www.eecs.berkeley.edu/~wkahan/ieee754status/754story.html

[Keith F. Lynch]

Scott Dorsey <klu...@panix.com> wrote:
> Now, instead we're going to get an underflow, when an underflow
> occurs. That is much nicer than silently just getting the wrong
> answer.

That will catch some precision loss, but far from all of it.
Arguably, not even most of it.

[Doug Wickström]

On Tue, 13 Nov 2012 03:26:52 +0000 (UTC), "Keith F. Lynch"
<k...@KeithLynch.net> wrote:

>Unless you know of some other 60-bit
>architecture.

Perkin-Elmer.

--
Doug Wickström

[David Harmon]

On Tue, 13 Nov 2012 00:10:21 +0000 (UTC) in rec.arts.sf.fandom,
"Keith F. Lynch" <k...@KeithLynch.net> wrote,

>I was careful to express no opinion on the subject. I've never
>programmed in 6502 assembler.

I never did much, and that was a long time ago. If I recall
correctly, it was one small step better than the Motorola 6800
instruction set it was derived from, by virtue of having
more-usable index registers.

My computer at the time was a 8080.

[Andy Leighton]

I wouldn't say better. It was swings and roundabouts.

6800 only had 1 index register true (6502 had two) however it
was 16 bit, the 6502 only had 8 bit index registers.

The 6800 had 2 accumalators, the 6502 only had 1.

The 6800 had slightly more instructions, slightly less opcodes.

The 6800 had a 16 bit stack pointer, the 6502 had a 8 bit stack
pointer.

The 6502 tended to perform better at a given clockrate due to
factors other than its instruction set, and was much cheaper.