Re: Static vs Dynamic

From: Pascal Costanza (costanza_at_web.de)
Date: 10/23/04 

Date: Sat, 23 Oct 2004 14:34:13 +0200

Darren wrote:
>>The code at that link just demonstrates an officially recommended
>>standard Java idiom. Are you saying that the Java designers have been
>>inexperienced programmers? Not a very good advertisement for that language.
>
> The example was not standard, it was wrong, the standard use of
> iterators is to assign the iterator result to a variable of the type
> you expect. The fixed version follows the standard way to do it with
> the addition of this code:
> Object key = i.next();
>
> Virtually any example of Iterator will do the same thing.

I didn't say that the example is standard, but that the idiom is
standard. Yes, the example contains a bug that may be very obvious when
you look at the code _in isolation_. When it's part of a much bigger
project, it's easy to miss the bug because the code looks quite correct
from far away. (Java has too much noise in its source code, which makes
it hard to see the essential stuff.)

> I wasn't saying java developers were inexperienced, just the guy who
> created the initial bad code.

As an experienced Java programmer you need to keep lots of code idioms
and patterns in mind and know them by heart which could be be automated
in other languages. In other words, the experience that Java requires
from programmers is a waste of time.

>>Generic types were supposed to improve the situation, but they actually
>>seem to make things worse. See http://www.mindview.net/WebLog
>
> I don't feel I can comment on this because I haven't had enough chance
> to explore generics yet... stuck in 1.4.2 for a while and no spare
> time atm. :(

You should really read Bruce Eckel's blog entries about them. (AFAICT,
Bruce Eckel is quite an experiented Java programmer.)

>>>Java doesn't assume programmers are idiots, therefore if used
>>>incorrectly, it can give the developer as much rope to hang themselves
>>>as an untyped language. The only difference is you have to ask for
>>>the rope.
>>
>>The explicit goal of the Java designers was to make the language usable
>>for "average" programmers. They may not be idiots, but the specific
>>example used in the above cited article doesn't require a lot of asking.
>
> This is not actually correct. The goal of Java, according to Gosling,
> was to make it easy for C/C++ developers to learn, and remove some of
> the more common bugs that occur in those languages. You heard some
> bad marketing material or something. When asked in an interview,
> Gosling admitted he had no idea how hard it would be for a newbie
> programmer to learn Java.

I quote from one of the original Java white papers from 1996, written by
James Gosling and Henry McGilton:

"The system that emerged to meet these needs is simple, so it can be
easily programmed by most developers; familiar, so that current
developers can easily learn the Java programming language; object
oriented, to take advantage of modern software development methodologies
and to fit into distributed client-server applications; multithreaded,
for high performance in applications that need to perform multiple
concurrent activities, such as multimedia; and interpreted, for maximum
portability and dynamic capabilities."

"Primary characteristics of the Java programming language include a
simple language that can be programmed without extensive programmer
training while being attuned to current software practices. The
fundamental concepts of Java technology are grasped quickly; programmers
can be productive from the very beginning."

See http://java.sun.com/docs/white/langenv/index.html

They mention a number of other design criteria, including the one that
you quote. Note that mentioning one goal doesn't mean that it's the
exclusive goal. Further note that there is a fundamental difference in
having a goal and attaining it. (I also doubt that C++ programers find
it easy to switch to Java.)

>>Java's type system doesn't really make the language more powerful. Type
>>systems that allow you to, say, dispatch on the return type of a method
>>can do a few things more than dynamically typed languages, but not
>>Java's. Java's type system actually introduces sources for bugs that you
>>wouldn't have in some dynamically typed language. See
>>http://prog.vub.ac.be/~wdmeuter/PostJava04/papers/Costanza.pdf
>
> In your paper you used this example:
>
> IPerson dilbert = new Person("Dilbert");
> Company dogbert = new Company("Dogbert Consulting");
> ...
> dilbert = dogbert.hire(dilbert);
> // returns a wrapper of type Employee with new methods
> // old methods are forwarded to the original object
> ...
> System.out.println("Name: " + dilbert.getName());
> if (dilbert instanceof Employee) {
> System.out.println("Employer: " +
> ((Employee)dilbert).getEmployer().getName();
> }
>
> I did find this interesting but it is still not the languages fault,
> it is a threading bug. The same kind of bug can happen in just about
> any language when using threads. In C you could have a pointer end up
> pointing somewhere else, but it is much more difficult to identify
> when it happens. At least Java adds key words to make solving a
> problem like that pretty easy and exceptions to help you identify
> them.

First of all, this was not the only example in my paper, but one of
three examples. Do I understand that you agree to the validity of the
other examples? (Most people with whom I have discussed the paper accept
the first two examples but don't agree to the third one.)

Secondly, I still think the third example is valid. I think it's not
primarily about threading but may happen as well in the single-threaded
case. I don't have a good example though.

> If faced with this in the future, use a synchronzied block:
>
> synchronized(dilbert){
> if (dilbert instanceof Employee) {
> System.out.println("Employer: " +
> ((Employee)dilbert).getEmployer().getName();
> }
> }

I know how to program in Java. I have used it exclusively and
extensively for seven years, since the second beta release of JDK 1.0.
Writing correct multi-threaded programs in Java doesn't consist of
arbitrarily placing synchronized statements in several places. Your
suggestion wouldn't work because you are not synchronizing the other
accesses to "dilbert".

But this is besides the point anyway. The gist of that example is that
the bug occurs only after three hours of repeatedly reassigning
"dilbert" every five seconds. That's a very extreme assumption - in
reality the assignments would occur much less often. The Java language
doesn't help you at all in seeing that there might be a problem. To
restate my statement made in the paper, this is the kind of bug you
definitely don't want to have. It's one of the worst because it is not
reproducible. (And it is based on a "check an object's type before
casting it" idiom as described in the Java language specification!)

>>If you know about studies that actually show how Java's type system is
>>in any way better than others (without resorting to circular reasoning,
>>for example by giving proofs of soundness), I would be very interested
>>in knowing about them.
>
> Sorry, I don't. To be honest, I don't really think it is necessarily
> better then other systems. It just is what it is and should be used
> as such.

Here is my summary:

Java was designed as an environment that is exceptionally easy to use by
inexperienced progammers. However in fact, it takes a lot of experience.

Especially, Java's type system was designed to detect bugs and ensure
"robust and secure" programs. To quote from that white paper again: "The
Java programming language is designed for creating highly reliable
software. It provides extensive compile-time checking, followed by a
second level of run-time checking. Language features guide programmers
towards reliable programming habits."

However, the facts are that a) in many cases, the type system lets very
obivous bugs slip through and b) in many cases, the type system doesn't
let you do what you want which makes you work around the type system and
creates additional sources of bugs.

Why should a complete failure taken as "what it is and [...] be used as
such"?

Pascal 

-- 
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."

Relevant Pages

  • Re: Why do some people hate java?
    ... programming language like Java to exist, or if Java must exists, there's ... The majority of programmers at the time were using C++, ... and other resources that are just as important to ...
    (comp.lang.java.programmer)
  • Re: Static vs Dynamic
    ... it's easy to miss the bug because the code looks quite correct ... >>As an experienced Java programmer you need to keep lots of code idioms ... These problems don't exist in a dynamically typed language. ... Any bad thread programming in any language is troublesome ...
    (comp.lang.lisp)
  • Re: How did C++ beat the competition?
    ... Efficiency is supposed to be built into the JVM, ... With C++ that meant that programmers had to learn a lot more or only use ... about Java as C++ programmers know about their language. ...
    (comp.lang.cpp)
  • Re: CollabRx seeks brilliant engineers for an excellent e-science adventure
    ... belief that lisp programmers are smarter/better. ... Java or PHP programmers. ... a type of language that attracts a personality that meets my perceptions ...
    (comp.lang.lisp)
  • Re: Why Generics?
    ... > Every study I've ever heard of concludes that the cost of a bug ... ``Smalltalk v. Java: Which is More Productive? ... As essentially a rather static language, Java needed generics. ...
    (comp.lang.java.programmer)