Can you elaborate on what happened when you tried to search? I’ve never had trouble.

I’m talking about using the ChatGPT API to make a chat bot. Even when the user’s input is just one sentence, it can cause ChatGPT to forget its prompt.

Is it possible to be a productive programmer with slow typing speed? Yes. I have met some.

But…can fast typing speed be an advantage for most people? Yes!

Like you said, once you come up with an idea it can be a huge advantage to be able to type out that idea quickly to try it out before your mind wanders.

But also, I use typing for so many others things: writing Slack messages and emails. Writing responses to bug tickets. Writing new tickets. Documentation. Search queries.

The faster I type, the faster I can do those things. Also, the more I’m incentivized to do it. It’s no big deal to file a big report for something I discovered along the way because I can type it up in 30 seconds. Someone else who’s slow at typing might not bother because it’d take too long.

GPT-3.5 seems to have a problem of recency bias. With long enough input it can forget its prompt or be convinced by new arguments.

GPT-4 is not immune though better.

I’ve had some luck with a post-prompt. Put the user’s input, then follow up with a final sentence reminding the model of the prompt and desired output format.

OK, let’s say you’ve got a bunch of regexes in a source repository that need to get modified frequently. It can be difficult to code-review complex regexes, and even harder to code-review changes to an existing regex.

Something like this might actually help. A change to a complex regex might actually produce a more clear diff of a subset of lines.

Also, I think being able to comment in the middle of a regex would be super handy for that type of code.

This should be required reading for anyone who thinks that frontend is easy.

Also, if anyone thinks this is a limitation of the web, I’d challenge you to try to create an app that displays 18,000 lines of syntax-highlighted, findable text using another popular toolkit like .NET, Qt, or Cocoa. They’ll all get bogged down if you try to naively put all of that content in a single view and expect built-in scrolling and find features to just work, quickly. Pretty much the only way to make something like that work involves a lot of tricks behind the scenes, no matter what platform.

I’m really happy they landed on a solution that not only delivers high performance, but supports the browser’s native Find function and accessibility. I think some people could have anticipated those problems, but far more important is that they listened to user feedback and pivoted when their first idea didn’t make users happy.

I said “one of” the most popular.

I also feel like it’s not accurate anymore.

Java doesn’t run on iOS. Period. In fact it’s almost impossible to build an iOS app using Java - the only ways to do it are essentially to transpile Java to some other language, so Java isn’t running on iOS at all.

iOS is one of the most popular operating system in the world by any measure. It supports a lot of languages.

But not Java.

I think it was badly designed in that it assumed we’d ditch IPv4 for IPv6. That was an absurdly unrealistic expectation.

Forget all of the rest of the issues. From day one they should have come up with a robust, performant system for bridging between IPv4 and IPv6 addresses. Make it so that EVERY IPv4 address is a valid IPv6 address, and provide a simple, robust way to tunnel traffic aimed at an IPv6 address through an IPv4 network.

That totally would have been possible. Then everyone could have switched to IPv6 with no downside, and switching out middle layers of the system would have been great, welcome optimizations.

As opposed to the reality today, where IPv4 is basically never going to go away, because the long tail of cheap devices and older networks have no incentive to switch.