4 ms·

Some languages have official versions than you need to declare right at the start. As in specification version, not implementation versions.

by xaduha 10y ago

nradov 10y ago
I'm not convinced that's any better than specifying the language version as a compiler command line argument.
- xaduha 10y ago
  It's plenty better. You're saying on the source code level that it's not designed to be run by anything but an implementation of that specification version.
  - nradov 10y ago
    But in practice the language version is always specified in the build script which is bundled with the source code. In Java that's typically a Maven pom.xml file. So you only have to change it once per module rather than in every separate source code file. I see no particular advantage in specifying the language version in each and every file; those source code files aren't meant to stand on their own anyway.
    - xaduha 10y ago
      The point is to remove obstacles that prevent you from introducing backward incompatible changes into the language, obstacles than prevent your language from evolving. Implementations can support several specifications of the language, you can keep those source code files as is or you can mix them. You can take advantage of new features in new files, but keep everything else working. Imagine you updated your pom file and bunch of stuff stopped working. If it's easy enough to fix you do it, if not you might just revert pom changes and stay with older version of the language, module or whatever. That wouldn't happen with versioned specification languages. > I see no particular advantage in specifying the language version in each and every file You obviously stuck with this mindset and not thinking about it hard enough.
      - nradov 10y ago
        No I'm not stuck, but realistically when you make a change like that you're going to have to update the entire module. There's no way that having a mix of incompatible different language versions in individual source code files within a single module is ever going to be practical for real world large scale product development.
        xaduha 10y ago
        Don't try to make it a technical issue, because it totally isn't. Every single one of those files goes through a compiler of some kind. Source code gets transformed to a tree, AST, whatever. They only thing changing here is that somewhere near the root of that tree there's a version. In many languages there is already a mechanism for specifying that kind of info, like pragmas or CDATA in SGML descended markup languages. And it's not hard to introduce either way. Javascript borrowed 'use strict' from Perl 5, for example. In the end you write something in a language. What language you use to write that isn't defined in some external file, it's an inherent property of the text. You can't write a note in Ye Olde English and expect it to be understood by modern people without issues.

Some languages have official versions than you need to declare right at the start. As in specification version, not implementation versions.

by xaduha 10y ago

Some languages have official versions than you need to declare right at the start. As in specification version, not implementation versions.

nradov 10y ago

I'm not convinced that's any better than specifying the language version as a compiler command line argument.

xaduha 10y ago
It's plenty better. You're saying on the source code level that it's not designed to be run by anything but an implementation of that specification version.
- nradov 10y ago
  But in practice the language version is always specified in the build script which is bundled with the source code. In Java that's typically a Maven pom.xml file. So you only have to change it once per module rather than in every separate source code file. I see no particular advantage in specifying the language version in each and every file; those source code files aren't meant to stand on their own anyway.
  - xaduha 10y ago
    The point is to remove obstacles that prevent you from introducing backward incompatible changes into the language, obstacles than prevent your language from evolving. Implementations can support several specifications of the language, you can keep those source code files as is or you can mix them. You can take advantage of new features in new files, but keep everything else working. Imagine you updated your pom file and bunch of stuff stopped working. If it's easy enough to fix you do it, if not you might just revert pom changes and stay with older version of the language, module or whatever. That wouldn't happen with versioned specification languages. > I see no particular advantage in specifying the language version in each and every file You obviously stuck with this mindset and not thinking about it hard enough.
    - nradov 10y ago
      No I'm not stuck, but realistically when you make a change like that you're going to have to update the entire module. There's no way that having a mix of incompatible different language versions in individual source code files within a single module is ever going to be practical for real world large scale product development.
      - xaduha 10y ago
        Don't try to make it a technical issue, because it totally isn't. Every single one of those files goes through a compiler of some kind. Source code gets transformed to a tree, AST, whatever. They only thing changing here is that somewhere near the root of that tree there's a version. In many languages there is already a mechanism for specifying that kind of info, like pragmas or CDATA in SGML descended markup languages. And it's not hard to introduce either way. Javascript borrowed 'use strict' from Perl 5, for example. In the end you write something in a language. What language you use to write that isn't defined in some external file, it's an inherent property of the text. You can't write a note in Ye Olde English and expect it to be understood by modern people without issues.