6 ms·

One day, long after I'm gone, people will finally accept that Python and JavaScript are no longer young languages. JavaScript is 26 years old, Python is 31. Th

One day, long after I'm gone, people will finally accept that Python and JavaScript are no longer young languages. JavaScript is 26 years old, Python is 31. They both continue to grow in importance year-on-year, JavaScript because there is nothing on the horizon which will plausibly replace it, and Python because a large number of industries and programmers genuinely love it. I think there's a nontrivial chance they'll both still be languages of primary importance in 50 years, but I'd bet my bottom dollar that they'll at least remain as relics yet needing support the way Fortran and COBOL exist today.

jacobr1 4y ago
> there is nothing on the horizon which will plausibly replace it I'm not going to be making any bets - but the one project that has possibility is WASM. A mature, polyglot ecosystem on top of WASM runtimes with web-apis seem like it could displace JS in browser as #1.
- chrisco255 4y ago
  Probably not. Unless you're rendering to another target besides the DOM (ie canvas) I doubt you see JS displacement as #1 in the browser. JS is not the performance bottleneck, the DOM itself is. And in the meantime, you've got 25 years of example code, component libraries, talent development, dev productivity tooling, browser integration, etc built up around it. And unlike other operating systems, the browser does not give you any kind of standard library of reasonably good components to build on. So the sheer size and volume of components and the ecosystem built up around npm well be an uphill battle for any WASM target language to compete with.
  - deleted 4y ago
    [deleted]
  - johnnyanmac 4y ago
    >Unless you're rendering to another target besides the DOM (ie canvas) I doubt you see JS displacement as #1 in the browser. if we're talking on the level of 20,30,50 years, we may in fact be able to move away from a DOM-based web. and WASM is simply a binary spec, so it can adjut with whatever comes on the horizon. We've had similar sized giants rise and fall in that span.
- still_grokking 4y ago
  Almost no languages run as WASM. This is not likely to change anytime soon (if ever), as nobody is working on this, and there is even quite strong opposition to get features in that are fundamentally needed to run anything else than the very few languages that already compile to WASM. ("Nobody" is interested in invalidating their investment in JS ;-)). Also WASM is actually slow, or better said, "it does not deliver its full potential". It will need advanced JIT compilers to keep up with the other two mayor VM langues. But in this regard WASM is behind around 20 years of constant development and improvement. My strongest hopes in this regard are currently with Microsoft (even I don't trust this company at all!), who are indeed interested to run their CLR stuff in a WASM VM, and could probably deliver on the needed features. But then, when you would run a CLR-VM (or a JVM) on top of a WASM VM, you know, you're building just the next Matryoshka… There are no real benefits to that besides "look mom, it runs in the browser".
sergiotapia 4y ago
Why did Python win the war with Ruby? Was it purely the math community deciding this is where we throw our weight and left Ruby the runt of the litter?
- Shorel 4y ago
  Performance. So many people say it doesn't matter. Until it does. Python works around it by having so many libraries built in C or C++.
  - still_grokking 4y ago
    > Python works around it by having so many libraries built in C or C++. Which works quite fine, until it doesn't. By than the needed rewrite in some language that delivers decent performance and safety all over the place in one package will be very expensive. I'm not saying that you should avoid Python (and its native code kludge) altogether but when using it just pray that you never reach that point mentioned above. It's a dead end and will likely require an almost full rewrite of a grown, business critical (and already heavily optimized) application.
    - mixmastamyk 4y ago
      Prototyping in Python, then rewriting the performance critical parts in a speedier more difficult language is one of the most efficient paths a project could take.
- Sohcahtoa82 4y ago
  I knew Python decently well before I ever played with Ruby. Ruby to me feels like a very ugly version of Python. It's like Python and Perl had a baby, and I have very strong negative opinions of Perl's syntax. It baffles me how a language that people jokingly refer to as a "write-only" language ever got any sort of ground.
- bushbaba 4y ago
  Python is easier to use if you come from a C/C++ style coding background.
dspillett 4y ago
> people will finally accept that Python and JavaScript are no longer young languages > JavaScript is 26 years old, Python is 31 I can't speak for Python, but Javascript has changed¹ massively in recent years, more so (I expect) than Fortran or COBOL every did in their active history. It could be argued that what we have now is a younger language with the same name. > but I'd bet my bottom dollar that they'll at least remain as relics yet needing support This I definitely agree with, though I suspect less so than Fortran/COBOL/similar. It is much cheaper to rebuild these days, and so many other things change around your projects², and there are more forces pushing for change such as a legion of external security concerns. That will add up to there being far fewer projects³ left to be maintained that haven't been redone in something new, because they fall into the comfy gap between the cushions of “it still works, don't touch it” and “it is far more hassle to replace than to live with as-is”. ---- [1] the core language is still the same, but there is so much wrapped around it from the last decade or so that I suspect someone who learned it fresh recently would struggle initially on EcmaScript 3 or before/equivalent. [2] where a Fortan/COBOL project might live for all its decades on the same hardware using the same library versions. [4] no absolutely fewer of course, but relative to the number of people capable of working on them – much of the price commanded by legacy COBOL work is due to very few having trained on the language in decades and many of those that did earlier being fully not-coming-back-for-any-price retired or no longer capable at all (infirm or entirely off this mortal coil), so those remaining in appropriate health and available are in demand despite a relatively small number of live projects.
- shagie 4y ago
  Fortran77 vs Fortran90 were fairly different languages that required a substantial revision to the numerical methods assignments that I had in the early 90s as the department shifted from one to the other. https://www.nsc.liu.se/~boein/f77to90/f77to90.html https://www.nsc.liu.se/~boein/f77to90/f77to90.html > There are now two forms of the source code. The old source code form, which is based on the punched card, and now called fixed form and the new free form. > ... > A completely new capability of Fortran 90 is recursion. Note that it requires that you assign a new property RESULT to the output variable in the function declaration. This output variable is required inside the function as the "old" function name in order to store the value of the function. At the actual call of the function, both externally and internally, you use the outer or "old" function name. The user can therefore ignore the output variable.
greyhair 4y ago
Python3 yes, but Python2 will have faded away. Perl! Oh, poor Perl. Python 3, or its children, will be around a long time. As will some version of /bin/sh
- kjs3 4y ago
  Yes, Perl certainly took an odd turn on their 'next gen version of the language' journey, but I'm willing to bet there will be a Perl community running 5.247.2 or some such decades from now, alongside sh, awk & sed.
- still_grokking 4y ago
  > As will some version of /bin/sh I hope not! That's one of the things I pray every day to go away. (Even I don't believe in any gods, and am a Linux-only user for the last 20 years). The Unix shell language is one of the most horrific legacy technologies that are still around. I really wish it dies soon™ and gets replaced finally by something sane!
  - high_5 4y ago
    It won't because it's too close to human interaction.
    - still_grokking 4y ago
      I don't get this argument. UIs changed in the past, and still change the whole time. Why would shell be any different?

jacobr1 4y ago

> there is nothing on the horizon which will plausibly replace it I'm not going to be making any bets - but the one project that has possibility is WASM. A mature, polyglot ecosystem on top of WASM runtimes with web-apis seem like it could displace JS in browser as #1.

chrisco255 4y ago
Probably not. Unless you're rendering to another target besides the DOM (ie canvas) I doubt you see JS displacement as #1 in the browser. JS is not the performance bottleneck, the DOM itself is. And in the meantime, you've got 25 years of example code, component libraries, talent development, dev productivity tooling, browser integration, etc built up around it. And unlike other operating systems, the browser does not give you any kind of standard library of reasonably good components to build on. So the sheer size and volume of components and the ecosystem built up around npm well be an uphill battle for any WASM target language to compete with.
- deleted 4y ago
  [deleted]
- johnnyanmac 4y ago
  >Unless you're rendering to another target besides the DOM (ie canvas) I doubt you see JS displacement as #1 in the browser. if we're talking on the level of 20,30,50 years, we may in fact be able to move away from a DOM-based web. and WASM is simply a binary spec, so it can adjut with whatever comes on the horizon. We've had similar sized giants rise and fall in that span.
still_grokking 4y ago
Almost no languages run as WASM. This is not likely to change anytime soon (if ever), as nobody is working on this, and there is even quite strong opposition to get features in that are fundamentally needed to run anything else than the very few languages that already compile to WASM. ("Nobody" is interested in invalidating their investment in JS ;-)). Also WASM is actually slow, or better said, "it does not deliver its full potential". It will need advanced JIT compilers to keep up with the other two mayor VM langues. But in this regard WASM is behind around 20 years of constant development and improvement. My strongest hopes in this regard are currently with Microsoft (even I don't trust this company at all!), who are indeed interested to run their CLR stuff in a WASM VM, and could probably deliver on the needed features. But then, when you would run a CLR-VM (or a JVM) on top of a WASM VM, you know, you're building just the next Matryoshka… There are no real benefits to that besides "look mom, it runs in the browser".

sergiotapia 4y ago

Why did Python win the war with Ruby? Was it purely the math community deciding this is where we throw our weight and left Ruby the runt of the litter?

Shorel 4y ago
Performance. So many people say it doesn't matter. Until it does. Python works around it by having so many libraries built in C or C++.
- still_grokking 4y ago
  > Python works around it by having so many libraries built in C or C++. Which works quite fine, until it doesn't. By than the needed rewrite in some language that delivers decent performance and safety all over the place in one package will be very expensive. I'm not saying that you should avoid Python (and its native code kludge) altogether but when using it just pray that you never reach that point mentioned above. It's a dead end and will likely require an almost full rewrite of a grown, business critical (and already heavily optimized) application.
  - mixmastamyk 4y ago
    Prototyping in Python, then rewriting the performance critical parts in a speedier more difficult language is one of the most efficient paths a project could take.
Sohcahtoa82 4y ago
I knew Python decently well before I ever played with Ruby. Ruby to me feels like a very ugly version of Python. It's like Python and Perl had a baby, and I have very strong negative opinions of Perl's syntax. It baffles me how a language that people jokingly refer to as a "write-only" language ever got any sort of ground.
bushbaba 4y ago
Python is easier to use if you come from a C/C++ style coding background.

dspillett 4y ago

> people will finally accept that Python and JavaScript are no longer young languages > JavaScript is 26 years old, Python is 31 I can't speak for Python, but Javascript has changed¹ massively in recent years, more so (I expect) than Fortran or COBOL every did in their active history. It could be argued that what we have now is a younger language with the same name. > but I'd bet my bottom dollar that they'll at least remain as relics yet needing support This I definitely agree with, though I suspect less so than Fortran/COBOL/similar. It is much cheaper to rebuild these days, and so many other things change around your projects², and there are more forces pushing for change such as a legion of external security concerns. That will add up to there being far fewer projects³ left to be maintained that haven't been redone in something new, because they fall into the comfy gap between the cushions of “it still works, don't touch it” and “it is far more hassle to replace than to live with as-is”. ---- [1] the core language is still the same, but there is so much wrapped around it from the last decade or so that I suspect someone who learned it fresh recently would struggle initially on EcmaScript 3 or before/equivalent. [2] where a Fortan/COBOL project might live for all its decades on the same hardware using the same library versions. [4] no absolutely fewer of course, but relative to the number of people capable of working on them – much of the price commanded by legacy COBOL work is due to very few having trained on the language in decades and many of those that did earlier being fully not-coming-back-for-any-price retired or no longer capable at all (infirm or entirely off this mortal coil), so those remaining in appropriate health and available are in demand despite a relatively small number of live projects.

shagie 4y ago
Fortran77 vs Fortran90 were fairly different languages that required a substantial revision to the numerical methods assignments that I had in the early 90s as the department shifted from one to the other. https://www.nsc.liu.se/~boein/f77to90/f77to90.html https://www.nsc.liu.se/~boein/f77to90/f77to90.html > There are now two forms of the source code. The old source code form, which is based on the punched card, and now called fixed form and the new free form. > ... > A completely new capability of Fortran 90 is recursion. Note that it requires that you assign a new property RESULT to the output variable in the function declaration. This output variable is required inside the function as the "old" function name in order to store the value of the function. At the actual call of the function, both externally and internally, you use the outer or "old" function name. The user can therefore ignore the output variable.

greyhair 4y ago

Python3 yes, but Python2 will have faded away. Perl! Oh, poor Perl. Python 3, or its children, will be around a long time. As will some version of /bin/sh

kjs3 4y ago
Yes, Perl certainly took an odd turn on their 'next gen version of the language' journey, but I'm willing to bet there will be a Perl community running 5.247.2 or some such decades from now, alongside sh, awk & sed.
still_grokking 4y ago
> As will some version of /bin/sh I hope not! That's one of the things I pray every day to go away. (Even I don't believe in any gods, and am a Linux-only user for the last 20 years). The Unix shell language is one of the most horrific legacy technologies that are still around. I really wish it dies soon™ and gets replaced finally by something sane!
- high_5 4y ago
  It won't because it's too close to human interaction.
  - still_grokking 4y ago
    I don't get this argument. UIs changed in the past, and still change the whole time. Why would shell be any different?