Same here, actually.

https://status.slack.com/

https://downdetector.com/status/slack/

I'm unable to see the threads window in any slack but able to access everything else

was done for a while for me; all the workspaces. things are returning to normal

This was a great read! I really like this part of shell programming. Unfortunately most functions in the wild have many side effects and environment variables which make them hard to reason about. I really appreciate clojure namespaces when working in bash

Thank you! :) If you liked that, you will love "Concise GNU Bash" by James Pannacciulli: https://www.youtube.com/watch?v=BJ0uHhBkzOQ > I really like this part of shell programming. Same... as long as one keeps the code purely functional, it is so useful and scales very well. Wanna process nginx logs weighing half a TB gzipped? No problem. zcat, zgrep, and sed away. > I really appreciate clojure namespaces when working in bash Oh boy, if there was one thing I could improve about Bash, it would be introducing "real" namespaces. Mercifully, functions occupy their own namespace (`type -a thingname`) so they don't mutate aliases, builtins, and reserved keywords. So we can do this...

$ sed() { echo lol; }

$ sed="phew!"

$ type -a sed
sed is a function
sed () 
{ 
    echo lol
}
sed is /bin/sed

$ man bash | sed
lol

$ man bash | command sed 1q # sort of Common Lispy, I suppose.
BASH(1)                               General Commands Manual                               BASH(1)

$ echo $sed
phew!

yeah bash is still strong for ETL-type work in a single file. I’d rather use babashka for anything non-throwaway nowadays, especially if it has to deal with data serialised in yaml or json

> I’d rather use babashka for anything non-throwaway nowadays, especially if it has to deal with data serialised in yaml or json Absolutely! Still, in situations where I really can't introduce Clojure in a reasonable way (needs institutional support), I'm grateful I can use structured data thanks to jq etc. I will die fighting on the hill called "Structured Logging". https://github.com/adityaathalye/bash-toolkit/blob/master/log-analysis.sh#L193

> ETL-type work in a single file Hm, if input files on disk are sensibly namespaced, then it can be one of those "embarrassingly parallel" problems. The nginx logs example I gave was like that. {6 nodes}/yyyy/mm/dd/hh/logfile{1..n}.gzip. Even a naive one-liner with xargs -P can help there. I know because I wrote said naive one-liner, and managed to narrow down where the malicious requests were coming from. 🤓

But overall, I do agree. Shell has a sweet spot, and most other spots aren't. Proper modern proglangs are very much preferable. And we are super lucky to have #babashka!

some gnu tools use multiple cores quite efficiently when available, I remember rewriting a tool written in JS to bash and the bash version being significantly faster without using xargs and such and fully saturating the available cores. I don’t remember which tools it used that were able to do it

Was it https://www.gnu.org/software/parallel/?

no I mean it didn’t require anything like that

Aah, I see. I haven't done big enough data processing to go far enough into shell parallelism/multicore. I've primarily written repo-specific tools and/or utilities, and ad-hoc "little data" processing (a few dozen gigs at most). That's shaped my little library of functions-as-cmd-line-tools... the set of "stuff I could use quickly and cheaply, if only I had written it down somewhere" :)

Actually, now I don't even care I never did anything "big" with shell. I'm happy with little tools, lots of fun, and of having received a sed-fu/Unix-fu masterclass from Douglas McIlroy (https://www.evalapply.org/posts/shell-aint-a-bad-place-to-fp-part-1-doug-mcilroys-pipeline/#appendix-an-unexpected-masterclass)!!! Gonna ride that high for a long time :))))

yeah that is pretty awesome

I did something similar to this post: https://adamdrake.com/command-line-tools-can-be-235x-faster-than-your-hadoop-cluster.html

similarly it was I think something to the tune of 3-4GB of data, which was JSON logs of an application

Ah, I see. My last adventure was to write a server logs -> billing calculator (api call based monthly billing against 40-50 GB of gzipped logs dump). Just to see what was feasible. It turned out that my Bash version: • weighed in at 10x less lines of code than the extant JVM version (~1.5Kloc Kotlin), • ran about 20% faster than the JVM job (~ 1GB/min throughput with no optimization whatsoever) • consumed way less memory and CPU (background job, with rest of the PC free for Intellij and Slack) • was idempotent and re-startable against intermediate data • and was a collection of composable functions fully reusable in any combination for ad-hoc log processing at the terminal, which people had to do anyway for debugging/post-mortems. It may have been slightly worse from a parsing/type-checking PoV --- correct tally of calculation, but probably within an acceptable margin of error.

I came away pleasantly surprised... it had little to do with any personal cleverness, and much to do with ease of doing pipelined, streaming, modular, data-oriented architecture.

Yeah, I like that post by Adam Drake. You may also like https://datascienceatthecommandline.com/ and https://www.datafix.com.au/BASHing/

create-react-app is like a step-brother of RoR or Django. Only worse.

it feels like one of those old python web frameworks where they were just a big ball of mashed up random libraries that mostly worked

RoR and Django feel a lot more coherent to me, much more coherent than CRA

Probably. But I've been to the deep guts of Django, and I couldn't leave unscarred. :(

(CRA is still worse though)

I totally understand the scarring

I survived rails v1 to v5

I need that on a t-shirt

hmmm maybe it was rails 2? it was so so so long ago

I did some django and turbogears back then, too

I'm fortunate enough that I've never even heard of Turbogears.

create-react-app now has powers that have grown far beyond its abilities to incorporate and control them

the counter-cliche to "worse is better" is "victim of its own success"

i'm not even mad at CRA. i think it successfully helped bootstrap the React ecosystem and lead to the evolution of things like next.js & remix

it's hard to start a project. it's also hard to start a rich & cohesive ecosystem. creating a sort of "industry standard boilerplate" has the effect of making a baseline that everyone can get mad about and then go and create something better for their use case

IMO spec basically did this for validation and coercion 😂

Spec didn't become a monster though. :)

Also, Plumatic schema was quite popular before Spec existed, I think.

my point is that spec spurred a lot of innovation, e.g. malli

> tell me you think software is collapsing under the weight of its own complexity ... Does this bio qualify? https://confengine.com/user/aditya-athalye-1

I used CRA before I convinced coworkers to move to nextjs

and now I'm eyeballing remix

https://www.youtube.com/watch?v=ZSRHeXYDLko

On it https://gist.github.com/dustingetz/d5300b7d16e516bfcb8b3eafdae18ad5

I've argued with CRA for much too long. It's zero configuration model just gets in the way sometimes. Ejecting is terrible and react-app-rewired/ customize-cra are just hacks

I have Redux Toolkit to fix Redux to fix Flux to fix MVC. #justayin

But software is not collapsing. Our mistakes are failing. They do that. But Tilton's Un-Compliment: "The brightest engineers will make anything work. " https://allpoetry.com/In-Broken-Images This is Clojure's opportunity.

Thx, @UK0810AQ2. I knew it. 👨‍🦯 The rugrats are to blame. https://youtu.be/ZSRHeXYDLko?t=866

@U0PUGPSFR as a rugrat who worked on silicone chips, I apologize 🙂

:rolling_on_the_floor_laughing: Well, the M1 turned out OK, I guess you did not do too bad. I recently had a lead engineer half my age give a candid explanation for why the DB was not 3NF, meaning I could not look at it and understand it. "We find it easier this way." Great callback to Barbie and math.

I may have worked on M1, but I'm not sure. Willing to take criticism regarding Intel's Cannon Lake

"...making Cannon Lake not only one of the shortest-lived microarchitectures of Intel, but also the shortest-lived 10 nm x86 CPU microarchitecture (with only one CPU model to be released and manufactured for 1.5 years)" History passes faster in hardware!

The fabrication process allegedly had terrible issues with it. Blame the material engineers and physicists 🙂