Quoting robert engels (2018-10-26 23:31:46) > OK, you got me, I'm sucked in - it was a nice balance of yes, BUT no. > > First, there is simply no debate, Java += Android, and you have the > most successful language/platform ever. NO debate. > Arguing against Java's write-once, run anywhere implementation is a bad > position to take. Yes, if you write a "swing" app, it doesn't run on > Android (at least not easily), but that is not what the promise of > WORA. Any system that has an "exec command" cannot make that guarantee. > In the "real world" the promise was delivered on - at least in > comparison to any competing technology. C may be the "most portable" > language ever, but I can write GUI applications in C that have zero > chance of running on multiple OSes. The position is simply invalid. > Arguing against Java in terms of "generics are done poorly",
I'll leave you and Pat to debate this; I don't care all that much. > and citing a third-party FAQ is absurd. This is a fair complaint. The linked FAQ seems rather verbose for its content. > The "core" Java tutorial on generics is a 3-4 pages, Which tutorial are you talking about? The tutorial on Orcale's website is decidedly longer than that: https://docs.oracle.com/javase/tutorial/java/generics/index.html > Claiming students have a problem is akin to saying, "my child was great > at finger paints, but is having a real hard time with differential > equations. Differential equations must be broken". > Are there rare edge cases in Java generics, yes. Do they come into play > in any sort of real-world frequency, no. The problem was not "students have a hard time understanding the concept" so much as "students come to me to ask for help debugging code that is throwing this weird specialized exception that they've never heard of. It's something that should always have been a compile time error, and *not* fixing it makes the language more complex. (It also hurts perf to do the runtime check). NullPointerException is pretty easy to understand too -- that doesn't make it not a source of bugs. > The statement, "Happily, Go doesn't have sub-typing in the first > place", shows the bias. I don't think Go needs sub-typing either - but > I wouldn't use Go in many places I would use Java where sub-typing is a > huge benefit. If you wish to debate the value of OO, please start with > someone other than me, because I will just say, I've done it a lot of > ways, and good OO where it applies is better than any of the > alternatives. Others may have more nuanced opinions. This wasn't meant to be a criticism of subtyping; I was just making the point that we have an easier problem to deal with, because we don't have to worry about interactions between the two. > And not to pick, but "type erasure makes runtime checks not work", is > blatantly false. I hope you meant to say "compile time checks", but > still, in the real-world, it is not an issue. This was in reference to the fact that in Java you can't e.g: * Have arrays of a parametrized type (e.g. Foo<String>[]) -- the runtime check that throws the ArrayStoreException can't work without having the type information available at runtime. * Have exceptions with type parameters -- the dispatching of exceptions is on the type, so this doesn't work if you erase the types at compile time. IIRC there were a few other examples in there. > I think this might be an ivory tower issue. It doesn't seem pure to > some, so it must be bad. This is some combination of ad hominem and straw man. > I'll end with an anecdote from the construction industry. > When laying a deck, you can try to be very accurate and cut all of the > boards to the same length, or you install them, and use a straight edge > to cut off the ends to exact same length. Real world vs. academia. No > experienced carpenter would do it the first way. ..and yet you seem to be the one advocating never fixing things once they're in the field? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
