As is my way, here is my annual 'goes on a bit' contribution to EUG.

I gather from EUG #19 that you need more detailed information on the kit that members have. Mine is as follows: Elk with MRB, AP2, AP3 using 3.5" ADFS, T2p3 and ABR - usually carrying View and Viewsheet ROM images but occasionally holding PASCAL, LISP or STARSTORE 2. You may think I'm principally an applications USER rather than midnight oil burning DEVELOPER. You'd be more or less right.

One reason I've never regarded the Elk as a serious development platform is the limited nature of the BASIC line editor. Another is I've never had an adequate pile of lovely unformatted ripe smelling data to process - and I wasn't about to type it in.

A friend recently dug out a B-I-G file (OK, then 22AC3) of telephone codes to towns that disposed of the raw data objection and left me gulping in disbelief at the editor as I wrote a program to format, edit and insert the necessary 1. Thus I began to use View as an efficient BASIC editor although my previous efforts had been fairly unrewarding.

What a twit I was! There's no need to type in line numbers and then change them and so on! To develop in View, just proceed as follows:

Enter View and write your program without using GOTOs or GOSUBs or line numbers. When you want to test your efforts, type AUTO at the top of the code and SAVE. Switch to BASIC, and *EXEC the code you SAVEd. Now your program will be in memory and can be test RUN or SAVEd as BASIC.

The advantages of using View are enormous. While developing you can use meaningful variable names that can be quickly and globally replaced to single memory-saving character names before production runtime. It also forces a structured approach to programming (No line numbers!). And best of all is the difference between a developing and finished program; you can build a library of frequently used PROCs and so on.

I discovered this procedure in the January 1988 Electron User edition and it was accompanied by a program to "strip" a BASIC program of its line numbers for subsequent editing in View (or another WP). The only use I could find this is to pull lumps out of an existing BASIC program. It's a waste of time while developing/testing. It's called STRIPER and I have submitted a copy of it as typed in.

By the way, this article ranks as the worst effort by St Roland Waddilove (Who seems to have spent months as the sole contributor to Electron User!) - there are factual errors liberally scattered throughout a rambling and fabulously unfocussed scrawl.

I now have a large file, in numerical order, of telephone codes to town and district exchanges within major cities. It goes into detail for some town exchanges, giving two figure codes for outlying districts. Regrettably, it is not as accurate or complete as I would like. For example, some district within town codes are missing (Mine for example!), strange descriptions (My old code in London doesn't agree with the A-Z) while the more nebulous codes, where there is no major town but a string of smaller ones, are marked by repeated codes against a list of town names. Two of these areas I know are not complete. Which is a pity if you live in Old Sodbury.

However, it's more right than wrong and it's available free if you send an ADFS formatted 3.5" disk and SSAE to the above address. If it's finished, I'll enclose my purpose-made database searcher too. You type in the code and it delivers up "The number you have dialled has not been recognised" appropriate town name to save you minutes of searching.

I use the 1471 Call Return service and have found it useful. The accompanying Direct Call Return (1471) has not been advertised but is very handy, especially for calling back to a phonebox. However, the direct service would appear to have been withdrawn, again without publicity.

Finally, you want to know why accurate spelling is important? Try using the 'you know what I mean' excuse in a computer program. If your code isn't exactly right and syntaxed correctly it crashes or chews up your data - or both - and goes on to attack the budgie. The same applies to the human language. Unless you know the person you are talking to knows your own speech or spelling deficiencies, it is important to remove avoidable errors and enable smooth communication.

At the moment I am collecting old 78rpm records and finding much to amaze me in the process. Do you think EUG members would be interested in the subject?

Chris Chadwick

I'd like to see this disk of yours. Why not simply submit it when it's finished? I also take your point about spelling and you're right, of course. Computers need precise information but in the case of human communication we have the advantage of intelligence so that we can evaluate information in a huge variety of different ways. My wife is bilingual in French/English but, as French as her first language, she sometimes drops the 's's when saying English plurals. It doesn't make her any more difficult to understand! Maybe this is why English is the most popular language in the world!

Editorial, for example, is my little gem. As you know, I spend quite a bit of time on EUG and Editorial helps me communicate.

Communication is everything. And as long as the world is talking, it ain't fighting. And goodness knows this world can do without fighting.

Also, never apologise for expressing your opinions, even if nobody seems to be listening. That's what EUG is for - among other things. So tell us about the records!

Gus Donnachaidh, EUG #22

Chris Chadwick