Comment by vorg | Hacker News Reader

Comment by vorg | Hacker News Reader

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.

(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.

C# and Javascript (mostly thinking of strict mode) fall in this category too

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.

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...

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.

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.

This works on dotnet. The dotnet runtime is versioned separately from the language so you can use a library written and compiled with C# 5 in a project that is written in C# 7 so long as they both target a compatible runtime. You can go even further and use a C# 7 library in a F# or VB project.

That is because there isn't C#, F#, VB.NET, C++/CLI or any language that you decide to put on top, just MSIL.

With straight native code, the story is a bit different.

Different Go modules can use different versions of the language, per this proposal.

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.

That's true now, but is was quite a bit less true back in the 3.0/3.1 days.

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.

Python 3.4 is available from the official CentOS repos, and 3.6 is even available in EPEL.

AIUI both are only available from EPEL.

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.

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.

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-comm... )

To call Perl 5 code from Perl 6, we currently have Inline::Perl5 (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) and other Inline modules (https://modules.perl6.org/search/?q=Inline ) that can be called from Perl 6.

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

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

Reply on news.ycombinator.com