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

431–440 of 450 posts

Re: Fast

#431

Post by jodrellblank »

NohatCoder wrote: post #425
jodrellblank wrote: post #404

Earlier quoted context omitted.

Someone posted their word game Cobble[1] on HN recently, the game gives some letters and the challenge is to find two English words which together use up all the given letters, and the combined two words to be as short as possible. A naive brute-force solver takes the Cobble wordlist of 64k words and compares every word against every other word and does 64k x 64k = 4Bn loops and in the inner loop body, loops over the…

Of course finding the optimal solution to a Cobble puzzle does not actually require the computation you describe. We can in a single pass find a limited set of candidate words and work out a solution with those.

Sure; after Casey Muratori saying that people argue with him that no normal developer needs to worry about performance, computers are fast enough, performance is a niche concern, I'm just musing how little data it takes - 64k is nothing to a modern person - and how abruptly anyone who wants a fast answer has to switch to think about performance, pre-processing the list, sorting more promising candidates first, using a faster language, noticing that it's embarrassingly parallel, etc.

Re: Fast

#432

Post by Fanmade »

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…

Absolutely! I have used Copilot for a few weeks and then stopped when I worked on a machine that didn't have Copilot installed and I immediately struggled with even basic syntax. Now I often use LLMs as advanced rubber ducks. By describing my problems, the solution often comes to my mind on its own and sometimes the responses I get are enough for me to continue on my own. In my opinion, letting LLMs directly code can be really harmful for the software developers, because they forget to think for themselves. Maybe I'm wrong and I am just slow to accept the new reality, but I try to keep writing most of my code on my own and improve my coding skills more than my prompting skills (while still using these tools, of course). For me, LLMs are like a grumpy and cynical old senior dev who is forced to talk in a very positive manner and who has fun trickling in some completely random bullshit between his actual helpful advice.

Re: Fast

#433

Post by bodhi_mind »

rick1290 wrote: post #428
bodhi_mind wrote: post #396

I’m senior developer on a feature bloated civil engineering web app that has 2 back end servers (one just proxies to the other) and has 8k lines of stored procedures as the data layer and many multi k line react components that intentionally break react best practices. I loathe working on it but don’t have the time to refactor legacy code. ———————- I have another project that I am principal engineer and it uses Djang…

whats your setup for the frontend? do you autogen your queries from DRF? do you prefer react headless over django templates?

If it’s something simple, I’ll use Django template because it’s very easy. Most stuff I work on these days requires more fancy ui so I’ll 100% use react or nextjs for front end (and I’ve be using zustand for state management). I’ll have an api util that uses axios and handles appending a jwt auth header to all requests and use that in my components. I like using Django-all-auth because it makes integrating email/google/microsoft auth really easy out of the box.

DRF is good, ninja is a little more light weight and flexible so it really comes down to the project.

Re: Fast

#434

Post by IshKebab »

fuzzfactor wrote: post #218
IshKebab wrote: post #196

Earlier quoted context omitted.

I often hear this sort of thing "Facebook was a success using PHP therefore language choice isn't important" or in this case "superhuman made their product fast and they still failed so speed isn't important". It's obviously wrong if you think about it for more than a second. All it shows is that speed isn't the only thing that matters but who was claiming that? Speed is important. Being slow doesn't guarantee failur…

>Being fast helps, but is rarely a product. >Being fast doesn't guarantee success. Sometimes it can be a deciding factor though. Also sometimes speedyness or responsiveness beyond nominal is not as much of a "must have" compared to nominally fast performance in place of sluggishness.

Yeah absolutely. At some point you go from "successful despite being slow" to "would have been a success if it wasn't so slow".

Re: Fast

#435

Post by joshvm »

maccard wrote: post #133
joshvm wrote: post #61

Earlier quoted context omitted.

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…

People are almost always talking about Faster Payments [0] rather than BACS. It really is instant. [0] https://en.m.wikipedia.org/wiki/Faster_Payment_System_(Unite...

Yeah Faster Payments is great, though it's relatively new in the scheme of banking and was explicitly designed to speed up small transfers (though now up to 1M I think?). My point was that the legacy system here is comparable to other countries. And until very recently a lot of companies still used BACS because that's how their payroll was set up.

I definitely miss it in other places I've worked.

Re: Fast

#436

Post by citizenpaul »

zahlman wrote: post #182
citizenpaul wrote: post #62

Earlier quoted context omitted.

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.

I knew someone would make this comment. I almost added a "I'm probably not leet enough to avoid these situations" disclaimer. It seemed a bit pointlessly self deprecating.

You don't always get to choose the state of or the way a system you work in/with is designed. In this case I was working in a limited scripting language that I have no choice about.

Keep that nose turned up. I'm sure you are leet10xninja. Maybe work on your reading comprehension before you dump on someone though as I already specified that I greatly simplified for comment sake.

Re: Fast

#437

Post by accoil »

NobodyNada wrote: post #298
accoil wrote: post #258

Earlier quoted context omitted.

Why would shorter lines be regular? I use hn with `max-width: 60rem;`, and I get a ragged right (which I very much prefer over justification), while also getting a line length easier for my eyes to follow.

My eyes seem to navigate by paragraph more so than by line. It's hard to try to overanalyze how I read, but I think "corners" of a paragraph are landmarks that I latch onto, and when I reach the end of a line of text I don't scan back along the the line horizontally back to the left, I "jump" back, using the boundaries of the paragraph to estimate the start of the next line, and continue reading from there. This mean…

Interesting; never considered anchoring on the paragraph boundaries. I suspect you are right in that I use line shapes to navigate, as I also treat capitals as landmarks to bounce around. Once had a visual migraine where I could only detect the current line (above and below just didn't exist), and it forced my reading speed to a crawl.

Re: Fast

#438

Post by mrngm »

NobodyNada wrote: post #298
accoil wrote: post #258

Earlier quoted context omitted.

Why would shorter lines be regular? I use hn with `max-width: 60rem;`, and I get a ragged right (which I very much prefer over justification), while also getting a line length easier for my eyes to follow.

My eyes seem to navigate by paragraph more so than by line. It's hard to try to overanalyze how I read, but I think "corners" of a paragraph are landmarks that I latch onto, and when I reach the end of a line of text I don't scan back along the the line horizontally back to the left, I "jump" back, using the boundaries of the paragraph to estimate the start of the next line, and continue reading from there. This mean…

One of my pet peeves is single line paragraphs.

It's like you have to take a breath after reading one paragraph.

But the paragraph was just one sentence.

---

"Justified", I suppose, just looks nicer in smaller width columns, like in a newspaper where there might be four columns on one page. "Ragged right" prevents a 'natural' line on the right side of the column, somewhat diffusing the bounding box of the column. Nonetheless, it's interesting to see another view on reading, where the parent commenter prefers wider rather than more narrow columns. I usually lose track on a line level, rather than paragraph level, when the column is too wide.

This also reminds me of an internal diff tool that showed changes with a red (removed) and green (added) coloured backgrond. At some point a colleague pointed out that they could not see the difference between those backgrounds! An eye-opener, if you will, in terms of accessibility that requires adding other, non-coloured, elements indicating the semantic meaning of those background colours.

Re: Fast

#439

Post by mrngm »

xnx wrote: post #408
dang wrote: post #341

Earlier quoted context omitted.

What's a markdown link tag?

I'm assuming [Example link text]( https://example.org ) I don't know what use that would be for a text comment though.

If anything, it allows hiding long URIs... especially those with tracking elements that visitors here may want to exclude when clicking on it.

Re: Fast

#440

Post by caycep »

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.

is it a hand coded website in this day and age?!
Post reply on HN