Re: Static vs Dynamic

From: Darren (pyedarren_at_hotmail.com)
Date: 10/23/04 

Date: 23 Oct 2004 13:36:34 -0700

Pascal Costanza <costanza@web.de> wrote in message news:<cldj43

> 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.)

When debugging, you would be looking at the code in isolation. For
the last 2 years I have been working on a very large Java project and
this still would have been found in minutes, if not be me then the
debugger.

>
> > 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.

Yes, casting is something to remember to do, but it's certainly not a
lot to ask and is typical in a typed language supporting polymorphism.

> 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.)

Read over that again, he always uses the word *programmer*. He is
talking about making it *easy for programmers* to learn the language,
not someone who doesn't know how to program. Making a language easy
for programmers is entirely different then making a language easy to
learn programming. That is why Java looks alot like C/C++, the syntax
is instantly recognizable to anyone who knows either. C/C++ are not
generally considered easy to learn for non-programmers. In reality
Java is only slightly easier to learn then C/C++ becuase of what it
borrowed from Lisp, garbage collection. BASIC is easy for someone to
learn programming on, not C/++ or Java.

Here is a more direct answer on the topic from Gosling:

"Q: In your experience, how long does it take for a novice programmer
to become a reasonably proficient [C/C++/Java] developer, capable of
writing nontrivial production code? How long for a programmer with
experience in one or more other languages? How can this time be
shortened?

Gosling: I know that for somebody who is a pretty talented C++
programmer, an afternoon pretty much does it for lots of folks. You'll
probably spend a lot of time going through the library manual. The
language itself tends to be a snap to learn; it's all the library
stuff that takes the time, and there the best way to do it is to just
start writing and using it, and when you need something, look for it.

For people who have never written a program before, I don't know."

(http://www.gotw.ca/publications/c_family_interview.htm)

> 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.)

Well, I actually didn't agree with "Statically Checked Implementation
of Interfaces"

You show how difficult and dangerous it is to have stub methods in
interface implementators, but there is a SIMPLE, commonly used
solution to this problem.

public class FileCharSequence implements CharSequence, Incomplete {
public FileCharSequence() {...}
public char charAt(int index) {...}
public int length() {...}
}

...

public interface Incomplete {};

By having stub implementations implement the "Incomplete" interface,
they are marked as such. Now that you have a marker interface, you
can have the compiler tell you what you need to finish. Your build
scripts do not make the "Incomplete" interface available. Using
marker interfaces is used all the time for problem like this. By
having the build scripts remove access to the marker interfaces you
can get a complete list of what is missing where. We use ones for
Incomplete, Questionable (put in from code inspections), FlawedLogic,
RequiresReview.

Very handy stuff. It not only removes the problems you listed, it
solves some others and helps ensures a quality of production builds.

For this one: "Statically Checked Exceptions"

I do agree with this one. Though it can be dealt with pretty easily
as well and without limitation, unfortunetly it requires more code.

public double[] calcStatistics() throws Exception {
try {
... make call to data abstraction layer ...
}
catch (ExceptionIKnow a) {}
catch (AnotherExceptionIKnow b) {}
catch (Exception e) { throw e }
}

...

try {
  double stat[] = calcStatistics();
} catch (Exception e) {
if (e isntanceof SomeNetworkException)
   System.out.println("Make sure you are connected to the server");
.etc.
.etc.
}

>
> 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".

Your right, but to be a fair example you should have syncrhonized the
methods that can change what Dilbert is anyways. Then this simple fix
would always work and you wouldn't even need to worry about an error
or exception handling, etc. But as you said, that is beside the
point.

I also know Java and have used it since beta. I don't expect it to
make up for incorrect usage of its capabilities. Polymorphism is a
powerful capability that I am willing to live with. The problems you
identify all extend from polymorphism, not type checking. They are
conflicting concepts and for Java to support both, there are trade
offs.

To me, what you are really pointing out is that mixing the
polymorphism and type checking within a language can lead to problem
situations that may be tricky to identify. That I would have to agree
with.

>
> 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!)

Well..that example is more about bad thread programming in my opinion,
not idioms. Any bad thread programming in any language is troublesome
to diagnose and reproduce. It's a bad example for the problem you are
illustrating IMHO.

> 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.

a) No language can save you from bad programming. To catch those
bugs, polymorphism would have to be removed.
b) Again, I see polymorphism as the source of those bugs and I am
happy Java has it.

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

I'll tell my customers Java is a failure next time they try to write
up another damn success story about their experience wtih our
software...over 3 million lines of Java, developed in 2 years, under
budget and on-time ;)

- Darren

Relevant Pages

  • Re: why is "self" used in OO-Python?
    ... and worse this has spread from Java into other ... by whatever happens to be the first OO language they learn". ... If the first programming language (or the ... I have no objection to teaching Java in a CS curriculum. ...
    (comp.lang.python)
  • Re: Public disclosure of discovered vulnerabilities
    ... I spoke of Java; ... > necessary when programming in Java. ... > it is every single programmer who wants to use the language securely. ... this is what we call the "mental model" problem in aerospace. ...
    (sci.crypt)
  • Re: 71% Say Finding New Energy Sources More Important than Conservation
    ... Most of the drive to define was for a test programming language, because each tester had it's own language and the engineer would have to re-write the program every time the testor changed. ... The only reason it was used was because people saw that it would have a longer life time than ADA. ... My group at Stanford switched to Java as their language of choice after giving up on C++ as too flawed to use. ...
    (soc.retirement)
  • Question on variable binding and assignment
    ... My Java for dummies book didn't tell me this stuff. ... Then for a dynamically typed language such as Perl, ... concept of "unbound variables" in a programming language in the first ...
    (comp.lang.lisp)
  • Re: why java is not pure object oriented?
    ... For learning I preffer language like Lisp based on ... program fast in latter, but, imho, it's very hard in former (like Java). ... CU> programming which is neither top-down nor bottom-up (though it's ...
    (comp.lang.java.programmer)
Quantcast