81–90 of 137 posts
Earlier quoted context omitted.
Anything complex should be written in a competent language like Java. Script languages (like Bash and Python) are for short (a few lines long) scripts. Using the tool outside the scope of what it was designed for is not a good idea.
Tell me you have never seriously used Python without telling me you have never seriously used Python. I mean, viewing Python strictly as a scripting language? I am honestly lost for words. There are many huge and major applications and web sites written in Python, without people regretting it after the fact. And yet here you are dismissing it out of hand without a single argument.
Earlier quoted context omitted.
I like my scripts to run on both linux and macos. It's somewhat limiting, but it saves trouble.
Linuxes have zsh. If you install zsh on linux or bash on macos, hassle is same ish. Installing homebrew is required but I always do it myself. Although bash is more often the available shell on cloud services.
No one else seems to have mentioned this, but POSIX sh does not include this feature. Until it does, and major POSIX shs have shipped with it for a decade, then the feature will actually exist in a way that the average shell coder cares about. You're better off just shipping Rust/Go/etc binaries and leave sh for your simple glue tasks. Even I've eventually switched to this, and I've written 10k+ long Bash scripts tha…
I think it's worth picking at this a bit. At least IME, a fairly small fraction of the Shell I write needs to run literally (any|every)where.
I don't mean to suggest there aren't people/projects for whom the opposite is true--just that it's worth chunking those cases and thinking about them differently.
It obviously isn't a global solution, but in the Nix ecosystem we have decent idioms for asserting control over the shell and tools any given script runs with.
Reliable environment provisioning can spare hundreds of lines of code real-world Shell tends to accumulate to sanity-check the runtime environment and adapt to the presence/absence of various utilities. It also enables us to use newer shells/features (and shell libraries) with confidence.
It's enough leverage that I only give it up when I must.
Earlier quoted context omitted.
Anything complex should be written in a competent language like Java. Script languages (like Bash and Python) are for short (a few lines long) scripts. Using the tool outside the scope of what it was designed for is not a good idea.
Tell me you have never seriously used Python without telling me you have never seriously used Python. I mean, viewing Python strictly as a scripting language? I am honestly lost for words. There are many huge and major applications and web sites written in Python, without people regretting it after the fact. And yet here you are dismissing it out of hand without a single argument.
Earlier quoted context omitted.
Tell me you have never seriously used Python without telling me you have never seriously used Python. I mean, viewing Python strictly as a scripting language? I am honestly lost for words. There are many huge and major applications and web sites written in Python, without people regretting it after the fact. And yet here you are dismissing it out of hand without a single argument.
Don't be too rude, this is a common view among people who are technically adjacent but not engineers, like IT people. It's an incorrect superstition, of course, but in tech almost everybody has their superstitions. There's no reason to be rude -- ignorance is not a crime.
I advocate the following rules for when to write and when not to write a shell script. # Write a shell script: * Heavy lifting done by powerful tool (sort, grep, curl, git, sed, find, …) * Script will glue diverse tools * Workflow resembles a pipeline * Steps can be interactively developed as shell commands * Portability * Avoid dependency hell * One-off job # Avoid shell scripting: * Difficult to see the preceding p…
I’ve been a sysadmin for nearly a decade, a frontend web designer for much longer (I still have a book on all the exciting changes in HTML4), and while I can very easily learn, compose, and use many markup and scripting languages, I have always struggled with full-on programming languages, and I’m not exactly sure why. Part of it, I think, is that most tutorials and online learning resources are focused on novices wh…
My guess is that you can easily learn the syntax and that you have the logical and analytical skills, but the part you have to learn is how to THINK about programming and how to DESIGN a program. If you have or haven't taking coding classes, I think reviewing topics like data structures, algorithms, encapsulation/object oriented programming, functional programming, etc. is the way to learn how to think about general programming. I don't think the language matters, but there might be resources about these topics in the language you're interested in.
An example of what you DON'T want is something like Effective Go (not just because it's out-of-date now): https://go.dev/doc/effective_go. This page can give you a really good base of information about what Go is, but I think you'll get much more bang for your buck with a resource that is more about the WHYs of programming rather than the WHATs.
Earlier quoted context omitted.
Which is because they're not hashmaps, they're associative arrays. Article treats them as the same thing, but they're not - that's why the "declare -A" is A and not H - it stands for "associative".
Author of the article here. As far as I care, if it quacks like a hashmap, it's better to describe it as a hashmap. The fact that it's an associative array under the hood is irrelevant.
A hashmap is a very specific structure that uses a hashing algorithm to normalize the key sizes, and then usually constructs a tree-like structure for fast key lookups. Anything that doesn't use such an implementation under the hood should not be called a hashmap, whether you care or not.
No one else seems to have mentioned this, but POSIX sh does not include this feature. Until it does, and major POSIX shs have shipped with it for a decade, then the feature will actually exist in a way that the average shell coder cares about. You're better off just shipping Rust/Go/etc binaries and leave sh for your simple glue tasks. Even I've eventually switched to this, and I've written 10k+ long Bash scripts tha…