On Wednesday, October 24, 2018 at 11:59:34 AM UTC-4, robert engels wrote: > > When Java came along there was a heavy sigh of relief by ISVs that > understood write-once, and it will continue to work even as mega company > released new OS versions and APIs - the burden was on the JDK/JRE > implementation to make sure it worked - not the business. The write-once > run “anywhere” was icing on the cake - it opened doors to some markets very > cheaply. > [snip] > I think Go would be best served by ensuring that any future release is > 100% backwards compatible with previous releases. This is the number one > aspect of Java (IMO) that lead to its success - it drastically reduced the > churn/expense of delivering software. Businesses like this…. Developers > like this... >
Actually, Java never delivered on the claimed "write once, run anywhere" idea. Its simply not feasible unless you restrict the domain to a small subset, say command line utilities that take arguments and switched from stdin. Smalltalk also claimed this, in a more general, GUI environment. It too failed to deliver. Decades before, COBOL was an attempt to do this. the "C" in COBOL stands for Common. IMHO, its impossible to design a language to deliver this run anywhere idea when we have no idea how future user interfaces will work. For a couple of decades, punched cards were a near universal UI. Then command lines, then GUI with mice, pointers and windows. Clearly touch and voice are hot topics today. I expect some sort of mental telepathy will be hot in the future. 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. -- 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.
