Debunking Human language not machine language!
There’s a lot of waffle coming from the author about science fiction in his most recent missive; we shall skip over most of this, dear reader, partly because it’s not relevant for a discussion on computer literacy (either the real definition or the author’s) but mostly because your correspondent spotted several things the author didn’t get entirely right in there and we’d be here all day if those were covered as well!
Of course, it’s possible for most people in all countries to learn other human or spoken languages. In lots of countries most of the population has learnt to speak one or more other languages. In spite of this, there are no countries that I know of where most of the population can program in any kind of Assembly Language, whether it’s for the 6502, 6510, 8510, Z80, 68000, Power PC, ARM, or even the possibly still most widespread Intel X86 family of processors. I think this proves my point that human language, not machine language is the answer!
This is, of course, complete and utter rot as an argument. People learn languages to communicate, so they pick up the local language first in order to talk with family members and friends then, perhaps, learn a second language to deal with the larger world if there is a need for them to do so. Computer languages are normally learnt by people who need to communicate with computers and, if that need isn’t there, they won’t in the same way there are very few people in the UK who are fluent in Korean or Portugese as a second language.
Even when two people share a language there are regional or cultural differences as well, the title of this post only makes sense to somebody who is aware of a certain 1980s Ronnie Corbett sitcom for example.
Even one of his then three companions, Adric, who was wearing a star for mathematical excellence and could calculate approximate square routes for large numbers in a few seconds, said that this was so tedious!
Despite the recounted events taking place in a fictional environment where 1980s computer experts on Earth could identify “megabyte modems” on alien worlds and the Doctor favoured Prime computers, machine code is probably still going to be as slow and laborious to work in as it is in the real world. Machine code is, generally speaking, just a string of numbers such as $a9, $00, $8d, $c8, $02 which mean nothing without a good reference guide and some translating[1] and that’s why we have assembly language!
It seems that most of these begin with the digits 532. Of course, this makes it very difficult to remember the various numbers using a popular Greco/Roman memory system, because this would involve conjuring up mental images all involving lemons.
Or simply assigning the number 53248 to a variable and remembering two digit offsets from there, that would work too… in fact that’s what the C64 user manual recommends.
Years before this, Atari had written a series of official labels standing for the memory locations which were important on their Atari 8 bit computers, such as GRACTL (player missile graphics control, 53277) and PMBASE (player missile graphics data, 54279). Programmers were recommended to use these labels in Atari BASIC as well as in 6502 Assembly Language.
We’ll just pause here to take note of the blatant hypocracy on the author’s part, dear reader. The Atari 8-bit’s BASIC doesn’t have special commands for hardware sprites and instead has to POKE values to five digit register numbers just like the C64 (with some of them even residing in the same general area of memory) but, magically, this stops being a problem to the author’s mind because someone made up some names for them! Yes these names could be assigned as variables in BASIC (if the programmer doesn’t mind chewing through precious memory) but that isn’t much different a solution to the one suggested above for the C64 and the names themselves are relatively cryptic anyway; nobody will know what PMBASE does or how it works without reading up and at least some of the manuals shipped with Atari home computers over the years didn’t cover hardware sprites.
From what I read, this language, which was either part of or another version to Commodore LOGO, enabled people to do impressive things using a language that was much closer to spoken English than BASIC was. I realised that if the Commodore 64 had been supplied with this language then it would’ve been a totally different kind of computer.
Some of the trade offs for any sort-of-human-readable language are that it limits what access the programmer has to the computer to some degree and needs to either be compiled or interpreted into something a computer can understand in order to actually execute. As an analogy, if assembly language is like learning French but having to work around colloquial variations with a friend in tow whilst visiting one of the more rural areas of the country, BASIC and LOGO are more like going to Spain and shouting “oy Pedro! Do you have chips” at the waiters because, although the message will probably be understood, it requires the person at the receiving end to do a lot more of the work.
Interestingly enough, on page 72 of the same magazine a software house owner called John Peel (NOT the deceased BBC DJ) says about converting his fantasy adventure game “Valhalla” from the Spectrum “Translating to the 64 was horrific. The memory map is a real mess, and we had to do all sorts of filthy things to get it to take a 35K program,” Peel said.
Since Valhalla was written in machine code, freeing up a contiguous 50K block of memory takes the following commands:
LDA #$36
STA $01
A team of programmers apparently working in machine code but not reading the reference guide for the computer they’re programming is the problem here, not the C64.
That said, there is of course a chance that Mr Peel wasn’t wording his description of the issue very well and that his team were struggling to cram the program, data, assembler and source code into RAM simultaneously but this is true of every 8-bit because assembly language source code always takes more space in memory than machine code; disk-based computers get around this by assembling to and from disk and many more commercially-oriented programmers were already cross assembling either from a second C64 or something else at that point.
Incidentally, your correspondent has just had a quick prod around inside Valhalla with a disassembler and Mr Peel was wrong, it’s much larger than 35K.
So, to sum up, Commodore with the C64 were looking backwards in time, while all other computer manufacturers were looking forwards!
BASIC with a few extra commands for graphics and sound is no more “looking forwards” for computer literacy than any other high level language; we’re still using some high level languages from back then and it certainly wasn’t a new, more human friendly high level language that opened computing up for more general use during the 1980s either because that accolade lies squarely at the feet of the Graphical User Interface and the C64 was one of very few computers from it’s era to get one of those in the form of GEOS.
But GUIs and voice-activated user interfaces hide the guts of a computer from the user so they actively discourage programming rather than promoting it; compare an “average” computer user now to one thirty years ago and the latter at least knew a couple of BASIC commands like LOAD and, if they cheated at games, probably POKE.
[1] The first two bytes are LDA #$00 and the rest translate to STA $02C8 – these set the shadow register for the Atari 8-bit’s background colour to black. Your correspondent can remember this fragment of code without thinking about it, but that’s a side effect of hand assembling 6502 machine code when first starting out in 1984.