Why's this so highly rated. Y'all don't know that fast is good?
Fast
301–310 of 450 posts
Re: Fast
#302Earlier 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…
it's funny, I feel like I'm the opposite and it's why I truly hate working with stuff like claude code that constantly wants to jump into implementation. I want to be in the driver's seat fully and think about how to do something thoroughly before doing it. I want the LLM to be, at most, my assistant. Taking on the task of being a rubber duck, doing some quick research for me, etc.
It's definitely possible to adapt these tools to be more useful in that sense... but it definitely feels counter to what the hype bros are trying to push out.
Re: Fast
#303A lot of people have low expectations from having to use shit products at work, and generally not being discerning. Speed is what made Google, which was a consumer product at the time. (I say this because it matters more in consumer products.)
I don’t think people realize how much working with bad tools inspired you to write equally bad applications.
Beautiful tools make you stretch to make better things with them.
Re: Fast
#304I 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.
We're pretty lucky here in Australia. Over the past decade or so, PayID has been successfully rolled out to virtually all banks, giving us free and (usually) instant money transfers - I'd say more than half of all personal payments are now done with PayID. Old-skool bank transfers are still the norm for business and administrative payments, but that's changing too, and in any case, those transfers are increasingly being executed behind the scenes over Osko (aka PayID), so they end up settling in seconds (or at least hours) instead of days.
Re: Fast
#305I've noticed over and over again at various jobs that people underestimate the benefit of speed, because they imagine doing the same workflow faster rather than doing a different workflow. For example, if you're running experiments in one big batch overnight, making that faster doesn't seem very helpful. But with a big enough improvement, you can now run several batches of experiments during the day, which is much mo…
Whenever we make our code faster the users just run bigger models :P.
Re: Fast
#306Only sorta related, but it’s crazy that to me how much our standards have dropped for speed/responsiveness in some areas. I used to play games on N64 with three friends. I didn’t even have a concept of input lag back then. Control inputs were just instantly respected by the game. Meanwhile today, if I want to play rocket league with three friends on my Xbox series S (the latest gen, but the less powerful version), I…
Heck yes! I recently dusted off (had to literally dust the inside of the cartridges to get past a black screen, lol) my old Sega Genesis (and bought an HDMI adaptor for it), and have been letting my school age sons play it. They haven't even commented on the basic graphics. They're like "wow dad, no boot time, no connecting to server time, no waiting to skip ads time". They love it.
Re: Fast
#307Earlier 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…
> 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. This is such a great observation.…
This is your brain trying conserve your energy/time by recollecting/brute-forcing/following known patterns, instead of diving into unknown. Otherwise known as „being lazy” / procrastinating.
Re: Fast
#308Back in the 90's I ran a dev team building Windows applications in VB, and had the rule that the dev machines had to be lower-specced than the user machines they were programming for.
It was unpopular, because devs love the shiny. But it worked - we had nice quick applications. Which was really important for user acceptance.
I didn't make this rule because I hated devs (though self-hatred is a thing ofc), or didn't want to spend the money on shiny dev machines. I made it because if a process worked acceptably quickly on a dev machine then it never got faster than that. If the users complained that a process was slow, but it worked fine on the dev's machine, then it proved almost impossible to get that process faster. But if the dev experience of a process when first coding it up was slow, then we'd work at making it faster while building it.
I often think of this rule when staring at some web app that's taking 5 minutes to do something that appears to be quite simple. Like maybe we should have dev servers that are deliberately throttled back, or introduce random delays into the network for dev machines, or whatever. Yes, it'll be annoying for devs, but the product will actually work.
Re: Fast
#309Efficient code is also environmentally friendly. First, efficient code is going to use less electricity, and thus, fewer resources will need to be consumed. Second, efficient code means you don't need to be constantly upgrading your hardware.
Unless your code is running on a large number of machines across data centers that energy is about 2-3 figures a month in total utilization.
So if we use cost as a proxy for environment impact it’s not saving much at all.
I think this is a meme to help a different audience care about performance.
Re: Fast
#310Earlier quoted context omitted.
And yet we live in a world of (especially web) apps that are incredibly slow, in the sense that an update in response to user input might take multiple seconds. Yes, fast wins people over. And yet we live in a world where the actual experience of every day computing is often slow as molasses.
The trouble is that "fast" doesn't mean anything without a point of comparison. If all you have is a slow web app, you have to assume that the web app is necessarily slow — already as fast as it can be. We like to give people the benefit of the doubt, so there is no reason to think that someone would make something slower than is necessary. "Fast" is the feature people always wanted, but absent better information, th…
I’ll tell you what fast is.
I’ve mentioned this before.
Quest Diagnostics, their internal app used by their phlebotomists.
I honestly don’t know how this app is done, I can only say it appears to run in the tab of a browser. For all I know it’s a VB app running in an ActiveX plugin, if they still do that on Windows.
L&F looks classic Windows GUI app, it interfaces with a signature pad, scanner, and a label printer.
And this app flies. Dialogs come and go, the operator rarely waits on this UI, when she is keying in data (and they key in quite a bit), the app is waiting for the operator.
Meanwhile, if I want to refill a prescription, it fraught with beach balls, those shimmering boxes, and, of course, lots of friendly whitespace and scrolling. All to load a med name, a drugstore address, and ask 4 yes/no questions.
I look at that Quest app mouth agape, it’s so surprisingly fast for an app in this day and age.