5 ms·

Languages cannot get better, only bigger, without dropping backwards compatibility. This is why Java needs to die. Not because it's particularly horrible, but b

by tormeh 10y ago

Languages cannot get better, only bigger, without dropping backwards compatibility. This is why Java needs to die. Not because it's particularly horrible, but because we can do better now.

dkersten 10y ago
Languages cannot get better, only bigger, without dropping backwards compatibility. Completely agree. Dropping backwards compatibility, if you have serious users, really isn't an option either. Just look at Python 2/3. You can deprecate stuff and very very very very slowly remove it, but it really is a slow process if you want to keep your existing users happy.
nradov 10y ago
By that standard every language needs to die. Or to put it another way, how long should languages be permitted to survive as we figure out better ways of doing things?
- tormeh 10y ago
  Very interesting question. The benefits of a new language has to be weighed against the learning that has to be done to use it and the load of maintaining things in different languages. It's not every 3 years or anything like that, but Java is 20 years old now, and it shows.
  - afandian 10y ago
    And another generation of programmers wastes time rewriting the same stuff in the language du jour.
    - greydius 10y ago
      This is going to happen anyway.
  - pjmlp 10y ago
    > It's not every 3 years or anything like that, but Java is 20 years old now, and it shows. Yes, I get to use mature libraries for everything without having to spend development time redoing them, and can focus on business code instead.
- lmm 10y ago
  I'd say about 5 years after their replacement becomes production-ready. (Having started switching to Scala 6 years ago I'd say that's about now for Java).
- xaduha 10y ago
  Some languages have official versions than you need to declare right at the start. As in specification version, not implementation versions.
  - nradov 10y ago
    I'm not convinced that's any better than specifying the language version as a compiler command line argument.
    - xaduha 10y ago
      It's plenty better. You're saying on the source code level that it's not designed to be run by anything but an implementation of that specification version.
      - nradov 10y ago
        But in practice the language version is always specified in the build script which is bundled with the source code. In Java that's typically a Maven pom.xml file. So you only have to change it once per module rather than in every separate source code file. I see no particular advantage in specifying the language version in each and every file; those source code files aren't meant to stand on their own anyway.
        xaduha 10y ago
        The point is to remove obstacles that prevent you from introducing backward incompatible changes into the language, obstacles than prevent your language from evolving. Implementations can support several specifications of the language, you can keep those source code files as is or you can mix them. You can take advantage of new features in new files, but keep everything else working. Imagine you updated your pom file and bunch of stuff stopped working. If it's easy enough to fix you do it, if not you might just revert pom changes and stay with older version of the language, module or whatever. That wouldn't happen with versioned specification languages. > I see no particular advantage in specifying the language version in each and every file You obviously stuck with this mindset and not thinking about it hard enough.
wtetzner 10y ago
I disagree. I mean, I agree that Java isn't good, but the changes made in Java 8 made Java both better and bigger.
TheGuyWhoCodes 10y ago
Yes let's just throw away 20 years of VM research and optimizations. Dropping some backwards compatibility which impacts performance the most is sensible and I wish java would do some of that but this is a long way from killing java. Java runs the world, you will have to work very hard and long to produce the same Ecosystem around something else.
- xaduha 10y ago
  Who said anything about dropping the VM or infrastructure? JVM is awesome. Java isn't.
  - TheGuyWhoCodes 10y ago
    Well that's just your opinion, I think java is pretty nice with Java8. When you see someone say let's kill Java what does that mean for the JVM? Because Oracle will not say ya cool let's just focus on other languages running on the JVM like kotlin and Scala and drop java all together. Java is more optimized performance wise than Scala and Kotlin and performance is important not just cool syntax. I think it's good that we have other implementations that allows the JVM to be pushed further and make Java compete with them, it's a win-win for the languages that run on the JVM and Java itself.
    - xaduha 10y ago
      > Java is more optimized performance wise than Scala and Kotlin and performance is important not just cool syntax. Not true. You're running bytecode, not Java. Compiled JVM languages benefit from JVM optimizations all the same. No one will actually 'kill' Java, it's about mindset of the users and companies. Kill Java = Give another JVM language a try. Oracle JVM isn't the only JVM implementation.
      - pjmlp 10y ago
        > Oracle JVM isn't the only JVM implementation. Quite true, but from Azul, IBM, HP, Jamaica, Aonix, Excelsior, Gamato,CodenameOne, ... who is interested in replacing Java (the language)?
user5994461 10y ago
Or we can keep Java so the entreprisey outsourced projects use that, while the hype 3lit3 tech use something else. That makes it easier to self select jobs and to recruit =) A win win.
overgard 10y ago
That's not really true -- for instance, C++ 11 is a lot more pleasant than C++ 98 even though it's just a more complicated version of that. A lot of bad ideas tend to fall into disuse, even if they're not technically gone.

by tormeh 10y ago

Languages cannot get better, only bigger, without dropping backwards compatibility. This is why Java needs to die. Not because it's particularly horrible, but because we can do better now.

dkersten 10y ago

Languages cannot get better, only bigger, without dropping backwards compatibility. Completely agree. Dropping backwards compatibility, if you have serious users, really isn't an option either. Just look at Python 2/3. You can deprecate stuff and very very very very slowly remove it, but it really is a slow process if you want to keep your existing users happy.

nradov 10y ago

By that standard every language needs to die. Or to put it another way, how long should languages be permitted to survive as we figure out better ways of doing things?

tormeh 10y ago
Very interesting question. The benefits of a new language has to be weighed against the learning that has to be done to use it and the load of maintaining things in different languages. It's not every 3 years or anything like that, but Java is 20 years old now, and it shows.
- afandian 10y ago
  And another generation of programmers wastes time rewriting the same stuff in the language du jour.
  - greydius 10y ago
    This is going to happen anyway.
- pjmlp 10y ago
  > It's not every 3 years or anything like that, but Java is 20 years old now, and it shows. Yes, I get to use mature libraries for everything without having to spend development time redoing them, and can focus on business code instead.
lmm 10y ago
I'd say about 5 years after their replacement becomes production-ready. (Having started switching to Scala 6 years ago I'd say that's about now for Java).
xaduha 10y ago
Some languages have official versions than you need to declare right at the start. As in specification version, not implementation versions.
- nradov 10y ago
  I'm not convinced that's any better than specifying the language version as a compiler command line argument.
  - xaduha 10y ago
    It's plenty better. You're saying on the source code level that it's not designed to be run by anything but an implementation of that specification version.
    - nradov 10y ago
      But in practice the language version is always specified in the build script which is bundled with the source code. In Java that's typically a Maven pom.xml file. So you only have to change it once per module rather than in every separate source code file. I see no particular advantage in specifying the language version in each and every file; those source code files aren't meant to stand on their own anyway.
      - xaduha 10y ago
        The point is to remove obstacles that prevent you from introducing backward incompatible changes into the language, obstacles than prevent your language from evolving. Implementations can support several specifications of the language, you can keep those source code files as is or you can mix them. You can take advantage of new features in new files, but keep everything else working. Imagine you updated your pom file and bunch of stuff stopped working. If it's easy enough to fix you do it, if not you might just revert pom changes and stay with older version of the language, module or whatever. That wouldn't happen with versioned specification languages. > I see no particular advantage in specifying the language version in each and every file You obviously stuck with this mindset and not thinking about it hard enough.

wtetzner 10y ago

I disagree. I mean, I agree that Java isn't good, but the changes made in Java 8 made Java both better and bigger.

TheGuyWhoCodes 10y ago

Yes let's just throw away 20 years of VM research and optimizations. Dropping some backwards compatibility which impacts performance the most is sensible and I wish java would do some of that but this is a long way from killing java. Java runs the world, you will have to work very hard and long to produce the same Ecosystem around something else.

xaduha 10y ago
Who said anything about dropping the VM or infrastructure? JVM is awesome. Java isn't.
- TheGuyWhoCodes 10y ago
  Well that's just your opinion, I think java is pretty nice with Java8. When you see someone say let's kill Java what does that mean for the JVM? Because Oracle will not say ya cool let's just focus on other languages running on the JVM like kotlin and Scala and drop java all together. Java is more optimized performance wise than Scala and Kotlin and performance is important not just cool syntax. I think it's good that we have other implementations that allows the JVM to be pushed further and make Java compete with them, it's a win-win for the languages that run on the JVM and Java itself.
  - xaduha 10y ago
    > Java is more optimized performance wise than Scala and Kotlin and performance is important not just cool syntax. Not true. You're running bytecode, not Java. Compiled JVM languages benefit from JVM optimizations all the same. No one will actually 'kill' Java, it's about mindset of the users and companies. Kill Java = Give another JVM language a try. Oracle JVM isn't the only JVM implementation.
    - pjmlp 10y ago
      > Oracle JVM isn't the only JVM implementation. Quite true, but from Azul, IBM, HP, Jamaica, Aonix, Excelsior, Gamato,CodenameOne, ... who is interested in replacing Java (the language)?

user5994461 10y ago

Or we can keep Java so the entreprisey outsourced projects use that, while the hype 3lit3 tech use something else. That makes it easier to self select jobs and to recruit =) A win win.

overgard 10y ago

That's not really true -- for instance, C++ 11 is a lot more pleasant than C++ 98 even though it's just a more complicated version of that. A lot of bad ideas tend to fall into disuse, even if they're not technically gone.