Re: Static vs Dynamic
From: Pascal Costanza (costanza_at_web.de)
Date: 10/24/04
- Next message: Pascal Costanza: "Re: Running Standalone Lisp Programs"
- Previous message: Neo-LISPer: "Re: lisp performance questions and observations"
- In reply to: Darren: "Re: Static vs Dynamic"
- Next in thread: Pete Kirkham: "Re: Static vs Dynamic"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 24 Oct 2004 10:18:01 +0200
Darren wrote:
> 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.
..._after_ you have found out where the bug is.
>>>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've been referring to the "iterate through this bunch of stuff" idiom,
not to type casts per se. If iteration were no issue they wouldn't have
added a new for construct in JDK 5.
> Read over that again, he always uses the word *programmer*.
Read my postings again, I have also always used the word "programmer".
>>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"
[...]
> 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.
That's a neat idea I haven't thought of before. I have to think about
the implications, but thanks anyway.
> 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.
Yep, and more code implies more potential sources of bugs.
>>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.
Usually, you only want write accesses block other accesses to a
variable. That's harder.
> 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.
These problems don't exist in a dynamically typed language.
> 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.
Exactly.
>>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.
Maybe.
> a) No language can save you from bad programming.
But some make it easier than others.
> To catch those
> bugs, polymorphism would have to be removed.
No, not at all.
>>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 ;)
You have put a smiley here, so I take this as an ironic comment. I still
think it should be noted that my "complete failure" remark was about
Java's type system, not about Java in general. Some of Java's aspects
are very good, like its excellent JVM implementation, and it's good to
hear that it works well for you. In large projects the choice of
programming language is but one aspect of many issues one has to take
into account. IMHO, social issues by far dominate technical ones. [1]
However from a programming language perspective, Java sucks big time: It
was a nice little language at first, but has clearly failed to meet its
original design criteria, and the incomplete patches that are applied to
it over the years make it continually worse (-> incomplete closures for
inner classes, "autoboxing" instead of turning primitive types into real
objects, incomplete generic types, etc.)
Pascal
[1] Lispers usually have to work against "social limitations", not
technical ones. For instance, many people believe that Common Lisp is
"just" a functional language while it can be any language you like, and
it already incorporates one of the most powerful object-oriented
language around.
-- Tyler: "How's that working out for you?" Jack: "Great." Tyler: "Keep it up, then."
- Next message: Pascal Costanza: "Re: Running Standalone Lisp Programs"
- Previous message: Neo-LISPer: "Re: lisp performance questions and observations"
- In reply to: Darren: "Re: Static vs Dynamic"
- Next in thread: Pete Kirkham: "Re: Static vs Dynamic"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
