Overall in the course,
the material would have quite a bit of emphasis on problem
solving and algorithms. Programming
is the core element of our programme in
UCD and we deal with a number of
different programming languages. Now,
the language that I'm going to refer to in
this introductory lecture is Python and
that's a language that we teach to some
of our students and we actually have
introduced a new module for first-year
students that introduces Python.
Really the emphasis of the
 introductory
programming courses in UCD
is that we try to teach you the basics,
we try to teach you the theory
and then you can apply those basics, you
can apply that theory to any programming
language that you want to learn. In
order to understand properly how
programming languages work and how
programming works we need to talk a
little bit about the structure of a
computer, which we do as well. When we're
talking about a particular language and
here I talk about, as I say, I mentioned
Python, but actually in first year
students cover the C programming
language. You talk about syntax, which is
what the the language looks like, how it
appears on paper or how appears on the
screen. Semantics, in other words what the
language actually means, what the
instructions actually do. Then we have
variables. Statements, statements are like
basic instructions in the language, the
flow of control, how we can actually tell
the computer to do this statement and
not do another statement or how to do
particular statements a number of times.
Input/output, how we actually communicate
with the the computer. Arrays, which are
part of how you can collect or combine
data into larger groups of data and then
subprograms, which are a technique for
breaking up larger programs into smaller
units. One of the important things
when you're writing programs is to make
sure that they're correct and in order
to make sure they're correct you have to
do extensive testing and what
we call debugging of your
programs, so we will talk a bit about that.
One of the most popular programming
paradigms on the planet at the moment is
object-oriented programming, now we don't
actually introduce object-oriented
programming in this module but towards the end of the module we will
give a lecture or two on object-oriented
concepts because you will be dealing
with those quite a bit in later modules
and in later years. One of the
features of any of our programming
courses and certainly any module that
I'm involved with is that there's lots
and lots of examples to illustrate the
various features that we talk about in
the lecture. So all of UCD's
modules have got a module descriptor and
as part of the module descriptor we list
out the learning outcomes, in other words
what we expect students to know at the
end of the module. So on successful
completion of this module students
should be familiar with the important
topics in computer programming, understand
the fundamental elements of a
programming language, be able to design
algorithms, be able to write computer
programs and in this particular module
it was Python that we're looking at,
be able to successfully run Python
programs, be able to evaluate programs to
find errors and be aware of the basics
of object-oriented programming. So 
those are the things that we would
expect students to know
by the time that the module is over.
What is programming? Programming
involves a number of different steps:
First of all we have to identify the
problem. So, there is some problem that
either we have or if we work on a
company, the company or our boss has and
either we help them
identify it or they identify the
problem for us. Then, we have to design a
solution. Now this design is unlikely to
be done individually, it's likely
nowadays to be done as part of a team or
a group. There will probably be some other
systems that our solution will have to
fit into so we'll have to be mindful of
that and there may be other constraints
in terms of costs and so on, that if
you're working for a commercial company
that you maybe have to be aware of as well. Then, we express the
solution as an algorithm, and we're going to be talking a bit more about algorithms in a
few minutes, but that's the fundamental map of the solution to the
problem that we devised, is the algorithm.
At this stage we haven't actually
touched programming as such at all,
we haven't certainly haven't touched a
programming language. The next step
then is to actually translate the
algorithm into a program in some
specific programming language, then
the computer translates the program into
machine code and depending on
the language that we use there's a
number of different techniques for that
translation: we can either compile or
interpret the language. So Python, for
example is an interpreted language, Java
is an interpreted language; C on the other
hand is a compiled language but one way
or another it gets translated into
machine code. Then we run the program
or in computer science parlance we say
we execute the program. Now if we're very
good at programming and very good at
writing algorithms then this program
will work perfectly first time. The
chances are that it won't. The chances
are when we test the program we'll find
some errors or some bugs in it and this idea of getting the bugs out
of our program is what we call debugging.
So we'll have to go back, we'll have to
maybe check some errors we might have in
our programming, maybe we'd have to check
some errors we have in our algorithm and
in extreme cases we may have to go
back and look at a new solution design, a
new solution to our problem. Then once
we're satisfied that the program goes
through all its tests successfully
and all the bugs are out of it, then we can
put the program into service. So, why do
we bother programming a computer at all?
Well the big reason is that of speed.
Computers can typically do operations
much faster than humans can,
particularly if it comes to arithmetic or
other computational operations. They can
also do those operations with much
greater accuracy and precision than
humans can. So if we're looking for
accuracy or precision in our results
then the chances are we will ask 
for a computer to do it.
Another reason for getting a computer to
do it is, humans typically get bored if
they're asked to do the same operation over and over again, so if, for example
there's lots of additions to be done of
maybe all of the purchases that
were made in a shop during the day, and
we want to get the total and we
have to add up all of the numbers and we
have to do that every hour, every day, for
every week, then a human will easily get
bored doing that. So one of the things
about computers is that they don't get
bored. So we can give them the same
operations to do over and over again and
they'll do it and unless something
extraordinary happens. They'll do it
without mistake every time. Another
reason that we will get a computer to do something for us is because what we want them to
do is may be a bit dangerous.
So if we want to defuse a bomb or
if we want to go to an uncharted planet
then we'll typically send and some sort
of robot there first just because
there's a lot of danger involved we
don't want to risk human life. There's also some things that computers
are better at than humans and in
particular as I mentioned before are
arithmetic or other computations, computers are typically better at those they do
faster, they do more accurately, with more
precision than humans can. So what do
we do when we we actually
program? A computer program, as I say,
is written to solve a particular problem.
In general, it's the programmer who
solves the problem not the computer. All
the computer does is take the program
and execute it or run it, but it's
the programmer who actually has
written the design, the algorithm and
translated that into a programming
language. Now, I would say that there has
been some research done recently on
computers actually writing programs and
that's a current research topic but in
general, for most commercial programs,
it's the programmer who solves a problem
not the computer. What the programmer
does is that gives the computer precise
instructions
on what to do
and that's what we call the program. So
the program then is the description to
the computer of what it has to do and
how to do it. The program is the solution
to the problem: when it's executed,
we'll get the required result. The
set of steps required to solve a problem
is called the algorithm and an algorithm
written in a particular programming
language is called a computer
program. So we start off with our
problem, we design a solution to
that, we formulate that solution as an
algorithm and then we translate the
algorithm into a program in a programming language and
that's what the computer runs. That's
essentially the task of programming.
You might ask, well why do we need a
programming language? What's wrong with
natural languages? We use natural
languages all the time and we can
usually make ourselves understood,
whatever about the accent, but usually we
can get the concepts across, so
what's wrong with natural languages? So
natural languages are
expressive, flexible and rich but
also ambiguous and it's imprecise. There
are also many natural languages but we
would prefer to have one precise
language that everybody could use and to
share the concepts that we have in
programming. Here's some examples of
the ambiguity that we have in natural
languages: You should have seen the bull
we got from the Pope. So this has
got at least three different readings,
and that's assuming that we've only got
one Pope, because in the Middle Ages
there would have been situations when we
would have had two or even three
different popes at the same time. One
reading of this first statement is that
a bull is a letter from the Pope to his
flock, so 'you should have seen the bull
we got from the Pope' could mean the
Pope has written us all a letter and you
should have seen it.
Another use of the word
bull is 'that's rubbish', so you may not
agree with what the Pope said in this
letter, you should have seen the bull we
got from the Pope in that letter we got
last week. So that's the second
reading, another reading of it is that
the Pope is actually the head of state,
he's a head of state of the Vatican, and
maybe he was on a state visit to some
poor country, in Africa for example, and
as a gesture of goodwill and support he
brought them a male cow, a bull and he give
them the bull as a present: 'you should
have seen the bull we got from the Pope'.
So as you can see even though it's all
aligned, all the words in that sentence
we know, there's a fair bit of ambiguity.
Just quickly looking at the second one:
'competent women and men hold all the good
jobs in the firm'. So first of all, there's
a bit of ambiguity there is what
constitutes a good job?
Is it the manager's job or is it
somebody who can come into work, sneak
into work every day and get paid for
doing nothing or is it a job that allows
you to have good promotion prospects and
then at the very beginning of that
sentence competent women and men so is
it competent women and competent men or
is it competent women and men no matter
how useless they might be hold all the
good jobs in the firm? So there's a lot
of ambiguity in natural language. We also
have a lot of imprecision in natural
language so 'Albert is tall'. This all
depends on what we mean by tall and who
Albert is. If Albert is
somebody living in Ireland, an adult in Ireland, they're over 1.8 meters
or so then they would be regarded as tall. If they're in baby
infants and they're a metre tall, they would be regarded as tall. However, if they are
1.8m and they're
playing on a U.S. college basketball
team, they wouldn't be regarded as tall.
So the measure of tall
or the meaning of tall there is very
imprecise, it all depends on the context.
The tall that we have for Albert is
completely different from the tall that
we might have for the Albert Hall which
is a concert hall in London which is a
few hundred meters tall and that is
nothing compared to the tallness of the
Burj Khalifa in Dubai which is almost a
kilometer tall. So this whole notion of
tall is very imprecise and can lead to a
lot of confusion if we use it in
conversation. Similarly 'the ferry is huge',
that all depends whether it's a ferry
from
Burtonport to Arranmor in Donegal or from
Baltimore to Sherkin or Cape Clear in
Cork, or whether it's the ferry
that goes from Dublin to France or from
Cork to France. 'The computer is fast':
a computer that was fast 20 years ago
wouldn't be
considered fast nowadays. 'The hundred
meters was fast; depends on whether this
hundred meters is being run in the Olympics
or it's a hundred meters been done by
Albert from baby infants. So what is an
algorithm? An algorithm is a set of
instructions that when executed will
solve a particular problem. Typically, it
involves a finite set of instructions, so
there's a limited number of instructions
and also it runs in finite time, that is
it stops eventually. Now, there are some
situations where we don't want the
algorithm to stop. So for example, if our
algorithm is monitoring the nuclear
power plant down the road then we want
that to run all the time. Similarly, if
our algorithm is controlling the
Airbus that were flying in then we want
that to keep going all the time or at
least until some point that the
pilot turns off the ignition or whatever
they do to stop an airplane.
The word algorithm originally
comes from the name of a Persian
mathematician in the ninth century
who wrote On the Calculation with Hindu
Numerals and when this was translated
into Latin then the word 'Algoritmi'
was what was came out of his surname Al-Khwārizmī. I'm just going to finish off
then by looking at a sort of an analogue,
a real-world analogue of an algorithm.
Now everybody since lockdown has been
doing lots of cooking and baking,
certainly has been happening in our house
and this possibly isn't one of the
recipes that you've been doing because
it's not the season for Tea Brack, even
though I think personally the Tea Brack
should be in season all year round,
so this is actually a real-life
recipe, it comes from Odlum's, the Odlum's
website, so you need self-raising flour, fruit mix, cold tea, castor sugar, an egg, mixed
spice and so on.
Then you've got the ingredients
which are your basic variables, if
you like, for your program and then
you've got your method which is your
algorithm. So this is a reasonable
analogue of an algorithm, but however, there are a few problems because it's not
really an algorithm, so it's a bit
imprecise, there's lots of detail left
out. For example, if you were to give this
to a computer or a robot to do, how do
you beat an eeg, it doesn't say how to beat an egg. Also, what kind of tea do you use? So
anybody who makes tea brack knows that
you have to use Barry's or Lyons or
something like that, you don't use chamomile or something like that, it's not
going to give you the same flavor on
your tea brack. What's a good pinch?
Now, most bakers and cooks will know
what a good pinch is, it's certainly not
a fistful. Which shelf in the oven? Because again, bakers and cooks
will know that the shelf that you put
your stuff on in the oven is going to
make a difference to the heat.
What is overnight? So for example, if you
are a night owl and you don't go to bed
until 3 o'clock in the morning and you
get up at 7 o'clock is that enough of an
overnight compared to somebody who goes
to bed at 10 o'clock and doesn't get up
till midday. Also, the recipe says
approximately 1 hour, it makes reference
to the word risen and
it talks about being firm to the
touch, again there's a lot of imprecision
there. Also, there's a bit of ambiguity in
the algorithm, it talks about adding
sugar, egg, flour and mixed spice but it
doesn't say add to what, remember
if we want to have this as an
algorithm, think of trying to explain
this to a stupid robot. So everything
has to be explained in detail. Also
the recipe doesn't account for fan
assisted ovens, because as
baker's will know, a fan assisted often
will be hotter, you'll put it in for
less time or you'll need less heat.
One of the omissions that we have in
our algorithm is that it doesn't actually say
to take it out of the oven, if you
actually read the recipe
carefully, it forgets to say take
the thing out of the oven. So this is the first
quarter hour of an introductory lecture to
programming. We would go on to talk a bit more
about algorithms, we would talk a bit about
algorithm design and it's actually,
certainly in any module I would give
it's probably lecture two before we
actually start talking about
particular programming languages and
before we start talking about how to
actually encode our algorithm in the
programming statements we have available
in the language. You may think that
this is a bit introductory and maybe
preempted among the questions that Gary
will have, but it is just to emphasise
the fact that in the Computer Science
programme in UCD we don't expect any
prior experience of programming, we
start off from scratch and we don't
assume that you have seen programming
before.
