Hacker News Reader

Comment by inglor | Hacker News Reader

That's how I use Python for the last few years.

My scripts end up longer and more verbose typically (I might just not be great at Python) but also a lot more maintainable (I am not great at writing maintainable Perl and I use Python more often).

I also use Node.js for this a lot because of the ecosystem containing so many accessible scripts and dependency management while not great is heaps better than most other ecosystems.

Of course OpenBSD can't do that with Python rather then Perl (as explained in that email). They have a different set of constraints. I am only saying in practice I have found Python to be the better alternative for my personal stuff.

View on HN

Python's subprocess is a bit more clumsy than Perl's built in features for running commands, with the proviso that running commands in Perl is best described as "idiomatic". Maybe if you didn't learn it 20 years ago like I did you'd have a hard time with its irregularity and colloquialisms.

Is there any non-shell scripting language that makes it as easy as shell to run external commands, redirect I/O etc.? I don't know of any. (Perhaps that is the very definition of a shell.)

Agreed. I really want a language that makes it easy to run subprocesses and do other Unix/shell magic, while being more straightforward and modern than Perl.

I think a good way of doing this would be to make a shell that has more expressive power and a clearer syntax.

Ruby uses the same sorta commands as perl does I think.

This is one of the few things really missing from python. I am wondering how easy it would be to write a PEP for an outsider.

TCL ships with tclsh which is regular TCL (so a first-class programming language) but allows you to invoke external commands as though they were functions (so arguably is a shell in your sense, though I wouldn't advise using it as your login shell).

subprocess.run() isn't too bad.

> Is there any non-shell scripting language that makes it as easy as shell to run external commands, redirect I/O etc.?

Would Scsh count?

I've tried to use Python for this kind of scripting, too, but went back to Perl. Python-the-interpreter is annoying. Is it /usr/bin/python or /usr/bin/python2 or maybe even 3? Does this server image / distro even come with Python? Sure, Python-the-language is nice and all, but when we talk about 1-10 lines of code it's not a big deal, and Perl... It's just there. Even on Windows Git Bash and mingw come with Perl.

Perl is a write only language for me.

I've got 20 year old python scripts the have been upgraded over the years that are still maintainable, easy to read and do the job just fine.

When I read the perldocs much of it looks write-only. But in keeping with Perl's spirit of "there's more than one way to do it", one can actually write straightforward Perl code that is as understandable as Python.

I'm a Perl fan, but there are some places where it's hard to avoid ugly code. Like collections of complex data structures, especially combined with references. No matter how hard you try, you get messy looking code.

This is exactly when I switched to Python, when I realized that I always had to look up how to dereference pointers to non-trivial objects.

For what it's worth, there's now postfix dereferencing which avoids the whole having to go back and wrap @{ ... } around things.

I can write code that is easy to maintain even after not seeing it for decades, and I can write code that I have trouble maintaining after a long weekend away from it, and I can do this in nearly any language I know.

Take good old fizzbuzz. Want to write it clear and simple in Perl? No problem:

  for (my $n = 1; $n <= 100; ++$n) {
    if ($n % 15 == 0) { print "fizzbuzz\n"; }
    elsif ($n % 3 == 0) { print "fizz\n"; }
    elsif ($n % 5 == 0) { print "buzz\n"; }
    else { print "$n\n" };
  }

Want to get clever and complex in Python? Here you go:

  def fizzbuzz(n, *args):
    cur = ['' for x in range(1,n+1)]
    for m, postfix in args:
      cur = [y+postfix if x%m==0 else y for x, y in zip(range(1,n+1), cur)]
    cur = [str(x) if y == '' else y for x, y in zip(range(1,n+1), cur)]
    return cur

  print("\n".join(fizzbuzz(100, (3, 'fizz'), (5, 'buzz'))))

Of course you could do an unclear and overly clever Perl version, too, or a clear and simple Python version.

The point is that python leads you to clear and simple. No one would write the monstrosity you did, not even by accident, while in Perl, even that little fizzbuzz looks noisy cus of the explicit new lines

I haven't used Perl recently, but the last time I did there was a say function, so

    say "foo";

was equivalent to

    print "foo", "\n";

My point exactly. Python begginners would have trouble recognizing the second option, which is good, because that’s the bad option: “Omit needless words”

Perl obviously even lets experts shoot themselves in the foot on the simplest code, see the fizzbuzz above me, While a beginner would never write the complex python version that was shown, not even by accident.

Optimizing for beginners is fine, but let's not act like it's "correct". It's a Python design choice, some people like it, but there are consequences to it. Like almost all language design choices, it's a trade off. Usually the trade-off for simple to learn is that it's restrictive to professionals and experts. For new users, teaching classes, and bringing amateurs onto an existing team, it works well. For a team where everyone has 5+ years of experience in Python, I imagine there will be some annoyances where they fell boxes in by the language. That's the trade off in action.

An example of a langauge at the extreme other end of the spectrum would probably be APL. It's indecipherable gibberish to me every time I look at it, but I'm not even an APL amateur, much less professional, and that language seems built to be used by people that are very familiar with it. Is that wrong? No, they just aren't optimizing for learnability and community growth, as Python does, instead opting to make it as simple and useful as possible for experts to get what they need accomplished.

You can counter by saying that most code is read more than it's written, so readability is more important, and to that I would say that it depends on the type of code (scripting languages lend themselves to a lot of one-off scripts), and that readability is also a function of experience. If you want your code easily readable my amateurs, then keeping the capabilities you can use to those an amateur can understand is beneficial. If you want your code readable and understandable by experienced programmers, use constructs and control flows that they are experienced with, which is a much wider set of capabilities usually (if the language supports them).

How is that version of FizzBuzz shooting oneself in the foot?

Even that Perl isn't as tidy as it could be. I'd be inclined to have `for my $n (1..100)`, and use `say` instead of print. I might even skip the `== 0` but just saying `(! $n % 15)`, but I'm on the fence about that.

I also wouldn't keep all the blocks on the same line, but it can be forgiven in a comment box.

> I'd be inclined to have `for my $n (1..100)`

I actually had that at first...

> I might even skip the `== 0` but just saying `(! $n % 15)`

...and that too. I changed them to be more likely to be obvious to even someone who has never seen Perl before. A lot of languages besides Perl have a "for" loop variant that is like a C "for" loop.

The formatting was indeed because it was in a comment box. I didn't want to take up too much vertical space on the page.

I would have written that Perl code as

    for (1..100) {
        if    (not $_ % 15) { say 'FizzBuzz' }
        elsif (not $_ % 3)  { say 'Fizz'     }
        elsif (not $_ % 5)  { say 'Buzz'     }
        else                { say            }
    }

Just saying

Perl is a write once language for me.

In that I write it once and 20 years later it still works even though I upgraded the compiler many times.

Reply on news.ycombinator.com