Live data from Hacker News

A Broken Heart

allenpike.com

31–40 of 53 posts

Re: A Broken Heart

#31

> At that point, I reached for an age-old tool that has gotten more useful in the modern age: binary search. That is, you explain the symptom to your coding agent. Then you have it repeatedly remove stuff from your code that might be causing the problem Can someone give me some high level pointers on how to setup this scaffolding?

"git bisect" usually does the trick.

Re: A Broken Heart

#32
post #15

Earlier quoted context omitted.

I'd give people the benefit of the doubt. Personally, having built UI with Win32, WinForms, VisualBasic, Cocoa/Interface Builder, Qt, Tcl/Tk, XSLT, vanilla HTML/JS, jQuery, Backbone, Ember, Knockout, Bootstrap, MooTools, YUI, ExtJS, Svelte, Web Components, and React (including Preact, SolidJS…)… I'll happily choose the React approach. The only other one I would even describe as "good" was Qt. I also don't get why "XM…

But it is not really XML like syntax, is it? It is still a string, even if a template string or whatever it is called, no? That still leaves the door open for XSS. A good (proper?) (e?)DSL would have the things that make the DOM as keywords in the language, and then we could ensure, that things which should merely be a text, are really only rendered as text, not injected DOM nodes. And the next failure is, that this…

> It is still a string, even if a template string or whatever it is called, no?

No.

> That still leaves the door open for XSS.

The door for that in React is called `dangerouslySetInnerHTML`, but it's extremely rarely used.

> jsx needs to rename HTML attributes, because of overlap with JS keywords like "class"

That's not really inherent to JSX, just React's use of it. SolidJS, for example, uses `class` instead. But in any case – JSX didn't make up those names. Those are the property names on JavaScript's DOM classes. The fact that there's confusion between "attributes" and "properties" is pretty baked-in to the Web platform, even causing confusion in standard Web Components. Every DOM library and framework (even jQuery) has needed to decide whether it's operating on properties or attributes.

    const div = document.createElement('div');
    div.className = 'foo';
> It also comes with hacks like "" or fragment.

The DOM has the same concept, DocumentFragment. How else would you represent e.g. "two sibling nodes with no parent node"?

> It lacks the awareness of context and therefore is not truly like HTML.

On the contrary, I'd argue it has way more context. It knows, and will warn you, if you try to do any DOM element nesting that the HTML spec forbids, for example.

> can be structurally pattern matched upon and iterated through, like a proper tree structure.

You are literally describing the output of JSX. Glad you like it ;)

Re: A Broken Heart

#33

> At that point, I reached for an age-old tool that has gotten more useful in the modern age: binary search. That is, you explain the symptom to your coding agent. Then you have it repeatedly remove stuff from your code that might be causing the problem Can someone give me some high level pointers on how to setup this scaffolding?

When I read the first sentence, I expected the author to use `git bisect`.

However, what the author seems to have done is used a prompt with claude that probably looked something like this:

"Some piece of code is causing the page to load very slowly. To debug this, I'd like to use binary search, where we keep commenting/uncommenting 50% of the remaining code, and then I manually check if the page is still very slow. Let's start now; Comment out a component (or parts of a component) that you estimate is 50% of the page, and I will tell you if the page is still slow."

Re: A Broken Heart

#34
post #19

Maybe off topic, but I couldn't help thinking that "we need to show a heart icon" -> "let's use a heart emoji because it's easy" -> "let's use a specific emoji font for consistency across platforms" -> "let's import it from Google Fonts every time" seems like a problematic developer mindset. A better heuristic is always keep in mind not only developer efficiency, but also program efficiency. I'm not saying optimize e…

Not OT at all. Emojis everywere are ridiculous. And coding agents love them! They put emojis in Python log lines which inevitably break the console, and of course in web pages. Logs don't need emojis. Not sure if anything does.

I love using emojis in my log lines, especially symbols for info/warn/error, but it does add another layer of complexity as you have to go through so many things to make sure the text is now rendered in the right font, has Unicode support enabled, etc, etc.

Re: A Broken Heart

#35

Mostly read like a normal article if you skip over the parts about using agents, which I did. There could not possibly be a single thing in the world more boring than listening to someone describe using an AI agent. Might as well describe in arduous detail how you use a gas pump or a grocery store checkout.

I found the bit about using an agent to produce a minimal repro case interesting.

I'm very much on the side of "artisanally writing all code by hand" in terms of preference, but I have to admit that sometimes it puts me in a bind where there's stuff I wish I could do but don't because it's too time-consuming for the value provided. Isolating repro cases sometimes falls into that bucket.

This seems like a good use case for AI. Even if the resulting code isn't great, as long as it repros the issue and is fairly small, it's fine. It's eventually throwaway code anyway. At best, it will be harvested for a test case, but otherwise it's gone once the bug is fixed.

Re: A Broken Heart

#36
> Naturally, I blamed React.

Did the author start a client-side debugging process without running any kind of diagnostics in the dev tools?

To me this sounds like "I saw some slowness in my application, so naturally I started adjusting indexes in my database." Without doing any upfront research, you're basically just throwing darts and hoping one sticks. This type of approach to debugging has never served me well.

Re: A Broken Heart

#37
post #9

Earlier quoted context omitted.

It's not solid red. It has shading.

I don't think the blog post itself is using that emoji font. The screenshot on the Noto Emoji Github page[0] doesn't look like it's using any gradients for the heart emoji, just flat shading. But it is using gradients for some of the other emojis (e.g. the croissant), and obviously the SVG fallback is all or nothing, not per-glyph. [0] https://github.com/googlefonts/noto-emoji

You need to look closer; the heart emoji has a flat fill, but a gradient in its outline stroke, from lighter-than-red near the top, to darker-than-red on the bottom.

Re: A Broken Heart

#38

Mostly read like a normal article if you skip over the parts about using agents, which I did. There could not possibly be a single thing in the world more boring than listening to someone describe using an AI agent. Might as well describe in arduous detail how you use a gas pump or a grocery store checkout.

Maybe consider that other people are not as au fait with AI.

There are plenty of people learning to use AI and this article helps them.

A reasonable amount of repetition of "things you should know" is good.

The article is well written because you could skip the parts you knew, and learn from the parts you were unfamiliar with.

Re: A Broken Heart

#39

> At that point, I reached for an age-old tool that has gotten more useful in the modern age: binary search. That is, you explain the symptom to your coding agent. Then you have it repeatedly remove stuff from your code that might be causing the problem Can someone give me some high level pointers on how to setup this scaffolding?

I do this all the time in a dumb but effective way. Add logging statements to code paths that drop timing info. Another dumb but effective way, instead of using a step through debugger, is drop "here, value is {val}". Telling claude to do this is trivial, it's quick, and it can read its own output and self-solve the problem all with just the code itself.

IMHO git bisect is slower, especially depending on the reload/hot-reload/compile/whatever process your actual app is using.

Re: A Broken Heart

#40

> At that point, I reached for an age-old tool that has gotten more useful in the modern age: binary search. That is, you explain the symptom to your coding agent. Then you have it repeatedly remove stuff from your code that might be causing the problem Can someone give me some high level pointers on how to setup this scaffolding?

When I read the first sentence, I expected the author to use `git bisect`. However, what the author seems to have done is used a prompt with claude that probably looked something like this: "Some piece of code is causing the page to load very slowly. To debug this, I'd like to use binary search, where we keep commenting/uncommenting 50% of the remaining code, and then I manually check if the page is still very slow.…

`git bisect` is interesting option. I haven't heard about it before. Thanks for info. Still learning something ;)

I'm old school. I used to do "manual bisection" on git history by just `git checkout ` until I find first introducing bug commit.

Then another "bisection" on commit changes until minimal change found.

Deterministic bugs are quite "fine". For me personally worst are randomly occurring bugs in specific conditions for eg. some race conditions.

Post reply on HN