Skip to main content

what have they done with Java?

57 replies [Last post]
saintjohn
Offline
Joined: 2004-10-25

Sun forgot one of the main java principles - simplicity.
As time goes on java becomes the same shit as C++.

- "assert" is not better than catching runtime exceptions & system.err.println in bug fixing before product release.

- introduction of generics is caused by some far-fetched reasons. They absolutely don't outweight one major drawback - java code becomes hard-to-read.

- but the worst thing one can imagine - metadata in j2se1.5:

@Retention(java.lang.annotation.RetentionPolicy.RUNTIME) @interface debug {
boolean devbuild() default false;
int counter();
}

This is the return of C++ "#indef,#define" - nightmare

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
patrikbeno
Offline
Joined: 2004-10-11

I am wondering why I still argue with you.
We have to admit our discussion does not lead us anywhere near conclusion. We both stand on our points.

I think I'd rather create and post some solid RFE.

Take care, buddy.
Over.

vhi
Offline
Joined: 2004-10-11

Actually, I guess the beauty of generics reveals itself when you have used it sufficient amount of time. Compare the same with OO. Many shunned away from OO because it was complex and argued that they lost sense of direction (read procedural mode) when using OO. But, with sufficient experience, OO seemed only natural for many of those whose where against it at first. Similarly IMO, we need some more experience using Java 1.5 and generics before proceeding with the discussion whether it has really improved our life. BTW, I used templates in C++, and simply loved it, after the usual initial aversion.

kcpeppe
Offline
Joined: 2003-06-15

> Actually, I guess the beauty of generics reveals
> itself when you have used it sufficient amount of
> time.

Even pigs looks pretty if you hang out with them enough ;)

This is a good point. The only problem I have (and as I've said before) is that they've been introduced directly into a production ready version of the language. What happens if we all decide tomorrow that generics have lost their coolness and now we want rid of them. Lets get familiar with them somewhere where we can end the experiement gracefully. Oooops.. too late. ;)

dgreenbean
Offline
Joined: 2003-12-08

I was playing around with a pre-release of generics back in the summer of 2003. >1 year is plenty of time for me.

-David

patrikbeno
Offline
Joined: 2004-10-11

I love generics, as you might have noticed.

That said, one year is good enough if things go right.
But one year is not enough if you have chosen the wrong direction and you have to admit it before you go on, or even throw away what you've done and redesign and rewrite it.
Sun did not reach the state of being able to admit they've made a mistake (at least at the time of final release).

Did you know they have dropped a feature just before final release only because they could not find how to fix the bug (or design issue)?
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4948569

kcpeppe
Offline
Joined: 2003-06-15

> But one year is not enough if you have chosen the
> wrong direction and you have to admit it before you
> go on, or even throw away what you've done and
> redesign and rewrite it.
Now that it's been released.. there is no going back.. and to be continously tweaking it is dangerous for backwards compatability. You cannot take the step of changing a language lightly! Just look at all the deprecated methods... they can't be removed for if they are.. they will break someone's code. More dangerous yet is to change the behavior. The compile will work yet the code will act differently.

Case in point, the Cray Supercomputer CPU did not use IEEE floating point and was subject to overflow errors. The users were asked if they would like to move to the IEEE floating point standard. The answer was a resounding no. The people using the machine choose to live with the bug in the processor rather than change the behavior of this core feature because they came to rely on the CPU behaving that way. To change the behavor was to invalidate years of work.

This is why the experiment should not have been done in a production version of the language.

> Sun did not reach the state of being able to admit
> they've made a mistake (at least at the time of final
> release).

First, it was the JCP, not Sun that mandated the changes. Secondly, there was never a critical review AFAICT, it was more a push to sell this "really cool language feature".
>
> Did you know they have dropped a feature just before
> final release only because they could not find how to
> fix the bug (or design issue)?
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=494
> 8569

Yet another sign that they should of held back on the entire implementation.

We need people who are thinking critically about these types of fundimential changes, not a bunch of cowboys just looking for the cool du jour!

patrikbeno
Offline
Joined: 2004-10-11

Am I not thinking critically enough?

Yet, i still think that if we will scream aloud what generics should be and what they will be like, we'll be able to change the language before everybody gets used to the bad design.

As a stated several times,
1) compiler is far too restrictive about generics than it should be just because it tries to enforce something that it cannot enforce, anyway. New better generics will not therefore break anything because it is not allowed now, anyway.
2) Any other incompatibility risks possibly introduced by changing generics design can be mitigated by sound and aloud public statement about what generics will look like in Mustang. Certain features (or misfeatures) will be declared obsolete and deprecated. Right now or in several months.

kcpeppe
Offline
Joined: 2003-06-15

> 2) Any other incompatibility risks possibly
> introduced by changing generics design can be
> mitigated by sound and aloud public statement about
> what generics will look like in Mustang. Certain
> features (or misfeatures) will be declared obsolete
> and deprecated. Right now or in several months.

If only it worked this way.

patrikbeno
Offline
Joined: 2004-10-11

We do not have another choice.
We have to try it. It will not be worse than it is, anyway (if done properly).

Either fight trying to save your ass or be fatalist and reconcile.

Have a better idea? Oh yeah, I remember, drop the whole thing. Well that's not an option, you know that.
Time for you to take pragmatic and constructive approach after all. Improve what you can as much as you can, or give up and go back to Smalltalk.

kcpeppe
Offline
Joined: 2003-06-15

> Time for you to take pragmatic and constructive
> approach after all. Improve what you can as much as
> you can, or give up and go back to Smalltalk.

Or better yet, let a bunch of cowboys run the language into the ground so that companies that come to rely on it, no longer can. Yeah, lets just ditch millions of $$$ of development on a whim so that you can go back to C++ yeeehhhhaaaa

patrikbeno
Offline
Joined: 2004-10-11

You think me one of those cowboys? I am just trying to sanitize generics, don't you see it? To mitigate the risks I see before we all get used to and before we start rely on the current bad design. Or you think my proposals make it even worse? You are not giving it a chance at all.

I am able to understand you are not very fond of generics. Different faces, different tastes. Why not.

But the argument we both have for some time here is not about my proposal at all, have you ever noticed that?
We argue about generics as an idea, concept. You argue it is a bad idea since the very begining, and therefore we did not even get to discuss the impact of my proposal.

It's the same with my 'object-switch' proposal. You oppose not because proposal is bad. You oppose because switch is not enough OOP for you.

Be honest. It's not about the quality of proposals. You fight the idea one level bellow. There's nothing wrong about it while we're all aware of this.

Are you?

patrikbeno
Offline
Joined: 2004-10-11

Just one note:
Once you start creating universal complex objects (such as collections but not only them), you find out that they are supposed to do the same thing but you need them to do it with different data types.
You begin to realize that you need to parameterize such complex types.
That's where generics come in. That's where they fit.
And there are things like complex types. You cannot narrow everything down to true/false

kcpeppe
Offline
Joined: 2003-06-15

> Benefit was explained. There were three or four
> classes without implementations just to show the
> concept. is this too complex for you? oh, I forget,
> it was so complex you did not manage to notice
> collections were never used in there :-(
>

What I did forget to mention but did notice is that the explination for what you were doing with generics took quite a bit of space. Strangely enough, composition was quite clear without the explination... hmmmm....

patrikbeno
Offline
Joined: 2004-10-11

Sadly, you refuse to to see the point. You asked for example of what YOU CANNOT DO WITHOUT GENERICS. The example is just about it.

This means that you CANNOT do the same thing with your composition. Your funny space consumption comparison is therefore unfair.

Further, explanation took quite a bit of space because you DO NOT UNDERSTAND. If you were capable to understand, I could just tell [i]"generics allows me to create and use type-safe parameterized code which leads to better readability and reusability"[/i]

Now, do THIS with your composition in less space

kcpeppe
Offline
Joined: 2003-06-15

> Sadly, you refuse to to see the point. You asked for
> example of what YOU CANNOT DO WITHOUT GENERICS. The
> example is just about it.

The sample is a 3 or 4 line code fragment that does nothing.. show me code!

> leads to better readability and reusability"[/i]
Your opinion, not mine!

>
> Now, do THIS with your composition in less space
Do what? again.. show me some real code!

This is not a matter of understanding.. This is a matter of narrowing the scope to something real. Look you made the claim that generics are great. Then in the same breath, you claim that they are broken! I'm pretty much done here unless your interested in showing something beyond a 3 to 4 line code fragment with some handwaving.

patrikbeno
Offline
Joined: 2004-10-11

> you made the claim that generics are great. Then in
> the same breath, you claim that they are broken! I'm
> pretty much done here unless

Generics are great for the reasons that has nothing to do with the way they are broken.
And you know better that I do that you don't like them not because they are broken but for completely different reasons.

> your interested in
> showing something beyond a 3 to 4 line code fragment

Uff, I've tried, man. Even now. And I deleted about 50+ lines because I felt tired of repeating myself.

Just last example from my recent 1.4-based project (not shorter but at least I will not repeat myself), where I designed and implemented universal component that covered some flaws in a framework we were forced to use.

Framework used hashtable of Strings called 'Datapacket' as a transport protocol between client and server and used single dispatch method for everything:

processDataPacket(DataPacket);

In this silly method, they usually did manual if/else nonsense based on datapacket's name just to call appropriate method. Parameters were passed to the called method by manual extraction from the datapacket. Note that these parameters were still just Strings.

To make this shorter: My solution was able to
- pick the required method automatically,
- extract method parameter type directly from the signature and instantiate it
- iterate its bean properties, and populate them with data from datapacket, converted from String to the appropriate type as expected by bean property.
- and of course, call the method and do the reverse process with its result.
- all this without any additional configuration, just by looking into the classes

sorry for long intro, but NOW I am finally getting to the point:

Some of the properties were collections and as you may guess, I needed to know the type manipulated by this collection to be able to populate collection with the expected instances.

Requirement:
- keep this information together with the code that relates to it.
Options:
- only xdoclet
Drawbacks:
- extra tool
- extra descriptor file
- additional process for already complex build process
- complicated refactoring
- extra implementation code needed to process generated descriptor
- extra documentation requirements

Finally, I hacked it. Not something I am proud of, but it worked. Just for the record:

List accounts; { defineSubType("accounts", Account.class); }

This QDH solution registered the class in a map used by the code, no need to generate, load and parse XML.
It's ugly, don't try it at home.

[b]But the point is, I would not need anything of this crap if I could just say [i]List[/i][/b]

dgreenbean
Offline
Joined: 2003-12-08

Your point about using the right tools is very pertinent to this discussion; however, you missed the purpose of adding generics to Java.

I program primarily in Java and Perl. I use Perl for the quick programs that I may want to keep around, but not necessarily integrate into a large-scale program. The reason is that I cannot enforce a number of safety requirements on my methods and data in Perl. The language simply does not provide for it (without having to use a hack). The primary safety restriction that I worry about is type-safety.

I use Java because of its ability to statically type my objects at compile-time. This is because I don't always know what my programs will be used for in the future. Sometimes I'm developing a data type that has no inherent use, but may be useful to have around in the future. In order to ensure its correctness, I rely heavily on the compiler.

Once I wrote a program in Java 1.4, and I had over 500 classes extending collections just to keep everything type-safe. Java 1.5 allowed me to reduce my entire program to about 15 classes. The complexity was dramatically reduced with absolutely no change in functionality thanks to generics alone.

If you are looking for a powerful language that does not provide a verbose type checking mechanism, I would recommend Scheme. Haskell is also a great language, as it can both statically type data, but will try to infer types whenever possible.

I use Java for many reasons. It is an industry standard, type-safe, and object-oriented. Other people like other languages for various reasons. If you don't like how Java is structured, don't use it. Java is, and always has been, a verbose language. I find this reduces complexity, but you may find otherwise. That's ok. It just limits you to using other languages. For a while, Sourceforge had a project called Nice, which did quite a bit to reduce Java's verboseness. I don't know if it's still around, but you may want to look at it if you want to steer Java towards a more consise syntax.

-David

kcpeppe
Offline
Joined: 2003-06-15

The primary safety
> restriction that I worry about is type-safety.

I guess this is where we differ, my primary concern is on symantic correctness and that cannot be enforced with a compiler.

>
> I use Java because of its ability to statically type
> my objects at compile-time. This is because I don't
> always know what my programs will be used for in the
> future.

Right, if you are building frameworks.. this can be an issue... but this is all the more reason to use composition as collections have collection type behavior where as domain objects have domain type behavior and it is those symantics that are important. Exposing a collection in an API is just exposing yourself for down stream problems. Not encapsulating collections in a class that provides symantics that is consistant with the domain is also exposing yourself for potential problems later on.

>
> Once I wrote a program in Java 1.4, and I had over
> 500 classes extending collections just to keep
> everything type-safe.

Humm, well I can't really comment on your requirements but I would say that in the dozens of projects that I've had some involvement in.. I've never seen a requirement that would justify the creation of these many collections. Tell me, how did you overcome the downcasting problem?

Just doing the maths.. that is 500+ type safe collection classes. If you were to use say, HashMap, ArrayList as the most popular collections that means your application would of had something like say.. 200+ classes that were to be contained in collections?

> If you are looking for a powerful language that does
> not provide a verbose type checking mechanism, I
> would recommend Scheme.

As interesting as Scheme is.. I think Smalltalk is a much better solution for production systems.

> Haskell is also a great

*nods* but again, Smalltalk would seem to be a better choice.

> If
> you don't like how Java is structured, don't use it.
> Java is, and always has been, a verbose language.

I don't mind how Java has been strutured... I just don't like the way it's been restructured. I agree that there were problems to solve.. the question is.. has the solutions proposed been vetted enough that we should be needing to change the most fundimential contract that we have in the Java Platform, the language. The proceedings of the JCP JSR managing this process were totally hidden from us. Did the committe take a critial look at the problem and discuss alternative before deciding on this course? Did they even properly identify the problem that they were trying to solve? Hard for anyone to say since all of that information is locked away under NDA. But mean while, no one really knows what kind of effect that this additional syntax is going to have.

In developing applications, I've found that the rule of thumb has been, if I can do something in Smalltalk in 1 unit or time, it takes me 4x that do get it done in Java and 10x that to get it done in C++. If there is any validity to these numbers then one has to ask the question, what is the difference in the languages that have resulted in the differences? If I list the differences the biggest that I can think of are in syntax and typing. Smalltalk is not typed and has very little syntax. Java has more syntax and is typed. C++ has a lot of syntax that is further confused with macros and templates. My conclusion, typing and syntax work against my productivity.

> I find this reduces complexity, but you may find
> otherwise. That's ok.

Well is it? Is it really ok? Isn't this like smoking in the elevator or in another closed space? It might be your perference to smoke but in doing so.. you have also forced those around you to do so also. This is not like a coding standard where we can undo each other preferneces with a formatting tool. This has created a very fundimential change in the most basic tool that we have.. the langauge.

> project called Nice

Thanks for the pointer.

dgreenbean
Offline
Joined: 2003-12-08

> The primary safety
> > restriction that I worry about is type-safety.
>
> I guess this is where we differ, my primary concern
> is on symantic correctness and that cannot be
> enforced with a compiler.

I guess I should clarify. Symantic correctness is my primary concern for design. Type-safety is my primary concern for syntax. I assume in this statement that the syntax will conform to my design (not always the case, but that's a runtime debugging process as you indicate).

> Right, if you are building frameworks.. this can be
> an issue... but this is all the more reason to use
> composition as collections have collection type
> behavior where as domain objects have domain type
> behavior and it is those symantics that are
> important. Exposing a collection in an API is just
> exposing yourself for down stream problems. Not
> encapsulating collections in a class that provides
> symantics that is consistant with the domain is also
> exposing yourself for potential problems later on.

I find it very helpful to keep the collections exposed in a framework that will be extended later on. The reason is that I did not want to have a custom API that would need to change with the next version of Java. One of Sun's objectives in Java 1.5 was to keep legacy code running. I can imagine that this will continue to some extent in future releases.

> Humm, well I can't really comment on your
> requirements but I would say that in the dozens of
> projects that I've had some involvement in.. I've
> never seen a requirement that would justify the
> creation of these many collections. Tell me, how did
> you overcome the downcasting problem?
>
> Just doing the maths.. that is 500+ type safe
> collection classes. If you were to use say, HashMap,
> ArrayList as the most popular collections that means
> your application would of had something like say..
> 200+ classes that were to be contained in
> collections?

I had some structures like a list of a list being both the keys and values of a map, and then needing a list of such maps. In the end, I just created the structures from the standard collections, downcast at runtime as I needed information from them, and hoped I wouldn't get an exception. So maybe I'm exaggerating a little. I did a little extra work, but I essentially made it look a lot more like Perl than Java.

I only needed to hold about 5 classes in the collections, but I needed to hold them in about 100 different kinds of collections each (no exageration).

> As interesting as Scheme is.. I think Smalltalk is a
> much better solution for production systems.
>
> > Haskell is also a great
>
> *nods* but again, Smalltalk would seem to be a better
> choice.

I'm not very familiar with Smalltalk, so I'll take this on faith. I like Haskell, but will happily consider Smalltalk as an appropriate alternative.

> I don't mind how Java has been strutured... I just
> don't like the way it's been restructured. I agree
> that there were problems to solve.. the question is..
> has the solutions proposed been vetted enough that we
> should be needing to change the most fundimential
> contract that we have in the Java Platform, the
> language. The proceedings of the JCP JSR managing
> this process were totally hidden from us. Did the
> committe take a critial look at the problem and
> discuss alternative before deciding on this course?
> Did they even properly identify the problem that they
> were trying to solve? Hard for anyone to say since
> all of that information is locked away under NDA. But
> mean while, no one really knows what kind of effect
> that this additional syntax is going to have.

This sounds more like a political/economic argument than a programming one. It would be nice if the general programming community could see the decision making process that was used to make the changes in Java 1.5. I'm sure that some information that is "locked away under NDA" would be helpful in resolving this discussion.

> In developing applications, I've found that the rule
> of thumb has been, if I can do something in Smalltalk
> in 1 unit or time, it takes me 4x that do get it done
> in Java and 10x that to get it done in C++. If there
> is any validity to these numbers then one has to ask
> the question, what is the difference in the languages
> that have resulted in the differences?

Again, I can't speak for Smalltalk, but I will use my experience with Perl as an example. I can generally do something in Perl about 4x as fast as I can in Java. Even debugging small programs can be much easier. As my programs gain in complexity, I find it much easier to go to Java. A friend of mine once said to me that type-safety means nothing other than documentation. Now, I tend to use it as such, with the exception that my "documentation" will tell me if my program has a problem in it. I like Java 1.5 because it allows me to do this without adding a lot of extra code to do so. My objects are formatted based on the logic that was worked out in the design phase.

> If I list the
> differences the biggest that I can think of are in
> syntax and typing. Smalltalk is not typed and has
> very little syntax. Java has more syntax and is
> typed. C++ has a lot of syntax that is further
> confused with macros and templates. My conclusion,
> typing and syntax work against my productivity.

Again, I think that this is really preference more than anything. I don't mind the verbosity because it gives me an extra mechanism of documentation. I find it helpful to have more of the syntax explicit, so I don't have to remember all of the implications of syntax (and can concentrate on the implications of my design). Many people (especially in the Perl community) like to rely on the implications of syntax to actually do something significant. I find this leads to hidden errors in complex designs.

> Well is it? Is it really ok? Isn't this like smoking
> in the elevator or in another closed space? It might
> be your perference to smoke but in doing so.. you
> have also forced those around you to do so also. This
> is not like a coding standard where we can undo each
> other preferneces with a formatting tool. This has
> created a very fundimential change in the most basic
> tool that we have.. the langauge.

The analogy is good, but has a flaw. The assumption is that there is only one elevator. Another problem with the analogy is that a building with many elevators can choose which are smoking and which are non-smoking, and all will bring you to the same place. I would propose a new analogy that you already implied: a Swiss Army Knife. The knife could just be the basic knife with maybe a screwdriver attached. It could also be a massive conglomerate of every tool imaginable including a power saw (exagerating). Java could be thought of as somewhere in between, but leaning towards the power saw. When choosing one tool, you can either take the simplest thing to do the job, and maybe spend a little more time on harder things, or you can take the more complicated one to do the job quickly. The problem with the power saw is that you have to be careful in its use or you will cut off your hand.

I agree that we don't each live in a bubble. In the end, it is important that groups of programmers use compatable tools. My comment below addresses one solution to using a different, but compatable, tool.

> > project called Nice
>
> Thanks for the pointer.

One word about Nice that I want to mention before you spend a lot of time on it. It looks a lot like 1.5. The difference is that it can (or could the last I looked at it) compile to Java 1.2 bytecode.

-David

kcpeppe
Offline
Joined: 2003-06-15

>
> I find it very helpful to keep the collections
> exposed in a framework that will be extended later
> on.
Humm, I would consider this to be a violation of encapsulation under most circumstances. Maybe it's ok in your domain if ArrayList of some other collection was symatically important. That said, I've not seen a business domain where this was the case. In most cases, exposed collections are an indication that there is an abstraction missing from the model.

The reason is that I did not want to have a
> custom API that would need to change with the next
> version of Java.

Again respecting encapsulation can help insulate your application from changes in the underlying classes. It's not perfect but it can help.

> I did a little extra work,
> but I essentially made it look a lot more like Perl
> than Java.

Interesing... this is the power of real OO languages.. they allow you build a vocabulary that is in alignment with your domain.

>
> This sounds more like a political/economic argument
> than a programming one.

Yes, it is... that said, it's had some interesting effects on programming ;)

It would be nice if the
> general programming community could see the decision
> making process that was used to make the changes in
> Java 1.5.

*sighs*... I interviewed Aaron Williams on two occasions regarding his attempt to "open up" the JCP process. Both pieces are buried somewhere in the JDJ (don't ask me which ones 'cos I didn't keep track). I think Aaron did a good job given the constraints that he was under. That said, the discussions of the executive of any JSR are still subject to NDA. One of the claims is that the NDAs are needed to protect intelectual property that may show up in discussions. My feeling is that this type of intelectual property doesn't really belong in a public specification.

I'm sure that some information that is
> "locked away under NDA" would be helpful in resolving
> this discussion.

My feeling is that by the time generics where proposed, the expert committee was more interested in selling the idea than taking a critical look at it.

>
> Again, I can't speak for Smalltalk, but I will use my
> experience with Perl as an example. I can generally
> do something in Perl about 4x as fast as I can in
> Java.

That would be about the same number for unix shell scripting so it's not a surprise.

Even debugging small programs can be much
> easier. As my programs gain in complexity, I find it
> much easier to go to Java.

As good a shell and Perl are, they don't have the ability to organize source as well as Smalltalk, Java or even C++ does. IME, these tools are good for gluing stuff together but don't scale to handle larger tasks.

> > Well is it? Is it really ok? Isn't this like
> smoking
> > in the elevator or in another closed space? It
> might
> > be your perference to smoke but in doing so.. you
> > have also forced those around you to do so also.
> This
> > is not like a coding standard where we can undo
> each
> > other preferneces with a formatting tool. This has
> > created a very fundimential change in the most
> basic
> > tool that we have.. the langauge.
>
> The analogy is good, but has a flaw.

*sighs* what analogy isn't flawed ;)

> The assumption
> is that there is only one elevator.

There is.. only one language.. if a langauge feature is avaliable.... it will be used and one will have to understand it if one is going to be able to read the code.

Another problem
> with the analogy is that a building with many
> elevators can choose which are smoking and which are
> non-smoking, and all will bring you to the same
> place. I would propose a new analogy that you
> already implied: a Swiss Army Knife.

Ok, which analogy is flawed least, I used smoking because what one person does.. has effect unintended or otherwise on another. The swiss army knife is interesting in that it implies that you have many choices but it is missing the effect on others.

>
> One word about Nice that I want to mention before you
> spend a lot of time on it. It looks a lot like 1.5.
> The difference is that it can (or could the last I
> I looked at it) compile to Java 1.2 bytecode.

Unfortunately, my quick seach did not bring up Nice.

dgreenbean
Offline
Joined: 2003-12-08

I think at this point, the discussion has been fairly exhausted without some more scientific research to figure out some of the higher level issues.

Your point of encapsulation is well taken, and I would tend to agree if that were appropriate in the situations that I have been using. In general, my specific requirements tend to require the full collections API to be available. I do not generally write stand-alone modules, and the interfaces into the code I write become much simpler if I allow access to the collections API, rather than a lot of wrapper methods. I would be interested to study this further though. Whether the language should be flexible enough to handle this requirement is one of the questions at hand in this post. I cannot propose to know the answer to that without further research.

Maybe the JSR discussions have that answer already ;-)

As far as using one language versus another, the question is less of any simgle language, and more of how different languages talk to each other. Since each language has a different set of features to offer, the industry should have better support for the way all these languages can interact.

I like the rich set of features that Java provides, and welcome generics as a feature that will definitely help me personally use the language more effectively. It seems that the majority of Java programmers agree. While changing the language is not a democratic process, it is more of a marketing process than a scientific one. The reason for this is that the language is a tool, and the tools are meant to be used by humans. Effective marketing will ensure that more people use the language. As with any marketing decision, some people will be disappointed with the results and find another tool.

The real trick is how can everyone use a tool of his or her choice, and produce something that is valuable to everyone else. While standards can provide this on a large scale, it would be pretty annoying to have to integrate a small Haskell program into a Java web server. Being able to compile that same Haskell program into Java 1.5 bytecode with an open-source compiler might be a better solution. I leave this question open though, as it is a very difficult problem.

As far as editing code, it gets even more difficult, but that is a business problem. Each company needs to assess the skills and preferences of its programmers, and use technologies accordingly. Since most Java programmers seem to welcome generics (I have no data to back this up), it makes sense that they were added to the language.

Nice is located at http://nice.sourceforge.net . It may be obsolete now, but the idea could be changed/extended to suit your needs.

-David

kcpeppe
Offline
Joined: 2003-06-15

> I think at this point, the discussion has been fairly
> exhausted without some more scientific research to
> figure out some of the higher level issues.

agreed ;)

>
> As far as using one language versus another, the
> question is less of any simgle language, and more of
> how different languages talk to each other. Since
> each language has a different set of features to
> offer, the industry should have better support for
> the way all these languages can interact.

Agreed... however there is a tendency to have organizations use a single language. I was fortunate to work in one organzation where we could use just about anything that we needed. After that it's been pretty much monotonic.

> some people will be
> disappointed with the results and find another tool.

The problem here is that the market is now skewed between .NET and the Java platform. Is there another language that will be able to overcome the barrier to entry that these two platforms have created?

> Being able to compile that same Haskell
> program into Java 1.5 bytecode with an open-source
> compiler might be a better solution. I leave this
> question open though, as it is a very difficult
> problem.

Sort of like the p-code solution or CLR? ;)

> Since
> most Java programmers seem to welcome generics (I
> have no data to back this up), it makes sense that
> they were added to the language.

I've had this discussion with a number of developers. The numbers in favor may not as large as one thinks. That said, I do agree, it seems as if the majority want generics. That said a guy named Copernicus sort of proved that the majority is not always correct ;)

> Nice is located at http://nice.sourceforge.net . It
> may be obsolete now, but the idea could be
> changed/extended to suit your needs.

I doubt that I'll use it. When I design languages, I tend to make them very specific to the problem domain that I'm working in. In this regard, I find that general programming languages are.. well... to general. That said, I shall be taking a look.

vhi
Offline
Joined: 2004-10-11

Wow... A VERY long and verbose thread ;-). I think we have lost track on what we are discussing. Again...

Anyway, let me repeat what I had posted elsewhere.

1. We need Maps. I do not know what you meant when you said that ALL usages of lists can be properly abstracted out of existance. Actually, an example here would greatly increase my understanding of your statement.
2. We, the developers who are STATICALLY minded, paranoid of less experienced maintainers, prefer static typing, prefer predictability over dynamism and maintainability.
That does not mean that we do not have experience in dynamic languages like Ruby. (Actually, I would love to see Objective-C/Ruby like messaging syntax in Java. Will post it as a request later).
4. Therefore, we feel that Generics is in spirit of what Java stands for. It definitely is not in the spirit for what Ruby stands for. In case you are looking for a more dynamic language for the JVM without any hooks for static typing, I suggest you checkout JRuby (though its integration with Java is not that tight).

tsinger
Offline
Joined: 2003-06-10

> Repeating myself: you don't like them? DO NOT use
> them. And let others enjoy and benefit from the
> feature.

I fully agree with you. Generics really help in avoiding bugs.

OK, in some complicated scenarios they are not easy to read, but that is the same in real-world, when something needs to be described exactly.

Tom

grlea
Offline
Joined: 2004-05-26

> generics do not improve readability.

Well, I don't think that was the main point of putting them in.
It was almost certainly to improve type safety, which it does very well.

Despite that, I disagree with your assessment of the readability of generics. I hope you are not confusing readability with prettiness: prettiness is how nice the code is to look at; readability is how easy it is to figure out what code does just by reading it. I think generics does increase Java's readability, but it does look a little ugly, a cost I'm willing to bear.

markswanson
Offline
Joined: 2003-06-11

Generics have helped me tremendously. I'd like to send a huge "Thank you" to Sun for doing this.

jimcp
Offline
Joined: 2003-11-04

"tremendously" Words? Can you publish an example, please? Only code talks.

kcpeppe
Offline
Joined: 2003-06-15

> Only code talks.

+10

patrikbeno
Offline
Joined: 2004-10-11

Well, for some people, code won't do it either :-(
But you can give it a try:
http://forums.java.net/jive/thread.jspa?forumID=23&threadID=106&messageI...

kcpeppe
Offline
Joined: 2003-06-15

> Well, for some people, code won't do it either :-(
> But you can give it a try:
> http://forums.java.net/jive/thread.jspa?forumID=23&thr
> eadID=106&messageID=4453#4453

Oh, that code talks.. it says complexity with very little benefit.. why do I want it? Now lets see some real code :)

patrikbeno
Offline
Joined: 2004-10-11

Benefit was explained. There were three or four classes without implementations just to show the concept. is this too complex for you? oh, I forget, it was so complex you did not manage to notice collections were never used in there :-(

If this is too complex for you, what can I achieve by posting a thousand lines of real code? You would not see it either. Because you do not even try to recognize angle brancket from a collection :-(

kcpeppe
Offline
Joined: 2003-06-15

> Benefit was explained. There were three or four
> classes without implementations just to show the
> concept. is this too complex for you? oh, I forget,
> it was so complex you did not manage to notice
> collections were never used in there :-(
>

It's hard to see what your really trying to show with that code fragement. Aside from a grotesque header and a very one sided assault on composition, the posting really doesn't offer much. Your explination is interesting but.. as has been posted, code talks and you've really not shown any.

patrikbeno
Offline
Joined: 2004-10-11

Ad. my "assault" on composition: I use and accept composition as a good design pattern. But it's just not an option for generics replacement.

Code that TALKS and WORKS is in Java5 collections. Unfortunatelly, this code does not speak the language you understand.

So I thought you need to see more complex architectural example. In such examples, signatures are important, something that shows how pieces fit together, how they interract. I haven't included any implementation because that does not work for you (see collections). However, this does not work for you either. I fear you may not have required kind of imagination for this (or you don't want to).

If we cannot reach the state where you at least see the point, we may not be able to begin discussing about whether this point is sound or not.

How may I be of service, sir? Simple is too simple, complex is too complex.
In simple examples, you miss the reason.
In complex ones, you fail to see it. And once you fail, you ask for simple stuff again. But it won't do it. You have to see the big picture.

vhi
Offline
Joined: 2004-10-11

Which is more readable, Map or Map? For ME, Map provides me with more information, hence is more readable. It is verbose, but readable. Verbosity does not necessarily mean it is less readable.

Again, at the risk of repeating myself, there are many of us, who would like to know the type of an object beforehand. We have a need to be guaranteed that some kinds of errors would not happen at run-time. It is just the way we are. We love to have control over the usage of APIs that we write.

Look at what happened to the 'Properties' class. In it, it had to be explicitly commented not to use 'put(Object, Object)' as it would compromise the proper execution of 'save' method. If Java supported Generics earlier, this could have been solved by extending Properties from 'Hashtable', instead of an ignore-me-at-your-peril comment and two extra methods.

kcpeppe
Offline
Joined: 2003-06-15

> Which is more readable, Map or Map? For
> ME, Map provides me with more
> information, hence is more readable. It is verbose,
> but readable. Verbosity does not necessarily mean it
> is less readable.

I get the same type safety from using composition without the messy syntax. More over compostion moves me to a symatically more correct model. If you are not using composition even with generics, IMHO, you are doing something wrong.

patrikbeno
Offline
Joined: 2004-10-11

Composition is a good design pattern.
But somewhere in your 'composed' object, you have to use collections. The more complex your object is, the more collections and more frequently it uses.

So, OK, you have a solid type safe composed object, But inside it, without generics, you still have less safe and less readable code.

And without generics, you cannot do something I described elsewhere (http://forums.java.net/jive/thread.jspa?forumID=23&threadID=106&messageI...)

kcpeppe
Offline
Joined: 2003-06-15

> Composition is a good design pattern.
> But somewhere in your 'composed' object, you have to
> use collections. The more complex your object is, the
> more collections and more frequently it uses.

IME, if your object is this complex, you are most likely doing something wrong. I've never felt the need to use more than two collections in an object and pretty much the only reason that I use a second collection is to maintain a secondary indexing scheme for query support.

>
> So, OK, you have a solid type safe composed object,
> But inside it, without generics, you still have less
> safe and less readable code.

Nonsense! the method signatures ensure that I cannot pass anything that I don't want to collect in the composing object.
>
> And without generics, you cannot do something I
> described elsewhere
> (http://forums.java.net/jive/thread.jspa?forumID=23&threadID=106&messageI...)

Sorry but I think the design is overly complex and consequently is a perfect example of the type of code that I would not want to promote nor maintain. In addition, the explination helps points out the need for closures, not generics.

patrikbeno
Offline
Joined: 2004-10-11

> IME, if your object is this complex, you are most
> likely doing something wrong.

In the begining, everything is simple, clean and readable. As application evolves, as it reaches version 10.0, as business introduces further and totally weird requirements unpredictable before version 1.0, without accepting the fact that application needs complete or partial redesign...
[b]things are getting too complex too quickly and very easily in the real world[/b] and if you cannot drop the whole thing, you're mostly helpless

> > So, OK, you have a solid type safe composed
> object,
> > But inside it, without generics, you still have
> less
> > safe and less readable code.
>
> Nonsense! the method signatures ensure that I cannot
> pass anything that I don't want to collect in the
> composing object.

Ok, if you use just your two Maps with different key:value types in your object, you will internally end up with at least 2^4 possible combinations for type-unsafe map.put(key,value) calls.
Ignoring the fact that your internal maps are completely unsafe, tell me please how do you at least HINT (not even ENFORCE) that you call map.put() with the proper arguments?
You state it in the comments in variable declaration? Well, then generics are much more suitable for this.

> Sorry but I think the design is overly complex and
> consequently is a perfect example of the type of code
> that I would not want to promote nor maintain.

Sounds to me like you either did not read or did not understand or never designed really complex application (or framework). No offence intended, sorry.
But if you just say it is too complex without telling how to make it simpler... :-(

> addition, the explination helps points out the need
> for closures, not generics.

I would love to hear how closures can help me with the mentioned example. no sarcasm here, I am just nor good enough at that 'closure' stuff.

kcpeppe
Offline
Joined: 2003-06-15

> > IME, if your object is this complex, you are most
> > likely doing something wrong.
>
> In the begining, everything is simple, clean and
> readable. As application evolves, as it reaches
> version 10.0, as business introduces further and
> totally weird requirements unpredictable before
> version 1.0,
I think you are mixing up language evolution with application evolution. I suggest a reading of Rousseau and his theory on the evolution of langauge.

>
> Ok, if you use just your two Maps with different
> key:value types in your object, you will internally
> end up with at least 2^4 possible combinations for
> type-unsafe map.put(key,value) calls.

more nonsense... if a coder can't manage two maps in a class, then he's not much of a programmer.

> > Sorry but I think the design is overly complex and
> > consequently is a perfect example of the type of
> code
> > that I would not want to promote nor maintain.
>
> Sounds to me like you either did not read or did not
> understand or never designed really complex
> application (or framework). No offence intended,
> sorry.
> But if you just say it is too complex without telling
> how to make it simpler... :-(

Sir, I have had some fun taking complex things and simplifying them. In one instance, I did away with 4 man years of coding in 5 days of coding. In another I reduced a 55,000 line framework to 7000 lines of code while capturing about 80% of the (useful) functionality. I've also witness others do the same for example, a colleague of mine replaced an important component of an application (that took 4 months to write) with 2 days of coding. In this case in addition to reducing bulk, the application ran 15x faster and the error rate was drastically reduced. I ask the question, how much code can anyone write and debug in 2 days?

Most of the problems I see came from people thinking that they need to control every single aspect of the code and in just about every case, they were wrong. Generics and typing are a perfect example. Pessimistic locking is another example. There are less intensive ways of achieving these same thing. Composition is but one example. My experience is that minimalisum in coding and in code is what works. These things are not minimalist.

Another colleague that I worked with taught me that when things are in their proper place, you will now because there will be a multi-dimensional reduction. The preceived need for generics, auto-boxing are expansionisum. Following the aforementioned principle, this tells me that the authors of these solutions are trying to solve the right problem the wrong way. Auto-boxing tells us that we need to mix objects and primitives but we can't. The syntaxtic sugar that you are looking for is now just about 30 year old. It's been well tested and it works.. promote primitives to the status of a first class object.

As for typing, I don't have a good answer for people wanting this feature. All I know if that when I encounter a language with strong typing, I will end up writing more code than when I use a language with no typing, weak typing or with a typing system that I can defeat (C being an example of the later). But, I would suggest that you don't believe me. Instead I would invite you to check out Ruby, Smalltalk, and Lisp and write an application or two in those languages. Better yet, try reading Pragmatic Dave's work on how building your own scripting language can help you to solve problems. I'd suggest using javacc, there are a lot of good example grammers around to help you over come the lack of documentation.

>
> I would love to hear how closures can help me with
> the mentioned example. no sarcasm here, I am just nor
> good enough at that 'closure' stuff.

Martin Fowler just wrote a brilliant piece on closures. Rather than do a poor job of repeating his words, you should take a look at his work. I believe it is published on the thoughtworks site.

patrikbeno
Offline
Joined: 2004-10-11

> > In the begining, everything is simple, clean and
> > readable. As application evolves, as it reaches
> > version 10.0, as business introduces further and
> > totally weird requirements unpredictable before
> > version 1.0,
> I think you are mixing up language evolution with
> application evolution. I suggest a reading of
> Rousseau and his theory on the evolution of
> langauge.

No.
I say that language and whole application development platform must help me to solve real-life problems. If application evolution cycles/needs are ignored by platform/language, you will get something academically right but pragmatically useless.

You say my object is complex. I say 'stuff happens'. I can't do anything about it in this release. Is there something that could help me? Oh, let's see, I have a lot of anonymous collections here and I have to use them, why not make them a little type safe and predictable? God bless generics, even as dumb as they are.

> Sir, I have had some fun taking complex things and
> simplifying them. In one instance, I did away with 4
> man years of coding in 5 days of coding.

Oh that's really impressive. really, no sarcasm.
Pity it's so relative: Was existing code so bad or is it just glorious you? Was your architecture easily extensible or it just solved THE ONE unredefinable problem at hand?

It is always easier and quicker and less verbose to do a raw JDBC call directly form JSP page. But we have a good reasons not to do it.

> more nonsense... if a coder can't manage two maps in
> a class, then he's not much of a programmer.

Coder usually can manage his own code. But you forget about a maintainer that have seen your code just 20 minutes ago, he barely knows what it does, but he is supposed to do something with it in the next hour. He may have a little problem, don't you think?.

That's where and why static and dynamic type safety comes in. Same aplies for a little more verbosity in the language (Perl or Bash may be less verbose, you can quickly startup your project but Java is more maintainable)

You seem to forget that project lifecycle usually does not end with the first release and that release 7.0 is often implemented by completely renewed development team. Needless to say that maintainance teams are built up from less experienced junior developers (seniors just don't want such a job)

> Generics and typing are a perfect example.
> Pessimistic locking is another example. There are
> less intensive ways of achieving these same thing.

Have you EVER spent several hours, I dare to say DAYS in some cases, by looking for a silly stupid annoying bug introduced accidentally by fresh new unexperienced member of your team?
What would you think if you find out that this fatal stupid mistake could be caught by the compiler?

Wake up! We do not only write the code. We do not only try to build up applications as fast and as efficiently as possible. [b]We also do maintain them.[/b] And OFTEN we do maintain applications written by others. Further, in real life the documentation is insufficient or wrong. [b]What is not enforced is not guaranteed to be obeyed![/b]
That is real life, these are real life problems and we have to deal with them. Generics, static type checking, DTDs/XMLschemas, build-time validations, these are things that really help in this war.
[b]Rule of thumb: Catch the error when it occurs not when it causes damage! Catch it or get caught![/b]

> My experience is that
> minimalisum in coding and in code is what works.

That my religion, too. [b]But I will never sacrifice readability, maintainability and self-documentation for any kind of minimalism[/b]

> I'd suggest using javacc,

Thank you, I am quite familiar. i have enjoyed a few days of PL/SQL & Java refactoring using javacc.

kcpeppe
Offline
Joined: 2003-06-15

>
> You say my object is complex. I say 'stuff happens'.

I'd like to further explain my assesment... A Bank is more than a collection of accounts, customers. To simply cast away this abstraction with a generic covering over a collection is to miss on this abstraction. The behavior to support that abstraction must live somewhere. Since it can't live in the collection, the question becomes, where? Quite often that behavior is scatter and consequently repeated through-out the application. The repetition is due to a number of reasons of which the two more important (IMHO) are one can't find it and it is buried in baggage that makes the behavior difficult if not impossible to use. Note, these are points of design and coding that may not appear to have anything to do with generics and they don't... or do they... Your example shows how generics may even help to promote designs that aid in the fragmentation of key abstractions.

>
> Oh that's really impressive.

Humm, this was not the point... In the first case, the development team decided to write a controller for distriuted processing in C. They also decided that they needed to control and track a large number of things. It took them a long time to write all of this code. Although they were fairly clever (and I am sincre about this), the got caught up in trying to build in to many controls that almost worked. So, the patched and tested and rewrote and tested but they were never able to get the system to the point where the error or failure rates in the process that they were trying to control/monitor even approached the error rates in the monitoring/controlling system. They used the wrong tool, C. The system was rewritten using Bourne shell scripts. It was the right tool because it supported the needed abstractions. It also allowed us to drop many of the controls and monitoring because they were not longer needed in this new solution space. Same problem, different solution. Lessons learned, one language does not fit all and consequently you need to use a language that supports the abstractions you need. The question is, can you recognize when this happens?

In the other cases, the reductions came with-in the same language. They were all due to people missing key abstractions in the solution space. Lesson learned, missing key abstractions is a huge problem. When people are able to identify key abstractions, thing tend to become simpler, not more complex.

IMHO, Smalltalk has found a number of the right abstractions in language where as C++ has taken C to a hightened level of complexity. Java seemingly is an accidential mix of the two and consequently suffers from some of the precieved complexities of C++ (Syntax) as well as patching over some of the precieved problems of Smalltalk (lack of control structures and typing). In some of the uglyness of the mix we have language that has allowed us to rise above the arguments of syntax and drift into more interesting topics. Unfortunately, the 1.5 has done a lot to reverse this trend in that we are now wasting a lot of time talking once again about syntax. For me, this is a sign that we are drifting towards complexity and as I've learned is that even though people accept this as a natural direction, it doesn't have to be this way.

patrikbeno
Offline
Joined: 2004-10-11

> I'd like to further explain my assesment... A Bank is
> more than a collection of accounts, customers. To
> simply cast away this abstraction with a generic
> covering over a collection is to miss on this
> abstraction.

You are forcing me to believe you have not read it at all.
I have not even used collections in the example!
Whole point had nothing to do with generified collections.
I am really disappointed.

The point was that you can use generics mechanism to upgrade whole your abstract (base) model
from set of interconnected and cooperating AbstractBank, AbstractAccount, AbstractCustomer
to a completely customized model using MyBank, MyAccount and MyCustomer. All this using relatively simple generic declarations.

You further explanations therefore do not make any sense. I suggest you read my example (again?), optionally ask me some 'where', 'how' and 'why' if you need to clarify something.
Because you just don't get it. Oh, but don't worry, if you are sure you read it all with attention, it can safely be my fault as it means that I was not able to explain my point. In this case I would welcome if you help me to make myself clear enough.

> They used the wrong tool, C. The system was rewritten
> using Bourne shell scripts. It was the right tool

I use BASH and tools a lot, my friend, and I love it, I enjoy being able to to do a quite complex task with a single line of code.
But forgive me, I doubt it can be used to write large-scale, complex but highly maintainable enterprise application. You must be joking.

> interesting topics. Unfortunately, the 1.5 has done a
> lot to reverse this trend in that we are now wasting
> a lot of time talking once again about syntax. For
> me, this is a sign that we are drifting towards
> complexity ...

Now please let me put it this way:

We're talking about syntax when we feel it reduces verbosity without sacrificing readability and safety. (Consider Java 5 enums and compare them with Bloch's type-safe enumeration pattern used in 1.4 and bellow. Improvement without any doubt. Same aplies for for-each statement. You may not need them but they really help)

Generics do not introduce complexity into the language. they help us to deal with complexities in applications we build. That is their main purpose and that's why they might seem overly complex. But compare them to the problems they may help you to solve and you will be happy to have them.

Well, I think I made quite a few points in this as well as my previous post. I feel you just ignore many of them.

kcpeppe
Offline
Joined: 2003-06-15

>
> > They used the wrong tool, C. The system was
> rewritten
> > using Bourne shell scripts. It was the right tool
>
> I use BASH and tools a lot, my friend, and I love it,
> I enjoy being able to to do a quite complex task
> with a single line of code.
> But forgive me, I doubt it can be used to write
> large-scale, complex but highly maintainable
> enterprise application. You must be joking.

System ran without any intervention (including hardware fail-overs etc.) for more than 3 years when management suddenly realized that no one had done anything or even looked at the very core of their distributed processing platform. What gave them piece of mind was that the new programmer assigned to look after the code was very comfortable with the entire code base only after a few minutes of study. So yes, Bash, Bourne, Perl can be effective in gluing systems together. Afterall, that is what they were designed to do ;)

>
> Generics do not introduce complexity into the
> language.

I completely disagree.

> Well, I think I made quite a few points in this as
> well as my previous post. I feel you just ignore many
> of them.

I might add the same but.... instead I'll just say that I've not ignored what you've written, you've just repeat the old boring type-safety mantra. I just don't see type type-safety as a big enough issue to warrent the extra syntax and complexity that it brings. End of story!

vhi
Offline
Joined: 2004-10-11

The enum in Java IS the implementation of Bloch's Enum Pattern.

Annotations were included to make the Java programmer's life *easier*. Look at EJB 3.0 specs and probably you will appreciate the amount of simplicity it brings.

Generics is not to satisfy the C++ programmer's requirements. It improves code reliability and hence predictability. Agreed that it makes it more verbose, but given a choice, I would choose predictability, it actually makes it more readable for me.

About asserts, I can only say that you have to use them frequently to appreciate them.

kcpeppe
Offline
Joined: 2003-06-15

generics do not improve readability. Unfortunately, we'll only learn this after the "horse left left the barn". :(

patrikbeno
Offline
Joined: 2004-10-11

Still alive & fighting, aren't we? ;-)

Generics may not improve readability FOR YOU. Ok, I can live with that.

But how can you convince me or others who claim generics REALLY DO improve readability for them? How? "Improving readability" is so subjective you cannot.

Repeating myself: you don't like them? DO NOT use them. And let others enjoy and benefit from the feature.

You asked for example of what you CANNOT do without generics. I gave it to you.
http://forums.java.net/jive/thread.jspa?forumID=23&threadID=106&messageI...
What do you say?

kcpeppe
Offline
Joined: 2003-06-15

> Still alive & fighting, aren't we? ;-)

Just trying to keep sanity in the discussions... :)
>

>
> Repeating myself: you don't like them? DO NOT use
> them.

How naive. I do wish it was that easy.. since generics are in the language, I'll have to deal with them.
>

> And let others enjoy and benefit from the
> feature.

There is no benefits.. IME...
> You asked for example of what you CANNOT do without
> generics. I gave it to you.
I disagree and you ignored my arguments so....

patrikbeno
Offline
Joined: 2004-10-11

I have not ignored your arguments.
You asked, I answered, you have not responded.
That's it, so simple. It's your turn. You may ignore it but don't say it was me.

eevictor
Offline
Joined: 2004-07-08

I have read through the Tutorial PDF on Generics.
I sighed and think that Java code will lost one of
it's major meric if people use generics all over the place.

My under standing of "Collection" is a group of something.
That Something can be anything. This vagueness is the purpose of called "Collection" and makes use of OO polymorphism.

If anyone have specific thing "Collection of Strings only, or else it will break the world!" in mind, then they should very create a specific class to encapsulate the collection and ensure it won't break the world.

Using triangle brackets reduce redability (or beauty). It simply make me want to stare away from the code.

patrikbeno
Offline
Joined: 2004-10-11

1) What would you suggest to use instead of angle brackets to make the code look more pretty?
2) Encapsulating every possible type of collection has its drawback: you cannot use such type as standard collection anymore.
3) Readability means that you are able to figure out what the code does, what data it expects and/or manipulates. It has very little to do with the beauty of the code.

For me, angle brackets work, I would not trade them for anything. Code is much more verbose, I agree. But verbosity is relative: you declare variable only once, you use it many times. the more you use such variable the more it pays off (compared initial verbosity)