Reinier Zwitserloot, you are correct regarding inter-version compatability. I just think there was some confusion.
Kevin, "[C# tuples] can be stack-allocated, and elements inside such a tuple don't need to be boxed. This is a *significant* difference!" .NET tuples are reference type classes, not structs. AFAIK, they can not stack allocated. Sure, C# can use primitives without boxing, which is the generics issue we talked about separately. Russel, "tuples in Python are great." Python and Scala and many others have full proper tuple syntax and integration. C# and Java do not. C# has several advantages over Java, but I don't think this is one of them. "The average Java programmer doesn't actually care as long as they get paid." I don't think you can single out Java in this regard. This probably applies to most salaried employees to some extent. "Are you sure int[] goes "much faster"? Define "much"?" Ok, I will try this out. Simon, "The issue at least in Java is that arrays don't work well with pretty much any other language feature. They are no collection, they don't interoperate with Generics, they don't follow the variance rules, etc etc etc. I don't want to use a feature which most Java designers/JVM engineers consider more or less deprecated." Scala addresses this point far better than C#/Java. Scala provides Array[Int] which performs identically to Java int[] but integrates with the rest of the language as you describe. I've personally benchmarked Scala Array[Int] and found it performed equivalently to Java int[]. Kevin, "Without extractors, pattern-matching, some form of flatMap/bind operation, etc. the lambdas in Java 8 are a level of abstraction below Scala and LINQ. And that's before we even start considering Futures, Options, etc. which can also take advantage of the same monadic operations." Java 8 has a flatMap. So does C#, but it is called SelectMany. Java also has a Future class. Option is a whole separate issue and on that Java/C# use plain null while Scala/F# use Option. You are all over the place. Simon, It sounds like you are saying that LINQ solves external database integration better than JPA/Hibernate (I completely agree). But LINQ isn't really much different than ECMAScript or Java 8 or Scala for local functional collection processing. "The Java ecosystem is notorious for sucking at coming up with standards and requiring people to come up with their own solutions. This used to apply at the framework/library level, now it has expanded to the language level. That's great for hobby projects and cultivating intellectual curiosity, but most medium sized companies/organizations require standards and long-term trustworthiness. Unfortunately, this pushes companies over on .NET and Windows, especially when they get fed the integration (SharePoint, Axapta/NAV etc.) sales pitch." "In the end, I think the .NET people are a bit more oriented towards getting things done, because Microsoft gets things done." There are the worker, builder, "git 'er done" types: immediate, concrete, tangible, simple results. There are the intellectuals: long learning curves, more abstract ideas, more about finding better ways of doing things and innovation rather than merely churning out quantities of work tickets. I'm trying to move more towards the latter group. -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/lNX2naWgYSIJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
