nirinor

While the author didn't make proper use of it, this is actually the best example of the articles point.

This is because I/P is sufficiently complicated and brutal that for any involved party X (Arab countries, Israel, Palestinians, Britain...), an interested party can make party X seem "inhuman, clearly we should defeat X anywhere we find them" to someone not previously informed on the topic.

So even if we don't select the evidence, or even select the date, but just selectively amplify, propaganda about it works just fine, across different media. The LLM news here is that as a media, LLMs transform biased background knowledge into eloquent confident _and tailored_ arguments for the bias, like a suave but motivated news anchor that is able to converse individually with _every listener_.

Because for all X, someone _is_ already amplifying the message "hate X", the main outcome of LLMs+Propaganda is not hate for a specific X, but just more hate.

And the solutions? The authors' ledger+timeline+blame+semantic checks are not a bad place to start.

For me, the core is that often the enemy we can and should defeat is not people, it is memes, like "hate _". LLMs (among other effects, good and bad) whitewash memes, and we all better be prepared to defend ourselves against their influence.

Answering myself: I've tried pi and oh-my-pi (omp.sh) in the last couple of days, and the latter feels solid and more effective than CC/opencode/pi. I have not reviewed the code, and 2 days is not a lot, so take with a large grain of salt, obviously.

I use CC at a client because that's their stack. I use (a particular version of) OpenCode for my own work, because it is so much better. Reading this post makes me sad.

Because everything matches and explains oddities I've seen and forgiven. So despite the hyperbole and the places where the authors' general sentiment are not mine, he's basically right, and I need to find a different harness.

If the post resonates for you too and you've found something better, happy for recommendations. pi seems to get the most mentions here, anyone feel it (or another option) is specifically better on these architectural aspects?

So, are computing gradients details of backpropagation that it is failing to abstract over, or are gradients the goal that backpropagation achieves? It isn't both, its just the latter.

This is like complaining about long division not behaving nicely when dividing by 0. The algorithm isn't the problem, and blaming the wrong part does not help understanding.

It distracts from what is actually helping which is using different functions with nicer behaving gradients, e.g., the Huber loss instead of quadratic.

Nah, Karpathy's title is "Yes you should understand backprop", and his first highlight is "The problem with Backpropagation is that it is a leaky abstraction." This is his choice as a communicator, not the poster to HN.

And his _examples_ are about gradients, but nowhere does he distinguish between backpropagation, a (part of) an algorithm for automatic differentiation and the gradients themselves. None of the issues are due to BP returning incorrect gradients (it totally could, for example, lose too much precision, but it doesn't).

Its a nit pick, but backpropagation is getting a bad rep here. These examples are about gradients+gradient descent variants being a leaky abstraction for optimization [1].

Backpropagation is a specific algorithm for computing gradients of composite functions, but even the failures that do come from composition (multiple sequential sigmoids cause exponential gradient decay) are not backpropagation specific: that's just how the gradients behave for that function, whatever algorithm you use. The remedy, of having people calculate their own backwards pass, is useful because people are _calculating their own derivatives_ for the functions, and get a chance to notice the exponents creeping in. Ask me how I know ;)

[1] Gradients being zero would not be a problem with a global optimization algorithm (which we don't use because they are impractical in high dimensions). Gradients getting very small might be dealt with by with tools like line search (if they are small in all directions) or approximate newton methods (if small in some directions but not others). Not saying those are better solutions in this context, just that optimization(+modeling) are the actually hard parts, not the way gradients are calculated.

I am not hiring, but might be able to help with some other parts. DM me if you want to talk.

I use python extensively. I've used bash (+awk+xargs+sed...) extensively.

Nushell is already a great improvement over bash _as a shell_. It is even better when using it to compose _preexisting text based programs_. I would say it is better in every way I can think of, except for: - not (yet) coming pre-installed, and - stability of interfaces and language.

Its already better enough to be my default shell on my daily driver, though I keep bash around because some things really assume it. I very much look forward to one day having a userspace with no traditional shells at all.

nushell is not yet a strict improvement over python, but it might one day be, and it is already better at: - munging text, json, dates and tables - quickly creating nice CLIs callable from the shell (even if that shell isn't nu!) - fun of programming in it

> Nushell is trying to blend two domains, shells and programming languages, which I see distinct advantages in keeping seperate.

Interesting, though, how many PL features the most popular shells tend to have...

> I do not want the world to be built on the back of shell scripts, regardless of how good you make the type system.

If I had read that before knowing nushell, I would strongly agree. Yet, it turns out you can make a shell so good I wouldn't mind if... not the world, but _a lot more_ was built on it.

I've needed these capabilities often while using awk for converting messy logs/error outputs into tables/commands.

Nowadays I like the nushell approach to the composition:

    echo 'quux=123 foo=123 bar=123' | str replace '.*quux=([0-9]+).*foo=([0-9]+).*' $"$2,$1" | from csv -n | each {|r| $r.column1 + $r.column2}

which of course relies on the same regex library (hattip).

Mislabeled? sounds like you're SEEKING WORK, SEEKING FREELANCER is for the other side.

I've joined the Tribe community a few months ago, done one project with them, so far very happy with my experience.

- Pleasant, helpful, knowledgeable people on the slack.

- Brief and effective process matching me with a client.

- They negotiated a rate I was happy with, taking a cut I found reasonable.

- Good working relationships with others in the project, both from Tribe and the client, everyone happy.

- Payment was simple and timely, when I encountered a technical issue with their provider during setup, Tribe were very helpful resolving it.

Feel free to ask questions here or DM me