Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fast

catherinejue.com

Post reply on HN
Print view View original

181–190 of 450 posts

Re: Fast

#181

Post by skydhash »

kfajdsl wrote: post #109
skydhash wrote: post #94

Earlier quoted context omitted.

I supposed you haven’t tried emacs grep mode or vim quickfix? If the change is mechanical, you create a macro and be done in seconds. If it’s not, you still got the high level overview and quick navigation.

Finding and jumping to all the places is usually easy, but non trivial changes often require some understanding of the code beyond just line based regex replace. I could probably spend some time recording a macro that handles all the edge cases, or use some kind of AST based search and replace, but cursor agent does it just fine in the background.

Code structure is simple. Semantics is where it get tough. So if you have a good understanding of the code (and even when you don't), the overview you get from one of those tools (and the added interactivity) is nice for confirming (understanding) the needed actions that needs to be done.

> cursor agent does it just fine in the background

That's for a very broad definition of fine. And you still need to review the diff and check the surrounding context of each chunk. I don't see the improvement in metrics like productivity and cognitive load. Especially if you need to do serveral rounds.

Re: Fast

#182

Post by zahlman »

citizenpaul wrote: post #62
PaulHoule wrote: post #2

Kinda funny but I think LLM-assisted workflows are frequently slow -- that is, if I use the "refactor" features in my IDE it is done in a second, if I ask the faster kind of assistant it comes back in 30 seconds, if I ask the "agentic" kind of assistant it comes back in 15 minutes. I asked an agent to write an http endpoint at the end of the work day when I had just 30 min left -- my first thought was "it took 10 min…

The only thing I've found that LLM speeds up my work is a sort of advanced find replace. A prompt like " I want to make this change in the code where any logic deals with XXX. To be/do XXX instead/additionally/somelogicchange/whatever" It has been pretty decent at these types of changes and saves time of poking though and finding all the places I would have updated manually in a way that find/replace never could. Tho…

> A prompt like " I want to make this change in the code where any logic deals with XXX. To be/do XXX instead/additionally/somelogicchange/whatever"

If I reached a point where I would find this helpful, I would take this as a sign that I have structured the code wrongly.

Re: Fast

#183

Post by jorvi »

stevage wrote: post #172
KPGv2 wrote: post #157

Earlier quoted context omitted.

The one and only thing I'd do is make the font bigger and increase padding. There's overwhelming consensus that you should have (for English) about 50–70 characters per line of text for the best, fastest, most accurate readability. That's why newspapers pair a small font with multiple columns: to limit number of characters per line of text. HN might have over 100 chars per line of text. It could be better. I know I c…

Increased padding comes at the cost of information density. I think low density UIs are more beginner friendly but power users want high density.

High information density, not high UI density.

Having 50 buttons and 10 tabs shoved in your face just makes for opaqueness, power user or not.

Re: Fast

#184

Post by zahlman »

willsmith72 wrote: post #129
flobosg wrote: post #107

Earlier quoted context omitted.

A process taking 0 seconds means that, in one year, it can be run 31540000 sec/0 sec = ∞ times, multiplying the profit by ∞.

Since when is the constraint "how many times can I run this thing"?

In principle, the reason that "every second saved here is worth $x" is because running the thing generates money, and saving time on it allows for running it more often.

Re: Fast

#185

Post by markasoftware »

cycomanic wrote: post #146
PaulHoule wrote: post #2

Kinda funny but I think LLM-assisted workflows are frequently slow -- that is, if I use the "refactor" features in my IDE it is done in a second, if I ask the faster kind of assistant it comes back in 30 seconds, if I ask the "agentic" kind of assistant it comes back in 15 minutes. I asked an agent to write an http endpoint at the end of the work day when I had just 30 min left -- my first thought was "it took 10 min…

I've already written about this several times here. I think the current trend of LLMs chasing benchmark scores are going in the wrong direction at least as programming tools. In my experience they get it wrong with enough probability, so I always need to check the work. So I end up in a back and forth with the LLM and because of the slow responses it becomes a really painful process and I could often have done the ta…

GitHub copilot's inline completions still exist, and are nearly instant!

Re: Fast

#186

Post by zahlman »

ilyakaminsky wrote: post #69

Fast is also cheap. Especially in the world of cloud computing where you pay by the second. The only way I could create a profitable transcription service [1] that undercuts the rest was by optimizing every little thing along the way. For instance, just yesterday I learned that the image size I've put together is 2.5× smaller than the next open source variant. That means faster cold boots, which reduces the cost (and…

Yep. I'm hoping that installed copies of PAPER (at least on Linux) will be somewhere under 2MB total (including populating the cache with its own dependencies etc). Maybe more like 1, although I'm approaching that line faster than I'd like. Compare 10-15 for pip (and a bunch more for pipx) or 35 for uv.

Re: Fast

#188

Post by skydhash »

Karrot_Kream wrote: post #111
skydhash wrote: post #94

Earlier quoted context omitted.

I supposed you haven’t tried emacs grep mode or vim quickfix? If the change is mechanical, you create a macro and be done in seconds. If it’s not, you still got the high level overview and quick navigation.

emacs macros aren't the same. You need to look at the file, observe a pattern, then start recording the macro and hope the pattern holds. An LLM can just do this.

And that's why I mentionned grep-mode, and such other tools. Here is some videos about what I'm talking about

https://youtu.be/f2mQXNnChwc?t=2135

https://youtu.be/zxS3zXwV0PU

And for Vim

https://youtu.be/wOdL2T4hANk

Standard search and replace in other tools pales in comparison.

Re: Fast

#189

Post by postalcoder »

hn_throwaway_99 wrote: post #104

Just want to say how much I thank YCom for not f'ing up the HN interface, and keeping it fast. I distinctly remember when Slashdot committed suicide. They had an interface that was very easy for me to scan and find high value comments, and in the name of "modern UI" or some other nonsense needed to keep a few designers employed, completely revamped it so that it had a ton of whitespace and made it basically impossibl…

It’s not modern UIs that prevent websites from being performant. Look at old.reddit.com, for instance. It’s the worst of both worlds. An old UI that, although much better than its newer abomination, is fundamentally broken on mobile and packed to the gills with ad scripts.

Re: Fast

#190

Post by portaouflop »

KPGv2 wrote: post #157
Eji1700 wrote: post #114

Earlier quoted context omitted.

Information density and ease of identification is the antithesis of "engagement" which often has some time on site metric they're hunting. If you can find what you want and read it you might not spend 5 extra seconds lost on their page and thus they can pad their stats for advertisers. Bonus points if the stupid page loads in such a way you accidentally click on something and give them a "conversion". Sadly financial…

The one and only thing I'd do is make the font bigger and increase padding. There's overwhelming consensus that you should have (for English) about 50–70 characters per line of text for the best, fastest, most accurate readability. That's why newspapers pair a small font with multiple columns: to limit number of characters per line of text. HN might have over 100 chars per line of text. It could be better. I know I c…

There are dozens of alternative HN front ends that would satisfy your needs
Post reply on HN