5 ms·

This and Lindy Effect factors a lot into my choices for what to use for my projects. My choice for a project I want to be as maintenance-free as possible are sp

This and Lindy Effect factors a lot into my choices for what to use for my projects. My choice for a project I want to be as maintenance-free as possible are special subsets of ASCII/txt, SQLite, Perl, Bash, PHP, HTML, JS, CSS. The subsets I choose are the parts of these languages which have persisted the longest. Using the Lindy Effect for guidance, I've built a stack/framework that works across 20 years of different versions of these languages, which increases the chances of it continuing to work without breaking changes for another 20 years.

akkartik 1y ago
For similar considerations + considerations of code size and hackability, I lately almost always prefer the Lua eco-system: https://akkartik.name/freewheeling https://akkartik.name/freewheeling
eviks 1y ago
This dogmatic approach means you lose out on ergonomics by using poorly designed tools like bash and perl, so you incur those costs all the time for little potential benefit far away in the future (after all, that effect is just a broad hypothesis)
- argomo 1y ago
  It has to be weighed against all the time spent learning, evaluating, and struggling with new tools. Personally, I've probably wasted a lot of time learning /new/ that I should have spent learning /well/.
  - eviks 1y ago
    Right, nothing is free, but switching costs is a different argument.
    - deleted 1y ago
      [deleted]
- forgotmypw17 1y ago
  Is it still dogmatic if I consider Perl to be well-designed and have already evaluated more popular tools?
  - eviks 1y ago
    If "This and Lindy Effect" do not "factors a lot", but instead the major factor is you believe perl is better designed, then no, dogmatism of vague future risk is replaced with pragmatism of the immediate usefulness
  - jwrallie 1y ago
    At the point being discussed, which is not breaking backward compatibility, it indeed is arguably better than more popular tools, and I believe perl has other advantages too.
- zeta0134 1y ago
  Very helpfully, python has stuck around for just as long and is almost always a better choice against these two specific tools for anything complicated. It's not perfect, but I'm much more likely to open a random python script I wrote 6 years ago and at least recognize what the basic syntax is supposed to be doing. Bash beyond a certain complexity threshold is... hard to parse. Python's standard library is just fine for most tasks, I think. It's got loads of battle tested parsers for common formats. I use it for asset conversion pipelines in my game engines, and it has so far remained portable between windows, linux and mac systems with no maintenance on my part. The only unusual crate I depend on is Pillow, which is also decently well maintained. It becomes significantly less ideal the more pip packages you add to your requirements.txt, but I think that applies to almost anything really. Dependencies suffer their own software rot and thus vastly increase the "attack surface" for this sort of thing.
  - forgotmypw17 1y ago
    My main problem with python is that a script I wrote 6 years ago (or even 1 year ago) is not likely to run without requiring modifications. If it's me running it, that's fine. But if it's someone else that's trying to use installed software, that's not OK.
    - esseph 1y ago
      This is one of the problems that containers help solve - no OS, just the dependencies required to run your code.
      - cjfd 1y ago
        It is also quite possible for old containers to no longer build.
        esseph 1y ago
        That's why your build pipeline alerts you when tests no longer work, and then you have a release of the previous build still available for download at any time. This is how containers are released!
- oguz-ismail 1y ago
  > poorly designed tools like bash and perl Skill issue, plus what's the alternative? Python was close until the 3.x fiasco
  - eviks 1y ago
    Indeed, double skill issue: one with the designers and the other one with the users having poor tool evaluation skills
    - oguz-ismail 1y ago
      > poor tool evaluation skills Both tools in question are installed everywhere and get the job done. There isn't much to evaluate, and nothing to compare against
      - eviks 1y ago
        > There isn't much to evaluate, and nothing to compare against These are exactly the skill issues I meant! Git gud in evaluating and you'll be able to come up with many more sophisticated evaluation criteria than the primitive "it's installed everywhere"
        legends2k 1y ago
        While there are other parameters I would consider like maintainability, ergonomics, mind share, ease of deployment, etc. The ubiquitous availability point triumphs most others though. Installation of new toolchain is usually a hassle when the same task can be done with existing tools. Also when I present it in a company setting installing new software and broadening the security attack surface is the first pushback I get.
        eviks 1y ago
        Do you advocate the use of Notepad on Windows to edit text because it already exists? What about the increase in the security attack surface from using languages that make it easy to make mistakes in something basic like quoting/escaping? Does it get in the top 10 of pushbacks?
- blueflow 1y ago
  Its not "far away in the future". Every other IT job right now is supporting, maintaining and fixing legacy software. These are the software choices of the past and you pay them in manpower.
  - deleted 1y ago
    [deleted]
- calvinmorrison 1y ago
  Calling perl poorly designed is absurd
testthetest 1y ago
It’s getting harder to make perfect choices as projects grow more complex. Even simple products often mean building for iOS, Android, web, backend, etc. You can only lean on html/js for parts of that, but in practice, the mobile apps will probably get rewritten every few years anyway. From my side I think it’s more useful to focus on surfacing issues early. We want to know about bugs, slowdowns, regressions before they hit users, so everything we write is written using TDD. But because unit tests are couple with the environment they "rot" together. So we usually set up monitoring, integration and black-box tests super early on and keep them running as long as the project is online.
donatj 1y ago
I love PHP, however since around 7.4 they have become pretty happy to make breaking changes to the language, including recently in ways where you cannot satisfy older and newer versions of the runtime simultaneously. I end up spending often a couple weeks of my life on and off fixing things after every major release.
- hu3 1y ago
  Was it related to magic quotes or global variables created from user input? If so, the writing has been on the wall for over a decade for these.

akkartik 1y ago

For similar considerations + considerations of code size and hackability, I lately almost always prefer the Lua eco-system: https://akkartik.name/freewheeling https://akkartik.name/freewheeling

eviks 1y ago

This dogmatic approach means you lose out on ergonomics by using poorly designed tools like bash and perl, so you incur those costs all the time for little potential benefit far away in the future (after all, that effect is just a broad hypothesis)

argomo 1y ago
It has to be weighed against all the time spent learning, evaluating, and struggling with new tools. Personally, I've probably wasted a lot of time learning /new/ that I should have spent learning /well/.
- eviks 1y ago
  Right, nothing is free, but switching costs is a different argument.
  - deleted 1y ago
    [deleted]
forgotmypw17 1y ago
Is it still dogmatic if I consider Perl to be well-designed and have already evaluated more popular tools?
- eviks 1y ago
  If "This and Lindy Effect" do not "factors a lot", but instead the major factor is you believe perl is better designed, then no, dogmatism of vague future risk is replaced with pragmatism of the immediate usefulness
- jwrallie 1y ago
  At the point being discussed, which is not breaking backward compatibility, it indeed is arguably better than more popular tools, and I believe perl has other advantages too.
zeta0134 1y ago
Very helpfully, python has stuck around for just as long and is almost always a better choice against these two specific tools for anything complicated. It's not perfect, but I'm much more likely to open a random python script I wrote 6 years ago and at least recognize what the basic syntax is supposed to be doing. Bash beyond a certain complexity threshold is... hard to parse. Python's standard library is just fine for most tasks, I think. It's got loads of battle tested parsers for common formats. I use it for asset conversion pipelines in my game engines, and it has so far remained portable between windows, linux and mac systems with no maintenance on my part. The only unusual crate I depend on is Pillow, which is also decently well maintained. It becomes significantly less ideal the more pip packages you add to your requirements.txt, but I think that applies to almost anything really. Dependencies suffer their own software rot and thus vastly increase the "attack surface" for this sort of thing.
- forgotmypw17 1y ago
  My main problem with python is that a script I wrote 6 years ago (or even 1 year ago) is not likely to run without requiring modifications. If it's me running it, that's fine. But if it's someone else that's trying to use installed software, that's not OK.
  - esseph 1y ago
    This is one of the problems that containers help solve - no OS, just the dependencies required to run your code.
    - cjfd 1y ago
      It is also quite possible for old containers to no longer build.
      - esseph 1y ago
        That's why your build pipeline alerts you when tests no longer work, and then you have a release of the previous build still available for download at any time. This is how containers are released!
oguz-ismail 1y ago
> poorly designed tools like bash and perl Skill issue, plus what's the alternative? Python was close until the 3.x fiasco
- eviks 1y ago
  Indeed, double skill issue: one with the designers and the other one with the users having poor tool evaluation skills
  - oguz-ismail 1y ago
    > poor tool evaluation skills Both tools in question are installed everywhere and get the job done. There isn't much to evaluate, and nothing to compare against
    - eviks 1y ago
      > There isn't much to evaluate, and nothing to compare against These are exactly the skill issues I meant! Git gud in evaluating and you'll be able to come up with many more sophisticated evaluation criteria than the primitive "it's installed everywhere"
      - legends2k 1y ago
        While there are other parameters I would consider like maintainability, ergonomics, mind share, ease of deployment, etc. The ubiquitous availability point triumphs most others though. Installation of new toolchain is usually a hassle when the same task can be done with existing tools. Also when I present it in a company setting installing new software and broadening the security attack surface is the first pushback I get.
        eviks 1y ago
        Do you advocate the use of Notepad on Windows to edit text because it already exists? What about the increase in the security attack surface from using languages that make it easy to make mistakes in something basic like quoting/escaping? Does it get in the top 10 of pushbacks?
blueflow 1y ago
Its not "far away in the future". Every other IT job right now is supporting, maintaining and fixing legacy software. These are the software choices of the past and you pay them in manpower.
- deleted 1y ago
  [deleted]
calvinmorrison 1y ago
Calling perl poorly designed is absurd

testthetest 1y ago

It’s getting harder to make perfect choices as projects grow more complex. Even simple products often mean building for iOS, Android, web, backend, etc. You can only lean on html/js for parts of that, but in practice, the mobile apps will probably get rewritten every few years anyway. From my side I think it’s more useful to focus on surfacing issues early. We want to know about bugs, slowdowns, regressions before they hit users, so everything we write is written using TDD. But because unit tests are couple with the environment they "rot" together. So we usually set up monitoring, integration and black-box tests super early on and keep them running as long as the project is online.

donatj 1y ago

I love PHP, however since around 7.4 they have become pretty happy to make breaking changes to the language, including recently in ways where you cannot satisfy older and newer versions of the runtime simultaneously. I end up spending often a couple weeks of my life on and off fixing things after every major release.

hu3 1y ago
Was it related to magic quotes or global variables created from user input? If so, the writing has been on the wall for over a decade for these.