If they can also do something about closures, I'll be much happier as a Java developer when this comes out than I am today.

I'm trying to understand why the collections syntax would create only immutable collections? Anyone know why so?

The collection literals are nice too, but why couldn't they infer the type from the following?

  Map<String, Integer> map = {"key" : 1};

  Map<> map = {"key" : 1};

It's kind of trivial in your example, but with complex objects that implement a lot of interfaces it isn't as obvious what the programmer means.

Since you can always make it specific what you want, you can assume that the most common case is the "default". That's what c#'s `var` does anyways - if you have a `var a=1;`, 'a' an int, not an object. If you use `var a=new []{1,2,3};`, it's int[], not object[].

I know of none ... Ocaml uses a special syntax for reconciling the type-inference with the inclusion polymorphism that it supports ... (name : sub_type :> super_type). And IMHO it gets ugly.

I'm not really clear about what "type unification" you're referring to, but the actual types in Java aren't known until runtime (you usually only know a parent). To change this behavior an overhaul of the entire architecture is needed.

C#

Not "type-inference" in the very general sense, just "type-inference" in the "when you see 'var someVar = 3;' you can infer that someVar is of integer type" sense. Which is what java is doing again. Playing catch-up to c#.

Map<String, Integer> m = new HashMap<>();

Which is ugly, but many Java developers are taking "programming to an interface" rule quite literally.

D, C++0x

This thread was talking about type inference in this case ...

var l = [12.4, 13, "a string"];

This would require the array to have generic arguments, and those generics arguments to be inferred from the types given to the constructor (in this case the base class would be Object). I think it works in Scala, but a type unification is really hard ... i.e. to be able to write your own generic functions / classes with the generic type inferred from the base class of the given arguments.

The definition of a generic function that would do this would look like ...

Array<T> createArray<T> (T ... args)

Also, since generic definitions are a PITA to write and read, many people dream of a Hindley-Milner type system where the generic type is discovered. But I don't know of a single OOP language that does that (Ocaml and F# try, but it's ugly) since OOP polymorphism is not compatible.

I was thinking specifically of the example in C# where you can do something like:

  var list = new[] { "hello", null, "world" }

It just seemed like these collection literals would be good candidates to use the new type-inference capabilities they're rolling out.

Yes, this is a really stupid feature of the language.

http://kenai.com/projects/duby

It uses Java types, doesn't need a runtime, and most interestingly, has a pluggable compiler. The Ruby-like syntax may not be to everyone's taste, but it's nicely compact.

(note to self for own project: make samples very accessible)

  Current -> MyProg_1.8.9
  MyProg_1.8.9
  MyProg_1.8.8
  MyProg_1.8.7

Hard-links would also be a nice addition. I am sure NTFS supports them deep inside it.

As far as I can tell, reparse points for directories will usually work perfectly well for most of the things you'd expect them to. I use them, and a subversion repository to version control pretty much everything config related on my windows machine.

Also, could you explain some more. Why do you think that they're "atrocious hacks"? They solve some problems in a quite nice way (simple versioning for example)

here's bind(2) man page, in case you're interested in learning some 20 year old technology http://plan9.bell-labs.com/magic/man2html?man=bind&sect=...

PS. This does not mean that bind is {better/worse/useless/deprecated/teh-win}. `mount -o bind` on linux exists and is not replacing sym/hard-links anytime soon.

  Set<String> mutable = new HashSet<String>(immutable)

The first thing people are going to do with these half assed immutable collections is pour the contents out into a mutable container. Which completely obviates all the thread safety and whatnot.

I slap my forehead. Do these people have no sense?

  List<String> list = new ArrayList<String>();
  list.add("item");
  String item = list[0];

I guess I was thrown off by the wording- I assumed the line about collections being immutable applied to all collections that use the new syntax.

This proposal was just rejected in Go, alas.

What a readability difference it makes in Ruby, Eiffel and (originally) Ada.