5 ms·

There seem to be a few standard ways to evolve to the next major version of a programming language: (1) Announce the next major version to be far off into the

by vorg 8y ago

There seem to be a few standard ways to evolve to the next major version of a programming language: (1) Announce the next major version to be far off into the future, and say it will be as backwards compatible as possible to keep developers supporting the old version, e.g. Go 1->2. (2) Build next version to be a little different to current version, provide no facility for interoperating between versions, then expect developers to switch over because of the branding, e.g. Python 2->3. (3) Announce next version to be far off into the future, and say it will be a totally different language and expect developers to switch because of the branding, e.g. Perl 5->6. (4) Don't announce or build a new major version, and keep profiting from developers using the current version for as long as possible, e.g. Java 1.x. (5) Announce next version to be very soon, but delay it for as long as possible with unofficial roadblocks and keep profiting from developers using the old version for as long as possible, e.g. Apache Groovy 2->3.

justinator 8y ago
Oh Perl 5-6 interopability was actualy promised at the very beginning - it was framed as "automatic translation" I think the problem that can't be dolved is only perl 5 can parse perl 5! There's other projects to make this happen (like: use v5;) Calling a Perl 5 module from Perl 6 can work I believe ( as well as other languages!), which is somewhat of a miracle. But it's interfaced using Perl 6.
- lizmat 8y ago
  To elaborate a bit on this: the 'use v5' project is pretty much dead at this point in time. (see also my open letter to the Perl community: https://www.perl.com/article/an-open-letter-to-the-perl-community/ https://www.perl.com/article/an-open-letter-to-the-perl-comm... ) To call Perl 5 code from Perl 6, we currently have Inline::Perl5 (https://modules.perl6.org/dist/Inline::Perl5:cpan:NINE https://modules.perl6.org/dist/Inline::Perl5:cpan:NINE): > Supports Perl 5 modules including XS modules. Allows passing integers, strings, arrays, hashes, code references, file handles and objects between Perl 5 and Perl 6. Also supports calling methods on Perl 5 objects from Perl 6 and calling methods on Perl 6 objects from Perl 5 and subclass Perl 5 classes in Perl 6. In a similar vein, there are Inline::Python (https://github.com/niner/Inline-Python/blob/master/README.md https://github.com/niner/Inline-Python/blob/master/README.md) and other Inline modules (https://modules.perl6.org/search/?q=Inline https://modules.perl6.org/search/?q=Inline ) that can be called from Perl 6.
infogulch 8y ago
(6) Design the new version to be compatible with the old version at the module level, allowing the different versions to interface with each other, where individual modules can be upgraded in isolation without breaking changes to their consumers, e.g. Rust 2018.
- oldmanhorton 8y ago
  C# and Javascript (mostly thinking of strict mode) fall in this category too
  - frutiger 8y ago
    C/C++ also. It amuses me that GP used Rust as the example for this family. In fact C has an ABI and doesn’t suffer the problem that sibling commenter mentioned.
    - coldtea 8y ago
      C doesn't do much evolution either, must less add generics or introduce new error handling semantics... And C++ just piles up features, supporting everything forever...
      - frutiger 8y ago
        That’s not really true. C++ makes changes after careful analysis. e.g. the repurposing of the auto keyword (which has been present since the days of K&R C!) I’m not a language lawyer, but one would be able to rattle of a long such list.
- pjmlp 8y ago
  It only works if everyone is obliged to build all their dependencies from source code, hence why Swift is having such hard time coming up with an ABI that could survive language evolution.
  - testvox 8y ago
wbond 8y ago
The Python 2 to 3 transition is completely unlike what you describe, at least from my perspective. I regularly write pure Python with no translation, 2to3 or six module usage that runs on Python 2.6-3.7.
- TylerE 8y ago
  That's true now, but is was quite a bit less true back in the 3.0/3.1 days.
- rwmj 8y ago
  Any good resource for this? I'm currently stuck maintaining some Python 3 code that must run on CentOS 7 (only Python 2 available) and for this I maintain a large "translation" patch on top of the upstream source, which is painful to say the least.
  - qbarrand 8y ago
    Python 3.4 is available from the official CentOS repos, and 3.6 is even available in EPEL.
    - richardwhiuk 8y ago
      AIUI both are only available from EPEL.
pbreit 8y ago
Just make it backwards compatible! Use all the ingenuity available to figure out how to do such a thing.
- hawski 8y ago
  But then you end up with C++ which is fine in some respects and totally dreadful in the others.
ksec 8y ago
I am not sure which one Ruby fits in, I guess it is more like 4, where major version isn't really breaking. I really don't like the idea of always thinking of Backward compatible though. Things will need to move forward. I think for a major version of a programming languages, it must provide something that offer major incentive for programmer to switch. For example if you want JIT that offers 2-5x the performance, it should only be working with new version going forward, and gets a chance to clean up any debt in the languages made over the past decade.

by vorg 8y ago

justinator 8y ago

Oh Perl 5-6 interopability was actualy promised at the very beginning - it was framed as "automatic translation" I think the problem that can't be dolved is only perl 5 can parse perl 5! There's other projects to make this happen (like: use v5;) Calling a Perl 5 module from Perl 6 can work I believe ( as well as other languages!), which is somewhat of a miracle. But it's interfaced using Perl 6.

lizmat 8y ago
To elaborate a bit on this: the 'use v5' project is pretty much dead at this point in time. (see also my open letter to the Perl community: https://www.perl.com/article/an-open-letter-to-the-perl-community/ https://www.perl.com/article/an-open-letter-to-the-perl-comm... ) To call Perl 5 code from Perl 6, we currently have Inline::Perl5 (https://modules.perl6.org/dist/Inline::Perl5:cpan:NINE https://modules.perl6.org/dist/Inline::Perl5:cpan:NINE): > Supports Perl 5 modules including XS modules. Allows passing integers, strings, arrays, hashes, code references, file handles and objects between Perl 5 and Perl 6. Also supports calling methods on Perl 5 objects from Perl 6 and calling methods on Perl 6 objects from Perl 5 and subclass Perl 5 classes in Perl 6. In a similar vein, there are Inline::Python (https://github.com/niner/Inline-Python/blob/master/README.md https://github.com/niner/Inline-Python/blob/master/README.md) and other Inline modules (https://modules.perl6.org/search/?q=Inline https://modules.perl6.org/search/?q=Inline ) that can be called from Perl 6.

infogulch 8y ago

(6) Design the new version to be compatible with the old version at the module level, allowing the different versions to interface with each other, where individual modules can be upgraded in isolation without breaking changes to their consumers, e.g. Rust 2018.

oldmanhorton 8y ago
C# and Javascript (mostly thinking of strict mode) fall in this category too
- frutiger 8y ago
  C/C++ also. It amuses me that GP used Rust as the example for this family. In fact C has an ABI and doesn’t suffer the problem that sibling commenter mentioned.
  - coldtea 8y ago
    C doesn't do much evolution either, must less add generics or introduce new error handling semantics... And C++ just piles up features, supporting everything forever...
    - frutiger 8y ago
      That’s not really true. C++ makes changes after careful analysis. e.g. the repurposing of the auto keyword (which has been present since the days of K&R C!) I’m not a language lawyer, but one would be able to rattle of a long such list.
pjmlp 8y ago
It only works if everyone is obliged to build all their dependencies from source code, hence why Swift is having such hard time coming up with an ABI that could survive language evolution.
- testvox 8y ago

wbond 8y ago

The Python 2 to 3 transition is completely unlike what you describe, at least from my perspective. I regularly write pure Python with no translation, 2to3 or six module usage that runs on Python 2.6-3.7.

TylerE 8y ago
That's true now, but is was quite a bit less true back in the 3.0/3.1 days.
rwmj 8y ago
Any good resource for this? I'm currently stuck maintaining some Python 3 code that must run on CentOS 7 (only Python 2 available) and for this I maintain a large "translation" patch on top of the upstream source, which is painful to say the least.
- qbarrand 8y ago
  Python 3.4 is available from the official CentOS repos, and 3.6 is even available in EPEL.
  - richardwhiuk 8y ago
    AIUI both are only available from EPEL.

pbreit 8y ago

Just make it backwards compatible! Use all the ingenuity available to figure out how to do such a thing.

hawski 8y ago
But then you end up with C++ which is fine in some respects and totally dreadful in the others.

ksec 8y ago

I am not sure which one Ruby fits in, I guess it is more like 4, where major version isn't really breaking. I really don't like the idea of always thinking of Backward compatible though. Things will need to move forward. I think for a major version of a programming languages, it must provide something that offer major incentive for programmer to switch. For example if you want JIT that offers 2-5x the performance, it should only be working with new version going forward, and gets a chance to clean up any debt in the languages made over the past decade.