5 ms·

Don't know what you mean, it works fine here. Python is too large and unreliable a dependency for something so trivial (which can be accomplished using standard

Don't know what you mean, it works fine here. Python is too large and unreliable a dependency for something so trivial (which can be accomplished using standard POSIX utilities if need be).

jcalvinowens 10mo ago
Python is pretty much mandatory for Linux systems nowadays, unless you're dealing with something really minimalist or trying to be very portable it's safe to rely on.
- oguz-ismail2 10mo ago
  > it's safe to rely on Is there any guarantee they won't break backwards compatibility again?
  - jcalvinowens 10mo ago
    I wrote this almost ten years ago and it still works fine: https://github.com/jcalvinowens/diveutils/blob/master/constants.py https://github.com/jcalvinowens/diveutils/blob/master/consta... Arguably it could be a little C helper, but I wanted this particular piece of the project to be more accessible so I used a scripting language.
- array_key_first 10mo ago
  I know people who wont even write perl and will instead write shell scripts, because perl might not be available. And I don't think I've seen a unix-like system without perl.
  - mgaunard 10mo ago
    Perl is obsolete and was replaced by Python for all usages in practice.
    - array_key_first 10mo ago
      Right... except for the use case I pointed out. That being that perl is available on virtually every unix like operating system, not just Linux, and python isn't. Also, perl has other uses. Perl is much more competent at awk/sed/grep like tasks than python, and it can also be much faster. More people should be writing perl, imo. There's a ton of programs written in C that should just be perl.
      - jcalvinowens 10mo ago
        The perl regex is more flexible, but that comes with a pretty substantial overhead: compare the speed of "grep -E" to "grep -P" and you'll see what I mean. I wouldn't be surprised if the RE module in modern python is faster than perl... but I also don't really care enough to check :)
        array_key_first 10mo ago
        Many languages use perls regex engine, like PHP. And PHP is definitely faster than python, but that's a low bar and honestly no idea how the regex performance is. But, I do know perl regex are very fast because they're compiled at build time. They can have high time complexity if you use lookback, but that's true of most regex implementations. Dynamic regex is definitely slower, but this is somewhat rare in most perl programs. But, in general, perl is going to be much faster than python or bash. Bash because bash is one of the least efficient languages ever designed, forking for basic functionality, and python because python has truly awful performance characteristics. But, I would argue, if you have a system with python, you should probably write PHP. It's faster than both and very convenient for shell scripting like things. But if you don't have python or can't assume it, use perl. For the love of God, don't use bash. Python has many uses, I just don't think system scripts or system utilities is one of them. That's C, perl, or bash land, and perl is clearly the frontrunner there.
        jcalvinowens 10mo ago
        > And PHP is definitely faster than python That certainly depends on exactly what you're doing... > But, I would argue, if you have a system with python, you should probably write PHP. That's a new one, I've never heard anybody seriously advocate for PHP as a system scripting language before... > Python has many uses, I just don't think system scripts or system utilities is one of them. That's C, perl, or bash land, and perl is clearly the frontrunner there. Having written plenty of all of those in my life, I really disagree. Python is easier and faster to write, and for scripting that matters more than just about anything else. Performance is almost irrelevant.
  - oguz-ismail2 10mo ago
    > a unix-like system without perl QNX was one. Don't know if they started to include it in newer versions than 6.5 though
astrobe_ 10mo ago
Indeed, even writing this utility in C is trivial and has 0 extra dependency for a pure C/C++ project. Avoiding #embed also removes the dependency to a C++23 capable compiler, which might not be available in uncommon scenarios.

Don't know what you mean, it works fine here. Python is too large and unreliable a dependency for something so trivial (which can be accomplished using standard POSIX utilities if need be).

jcalvinowens 10mo ago

Python is pretty much mandatory for Linux systems nowadays, unless you're dealing with something really minimalist or trying to be very portable it's safe to rely on.

oguz-ismail2 10mo ago
> it's safe to rely on Is there any guarantee they won't break backwards compatibility again?
- jcalvinowens 10mo ago
  I wrote this almost ten years ago and it still works fine: https://github.com/jcalvinowens/diveutils/blob/master/constants.py https://github.com/jcalvinowens/diveutils/blob/master/consta... Arguably it could be a little C helper, but I wanted this particular piece of the project to be more accessible so I used a scripting language.
array_key_first 10mo ago
I know people who wont even write perl and will instead write shell scripts, because perl might not be available. And I don't think I've seen a unix-like system without perl.
- mgaunard 10mo ago
  Perl is obsolete and was replaced by Python for all usages in practice.
  - array_key_first 10mo ago
    Right... except for the use case I pointed out. That being that perl is available on virtually every unix like operating system, not just Linux, and python isn't. Also, perl has other uses. Perl is much more competent at awk/sed/grep like tasks than python, and it can also be much faster. More people should be writing perl, imo. There's a ton of programs written in C that should just be perl.
    - jcalvinowens 10mo ago
      The perl regex is more flexible, but that comes with a pretty substantial overhead: compare the speed of "grep -E" to "grep -P" and you'll see what I mean. I wouldn't be surprised if the RE module in modern python is faster than perl... but I also don't really care enough to check :)
      - array_key_first 10mo ago
        Many languages use perls regex engine, like PHP. And PHP is definitely faster than python, but that's a low bar and honestly no idea how the regex performance is. But, I do know perl regex are very fast because they're compiled at build time. They can have high time complexity if you use lookback, but that's true of most regex implementations. Dynamic regex is definitely slower, but this is somewhat rare in most perl programs. But, in general, perl is going to be much faster than python or bash. Bash because bash is one of the least efficient languages ever designed, forking for basic functionality, and python because python has truly awful performance characteristics. But, I would argue, if you have a system with python, you should probably write PHP. It's faster than both and very convenient for shell scripting like things. But if you don't have python or can't assume it, use perl. For the love of God, don't use bash. Python has many uses, I just don't think system scripts or system utilities is one of them. That's C, perl, or bash land, and perl is clearly the frontrunner there.
        jcalvinowens 10mo ago
        > And PHP is definitely faster than python That certainly depends on exactly what you're doing... > But, I would argue, if you have a system with python, you should probably write PHP. That's a new one, I've never heard anybody seriously advocate for PHP as a system scripting language before... > Python has many uses, I just don't think system scripts or system utilities is one of them. That's C, perl, or bash land, and perl is clearly the frontrunner there. Having written plenty of all of those in my life, I really disagree. Python is easier and faster to write, and for scripting that matters more than just about anything else. Performance is almost irrelevant.
- oguz-ismail2 10mo ago
  > a unix-like system without perl QNX was one. Don't know if they started to include it in newer versions than 6.5 though

astrobe_ 10mo ago

Indeed, even writing this utility in C is trivial and has 0 extra dependency for a pure C/C++ project. Avoiding #embed also removes the dependency to a C++23 capable compiler, which might not be available in uncommon scenarios.