Hacker News Reader

Comment by imoverclocked | Hacker News Reader

That’s the fun thing about backward compatibility. You can never clean up technically supported things that were never intended.

It would be cool if we could have some kind of pragma or alternate syntax (file extension?) that gets rid of these unwanted ambiguities every decade or so. How to do that while avoiding the whole “Perl 6” can of worms might be the hard part though.

View on HN

Perl 5 has that.

Perl 5 seems to have all these annoying boilerplate lines that you need to add to every file in order to get “Perl The Good Parts”. But I think (I read) that they managed to boil it down to just one line.

Rust editions? They work on per crate, rather than per file level though.

In Java you set the language version per source file, and there are occasional and uncommon source incompatibilities, but it's still not worth it to introduce a common incompatibility (which isn't really the case here, anyway).

They still all compile to some set bytecode version, right?

The target bytecode/standard library version can also be specified on a per-file basis (we have both -source and -target options). But while the VM can load a classfile of any version since the beginning of time, the javac compiler supports only a certain number of versions back in terms of source version and target version (e.g. you can't use a JDK 19 compiler to target JDK 7, but you can ask for the same language, API, and bytecode level as 15).

Reply on news.ycombinator.com