5 ms·

The interesting bit about this post is that with that resume, you can still feed a family in 2022 (okay, you won't need any assembler, and one from the set { Fo

by jll29 4y ago

The interesting bit about this post is that with that resume, you can still feed a family in 2022 (okay, you won't need any assembler, and one from the set { Fortran, COBOL } will do). I wonder if Python and JavaScript will get you that far 50 years from now?

Lio 4y ago
Hard to say for sure but I'd bet that Unix/Linux/Posix and SQL skills might still be relevant.
gautamdivgi 4y ago
Java probably will for application development. Python should to with all that ML code. I don’t see anyone in a hurry to move it to Julia. C++ also, if you’re in the embedded space. I know Rust is coming but I don’t think c++ is going anywhere for a while.
- arecurrence 4y ago
  There's so much production code in C++ that it will have a long tail like Fortran even if people were to stop launching new products with it.
wyattpeak 4y ago
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.
- 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?
  - bushbaba 4y ago
    Python is easier to use if you come from a C/C++ style coding background.
    - azangru 4y ago
      Could you point out specific parts of python that are easier for someone with C/C++ background as opposed to Ruby? I remember starting with Ruby (after rudimentary CS50-level C), and finding it quite reasonable and logical, and nicer than python. I still think it's nicer than python, although I've long since stopped using it.
      - shagie 4y ago
        I believe the issue isn't so much "vanilla python" vs "vanilla ruby" for a developer coming from a C background but rather that ruby's programming style leads to a significant bit of meta programming which (aside from being a bit of a challenge to get one's head around) leads various shops and frameworks having built their own DSL for writing ruby. Open classes give me the security heebie jeebies. irb(main):001:0> "foo".bar (irb):1:in `<main>': undefined method `bar' for "foo":String (NoMethodError) from /usr/local/lib/ruby/gems/3.1.0/gems/irb-1.4.1/exe/irb:11:in `<top (required)>' from /usr/local/bin/irb:25:in `load' from /usr/local/bin/irb:25:in `<main>' irb(main):002:1* class String irb(main):003:2* def bar irb(main):004:2* "foobar!" irb(main):005:1* end irb(main):006:0> end => :bar irb(main):007:0> "foo".bar => "foobar!" irb(main):008:0> On one hand, that's really neat. On the other hand, the ability to add or modify a method in a system class is not something that I'd want near production code. I'm sure that other orgs have sufficient checks and style guide to prevent something from creeping in... but that sort of flexibility in the language is something that I'd prefer to stay away from if I want to be able to reason about ruby code. See also Ruby Conf 2011 Keeping Ruby Reasonable by Joshua Ballanco https://youtu.be/vbX5BVCKiNs https://youtu.be/vbX5BVCKiNs which gets into first class environments and closures.
- 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".
latchkey 4y ago
I've been writing code professionally for over 25 years now (and I'm 49). I feel like I could keep writing code for the rest of my life. 50 years doesn't sound like that long.
- bitwize 4y ago
  It's not. Hug your parents, spend time with your family. If you must code, do so on something you really feel strongly about from here on out.
  - latchkey 4y ago
    Funny enough, I did exactly that. During covid, I bought the dip and moved to a place that is 100' away from my dads house. I get to see him every day now. I feel very lucky.
- dn3500 4y ago
  I wrote code professionally for 40 years before retiring. Toward the end I was also doing a lot of non-code crap but I always resisted the push toward any kind of management. I am quite happy at how my career turned out.
jcadam 4y ago
There'll be plenty of legacy Java EE apps in need of maintenance. Not fun work, but it'll pay.
shubhamjain 4y ago
> I wonder if Python and JavaScript will get you that far 50 years from now? AngularJS itself singularly powers surprisingly large number of Enterprise applications. So even assuming the unlikely scenario that those languages are dead, and the only useful work is from dinosaurian companies who was too slow to switch, the answer would still be yes. :)
bee_rider 4y ago
I must be looking in the wrong places, but I don't have the feeling that Fortran on my Resume has really helped me a ton. Fortran is a fine language and of course "real programmers can write a Fortran program in any language," but it is hard to compete with the breadth of C++.
taude 4y ago
Python has been in use since before I graduated college. I supported a code base written in Python at event Microsoft back then (they acquired a company that wrote their product in Python, and then ported it over to C++/COM). We all had one of the something like 1.4 O'Reilly books, even. And I think one person from the team went on to write/support/somehow be involved in Subversion SCM (which was heavily written in Python). ....so Python has been around, used in product, by large companies, for a long time. I don't see it going anywhere in the next 20 years.
- mfuzzey 4y ago
  I think you probably mean mercurial (hg) which is indeed written in python. Subversion (svn) is written in C. Mercurial actually wasn't a bad choice at the beginning of the DVCS era on Windows as git didn't work well on that platform initially.
sbf501 4y ago
Probably not. Lots of "critical" software is re-written frequently. I met the head of IT at Target during a presentation he gave on how they switched from PHP to NodeJS (~2012). I took a year to migrate the entire ERP solution to NodeJS (plus frontend). Just like that, PHP was gone. If the entire ERP can be re-written that quickly, then if a better language comes along, it will displace the Node infra. What didn't change? SQL.
- utexaspunk 4y ago
  SQL is pretty darn perfect for its purpose. As long as databases exist, SQL will exist. It is also super easy and intuitive to learn- I taught myself and it has been my bread and butter for the ~17 years since .
  - opportune 4y ago
    SQL will always exist as a lingua Franca for data because its declarative nature lets anybody immediately start using a new database/data tool just knowing basic SQL. At the same time, it’s far from perfect for all use cases - it can be much easier to write certain queries imperatively than declaratively. I can envision a future in which databases are primarily used imperatively while still supporting SQL for those who want to use it.

by jll29 4y ago

Lio 4y ago

Hard to say for sure but I'd bet that Unix/Linux/Posix and SQL skills might still be relevant.

gautamdivgi 4y ago

Java probably will for application development. Python should to with all that ML code. I don’t see anyone in a hurry to move it to Julia. C++ also, if you’re in the embedded space. I know Rust is coming but I don’t think c++ is going anywhere for a while.

arecurrence 4y ago
There's so much production code in C++ that it will have a long tail like Fortran even if people were to stop launching new products with it.

wyattpeak 4y ago

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.

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?
- bushbaba 4y ago
  Python is easier to use if you come from a C/C++ style coding background.
  - azangru 4y ago
    Could you point out specific parts of python that are easier for someone with C/C++ background as opposed to Ruby? I remember starting with Ruby (after rudimentary CS50-level C), and finding it quite reasonable and logical, and nicer than python. I still think it's nicer than python, although I've long since stopped using it.
    - shagie 4y ago
      I believe the issue isn't so much "vanilla python" vs "vanilla ruby" for a developer coming from a C background but rather that ruby's programming style leads to a significant bit of meta programming which (aside from being a bit of a challenge to get one's head around) leads various shops and frameworks having built their own DSL for writing ruby. Open classes give me the security heebie jeebies. irb(main):001:0> "foo".bar (irb):1:in `<main>': undefined method `bar' for "foo":String (NoMethodError) from /usr/local/lib/ruby/gems/3.1.0/gems/irb-1.4.1/exe/irb:11:in `<top (required)>' from /usr/local/bin/irb:25:in `load' from /usr/local/bin/irb:25:in `<main>' irb(main):002:1* class String irb(main):003:2* def bar irb(main):004:2* "foobar!" irb(main):005:1* end irb(main):006:0> end => :bar irb(main):007:0> "foo".bar => "foobar!" irb(main):008:0> On one hand, that's really neat. On the other hand, the ability to add or modify a method in a system class is not something that I'd want near production code. I'm sure that other orgs have sufficient checks and style guide to prevent something from creeping in... but that sort of flexibility in the language is something that I'd prefer to stay away from if I want to be able to reason about ruby code. See also Ruby Conf 2011 Keeping Ruby Reasonable by Joshua Ballanco https://youtu.be/vbX5BVCKiNs https://youtu.be/vbX5BVCKiNs which gets into first class environments and closures.
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".

latchkey 4y ago

I've been writing code professionally for over 25 years now (and I'm 49). I feel like I could keep writing code for the rest of my life. 50 years doesn't sound like that long.

bitwize 4y ago
It's not. Hug your parents, spend time with your family. If you must code, do so on something you really feel strongly about from here on out.
- latchkey 4y ago
  Funny enough, I did exactly that. During covid, I bought the dip and moved to a place that is 100' away from my dads house. I get to see him every day now. I feel very lucky.
dn3500 4y ago
I wrote code professionally for 40 years before retiring. Toward the end I was also doing a lot of non-code crap but I always resisted the push toward any kind of management. I am quite happy at how my career turned out.

jcadam 4y ago

There'll be plenty of legacy Java EE apps in need of maintenance. Not fun work, but it'll pay.

shubhamjain 4y ago

> I wonder if Python and JavaScript will get you that far 50 years from now? AngularJS itself singularly powers surprisingly large number of Enterprise applications. So even assuming the unlikely scenario that those languages are dead, and the only useful work is from dinosaurian companies who was too slow to switch, the answer would still be yes. :)

bee_rider 4y ago

I must be looking in the wrong places, but I don't have the feeling that Fortran on my Resume has really helped me a ton. Fortran is a fine language and of course "real programmers can write a Fortran program in any language," but it is hard to compete with the breadth of C++.

taude 4y ago

Python has been in use since before I graduated college. I supported a code base written in Python at event Microsoft back then (they acquired a company that wrote their product in Python, and then ported it over to C++/COM). We all had one of the something like 1.4 O'Reilly books, even. And I think one person from the team went on to write/support/somehow be involved in Subversion SCM (which was heavily written in Python). ....so Python has been around, used in product, by large companies, for a long time. I don't see it going anywhere in the next 20 years.

mfuzzey 4y ago
I think you probably mean mercurial (hg) which is indeed written in python. Subversion (svn) is written in C. Mercurial actually wasn't a bad choice at the beginning of the DVCS era on Windows as git didn't work well on that platform initially.

sbf501 4y ago

Probably not. Lots of "critical" software is re-written frequently. I met the head of IT at Target during a presentation he gave on how they switched from PHP to NodeJS (~2012). I took a year to migrate the entire ERP solution to NodeJS (plus frontend). Just like that, PHP was gone. If the entire ERP can be re-written that quickly, then if a better language comes along, it will displace the Node infra. What didn't change? SQL.

utexaspunk 4y ago
SQL is pretty darn perfect for its purpose. As long as databases exist, SQL will exist. It is also super easy and intuitive to learn- I taught myself and it has been my bread and butter for the ~17 years since .
- opportune 4y ago
  SQL will always exist as a lingua Franca for data because its declarative nature lets anybody immediately start using a new database/data tool just knowing basic SQL. At the same time, it’s far from perfect for all use cases - it can be much easier to write certain queries imperatively than declaratively. I can envision a future in which databases are primarily used imperatively while still supporting SQL for those who want to use it.