Michael G Schwern wrote:
> On Tue, Jun 05, 2001 at 08:24:31AM -0700, Daniel S. Wilkerson wrote:
> > But in the end, I'm most concerned that my code is correct. Having
> > the compiler check everything it can possibly check for me is really
> > a requirement for that. Compile time type checking of method
> > signatures is really helpful as well.
>
> What you count as Java's greatest strength, I count as Java's greatest
> weakness. You have to remove *alot* of language features to get down
> to the point where its predictable at compile time.
You only remove these features if you turn on the "strict-type-checking"
mode, as someone else and I suggested.
Having compile time checking is just asking that the sentences in your
program make sense at a certain basic level before you run it. I cannot
imagine running an enterprise critical application where this has not been
checked. You are just hopeing with your fingers crossed behind your back
that every combination of things that will occur during runtime was found
during testing.
Here is a major point: Compile time checking is
a - syntactic, and
b - local.
You really can finish checking everything, if the type information is there.
In runtime checking, there are non-local dynamic things that can happen. You
can't possibly check them all. Some subtle bug in one part of your program
messes up some datastructure, which only fails when some other completely
unrelated thing is run a day later in some other part of your program. For a
sufficently large program, you can never check all of these combinations.
>
>
> No subroutine refs. No dynamic inheritance. No autoloading. No
> dynamic method calls. No symbol table manipulation. No eval. No
> automatic method generation. (That's off the top of my head).
You don't loose all of these. Java has interfaces, and then any class, even
loaded at compile time, that satisfies an interface is allowed to be used in
its place. This is as good as subroutine refs (and in general object refs)
that are checked at compile time, but where the implementation shows up at
run time.
Dynamic inheritance, is that messing with the inheritance tree at runtime?
I've never found a need for that. I think a lot of these features are just
bad habits that people may use but they don't realize that they don't really
need (like computd gotos). I've never used that, if I'm understanding you.
Java allows you to load classes at runtime. The interface / implementation
matching is checked then. No, you can't do many of the tricks that you can
in Perl, like having autoload implement methods for you that don't really
exist lexically, etc. Again, this would only not be allowed in
"strict-type-checking". So, you give it up only if you want to.
Not sure what a dynamic method call is. Virtual method calls, perhaps? Java
has these.
Symbol table manipulation is for me another "computed goto" something I don't
think I'll ever want. Again, you only give it up in the special mode.
No eval of strings, you mean. eval of blocks is fine: eval {}; if ($@) {
etc.}. Eval of strings seems like a very local thing that I would rarely
want to eval large chunks of code in. Perhaps it could throw a "type
checking failed" exception that you could catch outside the eval.
Automatic method generation. Again, never found the need, and you only give
it up if you want to.
>
>
> Every class in the hierarchy has to be defined and loaded completely
> at compile time (well, at least their method signatures) and defined
> strictly. If there's a class which isn't strictly defined anywhere in
> your hierarchy, no go.
Yes, that's the point.
>
>
> Also, since you're doing so much more work at compile time, any
> strictly typed code will probably have to be pre-compiled or else be
> sluggish to startup (this is just a guess).
Again, for large applications, one expects them to be pre-compiled.
>
>
> An optional strict typing system would be nice, but I just want you to
> be aware how difficult it will be to do right, and what you give up by
> using it. This isn't just a "let's toss this in" sort of feature.
Yes, its not easy to do right, and it is very helpful. Certainly worth it in
my opinion.
> > It got to the point in Java that I would sometimes check in my code
> > without even testing it I was so sure it was correct. I can't
> > imagine ever saying that about Perl.
>
> I can't imagine ever saying that about any language! Type checking is
> nice, but its just one class of error-checking. Doesn't do squat for
> basic logic errors, for example.
No, it does. Just as people have more accidents when talking on their cell
phones while driving, even if the cell phone is mounted on the dashboard and
their hands are free, the more you have distracting your attention, the more
likely you are to make other mistakes. Human attention is the ultimate
precious resource.
"By relieving the brain of all unnecessary work, a good notation sets it free
to concentrate on more advanced problems, and, in effect, increases the
mental power of the race."
-- Alfred Whitehead (1861 - 1947)
Quoted in P Davis and R Hersh The Mathematical Experience (Boston 1981).
http://www-groups.dcs.st-andrews.ac.uk/~history/Quotations2/215.html
And yes, I stand by what I said. You can write code in Java that you can
look at and know that it works. Your mind is on what you are saying. The
compiler is preventing so many little gotchas.
Daniel
