4 ms·

So what can we learn from this for designing future languages? Make it standard idiom to have every file of code declare its version-dialect at the top? Defau

So what can we learn from this for designing future languages? Make it standard idiom to have every file of code declare its version-dialect at the top? Default to throwing warning if interpreter and code version-dialect mismatch? Have the main code interpreter called by all code files simply be a host for routing code to the correct dialect-version interpreter? Perhaps include an optional "slim" download where the host only includes the interpreter for one dialect-version, but make this non-default\opt-in.

points 16y ago
> "So what can we learn from this for designing future languages?" We can learn that it's inevitable that your language will come into fashion, be hyped up to be "the language", then will fall out of fashion and be declared 'dead'. The idea of a '100 year language' is solid as long as developers don't choose languages like they choose what to wear. Unfortunately though, most developers seem to choose based on current fashion rather than anything else.
- metamemetics 16y ago
  Let's try to be constructive here! Come up with solutions and ways to avoid the problems mentioned in the future. There's always fashions and trends sure, but I think most people chose to program their last web app in Python or Ruby over assembly for more practical reasons...
  - points 16y ago
    heh true, although you sure can learn a lot doing things the 'unaccepted' way. So I'd actually advise everyone to try writing a webapp in assembly. If most people tell you what you're doing is crazy, it's often a big sign that you should do it.
    - regularfry 16y ago
      "They laughed at Columbus, they laughed at Fulton, they laughed at the Wright brothers. But they also laughed at Bozo the Clown."
- philwelch 16y ago
  Programming language popularity works like fashion, but not because developers are shallow and finicky. It's because it's actually important what other developers are using. You could have the best programming language ever, but libraries, resources, help, and advice won't exist until you have a lot of people using it. There's enough adventurous programmers to bootstrap this cycle with new languages, but the general principle holds.
  - points 16y ago
    I agree to an extent. That stuff matters when you're starting out and just learning. But after you get to a certain level the 'language ecosystem' isn't important at all IMHO.
    - lygaret 16y ago
      Massively disagree: once I get to a certain level, there's no way in hell I want to waste my time implementing all of (java) commons-lang, or my own sqlite bindings, etc. When the languages ecosystem is flourishing, I am productive. When it's not, I'm shaving yaks that prefer not to be shaved.
      - zaphar 16y ago
        snarky aside No one wants to implement all of java commons-lang in their language of choice because they'd be lynched by the languages users. I no of no other language with a standard library as annoyingly verbose and complicated as java.
zedshaw 16y ago
I'd say a good start would be: 1. Less syntax, so that later language features don't cause upgrade problems and can more easily be worked around rather than causing syntax errors. 2. Awesome package management with everything not core in packages that work with the distros so they don't mind using them. Both of those are damn hard to do though. Less syntax makes the language fairly unusable (Forth), and package management is just a nightmare in general.
- metamemetics 16y ago
  I think dialects are tough to predict emergent behavior that will inevitably happen if a language becomes old enough. They just want to happen. If your language assumes this and supports version-dialect from the start it will be more robust and age gracefully in the long run. edit: basically it would require too much work or a stroke of pure genius to ensure perfect syntax for a new language in public release 1. Language designers should assume as project age approaches infinity the probability of a syntax revision approaches 1. edit2: also if the interpreter host could interpret all the older versions up to the latest by default, you could write your code in both 2.7 and 3.1 and use 2.5 libraries with it etc. No need to rewrite every single older library for trivial changes.

points 16y ago

> "So what can we learn from this for designing future languages?" We can learn that it's inevitable that your language will come into fashion, be hyped up to be "the language", then will fall out of fashion and be declared 'dead'. The idea of a '100 year language' is solid as long as developers don't choose languages like they choose what to wear. Unfortunately though, most developers seem to choose based on current fashion rather than anything else.

metamemetics 16y ago
Let's try to be constructive here! Come up with solutions and ways to avoid the problems mentioned in the future. There's always fashions and trends sure, but I think most people chose to program their last web app in Python or Ruby over assembly for more practical reasons...
- points 16y ago
  heh true, although you sure can learn a lot doing things the 'unaccepted' way. So I'd actually advise everyone to try writing a webapp in assembly. If most people tell you what you're doing is crazy, it's often a big sign that you should do it.
  - regularfry 16y ago
    "They laughed at Columbus, they laughed at Fulton, they laughed at the Wright brothers. But they also laughed at Bozo the Clown."
philwelch 16y ago
Programming language popularity works like fashion, but not because developers are shallow and finicky. It's because it's actually important what other developers are using. You could have the best programming language ever, but libraries, resources, help, and advice won't exist until you have a lot of people using it. There's enough adventurous programmers to bootstrap this cycle with new languages, but the general principle holds.
- points 16y ago
  I agree to an extent. That stuff matters when you're starting out and just learning. But after you get to a certain level the 'language ecosystem' isn't important at all IMHO.
  - lygaret 16y ago
    Massively disagree: once I get to a certain level, there's no way in hell I want to waste my time implementing all of (java) commons-lang, or my own sqlite bindings, etc. When the languages ecosystem is flourishing, I am productive. When it's not, I'm shaving yaks that prefer not to be shaved.
    - zaphar 16y ago
      snarky aside No one wants to implement all of java commons-lang in their language of choice because they'd be lynched by the languages users. I no of no other language with a standard library as annoyingly verbose and complicated as java.

zedshaw 16y ago

I'd say a good start would be: 1. Less syntax, so that later language features don't cause upgrade problems and can more easily be worked around rather than causing syntax errors. 2. Awesome package management with everything not core in packages that work with the distros so they don't mind using them. Both of those are damn hard to do though. Less syntax makes the language fairly unusable (Forth), and package management is just a nightmare in general.

metamemetics 16y ago
I think dialects are tough to predict emergent behavior that will inevitably happen if a language becomes old enough. They just want to happen. If your language assumes this and supports version-dialect from the start it will be more robust and age gracefully in the long run. edit: basically it would require too much work or a stroke of pure genius to ensure perfect syntax for a new language in public release 1. Language designers should assume as project age approaches infinity the probability of a syntax revision approaches 1. edit2: also if the interpreter host could interpret all the older versions up to the latest by default, you could write your code in both 2.7 and 3.1 and use 2.5 libraries with it etc. No need to rewrite every single older library for trivial changes.