For me it's the name[0]. map puts out an array that has been mapped from another array. filter puts out an array that is a filter of the input array. both of those are always true. reduce, on the other hand, may put out a reduction of the input array (probably most of the time), but the fact that it may not means that what is happening is not actually a reduction. In languages like js/ts, you don't even have to return anything of the same type as the input array's elements. You could literally "reduce" and array of integers to a cancellation token, or a state object, or anything else.
I realize it's not the most efficient way to work, but I like my code to read like instructions. There's nothing reduce will do that a for loop won't accomplish and the for loop (+ an accumulator, of course) is more clearly "readable" than reduce. If I read map, I know what's going on. If I read filter, I know what's going on. If I read reduce, I have to figure out what's going on, even if I'm pretty sure what is going on. If I could rely on reduce to always give me back an element of the input array, I would use it more. But since it can give back anything, I prefer the simplicity of a for loop.
[0] I don't have any suggestions for "better" names because the whole operation is hard to sum up in a word? "dispatch" makes sense, as a function dispatching a function over each element in an array, but it masks the concept of accumulation from return values. "transform" is accurate, but hardly descriptive at all. the list goes on. It's an undeniably useful little function, it's just hard to make it easy to understand and therefore debug.
But I honestly very rarely use it (by either name) outside of a couple of pasted-in snippets (that I can't recall right now) where the strategy fits exceptionally well, probably because of the dumb reason that I tend to forget which block argument comes first (accumulator, or iterated item)! With other two-item argument lists such as `Hash#map` it being `key, value` makes sense, but with reduce/inject I don't see an obvious order. And I guess I learned before it was likely that some kind of AI autocomplete would be filling the args in for me.
It reduces n items to one item, recursively. The items don’t have to have the same type. Arguably accumulate is a more fitting name. I think of “reduce” as in cooking, boiling a volume of stuff down to some essence.
It's an implied threat, which you can infer from the presentation of the information. For example:
You really should listen to me. If you need some time to think it over, I understand. It's a lot to consider and you've got a lot in your plate. I'll check in soon - would tomorrow be okay? If you need more time, just tell me when.
vs
You really should listen to me. I'll give you a day to think it over before I take further action.
Same information, but the latter assumes a position of authority (I, the person in charge, will be the provider of the time you will receive), and then uses that position to provide an ostensible benevolence as a way to mitigate the implied follow up of non-benevolence. The threat is introduced as the power disparity. The person in power has leverage over the less powerful and the threat is that they will use it. Remove the power disparity, and the implication of threat is also removed.
Unions also use the threat of striking as a leverage point against corporations. As I noted elsewhere in this thread, there seems to be a common fallacy in this thread of "threat = bad". Laws are threats too. You need a more convincing argument than this.
My comment is about how inference and implication can change the result of a message just as much as the content or context. Whatever axe you've got to grind about threats being bad has nothing to do with what I said. Laws are threats. Unions make threats. So what? My point stands. Things that are obviously threats are threats, and things that say the same things in different ways might not be threats.
Awesome! It's really cool that it uses public domain images as the inspiration, too. And even cooler that you link to the places where you got those public domain images.
same. none of the available prompts are what I would prompt claude with and I get way better results than this. makes sense to me why the provided prompts result in the simulated outcomes. garbage in, garbage out.
Part skeptic and part zetetic, what prompt would you have used?
My impression is that this is an oversimplified demonstration of what can happen when you prompt Claude in a system with many more variables (than two buttons and two colours).
If I want the button to turn blue and that's it, what instead do I ask? Even in a complicated system with many levers, what do I request other than the desired end result, hoping that Claude pulls the right levers to produce something acceptably close to what I think I asked for?
I dunno, but in my experience Claude looks at all the levers in your codebase, understands what they do, and then generally figures out how to achieve the desired end result.
And when it doesn't, it's usually because of things outside of the codebase -- iOS layout quirks that aren't documented, buggy Python libraries it's relying on where you then have to tell it to read the source to figure out what's going on, that kind of thing.
The other thing that I think a lot of people run into is that they launch it into a completely human-built system with hundreds of thousands of lines of code and expect run #1 to be perfect.
You have to change the system so that the AI understands it, via establishing what your beliefs are, how those are reflected in values (especially important if you have e.g. compliance needs), how those values are reflected in the operational and strategic levels, and then a variety of tactical behavior coaching. For example, I ban 2>/dev/null - super tactical, and I say I value simplicity over covering every edge case - a very broad generalization.
"Make the Add to Cart button blue" is fine as a first step. When that doesn't have the desired result, I would simply revert the change, start a new session, and do something like "Give the Add to Cart button its own theme separate from the default button theme. Make the color for this new theme blue.". If this gives almost the correct result (e.g. it's not the shade of blue I want) I'd do a followup like "change the Add to Cart theme from #00FF00 to #16b8c4" with no implication that the previous step was wrong. If it's wildly incorrect I'd start over and try to specify in more detail about what exactly should happen.
If I don't understand why changing one button changed them all, I would use an entirely separate session to ask questions about how the site theming works. The fact that the site has a bunch of weird coupling between themes is useful information, and if I don't know how to resolve that I'd ask Claude for ideas about how to safely eliminate the coupling, and once it proposes a reasonable idea tell it to implement that.
The two big things here I'd never do is use emotional languages in prompts, and I'd never tell Claude to revert changes and try again. Once the incorrect change is in the context it's poisoning all of your future results.
Surely at any point after "Make the "Add to Cart" button blue", it'd be faster to just do it yourself: "grep -r "Add to Cart", insert "addToCart" as a class to the html element, then crack open style.css to stick "button.addToCart {background-color: blue}"
I'm counting maybe 80 keystrokes? That's shorter than your second prompt.
This idea generalizes. Large Language Models are poorly suited for tasks that we have already purpose-built systems to be easy for humans to use. The easiest way to tell your website that you want a button to look a certain way is to update the code. If you know exactly how you want something done, we have developed an incredibly efficient way to tell computers how something should be done: it's called source code.
LLMs work best when they're handed tasks that you don't want to figure out how to do.
It "makes sense" that plainly telling the chat bot to make one button blue makes the whole site blue? It "makes sense" that correcting it and repeating 3 times that no, only the one button should be blue, should make the button a gradient and start a philosophical discussion around the nature of "blue"?
Wow, you AI people really have a negative view of the technology y'all are trying to sell as the next Jesus
I'm not trying to sell the technology at all, much less as a messiah, and I absolutely have a negative view of it. It's a token predictor - nothing more, nothing less. If you treat it like it is supposed to "make sense" of things, you get predictably bad results. It "makes sense" that if you don't make the sense for it, it will do poorly, because it's a glorified auto-complete.
If the agent's change has such a catastrophic effect, the first thing you do is tell it to explain why its change had that effect.
Once you understand what the problem is, you can give it better instructions. If the architecture is shit, the agent is going to have a rough time of it.
So how would you prompt it instead? Because that's exactly how I prompt it, because any reasonable human being would know exactly what I mean by "Make the shopping button blue", and I am sick and tired of getting shitty results.
The first prompt is fine, it's the following ones that are poor.
> Why is half the site blue now? I asked you to change one button.
> Half the site is blue. I asked for ONE button
Neither of these is an instruction to fix the problem, they're treating the AI like a person and telling it what it did wrong, expecting the implied admonishment to be enough to steer it back. But without an actual instruction, it just goes and does whatever it thinks will help, which is often arbitrary.
The response I would have used in this situation is
"The Cancel button is also blue now. Make sure the color change is only scoped to the Add to Cart button"
Most of the available responses throughout this "skit" are similar cases of expressing frustration first and guiding the result second.
Skip the emotion and say exactly what you want, and nothing besides that.
I feel like I can almost see the shape of this, but that it's still very blurry for me. Seems like it could be used for some cool stuff, but I can't quite make out what. Procedural generation? Shader effects? Beyond the more important physical stuff they describe in the article, seems like there's some potential for fun with this?
Seems good! I'd migrate some of my open source projects, but they utilize the public static page hosting features of GitLab and GitHub, since they are typescript libraries that are demonstrated in the browser, so I'm reluctant to upset that.
We have a custom integration for "Pages" in partnership with statichost.eu.
You'll get a fully provisioned static website (h3 enabled) in < 1m with the click of a button. Custom domains are supported. Effectively the same what GH Pages offer :)
As others have said: great article! I did find myself wanting them to get to the point, but once they started describing the bug and the fix, it was very satisfying. I'm very happy there are companies out there on the frontiers of functionality not only funding fixes and debugging measures, but taking the time to write up the details so we can all benefit.
Tailscale just moved up in my priorities list. Was going to host my next website with hostinger, but now I'm going to at least try to run a personal server with tailscale to make it public. I might not be able to figure it all out, and may end up going with the VPS route, but this gave me some appreciation for the company that makes me willing to try the less familiar method.
I'm with you. I would prefer to be known as a "content creator" rather than a "woodworker" or "game developer" or "illustrator" or "writer" or "musician". Especially because all of that work tends to overlap all of the time. It feels so limiting to be described by a singular part of what I do. And I'm neurotic enough to want a 'comprehensive' word, rather than to slash myself to death in a description.
I don't particularly like the term "content creator". It feels too blunt and sterile to be particularly useful. But it does seem to be generally useful in how wide-reachingly descriptive it is.
Anecdata, but I find it funny you mentioning woodworker and musician. I build guitars and I play them. There is /some/ overlap, but only at the end result of me playing the guitar I have built. If I were to distill either of the two disciplines into 'content' each endeavor would lose its own individual meaning for me.
Being a musician has nothing to do with the output of working with wood, and likewise, my prowess on gouges, chisels, and saws is irrespective of my ability to write an interesting chord progression. Using a catch-all term to amalgamate the output of multiple specializations I think detracts from the results being, well... special.
I can certainly understand that, but I don't lend any specialness to anything I do, which may be why I don't consider any of it as needing to be differentiated for its craft. It's very useful to be specific when going in to specifics, but it seems very pedantic to be specific when I'm being general or broad. It might stem from just having so many different areas of interest. Feels braggadocios to keep chiming in with "I do that too", when I could just cover everything with "I create various types of content".
Though, I will admit that I never include cooking in that. Food, for some reason, has never felt, to me, like "content". Can't say I've ever interrogated why.
I'm also a fan of maker! Good shout. Though, I will say, I tend to see "maker" and "creator" as pretty interchangeable. Right up until the point of saying "content maker". That...doesn't feel right.
If nothing else, this blog post certainly invites scrutiny over how much feelings affect what classifications feel comfortable.
Sweet! I was just looking for something like this, this past weekend. Lots of command line stuff, but not much in the way of GUI apps. Excited to check this out! Thanks!
I realize it's not the most efficient way to work, but I like my code to read like instructions. There's nothing reduce will do that a for loop won't accomplish and the for loop (+ an accumulator, of course) is more clearly "readable" than reduce. If I read map, I know what's going on. If I read filter, I know what's going on. If I read reduce, I have to figure out what's going on, even if I'm pretty sure what is going on. If I could rely on reduce to always give me back an element of the input array, I would use it more. But since it can give back anything, I prefer the simplicity of a for loop.
[0] I don't have any suggestions for "better" names because the whole operation is hard to sum up in a word? "dispatch" makes sense, as a function dispatching a function over each element in an array, but it masks the concept of accumulation from return values. "transform" is accurate, but hardly descriptive at all. the list goes on. It's an undeniably useful little function, it's just hard to make it easy to understand and therefore debug.
reply