Why Generics?

  • Thread starter David Blickstein
  • Start date
D

David Blickstein

In Java5, the powers that be added generics.

Can someone please explain to me what value they add to Java? I think they
are one of the biggest (of many big) mistakes in C++. And I always felt
that they only reason they were in C++ was because it made the huge mistake
of not having a common root for the entire class hierarchy: Java's Object
type.

Java didn't need any language features to implement container classes
because of this. An reference of type Object can hold ANY Object.

The biggest objection I've ever heard to that is it forces you to cast down
when you extract from the container. Big deal!

That's nothing compared to what I've always had to go thru to make generics
work in C++.

Am I missing something or did C++ weenies invade the language committee?
 
E

Eric Sosman

David said:
In Java5, the powers that be added generics.

Can someone please explain to me what value they add to Java? I think they
are one of the biggest (of many big) mistakes in C++. And I always felt
that they only reason they were in C++ was because it made the huge mistake
of not having a common root for the entire class hierarchy: Java's Object
type.

Java didn't need any language features to implement container classes
because of this. An reference of type Object can hold ANY Object.

The biggest objection I've ever heard to that is it forces you to cast down
when you extract from the container. Big deal!

That's nothing compared to what I've always had to go thru to make generics
work in C++.

Am I missing something or did C++ weenies invade the language committee?

It was the C++ weenies, definitely. You're entirely
correct: The C++ saboteurs have contaminated Java with
generics simply and only to make the language unattractive
and cause its ultimate demise. The Java people have been
suckered into kissing the Bjarne Stone.

Oh, yeah, and one other teeny-tiny thing: If you make
a mistake, it gets diagnosed at compile time instead of at
run time. Which would you rather receive: a compiler error
that you alone see, or a ClassCastException with all the
honchos from The Big Customer watching? If you'd prefer
the former, learn to like generics.
 
M

Mark Thornton

David said:
In Java5, the powers that be added generics.

Can someone please explain to me what value they add to Java? I think they
are one of the biggest (of many big) mistakes in C++. And I always felt
that they only reason they were in C++ was because it made the huge mistake
of not having a common root for the entire class hierarchy: Java's Object
type.

Java didn't need any language features to implement container classes
because of this. An reference of type Object can hold ANY Object.

The biggest objection I've ever heard to that is it forces you to cast down
when you extract from the container. Big deal!

That's nothing compared to what I've always had to go thru to make generics
work in C++.

Am I missing something or did C++ weenies invade the language committee?

Generics in Java is very different to templates in C++. It doesn't have
the very complex behaviour that templates exhibit. So don't condemn Java
generics on the basis of unpleasant experience with templates.

Mark Thornton
 
B

Betty

It was the C++ weenies, definitely. You're entirely
correct: The C++ saboteurs have contaminated Java with
generics simply and only to make the language unattractive
and cause its ultimate demise. The Java people have been
suckered into kissing the Bjarne Stone.

Oh, yeah, and one other teeny-tiny thing: If you make
a mistake, it gets diagnosed at compile time instead of at
run time. Which would you rather receive: a compiler error
that you alone see, or a ClassCastException with all the
honchos from The Big Customer watching? If you'd prefer
the former, learn to like generics.
Just curious, would you say it is possible to write good
programs and not use the generics feature? Or does it make
some things so much better that it is compelling?
 
L

Lasse Reichstein Nielsen

David Blickstein said:
In Java5, the powers that be added generics.

Can someone please explain to me what value they add to Java?

Primarily one thing: More precise static type check.
I think they are one of the biggest (of many big) mistakes in C++.

C++ does not have generics. Templates is another beast.
The biggest objection I've ever heard to that is it forces you to cast down
when you extract from the container. Big deal!

Avoiding the extra cast is a side effect of the more precise type
system. Nice, but the cast is not the real problem. It is a symptom
of not knowing the correct type at compile time, which allows some
errors to slip through to runtime.

/L
 
E

Eric Sosman

Betty said:
Just curious, would you say it is possible to write good
programs and not use the generics feature? Or does it make
some things so much better that it is compelling?

Is it possible to write good code without generics?
Well, it depends on what you mean by "good." What's your
opinion of all the Java code written in the first nine
years of the language's existence? Is it uniformly "bad?"

The value proposition of generics, it seems to me, lies
purely in the fact that they make some kinds of mistakes
diagnosable by the compiler instead of by the JVM. Every
study I've ever heard of concludes that the cost of a bug
increases the longer it remains in the code, so a bug found
by the compiler should cost less than a bug found by testing
(or *not* found by testing ...).
 
J

John C. Bollinger

Eric said:
The value proposition of generics, it seems to me, lies
purely in the fact that they make some kinds of mistakes
diagnosable by the compiler instead of by the JVM.

I see some value in the additional self documentation provided by
generic declarations. I also think there is a certain degree of
usefulness simply in organizing your thoughts at design and early
development time well enough to write type constraints.
 
G

Guest

David Blickstein said:
In Java5, the powers that be added generics.

Can someone please explain to me what value they add to Java? I think
they
are one of the biggest (of many big) mistakes in C++. And I always felt
that they only reason they were in C++ was because it made the huge
mistake
of not having a common root for the entire class hierarchy: Java's Object
type.

Java didn't need any language features to implement container classes
because of this. An reference of type Object can hold ANY Object.

Yes, and that's not 100% good. If you believe thinking
about and specifying the types of variables is a good
thing (you should!), then the following declaration is not
so good.

Map personnel = new TreeMap();

This declaration, which employs generics is (far) better.

Map<String, PersonnelRecord> personnel = new TreeMap<String,
PersonnelRecord>();

Now the human reader AND the compiler know the types
of your Map's keys and values. The COMPILER can catch
someone doing this kind of bad thing:

personnel.put("David Blickstein", "computer programmer");

(Assuming "computer programmer" is not an instance of
PersonnelRecord).

George
 
C

Chris Smith

John C. Bollinger said:
I see some value in the additional self documentation provided by
generic declarations. I also think there is a certain degree of
usefulness simply in organizing your thoughts at design and early
development time well enough to write type constraints.

Absolutely! The self-documentation aspect of generics is, IMHO, *far*
more important than the type-safety, which is really just a consequence
of the former. I have never seen a ClassCastException myself except in
code designed to generate it for learning purposes... and I don't know
of anyone who has; but that doesn't mean that generics are useless.
Anything that prevents a formulaic comment of the form "Elements are of
class String" is good. I have nothing against comments, but I do have
problems with the need for them when it can be avoided.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
M

miz

and if i never have to type ((MyBean)myArrayList.get(i)).getMyBeanMethod(),
all the better.
 
T

Thomas G. Marshall

Eric Sosman coughed up:
It was the C++ weenies, definitely. You're entirely
correct: The C++ saboteurs have contaminated Java with
generics simply and only to make the language unattractive
and cause its ultimate demise. The Java people have been
suckered into kissing the Bjarne Stone.

I knew it!!!! The @#$%ers.....
 
T

Thomas G. Marshall

Lasse Reichstein Nielsen coughed up:
Primarily one thing: More precise static type check.


C++ does not have generics. Templates is another beast.


Avoiding the extra cast is a side effect of the more precise type
system. Nice, but the cast is not the real problem. It is a symptom
of not knowing the correct type at compile time, which allows some
errors to slip through to runtime.


Hmmm..... This sounds like a dangerous preamble to the "static vs. dynamic
type languages" threads. Heck, we haven't had one of those in the last 20
minutes or so, so why not? ;)
 
R

Ross Bamford

In Java5, the powers that be added generics.

Can someone please explain to me what value they add to Java? I think they
are one of the biggest (of many big) mistakes in C++. And I always felt
that they only reason they were in C++ was because it made the huge mistake
of not having a common root for the entire class hierarchy: Java's Object
type.

Java didn't need any language features to implement container classes
because of this. An reference of type Object can hold ANY Object.

The biggest objection I've ever heard to that is it forces you to cast down
when you extract from the container. Big deal!

That's nothing compared to what I've always had to go thru to make generics
work in C++.

Am I missing something or did C++ weenies invade the language committee?

I must admit this was my immediate response on first seeing Generics in
source - "I chose to specialise to Java a few years ago precisely to get
away from this kinda crap" and all that. Same with varargs.

However, I have to say that after using them in anger for the first
time, my software is better, tighter, and more importantly more
accountable. I know for a fact that the numerous maps, maps of lists,
lists of maps and god knows what else being passed around contain what
they're supposed to, without any 'surprise' Integers or anything like
that (as long as they haven't been outside my system, but that's another
problem).

I agree they seem like a hideous construct, but in an afternoon it's
easy to make them as automatic (for you to type) as for(;;).

Ross
 
C

Chris Uppal

Eric said:
It was the C++ weenies, definitely. You're entirely
correct: The C++ saboteurs have contaminated Java with
generics simply and only to make the language unattractive
and cause its ultimate demise. The Java people have been
suckered into kissing the Bjarne Stone.

Funny thing, I know you intended this as sarcasm, but I agree with it as
written. Well. not quite literally -- I don't suppose there's any
conspiracy -- but I do think that generics have been introduced out of
ill-considered, or unconsidered, C++-envy.

I don't see anything like enough value in (Java's) generics to justify the new
level of complexity. John's post captured perfectly the (perfectly real) value
in generics, so much so that I'm going to quote it again here -- John C.
Bollinger said:
I see some value in the additional self documentation provided by
generic declarations. I also think there is a certain degree of
usefulness simply in organizing your thoughts at design and early
development time well enough to write type constraints.

I (like Chris Smith, it seems) think the above virtues are /way/ more important
than the error trapping of static type checking. But I question whether
generics actually supply /enough/ of the above good things to make up for their
complexity. The arcane effects of erasure, the seemingly arbitrary
restrictions (especially on the use of primitive types -- a problem compounded
rather than eased by auto-boxing), the weird upper/lower bounds
notation/concept... All these mean, as far as I can see, that programmers are
being distracted from the real work of producing working programs, and are
instead being forced to waste time thinking about how to keep the compiler
happy.

Added to that, I am getting the impression that generics are also distracting
people from sound OO -- tending to use generics /instead/ of objects with
clearly defined roles. I'm not really sure that the tendency is widespread,
but if it is, then that's a Bad Thing indeed.

Oh, yes. I also suspect that the implementation is buggy. At least, when I
tried some moderately complex generical programming, I was getting some Very
Strange error messages from the compiler. That suspicion does not in itself
prove that there's anything even slightly wrong with generics -- of course ! --
but what /is/ relevant here is that either the implementation is buggy,
implying that the concepts are over-complicated, or if the implementation is
(mostly) fine, then my understanding must be badly flawed. If the latter is
true, then there is a further choice: either I that am a lot less competent
than I think, or that the generics concepts are a lot more complicated than
is acceptable. Guess which option I'm currently plumping for ;-)

Oh, yeah, and one other teeny-tiny thing: If you make
a mistake, it gets diagnosed at compile time instead of at
run time. Which would you rather receive: a compiler error
that you alone see, or a ClassCastException with all the
honchos from The Big Customer watching? If you'd prefer
the former, learn to like generics.

This is, of course, contentious. There are many people who disagree
(violently! ;-). I happen to be among them. But my point here is not to ague
the point one way or another, but to correct the impression that you may be
giving to less experienced programmers (more my your tone than by the actual
content) that this is a cut-and-dried issue, that the jury has returned its
verdict, and that the book has been closed.

Early error trapping is obviously a Good Thing -- if it's free. The problem is
that it is not. The gains have to be compared with the costs (in brittleness
of design/implementation, in extra complexity, in extra verbosity). The
question of whether the gain pays for the costs of static type checking is far
from closed; there is simply no consensus on the issue. In particular we can
look at the /incremental/ gain in early error trapping provided by generics
(over and above what we already got from Java's pre-generics type-system), and
compare that with the incremental costs (in complexity, etc) of the new
generics. Regardless of whether Java's old type system really earned its keep,
we can consider whether generics are a nett benefit as an add-on. I do not
believe that they are.

-- chris
 
P

Phillip Lord

Eric> Is it possible to write good code without generics?
Eric> Well, it depends on what you mean by "good." What's your
Eric> opinion of all the Java code written in the first nine years
Eric> of the language's existence? Is it uniformly "bad?"

Good or bad code is clearly not determinable by the language features
used. Or, indeed, the language used.


Eric> The value proposition of generics, it seems to me, lies purely
Eric> in the fact that they make some kinds of mistakes diagnosable
Eric> by the compiler instead of by the JVM. Every study I've ever
Eric> heard of concludes that the cost of a bug increases the longer
Eric> it remains in the code, so a bug found by the compiler should
Eric> cost less than a bug found by testing (or *not* found by
Eric> testing ...).

The difficulty here is that there are also costs associated with
generics. In the case of Java generics, the system is relatively
dumb; you have to tell the compiler a lot in code to get it to give
you the guarantees that it can. Actually this is true for Java types
in general

Frame f = new Frame()

Why two "Frame"'s (I do know why! Please don't tell me!). It would be
nice if the type system could infer more from less information.

Of course, it's very hard to judge whether some feature is worth the
cost or not. In the end, it depends on how easy it is for a programmer
to use the system, which depends on how sensible it seems to them.

Personally, I was always a big fan of the idea of generics, and
watched from the early possible implementions (GJ, poors mans
generics, Pizza and all that jazz). Sadly, after all of these years of
waiting, I write very litte code, so haven't got around to trying
generics in anger. For me, therefore, the question of whether they are
good or not, will remain unanswered.

Cheers

Phil
 
B

Bent C Dalager

Good or bad code is clearly not determinable by the language features
used. Or, indeed, the language used.

If this is true in general, then it shouldn't be possible to construct
a programming language that forces you to write "bad" code. I'd like
to see you write anything beyond a trivial program in Intercal and be
able to call the result "good code." :)

In fact, even a trivial program would be impressive.

Intercal is a programming language deliberately designed to be
idiotic. While it is little more than a joke taken a bit too far, it
does demonstrate that it is possible to make a programming language
that gives you little to no chance of producing "good" code. As such,
it serves to lend credence a statement of the type "it is possible to
construct a programming language that forces programmers to write
worse code than what they would have done had they used programming
language X". X being your favourite language.

If this is the case, then it is reasonable to assume that there exists
some sort of scale, at (or near) the one extreme of which you can find
Intercal and at the other end there exists a hypothetical (perhaps
impossible) language that forces you to always write good code.

Somewhere in between these two, then, we will find the workhorse
languages that we all know and love. It would be remarkable if Java,
C, C++, C#, Pascal, Fortran, etc., all happened to be at exactly the
same spot on this scale. Rather, it is reasonable to assume that the
different languages lend themselves to varying degrees to writing
"good" code. (I certainly don't dismiss the idea that this goodness
scale may be a multi-dimensional beast - chances are that it is - but
that isn't terribly important for the current discussion.)

So I don't think it is clear at all that good or bad code is not
determinable by the language chosen (although I can only provide
compelling evidence for the case of a language determining that your
code should be bad). More importantly, though, I expect that different
languages have widely varying properties in this respect and that your
choice of language puts an upper limit on how good your code can be
(for your given domain). Moreover, I expect that choosing a "good"
language is likely to enable you to produce good code with
considerably less cost than you could with a "worse" language.

Cheers
Bent D
 
T

Thomas G. Marshall

Phillip Lord coughed up:
....[rip]...

Eric> Is it possible to write good code without generics?
Eric> Well, it depends on what you mean by "good." What's your
Eric> opinion of all the Java code written in the first nine years
Eric> of the language's existence? Is it uniformly "bad?"

Good or bad code is clearly not determinable by the language features
used. Or, indeed, the language used.

Right. Well, except in the case of Perl, where all such code is uniformly
bad. :)

Eric> The value proposition of generics, it seems to me, lies purely
Eric> in the fact that they make some kinds of mistakes diagnosable
Eric> by the compiler instead of by the JVM. Every study I've ever
Eric> heard of concludes that the cost of a bug increases the longer
Eric> it remains in the code, so a bug found by the compiler should
Eric> cost less than a bug found by testing (or *not* found by
Eric> testing ...).

The difficulty here is that there are also costs associated with
generics. In the case of Java generics, the system is relatively
dumb; you have to tell the compiler a lot in code to get it to give
you the guarantees that it can. Actually this is true for Java types
in general

Frame f = new Frame()

Why two "Frame"'s (I do know why! Please don't tell me!). It would be
nice if the type system could infer more from less information.

Interesting point. I suppose a valid default might have been:

Frame f = new(asdfasdfasdf)

Allowing of course for this as well:

Frame f = new SubFrame(asdfasdf);

for Poly-m. {shrug}


....[rip]...
 
P

Phillip Lord

Thomas> Phillip Lord coughed up:
Thomas> ...[rip]...

Eric> Is it possible to write good code without generics? Well, it
Eric> depends on what you mean by "good." What's your opinion of
Eric> all the Java code written in the first nine years of the
Eric> language's existence? Is it uniformly "bad?"
Thomas> Right. Well, except in the case of Perl, where all such
Thomas> code is uniformly bad. :)

I'm a bioinformatician, so I write a lot of perl. I have some distinct
sympathy with this position. Although, I suspect it comes from a
position of ignorance. Many people think that all perl is write
only. Believe me, it really is possible to make this harder than it
needs to be. The distressing thing with Perl is that there are too
many perl hackers who think that incomprehensible code is
"clever". It's not.


Eric> The value proposition of generics, it seems to me, lies purely
Eric> in the fact that they make some kinds of mistakes diagnosable
Eric> by the compiler instead of by the JVM. Every study I've ever
Eric> heard of concludes that the cost of a bug increases the longer
Eric> it remains in the code, so a bug found by the compiler should
Eric> cost less than a bug found by testing (or *not* found by
Eric> testing ...).
Thomas> Interesting point. I suppose a valid default might have
Thomas> been:

Thomas> Frame f = new(asdfasdfasdf)

Thomas> Allowing of course for this as well:

Thomas> Frame f = new SubFrame(asdfasdf);

Thomas> for Poly-m. {shrug}

Or just


f = new Frame.

We now know that f is at least Frame. If I choose to use it later with

f = new SubFrame()

this is okay. If I do

f = new ClassWhichIsNotFrameOrSubClass()

then it's not. Of course, it's not necessarily possible to just bolt
this sort of technology on to a language. SML gets it right in this
regard, but is highly unusuable in other ways. Whether the
unusuability in other ways is an (indirect and necessary) consequence
of the good type system, I'm not really qualified to say.

Phil
 
D

David Blickstein

Lasse Reichstein Nielsen said:
Avoiding the extra cast is a side effect of the more precise type
system. Nice, but the cast is not the real problem. It is a symptom
of not knowing the correct type at compile time, which allows some
errors to slip through to runtime.

How often does this bug happen? In my experience, it's never happened. Is
my experience unusual?

In reading the description of generics, it seems that we've introduced a
language feature that introduces a new common class of bugs to avoid
creating instances of an exceedingly uncommon class of bugs.

Does anyone actually disagree with this?
 
M

Mike Schilling

Chris Uppal said:
Funny thing, I know you intended this as sarcasm, but I agree with it as
written. Well. not quite literally -- I don't suppose there's any
conspiracy -- but I do think that generics have been introduced out of
ill-considered, or unconsidered, C++-envy.

Why C++, in particular? The next version of C# has generics, and the
current one has auto-boxing, variable-length argument lists, for-loops over
collections, etc. Given that Java competes for mindshare with .NET, I think
competition with C# is a more likely motive for the 1.5 changes.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Generics ? 14
can this be done with generics? 32
More Generics warnings. 5
stupid generics 38
Generic generics help 7
Java generics limitations? 9
Generics and for each 12
Help on java generics 18

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top