From: Lew on
Arne Vajhøj wrote:
> Lew wrote:
>> Arne Vajhøj wrote:
>>> Lew wrote:
>>>> Arne Vajhøj wrote:
>>>>> <T> is new syntax. Just not new keywords. And it definitely added
>>>>> complexity - just consider how many questions are asked about it here.
>>>>
>>>> It is most assuredly not new syntax. The Java version that
>>>> introduced it hits end-of-service-life in less than four weeks. It
>>>> was introduced over five years ago. In what IT context is five
>>>> years considered "new"?
>>>
>>> It was new syntax when it was added.
>>
>> So was the "assert" keyword. So were anonymous classes. Heck, the
>> Java language itself was new when it first came out. Come on.
>
> Most new features add complexity.
>
> That was the point in what I was trying to explain.
>
> New features adds complexity whether they add new keywords or
> not. So "<T>" or "of T" does not make a big difference in
> the complexity added.

That is true. But economics teaches us that expenditures already made are
"sunk costs" and no longer part of the cost-benefit analysis.

My point was that we've already added '<T>' so there's no point in worrying
about "of T".

--
Lew
From: Roedy Green on
On Sat, 03 Oct 2009 22:02:09 -0400, Lew <noone(a)lewscanon.com> wrote,
quoted or indirectly quoted someone who said :

>I had that "ah-hah" moment. I'm sorry that you haven't, yet.

I go through these descriptions. For the most part I think I
understand all the little pieces, but it just does not hang together.
To use it, I end up using some pat little recipes, or trying to find a
class similar to what I am trying to do. I can't just write the stuff
off the top of my head the way I can all the rest of Java.

Some of the things Joshua Cramer said about the PURPOSE of the various
bits of syntax is helping to create frame to hang the individual bits
of lore on.

Perhaps another few rounds through the essays will make more sense now
I have some practical experience under my belt.

It just bugs me that specifying the contents of a container should be
any more complicated that specifying the contents of an array. There
must be some mistake. Perhaps what is needed in building to concept
of container into the language as deeply as arrays are. You are
resigned that this is a fundamental complexity of the universe, not
the result of political expedience, incompetence or laziness on the
part of the generics implementation designers. I am not yet convinced.
I don't understand it and why it was designed that way well enough.

There does not seem to be sufficient benefit to justify all the fuss.

Another way of putting it, generics are so hairy, they are almost more
likely to introduce more bugs than they prevent, at least temporarily.

--
Roedy Green Canadian Mind Products
http://mindprod.com

I advocate that super programmers who can juggle vastly more complex balls than average guys can, should be banned, by management, from dragging the average crowd into system complexity zones where the whole team will start to drown.
~ Jan V.
From: Roedy Green on
On Sun, 04 Oct 2009 13:19:36 -0400, Joshua Cranmer
<Pidgeot18(a)verizon.invalid> wrote, quoted or indirectly quoted someone
who said :

>What List[Integer] has going for it is that the array syntax fits closer
>into a notation of what a generics type generally does: it's a container
>of some object. On the other hand, it looks like an array access, which
>means that the parser would look rather interesting.

Other languages use array syntax for indexing Maps by string for
lookup. But that still does not describe the type of the elements in
the collection.
--
Roedy Green Canadian Mind Products
http://mindprod.com

I advocate that super programmers who can juggle vastly more complex balls than average guys can, should be banned, by management, from dragging the average crowd into system complexity zones where the whole team will start to drown.
~ Jan V.
From: Roedy Green on
On Sun, 04 Oct 2009 13:19:36 -0400, Joshua Cranmer
<Pidgeot18(a)verizon.invalid> wrote, quoted or indirectly quoted someone
who said :

>What List[Integer] has going for it is that the array syntax fits closer
>into a notation of what a generics type generally does: it's a container
>of some object. On the other hand, it looks like an array access, which
>means that the parser would look rather interesting.

& is used where you would expect to use comma. extends is used where
you would expect to use implements. super does not mean super.

I suspect the syntax would work just as well with () as <>, perhaps
with minor tweaking such as a "contains" keyword. < and > are already
taken. This is like C++ recycling >> for i/o.

The incompatibility of generics and arrays, and the inability to even
write the simplest Collection without a warning is just not good
enough. There is something fundamentally wrong with the design if such
uglinesses appear unavoidable.

In writing my own code, when something like this happens, it means I
got off on the wrong foot in my mental model quite early on. I have
to backtrack and completely rethink the problem. Then usually I will
be rewarded with something so simple I later wonder why I did not
think of it right of the bat.

The difference is I can presume some quite bright people like Bill Joy
chewed on this, and felt my same distress, but could not come up with
a simpler formulation.
--
Roedy Green Canadian Mind Products
http://mindprod.com

I advocate that super programmers who can juggle vastly more complex balls than average guys can, should be banned, by management, from dragging the average crowd into system complexity zones where the whole team will start to drown.
~ Jan V.
From: Roedy Green on
On Sun, 04 Oct 2009 15:44:44 -0400, Joshua Cranmer
<Pidgeot18(a)verizon.invalid> wrote, quoted or indirectly quoted someone
who said :

>Introducing new keywords is an issue I didn't discuss, but suffice to
>say that it's something that many of the people with a say in the future
>of Java want to avoid.

As a practical problem I think new keywords/reserved words are
overrated.

Old compiled code containing variables named after keywords causes no
problem. A global search-replace, which I do dozen times a day in my
IntelliJ IDE, would handle any code needing recompilation.

It would be highly improbable an existing program would suddenly have
new meaning because of a new keyword. It would nearly always just stop
compiling. It would continue to compile with a -source 1.6 option.

--
Roedy Green Canadian Mind Products
http://mindprod.com

I advocate that super programmers who can juggle vastly more complex balls than average guys can, should be banned, by management, from dragging the average crowd into system complexity zones where the whole team will start to drown.
~ Jan V.