That is a different argument entirely. That you have a team of competent Go developers that are productive in a few weeks is a point against generics in Go at all (which is where I am now).
And that was my original point, is that outside of type-safe containers, MOST generic code is not needed, since in these cases a specialized type-safe data structure will almost certainly be easier to use and test for the upper layers, and/or understanding the generic code (or contracts, et al), and is probably not worth the effort. As for the tutorial, maybe I wasn’t clear, but I was trying to show that the core is understandable in a few pages, and yes, the edge cases are more involved, but almost never does anyone in common code encounter these, and if they are not writing common code, they probably have the experience/education/intelligence to understand the edge cases easily. As a bad anecdote, you can peruse StackOverflow, and very rarely are there any “how to use Java generics”. The only constant questions are “difference between ? extends and ? super” and these are not typical use cases. I think think if people started taking the position that Go is basically C with managed memory and no pointers and that is all, Go and the world would end up in a better place. Stop trying to make Go something that it isn’t. Square pegs, round holes, yada yada yada... > On Oct 26, 2018, at 11:27 PM, Burak Serdar <bser...@ieee.org> wrote: > > On Fri, Oct 26, 2018 at 9:32 PM robert engels <reng...@ix.netcom.com > <mailto: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 > <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 >> <mailto:golang-nuts+unsubscr...@googlegroups.com>. >> For more options, visit https://groups.google.com/d/optout >> <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 > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <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.
