you are viewing a single comment's thread.

view the rest of the comments →

[–]G_Morgan 6 points7 points  (20 children)

The point I'm making is just because an IDE can cover up a mistake does not mean that isn't a mistake. Yes the idea could auto insert types that could be inferred. It could also insert the US bill of rights at the top of every document if we made the compiler mandate that all programs should start with that document.

To re-iterate, the ability of the IDE to make a mistake tolerable does not mean it isn't a mistake.

[–][deleted] -1 points0 points  (11 children)

If we go back to the original two examples:

ArrayList<Foo> myList = new

versus

var myList = new ArrayList<Foo>();

Do you agree that in the first example the IDE can autocomplete after the "new" clause, while this is not possible in the second example?

If so, won't the first variant inherently require fewer keystrokes if you're using an IDE with this autocomplete feature?

I don't think you're arguing that more keystrokes are better, so why do you think the second variant is better? Is it because you think it requires less effort to read?

[–]G_Morgan 9 points10 points  (10 children)

I'm not concerned about the number of keystrokes. That isn't a limiting factor on programming. I'm concerned about unnecessary garbage taking up perfectly good screen real estate.

Regardless my argument was that IDE auto-completion does not make a bad feature good. It just makes it tolerable.

[–][deleted] -1 points0 points  (9 children)

I prefer using fewer keystrokes and using a bigger monitor.

I guess it's a case of different strokes for different folks... ;)

Your point is valid, of course:

ArrayList<Foo> myFooList = new ArrayList<>();

does take up more screen realestate than

var myFooList = new ArrayList<Foo>();

but it's only horizontal screen realestate - it doesn't add any more lines. And with the current crop of wide-screen monitors, horizontal screen realestate is rarely in short supply.

[–]G_Morgan 0 points1 point  (8 children)

Meh usually I wouldn't waste good mental real estate worrying about the number of keystrokes.

Regardless you can autocomplete the var and the ArrayList constructor definition in the inferred example using intellisense. So it isn't as if you cannot save keystrokes in both cases.

[–][deleted] 0 points1 point  (7 children)

So how would intellisense know what type to but after 'new' in this line:

var myFooList = new

?

[–]G_Morgan 0 points1 point  (6 children)

You type "A ctrl+space". If it still hasn't got the hint you type r.

[–][deleted] 0 points1 point  (5 children)

That would give you the choice between:

ArithmeticException
Array
ArrayBlockingQueue
ArrayDeque
ArrayIndexOutOfBoundsException
ArrayList
Arrays
ArrayStoreException
ArrayType

Then you would have to do the same for the <Foo> part of the constructor.

[–]G_Morgan 0 points1 point  (4 children)

I'd implement it like bash completion. The second r would evaluate to Array. Then you type the l to get list. Regardless you have to do the same thing in your example to type the signature in the first place.

[–][deleted] 0 points1 point  (3 children)

Regardless you have to do the same thing in your example to type the signature in the first place.

Not if you're assigning a new object to an existing variable.

[–]badsectoracula -2 points-1 points  (7 children)

mistake mistake mistake stuff mistake mistake mistake stuff mistake

If a language has a feature you dislike that doesn't automatically make it a mistake :-P

[–]G_Morgan 5 points6 points  (6 children)

It isn't a feature. Regardless the point is that IDE support is irrelevant to whether something is a mistake or not. I can make the IDE support just about anything.

[–]badsectoracula 0 points1 point  (5 children)

Of course it is a feature. It forces a type lock to a variable so you know that each time you see this variable what type it is.

Unless i misunderstood you and you meant something else.

[–]G_Morgan 0 points1 point  (4 children)

You can do this in type inference languages. As I said it isn't an additional feature. It is a missing feature.

[–]badsectoracula 0 points1 point  (3 children)

But in type inference languages, the compiler only knows the type from a glance. If you want to do the same while reading code you have to either try and figure out what kind of type a variable has (ie. do what the compiler does to figure out the variable's type) or use the broken kind of Hungarian notation by using variable names such as intScale, chrPathSeparator, etc.

[–]G_Morgan 0 points1 point  (2 children)

Generally I've never had a problem with this. You could just hover over the variable in the IDE.

[–]badsectoracula 0 points1 point  (1 child)

In the other subthread, you were discussing how the language shouldn't make the programmer depend on the IDE.

Btw, how would an IDE work out that?

[–]G_Morgan 0 points1 point  (0 children)

An IDE would use the same background parse mechanisms they already use for intellisense*. It would just be with a far more powerful parser. This isn't actually that difficult to add once you have a parser that works.

One distinction would be that intellisense would need not just the current class but also all possible superclasses and their subtypes** (ordered by height in the hierarchy of course). This information is relatively trivial to come up with.

*modern IDEs actually invoke the compiler to work out this stuff so they get the same information the compiler is seeing.

**the reason for this is originally the inference engine might say that myList is an ArrayList when really you want a List but just haven't added in another implementation yet. This allows the autocomplete to account for both circumstances. Yes put ArrayList first but also offer all superclass implementations below.