On being a programmer

I'm a self-taught programmer. Possibly the worst kind of all, I lack the rigid discipline. I do not think I'd program for a living - I do it more as a hobby. This is personal choice. You see, if it were up to me, I'd be a movie critic. Get to watch lots of movies (good and endearingly terrible) and write my comments. Probably because I'm lazy. But enough of the history.

People, when they see me going on about this utility or that (I try to always make 'useful' programs for my examples) usually either say they appreciate it, or they ask why I do it.

1. Programming is a useful tool
   I have often used an application and had a complaint with it. I do not expect perfection, but - to pick on Argo's Voyager - claiming nearly half a megabyte on a 4Mb machine just for the front-end/dialler is unacceptable.
   You may feel that coding your own is beyond you. I didn't, and hence the QuickVoy project was born.
   Not all examples have to be that glamorous. You might just want a utility to perform some function that you are unlikely to find a program for. Take, for example, the APCS example in my assembler programming area. I had a need for a utility to fudge all my MODE 21 screengrabs to be MODE 28. And there were around 300 images. Would I pay for a little program to do that? Would I even find such a thing?
    
   
2. Programming could make you money
   Yeah, I know I've been doing it for a decade and made a total of about fifteen quid. Don't do the maths. Don't even go there...
   Most of my software is released for free. I, myself, don't do it to get rich. If I wanted that, I'd sell out and code for the Windows platform.
   But, look at Bill Gates. Whatever your personal feelings for the man and the mess he has made of computer science, you gotta admit that to go from nothing to staggeringly wealthy isn't bad. I doubt you will achieve similar. I doubt I ever will. But you could go from nothing to riches. All you need is the right idea and the conviction to pull it off. The current 'bandwagon' is for Internet services. Maybe, if you can see beyond that and predict tomorrow's fad, you can be right up there.
   Pokémon started as a computer game. Just a bit of software. Now it has all sorts of spin-offs ranging from cartoons to toys to more software. And it is the 'in' fad at the moment. Somebody, somewhere, is getting rich.
    
   
3. Maybe you're a control freak?
   A computer is a mathematical device. You fancy taking this and that and multiplying it by something else? Knock up a little program and watch it work. Knock up a more complex program where the mathematical results are displayed on the screen and you're on your way to creating a mandelbrot.
   Tell your computer to write a random value in the Abort vector, then cause an abort exception and watch the machine lock solid. Or step through memory writing junk across it and see how many applications survive.
   The computer will do exactly what you tell it to do. Nothing more, nothing less. Though, admittedly, the operating system sometimes gets in the way with a "no, you didn't want to do that" sort of message - but that's why I like RISC OS, I don't want my OS telling me what it thinks I shouldn't be doing. Hell if I feel like poking the processor to NOT use the page tables, from a taskwindow, I'll bloody well do it! And I expect my OS to crash accordingly, not start an argument. I am the GOD of my machine, and I don't expect my foolish experiments to be responded to by Couples Therapy.
    
   
4. It's educational
   That excuse is usually seen on the Internet as a disclaimer for the irresponsible publication of bomb-making recipes.
   But sometimes the excuse is true.
   Programming IS educational. It makes you think.
   Try linking two machines via their serial ports, and knocking up a simple little filing system whereby they can access each other's harddiscs. What kind of protocols will you use? How do you differentiate between 'this is a control message, tell me what files are here' and 'this is just a block of data'. You could use the &01 byte for control messages, and the &02 byte for data. But you cannot scan through for either of those, as they might appear within the data being sent. How do you handle that? Can you block you data, or do you send it as a stream. If you block your data, is the system able to handle other requests between blocks? For example, while one file is being transferred, can you wander the filesystem to look for the next file? Or set up a 'chat' between the machines. What happens if you want to seperate the machines physically. You now need modems, and you now need error control. Will both ends be able to dial and receive, or will it work on a server/client model?
   All we wanted to do was link two machines for file sharing. A sort of a cross between a network and a bulletin board.
   Look at the questions raised in just a minute of thought.
   There are many more opportunities. A common one for students doing degrees in computing is to write an operating system. I would dearly love to understand the concept of OS design well enough to write my own. No matter how crap it is, there is something rather amazing in knowing that YOU did it. I plan to go a stage further and construct my own computer. Maybe an ARM250, with basic I/O. The computer that Rick built...?
   On a much smaller scale, you could always do a Mike Cook and hook up some esoteric piece of hardware to your computer, and see if you can make some use of it. Maybe a cheapo ISA ethernet card?
    
   
5. It is art
   To many experienced programmers, coding is an art form. Whether it be writing perfect code, or optimising a program to benefit from the lesser known eccentricities of a particular operating system. Even, God forbid, 'dark code' is an artform. This is not 'good' code as would be taught by a teacher, but rather it is perfectly functional code that requires a deeper knowledge of things. Take the following two examples:
     DEFPROCread_string(pointer%)
    LOCAL out$
    SYS "OS_IntOn" pointer% TO out$
  =out$
   and:
     BIC R0, R0, R0, ASR#31   ; IF R0 < 0 THEN R0 = 0
   The first example converts a pointer to a string to a string. The second example provides a zero cut-off, so anything less than zero is zero.
   I'll leave it to you to figure out how. It isn't difficult. How about something a little bit deeper, and more useful?
   

   .swihandler
     CMP   R11, #((endofjumptable - startofjumptable) / 4)
     ADDCC PC, PC, R11, LSL #2
     B     error
   .startofjumptable
    B      swi0
    B	swi1
    ; etc...
   .endofjumptable

   The CMP and the ADDCC are all that's necessary to implement a jump table of 'n' items. You might not call it 'art', exactly, but it is small and functional and does it's job well. On the whole, I feel 'larger' things have greater art value than smaller things. You can't really say 'this instruction is art', while the others aren't, can you? :-)
    
   I cannot really say any more on this subject. My personal concept of code 'art' is either beautifully laid out code (not something that is all compressed onto as few lines as possible); or dark code that twists the hardware/OS/compiler into spitting out functional reliable code, only you need to think and learn in order to figure out exactly what is happening. People maintaining such code will be only too happy to recode an entire project than deal with the sort of mind that makes heavy use of C's comma operator within loops; thus their idea of code artistry will be different.
   No problem. I, personally, loathe abstract geometric splats on a canvas that are said to represent deep perspectives on society and life in general. I like my paintings to be of real things. I like paintings that look real, such as the famous sheep on a winter morning (Farquaharson). Others will drool over sand castles and concrete insides of houses. It is a personal and highly subjective thing. But you can create beautiful code...
    
   
6. It is spiritual
   Coding in assembler, particularly when working on something low level such as a device driver, can be a deeply spiritual experience. (you may cue the men in white coats now).
   With that kind of code, you are no longer dealing with abstract illusions such as the Desktop, or sprites, or a letter to your girl (or boy, as is your sex/preference).
   Now, we are dealing with binary values. Sixteen registers, one serving a dedicated purpose, which can each hold a 32 bit value. Those values can be added, subtracted, multiplied, or logically munged by operations such as OR and AND. There is no concept of sticking one string on the end of another. The colour blue is just a fantasy given a binary pattern. There is nothing except data. Pure data. And you can do nothing except load the data, store it, mathematically alter it, and perform mathematical equivalence tests upon it. From those incredibly simple building blocks, we can create the illusion of a Desktop. On that desktop we can imagine a publishing thing. A piece of software that will let you write anything, in any style imaginable. And into your writing, you can insert pictures. And of that writing, you can copy it to a buffer where it will be directed to another processor running another program. And from that second processor, it will eventually attain physical form. As a little motorised lump whizzes from one side of a piece of paper to the other, little squirts of ink will be shot out under the control of this second processor. Totally independant to your processor. And totally unaware of what is happening - it is all a mathematical maze to the processor. There is no ink, no head, no paper, no feed rollers. Just a sequence of comparisons and data movements that eventually combine to turn your imagination into a physical document.
   Well I'll be damned.

Don't be put off when I make frequent references to mathematics. The ARM can add and subtract. It can even multiply, but it cannot divide. It is integer maths (3.5 x 3.5 = 6, as .5 cannot be expressed in integers) and boolean algebra. Everything else is either passed to a floating point mathematics co-processor, or faked with lots of complicated programming.

So, pick whichever reason(s) from the above that sounds the most plausible. Programming is challenging, fun, not too good for your social life. The same could be said of a few bottles of Vodka, however programming is certainly likely to make your electronic life easier afterwards. That cannot be said of Vodka.