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

61–70 of 450 posts

Re: Fast

#61

Post by joshvm »

Liftyee wrote: post #54

I always have to remind myself of the bank transfer situation in the US whenever I read an article complaining about it. Here in the UK, bank transfers are quick and simple (the money appears to move virtually instantly). Feel free to enlighten me to why they're so slow in the US.

For ACH, it's the scheduling and batching that makes it slow. The transfer itself should be instant but often my bank sends it out around midnight. This is why Venmo and Zelle are so popular. You can also modify/cancel a bank transfer before it goes through, which is nice.

This is the same in Switzerland. If you request an IBAN transfer, it's never instant. The solution there for fast payments is called TWINT, which works at almost POS terminal (you take a picture of the displayed QR code).

I think BACS is similarly "slow" due to the settlement process.

Re: Fast

#62

Post by citizenpaul »

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. Though I've never tried this on a huge code base.

Re: Fast

#63

Post by SatvikBeri »

Aurornis wrote: post #32

> Rarely in software does anyone ask for “fast.” We ask for features, we ask for volume discounts, we ask for the next data integration. We never think to ask for fast. Almost everywhere I’ve worked, user-facing speed has been one of the highest priorities. From the smallest boring startup to the multi billion dollar company. At companies that had us target metrics, speed and latency was always a metric. I don’t thin…

At 6 out of 8 companies I've worked at (mostly a mixture of tech & finance) I have always had to fight to get any time allotted for performance optimization, to the point where I would usually just do it myself under the radar. Even at companies that measured latency and claimed it was important, it would usually take a backseat to adding more features.

Re: Fast

#65

Post by [deleted] »

Liftyee wrote: post #54

I always have to remind myself of the bank transfer situation in the US whenever I read an article complaining about it. Here in the UK, bank transfers are quick and simple (the money appears to move virtually instantly). Feel free to enlighten me to why they're so slow in the US.

[deleted]

Re: Fast

#66

Post by edwcross »

fouronnes3 wrote: post #38
Aurornis wrote: post #33

Earlier quoted context omitted.

> I have to deal with VERY noticeable input lag. Like maybe a quarter of a second. It’s pretty much unplayable Your experience is not normal. If you’re seeing that much lag, the most likely explanation is your display. Many TVs have high latency for various processing steps that doesn’t matter when you’re watching a movie or TV, but becomes painful when you’re playing games.

This does not undermine chamomeal's argument. The whole point is that back in the N64 days, they could not possibly have had that experience. There was no way to even make it happen. The fact that today it's a real possibility when you've done nothing obviously wrong is a definite failure.

TVs back then supported a given standard (NTSC, PAL) and a lower resolution. CRTs couldn't "buffer" the image. Several aspects made it so that "cheating" was not possible.

It was either fast, or nothing. Image quality suffered, but speed was not a parameter.

With LCDs, lag became a trade-off parameter. Technology enabled something to become worse, so economically it was bound to happen.

Re: Fast

#67

Post by SatvikBeri »

SideburnsOfDoom wrote: post #58
pclowes wrote: post #6

Highly Agree. Speed of all kinds is incredibly important. Give me all of it. - Fast developers - Fast test suites - Fast feedback loops - Fast experimentation Someone (Napoleon?) is credited with saying "quantity has a quality all its own", in software it is "velocity has a quality all its own". As long as there is some rigor and you aren't shipping complete slop, consistently moving very quickly fixes almost every o…

> Someone (Napoleon?) is credited with saying "quantity has a quality all its own" Joe Stalin, I believe. It's a grim metaphor regarding the USSR's army tactics in WW2. https://www.goodreads.com/quotes/795954-quantity-has-a-quali...

According to Wikiquotes, this is a common misattribution, and the first known record is Ruth M. Davis from 1978, who attributes it to Lenin: https://en.wikiquote.org/wiki/Quantity

Re: Fast

#68

Post by chaps »

This is such an important principle to me that I've spent a lot of effort developing tooling and mental models to help with. Biggest catalyst? Being on-call and being woken up at 3am when you're still waking up... in that state, you really( don't want things to go slowly. You just want to fix the damn thing and get back to sleep.

For example, looking up command flags within man pages is slooooow and becomes agonizingly frustrating when you're waking up and people are waiting for you so that they can also go back to sleep. But if you've spent the time to learn those flags beforehand, you'll be able to get back to sleep sooner.

Re: Fast

#69

Post by ilyakaminsky »

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 providers a better service).

[1] https://speechischeap.com

Re: Fast

#70

Post by mvieira38 »

9rx wrote: post #12

> Rarely in software does anyone ask for “fast.” They don't explicitly ask for it, but they won't take you seriously if you don't at least pretend to be. "Fast" is assumed. Imagine if Rust had shown up, identical in every other way, but said "However, it is slower than Ruby". Nobody would have given it the time of day. The only reason it was able to gain attention was because it claimed to be "Faster than C++". Watch…

Only in the small subset of programmers that post on HN is that the case. Most users or even most developers don't mind slow stuff or "getting into flow state" or anything like that, they just want a nice UI. I've seen professional data scientists using Github Desktop on Windows instead of just learning to type git commands for an easy 10x time save
Post reply on HN