zem

if nothing else, you could guess that a compilation error within a function body would still let other functions be compiled, and proceed on that basis.

for me the distinction is that pre-"content" you created a website so you have a place to host your art; with "content" you produce art to have something to put on your website.

would prove that robots were subject to nominative determinism too, if nothing else!

Counterexamples welcome.

I mentioned "peas and honey" in another comment. zucchini and lube if you wanted to go for "haha weird sex practices", though just having condoms/lube in there doesn't make things intrinsically funny the way the OP seems to imagine. baby food and wine/headache pills/earplugs, for more sitcom-level humour ("haha, yeah, having a newborn is hard, we've all been there!"). knife and large garbage bags for a darker turn

the basic idea is "these two specific items suggest a funny image of them being used together, with the added context that it was likely just a random coincidence". it's not laugh-out-loud humour, but it can be amusing.

yeah the idea of "funny" seemed pretty puerile to me

search for peas and honey!

at the very least you could follow some trusted entity's recommendation for a bunch of crates at once. e.g. if the author of some large rust project like bevy published a battery pack I would pay attention because they have had to solve the problem of picking out several crates and seeing that they all work well together.

apart from anything else it has a really beautiful object system. I feel like racket and ocaml are two languages where the object system doesn't get enough love.

personal taste, for the most part. I like the thought of a single namespace, it fits my intuition from pretty much every other language out there, and I like how the code looks when I can pass functions around as though their names are regular variable bindings to an underlying function object.

this is definitely true for forth (:

people don't usually think of C as a host platform, but the python community has a similarly symbiotic relationship with C extensions.

i'm not sure i understand your objection. here's a concrete example of what i'm talking about:say i want to add a new feature to my code analyser, exception-aware code analysis. it ends up being 2000 lines worth of diffs, touching a bunch of files, and definitely too much to review in one go. so what i do is, first i write a doc file describing the feature, to show what i'm working towards. then i write a small commit, "add a new `exception_handlers` member to the context struct, and a small class containing its datatype", and upload it for review. why is this new member needed? see the plan doc pointed to by the commit message! now i needn't wait for it to be reviewed, i can stack another commit on top of it, "populate the exception_handlers info by walking the AST". it depends on the exception_handlers member being in the struct, but, crucially, it doesn't depend on that code being merged in, because it's there in the stack below this commit. i can keep adding things like "inherit exception_handlers when analysing function calls", "validate that all explicitly raised exceptions are caught by an exception handler in the current scope", etc - there are a lot of moving parts to analyse exception handling, but each commit is fairly small, does one precise thing, and is therefore relatively easy to review.

when the stack is complete and all the commits are uploaded to wherever (we use phabricator but i'm sure github has an equivalent) for review i just need to sit back (or work on something else) while my reviewer(s) go through each commit and validate that it looks like it does what it says on the tin. as soon as the bottom of the stack gets approved i can merge it in, or i can wait for everything to be reviewed. if there are any changes i do them and rebase the rest of the stack on top of the changed commit, fixing merge conflicts if needed. (it really helps if your tooling supports this workflow, of course!). and when it's all reviewed and merged, the effect is exactly the same as if i'd just sent in a 2000 line combined commit and merged it in - there's no need to go look through the git history for anything, the code will hopefully make sense as part of the codebase.

not if you break your work into a stack of PRs, which is the standard practice for my team at work. you just keep adding PRs to the top of the stack while the reviewer proceeds from the bottom. if something changes you propagate the change up the stack, which LLMs are also pretty good at doing.

unlike the op, I've been having a wonderful time using claude, both at work and for my own personal projects, so I will share what has worked for me, just in case it resonates with anyone else.

my anecdotal advice is to avoid the entire "agent" temptation, and treat the LLM as a code generator. have a single session running at a time. come up with a plan, iterate on it until you are satisfied, then tell it to execute the plan, and watch it. not necessarily to the extent of reading the scroll (though I sometimes do do that too!) but as it finishes each step look over what it has done, suggest improvements and course corrections, and then let it go on to the next step. at the end you will have a pretty good grasp of the state of the code, and the overall time it will take you isn't really any longer than trying to churn out reams of code and then go through it all at once.

the other option if you want something closer to a one shot workflow is to go into far more detail during the planning stage, have it describe not just architectural details but actual code (if you're a senior engineer especially you probably know what the key pieces of code that will drive a lot of other decisions mechanically are likely to be).

also refactoring is cheaper than it has ever been, if something feels hard to grasp to you stop and work with the LLM until you like the looks of it better.

and again, the key bit is to have one LLM doing one thing at a time, and to stay engaged in the process while it does so.

asimov's "profession" is a very relevant SF short: https://www.inf.ufpr.br/renato/profession.html

the exoskeleton metaphor is way older than the current wave of LLMs

"All happy families are alike; each unhappy family is unhappy in its own way" -- Leo Tolstoy, "Anna Karenina"

I spent two days last week trying to figure out why a docx file I was generating with python-docx looked fine in libreoffice but would not open in word. it was just some text with a circle overlaid on it, but word is a lot fussier about the xml structure of the document than libreoffice is. finally had to create the same structure directly in msword and have claude examine the two files for differences.

I ran into a pretty funny instance just yesterday - I was upgrading my windows partition to windows 11 and I asked claude if there was any chance it could corrupt my linux partition in the process. claude confidently said that yes there was a known failure mode where if the recovery partition was not large enough for windows 11 it would silently resize it, damaging the neighbouring partition. it even told me what system command it used to do so.

I googled the command and when the gemini prompt came up I said that claude had told me it might be run during the upgrade and damage my linux partition. gemini said "there is no such argument to that program, the other AI is hallucinating, and here is the knowledge base article that probably caused it to go wrong", which was actually pretty impressive, and amusing in the way it used both the term "hallucinating" and the phrase "the other AI".

I fear that it's more insidious than that - that the questions the OP is asking are already things that the other person has decided (consciously or otherwise) that they no longer bother thinking about themselves and just outsource the effort to the nearest LLM

I think the line is between AI-generated and AI-assisted - I have AI assisted projects that I have happily been developing for several months and they are going fine, I feel just as engaged with them as I did with my hand coded projects, but also I am more engaged insofar as I actively manage the architecture and the code, and see to it that the AI is following the plan I have in mind.

people chasing after "one shot" code certainly aren't helping, I agree.

brings back fond memories of idlerpg

the problem is not the people who want impulse satisfaction, comfort, and convenience - these are all perfectly normal human desires. the problem is that we as a society have allowed predators to tie these needs to surveillance and addiction engineering. there is no intrinsic reason that couldn't have been regulated against - look at some of the absolutely idiotic things the government is willing to spend time and money in micromanaging.

I was lucky enough to have Morrison and Boyd as my undergrad ochem textbook. they built the material up really well from first principles.

https://www.anildash.com/2024/11/19/dont-call-it-a-substack/ is a persuasive argument for the opposite

the claude giveth and the claude taketh away. I could definitely use claude in a tightly directed manner to clean up a slopified codebase (and I would enjoy doing so), you just need to think of it as closer to a power tool than an agent.

imagine not 2% of users not being able to use the site, but any given user not being able to use the site 2% of the time, and see if that changes the calculus for you.

I know what they meant, I was saying that imo the ergonomic name is has_not_been_viewed_much. it's directly expressing the property you are interested in, as opposed to expressing the negative property and comparing it to false.

why, though? the current version is the interesting property

wow, that really is lovely. my favourite one so far.