18 Aug
2001
18 Aug
'01
5:29 p.m.
On Sat, Aug 18, 2001 at 01:45:07PM -0700, Fred Cisin (XenoSoft) wrote:
Acorn designed a 6502-based computer for the BBC, called (natch) the BBC
Microcomputer. Sophie Wilson wrote a fine BASIC for the machine. When
Acorn designed the ARM chip and a line of computers based on that, the BASIC
got ported, but I don't know who did that work. I mentioned BBC BASIC in
another message, but only in passing.
It does all the usual "instant gratification" BASIC things but can
accommodate structured coding (REPEAT/UNTIL, multi-line functions/procedures
that take values and return results, probably other features). The
assembler is tied into the BASIC very nicely. You can access BASIC
variables from assembler and you can use BASIC programming to determine what
to assemble (I guess that would be a kind of macro processing).
It's not a perfect solution. It still allows spaghetti code. If you're
writing pure assembly (as opposed to mixed BASIC/assembly) a full assembler
might be less clumsy. But it's certainly very flexible in that you can
start with simple programs and work up to quite complicated ones.
Disclaimer: I haven't written any programs in the language myself.
On Sat, 18 Aug 2001, Derek Peschel wrote:
We were, but then I changed the subject. :)
I never said that fancy macros were for
beginners! I was just pointing out
the extreme case of what you can do with a good macro processor. The
beginners WILL probably want to use the PRINT macro, however.
I apologize. I was under the [apparently mistaken] impression that we
were talking about beginners. Also, I
mentioned languages with embedded assemblers, and that might be a
useful way to teach assembler -- by ignoring it at first and then using it
in small pieces.
That might be very interesting. I knew one teacher whose first assignment involved a
FOR loop. Her
students were unable to coherently describe whether difficulties that they
had were with the compiler or with their programming logic. Virtually
none of her students made it to a second course.
Sad but occasionally true. I met a student in an intro CS course who
obviously didn't understand the idea of imperative programming (what happens
to variables as the program progresses, the fact _that_ the program
progresses, what WHILE loops do, etc.).
I once hired one of their graduates. I fired him a
few weeks later. He
was unable to write a trivial program to print 3-up mailing labels from a
name/address data file, because he couldn't figure out any way to do 3-up
labels without knowing how to make the printer return to the top of the
page!
I'm sure I could solve the problem pretty quickly. On the other hand, I
would put that task (or ones like it, but more elaborate) into the class
of "algorithms that look easy, but require more analysis and more weird
special cases than you would think at first". More elaborate tasks might
include:
- Make the names run alphabetically down the first column
of a page, then down the second, then down the third,
then continue with the next page.
- Make the names run alphabetically down the first columns
of all pages, then the second, then the third.
- (I did this recently in AWK) Change a file of the form
jmp a1
call a2
jmp a2
call a3
into one of the form
a1 jmp
a2 call, jmp
a3 call
- If you really generalize things you get report generators
or page-layout programs. I suspect those require a lot of
care to get right.
Maybe I'm the only one with this view. Maybe I've gotten lazy after
graduating. Maybe the current programming languages make this sort of thing
harder than it ought to be. But maybe not. :)
-- Derek