[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon May 7 00:48:22 1997 
Subject:Re: The future of POP-11 
From:Jonathan Cunningham 
Volume-ID:970507.04 

In article <5kfdcb$5hv@infa.central.susx.ac.uk>,
richardm@cogs.susx.ac.uk (Richard Matthias) wrote:

>Jonathan Cunningham (jlc@sofluc.demon.co.uk) wrote:

>: Sounds like a good idea. I've been saying for several years now that C++
>: is too hard to learn (i.e. the demand for programmers exceeds the supply
>: of people capable & willing to use C++). It wasn't obvious until about
>: a year ago what would replace it.
>
>The reason there are not enough c++ programmers is that there are (a) not that
>many good programmers full-stop and (b) programming is not taught sufficiently
>well.

I'm not so sure about (b). It assumes that there are enough people
with the innate ability to program well. An ideological assumption,
which is currently becoming less fashionable (that everyone has the
same potential. Very PC, but patently absurd, if you think about it).

>You can think of c++ as a super-set of C, so depending on how much
>functionality you want to use, it is really no more complex than C. In

It's true that C is no more complex than C. And also true that many
alleged C++ programmers program in C (but use C++ compilers).

>addition there are things in c++ like templates and  the STL (standard

Templates are an abomination. Not only ugly, but I have *yet* to come
across an implementation without bugs. That may have changed in the
last few months (though I doubt it - ok, I've only used four
different C++ compilers with any degree of seriousness - but I've also
read comparative reviews). But we are still a long way away
from the kind of optimisations that I would expect (e.g. not making
zillions of copies of identical code for different type instantiation).

>template library) that a quite complex to learn if you are a library
>developer, but as a library user actually make programming simpler by a
>margin.

I'm prejudiced against the STL as well.

>Java *will not* replace c++ ever. The JVM is useless for many environments

Hah! How young are you? You may be right, but if so, it will be for the
wrong reasons. Languages change a lot over time. I've no idea what Java
will look like in three years time. But I predict that a lot of its
current deficiencies will have been plugged. And Java will also be well
on the way to becoming bloated, and ripe for replacement.

C++ is currently TLOC for hackers (in the traditional sense, not the
media sense). But hackers (or ace programmers) tend to prefer elegance.
C++ is not elegant. OTOH, some people still use Fortran ...

C++ also has some serious defects as a systems programming language: a
task for which it was never intended (Stroustrup invented it as a
language for use by a single programmer - not teams. Have a look at
"The Design and Evolution of C++" where he explains his design
decisions). The recent introduction of namespaces is not going to
solve this.

>(though it is well suited to AI work) and even if you compile directly to the
>physical machine the madated garbage collection makes Java unsuitable for many
>many things.

For real-time control work, I would still expect to use C, at present, not
C++. For a variety of reasons. However, there is no intrinsic reason why
garbage collection should preclude this kind of use. Asynchronous
incremental GC algorithms have been known for years. But I don't
expect them to be implemented for Java; my guess would be that
people will stick with C for low level stuff.

>In addition the lack of libraries and tools mean that Java will not even
>compete with C++ in Javas strongest arena (desktop apps) for at least another
>2 years.

I agree with this: not before 2000 at the earliest. But I never implied
otherwise. (Although some software companies are already developing apps
in Java - so the first serious apps will appear sooner than this.)

>: Having done a certain amount of AI programming in C++ recently, I, for
>: one, expect java to be an improvement (the language - I'm not sure if even
>: yet the development environments are ready for serious work).
>
>Garbage collection is about the only thing Java actually buys you over c++
>from an AI point of view and you can get GC in C++ with a library so its no
>big deal.

Or smart pointers (what I use). But this is a small point. The reason for
preferring Java is that C++ is ugly. Much more important ;-). A language
which lets you pass arguments as pointers *or* references? That's only for
backwards compatibility <Shudder>.

Or, if you want a serious reason, it is because there will be a move
away from monolithic applications and application bloat. Netscape (IMO)
is making a mistake by trying to fight this and produce another massively
bloated all-singing-all-dancing mail+news+life-the-universe-and-everything
app. Oh, I don't believe in the NC, but it really is time we moved back
to a more cooperating applet style of software development. I hope it
happens soon. Java could facilitate that. There's a whole re-usable
objects can of worms here too, which I don't have time to go into.

>Object orientation is usefule in AI for simulation work, but with Java you are
>forced to use it. No problem for the experienced programmer, but when you are
>teaching a beginner to program (something pop11 has been used for at Sussex)
>you really don't want to have to explain OO at the same time before they can
>even get their eliza or whatever going.

Aaargh!! No wonder you said programming was not being taught properly: if
you aren't teaching OOP from day one, you are making life *much* harder.
Do you also teach algebra using Roman numerals before introducing
the decimal system?

I'm not going to argue this point: if you don't agree that OOP is
simpler than procedural, then I won't be able to convince you. But I
would also be sceptical that you've yet acquired the OOP mindset, and
think in terms of objects and methods rather than procedures and data.

>Object orientation is usefule in AI for simulation work, but with Java you are

What a strange thing to say. I wouldn't dream of writing *any* program
other
than as an OOP. See above re mindset.

Incidentally, it's interesting to compare the number of Smalltalk
vacancies with the number of lisp vacancies being advertised. (I'm not
a smalltalk advocate BTW, and have little experience of it myself. But
there are more vacancies.)

>: Note that "small and simple" doesn't imply low level. Words and lists in
>: pop are simple. Why have vectors, arrays, strings etc.? Those are
>: implementation details, and I shouldn't have to know about them.
>
>Because somewhere along the line people decided they wanted to write useful
>software in pop. Lists are a nice data abstraction, but you pay a huge

You misread my post. Lists are *not* a nice data abstraction. They are
one way to implement the abstraction of sequences, and are the most
efficient way to do this for certain algorithms. Vectors are more
efficient for other algorithms. It's because of the way that pop11
compilers have traditionally been written (a neat idea, BTW) that it
is difficult to carry out global optimisations, which would include
late commitment to data structure choice *by the compiler* if you
had Sequence as a basic abstract data type. I think there may now
be a consensus that it would be better to generate a full parse
tree as an intermediate, rather than directly emitting pop VM in
the syntax procedures.

>performance hit if it doesn't fit your algorithm. STL (see above) has a vastly
>superior attitude towards the interface of data absractions and algorithms

No it doesn't. I don't like STL. Maybe I'll dislike it less when they
(the standardisation committee) get it closer to being right. Meanwhile,
I write my own libraries except when necessary to co-operate with other
people. (This at least has the advantage that I don't have to worry
about bugs in the library.)

>using iterators. ObjectSpace have provided a similar facility for Java in the

I don't overload operators either in C++. It's one of those cute things
that makes code much less maintainable.

I have my doubts about the utility of some other features too (exceptions,
RTTI etc.) which add a lot of overhead for relatively little benefit (IMO),
but I'm still reserving judgement on those.

And, in case you are wondering, all these prejudices are derived from
actual experiences. Yes, I have hired a contract C++ programmer to port
some of my code, and he spent three weeks looking for a bug in it. And
failed to find a bug - because it wasn't in my code, it was in
the library. (Actually, it was in the "new" allocator of the
target compiler. No wonder he thought it was my code! I had to use one of
those memory checking thingies before even my colleagues would believe it.
Then it turned out it was a "known bug". <Sigh>)

And I've done all the pretty things like redefining pointer and assigment
operators to maintain reference counts, so I didn't have to worry
about memory management.

So if you are happy with C++, keep using it. It does have some
virtues.

Jonathan