I never made any claims about anyone else. I only presented my opinion that backwards compatibility is a requirement for success.
WORA was not a huge factor in Java’s initial success IMO. There was only a single dominant OS and all others combined made up a tiny fraction of the market. Linux was starting to get some traction and visionaries could see the value in WORA but it certainly wasn’t mainstream. If anything WORA helped Sun not ISVs. If a new app was written in Java it had a much better chance of being available for Solaris which improved Suns position. You are completely correct about the compatibility guide. Funny though, in 20 years of Java I had never read one. I read the 4 and 5 and 6 ones and the number of breaking changes is insignificant. With Java 8 as expected, things have started to change. Maybe my aversion to radical change in Go is based on my position that things have gone off the rails with Java. Gosling knew what he was doing when he created it, and now marketing and lesser minds or different interests are controlling it, leading to problems. It feels that the same is starting to happen in Go... where niche needs start controlling the process. The difficult life was due more to continual API changes, not language changes. The comment that you failed to address is the OS/services lifespan and tools like Linux. Again, still C89. This is the sweet spot for Go IMO so the backwards compatibility is more important. Next thing Gophers will be crying for is lambda syntax... just wait. > On Oct 28, 2018, at 6:55 AM, Henry <henry.adisuma...@gmail.com> wrote: > > There are fallacies in your arguments. > > First, you argue that Java is successful because it is backward compatible > all the way back to version 1.0, both in source and binary compatibility. > Therefore, if Go is to be just as successful, Go must do the same. > > Second, you assume that people who disagree with you are in the "no backward > compatibility" camp. > > Third, you rant about having to constantly update and rewrite your code prior > to Java. > > Let's get back to those points. Java is not the only successful language. > There are lessons we can draw from C and C++ too, which -despite their age- > are still very relevant in today's world. > > To claim that Java is popular because it is backward compatible is just > wrong. You are giving too much credits to backward compatibility. Java > success is a combination of many things, including the heavy push from Sun > which I mentioned earlier. Sun invested tons of money into Java. Putting > aside the business aspects of Java, one technical merit of Java that you > failed to mention as being contributive to its success is portability. In > fact, Java is marketed as the "Write Once Run Everywhere" language. Although > we know it is not 100% accurate, Java is -in a way- portable. It saves > companies tons of money from having to write different code for different > platforms. > > Your claim that the current Java is 100% compatible with Java version 1.0 is > just wrong. Every time a new JDK is released, there is a compatibility > document, which lists the various incompatibilities with the earlier versions. > > The binary compatibility part isn't relevant to Go. > > If you were to re-read the earlier posts, people who disagree with you don't > necessarily advocate "no backward compatibility at all". They just don't > agree that backward compatibility should go that far back. If Java don't even > make a 100% compatibility guarantee with their version 1.0, why should Go? To > me, Go 2 being backward compatible with Go 1 is still acceptable, but Go 11 > being backward compatible to Go 1 is not necessary (You were using Java > analogy: the current Java is 11 being compatible with Java 1). > > Last, I don't remember life was that difficult prior to Java. Backward > compatibility was not Java invention. Many languages back then were already > backward-compatible in a reasonable way. The major libraries were quite okay > in my opinion. To me, the major value that Java brought was portability. > >> On Sunday, October 28, 2018 at 11:47:19 AM UTC+7, robert engels wrote: >> I think arguing that marketing was the cause of the proliferation is not >> accurate. Marketing helps push technology, see big mega company, but in the >> embedded space since the consumer does not “know what’s in there” it matters >> far less. Java proliferated substantially on technical merits. Writing “UI >> interfaces” for desktop cable boxes and VCRs was too error prone and costly >> (in time) - Java made this straightforward, if not trivial. >> >> There is a a reason that big mega company eventually copied Java’s design, >> and platform for their own products - it was technologically superior to >> what they had. >> >> I can only think of 2 major language changes in Java - generics/enums in >> 1.5, and lamdas in Java 8, and both were backwards compatible from a binary >> perspective and almost completely at the source code level. People keeps >> saying “only trivial 1.0 programs would work”. That is just not true. If you >> didn't use private apis (e.g. sun.*, or com.sun.*) it is going to compile >> today and run today. >> >> As a person who lived through the constant update and re-write cycles of the >> past, backwards compatability is not to be discounted. Pick your favorite >> library, then imagine the API changed completely every 6 months, would you >> still continue to use this library? You would either find something else, or >> stay on the old version. >> >> I am not stating that Go proposes to change every 6 months - it is an >> exaggeration (I seem to need to point these out) - but the acceptable >> timeframe varies - based on resources, profit margins, etc. as to what >> constitutes “worthless churn”. If Go is going to be used for instrastructure >> systems (and OSes?) it needs a REALLY long shelf life - these are not >> systems that are going to be continually changed… For example, the Linux >> kernel is still C89 AFAIK… (commit) >> >> Btw, the additional keywords added after Java 1.0 through Java 11, 20+ years >> later: >> >> enum strictfp _ (underscore) >> >> >> >>> On Oct 27, 2018, at 11:08 PM, Henry <henry.ad...@gmail.com> wrote: >>> >>> You need to remember that Sun spent a lot of money into Java marketing. >>> They aggressively pushed Java into every device, from servers to >>> refrigerators and toasters. No company to date has ever done what Sun did >>> with Java. So it is wrong to conclude Java is popular due to its technical >>> merits alone (or in this case, due to backward compatibility that goes to >>> back version 1.0 - which isn't true anyway unless it is a very simple >>> program). In fact, Java is now a highly complicated language rivaling C++. >>> They both have one thing in common: extensive backward compatibility. They >>> often implemented new features in a backward compatible way, creating >>> unnecessary complexity - which then accumulates as technical debts over >>> time. Backward compatibility is good, but it has to be reasonable and >>> limited. Otherwise, they will impose unnecessary constrains for the >>> language development. >>> >>> Having a compiler that can build older versions is good, but as I said, it >>> has to be reasonable. If the source's version is too ancient, it is easier >>> and simpler for the users to just download the older compiler and build. >>> There is no need for version annotation and you have less maintenance for >>> the current compiler. >>> >>>> On Sunday, October 28, 2018 at 5:40:23 AM UTC+7, robert engels wrote: >>>> As others pointed out, this was not true when ‘enums’ were added, but >>>> still the Java compiler has always supported compiling using old version >>>> constructs. In the case of enums it was binary compatible. >>>> >>>> I think Ian’s proposal on the comment build flag to specify the language >>>> version is a good one. I think you might need to also be able to specify >>>> the language version in the mod file for legacy modules you don’t want to >>>> edit/maintain (as they wouldn’t have the per file comments either). >>>> >>>>> On Oct 27, 2018, at 5:29 PM, hay <habiba...@gmail.com> wrote: >>>>> >>>>> "To this day, you can take a “binary” written for Java 1.0 and it will >>>>> run under the latest JRE. You can compile Java 1.0 source code with the >>>>> latest compiler. This is an amazing accomplishment that can’t be >>>>> understated." >>>>> I've concern about this. This kind of guarantee might prevent needed >>>>> changes in the future version. In my opinion, backward compatibility >>>>> guarantee by major version is best approach. For Go 2 and Go 3 developers >>>>> should change their code if it breaks. >>>>> >>>>> -- >>>>> 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...@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...@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.
