Why Generics?

[David Blickstein]

It was the C++ weenies, definitely.You're entirely

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.

Would be the least bit surprised if C++ weenies infected the C# design as
well.

Or it could be that it's not so much as competing for C# mindshare as
competing to get the C++ mindshare. All those people who bought into C++
because it was hyped as the early 90's "it" language and too late realized
what an amazing piece of ATROCIOUS language design it is, and how much
money it is costing them.

Y'know... if I may..this all reminds me of what I see here in my home state
of NH.

In the 80s NH had the 2nd lowest per-capita taxes in the nation and modest
services. In sharp contrast our southern neighbors in Massachussetts had
very nearly the HIGHEST per-capita taxes (source: US Statistical Abstract).

So in the late 80s and 90s, there was a wave of Mass refugees moving to NH
attracted by the lower taxes. And the first things they started to do was
ask for new government services to be added - the sort of things that caused
their MA tax rates to be so high.

It's like they couldn't make the connection between services and taxes.

I think we might see something similar here with Java.

My understanding is that C++ is dying (I wish *I* could be the one to pull
out the feeding tube). Everyone is hearing about the advantages of the
modern languages like C# and Java.

So they're all moving to these other languages and trying to drag their
familiar C++ methods with them not recognizing that it's their ABSENCE that
made Java and C# so attractive.

 

[Thomas G. Marshall]

Phillip Lord coughed up:

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

(?) Why does one imply the other?

I have some distinct
sympathy with this position. Although, I suspect it comes from a
position of ignorance.

Which: Is it my position or your sympathy that comes from ignorance?

I assure you that I've done Quite A Lot (tm) in perl. But I have been
around the block enough times to know that when a language lends itself to
terseness and obfuscation that there will be many an engineer that will
attempt the most terse and most obfuscated production code.

Everyone knows that a language is better when it has things like $| and $<
in it with such obvious meanings.

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.

....[rip]...


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.

No, because now you're in dynamically typed language territory, and that
would (without doubt) ignite a flame war . What we were discussing were
mere shortcuts, or so I thought. Unless of course that the f = new Frame is
short cut for Frame f = new Frame, and not something else like Object f =
new Frame.


....[rip]...

 

[Thomas G. Marshall]

David Blickstein coughed up:

Would be the least bit surprised if C++ weenies infected the C#
design as well.

Or it could be that it's not so much as competing for C# mindshare as
competing to get the C++ mindshare. All those people who bought
into C++ because it was hyped as the early 90's "it" language and too
late realized what an amazing piece of ATROCIOUS language design it
is, and how much money it is costing them.

Y'know... if I may..this all reminds me of what I see here in my home
state of NH.

In the 80s NH had the 2nd lowest per-capita taxes in the nation and
modest services. In sharp contrast our southern neighbors in
Massachussetts had very nearly the HIGHEST per-capita taxes (source:
US Statistical Abstract).

So in the late 80s and 90s, there was a wave of Mass refugees moving
to NH attracted by the lower taxes. And the first things they
started to do was ask for new government services to be added - the
sort of things that caused their MA tax rates to be so high.

Right about your observation, and right metaphor as well. I grew up in NH
and later moved to MA. I know precisely the phenomenon you are talking
about (from observation). As an aside, the thing that confuses the MA
people as they move to NH is that nearly everything in NH is powered from
the property tax---NH has no income /nor/ sales taxes. The MA folks freak
out over this often by assuming that this unfairly clobbers land owners.
They forget that even /rent/ is affected by property tax: someone somewhere
owns the property and pays---this payment of tax sooner or later results in
higher rent. It's all part of the same economic puzzle as in all states.
The only difference is that NH chooses to have only a few targeted avenues
of taxation, whereas MA prefers them to be multiple and varied.

 

[Adam P. Jenkins]

Phillip Lord coughed up:


No, because now you're in dynamically typed language territory, and that
would (without doubt) ignite a flame war .

Not at all. Check out SML (http://www.smlnj.org), OCaml
(http://caml.inria.fr/ocaml/), Haskell (http://www.haskell.org/), Clean
(http://www.cs.ru.nl/~clean/), or google for "type inferencing". All of
these languages have stricter static typing than Java IMO yet they all
allow things like the above. The compilers use type inference to allow
type declarations to be omitted in most cases. It's still possible in
these languages to explicitly declare the types of variables or
functions to resolve ambiguity in certain cases, or just for
documentation purposes.

For example in OCaml if I write
let pi = 3.14
The compiler knows that pi is a float. If I write
let square x = x * x
The compiler infers that 'square' is a function of type
int -> int
(In this case it knows because the * operator is only for ints in OCaml.)

 

[Chris Uppal]

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.

I don't think that generics have introduced a new class of /bugs/ have they ?

They make the language more difficult to use, and I suppose they introduce the
possibility that someone will write an unnecessarily restricting generic
declaration (thus making it harder to use, modify, or extend, that code), but I
don't see how they introduce a new way for a program to malfunction at
runtime ?

-- chris

 

[Chris Uppal]

[me:]

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?

My reason is simply that people have been discussing adding "templates" to Java
since well before C# was invented (or at least publicly admitted to). Same
goes for enums.

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.

I agree that C# provides competition and a source of ideas (both good and
bad). I don't doubt for a minute that Java's auto-boxing etc, have been added
more in imitation of C# than convergently with it.

BTW, do you know of a description (readable, rather than a formal spec) of the
semantics/implementation of C#''s generics ? I gather that it's being done at
the VM level rather than by compiler kludgery. If so then it may be that C#''s
generics are less problematic than Java's.

-- chris

 

[Phillip Lord]

Thomas> Right. Well, except in the case of Perl, where all such
Thomas> code is uniformly bad.
Thomas> (?) Why does one imply the other?


Perl is, still, largely the language of choice in bioinformatics. For
a variety of reasons, we tend to use fairly old fashioned technology,
including many different flat files. So we write lots of parsers and
extracters, at which perl excels. Also a lot of analyses are
experimental and the code base is used once or twice and thrown
away. Again, perl is very good at this. When I come back to Java, I
often forget to compile the code, and then get really annoyed that I
have to. Of course the compilation has advantages.

One day, bioinformaticians will not use perl. But it won't be for a
long time.




Thomas> Which: Is it my position or your sympathy that comes from
Thomas> ignorance?

Thomas> I assure you that I've done Quite A Lot (tm) in perl. But I
Thomas> have been around the block enough times to know that when a
Thomas> language lends itself to terseness and obfuscation that
Thomas> there will be many an engineer that will attempt the most
Thomas> terse and most obfuscated production code.

Thomas> Everyone knows that a language is better when it has things
Thomas> like $| and $< in it with such obvious meanings.


My experience has been that many people who knock perl haven't
actually used it that much. The syntax is obtuse, but not so bad once
you are used to it.

I didn't know whether this is true in your case, which is why I said
"suspect". Now I know better.

You are definitely correct


Thomas> No, because now you're in dynamically typed language
Thomas> territory


No, this isn't true. What I want is for Java to figure out more. I
still want f to be strongly typed.

Thomas> , and that would (without doubt) ignite a flame war .

Heaven forbid.

Thomas> What we were discussing were mere shortcuts, or so I
Thomas> thought. Unless of course that the f = new Frame is short
Thomas> cut for Frame f = new Frame, and not something else like
Thomas> Object f = new Frame.

I wasn't suggesting a syntactic shortcut per se. More the hope that
more can be done with less requirement for the programmer to annotate
the code base with types everywhere. In short, a cleverer type
system. Whether this is possible, I don't know. It's an aspiration.

Cheers

Phil

 

[hiwa]

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

I'd like to hear what were the major faults in C++ generics.
For a solace for Java generics learners.

 

[Andrew McDonagh]

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

Thomas> (?) Why does one imply the other?


Perl is, still, largely the language of choice in bioinformatics. For
a variety of reasons, we tend to use fairly old fashioned technology,
including many different flat files. So we write lots of parsers and
extracters, at which perl excels. Also a lot of analyses are
experimental and the code base is used once or twice and thrown
away. Again, perl is very good at this. When I come back to Java, I
often forget to compile the code, and then get really annoyed that I
have to. Of course the compilation has advantages.

One day, bioinformaticians will not use perl. But it won't be for a
long time.





Thomas> Which: Is it my position or your sympathy that comes from
Thomas> ignorance?

Thomas> I assure you that I've done Quite A Lot (tm) in perl. But I
Thomas> have been around the block enough times to know that when a
Thomas> language lends itself to terseness and obfuscation that
Thomas> there will be many an engineer that will attempt the most
Thomas> terse and most obfuscated production code.

Thomas> Everyone knows that a language is better when it has things
Thomas> like $| and $< in it with such obvious meanings.


My experience has been that many people who knock perl haven't
actually used it that much. The syntax is obtuse, but not so bad once
you are used to it.

I didn't know whether this is true in your case, which is why I said
"suspect". Now I know better.

You are definitely correct



Thomas> No, because now you're in dynamically typed language
Thomas> territory


No, this isn't true. What I want is for Java to figure out more. I
still want f to be strongly typed.

Thomas> , and that would (without doubt) ignite a flame war .

Heaven forbid.

Thomas> What we were discussing were mere shortcuts, or so I
Thomas> thought. Unless of course that the f = new Frame is short
Thomas> cut for Frame f = new Frame, and not something else like
Thomas> Object f = new Frame.

I wasn't suggesting a syntactic shortcut per se. More the hope that
more can be done with less requirement for the programmer to annotate
the code base with types everywhere. In short, a cleverer type
system. Whether this is possible, I don't know. It's an aspiration.

Cheers

Phil

lots of bioinformatics use a variety of languages (Perl, C, C++, Java,
PLSQL, etc), Lion Bio-science have a system that is predominately J2EE
based.

 

[Tor Iver Wilhelmsen]

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

They fix a bug in the language.

Basically, Java is strongly typed (or strictly typed? I get those
confused sometimes), which means you cannot assign a Foobie to a
Griffon type variable, unless Foobie is descendant from Griffon.

All of that is thrown out of the window once you start passing Objects
around and playing with instanceof and casting and crossing your
fingers hoping nothing breaks at runtime.

Generics makes (especially) Collections and other "open" objects into
well-behaved strongly typed objects again. Yes, there is casting going
on under the hood, but at least the compiler can treat Java as it
should be.

 

[Chris Uppal]

Basically, Java is strongly typed (or strictly typed? I get those
confused sometimes), which means you cannot assign a Foobie to a
Griffon type variable, unless Foobie is descendant from Griffon.

Leaving aside the fact that the "cannot assign unless .. is descendant from.."
bit is only an approximation (a reasonably approximation, but not entirely
true). The correct term for the property you are describing is, I think,
"statically typed" (or if you want to be pedantic "strongly statically typed"
or "strictly statically typed" -- ASFAIK there is no generally accepted
difference). The point is that the strong (or strict) type rigour is enforced
statically (at compile time) rather than dynamically (at runtime).

Compare a language such as C, which has weak, but still static, typing. Or
languages such as Smalltalk, LISP, Ruby, and Python, that have strong dynamic
typing.

-- chris

 

[Mike Schilling]

BTW, do you know of a description (readable, rather than a formal spec) of
the
semantics/implementation of C#''s generics ?

No, unfortunately. My biggest complaint about .NET (as opposed to Java) is
the lack of good conceptual documentation. You can find specs and
step-by-step instructions (e.g. click this button, choose the third tab,
fill in the box, check the third box, and choose "OK") but not much in
between.

I gather that it's being done at
the VM level rather than by compiler kludgery. If so then it may be that
C#''s
generics are less problematic than Java's.

That's my understanding too, that generics result in the creation of new
first-class type objects at runtime.

 

[David Blickstein]

My reason is simply that people have been discussing adding "templates" to
Java

since well before C# was invented (or at least publicly admitted to). Same
goes for enums.

Enums were truly needed. They eliminated a class of (what I consider to be)
type-related errors that in my experience was very common: using the wrong
constant in the wrong context. Like substituting LAYOUT.LEFT_JUSTIFIED
for LAYOUT.WEST in a layout manager.

There's a C# feature that I also think is desperately needed in Java.

C# allows you to use the SAME syntax for fields and nyladic (zero arguments)
methods. This allows you to abstract the implementation of the field so
that fields can be re-implemented as methods without breaking existing code.

This is a very common occurrence. SOmething starts out with a static value
and ends up being a dynamic value.

I'm getting someone on the Java committee to propose this.

 

[David Blickstein]

I'd like to hear what were the major faults in C++ generics.

A great source of information for "major faults in C++" is Scott Meyers book
"Effective C++" - which around here we refer to as "Defective C++" because
that really is a more appropriate title for the content.

One problem with C++ templates (C++ doesn't have "generics" per se), is
"code bloat".

From Meyers:

"once you start using them regularly, you'll discver that if you
instantiate a
template a dozen times, you are likely to instantiate the code for the
template a dozen times. "

"There is a name for the resultant increase in object code size:
template-
induced code bloat. It is not a good thing."

Actually another good source of "Defective C++" is the book known as "the
Bjarne Stone" which is Bjarne Stroustrup's book on C++. (Bjarne Stroustrup
is the perpetrator of C++. I refuse to say "designer of C++" because C++
never struck me as having ever been "designed" in any respectful sense of
the word.)

Read the first 200 or so pages. It's outright depressing. An amazing
number of sections include a description of a feature, followed by a
description of all the ways you can hang yourself by using it.

 

[Mike Schilling]

Enums were truly needed. They eliminated a class of (what I consider to
be)
type-related errors that in my experience was very common: using the wrong
constant in the wrong context. Like substituting LAYOUT.LEFT_JUSTIFIED
for LAYOUT.WEST in a layout manager.

There's a C# feature that I also think is desperately needed in Java.

C# allows you to use the SAME syntax for fields and nyladic (zero
arguments)
methods. This allows you to abstract the implementation of the field so
that fields can be re-implemented as methods without breaking existing
code.

A syntax change doesn't help much here. Unless the bytecode is also changed
to make field references and zero-argument method calls identical, a change
will cause incompatibility with existing binaries.

 

[Tor Iver Wilhelmsen]

A great source of information for "major faults in C++" is Scott Meyers book
"Effective C++" - which around here we refer to as "Defective C++" because
that really is a more appropriate title for the content.

Allow me to add another recommendation of that book: Bruce Eckel's
"Thinking in C++" taught me the language, "Effective C++" taught me
never to touch it.

 

[Thomas G. Marshall]

Adam P. Jenkins coughed up:

....[rip]...

[...] or google for "type
inferencing". All of these languages have stricter static typing
than Java IMO yet they all allow things like the above. The
compilers use type inference to allow type declarations to be omitted
in most cases.

Oh I know this, I was being glib really, sorry for the confusion. I put in
a smiley mostly because things of this form:

<no type> <variable name> = new <class/type name>

Are enough to smell like DTL and is shaking a bottle of nitro in these
parts. Again, another smiley:

My replies now are a little scattered, but the jist is that what you are
talking about is a short-cut. And you don't speak to this point, but using
the shortcut means that you are not declaring the variable as a superclass
of the actual instantiating class (for polym). In that case you would need
to forego the shortcut and specify the typed construct. Whatever....

....[rip]...

 

[Thomas G. Marshall]

David Blickstein coughed up:

Enums were truly needed. They eliminated a class of (what I consider
to be) type-related errors that in my experience was very common:
using the wrong constant in the wrong context. Like substituting
LAYOUT.LEFT_JUSTIFIED for LAYOUT.WEST in a layout manager.

If that's what you were worried about then enums were not "truly needed" at
all. The examples you gave are examples of poorly designed type-UN-safe
enums.

Consider this type-SAFE pseudo-enum instead:

public class TrafficColorEnum
{
public static final RED = new TrafficColorEnum();
public static final GREEN = new TrafficColorEnum();
public static final YELLOW = new TrafficColorEnum();
}

public void setColor(TrafficColorEnum color)
{
if (color == TrafficColorEnum.RED)
// do something red specific...
}

There are (of course) much more complicated versions of this, including very
detailed AbstractEnum superclasses that allow values to be tagged to the
enums, but you get the idea. Each constant is an enum element, each of type
TrafficColorEnum.

 

[Thomas G. Marshall]

Chris Uppal coughed up:

I don't think that generics have introduced a new class of /bugs/
have they ?

They make the language more difficult to use, and I suppose they
introduce the possibility that someone will write an unnecessarily
restricting generic declaration (thus making it harder to use,
modify, or extend, that code), but I don't see how they introduce a
new way for a program to malfunction at
runtime ?

Robert C. Martin, mostly a denizen of comp.object, has pointed out several
times that there are some things that are /over/ engineered. I don't know
his position on generics, but the example that he has lately discussed is
that a "Just Create One" is superior to a true singleton. I am seeing
shades of this line of thinking (right or wrong) in this thread.

 

[Thomas G. Marshall]

Chris Uppal coughed up:

Leaving aside the fact that the "cannot assign unless .. is
descendant from.." bit is only an approximation (a reasonably
approximation, but not entirely true). The correct term for the
property you are describing is, I think, "statically typed" (or if
you want to be pedantic "strongly statically typed" or "strictly
statically typed" -- ASFAIK there is no generally accepted
difference). The point is that the strong (or strict) type rigour is
enforced statically (at compile time) rather than dynamically (at
runtime).

Compare a language such as C, which has weak, but still static,
typing. Or languages such as Smalltalk, LISP, Ruby, and Python, that
have strong dynamic typing.

I'm not convinced that the word "strong" belongs with the words "dynamic
typing".