3 ms·

It makes me think there isn't any reason old languages cannot adopt these. Or even, come up with a new, batteries included version. Eg. keep the Java syntax,

by Gunax 4y ago

It makes me think there isn't any reason old languages cannot adopt these. Or even, come up with a new, batteries included version. Eg. keep the Java syntax, but add one standard package manager (instead of ant, mvn, gradle), one standard test framework, standard formatter, etc. Call it 'Java++' or whatever.

setr 4y ago
You need to incentivize codebases to be moved to the new thing, or you have to rely on incremental adoption by new projects. It’s a tragedy of the commons — for any individual codebase it’s hardly worth the trouble (My codebase(s) already has a standard formatter / package manager / whatever; what do I get by changing?) but it’s worth it every other codebase was already moved. Alternatively you build a thing that every other system could be auto-migrated to, which inevitably means supporting every possible feature of everything in play and slapping an ANSI standard label on it; and then watch as everyone extends the standard arbitrarily
- aninteger 4y ago
  > My codebase(s) already has a standard formatter / package manager / whatever; what do I get by changing?) I guess you don't get much for yourself, but you get closer to some form of community standard. This ultimately helps your codebase "grow" when you need help from, or need to hire, other people. Other people that know those standards.
  - setr 4y ago
    That’s fundamentally the problem; it’s only beneficial if the whole community moves in unison. If I switch from one standard with 10% ecosystem usage to another with 25%, I’ve accomplished nothing. You need something more like at least 60-70% standard usage to be a meaningful target. Unless that 25% usage choice eventually grows to full usage… but I can’t predict the future — so I’m just betting on it. But that bet also does very little for me even on success (it’s definitely nicer to be normal, but it’s hardly critical), and I could just as well make the migration after it’s become a real standard with no risk. So why am I migrating?
oaiey 4y ago
There are low hanging fruits which would have adoption problems but that can be navigated. However, there are very painful things like modern compilers which are massive undertakings for an old languages. It cost Microsoft 3-4 years to rewrite the C# compiler to be modern. But the benefit is a language server which keeps pace with the compiler and refactorings on the same AST (aka more stable/reliable).

by Gunax 4y ago

setr 4y ago

You need to incentivize codebases to be moved to the new thing, or you have to rely on incremental adoption by new projects. It’s a tragedy of the commons — for any individual codebase it’s hardly worth the trouble (My codebase(s) already has a standard formatter / package manager / whatever; what do I get by changing?) but it’s worth it every other codebase was already moved. Alternatively you build a thing that every other system could be auto-migrated to, which inevitably means supporting every possible feature of everything in play and slapping an ANSI standard label on it; and then watch as everyone extends the standard arbitrarily

aninteger 4y ago
> My codebase(s) already has a standard formatter / package manager / whatever; what do I get by changing?) I guess you don't get much for yourself, but you get closer to some form of community standard. This ultimately helps your codebase "grow" when you need help from, or need to hire, other people. Other people that know those standards.
- setr 4y ago
  That’s fundamentally the problem; it’s only beneficial if the whole community moves in unison. If I switch from one standard with 10% ecosystem usage to another with 25%, I’ve accomplished nothing. You need something more like at least 60-70% standard usage to be a meaningful target. Unless that 25% usage choice eventually grows to full usage… but I can’t predict the future — so I’m just betting on it. But that bet also does very little for me even on success (it’s definitely nicer to be normal, but it’s hardly critical), and I could just as well make the migration after it’s become a real standard with no risk. So why am I migrating?

oaiey 4y ago

There are low hanging fruits which would have adoption problems but that can be navigated. However, there are very painful things like modern compilers which are massive undertakings for an old languages. It cost Microsoft 3-4 years to rewrite the C# compiler to be modern. But the benefit is a language server which keeps pace with the compiler and refactorings on the same AST (aka more stable/reliable).