6 ms·

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 pote

by 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

by eviks 1y ago

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