41–50 of 111 posts
I much prefer the pipe to method chaining.
Could this be elaborated?
Apparently a number of people disagree with me, or the way I initially expressed myself, judging from the amount of downvotes I've had. Weird how that happens; tabs and spaces.
Earlier quoted context omitted.
ls | grep file.txt vs ls().grep("file.txt")
Your comparison is not quite optimised as you use () which is not necessary. But I understand the comparison you make. But, you can write an optimised pipe in ruby too. I actually did that, because I could not want to be bothered to be restricted via ruby's syntax for pipe-like operations. Even aside from that, the original claim was about pipes versus method chaining. To me these are not orthogonal to one another; t…
I'm simultaneously amazed and horrified (by the strange but amazing love child you've created between bash and ruby). I spent years (nearly a decade) trying to blend ruby and bash to make the perfect shell, and after never being quite satisfied, I eventually gave up and embraced bash. This does get closer/further than I ever could, and is a fascinating project. I'm going to give it a spin, though I can already imagin…
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'm simultaneously amazed and horrified (by the strange but amazing love child you've created between bash and ruby). I spent years (nearly a decade) trying to blend ruby and bash to make the perfect shell, and after never being quite satisfied, I eventually gave up and embraced bash. This does get closer/further than I ever could, and is a fascinating project. I'm going to give it a spin, though I can already imagin…
> I can already imagine the biggest obstacle I'll hit: rubish not being available in the remote environments I need it to 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'm recently seeing more and more Ruby projects that are at least partly vibe-coded, and I'm kind of torn. On the one hand I appreciate that this allows people to create stuff that they maybe wouldn't have the time to do otherwise. On the other, the code itself makes it harder for people to contribute, especially those, like me, who don't use coding agents. A random example: https://github.com/amatsuda/rubish/blob/ma…
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.
Earlier quoted context omitted.
> I can already imagine the biggest obstacle I'll hit: rubish not being available in the remote environments I need it to The ubiquitousness of bash is among the few reasons why it continues to endure. It will be eternal if nobody tries to replace it.
Many, many people have tried...
Bash maintainer actually implemented the library feature I suggested and it's already dramatically cut down the amount of unsightly bash code I need to keep around and maintain.
I'm getting pretty tired of coping with old stuff just because it's there though. Went through this phase with GNU make too.
Good April 1 article.
But why would it be a first april article? Are there any arguments to be made for this statement? Because the shell works, I just tested it. It may not be everyone's cup of tea but that's always the case for any given software. The primary reason I use bash over, say, zsh, despite thinking zsh is more advanced, is that I use bash mostly because it is very simple. I like simplicity. (Bash could be even simpler, I woul…
Earlier quoted context omitted.
Many, many people have tried...
Yeah. I will probably join their ranks at some point. Bash maintainer actually implemented the library feature I suggested and it's already dramatically cut down the amount of unsightly bash code I need to keep around and maintain. I'm getting pretty tired of coping with old stuff just because it's there though. Went through this phase with GNU make too.
Earlier quoted context omitted.
Yeah. I will probably join their ranks at some point. Bash maintainer actually implemented the library feature I suggested and it's already dramatically cut down the amount of unsightly bash code I need to keep around and maintain. I'm getting pretty tired of coping with old stuff just because it's there though. Went through this phase with GNU make too.
I struggle with this too. On the plus side, the devil you know is often better than the devil you don't know, and anything new will require re-learning a lifetime's worth of muscle memory. It's also nice to know that your bash scripts are going to be hyper-portable and will still work even many years later. The muscle memory is also real. However it isn't great to be constrained with unsightly code for sake of extrem…
Doubt. I'm up to my neck in bashisms, and I require the very latest bash on top of that.
import() {
local f
for f in "$@"; do
[[ -v loaded[$f] ]] && continue
loaded[$f]=1
source -p "${HOME}/.local/lib/bash" "${f}"
done
}
import arguments terminal