Why Generics?

[Andrew Thompson]

Chris Uppal coughed up:

Changing the subject line for this and (lol) removing the conversation
context was a sketchy thing to do. It means that this message has
landed on some browsers as a thread on its own. Yikes.

I think it is better that way. Certainly funnier. ;-)

 

[Dale King]

Dale King coughed up:

(e-mail address removed) wrote:



Remember that you must always fail as early as possible! Generics
turn Runtime Errors (class cast exceptions) into compile time
errors. This
has tremendous values.

For this to have "tremendous value" then it must be the case that
class cast exceptions are being thrown in expensive-to-change code
(deployed or late in testing) on frequent basis. That is not my
experience.

[...]


It greatly depends on whether or not you ship your code. Of course
if it's you who is the 'client' or someone in the next cubicle, you
are right. But sometimes its halfway around the world.


This is something of a simplification. I agree that code that has
shipped (however far it's gone physically) has a higher cost to
change than code that has not shipped. Code that has shipped to
many customers has a higher cost than code that has shipped to only
a few, or even none. Etc. But what your analysis misses is
factoring in the probability of there being a problem in the first
place. If that were mathematically, exactly, zero then clearly it
doesn't matter how far the code has shipped. If the probability is
low enough then even when multiplied by the large cost of late
changes, the resulting probable cost is low. It is not enough to say "it
would be bad if it happened", you also
have to ask how likely it is to happen before you decide what
preventative measures are justified.

As others have said, class cast exceptions are so rare that many
people have never even seen one -- not even in development code (I
never have) -- so the probability of there being one in any given
shipped application is very low. Given that multiplier, it is
unlikely that there is "tremendous" value to be found in
"eliminating" them. Not unless the cost of failure is absolutely
stratospheric (hundreds of human lives, say).

And in addition to factoring in how likely you are to introduce such
an error you also have to factor in the probability that it will be
undetected until it ships.

I'm not sure I can say that I have never written code that never had a
CCE (although I can't think of a specific instance), but if one were
introduced its hard to think of a credible case where that would not
easily be detected at runtime so that the odds of it getting out the
door are pretty much nil. It would be nicer to catch that at compile
time but the cost differential is almost zero.

This line of reasoning is missing a critical component in order to be valid.

Even if everyone have /hardly ever/ experienced a CCE in their entire life
does not mean guarding against it is a waste of time. Why?

Never said it was a waste of time. However it is not the main reason for
generics. It is a good reason, but down the list of importance.

 

[Dale King]

That's going a bit far. It could easily be in a very rarely exercised path. 100% test
coverage is nearly impossible, especially in larger systems. The resulting cost of the
undetected problem could be quite large ... losing a major sale, for instance.

And I agree that all that is *possible*. The point was that it seems to
be quite rare. It is good to have generics to help prevent this. The
only point was that it is not the main reason for generics.

 

[Lee Fesperman]

And I agree that all that is *possible*. The point was that it seems to
be quite rare. It is good to have generics to help prevent this. The
only point was that it is not the main reason for generics.

It was the 'pretty much nil' comment that was a bit far.

Frankly, the main reason for generics is competition with other languages.

 

[Dimitri Maziuk]

Lee Fesperman sez:
....

Frankly, the main reason for generics is competition with other languages.

What other languages?

A language cannot discard compile-time type information as soon
you touch its collections framework and claim to be the most
type-safe language in existence at the same time. It's as
simple as that.

Dima

 

[Thomas G. Marshall]

Dimitri Maziuk coughed up:

Lee Fesperman sez:
...

What other languages?

A language cannot discard compile-time type information as soon
you touch its collections framework and claim to be the most
type-safe language in existence at the same time. It's as
simple as that.

1. This may be true, but I don't see how it invalidates or even addresses
Lee's statement one bit.

2. When did Sun claim Java to be the most type-safe language in existance?

 

[Lee Fesperman]

Lee Fesperman sez:
...

What other languages?

Various modern object-oriented versions of C, such as, C++. This is just one man's
opinion, I hope you realize.

 

[Antti S. Brax]

(e-mail address removed) wrote in comp.lang.java.p$

Chris Uppal coughed up:

Hope noone expounds upon the virtures of sex or breathing to you.

As opposed to Smalltalk, people here have an extremely long
first hand experience with breathing. I am also quite sure
that most people here have tried the competing alternative
and have quickly found that is it extremely uncomfortable to
live with for more than a minute or so.

And while sex might not be as popular as breathing here, most
people recognize the long and proven track record it has. Sex,
although it often is a total mess, has been developed for
hundreds of generations and it has always prevailed while it's
competitors usually fail during the first generation (I have
to admit that there seems to be a steady stream of news about
advances in the field of cloning. It is on my list of things
to try in the near future.)

 

[David Blickstein]

Chris Smith coughed up:

Interesting. I see generics as a step BACKWARDS with regard to
"self-documentation".

In the realm of C++, I've always considered one of the DISADVANTAGES of
templates as being to provide a way to AVOID having to document an
interface.

Let me explain.

Correct me if I'm wrong, but... in C++ templates classes can implement
PRESUMPTIONS about the parameterized types. That is, I can write a
template class that ASSUMES that one of the parameterized class-types I pass
in provides a method called "m".

This is commonly used in C++ to avoid the confusion, performance penalties
and overall ugliness of multiple-inheritance.

Now I haven't used generics in Java (I'm leaning heavily towards FORBIDDING
their use in all but the container classes but...

Isn't it true that I can write generics in Java that make presumptions about
the type that have absolutely ZERO "documentation" other than any comments
the implementer is gracious enough to provide? ISn't it true that even
Javadoc will NOT give ANY indication of this vital piece of information?

That is, can't I (in Java as in C++) write a generic class that presumes the
class type passed in implements a particular combination of methods and
fields? And is it not true that there's no way in the language (other than
comments) to say that "this type parameter must be assignment-compatible
with a particular class or interface?

So... unless I'm missing something about generics, it strikes me that while
it does provide a mildly useful piece of documentation about types, it also
opens the door for writing code that is far more likely to create a more
serious documentation gap than the one it "fixes"?

db

p.s. I must say that thus far, I personally have seen no remotely
compelling arguments for generics in Java. But that's just my opinion.
To me templates in C++ were a mistake created to fix another of uncle
Bjarne's mistakes: not providing a common root for class types. A classic
C++ blunder on top of blunder.

One of the things I like about Java is that unlike C++, it is very
well-designed and avoided the vast amount of mistakes made in C++. It's a
bit disturbing to see a mistake in C++ start creeping in.

I've been told that the main reason that C++'s STL hasn't caught on is that
its so difficult to avoid the pratfalls set up by its use of templates (code
bloat, etc.... all those things mentioned in Meyer's "Defective C++" book).
(FYI: Sun's HotSpot is essential STL-free.)

Compare the adoption of STL with that of Java's JRE. No one thinks twice
about using the JRE.

 

[David Blickstein]

And I agree that all that is *possible*. The point was that it seems to

be quite rare. It is good to have generics to help prevent this. The
only point was that it is not the main reason for generics.

Not according to Peter Van der Linden in the latest edition of his "Just
Java" book.

I believe he says that is indeed the main reason it is there and I think as
a distinguished Java contributor/author/employee for Sun he's a
well-informed source.

Van der Linden (my FAVORITE Java author btw) takes a lot of time in the
chapter to debunk the notion that it was done so you didn't have to write
casts when extracting from container classes, but as I said, says the main
benefit is compiler-detected type safety.

I still say that error it detects is exceedingly rare and this was a
disturbingly bad addition to the language.

 

[Chris Smith]

Interesting. I see generics as a step BACKWARDS with regard to
"self-documentation".

In the realm of C++, I've always considered one of the DISADVANTAGES of
templates as being to provide a way to AVOID having to document an
interface.

Yes, that is true of C++.

Now I haven't used generics in Java (I'm leaning heavily towards FORBIDDING
their use in all but the container classes but...

Isn't it true that I can write generics in Java that make presumptions about
the type that have absolutely ZERO "documentation" other than any comments
the implementer is gracious enough to provide? ISn't it true that even
Javadoc will NOT give ANY indication of this vital piece of information?

No, none of that is true. Type parameters to types in Java have bounds,
and the class of potential operations on a type is limited to those that
can safely be performed within those bounds. For example, you can look
at a class that is declared as:

class MyClass<T extends Number> { ... }

and know that the class does not use the type parameter T in any way
except what can be done to a generic number.

In other words, all of your concerns about templates in C++ are valid,
but they do not apply to generics in Java (by which I don't mean that
they only partially apply; I mean they do not apply at all).

It's a bit disturbing to see a mistake in C++ start creeping in.

This is a case where you should learn how something works before you
criticize it. There are lots of ways to criticize Java's generics, and
I agree with most of them (especially that they create unsolvable
compile-time warnings, especially when working with older APIs) but this
isn't one.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[David Blickstein]

This is a case where you should learn how something works before you

criticize it. There are lots of ways to criticize Java's generics, and
I agree with most of them (especially that they create unsolvable
compile-time warnings, especially when working with older APIs) but this
isn't one.

I did read up on generics, but given that I saw ABSOLUTELY zero pragmatic
value to them (moving detection of an error that rarely happens from runtime
to compiletime, and a minor "documentation" value) and lots of reasons to
dislike them (which you seem to acknowledge) I guess I didn't commit what I
learned to permanent memory.

Look, I still think that they do NOT add any substantive value to the
language. And while it would appear that the Java folks have eliminated
many of Uncle Bjarne's goofs, at the end of the day they don't add to Java
as much as they add to C++. And the only reason that they add anything
substantive to C++ is because of ANOTHER of Uncle Bjarne's goofs (not
providing a root for the class system).

 

[Dimitri Maziuk]

Lee Fesperman sez:

Various modern object-oriented versions of C, such as, C++. This is just one man's
opinion, I hope you realize.

I do, and I though that's what you meant. Truth is, C++ templates are
very much unlike generics.

Dima

 

[Thomas G. Marshall]

David Blickstein coughed up:

I did read up on generics, but given that I saw ABSOLUTELY zero
pragmatic value to them (moving detection of an error that rarely
happens from runtime to compiletime,

You may have read up on it, and you may have drawn such a conclusion, yet I
noticed that you snipped away and didn't comment on Chris's correction of
your suppositions.

Furthermore, as I've pointed out repeatedly, the fact that an error rarely
happens doesn't mean that there isn't something considerable to gain by
having it detected. The fact that CCE's rarely happen is due in large part
to the fact that engineers are aware of its danger. Generics have at least
the potential to lessen the degree of defensive coding needed. I have
suspicions that generics don't save much in regards to the bottom line, but
it isn't because the CCE rarely happened. Saying so is just a bunch of
broken logic.

 

[Lee Fesperman]

Lee Fesperman sez:

I do, and I though that's what you meant. Truth is, C++ templates are
very much unlike generics.

Yes, they are in the actual implementation, as Java is very much unlike C++. Also, there
are significant differences from the C# approach. However, there is commonality in the
general purpose. That's why I believe they were added, to fill a similar, perceived
need. IOW, for marketing/competitive reasons, to match feature lists. In this arena, the
details are irrelevant.

How and why they should be used is wholly different issue. Since they are now part of
the language, this becomes the dominant consideration for language users.

 

[Dale King]

Not according to Peter Van der Linden in the latest edition of his "Just
Java" book.

I believe he says that is indeed the main reason it is there and I think as
a distinguished Java contributor/author/employee for Sun he's a
well-informed source.

He also used to be a regular here many moons ago.

There are lots of people that say all sorts of things. Doesn't mean they
are all true. Have you read the comments by Bruce Eckel, another highly
respected author, about generics. He basically complains because Java
generics are not C++ templates.

There are lots of people of that say that is the main reason. And I
agree it is a reason. But the other reasons seem to carry more weight to me.

Van der Linden (my FAVORITE Java author btw) takes a lot of time in the
chapter to debunk the notion that it was done so you didn't have to write
casts when extracting from container classes, but as I said, says the main
benefit is compiler-detected type safety.

I still say that error it detects is exceedingly rare and this was a
disturbingly bad addition to the language.

I think the error is exceedingly rare, but think it was a good addition
to the language, except that it should have been really added to the
language instead of the hack of type erasure.

 

[David Blickstein]

Have you read the comments by Bruce Eckel, another highly
respected author, about generics. He basically complains because Java
generics are not C++ templates.

Given the first sentence above, my answer is that he doesn't sound like
anyone I would "respect".

C++ templates are a mistake necessitated by a previous mistake.

If he thinks they should be more like C++ templates, I would suggest he read
ANOTHER "respected" author named Scott Meyers. Specifically his book
entitled "Effective C++" (which almost everyone I know of refers to as
"Defective C++".)

 

[David Blickstein]

You may have read up on it, and you may have drawn such a conclusion, yet I
noticed that you snipped away and didn't comment on Chris's correction of
your suppositions.

I'm not sure what sort of comment you were expecting.

I think I did "acknowledge" the correction via saying that DESPITE the fact
that Java generics fix one of the biggest of Uncle Bjarne's mistakes with
templates, the justification I've heard for them doesn't even fall within
earshot of the line of sufficiency.

 

[Thomas G. Marshall]

David Blickstein coughed up:

Given the first sentence above, my answer is that he doesn't sound
like anyone I would "respect".

C++ templates are a mistake necessitated by a previous mistake.

If he thinks they should be more like C++ templates, I would suggest
he read ANOTHER "respected" author named Scott Meyers. Specifically
his book entitled "Effective C++" (which almost everyone I know of
refers to as "Defective C++".)

Well, one of the things that is particularly clear is that there is no
enormous consensus on language features and their value.

I'm betting that we've covered everything there is to cover with respect to
C++ comparisons with generics.


--
Enough is enough. It is /not/ a requirement that someone must google
relentlessly for an answer before posting in usenet. Newsgroups are
for discussions. Discussions do /not/ necessitate prior research. If
you are bothered by someone asking a question without taking time to
look something up, simply do not respond.

 

[David Blickstein]

Depends on how you define "waste".

You could argue that a terrorist MIGHT attack the U.S. by putting poison in
our shampoo, and thus putting inspectors at every shampoo bottling facility
is not a "waste of time". Hey it could happen!

And IMHO it is a "waste of time" if we're guarding shampoo plants INSTEAD of
guarding borders.

I also think in addition to counting "opportunity" cost in your definition
of "waste" we might also include the other costs/negatives of generics
(complexity)... but... that's a whole other topic.

db (who at this point in life and has no use for shampoo anymore)