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

361–370 of 450 posts

Re: Fast

#361

Post by dqv »

SideburnsOfDoom wrote: post #41

> Instant settle felt surprising in a world where bank transfers usually take days. Yeah, that's not "a world" it's just the USA. Parts of the world - EU, UK etc have already moved on from that. Don't assume that the USA is leading edge in all things.

> Yeah, that's not "a world" it's just the USA.

"In a world" is a figure of speech which acknowledges the non-universality of the statement being made. And no it is not "just the USA". Canada and Mexico are similarly slow to adopt real-time payments.

It is wild to tell someone "don't assume" when your entire comment relies on your own incorrect assumption about what someone meant.

Re: Fast

#362

Post by 0wis »

mvieira38 wrote: post #70
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

Not everyone is conscious about it but I feel like it’s something that people will always want.

Like the « evergreen » things Amazon decided to focus on : faster delivery, greater selection, lower cost.

Re: Fast

#365

Post by fragmede »

scrollaway wrote: post #265
inopinatus wrote: post #251

Earlier quoted context omitted.

I like to use example.com/net/org bonus, these have both http & https endpoints if you needed a differential diagnosis or just a means to trip some shitty airline/hotel walled garden into saying hello.

https://neverssl.com :)

httpS://neverssl.com?

Re: Fast

#366

Post by nvarsj »

Cthulhu_ wrote: post #347
nakedneuron wrote: post #339

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 men…

The website is fast because it's minimal, just under 80 kB of which 55 is the custom font; this is fine for plain content sites, but others will have other requirements. There's never a reason to make a content website use heavyweight JS or CSS though.

That’s actually why I don’t like discourse at all. If your community site needs loading icons I don’t want to use it.

Re: Fast

#367

Post by atoav »

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

As some working on embedded audio DSP code I just had to laugh a little.

Yes, there is a ton of code that has a strict deadline. For audio that may be determined by your buffer size — don't write your samples to that buffer fast enough and you will hear it in potentially destructively loud fashion.

This changes the equation, since faster code now just means you are able to do more within that timeframe on the same hardware. Or you could do the same on cheaper hardware. Either way, it matters.

Similar things apply to shader coding, game engines, control code for electromechanical systems (there, missing the deadline can be even worse).

Re: Fast

#368

Post by oblio »

panarky wrote: post #318
pron wrote: post #152

Earlier quoted context omitted.

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…

> assume I haven't thought the problem through This is the essence of my workflow. I dictate rambling, disorganized, convoluted thoughts about a new feature into a text file. I tell Claude Code or Gemini CLI to read my slop, read the codebase, and write a real functional design doc in Markdown, with a section on open issues and design decisions. I'll take a quick look at its approach and edit the doc to tweak its app…

1. Shame on you, that doesn't sound like fun vibe coding, at all!

2. Thank you for the detailed explanation, it makes a lot of sense. If AI is really a very junior dev that can move fast and has access to a lot of data, your approach is what I imagine works - and crucially - why there is such a difference in outcomes using it. Because what you're saying is, frankly, a lot of work. Now, based on that work you can probably double your output as a programmer, but considering the many code bases I've seen that have 0 documentation, 0 tests, I think there is a huge chunk of programmers that would never do what you're doing because "it's boring".

3. Can you share maybe an example of this, please:

> and write a real functional design doc in Markdown, with a section on open issues and design decisions.

Great comment, I've favorite'd it!

Re: Fast

#369

Post by NohatCoder »

9rx wrote: post #25
Dylan16807 wrote: post #19

Earlier quoted context omitted.

Maybe for languages, but fast is easily left behind when looking for frameworks. People want features, people want compatibility, people will use electron all over.

> fast is easily left behind when looking for frameworks. Nah. React, for example, only garnered attention because it said "Look how much faster the virtual DOM is!". We could go on all day. > People want features, people want compatibility Yes, but under the assumption that it is already built to be as "fast" as possible. "Fast" is assumed. That's why "faster" is such a great marketing trick, as it tunes people into…

It is only fast compared to a really dumb baseline. But you are right that the story of React being fast was a big part of selling it.

Re: Fast

#370

Post by resonious »

oblio wrote: post #360
resonious wrote: post #352

Earlier quoted context omitted.

My dev environment works perfectly on Termux, and so does Claude Code. So I just run `claude` like normal, and everything is identical to how I do it on desktop. Edit: clarity

Do you use it on a phone or on a tablet?

Phone. One of those foldy ones though so pretty big screen.
Post reply on HN