this is a common issue I think, but specifically with claude code.. I'm so exhausted by having to explain when I'm asking a question about a proposed change I am never asserting something... always just asking. when i ask something like "why are you using Getenv() here?" I usualy get: "You're absolutely right! I was so wrong, I'll stop that and go this other way..." if I wanted to express that sentiment I'd do it directly. has anyone found a way to phrase a question economically that conveys that you actually just want an answer?

This Week in Bitcoin from @Chris Fisher

npub.blog

A local-first Nostr long-form content reader

npub.blog translates articles with imeta tags containing 'audio/mpeg' mimetypes into podcast episodes

I am using claude-code, and one constant struggle I have is getting it answer questions without poisoning it's concept of what we're working on. I create markdown files describing the features and such, but when I come across strange implementation and ask something like: "is there an implementation of this in go-nostr we could use instead of writing new code?" it takes that as a suggestion "You're absolutely right!" and runs off to edit the code, rather than just answering my question. I have various lines in my CLAUDE.md describing how not to run off and change things without being explicitly told to do so, but that all eventually falls out of context or is just not working. do any of you have suggestions on how to ask claude code questions in context without derailing things? #ai

"that was the time I was most frightened, waiting for my turn. I'll never put on a lifejacket again"

excellent paper that zooms out to question the current AI paradigm of stochastic gradient descent. it results in "fractured, entangled representations", that is, deep neural network toplogies which are not modular. this means that in order to improve a specific function, all the scattered heterogeneous loci of that function must be found and updated. the author points out an example of neural nets, though vastly smaller than modern LLMs, that were generated by a process of open ended evolution, and that they produce highly factored and modular representations. "Questioning Representational Optimism in Deep Learning: The Fractured Entangled Representation Hypothesis" by Kenneth Stanley et al

arXiv.org

Questioning Representational Optimism in Deep Learning: The Fractured Entangled Representation Hypothesis

Much of the excitement in modern AI is driven by the observation that scaling up existing systems leads to better performance. But does better perf...

this book is still relevant, maybe more than ever from Richard Hamming's "The Art of Doing Science and Engineering": FORTRAN, meaning FORmula TRANslation, was proposed by Backus and friends, and again was opposed by almost all programmers. First, it was said it could not be done. Second. if it could be done, it would be too wasteful of machine time and capacity. Third, even if it did work, no respectable programmer would use it—it was only for sissies! The use of FORTRAN, like the earlier symbolic programming, was very slow to be taken up by the professionals. And this is typical of almost all professional groups. Doctors clearly do not follow the advice they give to others, and they also have a high proportion of drug addicts. Lawyers often do not leave decent wills when they die. Almost all professionals are slow to use their own expertise for their own work. The situation is nicely summarized by the old saying, “The shoe maker’s children go without shoes”. Consider how in the future, when you are a great expert, you will avoid this typical error! With FORTRAN available and running, I told my programmer to do the next problem in FORTRAN, get her errors out of it, let me test it to see it was doing the right problem, and then she could, if she wished, rewrite the inner loop in machine language to speed things up and save machine time. As a result we were able, with about the same amount of effort on our part, to produce almost 10 times as much as the others were doing. But to them programming in FORTRAN was not for real programmers!

npub.blog

A local-first Nostr long-form content reader

is a webapp for reading long-form content. it pulls articles from anyone you follow, as a feed. I haven't found another site that does such a thing so I built this. I've been polishing it, but it's obviously still very raw and untested. give it a look. send me feedback if you notice something broken. you can enter an npub or a nip05 if you want to see someone else's article feed, or just sign in with your own to read your feed. one day nostr will transparently supplant RSS feeds as the obvious way to asynchronously distribute and track long-form content. there's just some missing components along the way we have to build.