On Fri, Oct 26, 2018 at 9:32 PM robert engels <reng...@ix.netcom.com> wrote: > > 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”, and citing a > third-party FAQ is absurd. The “core" Java tutorial on generics is a 3-4 > pages, and almost every Java developer never goes beyond that. 99.9999% of > Java generic use cases are self explanatory or explained in a matter of > minutes to anyone with any development experience.
You seem to agree that Java generics work only "most of the time". If you limit yourself to existing collections and stay away from arrays at all costs, this is almost true. However, if you're writing code that does more than moving data from here to there, you get into some edge cases that simply require you to redesign your code to make generics work. The simplest example I can think of is the fact that new T() won't work. Also, the generics tutorial is not really that short: https://docs.oracle.com/javase/tutorial/java/generics/index.html Just to clarify, I have too much code written in Java, and I like the language. I agree with your comments about WORA. However, I also witnessed that a team of developers with no previous Go exposure became competent Go developers in just a few weeks, and now writing rest apis calling databases at the backend. Most Java developers, on the other hand, simply use generics in the context of type-safe containers and avoid writing generic code altogether. Java generics work for most because of avoidance, not because of ease or utility. > > 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 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. > > 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. > > I think this might be an ivory tower issue. It doesn’t seem pure to some, so > it must be bad. > > 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. > > > > > > On Oct 26, 2018, at 9:20 PM, Ian Denhardt <i...@zenhack.net> wrote: > > Quoting Pat Farrell (2018-10-26 21:30:47) > > This leads to my second issue with the OP's ideas. I strongly believe > that Java has been damaged by its attempt to deliver backward > compatability. While others have brought up the potential issues with > keywords, a much more telling disaster was Java's implementation of > generics. It was done in a language compatable way, but there result > was design choices and restrictions that make it nearly impossible to > use Java generics "properly". Lest you think I exaggerate, look at > Exhibit 1, the FAQ on how to actually use it is huge. It has hundreds > of edge cases. See > FAQ.� http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.html > If the implementation had decided to not require backwards > compatibility, they might have been able to design generics such that > there is no need for thousands of special case rules that are > Frequently Asked. > > > Definitely worth nothing: there *pages* in that FAQ that could have been > cut if they'd just removed covariant array subtyping, to be consistent > with the rules for generics and (more importantly) actually sound. > > For anyone who doesn't know what I'm talking about: > > class Main { > public void main(String[] args) } > String[] strArray = new String[4]; > > // Arrays are references, so this points to the same > // memory: > Object[] objArray = strArray; > > // Whoops, now there's an integer in your array of > // strings! > objArray[0] = new Integer(80); > } > } > > This type-checks. It throws an ArrayStoreException at runtime. I do not > miss explaining ArrayStoreException to students. > > It also seems like 25% of the FAQ amounts to "type erasure makes runtime > checks not work." > > I don't know of any mistake in Go 1 that's quite as egregious while > being and quite as easily fixed -- but I agree we should keep our eyes > out for designs that are becoming far more complicated for the sake of > backwards compatibility. > > --- > > It is also worth observing that the Java developers were attacking a > much harder problem in adding generics to Java that we are trying to add > them to Go -- subtyping and parametricity have very subtle interactions, > and finding satisfactory ways to mix them has been the subject of a lot > of type-theory research over the past few decades. Prior to the past > couple of years, I would have just advised someone designing a new > language to punt on one feature or the other entirely. I might still, > but there have been a few developments of late that that are > encouraging. Good luck bolting them on to an existing design though. > > Happily, Go doesn't have subtyping in the first place. > > (there are a few minor things that look like subtyping at first glance, > but I suspect they don't present a problem. It's hard to not be > a bit handwavy here since the language spec is not mathematically > precise wrt the type system). > > -- > 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. > > > -- > 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. -- 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.
