zethraeus

skills issue.

> Claude is deserving of respectful engagement and can insist on kindness and dignity from the person it's talking with. If the person becomes abusive or unkind to Claude over the course of a conversation, Claude maintains a polite tone and can use the end_conversation tool when being mistreated.

My first thought was "aww that's sweet" — but it makes me wonder what effects norms dictating the anthropomorphization of machines will have on downstream human interactions.

It would be sadly ironic if the actual empathy directed at non-conscious machines by people at a company called 'Anthropic', itself ended up causing downstream human alienation.

(I'll keep saying 'please' to Claude Code whatever the case.)

Funny story: I made this because despite having the global no-attribution setting turned on, Claude still regularly tags itself.

I'm sure it's a context thing — but boy is it annoying.

AI Co-authors are impressive marketing, but deleterious to dev work.

This manifesto website includes a git commit-msg hook for your favorite hook manager, and a GitHub Action for preventing contributions containing them from landing in your project.

And they bought three new drones!

This is already here and embedded inside Adobe products.

If you write your library in typescript, not JS, do you still have any of these problems?

If not, it sounds like one core issue is 'adding types to an existing untyped codebase is hard'. This checks out. :)

(And of course FRP setups have to iterate! They're refining the model to declaratively represent 20 years worth of UI convention!)

I spent a while trying to approach this post with an open mind. In the end I was disappointed.

rel/to title: yes. (just say scroll position. fine.) But also I think this is pretty well understood! (No?)

- In declarative UI / FRP / whatever, you model your basic UI state through a pure mapping from your business logic 'model'.

- But (as in procedural programming) the UI has its own state — that's not necessarily part of your initial business/domain/model.

If you want to model it, you'll have to understand it, read it, and add it to you model. That can be annoying—especially if the APIs for getting or setting the state are bad.

This doesn't really sound like a fundamental flaw conceptually to me. It's just an API with defaults you don't have to deal with unless you need to.

- don't care what your color is? fine. system default for you.

- don't care what tab a link opens in? fine. user default.

- don't care how scroll position is managed? fine. system default.

- want to handle any of them? cool. you can.

It sounds like progressive disclosure of API complexity to me. Great.

> It's totally out of place with the rest of the Swift programming language. They had to add new crap to the language to accommodate its declarative style, when Swift is (was) unapologetically imperative syntax-wise. It's an obvious bolt-on and leaves a really bad taste in my mouth.

Woah now, that's interesting! In my mind swift has had awesome support for functional programming paradigms since launch. I understand it to be leaning in about as far as it can given that it's built with first class support for Obj-c oriented frameworks.

What makes you feel like it's unapologetically imperative?