hpr-knowledge-base/hpr_transcripts/hpr0262.txt

Episode: 262
Title: HPR0262: Programming 101: The Basics
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr0262/hpr0262.mp3
Transcribed: 2025-10-07 15:00:14

---

music
music
music
music
music
music
Welcome to Hiccup Radio everyone, my name is Soak, today I'm going to be talking about
programming 101.
I'm going to do a series of programming to try to impart some of the things I've learned
in the past, all called a century, that I've been coding.
So first a brief history of my experience.
When I was around seven or eight, not exactly sure when it was, but I'm going to use seven
for reasons that will become clear soon.
So when I was seven, my brother being the lucky git that he is, he wanted that expression
48k.
We're here if you don't know what that is.
We had various games for it, but we also bought some of the Spectrum magazines that had
code, or Spectrum Basic code, in each one for a little game, and there were things like
to snake, nothing fancy at all, in fact you can get better stuff from cell phones nowadays.
But I got used to typing up the code, and then checking for my typos, and then checking
for the typos that I type in when I tried to correct the typos that, where you get the
idea.
Trying to write someone else's code in when you don't know a huge amount of coding is rather
a pain, especially when it's printed in a magazine and sometimes they don't print it
too clearly, but it introduced me to programming.
Being Spectrum, as with most games back then, you could actually break into the code and
look at it and change it, and I used to hack the code around to give me infinite lives
or whatever.
Of course I sucked back then, I would actually delete any lines that gave me an error, but
it got me into looking at the code.
I kept at it for a few years, upgrading to a Spectrum Plus 3, with those weird 3-inch
double-sided floppy disk.
Yes, 3 inches, and yes, you can actually take the disk out, physically flip it over and
use the other side, and it was like 170k on each side, 180 or something.
At school we had BBC's, again just we hear it if you don't know.
Some per classroom, so I didn't get to do a whole amount there, although BBC Basic
was similar to Spectrum Basic, because it's the whole basic thing.
From there I moved on to an Amiga, running Wordbench, I think 1.3 at the time, then 1.4,
forget exactly, but Wordbench, and this is where I really started to get around to messing
around with computers.
I had the command line set up with a ton of shortcuts, now could fly around and do loads
of stuff.
I played around so much and had a few friends that doubled, but no one quite as much
as I did.
I was now at secondary school, which is roughly high school for any American's listening,
where they had RM Nimbus's mainly, and a lab with some BBC's there.
I started spending time in the computer labs and coding stupid little things, a paint
programme here, and so on, so forth.
We had a student teacher for a time for maths, and she taught us programming.
The first lesson we were taught to write a programme to find the square root, or the
square root to three significant figures if it was one of these weird ones that carries
on forever.
The SQL function would have been the one line up, but we would say we could not do this,
but we had to take half the number, and then square that and see if it was higher
or lower than the result we wanted, and then move one way to half between that number
and that zero, and anyway.
I read the code in a few lines, I think it was six or so with a few comments.
Whilst we were waiting for everyone to take their seats in class, we were discussing how
many lines people had used, another friend had used less, but I felt his was a little
more confusing.
I'll come on to that in a moment, I'm more of a code that likes to have more lines
code that's much easier to read than a one line that does everything.
The teacher was at the front, we were actually at the desk, right to the front, and she said
she'd written the code in 20 lines.
I realised at that point I wasn't going to learn anything from her.
You see, I used a loop and she hadn't, but I'll explain loops in another episode.
Fast forward to university, I was doing a degree in computing, not anything else, no major
mind, things like the US, just computing, pure, plain and simple.
I learned a bunch of things, assembly, prologue, pascal, visual basic C, and a few others
like a weird language written by the lecturer.
I bought my first computer for it's 6DX266, if I remember correctly, four mega memory.
Windows 3.1 and DOS, five or something on it.
I played some games, coded a few things.
One of my friends was actually running Linux, but I never actually picked it up from there.
Maybe a missed opportunity.
So I spent some time coding and messing around, played with the Unix machines and the
lab and geeking out way too much.
This is where I got into muds, if you remember, the deviates interview.
Then I got a job as a coder and I wrote C on my first day.
The company was more of the B shop actually, so I spent most of my time working in Visual
Basic, and there's some Clipper and a few Quick Basics, and I spent about nine years at
the company first developing and then I got shifted to supporters there outsourcing the
development.
But I got a little proud of my work.
I wanted to make generic code that would work in different places.
For example, someone had written a printing module for Clipper, and this is great.
I mean, really beautiful.
I mean, who would you call appreciate this?
You can say things like, dear name, i-something-slash-i, and it would populate name from the
database with the person's name and then the i-slash-i would be converted to italics.
By looking at driver files, we'd create ourselves with a third line or whatever it was, which
had italics on and fourth line, which was italics off for that specific printer.
This is great.
You call the program and passable printer type, and it works for any printer that we had
drivers for, and we could write more drivers just by looking at the printer manuals.
I actually help code similar one in Quick Basic.
It can't take all the credit.
When the company merged, we gained a ton more printers, of course none of which were the
same types we had.
Quick 10-15 minutes later and we could get people printing on any of the new printers.
Now, about 10-15 minutes of our work to make the driver file, then maybe 15-30 minutes
testing the few apps, and then wait three weeks to get the file copied over to the
production environment.
But that's another story, that's the way the business worked.
So I started getting a little proud of my work, and I loved it when I could fix and help
someone out, and I tried to make the programmers in up to pieces of possible.
So when the users get a form back from the client, they fill it into a program 20 to the
details, and you have the program screen matching the forms, so they can just read from the
form to form to form, and copy straight across.
You have it, so you can actually tap from one input to the next, automatically, or if
it's a date automatically go through when 6 digits or 8 after the year 2000, we're filled
in.
This made it so much easier for the user, because they didn't have to keep clicking
on the screen.
They could have the form up next to the screen, and if they could touch type, they could
touch type through it and do it up really quickly.
Some of the people I worked with got this and some didn't.
Anyway, so I left that job for various reasons, I can't really go into it, it's contractual
stuff.
If someone wants to pay me like 100 grand, I'll explain, but it's a long story.
But I left on my own, I wasn't fired or about to be fired or anything, and had I not left
I may still be there to this day.
They did redundancies, and they were rating people on scores from that redundancy, so I took
full redundancy, and my score was, I can't remember, I think I scored like 29 or something
on the cutoff was like 23, so there was no way I would have actually been fired.
So I don't know, now I'm 32, and if I say I started at 8.7 and not 8, see I told you,
I mentioned this again, and that is actually 25 years, or a quarter century I've coded
before.
Admittedly, really bad at the start, but I like to think I'm an above average coder.
Actually, having seen a lot of the example coder helps, and I'd say I'm a top coder,
but I don't have much faith in a lot of the code people put out there.
I don't actually think it's that difficult to become a top coder.
I'm not, by any means, the best.
I am not learners, tall vows, or any of that kind of thing, but I'm a pretty good programmer.
So I'm going to try and part some of the things I've learnt over the years.
If anyone disagrees from me on anything I say, please let me know, and we can discuss
why I think this is, and why you think that is.
And I would love to learn some more tips and tricks from people here.
That's one of the reasons I'm doing some of these, so if people can teach me stuff,
I don't know.
I think that's brilliant.
And by actually doing the episodes with myself, I can say, I'm going to do one of programming
and get a discussion started about it.
So anyway, programming basics.
I'm not going to go into any specific languages for now.
I will try and explain the mindset and similar, and a lot of the programming techniques are
the same no matter what the language, and if you only learn one language, your stuff
because the fastest being popular, you're then in trouble.
It's like driving.
You don't just drive any car, not how to drive a specific car.
ABS brakes, for example, analog brake system.
Pre ABS brakes.
You don't just dump on the brakes itself, you have to dump some, dump, dump, dump, dump.
If it's oily or snow or whatever.
If you dump on the brakes, you'd skid.
After ABS, dump on the brakes, ABS figures it for you.
You learn why, and it makes you better about it.
You don't just learn how for that particular one, because if you learn how to drive on an
ABS car, dump on the brakes, that's how to do it.
You then try to drive a pre ABS car, dump on the brakes, or you crash and die.
So learn why, learn about it.
So I've got a quick quiz for you.
This is quite simple, but it tries to explain the mindset why some things still have bugs
while most things.
Imagine you're trying to write a program to boil a kettle, to make yourself a hot drink.
The old style stick it on the stove and it will whistle when it's done.
I want you to write out a list of instructions that you all need to do this.
Simple English language will do.
Nothing fancy.
I'll wait here.
Okay, I actually just paused the podcast and do this.
I'll always get really boring.
Seriously, I would actually let you stop and I actually just think about it.
Okay?
All right.
Hopefully you've done that now.
So I'm imagining you're going to have something like fill kettle, turn, stay on, put the kettle
there, wait for whistle, take kettle of stove, make tea or whatever.
Yeah?
Well, congratulations.
You just burnt your house down.
You didn't turn the stove off, did you?
Or maybe you burnt it down because the whistle was broken and you never checked on it.
Or you ever filled the kettle because there was water in it from last time.
And you didn't check how much was there.
Or maybe the stove had no parents that would never make the water boil.
Or a million other things that could go wrong and mess it up.
This is what coatings like.
You have to think of all the possible ways that could go wrong and try to prevent it.
So the new improved way for boiling the water would be presumably something like pick
up the kettle, look at water level, if under a cup full or however much you need, fill
water to a cup full.
Turn, stay on, put kettle on stove, check light is on a gas or whatever, so the kettle
wouldn't boil.
Wait through the whistle or 10 minutes, whichever comes first.
Turn, stay off, confirm it's off, take the kettle off the stove, make tea or whatever.
Not likely more complicated, but it should work and it's looking good.
We've covered some of the obvious things that could go wrong.
I'm sure I will have missed bits.
I didn't check the kettle was leaking or similar so you don't need to tell me it wasn't
going to be right.
It's just an example to try and make you think in that kind of manner.
Now computer language is very in several ways.
The main one is how high or low level it is.
A very low level language would be the ones in zeros, whereas the high level language
would be more like English.
Assembly code for example is hard to read as the lowest you can get basically without
going to ones in zeros, because it gets converted straight into ones in zeros.
Assembly code would be something like more VH, BH, Bint 21H and so on and so forth.
Yeah, I can't remember what that does, actually it doesn't do anything depending on what's
in various registers, but it's been a long time since it is assembly, but it's really
confusing.
Don't even have real words.
See for example is still a low-ish level language, but it is more readable.
For example, printf, open brackets quotes, hello world quotes, close brackets, semicolon.
That would print hello world onto the screen.
Well, actually it wouldn't if you just did that because you need libraries stuff, but that's
just the one line you need.
Assuming you've got the libraries, that one line would print hello world onto the screen.
Visual basically there is a high level language and would be print quotes, hello world quotes,
and that would put it out.
Now the English language is a wonderful thing.
It allows me to do a podcast like this and talk on it, but it is incredibly fake for
some things.
For example, the sentence, I didn't put Indian ink in the washing machine.
I tried to read that with no information.
Now let's try stressing different words.
I didn't put Indian ink in the washing machine, but I know who did.
I didn't put Indian ink on the washing machine.
I threw it in there.
I didn't put Indian ink in the washing machine.
It was permanent ink.
I didn't put Indian ink in the washing machine.
It was an Indian curry.
I didn't put Indian ink in the washing machine.
I poured it on top.
I didn't put Indian ink in the washing machine.
I put it on the photocopier.
So depending on what would I stress, it changes the entire sentence.
Progaming languages are designed to be pure.
One thing means only one thing.
That simple.
There is no way a computer can get confused over what each word means.
Of course, if you write random words, the computer is still going to have no clue,
but it isn't for many vagueness of the language.
Now the plan on these podcasts is that I will cover some things in the language each
episode and build them up so you can write some simple programs.
Although I've yet to decide on the language, as I mentioned earlier, I have done a turn
of my time.
And as I've decided, I should probably pick one of the following for various reasons.
Because Linux is written in C, and therefore I could actually get some code in the kernel,
which would be really cool.
Although one strike against it, I did do C in the past, and I was thinking about learning
at a new language.
PHP, because it's on the web, and things like Drupal use PHP, should be quite a marketable
skill, and as everyone seems to be going web-based, it would be useful on Python.
Because again, you can do web with it and you can write Python scripts.
I decided against a few things like Mono because, well, there's a few big question marks
over it, and it's C sharp, like I said before, it's not a new or new to me language.
And I didn't want to do Pearl because, well, Wanderer does it, and well, just listen to
the Linux crank subset about that, if you want to know more about that.
So I'm leaning towards PHP at the moment.
I would like some feedback though, because language anyone really wants me to do.
Give me some reasons, I'll consider it.
Otherwise, I will be pressing on with PHP.
And next time, I'll go through Installing PHP, some of the basics, and writing a Hello World
program, because I'm sure there is actually a law somewhere that states the first period
of manual writes for a new language, must say Hello World.
So if you want to let me know, either comment on the HPR page, or go vote at zog.org-po-ll.
That is, of course, not P-O-L-E.
I have had this up for a while.
And so far, as of the 29th December at 121 in the morning, Western Time Pacific Standards
time, we have one vote for C, two votes for PHP, six for Python, and two for other.
Now, based on that, it may end up doing Python.
I think I prefer PHP, but no big deal either way.
So anyway, that's kind of the basic code for you.
I'm not going to do any more just yet, trying to get this one out fairly, quickly, fairly
easily for the beginning of the new year.
And because I was late for the last one, so I want to get this sorted out.
And so we'll be going through some of these things, how to install the programming language,
various tools, like I'm like in G-NEE, for example, for writing the code, because it highlights
syntax highlighting for things like that.
Then we'll go through some basic things, and we'll probably get not much further than
doing Hello World.
But I'm planning on doing a bunch of these, and if there's a specific thing someone wants
me to write, hey, wouldn't it be cool if we had a little program that did this?
Something really simple that I could actually explain in an HGRI episode, and move for it.
Maybe something really simple, like just sorting out anagrams of something.
You put in some text, it gives you the anagrams from them.
Something really simple like that, that isn't going to require a huge amount of code, and
not expecting anyone to turn around and say, hey, wrote a new link in this kernel, and
I definitely want to be doing that.
Thank you for listening.
If you've got any questions, you can email me at zooksorryatgmail.com, that's xray osca
kilo echo Sierra osca Romeo uniform at gmail.com, or you can visit me at zook.org xray osca
kilo echo dot osca Romeo golf.
Thank you for your time, and you've been listening to Hack of Public Radio.
Thank you for listening to Hack of Public Radio.
HPR is mounted by caro.net, so head on over to caro.nc for all of us with you.