[Tutor] Not Really Questions

[Alan Gauld]

Hi John,

I'll pitch in although I've read most of the other answers
too so I'll be adding to them mostly.

> The first one is lists... I can't for the life of me understand why 
> a list
> starts at zero. In everything else in life other than programming

Not quite. In math zero is usually the starting point, its generally
viewed as a positive number(although it is obviously neither positive
or negative) and proofs and definitions usually start by consideriung
zero - or at least defining whether zero is in or out of scope.

This math point is important because programming was originally
a branch of math and it was mathematicians who laid the ground
rules.

But, it was by no means cast in stone until implementations
of  list indexing started to be based on the start addressof the
list in memory.

In C this is even explicitly visible.

We can declare anm array of numbers like this

int   anArray[] = {1,3,5};

and then a pointer to an integer like this

int* intPtr;

We can now set intPtr to point at the array:

intPtr = anArray;

If we printed thevcontents of intPtr we would get 1
Now increment the pointer:

intPtr == 1

Now id we print iojntPtr we will get 5, the next value in the array.

We can also get the 3rd element by using

intPtr = anArray + 2
printf("%d",*intPtr)  // print the content of intPtr

and of course we get the same result with

printf("%d",intArray[2])  // print the 3rd element of intArray

So in C you can see that indexing is really a very thin
wrapper around memory aroithmetic.

> The next thing I don't understand is why the last number in a range 
> is not
> used...
>
> For a in range(1,6):
>    print a,
>
> 1 2 3 4 5

This is to make range match with the indexing.
We can do stuff like

for index in range(len(alist)):
    print alist[index]

If the two did not match you would do something like:

for index in range(len(alist)):
   print alist[index-1]

If you are going to be weird at least be consistently weird!

Finally some languages allow us to use "normal"! indexing

Pascal for example allows:

program test(output)
var
    anArray : array [1..5] of integer;
    n : integer;

begin
    for n := 1 to 5 do
        begin
        anArray[n] = 2 * n
        end;
    writeln anArray[1];
    writeln anArray[3];
    writeln anArray[5]
end.

Which populates an array with indices from 1 through 5

> The 3rd whinge is object oriented programming. I think I understand 
> the
> principle behind OOP but in practise, to me, it just makes programs 
> jumbled,

Further to the previous comments, OOP has several purposes and
is used to achieve difgfferent things. But fundamentally OOP is used
to control the complexity of large programs. If you are writing 
program
of less than 100 lines you almost never need to use OOP (You may
choose to for some of the other reasons below, but its not needed).
Between 100 and 1000 lines you are more likely to find OOP coming
in handy. Between 1000 lines and 10,000 lines you will almost 
certainly
find at least some of your code that benefits. Beyond 10,000 lines
(and I'm, talking Python code here) OOP will be almost indispensible
in helping you keep the structure of the code clear in your mind
(and in your code too!)

There are other ways to control complexity and very large programs
have been written without it. It fact its fairly safe to say that all 
the
biggest programs are OOP free being written in COBOL. But COBOL
has its own mechanisms for managing complexity and there is now
an object oriented COBOL available to combine the best of both worlds.
[On a personal note the two biggest programs I've worked on have both
been COBOL - 10 million and 6 million lines respectively. The 3rd
biggest was C++ at 3.5 million lines. The COBOL was easier... But
I've also worked on a 500K lines C program(with no OOP) and that
was the hardest of all of them! So OOP works but its not the holy
grail that some pundits would have you believe]

Other reasons to use OOP are that it definitely makes reuse easier
both within a project and between projects. It also can reduce the
code size on some types of project. It definitely makes code more
flexible by allowing objects to be swapped in and out if they have the
same "interface" or protocol.

Also some people find objects more easy to think about.
It seems more logical to move the table than to change the
table's x and y coordinates... However folks brought up with
a math or science background, or who have already programmed
find it very hard to make the mental switch to seeing the world as
communicating objects rather than data being maniupulated by
functions...

And thats way more than I set out to write!!!

HTH
-- 
Alan Gauld
Author of the Learn to Program web site
http://www.freenetpages.co.uk/hp/alan.gauld