Title: I Wish Programming Was Easy Again

It takes my PC just over 90 seconds from power up to desktop. It's nothing special, not really that high spec'd, okay, it has a lot of memory on it, but lots of memory is nothing that peculiar anymore.

Now, add onto that time loading kdevelop and we're up to the two minute stage. Type some code, compile and test, say 5 minutes. The code is linked to, say, OpenGL.

It's not an amazing amount of time, but say the code has a problem. Is the problem in the code or the libraries it is linked to? Check the code, hmm, nothing looks wrong there. Right, run the debugger on the binary... ah, looks like I'm passing something incorrectly to OpenGL. What is supposed to be passed in there? Where is my book with the API in? Drat, it's out of date, but looking at that I'm actually correct. Oh well, fire up the browser and search the OpenGL documentation, ah, found the problem.

My code is fine, it's passing the correct information to OpenGL, so what is the problem? I'd better check the physical information being passed and that it is exitting the OpenGL function correctly. It is. ARGH!!!!!!!

Does that sound familiar? It does from this end, and definitely will when you think back to when you started to learn C++ (or C) and tried to link it to an established library for the first couple of times (or more - I still manage to mess up when using Qt).

Is there a reason for this or is programming just becoming to darned complex these days for people to break into? And if it is too complex, shouldn't we all be doing something about it?

My original editorial in the last issue of C Vu sparked quite a lot of conversation on the accu-general mailing list where it gave those on there the chance to let off a bit of steam over the issue.

However, as with most computer related topics, it is not as simple as looking through rose-tinted glasses, a more pragmatic approach is required. While I stick to every word I said in the last editorial, you'll see that some things are made better by being slightly more complex.

One of the main issues raised was how complex something as simple as making the internal speaker play a scale had become. The example cited was for the Dragon32 which just needed PLAY "ABCDEFG" to be typed into the machine and a scale played. But was it really as simple as that for everything?

You'll need to think back now. If I take 4 machines (BBC B, Oric, Spectrum and Dragon) and compare how different something as simple as playing a scale was, we can soon see that even then something like sound wasn't that easy! I'll not consider the Commodore range as I have no real experience of them.

BBC B                          Oric 1
FOR a%=89 TO 113 STEP 4        FOR a=1 TO 8
SOUND 1,-10,a%,100             MUSIC 1,3,a,10
NEXT                           NEXT

Spectrum                       Dragon
FOR a=0 TO 11                  PLAY "ABCDEFG"
BEEP a, 5
NEXT a

These will all play a series of beeps which produce a scale (some include the sharps, some don't). What it demonstrates that from a programming perspective, if you learn from any of these audio systems, you're going to have a problem going to a different one.

Okay, sound is just one thing. A machine is nothing without input/output and graphic handling. This is where things became really different. While most had a PLOT and DRAW method of putting lines on the screen, the way they did it wasn't the same. The BBC B and Spectrum were effectively the opposite of each other with the Oric just being strange!

Line graphics are all well and good, but what about sprite handling? None of the 8 bit machines really had any sprite handling facilities, so unless you created a whole pile of user defined graphics, you would need to fudge the screen so that it appeared there was more graphics than there was or you had to generate the graphics on the fly or you plain had (say) 16 points of rotation and depended on a frame rate to fool the eye. (Later versions of BBC BASIC (mainly for the RISC OS machines) had sprite handling facilities, however, that would also mean I would need to consider the ST and Amiga machines).

Compare this to literally a few lines to call the Allegro or SDL libraries and you can see my point. Sure, there are problems learning how to compile, waiting for the build and the such, but it is (on the whole) much easier to learn.

Simple, yes it was easier but the drawback was that moving from one platform to another was a right royal pain in the backside! Interoperability was not on the cards.

While things are more complex now (such as having to use specialist bitmap software for sprites or sound software for audio), the actual API is much simpler; you learn it once and compile it quite a few times. Sprite, audio and (to some extent) error handling is provided by the library.

Okay, at this point, you're starting to question the reason behind the argument put forward in the last editorial as this really does make me sound as if I've contradicted myself.

While the movement has been from a version of BASIC on all machines, quite a number of machines do come with languages which don't require compilation. Tcl is one such language. No compilation is required and the results are instantaneous. It just isn't as easy to learn as BASIC was or (in my opinion) as friendly to the new user.

Copyright issues aside, there is no real reason why a version of BBC BASIC for each platform isn't bundled (I know there is BBC BASIC for Windows, a Linux BBC BASIC and a MacOSX version, all but the Windows version being free). This would give the user an easy to use language within (about) 2 minutes from firing up with the advantage of seeing instant results.

A point which was raised in discussion was the use of DHTML and Javascript with a web browser for learning. I have a problem with this, in fact, I have a few.

While everyone now using one of the main platforms^[1] has a browser, someone learning on (say) Firefox will need to learn how to get around DHTML problems for Opera and IE (with the same being applicable in reverse). This is pretty much the same problem as there was with the differing implementations of BASIC.

We are all (presumably) professionals. We know how to build our software, effectively debug, optimise the code we write and the myriad of other aspects there are to writing software, but we must remember that we all had to start somewhere.

While there is little doubt that the likes of Francis Glassborow's book is a step in the right direction, it is, unfortunately, not cross platform. I certainly would not buy a copy as I very rarely touch a Windows machine (other than tech support at work that is!); it would contain very little which would give an instant result for either myself or my son.

Have we moved so far away from having a built in interpreter with some form of common language behind it that to go back would be almost unthinkable? I have to conclude, on current evidence, that this is the case.

The learner no longer has the 3 seconds and into BASIC as we used to have. The code, build, run, debug system looks here to stay unless a common language is built in to each Linux distro, each version of Windows and OSX. I can't see that happening, more's the pity.

Sorry folks, looks like the fun days of the 8 bit machines have gone and we're left with makefiles and debuggers.