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

331–340 of 450 posts

Re: Fast

#331

Post by pjmlp »

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…

Not only that, I am already typing enough for coding, I don't want to type on chat windows as well, and so far the voice assistance is so so.

Re: Fast

#332

Post by pjmlp »

pron wrote: post #152
cycomanic wrote: post #146

Earlier quoted context omitted.

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…

Programmers (and I'm including myself here) often go to great lengths to not think, to the point of working (with or without a coding assistant) for hours in the hope of avoiding one hour of thinking. What's the saying? "An hour of debugging/programming can save you minutes of thinking," or something like that. In the end, we usually find that we need to do the thinking after all. I think coding assistants would end…

I agree with your comment in general, however I would say that on my field, the resistence to TLA+ isn't having to think, rather having to code twice without guarantees that it actually maps to the theorical model.

Tools like Lean and Dafny are much more appreciated, as they generate code from the model.

Re: Fast

#334

Post by nobodywillobsrv »

Is it just me or is the premise of this the opposite of your work life as well? I have worked in the space of "fast" primarily and that is the main objective. Fast, iterate ... Don't be like "IT" (the slow team nobody can fire who never finishes anything).

Of course fast has downsides but it's interesting this pitch is here. Must have occurred many times in the past.

"Fast" was often labeled "tactical" (as opposed to "strategic" in institutions). At the time I remember thinking a lot about how delays plus uncertainty meant death (nothing gets done, or worse). Even though Fast is often at the cost of noise and error, there is some principle that it can still improve things if not "too far".

Anyone know deeper writings on this topic?

Re: Fast

#335

Post by dang »

abrookewood wrote: post #268
FlyingSnake wrote: post #156

Earlier quoted context omitted.

HN is literally the website I open to check if I have internet connectivity. HN is truly a shining beacon in the trashy landscape of web bloat.

yep, I do exactly the same thing. If HN isn't loading, something is definitely fckd.

Except when HN itself is fckd.

It does happen less than it used to, but still.

(Edit: Btw, it's fine to say 'fucked' or other swear words on HN - we don't care about profanity and aren't Bowdlers. I add this because people sometimes misinterpret https://news.ycombinator.com/newsguidelines.html that way, assuming that we want drawing-room politness.)

Re: Fast

#336

Post by dang »

throwawayexmple wrote: post #199
FlyingSnake wrote: post #156

Earlier quoted context omitted.

HN is literally the website I open to check if I have internet connectivity. HN is truly a shining beacon in the trashy landscape of web bloat.

I find pinging localhost a bit more reliable, and faster too. I blame HN switching to AWS. Downtime also increased after the switch.

When did you notice HN switching to AWS, and what changed?

(Those are trick questions, because we haven't switched to AWS. But I genuinely would like to hear the answers.)

(We did switch to AWS briefly when our hosting provider went down because of a bizarre SSD self-bricking incident a few years ago...but it was only for a day or two!)

Re: Fast

#337

Post by dang »

frutiger wrote: post #214
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…

The HN UI could do with some improvements, especially on mobile devices. The low contrast and small tap areas for common operations make it less than ideal, as well as the lack of dark mode. I wrote my take on an ideal UI (purely clientside, against the free HN firebase API, in Elm): https://seville.protostome.com/ .

Anyone who goes to the trouble of making their own HN front end is entitled to complain as much as they want, in my book! Nicely done.

Re: Fast

#338

Post by Karrot_Kream »

skydhash wrote: post #225
kfajdsl wrote: post #204

Earlier quoted context omitted.

You mentioned grep-mode, which to my knowledge is just bringing up a buffer with all the matches for a regex and easily jumping to each point (I use rg.el myself). For the record, this is basically the same thing as VSCode's search tool. Now, once you have that, to actually make edits, you have to record a macro to apply at each point or just manually do the edit yourself, no? I don't pretend LLMs are perfect, but I…

Maybe it's my personal workflow, but I either have sweeping changes (variable names, removing dependencies) which are easily macroable, or very targeted one (extracting functions, decoupling stuff,..,). For both, this navigation is a superpower and coupled with the other tools of emacs/vim, edit is very fast. That rely on a very good mental model of the code, but any question can be answered quickly with the above to…

Yes I've done this kind of refactoring for ages using emacs macros and grep. Language Server and tree-sitter in emacs has made this faster (when I can get all the dependencies setup correctly that is.) Variable name edits and function extraction is pretty much table stakes in most modern editors like IntelliJ, VSCode, Zed, etc. IIRC Eclipse had this capability 15-20 years ago.

I used to have more patience for doing it the grep/macro way in emacs. It used to feel a bit zen, like going through the code and changing all the call-sites to use my new refactor or something. But I've been coding for too long to feel this zen any longer, and my own expectations for output have gotten higher with tools like language-server and tree-sitter.

The kind of refactorings I turn to an LLM for are different, like creating interfaces/traits out of structs or joining two different modules together.

Re: Fast

#339

Post by nakedneuron »

Website is superfast. Reason I usually go for the comments first on HN is exactly this: they're fast. THIS is notably different.

On interfaces:

It's not only the slowness of the software or machine we have to wait for, it's also the act of moving your limb that adds a delay. Navigating a button (mouse) adds more friction than having a shortcut (keyboard). It's a needless feedback loop. If you master your tool all menus should go away. People who live in the terminal know this.

As a personal anecdote, I use custom rofi menus (think raycast for Linux) extensively for all kinds of interaction with data or file system (starting scripts, opening notes, renaming/moving files). It's notable how your interaction changes if you remove friction.

Venerable tools in this vein: vim, i3, kitty (former tmux), ranger (on the brim), qutebrowser, visidata, nsxiv, sioyek, mpv...

Essence of these tools is always this: move fast, select fast and efficiently, ability to launch your tool/script/function seamlessly. Be able to do it blindly. Prefer peripheral feedback.

I wish more people saw what could be and built more bicycles for the mind.

Re: Fast

#340

Post by CraigJPerry »

>> Rarely in software does anyone ask for “fast.”

I don't know, there are a sizeable subset of folks who value fast, and it's a big subset, it's not niche.

Search for topics like turning off animations or replacing core user space tools with various go and rust replacements, you'll find us easily enough.

I'm generally a pretty happy MacOS user, especially since M1 came along. But I am seriously considering going back to linux again. I maintain a parallel laptop with nixos and i'm finding more and more niggles on the mac side where i can prioritise lower friction on linux.

Post reply on HN