I think it was a sort of major achievement for UNIX, actually, that
y' know its big claim to fame is: ... yes we (Dennis and Ken) we wrote the UNIX
kernel in C. We had to have a few dozen lines of assembler and maybe, somewhere
in there, there's the odd sprinkling of gotos -- and there's good excuses for it,
sometimes, in the heart of an operating system but they're, even then,
massively reduced from what they would have been. So, that was the whole thing: we
must eliminate gotos. You can call them gotos, if you like, you can call them
jumps; you can call them branches. All essentially resolve into being the same
thing. They ... and I think most of you - from the education you're having already, or having
seen previous Computerphile videos, will know that gotos, branches, jumps etc are
unavoidable at the assembly language level. OK? That's the way that machines
actually work. You tell them to `goto' a different [next instruction] address. So what's wrong with
incorporating that idea into higher-level languages? Well, the argument
was - and it's quite right - the problem with the goto is that programmers never [seldom?!]
adequately document alongside *why* they are `going to' ... A common construct, of
course, is to have a go-to at the bottom of a loop to jump back to the top. You
check at the top whether you've finished the loop or not. But in the end,
when it's finished, you do another goto when you jump past it [i.e. the loop body] to the next
instruction. A good assembler program will put a little note in there saying
`loop finished', or something like that, so the argument is, well, that looping
construct, in a higher-level language, could be replaced by a `while'. And if that
`while' is then compiled down into assembler the gotos will be there, but
when you consult back with the high-level language you know that it [the goto] was
there because it's a `while' loop. And that is, basically, what it comes down to. By
using higher level constructs you make your intentions plain.
This enables me to kill two birds with one stone! Some of you are getting
very, very worried about unsolved Rubik cubes. Now I left one here there's some
unsolved in a particular way that I hope I can do, in real time now, without
embarrassing myself. This cube is solvable with two operations called
Goto monotwists. Goto is a very common Japanese surname and I'm guessing that
the Goto of Goto-monetwist fame must have been a Japanese mathematician going
way back to the early 1970s when I first got this from a set of notes [by David Singmaster] on how to
solve the cube. It always amused me, and I always delighted in doing it, because there
is another Goto who was a very famous Japanese computer
scientist. And to everybody's great amusement - in the 70s or 80s - he was at a
conference saying: "You have no idea how stressful it is to have the surname Goto
and to be involved in high-level programming language design and analysis"
And people said: "But, Professor, why ... ? ". He said: "People are always trying to eliminate me!
So, anyway, back to the gotos. [looks at cube] I see that that one, and that one, are needing a
twist - and you can get things that twist on their own axis - but while leaving the
rest of the cube unchanged - or `invariant' as mathematicians like to call it. You
can see that there's a sort of threefold symmetry on these corners. You can do one
twist, two twists and when you've done three twists you're bound to be back to
the same place. I can see from this one that it's actually going to need a
couple of these Goto monotwist operations [or one inverse monotwist], to get it to being perfectly
right. And I hope I can do them without goofing up. If you write ... if you post a
comment on this please *don't* point out that that this is heavily sub-optimal. Yes, I
know! There's brilliant [ but non-Goto] ways to do it much more quickly I'm sure. So, I remember,
in group theoretical notation, [using ' to denote "-1" i.e. an anti-clockwise move] it goes something like R' D R F D F' U
F D' F' R' D' R U'
That's progress! There's still two things that are wrong but they now have exactly the
same colour. And I know from my suboptimal - but at least I can remember it (!) -
algorithm, that another Goto monotwist, given
they're both the same colour and provided I don't goof up, one more will get it
right. So here we go: - R' D R F D F' U. F D' F' R' D' R U'. Yippeee! Computer Scientists can do limited Group Theory
if they try very hard! But it's not enough trespassing on
Numberphile territory. I cannot commit - and will not commit to memory - the
something like 90 algorithms, I think, that you've got to know, to be even moderately
good at doing a cube really, really quickly. I tend to try and remember about
10 or 12 [algorithms] and accept that they're sub- optimal - but I find them easier to remember!