In article <4lglr2$ceg@percy.cs.bham.ac.uk>,
luc_beaudoin@com.newbridge.qmail (Luc Beaudoin) wrote:
> RE>Java (slightly off topic) 4/21/96
and some days later it appeared on the demon news server (I've been waiting
to reply, as Luc also copied his post to me by mail).
>
>
>It is refreshing to see a serious contender against and improvement on C/C++.
>
>>pop11 (ie garbage collector, no "bare" pointers). Plus it is pure OO.
>
>I don't want to argue about what "pure" is, but it is significant that Java is
>not objects all the way down. As you mention it has a bunch of types that were
Ok, it is not "pure". What I meant (and I shouldn't call it pure OO) was
that
all functions are methods of some class or other. I'm not sure even this is
true, as some built-in operators are overloaded (like +), although users
cannot themselves overload operators (unlike C++).
I think it would be more accurate, instead of "Plus it is pure OO", to say
"But it is not pure OO". :-).
Nevertheless, somehow it "feels" OO to me. I don't care about ideological
purity, as when even ints are instances of some class. So it is even more
like pop11 than I originally implied!
>included for efficiency reasons but which make coding tedious. One has to
>translate ints into Integers, booleans into Booleans, etc,, and one has to be
>very sensitive about whether a method expects an object or just a type. I
>haven't used Pop-11 since Objectclass has become fully integrated, so I don't
>know what kind of problems new Pop users are having on that front.
Yes, I agree you would have to do this, and that it is a pain. But I've
never wanted to (for example) define new booleans inheriting from the built
in booleans, so I can live with this.
Incidentally, the existence of booleans is yet another similarity with
pop11
(and a difference from lisp). Except that there is no using non-booleans in
a
conditional expression: you have to use if (j == 0) or if (j != 0) if you
want to test for non-zero values of an integer.
I wonder how many bugs would have been avoided in pop11 if a non-boolean
in a condition caused a run-time error (mishap) instead of being treated
as non-false?
(snip)
>Jon, I'm not as big on "small" as you are. Static typing, single inheritance,
>method dispatching based on a single argument, and the absence of incremental
>compilation and macros do not make programming easier. I think Pop-11
>illustrates that you can have "big" features while being "small".
It's more a historical comment: "big languages don't survive". Time will
show if it is true. Incremental compilation is a big win: that's why
incremental C++ development environments cost so much (and lesser mortals
like me have to use conventional compilers). (BTW macros are a Bad Thing.)
But actually, incremental compilation is less important nowadays. It is
only when you get up to a few thousand lines of code that it starts
becoming important, and I tend to segment problems into pieces if they
get bigger than that, with each piece a separate library. It is still
a pain to wait for a link, but only _really_ big programs are still a
problem. And (IMNSHO) the days of monolithic monsters are numbered. We
are heading for component-ware. When the applet you are working on (all
few hundred lines of code) compile, link and start in under a second, who
cares if it could have been a few tenths of a seconds faster? Especially
if the code runs faster. Modern machines are seriously faster than when
Poplog was started, and the end is not yet in sight.
And it is the "componentware" nature of java that aroused all the initial
interest. I'm sure a simplified pop11 could have been used instead.
But I'm inclined to agree with you: it is not smallness, so much as a good
set of features. I think a large, standardised, library is good. Maybe a
language is "too large" when it has features that are hard to learn or
hard to implement, or not very useful.
C++ now has exceptions. They impose a run-time penalty. How many people
will use exceptions, and how many will continue to return success/fail
codes from their functions, and test them in the calling routine? I
understand the arguments in favour of using exception handlers, but I
don't like them. Maybe I'm old fashioned. Maybe I don't like non-obvious
transfer of control (did anyone mention "gotos"? :-).
To return to your comments:
I've already commented last week that Java has a kind of multiple
inheritance
(not full multiple inheritance).
Static typing, when you know the type. But run-time typing when needed:
you can have variables of type "Object", to which anything can be assigned.
I actually find typed variables help in understanding poorly commented
code.
After all, if you see a variable declared as of type "AbsTime" and
another of type "RelTime", as in the following pseudo-code, it is fairly
easy to guess:
AbsTime a;
RelTime r;
TimeNow() -> a;
ShiftLength() -> r;
while ... do a + r -> a; ... endwhile;
It is also fairly obvious that
a + r -> r;
would be a typo. (Probably a braino, if real variable names instead of
a and r.) Except that with static type-checking, it would be picked up
at compile time. (And you couldn't use the "+" operator in pop11 or
java.)
Of course, you get the type checking with objectclass - but it would be
a run-time error. Even if you override addition of durations (maybe you
want different shift patterns or something), so that you have run-time
dispatch for the absXrel->abs operator, it is hard to believe that
absXrel->rel could ever be correct.
--jlc
|