6 ms·

Whatever people find unacceptable about Java could've been fixed. No need to burn it all down and start over. Remember, I'm talking about "source level" syntax

Whatever people find unacceptable about Java could've been fixed. No need to burn it all down and start over. Remember, I'm talking about "source level" syntax of the language not any specific VM implementation. Every compiler and VM can be replaced eventually. It's the code syntax that needs to be "universal" not anything else.

manigandham 6y ago
That's what Scala and Kotlin are, fixes for the original Java flavor. Then again, more alternatives are good for competition; and incubating and sharing new designs that aren't possible in a very old language.
- lumost 6y ago
  barring competition languages seem to stall out over time. Java fell out of favor because every java app turned into a pile of xml and factories that everyone hated and was slow to develop. The faster evolution of peer languages allowed for recognition of what people didn't like in Java (The ceremony of getting setup and invoking "app" logic). The better parts of Scala, kotlin, and the guava library are steadily making their way into the language. But if there wasn't competition the language would absolutely stagnate again as risk aversion sets in.
- WClayFerguson 6y ago
  Right, I think the languages that compile JVM bytecode were much more heading in a better direction than the ones who said "let's have fun and just start from scratch, and further fragment the industry"
  - klodolph 6y ago
    You’re just painting caricatures of language designers. Flamebait without substance.
  - acdha 6y ago
    Couldn’t you also say the same thing about Java not going with one of the earlier bytecoded VMs? Or, from the other direction, would we have seen more languages embrace the JVM if it’d been more open and things like invokedynamic had been added earlier? I think there are some interesting points to made where you’re coming from, but this fragmented approach isn’t effectively making them. Something like a blog post might be better.
    - WClayFerguson 6y ago
      Here's a non-fragmented translation for ya: "The fewer languages there are the easier it is for developers to share code."
klodolph 6y ago
This sounds far-fetched to me, partly because of the nontrivial technical differences between Java and Go and partly because of the politics surrounding Oracle’s ownership of Java and the way Oracle quashes community efforts. Value types, interior pointers, multiple levels of pointers, slices, and radically different indirect dispatch semantics are just a few things that Go has that Java doesn’t. These aren’t things that you can staple to Java. Java is more than syntax, it’s the semantics of the JVM and its object system, which should only be extended in a backwards-compatible way. So I’m gonna say that the reason Go exists is exactly because the creators didn’t want to burn down Java and start over. It turns out that you can create a new language without burning anything down. There is also C# and the various nontrivial differences between C# and Java, like value types and type erasure in generics. There are plenty of languages which exist side-by-side with Java in the JVM: Clojure, Kotlin, and Scala to name three. These all have their differences but they’re all designed specifically with the JVM in mind. Go isn’t.
- WClayFerguson 6y ago
  I think the world was almost tolerable before Go and Rust came along. We already had too many languages even before those two, but at least there was a clear leader: Java. Nowadays the market is completely fragmented.
  - AnimalMuppet 6y ago
    What's your issue? How exactly do more languages harm you? Or harm anyone? Is choice bad for some reason?
    - lolive 6y ago
      I think all languages do suffer from their initial design. And spend 5-years iteration to circumventing them. Java will have proper asynchronous management in 5 years, Go will have generics in 5 years, Rust will have a garbage collector variant in 5 years, Python and JavaScript will have full multithreading in 5 years. In the end, no language is catching the whole problematic and solve it at once. So there is a programming language fatigue. PS: when I say that things happen within a timeframe of 5 years, it includes the time to deliver the feature in the language, and people to massively adopt it, and new developped code to include it in mass.
wvenable 6y ago
> Whatever people find unacceptable about Java could've been fixed. It's been DECADES. Plenty of time to fix things but nope. I don't know what Java's developers were interested in but improving things for other developers was not one of them. C# is literally a better Java already. And Kotlin.
- josephg 6y ago
  I agree. The problem with Java is its culture, which cannot be fixed by same thinking which created it. And by culture I mean, java attracted people who think that lines of code are cheap and see nothing wrong with a 200 line class which has no actual behaviour beyond boilerplate. People who measure their output by the number of lines of code added per day, not the number of features added to a project per year. Any "fixed" version of java needs to either bring those people along - and in the process import a lot of java's stale thinking. (Some corners of the C# world struggle with this). Or leave those people behind and build a new community around your new thing (eg Scala, Clojure). You can see this in the java community already - there are plenty of tools in the modern JVM for doing terse functional programming. But as far as I know that stuff remains unpopular. Why? My theory is that most of the people who really care about writing terse, efficient, maintainable code jumped to better languages years ago.
  - WClayFerguson 6y ago
    > 200 line class which has no actual behaviour beyond boilerplate A skilled Java developer might make a huge POJO have every variable private and then implement getters and setters to control or monitor access to every member. But then some noob straight outta college will look at that code, not understand why it's being done so 'stupidly', and just delete all the accessors and make every variable public, so you don't even need any getters/setters. Said noob will consider himself a superior programmer until he looks back on it 10 years later, with enough wisdom to see clearly.
    - josephg 6y ago
      Yikes! On behalf of everyone who doesn’t write Java for a living, 200 lines for a plain data object, full of trivial getters and setters everywhere is crazy. Code like that decimates your velocity because of how much effort it takes to refactor or add features to your project. The noob’s instincts are right. Well written code in just about any other language doesn’t need all that crap. And for good reason - you can really feel the difference if you actually measure your performance programming, in the short term or the long term. And in either features/hour or features/line changed. I worked at a place once which had this C# project which wrapped incoming http calls into calls to our internal backend (also http). Then it took the JSON from the backend and converted it to JSON for the browser. The code was 3500 lines full of that sort of POJO getter and setter crap. Every time we added a feature, this code needed to be updated. We had 2 people assigned full time to do those changes. After way too many meetings we managed to replace the whole thing with a few hundred lines of nodejs code. Those guys were moved into more useful roles - saving the company 2 full time salaries.
voldacar 6y ago
> Whatever people find unacceptable about Java could've been fixed. yeah by making it common lisp instead of java
- WClayFerguson 6y ago
  That's a great point. Lisp is so simple in every way, you could make a good case that it was superior to all other languages, and that perhaps inventing Java was the mistake and Lisp should've been the "final" language.

manigandham 6y ago

That's what Scala and Kotlin are, fixes for the original Java flavor. Then again, more alternatives are good for competition; and incubating and sharing new designs that aren't possible in a very old language.

lumost 6y ago
barring competition languages seem to stall out over time. Java fell out of favor because every java app turned into a pile of xml and factories that everyone hated and was slow to develop. The faster evolution of peer languages allowed for recognition of what people didn't like in Java (The ceremony of getting setup and invoking "app" logic). The better parts of Scala, kotlin, and the guava library are steadily making their way into the language. But if there wasn't competition the language would absolutely stagnate again as risk aversion sets in.
WClayFerguson 6y ago
Right, I think the languages that compile JVM bytecode were much more heading in a better direction than the ones who said "let's have fun and just start from scratch, and further fragment the industry"
- klodolph 6y ago
  You’re just painting caricatures of language designers. Flamebait without substance.
- acdha 6y ago
  Couldn’t you also say the same thing about Java not going with one of the earlier bytecoded VMs? Or, from the other direction, would we have seen more languages embrace the JVM if it’d been more open and things like invokedynamic had been added earlier? I think there are some interesting points to made where you’re coming from, but this fragmented approach isn’t effectively making them. Something like a blog post might be better.
  - WClayFerguson 6y ago
    Here's a non-fragmented translation for ya: "The fewer languages there are the easier it is for developers to share code."

klodolph 6y ago

This sounds far-fetched to me, partly because of the nontrivial technical differences between Java and Go and partly because of the politics surrounding Oracle’s ownership of Java and the way Oracle quashes community efforts. Value types, interior pointers, multiple levels of pointers, slices, and radically different indirect dispatch semantics are just a few things that Go has that Java doesn’t. These aren’t things that you can staple to Java. Java is more than syntax, it’s the semantics of the JVM and its object system, which should only be extended in a backwards-compatible way. So I’m gonna say that the reason Go exists is exactly because the creators didn’t want to burn down Java and start over. It turns out that you can create a new language without burning anything down. There is also C# and the various nontrivial differences between C# and Java, like value types and type erasure in generics. There are plenty of languages which exist side-by-side with Java in the JVM: Clojure, Kotlin, and Scala to name three. These all have their differences but they’re all designed specifically with the JVM in mind. Go isn’t.

WClayFerguson 6y ago
I think the world was almost tolerable before Go and Rust came along. We already had too many languages even before those two, but at least there was a clear leader: Java. Nowadays the market is completely fragmented.
- AnimalMuppet 6y ago
  What's your issue? How exactly do more languages harm you? Or harm anyone? Is choice bad for some reason?
  - lolive 6y ago
    I think all languages do suffer from their initial design. And spend 5-years iteration to circumventing them. Java will have proper asynchronous management in 5 years, Go will have generics in 5 years, Rust will have a garbage collector variant in 5 years, Python and JavaScript will have full multithreading in 5 years. In the end, no language is catching the whole problematic and solve it at once. So there is a programming language fatigue. PS: when I say that things happen within a timeframe of 5 years, it includes the time to deliver the feature in the language, and people to massively adopt it, and new developped code to include it in mass.

wvenable 6y ago

> Whatever people find unacceptable about Java could've been fixed. It's been DECADES. Plenty of time to fix things but nope. I don't know what Java's developers were interested in but improving things for other developers was not one of them. C# is literally a better Java already. And Kotlin.

josephg 6y ago
I agree. The problem with Java is its culture, which cannot be fixed by same thinking which created it. And by culture I mean, java attracted people who think that lines of code are cheap and see nothing wrong with a 200 line class which has no actual behaviour beyond boilerplate. People who measure their output by the number of lines of code added per day, not the number of features added to a project per year. Any "fixed" version of java needs to either bring those people along - and in the process import a lot of java's stale thinking. (Some corners of the C# world struggle with this). Or leave those people behind and build a new community around your new thing (eg Scala, Clojure). You can see this in the java community already - there are plenty of tools in the modern JVM for doing terse functional programming. But as far as I know that stuff remains unpopular. Why? My theory is that most of the people who really care about writing terse, efficient, maintainable code jumped to better languages years ago.
- WClayFerguson 6y ago
  > 200 line class which has no actual behaviour beyond boilerplate A skilled Java developer might make a huge POJO have every variable private and then implement getters and setters to control or monitor access to every member. But then some noob straight outta college will look at that code, not understand why it's being done so 'stupidly', and just delete all the accessors and make every variable public, so you don't even need any getters/setters. Said noob will consider himself a superior programmer until he looks back on it 10 years later, with enough wisdom to see clearly.
  - josephg 6y ago
    Yikes! On behalf of everyone who doesn’t write Java for a living, 200 lines for a plain data object, full of trivial getters and setters everywhere is crazy. Code like that decimates your velocity because of how much effort it takes to refactor or add features to your project. The noob’s instincts are right. Well written code in just about any other language doesn’t need all that crap. And for good reason - you can really feel the difference if you actually measure your performance programming, in the short term or the long term. And in either features/hour or features/line changed. I worked at a place once which had this C# project which wrapped incoming http calls into calls to our internal backend (also http). Then it took the JSON from the backend and converted it to JSON for the browser. The code was 3500 lines full of that sort of POJO getter and setter crap. Every time we added a feature, this code needed to be updated. We had 2 people assigned full time to do those changes. After way too many meetings we managed to replace the whole thing with a few hundred lines of nodejs code. Those guys were moved into more useful roles - saving the company 2 full time salaries.

voldacar 6y ago

> Whatever people find unacceptable about Java could've been fixed. yeah by making it common lisp instead of java

WClayFerguson 6y ago
That's a great point. Lisp is so simple in every way, you could make a good case that it was superior to all other languages, and that perhaps inventing Java was the mistake and Lisp should've been the "final" language.