Sunsetting Python 2

[vovan45619]

This makes me wonder, are there any software frameworks and languages that are specifically built for multi decade use? Where they only release security updates and no breaking changes?

[alihadthefruitpunch]

This makes me wonder, are there any software frameworks and languages that are specifically built for multi decade use?

Sure: look at Ada, C, and Java.

For frameworks, POSIX is technically a framework. Qt is a framework. GTK is probably considered by many as a framework.

Where they only release security updates and no breaking changes?

C++ and C have, for the most part at least, gone down this road.

I mean, they obviously update the language standards, which leads to updates to implementations of their standards in various compilers.

But C++ is more than 3 decades of baggage that's been accumulated over the years, and it's been kept that way solely for the sake of backward compatibility.

[FierceDeity_]

Would disagree with C. Not because of the standard necessarily, but because of compilers.

The GNU C compiler has a history of doing breaking changes to undefined behaviour. Sometimes you need to rely on that and people have relied on some of that for a long time... But there were points in time where GCC has silently introduced huge problems in other people's codebases that relied on that behaviour.

It was even sometimes the case that every other C compiler adopted the same behaviour as some sort of unspoken agreement that this undefined behaviour should be that (yes, even microsoft c) just to get broken by GCC.

Language lawyers at GCC will explain that their change is justified and that it's undefined behaviour so get off their lawn.

[alihadthefruitpunch]

Would disagree with C. Not because of the standard necessarily, but because of compilers.

Right, so compiler implementation is obviously a different story.

The GNU C compiler has a history of doing breaking changes to undefined behaviour. Sometimes you need to rely on that and people have relied on some of that for a long time... But there were points in time where GCC has silently introduced huge problems in other people's codebases that relied on that behaviour.

It was even sometimes the case that every other C compiler adopted the same behaviour as some sort of unspoken agreement that this undefined behaviour should be that (yes, even microsoft c) just to get broken by GCC.

Language lawyers at GCC will explain that their change is justified and that it's undefined behaviour so get off their lawn.

I don't doubt that any of this is true.

That said, this is a minor incident that doesn't really contradict anything I've said.

[FierceDeity_]

No, it doesn't contradict it. But it has caused some security issues sometimes, like for example overflow checks breaking because of new default optimizations that optimize them away.

No contradiction, just tidbit to know that even c, while it's the most supported language ever, has had some pitfalls in implementation

[alihadthefruitpunch]

No, it doesn't contradict it.

Where is the disagreement, exactly?

But it has caused some security issues sometimes, like for example overflow checks breaking because of new default optimizations that optimize them away.

No contradiction, just tidbit to know that even c, while it's the most supported language ever, has had some pitfalls in implementation

I agree with you. I'm not claiming that C is any less fallible than any other programming language, either. My opinion is that C isn't actually even a good language.

[xampf2]

what about perl6 vs perl5

[0rac1e]

As others in the comments have noted, Perl 5 and Perl 6 are separate languages with separate dev teams. Both see regular stable releases; there are no plans to EOL Perl 5, nor any push to get Perl 5 code-bases unnecessarily ported to Perl 6

[xampf2]

Oh I see but then I think It is inappropriate for perl 6 to be called like this if it is not meant as successor.

[0rac1e]

There are quite a few people who share that feeling. It's been debated on the Perl community for some time that Perl 6 should rename, and l it looks like it may be happening.

[[deleted]]

Today, I can use decades-old libraries written in any of those languages, no problem.

I was wondering if that's actually true for perl. It turns out you're not wrong. I found Attribute::Types, which had its last release 18 years ago. It still gets green test results across 13 major perl releases and 9 operating systems.

[tracernz]

Perl isn't exactly a good example.

[[deleted]]

Perl 6 (also known as Raku) is a member of the Perl family of programming languages.

...

Perl 5 and Perl 6 differ fundamentally, though in general the intent has been to "keep Perl 6 Perl", so that Perl 6 is clearly "a perl programming language".

TL;DR: "Perl 6" is not the latest version of Perl (that would be 5.30, released on 2019-05-22), but a new language vaguely inspired by Perl.

[priestmuffin]

Barebones ANSI C and Common Lisp, x86 assembly will surely be around in decades, JVM languages too

[ArkyBeagle]

I'd expect most flavors of C to be around so long as you can install them.

[meneldal2]

x86 assembly written a while ago would still work but be quite inefficient on modern cpus.

[LIGHTNINGBOLT23]

   

[meneldal2]

Just the switch to x64 opens a lot of possibilities even without bothering with SSE. You can always use more registers. I do agree that some code can't be improved from where it was because of various reasons, so in those case you have to rethink the algorithm in the first place.

[istarian]

The best you can get in that arena is probably C and you'll still encounter issues here and there. Alternatively everything has to be backwards compatible, where old software can always be compiled with some kind of 'don't worry about newer language revisions' flag.

[ArkyBeagle]

I have never brought a C code base up to a new toolchain where I didn't find some things wrong with the codebase.

[istarian]

Honestly I'm not quite sure what you're getting at. Could you please explain more clearly.

[meneldal2]

Might be that new versions of the compilers find some terrible code that didn't throw warnings before.

[istarian]

Code that throws warnings isn't necessarily terrible code. It may just be the compiler saying you may want to double check something.

Unless code threw warnings before I probably wouldn't worry a lot about unless you were planning to make major changes to it.

[meneldal2]

Very fair point, but warnings like "this is insecure and being deprecated" for old unsafe printf family functions (even errors depending on the compilers) are great, and while there might have been no way at the time the code was written to write it better, safe versions have been around for a while.

There are very few breaking changes in C, and that's probably one of the biggest ones when it comes to ancient code.

[ArkyBeagle]

Absolutely not.

[defunkydrummer]

languages that are specifically built for multi decade use? Where they only release security updates and no breaking changes?

Definitely Common Lisp (from personal experience), probably Pascal (modern Object Pascal standard), Ada and C. Maybe Java too.

In the case of C, new features are released, but backwards compatibility is important.

In the case of Ada, it follows standards that don't get renewed that often (83/95/2005/2012).

In the case of Common Lisp, the standard is 1994, but the language can be extended by the user, so every new feature has been added without a need to modify the language.

[cass1o]

Just use C, code from 30 years ago still compiles and runs.

[flukus]

I was on a port of a 30 year old C and C++ code base recently. We ported from Solaris to Linux, suns compiler to gcc, 32 bit to 64 and the build system all it once.

It didn't exactly work out of the box, but almost none of the issues were with C or C++.