Campbell Ritchie wrote:Welcome to the Ranch
I think a large part of the problem with Java® generics is that they were not introduced on day 1. Maybe they ran out of time or money or both. So as not to lose backwards compatibility generics is implemented via erasure. Maybe if they had intriduced generics at the beginning and used reification you wouldn't now be seeing that problem.
Jesper de Jong wrote:I am strongly in favour of static typing. The earlier you catch errors in a program, the cheaper these errors are to fix. It is always better to have an error show up at compile time than to have it show up much later, at runtime. At runtime, you won't notice an error until the code with the error is executed. Especially if the error first occurs when the software is already deployed in production, it will be much, much more expensive to fix than when it would have been caught at compile time.
Paul Clapham wrote:Here's another take on the question which I haven't seen elsewhere.
If you hang around this forum for a while and watch what beginners ask, you will see people who want to make a List consisting of a variety of different kinds of object. Usually they are fumbling around trying to figure out how to cast these objects when they go to get them back out of the list.
And usually they have made a design error by trying to produce a heterogeneous list like that. So what I'm saying is this: the presence of generics in the language implies that a List should (almost) always be a homogeneous list, a List<Something> in fact. Which means that not only is the presence of generics preventing run-time errors by presenting them as compile-time errors, it's also preventing design errors by constraining what code you can write.
Thomas Gard wrote:But I would argue that it ignores the fact that actually using statically typed languages has its own cost: it increases development time. To many of us, it's much better to simply use and let the compiler (or runtime) figure out how to declare things.
Jesper de Jong wrote:
Thomas Gard wrote:But I would argue that it ignores the fact that actually using statically typed languages has its own cost: it increases development time. To many of us, it's much better to simply use and let the compiler (or runtime) figure out how to declare things.
I disagree that it increases development time significantly; on the contrary, it helps to make code easier to understand, which saves you time. Besides providing more type-safety, generics help as documentation, so that you understand quickly what exactly a method returns, for example. Suppose that you have some method that returns a List in some unfamiliar project. How do you know what the type of the elements in the List is? Without generics it's hard to find out. With generics, you can see it immediately.
Paul Clapham wrote:Sure, I'm not saying it prevents that design (which isn't all that bad because it isn't that heterogeneous),
Thomas Gard wrote:
Have you spent considerable amounts of time in dynamically typed languages? It's a much smoother experience, even though I'm most familiar with the rigidity of statically typed languages.
Dave Tolls wrote:
Does Javascript count?
Because that is one pain in the posterior with some of the "interesting" code I've had to work with, all done based on the freedom the language gives.
You argue that you should know what is passed back, however it is anything but clear in your average script.
At least with Java I know (outside of a few frameworks) what I need to be dealing with just from looking at the signature. And you can usually bury those framework interactions (eg some Hibernate stuff) into the smallest scope.
Thomas Gard wrote:I just don't like that arrays are covariant, and generic types are invariant, and further that you cannot mix the two.
Thomas Gard wrote:
No, I'm saying that you don't know what a routine is doing simply by knowing the datatypes returned. You just don't. And it doesn't even help. And once you *do* know what the routine is doing, the last thing in the world that matters is the type.
Thomas Gard wrote:
But I'm not intending on winning anyone over to the dynamic types camp. In fact, it took me quite a while to let go of it myself, so I certainly am not expecting anything there. Nor would I even attempt anything to that extent in a Java forum. So we can shake hands and leave that part of the discussion behind.
Thomas Gard wrote:
What I was hoping to focus on was whether or not generics actually end up doing more harm than good. I am comfortable using generics....I just don't like that arrays are covariant, and generic types are invariant, and further that you cannot mix the two. It's just not intuitive, and I don't see the win in all of this.
In fact, I'll bet if you ask around you'll find that most folks who are "fans" of generics don't even know what the terms covariant and invariant mean, let alone that you can't declare an array of a generic type.
Thomas Gard wrote:
Have you spent considerable amounts of time in dynamically typed languages?
Meyer is very good at identifying the good and bad features of languages and writing them down succinctly.Bertrand Meyer's book, page 1106-7 wrote:Born in a log cabinet, C quickly rose to prominence …
Politically, C ended the fossilized situation which prevailed in the programming language world until about 1980.
… Fortran … Cobol … PL/I …
C [… made] it acceptable to think of the programming language as something you choose from a reasonable broad and evolving catalog.
Consider Paul's rocket mass heater. |