Rob Cook


Home | Donate

Programming - the first 37 years


2022-12-22

Goto considered awesome!

In the beginning was the word, and that word was goto. It appeared on line 20, which was only the second line of code due to the convention of using multiples of ten for line numbers. (Yes, back in the mists of time each line of code needed a unique number. You used multiples of ten in case you wanted to go back and add more lines in-between the ones you had already written.) Next to the word goto was the number 10. On line 10 was the single statement print "Hi, there!". The whole program looked like this:


    10 print "Hi, there!"
    20 goto 10
    

My first BASIC program. An infinite loop of textual greeting. I was hooked.

Alongside goto I learned about variables, conditional statements, and reading user input from the keyboard. With a firm grasp on my primitive BASIC knowledge, I decided what I really wanted to do was write games. Text adventure games specifically. Lack of control flow structures aside, I had all the knowledge I needed to make this a reality... sort of.

The problem with a kid's imagination is its vast. Knowing few if any boundaries, I remember wanting to tell complex time travel stories or vivid fantasy adventures. The problem with goto is, as an unconditional jump statement, it leads very rapidly to a mess of spaghetti code. This however didn't deter me.

I wrote several games, or I should say I started several games. They all quickly collapsed a dozen or so choices in. It turns out jumping unconditionally to line labels is not a good way to write working code. Still I persevered, not knowing my limitations of knowledge. Unaware that there were better ways to do things.

Despite repeated failure, the defining mood of that period was fun. Coding was fun. Finding bugs was fun. Playing the broken games was fun. This pattern persisted pretty much unbroken, until I discovered something new.

Pretty pictures

Logo had something all young coders craved - graphics. Its turtle system allowed interactive sessions where you could input some simple logical command (forward 10 for example), and see a cursor on screen draw a line in response. It was magic.

Drawing pictures was the name of game now. Loops and conditionals allowed the drawing of repeating patterns. Fill and colour commands some simple shading. Each school break time a group of us would blag time on the RM Nimbus computer and experiment with Logo.

By chance I found a reference pamphlet of logo commands. Armed with this new knowledge we experimented further, even trying to get a network talk command working (despite the machines at school not being networked together in any way).

This sense of exploration was wonderful, as was the camaraderie.

Pascal and COBOL

It would take until college before I received any formal education in computer programming. After a brief dalliance with art, I impressed the head of the programming course by completing the first assignment overnight (albeit in a crude fashion). I was allowed to switch courses, and was introduced to the yellow and blue of the Turbo Pascal IDE.

I spent long days in the labs, working on assignments and getting my head around the latest bit of coding knowledge dispensed to the class. Pascal was awesome, and being taught things like proper control flow, arrays, and file access was mind expanding.

COBOL followed. It was dull in comparison. A language defined by committee for business tasks. I would design data entry forms, write my procedures, and wish to be coding in something else. It did teach me proper structured programming though.

The UNIX way

My first real job was as a UNIX support technician. I loved it. I spent days learning, pouring over reference books, then writing scripts to automate anything and everything about my job.

The excitement didn't last though. I found working life boring after a while, the same faces, the same work. Workplace politics was more important than technical ability, and I was a naive and ignorant politician.

UNIX taught me the importance of writing programs that do one thing, and do it well. Write small programs that can interact with other programs instead of a monolith. Prefer to work on plain text data.

Java and AI oh my!

University was great. After a stint in the real world, having all that time to focus on learning about programming was a welcome relief. Sadly the usual student vices of drinking too much and sleeping in, meant I never really took full advantage of it.

I gained a respectable 2.1, and did learn an awful lot. On reflection I leant few of the skills I would need as a professional programmer. It was however a rigorous grounding in how to think and reason about things, how to communicate clearly in writing, and a good taster of what was possible in more specialised disciplines.

Java was a nice language to underpin it all. The object oriented programming paradigm was a natural fit for my brain. The importance of abstraction was brought to the fore, as was good code organisation. It was a versatile language and standard library. CLI, GUI, n-tier web - it could be used for it all.

My interest in AI was driven by games. Whilst I learnt nothing much of that particular application of AI, I did cover the basics of searching, classification, clustering, and learning algorithms. This was of course before the modern day explosion of interest in the topic. My cohort was only seven students including myself.

C# and .NET

Seventeen years is a long time on one tech stack, but C# and the .NET ecosystem continue to evolve and adapt. The latest release is a long way from where it started circa 2000. By borrowing ideas from functional programming, it simplifies a great deal of what would otherwise be grunt work. LINQ is a fantastic example of that.

I've reached a point in my career where I can rapidly code most things I need in the course of my job. By sticking to one language, I've been able to focus on the underlying concepts more. The stuff that doesn't change as rapidly as language fashions and Javascript frameworks.

Coding to interfaces, separation of concerns, single responsibility, unit testing, dependency injection, design patterns... I've learnt it all through the lens of Microsoft's language. It feels like an old friend at this point.

When you aren't jumping from language to language, learning framework after framework, you can really focus on things like design and architecture.

Working as a professional you rapidly learn a lot about the things that go around programming. Source control, sprint planning, code reviews, and a host of other things. They are just as important to grasp as the coding.

Playing with Python

Which brings me to Python. It feels like coming full circle. Coding in Python is fun. There's an immediacy and sense of exploration to it. Firing up the interactive console and wrangling some data into shape is so simple and rewarding to do.

I've briefly taught Python to ten year old kids, and its fun to see them experiment with it the way I did with BASIC all those years ago. I firmly believe anyone who wants to can learn to code with it.

Advice

  1. If I was starting out today I would learn Python. It is the de-facto beginners language, supported by a myriad of learning materials. Its fun, simple, and rewarding. It can take you a long way.
  2. Read. A lot. From high quality sources (not all blogs are created equal). Read books. Read code. Just read.
  3. Learn (or at least study) a different language now and again. New points of view are important. Bring fresh ideas back to the fold.
  4. Be the dumbest person in the room at least once in your career.
  5. Have fun. Life is play. The ride goes up and down, but its just a ride.
end