The Artima Developer Community
Sponsored Link

Weblogs Forum
Have Generics Killed Java?

62 replies on 5 pages. Most recent reply: Aug 8, 2010 3:43 PM by Eric Armstrong

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 62 replies on 5 pages [ « | 1 ... 2 3 4 5 ]
Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Have Generics Killed Java? Posted: Aug 7, 2010 10:33 AM
Reply to this message Reply
I'm reading a Servlet example ( that uses the old syntax, and seeing all the casts makes me really appreciate the new generics.

In the old days, I'd be wondering "what the heck does a ShoppingCart hold so I can cast it to something useful" and browsing somebody's lousy and out of date javadocs. Now the IDE & compiler knows.

Niklas Ekström

Posts: 1
Nickname: niklas
Registered: Aug, 2010

Re: Have Generics Killed Java? Posted: Aug 7, 2010 1:45 PM
Reply to this message Reply
> isn't the generics; it's the lack of type inference. In
> C# it's
foreach (var e in map)

In C# you can also do this:

public static class Extensions
    public static void ForEach<TKey, TValue>(this IDictionary<TKey, TValue> dictionary, Action<TKey, TValue> action)
        foreach (var pair in dictionary)
            action(pair.Key, pair.Value);
class Program
    static void Main(string[] args)
        var dictionary = new Dictionary<string, string>();
        dictionary["key1"] = "value1";
        dictionary["key2"] = "value2";
        dictionary.ForEach((k, v) => Console.WriteLine("{0} : {1}", k, v));

Once you have the extension method, the ForEach on the last line looks similar to the Ruby version.

Eric Armstrong

Posts: 207
Nickname: cooltools
Registered: Apr, 2003

Re: Have Generics Killed Java? Posted: Aug 8, 2010 3:43 PM
Reply to this message Reply
Morgan wrote:
> Seeing all the casts makes me really appreciate the
> new generics.
Yeah. Can't say I loved those, goodness knows.

Niklas gave this C# example:
> dictionary.ForEach((k, v) => Console.WriteLine(...)
Gotta love that.

Still. I continue to be amazed that there is any kind of argument over specification-first development, where the specification is both readable and runnable. (Every production shop I see, people don't seem to think they have time for it.)

People who work in statically-typed languages spend so much time satisfying the compiler that they often seem appalled by the "extra time" required to write tests. By the time they have finished satisfying the compiler, they have a program that runs in a "plausible" manner. But they leave behind a program that isn't truly spec'd, and that has unknown bugs. Worse, when a bug does surface, the cause will be hard to find. (A major advantage of tests is that they keep bugs shallow.)

On the other hand, I take the point made by several folks that static typing in general, and generics in particular, help immensely when trying to figure out what some other programmer's code expects, and what it gives back. In large projects especially, fixed classes and static types all seem like a major win.

But here, I think that "specification" (as in readable, runnable tests) provides an interesting answer:
a) They say what a routine accepts and what it gives back.
b) If an "open" class needs to be extended to work, the
tests tell what additions are necessary, and how they
are accomplished.
c) If the extensions cause problems in the calling code,
the callers tests identifies the problems straight
d) If the caller has extensions of their own, the
library tests tell straight away whether or not the
extensions cause problems.

In effect, runnable specifications enforce contracts. They do so in a way that can ensures correct semantics, rather than being limited to correct types. So the relative "safety" of static typing seems like something of a mirage, to my mind. (To take a page from Dykstra, you specify pre-conditions, post-conditions, and invariants. Then you prove those conditions are satisfied over a range of inputs.)

The more work it takes to achieve that degree of safety, the less inclined the programmer will be to consider (and the less time is available for) other measures that provide an even greater degree of safety.

Type inferencing is clearly necessary to minimize the time requirements. But is it sufficient? I don't see how it can be, given that static typing is itself insufficient.

Even so, it is clear that type inferencing would greatly reduce the cost of compliance, in return for a measure of safety and more readable contracts.

Flat View: This topic has 62 replies on 5 pages [ « | 2  3  4  5 ]
Topic: How Much Unit Test Coverage Do You Need? - The Testivus Answer Previous Topic   Next Topic Topic: Adding Optional Static Typing to Python

Sponsored Links


Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use