The ubiquitousness of bash is among the few reasons why it continues to endure. It will be eternal if nobody tries to replace it.

I went the same way with simply bumping up my bash skills.

Part of me feels like I'd prefer pry loaded with a library that provides shell like methods for doing ruby-esque things.

Tbh that sounds like quite a lot of codebases from single developers rather than teams I've tried to look at over the years long before LLMs were a thing, and not specifically just for one language (although when it's in a dynamically-typed language it certainly increases the difficulty). Probably quite a lot of training code for LLMs was like this (the people who trained it have access to basically the entire set of code that I did, after all), and the way to avoid it is basically the same: someone has to just care enough to either not write it like this in the first place or take the time to fix it.

As someone who's for a while been a hardline "both developers and users of open source owe each other nothing" advocate (other than the basic human respect that I believe we all owe each other, and that's not specific to open source), I don't really see LLMs as fundamentally changing that calculus. People will create open source, other people will decide to use it or not, maybe to try to contribute back or not, and the maintainers will decide to include those contributions or not, maybe someone decides to fork it, or write a replacement for it because they can't stand the choices or the code of the original, and all of that is basically how things are supposed to work. The system isn't perfect, but I'm not sure what the alternative would be, because putting any further obligations on either side would create worse problems than the ones they solve.

(Some people will choose not to release the source code for their projects instead, and that's fine too, even if in the long run I'm sometimes sad at the result of "this thing that I'd like to run doesn't really support being run in the way I want, and the author is long gone and probably wouldn't even be inconvenienced by my own personal modifications that I don't have any need to distribute". Lots of people will make choices that I wouldn't personally make, but that doesn't inherently make them bad, because other people understanding the rationale is not a particularly good measure of whether something should be allowed or not compared to, like, whether you're actually hurting anyone by doing it).

In my day - I think it was around 2000 – I was handed a 5000 line perl script that both responded to CGI bin requests to run a store and kicked off fulfillment of the orders. Inside that script, it had two 1500 line long subroutines that sometimes navigated internally via goto.

We refactored, and added new features while a profitable business ran on top of the code. You don’t get quite the velocity you do on good code, but it’s manageable.

This is a language that explicitly sacrifices important stuff like the strength of automatic checks possible and performance in lieu of developer ergonomics. Even if you support that particular choice, chosing the language when you won't be writing or reading most of the code is a pretty poor tradeoff.

I think this will improve, but I also think your comment is important for people using agents to read. Speaking for myself, I want people like you to be able to read/understand/contribute to my projects should you desire, so this is a great reminder for me.

Think about what it would take to write this in Python right now:

  for wmv_file in $(find $1 -name '*.wmv'); do
    echo -n "${wmv_file} "
    ffmpeg -i $wmv_file ${wmv_file%.wmv}.mpg 2>&1 | grep kb/s: || echo "ERROR $?"
  done

  for wmv_file in find(argv[1], glob="\*.wmv"):
    print(wmv_file, end=" ")
    result = do("ffmpeg", "-i", wmv_file, basename(wmv_file, ".wmv") + ".mpg")
    if result: print(grep(str(result), "kb/s:"))
    else: print("ERROR", result.status)

Isn't it generally expected for a feature-packed interpreted language to be slower than a minimal compiled language?

The "scripting" languages should of course not try to be slow, but people rarely use them for speed-reasons; they use these languages for gains in productivity and ease of writing code, adding features and so forth. That should be the primary focus point.

In the future we may no longer have such a speed penalty anyway.

I think Rails both boosted Ruby and killed it. When I ask people about why they dislike Ruby it's usually due to something specific to Rails (plus some comments around syntax which are easily dismissed or accepted).

I used to be a pretty heavy Ruby user and I still love the language, though I have only used Rails sparsely and not by choice.

I had the opportunity to work on a Ruby project for a couple weeks a few years ago and it was such a pleasure to read through the code and interpret it! It was unfortunately another project that was being replaced with something else because Ruby skills were harder to find.