Hi clay,
- Better Generics: Java lacks reified generics in that it discards type
> info at runtime. I agree that this is a deficiency of Java, but the
> practical consequences of this seem quite obscure.
>
The practical consequence is that for example an ArrayList with one million
doubles takes up 28MB instead of 8MB (and that's just on a 32bit VM). While
some might argue that RAM can be considered infinite these days, CPU cache
sadly isn't. Imagine the performance improvements if an ArrayList could
guarantee that its values are stored in one chunk! I certainly would prefer
living without > 70% memory overhead for the simplest use-cases (it gets
much worse with stuff like Tree{Set,Map} or collections of
ConcurrentHashMaps).
Sure C# can do List<int> faster than a Java List<Integer>, but int[] goes
> much faster in both languages, and most super performance sensitive code
> uses that. Other language features have more tangible benefits.
>
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.
> - Properties: The getter/setter practice of Java is horrendous. C# has
> first class properties which is better. Scala is even better, in that it
> eliminates the getter/setter boilerplate and doesn't even need a special
> property mechanism, you can just use val/var/def.
>
Pretty much agree.
> - Unsigned integers: I know there are some use cases, particularly in
> hashing and cryptography, where you really want a 32/64-bit unsigned int.
> Java 8 has library functions to address this which can hypothetically be
> properly optimized to give full performance benefit. It's still slightly
> nicer to have native unsigned primitives in C#, but practically Java 8 is
> fine.
>
Yes, I don't care about them too much.
The above three, to me feel like tired language wars points, by people who
> are already emotionally dead set of liking C# and hating Java,
>
I don't really have any opinion about that. Java is conceptually a much
nicer, smaller, simpler language, but if I had to get work done (and
everything else wouldn't matter), I would choose C# immediately, because it
is much more pragmatic about getting things done.
> but in reality, these points don't have large practical implications and
> are trivial to work around.
>
The missing struct/reified generics issue can't be worked around at all,
and the consequences are huge.
- Tail Call Optimization: OK, this is important and Java is behind on this
> one. Scala has this however.
>
Not really. Or more precisely: Only in some limited cases known at compile
time. If you don't want to fall back to trampolining (and suffer from poor
interop and performance) you really need VM support for this.
Considering that Schwaighofer already implemented it for interpreter,
client _and_ server compiler while preserving the existing security
mechanisms years ago and that the patchset was even updated to track JVM
changes (as far as I remember) I really wonder how far down it lives on the
priority list.
Nevertheless, it is possible to live without it. In the beginning, the CLR
did have some pretty severe restrictions on TCO, too.
> - Tuples: I looked at the new .NET 4.0 tuples in the standard library, and
> those aren't any different than any third party tuple library on Java.
> Scala and others have more native, language level tuples.
>
The issue is that there isn't any standardization around it in Java, so its
use is pretty much restricted to isolated islands. Same issue with function
types.
> "On the Java side, we have bizarro bullshit approaches like JDBC, raw SQL,
> code generation, JPA, and a ton of other ugly, half-assed non-solutions to
> problems which shouldn't have existed in the first place."
>
> Tons of Java technologies were terrible in hindsight or have been replaced
> by something much better. The .NET landscape is absolutely no different. In
> my personal experience, Java devs are more quick to say, the official
> product is bad, let's use something better, while .NET developers are more
> likely to stick with and defend the official product.
>
I guess the difference is that Microsoft listens to feedback and is open to
considerable improvements and changes to their libraries without needing
tons of people telling them exactly that for years. See for example how the
Entity Framework came to live and where it is now. The disadvantage of that
is that it sometimes looks like as if Microsoft reinvents their approach to
e. g. ORM every second year. They move fast and they leave people behind,
and they are not really upfront about it.
Apart from that, there are also alternatives like Dapper, NHibernate, etc.
which interoperate quite nicely where it matters.
> - LINQ: I've used LINQ when I was doing C#, but I am no expert. Could you
> articulate what this does better than Java 8? Is it really years ahead?
>
The issue is that Java is missing the infrastructure in the compiler to
lift the closures to an AST representation for further processing. Without
this, it is hard to translate the arguments given to the collection methods
to SQL or some other representation.
You could probably write some tool to analyze the generated bytecode, but
tooling would suffer from that. C#'s LINQ isn't perfect though, because the
lifting is shallow, which means that for instance references to external
methods will fail at runtime (as far as I remember) because no lifted
representation exists/was generated for them. That has a certain impact on
re-use, but LINQ is still magnitudes better than the burning trainwrecks of
JPQL or the Criteria API.
One of the seldom glimpses of sanity I have seen in the Java ecosystem
lately was JOOQ, which relies heavily on code generation though.
> Most LINQ examples I see on the Internet can be translated into Java 8's
> functional collections (I'm not sure about join type operations) and the
> latter syntax is more intuitive/natural. Also, for external database
> access, typesafe's slick looked like a better solution at a superficial
> level (I haven't actually had the chance to use it yet).
>
Yes, Slick does a lot things right and has all the necessary infrastructure
available to also solve the rest properly, but imho there is still a long
way to go. Nevertheless, I'm still waiting for type macros, because it's
2012 and I can't seriously imagine that I'm writing code to describe
database tables (or use code generation) when the database has _all_ the
necessary information already available. I guess this will be the next case
of bigotry where some mechanism to solve a huge, real-world issue is
perfectly fine in one language (F#) and totally "OMG so complex!!!!!!!" in
another (Scala). :-)
> - F#: I haven't used it, but I've heard great things about F#, and I
> suspect they are right. This sounds like a more academic, thinking man's
> programming language and that's not what the typical Joe C# dev wants. I've
> talked to several C# exclusive shops and interest in F# was very low.
> Secondly, I couldn't get this running on Mono on my Linux dev system and F#
> clearly isn't the Mono team's priority. On Microsoft forums, most people
> said to just use OCaml if you don't want to set up a Windows VM. Ocaml is
> on my todo list, along with deeper forays into Haskell, but if F# is just a
> .NET flavor of Ocaml, I can just stick with the latter.
>
Yes, that's my impression, too. I also had issues getting it to run on
Mono. I guess it gets a bit more easier after the 3.0 release.
It is impressive to watch how they manage to ship useful, practical, but
conceptually advanced features without anyone declaring Jihad on them. I
really wish something like this could be pulled off in the Java ecosystem...
(Some of the stuff is also a bit scary though, like the possibility to use
inline CIL bytecode instructions in source code.)
> In my observations, even Java developers hate Java :) Or are at best luke
> warm about it. The last problem in the Java community is over-confidence :)
> There are several people in this Java forum who constantly talk about how
> terrible Java is. I don't see anything close to that type of self-loathing
> over on C# forums and I don't think that's due to product quality.
>
But on the other side, you just saw how some people try every tactic
possible to shut constructive discussion down on this list. :-) In the end,
I think the .NET people are a bit more oriented towards getting things
done, because Microsoft gets things done. But we are stuck with discussing
the same thing over and over because on the large scale, big O didn't get
much done apart from incrementing version numbers.
Nice day!
Simon
--
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/-/_4BPp9CM1XsJ.
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.
