So wouldn’t the fees be proportional to the price? The added taxes on a tiny cheap holiday home would be cheap too.

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.

Doesn’t that also mean that ONE malicious person can get traffic off their local street or hurt a competitor’s business?

Just like moderating Lemmy, effectively policing user-generated content is a huge challenge.

I don’t think we know that yet, and I think the discovery will be interesting.

How many reports were there? Were they credible? What other sources of truth did Google consult in deciding to ignore those reports?

Google gets lots of reports and needs to filter out spam, and especially malicious reports like trying to mark a competitor’s business as closed, or trying to get less traffic in your neighborhood for selfish reasons. It wouldn’t be reasonable for Google to accept every user suggestion either.

So if Google reached out to the town and the town said the bridge is fine, then it’s not Google’s fault. If they ignored multiple credible complaints because the area was too rural to care about, that might be negligent.

I agree with you, but politics is complicated. If she felt like continuing to fight for nuclear at that time would be unpopular, it might not have been worth it. It probably would have made it impossible to achieve other goals.

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.

I’d create a GitHub issue and discuss it with the developers first. As long as users can opt out it might be reasonable.

But having a lot of people use the extension in the meantime would prove the demand.

Who would it simplify things for?

Not for the developer. For developers, compiling in advance would just slow them down and remove a lot of the cool things you can do with Java today like hot-swapping and reflection.

Not for the user. The current system is totally transparent to the user.

You’re proposing making things simpler for the Android OS, but worse for the developer. That’s the exact opposite of what they want. A lot of Android is quite complex in ways that make things easier for developers, on purpose.

I think the main issue is who it’d be simpler for. Let’s say that they switched to AOT compiling. That enables them to “simplify” the way Android works internally.

Who does that actually make things simpler for?

Literally ONE subteam of the Android team at Google. Nobody else.

It wouldn’t make things any simpler for developers. In fact, it’d make things worse because AOT compilation is slower and doesn’t allow things like hot-swapping code while your app is running - something you can do now with Java.

It wouldn’t make things any simpler for OEMs. They don’t have to worry about the Java runtime at all, they just worry about drivers.

It wouldn’t make things any simpler for the other 99% of the Android team that builds new APIs, new drivers, etc.

Basically you’re proposing a radical change that would make the platform worse for almost everyone, just so that one pretty small team at Google that builds the Java runtime portion of Android could make it a little simpler???

You say the current system seems “too complicated”. I agree it’s complex, but for a reason. Actually just about everything in tech is complex if you peek behind the curtain and learn how it works inside. The only difference here is that the code is open so anyone can see how it works. But for the most part these are just hidden details.

I guarantee that if you looked into how video frame compositing on Android works, or how low-latency audio works, or any of a hundred other things, you’d realize they’re incredibly complex too - probably “too complicated” at first. But that complexity is for a reason.

First of all, since the very early days Android has always allowed apps to make use of native code using the “NDK”, and in fact most games and most apps that do any sort of AI, image processing, or anything else complex like that make heavy use of native code already, for performance reasons.

Keep in mind that the decision to base Android apps around Java was made back in 2003 when Android was founded. Some of the reasons they picked Java were:

• It’s one of the most widely known languages by developers
• It’s hard to write code in languages like C and C++ without introducing memory bugs and security bugs. Using a higher-level language makes those bugs far less common.
• It’s portable - you note that Android only supports arm64 now, but at the time it was arm32, and Android has actually always had some level of support for x86 - you can run the emulator for x86, and some x86 Android devices exist. Using a bytecode language means Android is future-proof
• It’s not limited to just Java - the JVM has a rich ecosystem of languages that developers can use

Now 20 years later I think it’s worked out pretty well. It’s hard to imagine picking a different language would have worked out better. Java is still just as popular as ever, and Android developers can take advantage of all of the Java tools from any other platform or application.

Apple’s original option for iOS apps was just Objective-C, which is higher-performance, but overall it’s a more obscure, difficult to use language. Developers adopted it despite Obj-C, not because of it. Apple had to invent Swift to provide a more modern alternative, because Obj-C is basically not used anywhere else and it felt very ancient. While Swift is a pretty great language, it’s still somewhat obscure, only used for iOS and Mac apps - while Java and JVM languages are used everywhere.

Anyway, let’s say that Android really did want to switch, for some reason. I’m not sure why you think switching to compiled code would be less complex. How would all of the millions of existing Android apps migrate? What native languages would be supported? It’d be a huge transition for dubious benefits.

As it is, Android is extremely flexible. While the official APIs require a JVM language, because of the NDK you can basically write Android apps in whatever language you want. People have built frameworks enabling you to build Android apps in nearly every language under the sun.

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 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.