[Tutor] tutor

[ALAN GAULD]

> > I'm intrigued by that statement. What do you find challenging?
>
> All of it seems complicated at first because I'm not familiar with the
> nuances of the new language. ....I do not have a CS background.

That's one of the reasons I wrote my tutor. It became obvious to me 
that most web tutors assumed a CS training. I decided I neded to 
define the CS terminology and as much of the theory as was 
necessary to understand the other tutors. Kind of like the meat 
of my first year computing course at uni' but accessible to 
non-CS folks.

> > Those can usually be learnt in a morning and after that
> > its a matter of gaining experience writing (and reading) code.
>
> Not everyone can pick things up as fast as some people do.

True, but if you already understand the concepts its usually pretty 
easy to translate them to a new language. You don;t need to remember 
the new syntax, just create your own short reference card. 
I find most lamnguages can be represented on a single side 
of A4/Letter paper. Not the whole language but enough to tackle
basic problems and start getting some hands on experience.
Thats the level I mean by a morning.

> One of the first languages I learned was a dialect of Lisp, a
> functional programming language called Logo. 

Logo is great, I first used it on an old CP/M 8 bit Micro.
The syntax is easy and yet extensible, with less parens 
than Lisp. I even had a Windows version (ie it could write 
GUI programs not just run in a window!) MSWLogo, for a while, 
and an OOP version (objectlogo).

The comp.lang.logo newsgroup still has a little bit of traffic, 
I sometimes drop by for old times sake! Last time I looked 
a version of MSWLogo had been produced for XP...

> > fluent in a new language within a week. I would never send
> > someone who can program on a training course for a new
> > language (except for C++!)
>
> Why the exception for C++ ?

C++ is a really tricky language. Not only is it huge but there 
are lots of real sneaky gotchas lurking that only long periods 
of painful debugging will reveal without training. The biggest 
problem is that C++ creates zillions of temporary objects which
sometimes don't get deleted thus chewing up memory
(no garbage collection). also the rules around multiple inheritance 
and member data access are arcane beyond telling. For example:

class X {
private:
    int foo;
protected:
    int bar;
public:
    int baz;
}

class C: public X{....}

class D: protected X {...}

class E: private X {...}


C *c = new(C)
D *d = new(D)
E *e = new(E)

Now tell me which attributes are visible
1) to the methods of C,D,E and 
2) to the users of the instances c,d,e.

And thats only single inheritance!

Too much power and flexibility leads to too many permutations.

> > (One such experiment was Borland's ObjectWindows - did
> > anyone else ever use that?)
>
> Was that the one that used objects like old flowchart symbols
> to design a program? I may have seen pictures of it somewhere,
> but never actually saw it in person. =)

That's the one. It was quite powerful with very easy database access 
mechanisms (but without a loop construct!) but ultimately so finnicky 
to use that you were a lot quicker writing code. As soon as Delphi 
appeared ObjectWindows died a quiet but surprisingly prolonged death


Alan G.