Summary
Type inference makes it possible to not have to declare local variables in an otherwise strongly-typed language. Elliotte Rusty Harold shares his view on why adding type inference to Java would make Java a less attractive language.
Advertisement
Type inference seems to be a well-accepted feature of many modern languages: Scala, Haskell and a host of other languages have it, and type inference is also a planned for the next versions of C# and Perl.
Type inference alleviates the need for the programmer to explicitly declare local variable types in an otherwise strongly-typed language. Instead, the compiler is tasked with deducing the eventual type of a variable or expression. The compiler can do this by examining method return types and the results of other expressions that are eventually assigned to local variables. Since type inference provides a way to reduce by some amount the code a developer has to write and maintain, and there are several proposals to add type inference to Java.
In his latest blog post, Type Inference: Another Bad Idea for Java 7, Elliotte Rusty Harold shares his views on why adding type inference to Java may not be a good idea, after all:
Type inference actually makes some sense in languages like JavaScript and PHP that are built around this, and had this feature from day 1. It makes no sense in a language like Java that’s built around the opposite. It makes Java look weakly typed, but it isn’t. In fact, if anything this is now more strongly typed because, for example, you have to type a Map variable as a HashMap or a TreeMap rather than just a Map.
However, Harold's real beef is with the fact the adding type inference would layer yet another veil of complexity over Java:
This makes some sense to those of us who’ve been breathing this stuff for 10+ years now. It makes no sense at all to anyone who’s coming to the language for the first time. It’s just one more source of weird, incomprehensible compiler error messages they have to ask their professor to debug for them. Is this really worth saving a few keystrokes of typing?
Indeed, Harold believes that Java's time has come, and that new features and new language ideas should find their way into new languages instead:
It’s time to call a halt to new features in the Java language... The current push to add new language features to Java without taking anything away must stop. Every single one makes the language worse, not better. Every single one makes Ruby and C# and Python look more attractive. You cannot build on top of an old foundation forever. Fifty story skyscrapers cannot be built by adding floors to a five-story tenement. Sometimes you have to move down the block and start building in a new lot. For Java, that time has come.
Do you agree with Harold that increasing the number of features available in Java makes other, possibly simpler, languages more attractive? Is it time to move on and explore other languages in order to benefit from programming concepts that Java does not provide?
I wholeheartilly agree that Java should stay as it is. Other programming paradigm should go into new languages. 'Pimping' a programming language is like pimping your car - it may look sexy for a while, but it devaluates your car in the long run.
I agree with Achilleas, this is one of those problems that can be solved just as easily by the IDE as the browser. Putting functionality in the tooling rather than the language itself is a nice way of leaving developers with the choice to adopt a new piece of functionality or not.
> "Type inference actually makes some sense in languages > like JavaScript and PHP that are built around this, and > had this feature from day 1." > > I'm surprised to see that comment repeated without > question - does either JavaScript or PHP have type > inference?
Excellent point. It's also interesting that he thinks adding new features to Java drives people to C#, because it seems like C# is the one that is escalating the "features race" and many advocates of adding features feel they are necessary to compete with the rapid evolution of C#.
If it was done in the IDE what would happen if for some reason there happened to be a class called auto that happened to inherit from HashMap?
I think the car pimping analagy is erroneous, it implies that changes are for vain attempts to change status / attractiveness. Changes to a language are about improving its developers' productivity.
Personally I work with Java pretty much every day and another language with type inference, it's not just the type inference but the other langauge does make me feel like writing Java is like explaining things to a small child.
> "Type inference actually makes some sense in languages > like JavaScript and PHP that are built around this, and > had this feature from day 1." > > I'm surprised to see that comment repeated without > question - does either JavaScript or PHP have type > inference?
I think what he may have meant was that those languages have a weaker type system, and thus it's already not necessary to specify type for local variables for JavaScript and PHP.
I don't know how type inference would work for the current version of JavaScript, but the next generation JavaScript provides optional static typing. Type inference may be quite useful for that language since you could program without specifying types but still ask the compiler to produce a strongly typed program.
At the same time, I personally like specifying types in source code, since it makes the code all the more explicit. (I have to say, though, it's easy to get used to loose typing when coding in, say, Ruby...)
I'd like to see a vote on whether Java developers want the language developed. It seems to me that (1) the development of Java is inevitable because of its sheer momentum, and (2) the interesting people in the industry (many of whom embraced Java for its first decade) simply aren't interested anymore. I bet the effort required to further develop such a big, old, established language like Java could fund the development of 10 industrial strength Scalas, which would have a far greater impact on what's possible on the JVM and coding in general.
> > "Type inference actually makes some sense in > languages > > like JavaScript and PHP that are built around this, and > > had this feature from day 1." > > > > I'm surprised to see that comment repeated without > > question - does either JavaScript or PHP have type > > inference? > > I think what he may have meant was that those languages > have a weaker type system, and thus it's already not > necessary to specify type for local variables for > JavaScript and PHP.
Do you think that follows from what he wrote? Considering what he wrote, maybe he simply doesn't understand what type inference does.
You can often find this pattern in the programming domain: Someone invents a new, simple language (Java, C++, SQL, XML, ...) or library which becomes a success. But then the 'experts' and 'gurus' chime in, diagnose 'shortcomings' and 'omissions' and demand all kinds of 'improvements' and 'extensions'. In the end, the simplicity and usability of the original approach is gone and people abandon it. This pattern is so common that the few notable exceptions stand out: e.g. 'classic' C, also Python and Ruby which explicitly target simplicity and programmer friendliness.
People often forget that code is both written and read. In large applications, like the ones for which java is so popular, a lot of time is spent on maintaining and building atop of existing code. I'm sure many people would agree on the fact that more time is spent maintaining source code than developing it from scratch. Type inference for java could probably reduce the time it takes to type a method, but it would give us little else. When writing a method I should be forced to know what return types I'm dealing with, later on it should be obvious to me from looking at the source what the method does and what the types are. I shouldn't have to look at return types in other classes just to understand what a method does. The proposed feature reduces readability and therefore maintainability will suffer.
I'm sure the feature is appealing for small programs and for languages that are primarily used for small applications. Perhaps what we're seeing here is another sign of the need for specific languages for specific target domains. I personally don't believe that there can be a single language that is the most suitable for any given task.
I think the original writer is confusing dynamic typing with inferred typing. Javascript doesnt have type inference, but it does have dynamic typing.
At its simplest, type inference saves keystrokes:
Dictionary<Foo<Bar,Baz>,Bonk<Zoink,Zargh>> dict = new Dictionary<Foo<Bar,Baz>,Bonk<Zoink,Zargh>>();
Anyone see anything wrong with that?
Consider:
var dict = new Dictionary<Foo<Bar,Baz>,Bonk<Zoink,Zargh>>();
Where var tells the compiler to figure out what the type of 'dict' should be. Its strongly typed; once the type is decided by the compiler, you cant assign any other types to 'dict'.
Personally, I think the original writer doesnt know what hes talking about, has never used type inference, and is basically a back-slider.
Looking back, its hard to understand why anyone would release a programming language without generics. In a few years time, we will look back and find it hard to understand why anyone would use a strongly typed programming language without some degree of type inference.
> When would the IDE convert auto into HashMap? > > If it was done in the IDE what would happen if for some > reason there happened to be a class called auto that > happened to inherit from HashMap? >
Although I used 'auto' for illustration purposes, I do not think that anyone would name a subclass of HashMap as 'auto'. But if that is the issue, it could be done with another keyword, perhaps a symbol not used by Java. For example:
$ map = new HashMap;
Flat View: This topic has 36 replies
on 3 pages
[
123
|
»
]
Previous Topic
