Interesting bug

[Allin Cottrell]

Well, now we don't have that problem. Kids these days won't know a
programming language from a hole in the ground. What they want their
computer to do is access the latest "hip" chat sites and play the
latest action-packed shoot-'em-ups. Nothing that would actually require
creative thinking - heck, thinking at all.

As a teacher of undergraduates, I'm sorry to say that I can confirm
that. In the DOS days, I had a scattering of students who really
knew about computers. In the XP days, I have none.

Allin Cottrell

 

[Richard Delorme]

Dan Pop a écrit :

Maybe, maybe not. The 20K of ROM were probably holding plenty of code
that had nothing to do with the BASIC interpreter itself. There is also
the execution speed issue: GOTO lineno is much faster to implement in an
*interpreter* than scanning for the matching ELSE or reverse scanning to
find the beginning of the loop. Sure, such things can be accelerated,
by giving up the pure interpreter model, but this requires even more
resources.

I don't think that technical considerations were really important.

The PC implementations supporting structured programming features
were typically incremental compilers...

Then, there is the marketing issue. The vast majority of C64's were not
supposed to be programmed in BASIC (or any other language), they were
supposed to be used as game machines. Games implemented in assembly.
Due to that, certain, game-oriented hadware features of the machine were
not even properly supported by the BASIC interpreter. So, the vendor
correctly (from HIS point of view) decided not to invest too much
resources into a sophisticated BASIC implementation where a simple minded
one could serve equally well.

That's the main point. The lake of competition, the availability of a
simple and inexpensive BASIC made by Microsoft for their platforms, and
other marketing issues can well explain the choices made by Commodore.
So, whatever if standardized specifications for a better BASIC existed
and the machine was powerful enough to handle them, they did not bother
implementing it.

I'm sure the really talented kids, who found
the limitations of the builtin BASIC annoying, could find better
alternatives.

Yes, here is an impressively long list of available languages for
commodore-64:
http://www.npsnet.com/danf/cbm/languages.html
The availability of structured languages (BASIC included) also shows
that the commodore resources were relatively sufficient to handle them.

So, they probably used resource-rich mainframes, so I fail to see your
point.

A GE-635 (1966-1975) followed by an Honeywell 66/40 (in 1976). Their
resources were quite comparable to a commodore-64, and were shared among
many users (up to 200).

So what? Are you suggesting that the resources of the C64 were comparable
to those of a mainframe from the mid-seventies?

Probably, but that's not the problem. I just want to show that BASIC
could have been a well-structured language on the family and personal
computer of the early 1980s.
I think Kurtz and Kemeny shared a similar opinion when they decided in
1983 to create a company to make "available to everyone a high-quality
BASIC", as demonstrated in this Kurtz' interview:

(from http://www.truebasic.com/downloads/D2006.pdf)
Q: How did Dartmouth BASIC become True BASIC?
A: Teaching at Dartmouth, John Kemeny and I were shielded from some of
the worst implementations of BASIC. For example, we stopped using line
numbers in 1975, just as personal computers were being invented.
Dartmouth BASIC had continued to evolve into a more and more
sophisticated language that was a joy to use. However, in 1983, three
Dartmouth alums challenged us to look at the versions of BASIC that were
out there, all different on the different computers. We were appalled at
how terrible these crude `street' versions were, and what high school
and college students and teachers had to contend with. We knew that
writing papers or delivering talks would have little effect so we
accepted the challenge of forming an independent commercial software
publishing company and making available to everyone a high-quality
BASIC, one that reflected our years of teaching experience.

 

[Rob Thorpe]

Most likely, Commodore didn't see BASIC programming as relevant to the
marketing of a machine, which was, obviously, hardware optimised to
be used as a game console. However, since it was sold as a home computer
(another marketing trick: parents objecting to buying a game console
could be convinced to buy a home computer ;-) it had to have a BASIC
interpreter.

Compare to the ZX-Spectrum, that was poorly equipped as a game console,
but whose BASIC supported all the hardware features of the machine,
including the high resolution graphics and the sound generator (an I/O
port bit directly turning on and off the membrane of a loudspeaker).
It came with a very nice BASIC manual documenting everything (including
low level hardware and software implementation details) and a cassette
with demo BASIC programs (making minimal use of machine code to improve
the program's user interface). It's obvious that Clive Sinclair seriously
considered the educational usage of the machine, apart from its
recreational one (the machine also came with a very short user guide,
explaining how to connect it to the TV and tape cassette recorder and how
to load "programs" from tape).

Dan

I grew up with an Amstrad 464, a 64K Z80 based thing no-one really
remembers.

Like the Commodore 64 it was more for games, but the BASIC interpreter
was still good, although slow. It also supported some things that
were rather like threads, strangely enough. The BASIC manual was a
work of genius, especially the graphical programs.

 

[Randy Howard]

Then again, no matter how many minds Dijkstra's paper might have changed,
there is plenty of proof that well structured code can be written with
gotos and badly structured code without. The tool might help, but it
cannot replace the skill of the craftsman.

I think that if his paper had said something like "harmful for newbies" in
the title, it might have been far more appropriate overall.

 

[Randy Howard]

As a teacher of undergraduates, I'm sorry to say that I can confirm
that. In the DOS days, I had a scattering of students who really
knew about computers. In the XP days, I have none.

Hmm, I have a 10-year old child currently learning to program in C
on an XP system. We'll be working on cross-platform portability to
Linux and Mac systems (the latter primarily for byte-order discussions)
shortly.

 

[Christian Bau]

I think that if his paper had said something like "harmful for newbies" in
the title, it might have been far more appropriate overall.

Also remember that this paper was written at a time when many
programmers _had to use_ goto because they used a language that had
nothing better. Just rewrite a switch statement with five cases using
goto only, and you see that the code becomes a mess. So "goto is
harmful" didn't mean primarily that goto should be removed, first of all
it meant that programming languages should have better constructs than a
plain goto.

 

[Joona I Palaste]

Hmm, I have a 10-year old child currently learning to program in C
on an XP system. We'll be working on cross-platform portability to
Linux and Mac systems (the latter primarily for byte-order discussions)
shortly.

But *you're* a computer programmer too. Neither of my parents, nor any
of my elementary school teachers, knew anything about computers when I
started programming. I started programming from natural interest, not
because someone taught me.

--
/-- Joona Palaste ([email protected]) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Outside of a dog, a book is a man's best friend. Inside a dog, it's too dark
to read anyway."
- Groucho Marx

 

[Old Wolf]

I grew up with an Amstrad 464, a 64K Z80 based thing no-one really
remembers.

I remember it for the wrong reasons: when Amstrad bought out Sinclair,
they immediately ceased production of Sinclair machines and concentrated
on the 464.

Like the Commodore 64 it was more for games, but the BASIC interpreter
was still good, although slow. It also supported some things that
were rather like threads, strangely enough. The BASIC manual was a
work of genius, especially the graphical programs.

There was a demo of these things at a mall; each PC had a book of
programs with it, and you could go in, type out a program for 2 minutes,
and see all these amazing graphical effects. Good marketing

 

[Dan Pop]

Dan Pop a écrit :

I don't think that technical considerations were really important.

Hard to say...

That's the main point. The lake of competition, the availability of a
simple and inexpensive BASIC made by Microsoft for their platforms, and
other marketing issues can well explain the choices made by Commodore.
So, whatever if standardized specifications for a better BASIC existed
and the machine was powerful enough to handle them, they did not bother
implementing it.

Name one 8-bit home computer implementing the "better" BASIC
specification in its ROM. Even those which didn't go the Microsoft
BASIC way, still took the KnK specification from 1964 as their
starting point.

A GE-635 (1966-1975) followed by an Honeywell 66/40 (in 1976). Their
resources were quite comparable to a commodore-64, and were shared among
many users (up to 200).

Equating a mainframe and a home computer is ridiculous. Even if they
had comparable amounts of central memory (which I strongly doubt), the
mainframe had a very powerful I/O system that could compensate the lack of
memory. Now, tell us about the C64 I/O system...

Probably, but that's not the problem.

It's pretty much part of the problem.

I just want to show that BASIC
could have been a well-structured language on the family and personal
computer of the early 1980s.

But you have provided exactly zilch arguments supporting this opinion.
The existence of a language specification is far from being enough for
that purpose. Write an implementation that could fit in 16 K, along with
all the device drivers and the rest of the system management software
usually required by an 8-bit home computer and that would deliver decent
performance on a 4 MHz Z80A (or equivalent micro of the time) and THEN
you'd have a *valid* point.

The fact that it took a mainframe or a PC to produce such implementations
might provide a clue....

Dan

 

[Joona I Palaste]

Equating a mainframe and a home computer is ridiculous. Even if they
had comparable amounts of central memory (which I strongly doubt), the
mainframe had a very powerful I/O system that could compensate the lack of
memory. Now, tell us about the C64 I/O system...

Hmm, the old 1541 disk drive used to take 10-15 minutes to load about
20-40 kilobytes of data from disk. And the cassette drives, they were
even slower...
When I switched to an Amiga 500, the disk drive speeds of several tens
of kilobytes per second were like a wonder.

--
/-- Joona Palaste ([email protected]) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"The day Microsoft makes something that doesn't suck is probably the day they
start making vacuum cleaners."
- Ernst Jan Plugge

 

[Dan Pop]

A fully interpreted BASIC that scanned the actual source code as the
program progressed caused lots of interesting things. For example,
short line numbers actually performed better than long ones. Also
variables were faster than literal numbers. This was obvious, really,
as scanning a literal number required a decimal-to-binary conversion
but scanning a variable only required a table lookup. Thus several
magazines actually recommended replacing uses of 0 and 1 (which were
the most common numbers) with uses of variables that were assigned
these values and never reassigned.

Sinclair BASIC took some shortcuts, to accelerate the execution:

1. All keywords were single bytes and were input as single character
strokes, using a modal model of the keyboard (3 cursor types: K/L/E
and 2 shift key types).

2. All constants in the code were followed by their binary representation.
Those hidden bytes were stripped when the line was edited and inserted
back when the line was scanned, before being inserted back into the
program.

#2 "wasted" more bytes than #1 saved. When optimising for program *size*,
one would use variables instead of constants.

The Commodore 64 actually used line numbers in a weird fashion. If we
ignore GOTO and GOSUB, line numbers were pretty much irrelevant.

And FOR loops. The loop control variable usually contained the line
number of the corresponding FOR statement, too.

Execution normally proceeded in the order the lines were in memory. If
you edited the memory directly, you could for example put the lines in
reverse order, or even give every line the same number, and the program
still ran like it originally did. (If it didn't use GOTO and GOSUB, of
course.)

This is normal for a minimal BASIC implementation: ordinary line numbers
are only to avoid the need for a more sophisticated editor. The HiSoft
Pascal and C *compilers* for ZX-Spectrum also used line numbers in the
source code, to simplify the built-in text editor: the compilers used
them only in diagnostics: "Error 15 at line 180" where 180 was the
logical line number (assigned by the programmer or automatically by the
editor) not the physical line number.

Dan

 

[Richard Delorme]

Dan Pop a écrit :

Name one 8-bit home computer implementing the "better" BASIC
specification in its ROM. Even those which didn't go the Microsoft
BASIC way, still took the KnK specification from 1964 as their
starting point.

I called that "the lake of competition".

But you have provided exactly zilch arguments supporting this opinion.
The existence of a language specification is far from being enough for
that purpose.

I also gave the following link:
http://www.npsnet.com/danf/cbm/languages.html
from which you can read:

- Structured BASIC V6.5 [C64]
"Flexible new language".
- Symbolic/Structured BASIC [PET] (1979, Softside Software)
S-BASIC includes editor, "pre-compiler" and loader package. Allows
structured BASIC constructs like no line numbers, WHILE and UNTIL loops,
labeled GOTOs and long lines. Upwardly compatible with PET BASIC.

(the PET was actually not a C64 but an older professional computer from
which the C64 derived).

So structured BASIC existed on the C64 or similar machines.

Write an implementation that could fit in 16 K, along with
all the device drivers and the rest of the system management software
usually required by an 8-bit home computer and that would deliver decent
performance on a 4 MHz Z80A (or equivalent micro of the time) and THEN
you'd have a *valid* point.

Of course, I will write for tomorrow what needed several man-years of
development.

The fact that it took a mainframe or a PC to produce such implementations
might provide a clue....

Then, the fact that such languages existed on 8-bit machines proves my
point of view.

 

[Dan Pop]

Dan Pop a écrit :

I called that "the lake of competition".

You haven't explained the reasons of this lack of competition, considering
that there was plenty of competition on the home computer market.
An evil conspiracy of the home computer makers?

But you have provided exactly zilch arguments supporting this opinion.
The existence of a language specification is far from being enough for
that purpose.

I also gave the following link:
http://www.npsnet.com/danf/cbm/languages.html
from which you can read:

- Structured BASIC V6.5 [C64]
"Flexible new language".
- Symbolic/Structured BASIC [PET] (1979, Softside Software)
S-BASIC includes editor, "pre-compiler" and loader package. Allows
structured BASIC constructs like no line numbers, WHILE and UNTIL loops,
labeled GOTOs and long lines. Upwardly compatible with PET BASIC.

(the PET was actually not a C64 but an older professional computer from
which the C64 derived).

So structured BASIC existed on the C64 or similar machines.

Not as part of their firmware, which was the point of this discussion.
I guess even Pascal compilers were available for C64, so no one contested
the possibility of implementing structured programming languages on such
machines. Merely the practicality of having such implementations in the
machines firmware.

Of course, I will write for tomorrow what needed several man-years of
development.

Then, you still have no valid point for your claim.

Then, the fact that such languages existed on 8-bit machines proves my
point of view.

It proves zilch. How much of the machine's resources was taken by the
implementation of those languages? The answer to this question will
show you whether putting such implementations into the machine's firmware
was an economical option.

Dan

 

[Randy Howard]

But *you're* a computer programmer too. Neither of my parents, nor any
of my elementary school teachers, knew anything about computers when I
started programming.

Same here. In fact, a couple other students and I, in the first "Computer
Math" class ever taught in my High School, taught the teacher how to use
her computer. The 6 week "Summer Course" she had before the class started
was fairly weak. In effect, several of us that had built our own computers
(Heathkits) taught most of that class, while letting her pretend to so she
could get paid. She taught algebra for 15 or 20 years before that, and
AFAICT, had never seen a computer before that summer. Of course, few people
had in that time period.

I started programming from natural interest, not because someone taught me.

Again, I had the same experience. FYI, I didn't try to get her into computer
programming, (especially considering the future of the industry), but after
being asked to show how to do it, I don't see any harm in it.

 

[glen herrmannsfeldt]

Old Wolf wrote:

(snip)

Don't forget the BASIC equivalent of "switch":

240 GOTO 250*(i=0) + 350*(i=1) + 380*(i=2) + .... + 3530*(i=51)

(this came from an adventure game where there were 50 or so possible
user actions, each having its own handling "function").

Luckily my micro's version of BASIC included the feature of expressions
evaluating to either 1 or 0 (pretty advanced for those days); the other
micros had to do something more complicated.

Most BASICs that I knew of had real computed GOTO and GOSUB,
something like:

ON I GOTO 10,20,30,40

They were not completely interpreted, such that GOTOs
to non existing lines would be discovered before the program
started running.

In the early years of microcomputers, there were "Tiny BASIC"
systems that simplified many things, including the GOTO
method described above. Also, the same expression evaluator
was used for INPUT statements as for other expressions, so
variables could be use to reply to an INPUT prompt.

Around that time I had a TRS80 Color computer running
OS/9 with BASIC/09 and also a C compiler.
BASIC/09 was pretty different from other BASICs, among others
it didn't require line numbers for each line, and might
even have used alphanumeric statement labels. There was
something similar to break to get out of loops, which allowed
execution of one or more statements on the way out.

The C compiler was fine, but it didn't include the full
math library like one would expect.

-- glen

 

[Dan Pop]

Most BASICs that I knew of had real computed GOTO and GOSUB,
something like:

ON I GOTO 10,20,30,40

Sinclair BASIC had GOTO var.

They were not completely interpreted, such that GOTOs
to non existing lines would be discovered before the program
started running.

Being almost completely interpreted, Sinclair BASIC would simply jump to
first existing line with a number higher than that specified (IIRC).

In the early years of microcomputers, there were "Tiny BASIC"
systems that simplified many things, including the GOTO
method described above. Also, the same expression evaluator
was used for INPUT statements as for other expressions, so
variables could be use to reply to an INPUT prompt.

I believe this is a language feature.

Around that time I had a TRS80 Color computer running
OS/9 with BASIC/09 and also a C compiler.
BASIC/09 was pretty different from other BASICs, among others
it didn't require line numbers for each line, and might
even have used alphanumeric statement labels. There was
something similar to break to get out of loops, which allowed
execution of one or more statements on the way out.

The C compiler was fine, but it didn't include the full
math library like one would expect.

Back then, you were happy when an 8-bit micro implementation supported
all the features documented in K&R1 (which didn't include any math
library support at all, although it was mentioned en passant).

Dan