152 karma · joined June 20, 2020
“Mary Jackson is a world-famous African-American sweetgrass basket weaver. In 2008, she was named a MacArthur Fellow for her basket weaving.”
https://en.wikipedia.org/wiki/Mary_Jackson_(artist)?wprov=sf...
I have to say, that sounds more fulfilling than anything I will ever do. People who become the best at anything are usually truly extraordinary.
This is not the equilibrium we are aiming for as a society, and the matter is not settled here.
The point of these measurements is not to demand that women are paid more for less work. The point is for us to keep asking “why”, and not just stop after the first one.
“Why are women earning less at the New York Times?”. Maybe the company is just top-heavy with men in leadership roles. This has been floated in this thread as a common cause.
“Why are there more men in leadership roles?”. A few commenters have shared anecdotes of having far more men in their recruiting process. More men applying would help explain more experienced men higher up in the company.
“Why are there more men than women applying?”. We’re getting closer to root causes now. In software engineering, for example, there are just more men in the workforce.
“Why are there more men in the workforce?”. It gets more difficult, but also more important, to investigate the answer at these lower levels. Girls Who Code and similar initiatives are tackling this behemoth cultural problem. It will take years to see the effect of their work, but their success breeds hope that someday, the gap in this New York Times statistic will close a little.
At any of these levels, a company can step in and try and correct the natural bias in their hiring or development pipeline. That is, of course, the most sensitive topic for a lot of us here. Such initiatives should have buy-in from the workforce, and there’s an implication here that the (unionized) workers of NYT do support some kind of intervention.
Their choice, and above all the very measurement of a wage gap, doesn’t need to be threatening to anybody here. It will forever be important to track this number even if we “feel” like the explanations are simple. It doesn’t represent some kind of action the company should be forced to take. It measures where we are on every level of asking “why?”.
I only found out about https://www.soundslice.com recently. I'm not sure how it managed to evade me for years of searching for music resources on the internet... but for anyone interested in sheet music, I can't recommend it enough.
The design of the whole platform is so minimal and beautiful, and having notation synchronized with YouTube is simply brilliant. Built by one of the co-creators of Django, too!
I'm amazed at how many of us in Los Angeles live here for years and skip this place. It's one of the most beautiful places I've ever been.
It's also possible to compile your JVM Clojure program yourself to a binary with GraalVM for even better performance than Babashka and even faster startup.
But before Babashka, that was indeed a barrier to using Clojure in shell scripts. Now we have it all!
It's surprisingly excellent! Sure, the "language" of paredit features more powerful text manipulation that just simple movement... but combined with the new "jumping" in the latest Helix release [1], it makes for a very impressive keyboard-based navigation system.
[0]: https://helix-editor.com [1]: https://helix-editor.com/news/release-24-03-highlights/
The official Clojure CLI, for example, is just plain confusing, and that's most people's first impression to the entire ecosystem. The config files, while they use the wonderful `.edn` format, are also not intuitive. Newcomers are the most likely people to encounter the most amount of error messages... which are famously difficult to read.
And that's before you even get into REPL configuration, which involves coordination with your editor process, a client process, and a server process. Even if you have a tool like Calva or CIDER managing it for you, you'll still get confused when something goes wrong unless you grok all the moving parts.
Even if you figure that all out, you still don't have Parinfer or equivalents setup yet in your editor. Also, clojure-lsp tends to require some configuration to get working the way you want. And that's before you get started with ClojureScript, which brings the complexity to another level entirely.
Despite all this, I love Clojure. It's an expert's language, even though it shouldn't have to be. Once you learn this stuff, you respect why much of this complexity exists. It's inherent to the amount of power the language gives you.
But doesn't mean we can't make it easier to use and get started with.
A couple years with Rust has taught me that intuitive errors and tooling will funnel you far enough into language to get you productive, and then you're much more likely to stay. There's just no way I would have stayed long enough to be a Rust professional if it hadn't been for cargo and rust-analyzer.
These "non-language" components of Clojure are just not easy enough to use, and its inhibited Clojure's growth. If, however, you do put in the time to grok these parts, the joy of using the language itself never fades.
It's a particularly good entry point because unlike full-JVM Clojure it has a very fast startup time. Newcomers can use any file-watching /reloading tools (e.g. nodemon) that they're already familiar with to work with it interactively.
Hopefully, a enthusiastic user will graduate to using a REPL connection in their editor for a fully interactive setup. But newcomers tend not to do this... its an unfamiliar workflow to most, and can be pretty cumbersome to setup.
[0]: https://babashka.org
I've been working with a fully Rust-based web stack, and it's been such a joy. Tailwind compilation causes me to still deal with Node. I'd love to see that go away.
That was more convenient for me, especially as I remap my caps-lock key to CTRL system-wide.
I'm not sure why so much of this thread takes offense to your work. HTMX has been transformational for me. I'm grateful that you persevere.
The fact that there are so many strong opinions from people who demonstrate an embarrassingly low understanding of the situation is one of the reasons the problem is so hard to solve in the first place.
So it's true, if you're willing to use a DSL embedded in your server language (like JSX), then you'll have the full language tooling available to you. And this probably isn't giving up much over language-specific templates.
A JSX-equivalent for the Rust server-side rendering world would probably be maud [1] or leptos [2].
I'll offer one here... using HTMX usually means you're going to be writing HTML templates, and HTML templating languages don't have much IDE support. I really miss goto-definition etc. when I'm writing Jinja templates.
That being said, I've personally found Rust/HTMX to be a magnificent combo. I personally find writing backend endpoints in Rust to be no more cumbersome than any other language (after becoming comfortable with Rust)... and there's massive gains from the incredible tooling and type system.
I wonder if you've considered using Askama for your templates? It has a Axum integration that cleans up some of the boilerplate around template rendering. There's also an open PR for block fragments [1], which will make componentization of HTML fragments much easier, as discussed in this essay on the HTMX site [2].
We need more projects like this to demonstrate how useful, highly-interactive apps are made with HTMX. I'd encourage skeptics to try the same before writing it off.
[1] https://github.com/djc/askama/pull/824 [2] https://htmx.org/essays/template-fragments/