4 ms·

Assuming that a different language is better for a specific job, there is a cost associated to having another language.

• CuriouslyC 3y ago
  There's no cost associated with bash unless you're hiring muppets.
  • snapcaster 3y ago
    I would have disagreed (obscure syntax thats hard to memorize if you write bash rarely) but LLMs have really removed all of that
    • dave4420 3y ago
      My boss introduced a bug into our build system because of misunderstanding bash semantics. LLMs really haven’t solved this. Bash makes everyone a muppet if you push it hard enough. (True of all tools, perhaps. But you don’t have to push very hard with bash.)
      • wrs 3y ago
        With Bash quoting rules it’s not like you have to push, it’s more like you don’t pull hard enough to keep it from going over the edge.
        • fiddlerwoaroof 3y ago
          Shellcheck basically solves this problem
          • DonHopkins 3y ago
            That's like saying opioids solve the cancer crisis, and Naloxone solves the opioid crisis.
            • dymk 3y ago
              No, it’s like saying shellcheck solves most of the challenges with writing shell scripts, which it does
              • DonHopkins 3y ago
                But your metaphor is missing the apt comparison of shell scripts with cancer and opioids.
  • itishappy 3y ago
    No security concerns with your projects either! ;) Unfortunately, the world's full of muppets, present company not excluded.
  • arp242 3y ago
    I encountered bugs and had to fix glaring problems in shell scripts literally everywhere I worked. Most devs are not deeply steeped in Unix, and don't really know what they're doing with this as it's not their main job. They kinda clobber something together that "kinda works" – right up to the point it doesn't. There is no shame in that; I do that with some stuff too – we all do – because there is no point learning something in-depth if you use it once a year. This is not a "zomg devs are stoopid" rant, it's just an observation of fact. I've written tons of shell scripts and and I love how it enables you to do something useful very quickly in very little code. Last week I hacked together a "ncurses"-type terminal music player in less than 200 lines which actually works fairly well, which I thought wasn't too bad for an evening of work. But in general I distrust other people's shell scripts, and I found that 9 times out of 10 that's warranted. I tend to push for zsh as it fixes the most egregious footguns and limitations, but there's still plenty of things to do wrong, and the syntax can be unfamiliar.
    • mike_d 3y ago
      > I encountered bugs and had to fix glaring problems in code literally everywhere I worked. Fixed it for you. This is why they pay us the medium bucks.
      • arp242 3y ago
        Obviously that implies that the problems and bugs were much worse than average.
    • fiddlerwoaroof 3y ago
      Something that “kinda works” actually does work. Fixing the edge case when it is actually a problem may actually save time compared to spending extra time up front on things that might never be a problem.
      • syndicatedjelly 3y ago
        Waiting for edge cases to break something, when a solution is known, is a symptom of lousy engineering culture.
  • justinclift 3y ago
    For everyday bash usage, sure. But I worked with an extremely bash-skilled guy at IBM many years ago who went out of his way to write his scripts in the most arcane way possible. On purpose. It was his form of job security, from rough memory when I asked wtf?. ;) I wasn't project lead on that one, so we just had to put up with it... :(
  • tstrimple 3y ago
    People who say stuff like this must not have worked on enough Linux environments. Bash scripts aren't fully portable, and there are absolutely differences in environments which prevent portability of bash scripts. Since using Nix, I've realized the number of bash scripts which are only superficially portable are drastically higher than the number which are actually portable. As one trivial example, how many bash scripts use the more portable shebang of `#!/usr/bin/env bash`? Extremely few. And every one which hard codes `#!/bin/bash` has created a less portable script most likely without ever having realized it. Guess they are all muppets though right?
    • CuriouslyC 3y ago
      If you standardize the Unix utils you use and the bash version you use, it's really not hard to avoid a lot of the issues you're talking about. To get all developers in an org working on compatible ubuntu-like systems, just mandate use of WSL on Windows and GNU unix commands on mac so everything is the same for everyone. That being said, if you and your team just don't have a lot of bash/unix experience, that is probably a good argument for writing your utility scripts in whatever you can actually write without a ton of bugs. Would you complain about node bugs if your org wasn't standardizing the node version people used and some people were still on node 12??
  • hyperhopper 3y ago
    Not true. Bash is filled with foot guns. In fact even HN has articles hitting the front page every other month about another bash footgun and how to avoid it. Any Muppet can write a bash script to do the thing, but only somebody with a lot of bash and unix experience can make sure it's dodging the hundreds of common and obvious but incorrect way of doing things.
• hosh 3y ago
  When it comes to infra, someone's preferred language may not always be available. Infra and devops is more about plumbing, and plumbing gets messy. It can go the other way as well. tcl was originally conceived as an embeddable scripting language that can drive GUI applications, and has been very successful in that use-case. It has a few flaws, but I would have preferred it to been embedded in the browser instead of making up Javascript back in the day.
• hgs3 3y ago
  > there is a cost associated to having another language Could you elaborate?
  • syndicatedjelly 3y ago
    They’re probably talking about the “cost” to create and maintain a custom interface between languages