12 ms·

I'm starting to long for a stack that doesn't constantly change. Just set the features and that's it. Security updates only after that. It feels like a constant

I'm starting to long for a stack that doesn't constantly change. Just set the features and that's it. Security updates only after that. It feels like a constant grind keeping up with everything. Containers, clouds, programming languages, operating systems, frontend frameworks, transfer protocols, it seems like it takes so much effort to just build something and keep it going. That Python 2 is still around doesn't really surprise me. Many of the projects that were built upon it were built by non-developers (scientists, etc) that have no strong reason to keep everything current.

evmar 7y ago
Go has a compatibility promise from 2012 that they've upheld for now seven years. They are still discussing whether to change something in Go 2. https://golang.org/doc/go1compat https://golang.org/doc/go1compat
- majewsky 7y ago
  > They are still discussing whether to change something in a backwards-incompatible way in Go 2. FTFY
- sadfklsjlkjwt 7y ago
  Fortran from the 1980s is still supported...
  - cik 7y ago
    Hell, I fixed something in Turing last week. My eyes are still bleeding.
  - pletnes 7y ago
    You misspelled the 1960s.
  - gowld 7y ago
    And yet almost no one chooses to write new Fortran code for applications. We rely on a few ancient critical widely used libraries like BLAS, accessed from non-Fortran programs.
    - greglindahl 7y ago
      This is not true, there are niches where Fortran is still dominant for new code. Also for BLAS, the underlying code is usually no longer Fortran.
  - greglindahl 7y ago
    Fortran from the 1960s is still supported. Almost all modern Fortran compilers support syntax that was deprecated decades ago.
- petre 7y ago
  They probably do not want to end up with a Perl 6 situation. I meant Raku, the language formally known as Perl 6.
- giancarlostoro 7y ago
  I came to say this. I learned Go in the early years and have come back after not touching it in years and it all still sounds eerily familiar and a lot of the basics I learned are still relevant to what I do. Go is good at being Pythonic in some senses too. Some would say to a fault.
VectorLock 7y ago
I think Python 2 had hit the perfect balance of "just enough but not too much" which I'm very deeply worried that Python 3 is going to deviate from.
- novok 7y ago
  Python 3 is barely different in my experience and it's been about 10 years at this point. I do enjoy some of the "new" features of python 3.
  - rabidrat 7y ago
    I used `async` as the name of a function decorator in some Python3.4 code, which then broke in 3.6 which introduced `async` as a keyword.
    - zerkten 7y ago
      What was the level of effort to remediate that?
      - takeda 7y ago
        sed 's/async/whatever' ...
      - rabidrat 7y ago
        Probably around 4-6 hours of work all told. We had to come up with a new name, do a find/replace, review the changes, test, fix a couple of issues because the replace wasn't perfect/complete, update the dev documentation, make a new patch release, and then create packages for the various supported platforms. Oh and looking back over it now, the filename had to be changed too, because apparently you can't use a keyword as a module name in Python either. So where the documentation linked directly to that file, that had to be updated as well. [1] https://github.com/saulpw/visidata/issues/164 https://github.com/saulpw/visidata/issues/164 [2] https://github.com/saulpw/visidata/releases/tag/v1.2.1 https://github.com/saulpw/visidata/releases/tag/v1.2.1
  - 7y ago
MisterBastahrd 7y ago
One day tech historians are gonna look back at this era and shake their heads at all the time, energy, and talent being wasted by people just trying to keep up with tech trends for the sheer purpose of remaining employable.
- blauditore 7y ago
  I don't think it's that bad. I've never heard of someone who got fired because they didn't know the latest JS framework. Also, new tech trends are not just hot air, there's also a lot of innovation happening. You just have to see through the hype and wait until the dust settles.
  - zerkten 7y ago
    There is also the situation that someone gets hired for their tech skills, but the thing that keeps them in a job is their ability to pick up the domain. The tech choices are often point in time decisions which are irrelevant to any outcome. The domain knowledge builds is worth more than any framework knowledge. If you are successfully (i.e. the business or product keeps being developed) you still need to be aware of the internal weaknesses of your original choices and the external opportunities of updating to something more modern. The challenge is in managing the transition which is a skill in itself.
  - Rychard 7y ago
    > I've never heard of someone who got fired because they didn't know the latest JS framework. Sure, but I've worked with a number of individuals who have either resigned (on their own), or have been let go, solely because they had no desire or interest in keeping up with their craft. I think that's effectively the same thing, though. Ultimately, the notion of not wanting to stay abreast of the current industry trends is neither something I can relate to, nor is it something I see as being compatible with one's employability.
  - mcguire 7y ago
    How many haven't been hired because they didn't know the latest JS framework? Reinventing wheels isn't innovation, particularly if the reinvention isn't round.
alanfranz 7y ago
Honestly: the Java environment is exceedingly good at that. Backwards incompatible changes are truly minimal, and only those that are strictly necessary are added. And since Java 8 the language is pretty nice and offers good functional idioms. Of course, major versions of libraries still change. But there's no match with the JS approach.
- lvh 7y ago
  I agreed until the disaster that was Jigsaw. Maybe Jigsaw didn't impact you particularly hard, but you can't argue the JVM has a policy of minimal backwards incompatible changes given that debacle.
  - chrisseaton 7y ago
    I work on Java at a really deep level, and I haven't had to interact with Jigsaw at all. What is it breaking for you?
    - brabel 7y ago
      A lot of things like older versions of Gradle (which at some point was a blocker to move to Java 9, but not now), Groovy (also fixed, but still has some warnings), which we use heavily for tests, several reflection-heavy frameworks (think dependency injection, annotation-processors etc), which to this day require some ugly hacks like --patch-module to "open" packages, JUnit tests (which also need the same hacks to work), even the location of resources loaded with class.getResource() had to be modified when modularizing a jar, so that resources go into the proper packages that are visible to the loader... You seriously didn't suffer any of these?
      - chrisseaton 7y ago
        No I didn’t experience any issues like that myself.
  - dhash 7y ago
    I’m a full time scala developer and have had basically no problems taking longer than a day to in moving to the LTS releases of 9+. It’s probably pretty helpful that the scala ecosystem doesn’t depend much on non-well trodden parts of the JDK
dexen 7y ago
Surprisingly enough, PHP is a good example of environment that doesn't break backward compatibility much. About the only change that had a significant impact on projects I worked on was removal of the 'mysql' DB extension (replaced by 'mysqli' and 'PDO'). For an older project I created a few shim functions and it still works just fine. While frameworks come and go, the core of the language is highly backward compatible. The choices made early on were in the UNIX style, so they were right. To quote an earlier post[1], -- There is something to be said about PHP's staying power. The early versions of the language weren't considered "right". Except maybe they were right for the problem at hand. The way I see it was PHP captured the vector of change, and left ample room for future developments. Both internal changes (hello, bytecode; hello, JIT), language level features (hi there, namespaces), and runtime level features (oh hai, countless built in classes and functions). Moreover, unlike many framework that shone brightly and burned out quickly (Rails?), PHP captured the essence of the environment: HTTP is stateless, and URLs aren't uniformly routable from either end, and well-formed HTML/XML/JSON is just a subset of tag soup. Worse is better. -- [1] https://news.ycombinator.com/item?id=19536132 https://news.ycombinator.com/item?id=19536132
- dannypgh 7y ago
  If your timeframe goes back to PHP4, this most certainly isn't true. Just one glance of https://www.php.net/manual/en/reserved.keywords.php https://www.php.net/manual/en/reserved.keywords.php should prove this - every new keyword is a backwards incompatible change. And I mention this because I used to support software that used, as a variable name, something which became a reserved word...
  - lowercased 7y ago
    as a variable name, wouldn't it have been prefixed with $ ? the XML parsing was probably the biggest BC change I hit between 4 and 5.
    - dannypgh 7y ago
      I think I'm misremembering and they were method names. I believe it was clone, in fact.
ashton314 7y ago
Elixir 1.9 came out. No future core language changes are planned. There are no intentions of creating an Elixir 2.0. There will still of course be regular improvements and updates, but the core language is basically set. Read about it here: https://elixir-lang.org/blog/2019/06/24/elixir-v1-9-0-released/ https://elixir-lang.org/blog/2019/06/24/elixir-v1-9-0-releas...
- elcritch 7y ago
  If Elixir wasn’t an option for me, Clojure would be my next option. Clojure seems like it has a similar philosophy, and builds on a dynamic immutable core. That being said I like writing code that can feel “done”. No “I wish I could refactor this object hierarchy to make it easier to use, etc” notions in the back of my mind. Not every piece of code is like that, but enough.
novok 7y ago
Java is fairly stable I've found. Just get away from javascript and once in 20 year platform language changes like swift and most platforms don't have that much churn.
vintagedave 7y ago
Delphi still lets you build programs that used to run on Windows 3 with minimal changes, and definitely anything 32-bit. It's part of the value proposition: the language and libraries are planned for forward compatibility and stability for use ten years in the future, as well as now.
- FpUser 7y ago
  Actually there were some problems (very long procedures I think would be one example). Other then that compatibility shines.
- smush 7y ago
  To save others the same DDG search I did -> Delphi is a Pascal language IDE that compiles to native Windows binaries. Apparently there is this thing called Lazarus that is a free version of it?
  - FpUser 7y ago
    FreePascal is language/compiler and Lazarus is an IDE. Lazarus IDE runs on all major platforms and produces native code. Suitable for anything starting from system code and up to complex GUI apps.
hirundo 7y ago
> I'm starting to long for a stack that doesn't constantly change. I looked up "engraving marble" to find an example of the above, but no luck there: They use lasers for that now.
adamkl 7y ago
As I get older and crankier I find simplicity and stability become a lot more interesting than reinventing the same wheels over and over again. This is probably why I’ve come to appreciate Rich Hickey’s talks more and more as years go by. I think Clojure is a good fit when it comes to stability as per their own development guidelines [1]: The Clojure development team values a measured and thoughtful approach to language evolution with a strong emphasis on maintaining backward compatibility. [1] https://clojure.org/dev/dev https://clojure.org/dev/dev
- finalfantasia 7y ago
  To anyone who's interested in this topic, I strongly recommend this talk from Rich Hickey about "giving something to somebody that they can use and making a commitment": Spec-ulation (https://www.youtube.com/watch?v=oyLBGkS5ICk https://www.youtube.com/watch?v=oyLBGkS5ICk)
Alupis 7y ago
> I'm starting to long for a stack that doesn't constantly change Come on over to Javaland, it's nice, warm, and the sun is always shining! With the exception of the Java 8 -> Java 11 transition (skipping the non-LTS versions), things are pretty stable. You don't have to use any new-fangled features if you don't want... and your Java 3 code compiled nearly 20 years ago will still run just fine on modern JVM's.
- anoncake 7y ago
  > Come on over to Javaland, it's nice, warm, and the sun is always shining! My oracle predicts much worse weather.
  - Alupis 7y ago
    > My oracle Funny joke, but Oracle is all but out of the equation at this point. They've stepped back and become yet another JVM vendor that takes OpenJDK source and compiles it into a binary for users, sprinkled with some special sauce here and there, and just happens to charge for support. That puts them in line with Azul, IBM, Amazon, AdoptOpenJDK Project, SAP, Red Hat, and a ton more. You get your pick of JVM vendors now... That's a fantastic thing for Java.
- gowld 7y ago
  Python 2 (the OP topic) from 2000 still works too. Running code is the easy part. Writing it is the hard part. And if running on a VM is your standard, my old DOS programs still run on DOSBox :-)
jasonpeacock 7y ago
The world keeps moving, if you don't want to move with it then pick something that has already stopped. Maybe C? Cobol? Ada? Fortran? Though even those languages have modern flavors & updates... We make progress because we learn, not just new technology, bu new approaches to old problems. When I see an "old" programmer who keeps writing C89 code because "it still works", it is painful to see them rejecting decades of learnings about how to write better software.
nine_k 7y ago
Have you tried Fortran? C also shows excellent stability and backwards compatibility. Cobol is also quite stable, but IDK about the quality of open-source tools for it. The problem of stability is that you are pinned to the moment when the interfaces were defined and committed to, and this moment goes further and further into the past. Quite often this means that you can't use the new things which give advantage to your competitors.
ceronman 7y ago
Use C. Standardized since the 80s, it has had only minor, backwards compatible revisions in 99 and 11. According to the TIOBE index, it's the second most popular language in the world. It works on almost any platform imaginable and it has decades of tooling available for it. Of course it doesn't have any of the good new things developed recently, but if it's stability what you look for, then I don't see a better option.
- kbenson 7y ago
  Or Perl. Perl takes backwards compatibility very seriously. There was a lot of gnashing of teeth a while back on whether to make newer versions actually change the default behavior finally to some new features could be opt-out instead of opt-in. An by new features, I mean stuff like "use strict", which has been best practice for a couple decades now, but the change would cause problems for existing scripts that didn't turn that feature on. The rule has generally been that you can take a 20 year old Perl script and it will still just run. This has its own complications though, as it makes it harder to advance the language, and then people feel it's being left behind (the Perl 6 stuff came after that feeling developed). It's a longstanding problem in language design and communities, stability vs advancement.
  - theamk 7y ago
    Unless it uses CPAN stuff, or calls out to external tools. Those are often needed for key functionality, and they get stale much faster than perl itself.
    - kbenson 7y ago
      The old versions of modules are available, if you don't happen to have the exact same code present. Core modules are all I would worry about, but I'm pretty sure those are held to the same standard as far as backwards compatibility. One or two modules might have been ejected from core or moved into core, but those should be easily found on CPAN as well. In the end, getting something working from scratch on a newer Perl that has a lot of CPAN dependencies (as opposed to just updating Perl) might be a little annoying in that you have to track down all the module versions, but it's far from impossible, or even all that hard. For example, the CGI module[1], which was a core module but historically seen as fairly bad (at least as of now, and at least in some of its uses, it supported a wide set of use cases), it was removed from core and housed on CPAN. If you follow the link provided and check the past versions (dropdown as part of the module path and name), you'll see there are many versions shown, possibly every public version, and going back to 1998 for CPAN, and 1995 for 1995 for the BackPAN. Each of those is visible as an item with it's documentation at the time and the module available to download and use. You can also access the CPAN testing matrix[2], and if you dig around you can actually find the results for some tests back in 1999.[3] If I was responsible for getting some old Perl app to run on a more modern system, I would by much more worried about the OS changing in a complex way than I would about getting the Perl code to run again as expected. Which is to say, I wouldn't be worried much at all. 1: https://metacpan.org/release/CGI https://metacpan.org/release/CGI 2: http://matrix.cpantesters.org/?dist=CGI+4.44 http://matrix.cpantesters.org/?dist=CGI+4.44 3: http://matrix.cpantesters.org/?dist=CGI%202.55 http://matrix.cpantesters.org/?dist=CGI%202.55
toast0 7y ago
You want to find a stack that's small / concise / organized enough that you could support it if you needed to. It's ideal if it has a stable community, but it should be a small group of core devs, so they don't have time to change things that aren't broken. It helps if the community has a culture of stability. In my experience, FreeBSD and Erlang fit this bill. You may need to manage some small changes now and again when upgrading between releases, but generally the most apparent changes are things you were doing before work better. And you can run a fleet with rather divergent versions, as long as you're careful not to use new features (it helps to make sure your dev environment matches your most out of date hosts)
didibus 7y ago
Clojure has had only a single backward breaking change since its creation in 2008, it took 10 full years before being introduced, and it was a pretty minor one at that. Java and the JVM themselves value backward compatibility, and I'd say Clojure takes it a notch above that.
- ollran 7y ago
  I guess I have missed that. What was the change?
  - didibus 7y ago
    When they added clojure.spec. It started validating macros at compile time. If you were previously using an illegal syntax, but that somehow didn't cause any issues, those would now throw a compile time error. Overall it was for the best, since prior to that it was just weird code that had a bit of a undefined behavior since it wasn't using the macro in the proper way. But it still meant we had to go and fix a few of them so they compiled again. Though in the process we realized that we were misusing the macros to begin with.
TeMPOraL 7y ago
Try Common Lisp. The language has an ANSI standard, published in 1994. So the base has been stable and fixed for the past 25 years. A lot of Lisp code that old or even older works perfectly fine on a current CL implementation.
- sedachv 7y ago
  Not only that, the "Common" in Common Lisp is a reference to a standardization of several existing dialects, so a lot of Lisp code from the 1960s and the 1970s will run without any modifications.
gowld 7y ago
Python 2 is 19 years old. Python 3 is 11 years old. 11 years is a long time to married to the bugs of the past. 20 years is a long time to be married to a fixed language.
b0rsuk 7y ago
Sounds like mathematics.
beerandt 7y ago
FORTRAN?
crimsonalucard 7y ago
Then how do you improve? Currently there is no all encompassing theory for the design of languages or anything. So there's no prove-able way to design a language that can always be improved and always be backward compatible. I imagine that such a language would be incredibly simple. Minimal syntax and all sugar and conveniences would be built with libraries.
jeandejean 7y ago
Can't you just ignore those comments?
RcouF1uZ4gsC 7y ago
I think you are looking for COBOL.
keymone 7y ago
Lots of people say Java but of the more fancy and convenient (and correct, cough I’m obviously biased cough) ways to do development, I can’t stress enough how amazing it has been to watch release after release of Clojure consisting of mostly trivial changes or library additions. The language is arguably complete and any syntactic changes you could wish upon yourself are doable in form of a library because it’s a lisp. And all that piggybacks on top of already quite stable java ecosystem. Can’t get much better than that.
RangerScience 7y ago
I feel like pure Ruby meets this. I've been using Sinatra for years, it's been basically the same that entire time, and the language feels pretty stable in my usage (some nice added things, like stabby syntax and `.then`, but those are really just sugar). Rails is so-so.
leshow 7y ago
I think the only option there is C. It hasn't changed much for a long time, for better or worse.
WalterBright 7y ago
> I'm starting to long for a stack that doesn't constantly change. Just set the features and that's it. I hear every day: don't change a thing in D, just add these two features.

evmar 7y ago

Go has a compatibility promise from 2012 that they've upheld for now seven years. They are still discussing whether to change something in Go 2. https://golang.org/doc/go1compat https://golang.org/doc/go1compat

majewsky 7y ago
> They are still discussing whether to change something in a backwards-incompatible way in Go 2. FTFY
sadfklsjlkjwt 7y ago
Fortran from the 1980s is still supported...
- cik 7y ago
  Hell, I fixed something in Turing last week. My eyes are still bleeding.
- pletnes 7y ago
  You misspelled the 1960s.
- gowld 7y ago
  And yet almost no one chooses to write new Fortran code for applications. We rely on a few ancient critical widely used libraries like BLAS, accessed from non-Fortran programs.
  - greglindahl 7y ago
    This is not true, there are niches where Fortran is still dominant for new code. Also for BLAS, the underlying code is usually no longer Fortran.
- greglindahl 7y ago
  Fortran from the 1960s is still supported. Almost all modern Fortran compilers support syntax that was deprecated decades ago.
petre 7y ago
They probably do not want to end up with a Perl 6 situation. I meant Raku, the language formally known as Perl 6.
giancarlostoro 7y ago
I came to say this. I learned Go in the early years and have come back after not touching it in years and it all still sounds eerily familiar and a lot of the basics I learned are still relevant to what I do. Go is good at being Pythonic in some senses too. Some would say to a fault.

VectorLock 7y ago

I think Python 2 had hit the perfect balance of "just enough but not too much" which I'm very deeply worried that Python 3 is going to deviate from.

novok 7y ago
Python 3 is barely different in my experience and it's been about 10 years at this point. I do enjoy some of the "new" features of python 3.
- rabidrat 7y ago
  I used `async` as the name of a function decorator in some Python3.4 code, which then broke in 3.6 which introduced `async` as a keyword.
  - zerkten 7y ago
    What was the level of effort to remediate that?
    - takeda 7y ago
      sed 's/async/whatever' ...
    - rabidrat 7y ago
      Probably around 4-6 hours of work all told. We had to come up with a new name, do a find/replace, review the changes, test, fix a couple of issues because the replace wasn't perfect/complete, update the dev documentation, make a new patch release, and then create packages for the various supported platforms. Oh and looking back over it now, the filename had to be changed too, because apparently you can't use a keyword as a module name in Python either. So where the documentation linked directly to that file, that had to be updated as well. [1] https://github.com/saulpw/visidata/issues/164 https://github.com/saulpw/visidata/issues/164 [2] https://github.com/saulpw/visidata/releases/tag/v1.2.1 https://github.com/saulpw/visidata/releases/tag/v1.2.1
- 7y ago

MisterBastahrd 7y ago

One day tech historians are gonna look back at this era and shake their heads at all the time, energy, and talent being wasted by people just trying to keep up with tech trends for the sheer purpose of remaining employable.

blauditore 7y ago
I don't think it's that bad. I've never heard of someone who got fired because they didn't know the latest JS framework. Also, new tech trends are not just hot air, there's also a lot of innovation happening. You just have to see through the hype and wait until the dust settles.
- zerkten 7y ago
  There is also the situation that someone gets hired for their tech skills, but the thing that keeps them in a job is their ability to pick up the domain. The tech choices are often point in time decisions which are irrelevant to any outcome. The domain knowledge builds is worth more than any framework knowledge. If you are successfully (i.e. the business or product keeps being developed) you still need to be aware of the internal weaknesses of your original choices and the external opportunities of updating to something more modern. The challenge is in managing the transition which is a skill in itself.
- Rychard 7y ago
  > I've never heard of someone who got fired because they didn't know the latest JS framework. Sure, but I've worked with a number of individuals who have either resigned (on their own), or have been let go, solely because they had no desire or interest in keeping up with their craft. I think that's effectively the same thing, though. Ultimately, the notion of not wanting to stay abreast of the current industry trends is neither something I can relate to, nor is it something I see as being compatible with one's employability.
- mcguire 7y ago
  How many haven't been hired because they didn't know the latest JS framework? Reinventing wheels isn't innovation, particularly if the reinvention isn't round.

alanfranz 7y ago

Honestly: the Java environment is exceedingly good at that. Backwards incompatible changes are truly minimal, and only those that are strictly necessary are added. And since Java 8 the language is pretty nice and offers good functional idioms. Of course, major versions of libraries still change. But there's no match with the JS approach.

lvh 7y ago
I agreed until the disaster that was Jigsaw. Maybe Jigsaw didn't impact you particularly hard, but you can't argue the JVM has a policy of minimal backwards incompatible changes given that debacle.
- chrisseaton 7y ago
  I work on Java at a really deep level, and I haven't had to interact with Jigsaw at all. What is it breaking for you?
  - brabel 7y ago
    A lot of things like older versions of Gradle (which at some point was a blocker to move to Java 9, but not now), Groovy (also fixed, but still has some warnings), which we use heavily for tests, several reflection-heavy frameworks (think dependency injection, annotation-processors etc), which to this day require some ugly hacks like --patch-module to "open" packages, JUnit tests (which also need the same hacks to work), even the location of resources loaded with class.getResource() had to be modified when modularizing a jar, so that resources go into the proper packages that are visible to the loader... You seriously didn't suffer any of these?
    - chrisseaton 7y ago
      No I didn’t experience any issues like that myself.
- dhash 7y ago
  I’m a full time scala developer and have had basically no problems taking longer than a day to in moving to the LTS releases of 9+. It’s probably pretty helpful that the scala ecosystem doesn’t depend much on non-well trodden parts of the JDK

dexen 7y ago

Surprisingly enough, PHP is a good example of environment that doesn't break backward compatibility much. About the only change that had a significant impact on projects I worked on was removal of the 'mysql' DB extension (replaced by 'mysqli' and 'PDO'). For an older project I created a few shim functions and it still works just fine. While frameworks come and go, the core of the language is highly backward compatible. The choices made early on were in the UNIX style, so they were right. To quote an earlier post[1], -- There is something to be said about PHP's staying power. The early versions of the language weren't considered "right". Except maybe they were right for the problem at hand. The way I see it was PHP captured the vector of change, and left ample room for future developments. Both internal changes (hello, bytecode; hello, JIT), language level features (hi there, namespaces), and runtime level features (oh hai, countless built in classes and functions). Moreover, unlike many framework that shone brightly and burned out quickly (Rails?), PHP captured the essence of the environment: HTTP is stateless, and URLs aren't uniformly routable from either end, and well-formed HTML/XML/JSON is just a subset of tag soup. Worse is better. -- [1] https://news.ycombinator.com/item?id=19536132 https://news.ycombinator.com/item?id=19536132

dannypgh 7y ago
If your timeframe goes back to PHP4, this most certainly isn't true. Just one glance of https://www.php.net/manual/en/reserved.keywords.php https://www.php.net/manual/en/reserved.keywords.php should prove this - every new keyword is a backwards incompatible change. And I mention this because I used to support software that used, as a variable name, something which became a reserved word...
- lowercased 7y ago
  as a variable name, wouldn't it have been prefixed with $ ? the XML parsing was probably the biggest BC change I hit between 4 and 5.
  - dannypgh 7y ago
    I think I'm misremembering and they were method names. I believe it was clone, in fact.

ashton314 7y ago

Elixir 1.9 came out. No future core language changes are planned. There are no intentions of creating an Elixir 2.0. There will still of course be regular improvements and updates, but the core language is basically set. Read about it here: https://elixir-lang.org/blog/2019/06/24/elixir-v1-9-0-released/ https://elixir-lang.org/blog/2019/06/24/elixir-v1-9-0-releas...

elcritch 7y ago
If Elixir wasn’t an option for me, Clojure would be my next option. Clojure seems like it has a similar philosophy, and builds on a dynamic immutable core. That being said I like writing code that can feel “done”. No “I wish I could refactor this object hierarchy to make it easier to use, etc” notions in the back of my mind. Not every piece of code is like that, but enough.

novok 7y ago

Java is fairly stable I've found. Just get away from javascript and once in 20 year platform language changes like swift and most platforms don't have that much churn.

vintagedave 7y ago

Delphi still lets you build programs that used to run on Windows 3 with minimal changes, and definitely anything 32-bit. It's part of the value proposition: the language and libraries are planned for forward compatibility and stability for use ten years in the future, as well as now.

FpUser 7y ago
Actually there were some problems (very long procedures I think would be one example). Other then that compatibility shines.
smush 7y ago
To save others the same DDG search I did -> Delphi is a Pascal language IDE that compiles to native Windows binaries. Apparently there is this thing called Lazarus that is a free version of it?
- FpUser 7y ago
  FreePascal is language/compiler and Lazarus is an IDE. Lazarus IDE runs on all major platforms and produces native code. Suitable for anything starting from system code and up to complex GUI apps.

hirundo 7y ago

> I'm starting to long for a stack that doesn't constantly change. I looked up "engraving marble" to find an example of the above, but no luck there: They use lasers for that now.

adamkl 7y ago

As I get older and crankier I find simplicity and stability become a lot more interesting than reinventing the same wheels over and over again. This is probably why I’ve come to appreciate Rich Hickey’s talks more and more as years go by. I think Clojure is a good fit when it comes to stability as per their own development guidelines [1]: The Clojure development team values a measured and thoughtful approach to language evolution with a strong emphasis on maintaining backward compatibility. [1] https://clojure.org/dev/dev https://clojure.org/dev/dev

finalfantasia 7y ago
To anyone who's interested in this topic, I strongly recommend this talk from Rich Hickey about "giving something to somebody that they can use and making a commitment": Spec-ulation (https://www.youtube.com/watch?v=oyLBGkS5ICk https://www.youtube.com/watch?v=oyLBGkS5ICk)

Alupis 7y ago

> I'm starting to long for a stack that doesn't constantly change Come on over to Javaland, it's nice, warm, and the sun is always shining! With the exception of the Java 8 -> Java 11 transition (skipping the non-LTS versions), things are pretty stable. You don't have to use any new-fangled features if you don't want... and your Java 3 code compiled nearly 20 years ago will still run just fine on modern JVM's.

anoncake 7y ago
> Come on over to Javaland, it's nice, warm, and the sun is always shining! My oracle predicts much worse weather.
- Alupis 7y ago
  > My oracle Funny joke, but Oracle is all but out of the equation at this point. They've stepped back and become yet another JVM vendor that takes OpenJDK source and compiles it into a binary for users, sprinkled with some special sauce here and there, and just happens to charge for support. That puts them in line with Azul, IBM, Amazon, AdoptOpenJDK Project, SAP, Red Hat, and a ton more. You get your pick of JVM vendors now... That's a fantastic thing for Java.
gowld 7y ago
Python 2 (the OP topic) from 2000 still works too. Running code is the easy part. Writing it is the hard part. And if running on a VM is your standard, my old DOS programs still run on DOSBox :-)

jasonpeacock 7y ago

The world keeps moving, if you don't want to move with it then pick something that has already stopped. Maybe C? Cobol? Ada? Fortran? Though even those languages have modern flavors & updates... We make progress because we learn, not just new technology, bu new approaches to old problems. When I see an "old" programmer who keeps writing C89 code because "it still works", it is painful to see them rejecting decades of learnings about how to write better software.

nine_k 7y ago

Have you tried Fortran? C also shows excellent stability and backwards compatibility. Cobol is also quite stable, but IDK about the quality of open-source tools for it. The problem of stability is that you are pinned to the moment when the interfaces were defined and committed to, and this moment goes further and further into the past. Quite often this means that you can't use the new things which give advantage to your competitors.

ceronman 7y ago

Use C. Standardized since the 80s, it has had only minor, backwards compatible revisions in 99 and 11. According to the TIOBE index, it's the second most popular language in the world. It works on almost any platform imaginable and it has decades of tooling available for it. Of course it doesn't have any of the good new things developed recently, but if it's stability what you look for, then I don't see a better option.

kbenson 7y ago
Or Perl. Perl takes backwards compatibility very seriously. There was a lot of gnashing of teeth a while back on whether to make newer versions actually change the default behavior finally to some new features could be opt-out instead of opt-in. An by new features, I mean stuff like "use strict", which has been best practice for a couple decades now, but the change would cause problems for existing scripts that didn't turn that feature on. The rule has generally been that you can take a 20 year old Perl script and it will still just run. This has its own complications though, as it makes it harder to advance the language, and then people feel it's being left behind (the Perl 6 stuff came after that feeling developed). It's a longstanding problem in language design and communities, stability vs advancement.
- theamk 7y ago
  Unless it uses CPAN stuff, or calls out to external tools. Those are often needed for key functionality, and they get stale much faster than perl itself.
  - kbenson 7y ago
    The old versions of modules are available, if you don't happen to have the exact same code present. Core modules are all I would worry about, but I'm pretty sure those are held to the same standard as far as backwards compatibility. One or two modules might have been ejected from core or moved into core, but those should be easily found on CPAN as well. In the end, getting something working from scratch on a newer Perl that has a lot of CPAN dependencies (as opposed to just updating Perl) might be a little annoying in that you have to track down all the module versions, but it's far from impossible, or even all that hard. For example, the CGI module[1], which was a core module but historically seen as fairly bad (at least as of now, and at least in some of its uses, it supported a wide set of use cases), it was removed from core and housed on CPAN. If you follow the link provided and check the past versions (dropdown as part of the module path and name), you'll see there are many versions shown, possibly every public version, and going back to 1998 for CPAN, and 1995 for 1995 for the BackPAN. Each of those is visible as an item with it's documentation at the time and the module available to download and use. You can also access the CPAN testing matrix[2], and if you dig around you can actually find the results for some tests back in 1999.[3] If I was responsible for getting some old Perl app to run on a more modern system, I would by much more worried about the OS changing in a complex way than I would about getting the Perl code to run again as expected. Which is to say, I wouldn't be worried much at all. 1: https://metacpan.org/release/CGI https://metacpan.org/release/CGI 2: http://matrix.cpantesters.org/?dist=CGI+4.44 http://matrix.cpantesters.org/?dist=CGI+4.44 3: http://matrix.cpantesters.org/?dist=CGI%202.55 http://matrix.cpantesters.org/?dist=CGI%202.55

toast0 7y ago

You want to find a stack that's small / concise / organized enough that you could support it if you needed to. It's ideal if it has a stable community, but it should be a small group of core devs, so they don't have time to change things that aren't broken. It helps if the community has a culture of stability. In my experience, FreeBSD and Erlang fit this bill. You may need to manage some small changes now and again when upgrading between releases, but generally the most apparent changes are things you were doing before work better. And you can run a fleet with rather divergent versions, as long as you're careful not to use new features (it helps to make sure your dev environment matches your most out of date hosts)

didibus 7y ago

Clojure has had only a single backward breaking change since its creation in 2008, it took 10 full years before being introduced, and it was a pretty minor one at that. Java and the JVM themselves value backward compatibility, and I'd say Clojure takes it a notch above that.

ollran 7y ago
I guess I have missed that. What was the change?
- didibus 7y ago
  When they added clojure.spec. It started validating macros at compile time. If you were previously using an illegal syntax, but that somehow didn't cause any issues, those would now throw a compile time error. Overall it was for the best, since prior to that it was just weird code that had a bit of a undefined behavior since it wasn't using the macro in the proper way. But it still meant we had to go and fix a few of them so they compiled again. Though in the process we realized that we were misusing the macros to begin with.

TeMPOraL 7y ago

Try Common Lisp. The language has an ANSI standard, published in 1994. So the base has been stable and fixed for the past 25 years. A lot of Lisp code that old or even older works perfectly fine on a current CL implementation.

sedachv 7y ago
Not only that, the "Common" in Common Lisp is a reference to a standardization of several existing dialects, so a lot of Lisp code from the 1960s and the 1970s will run without any modifications.

gowld 7y ago

Python 2 is 19 years old. Python 3 is 11 years old. 11 years is a long time to married to the bugs of the past. 20 years is a long time to be married to a fixed language.

b0rsuk 7y ago

Sounds like mathematics.

beerandt 7y ago

FORTRAN?

crimsonalucard 7y ago

Then how do you improve? Currently there is no all encompassing theory for the design of languages or anything. So there's no prove-able way to design a language that can always be improved and always be backward compatible. I imagine that such a language would be incredibly simple. Minimal syntax and all sugar and conveniences would be built with libraries.

jeandejean 7y ago

Can't you just ignore those comments?

RcouF1uZ4gsC 7y ago

I think you are looking for COBOL.

keymone 7y ago

Lots of people say Java but of the more fancy and convenient (and correct, cough I’m obviously biased cough) ways to do development, I can’t stress enough how amazing it has been to watch release after release of Clojure consisting of mostly trivial changes or library additions. The language is arguably complete and any syntactic changes you could wish upon yourself are doable in form of a library because it’s a lisp. And all that piggybacks on top of already quite stable java ecosystem. Can’t get much better than that.

RangerScience 7y ago

I feel like pure Ruby meets this. I've been using Sinatra for years, it's been basically the same that entire time, and the language feels pretty stable in my usage (some nice added things, like stabby syntax and `.then`, but those are really just sugar). Rails is so-so.

leshow 7y ago

I think the only option there is C. It hasn't changed much for a long time, for better or worse.

WalterBright 7y ago

> I'm starting to long for a stack that doesn't constantly change. Just set the features and that's it. I hear every day: don't change a thing in D, just add these two features.