Agreed. If I'm looking at what it proposes then about 1/2 the time I don't make the changes. If this were fully automated you would need an addendum like "Only make the change if it saves over 100 lines of code or removes 3 duplicate pieces of logic".
There are other scenarios you would want to check for but you get the idea.
I don't think it's a hard rule, more of an ethos. If you know there are going to be a bunch of something, write the abstraction out of the gate. If you have three code entities with a lot of similar properties, but the app is new and you feel like there's a good chance they might diverge in the future, then leave them separate.
I think that remains to be proven. The context was 16-year olds being able to freely build things. They still can do that as before. Not everything is a competition.
We've had such models before. GPT Pro, Gemini DeepThink. Mostly targeting science advancements as opposed to security research, but still, in a way Mythos is just more of the same.
Bug bounties don't reflect the market impact of the vulnerability though, just the amount needed to incentivize white hats to do research they wouldn't otherwise (or that they would target to other platforms that pay higher bounties). You need to look at market prices for zero days on the black market to get closer.
Bug bounties reflect what companies are willing to pay to find bugs. Mythos would have to be more expensive than that (probably considerably so) to not be worth its cost. If you are saying that finding bugs has significantly more value than reflected by bug bounties, then that strengthens my point.
Conventions already existed in DOS (CUA) and MacOS. The point is, every operating system had its user interface conventions, and there was a strong move from at least the mid-1980s to roughly the mid-2000s that applications should conform to the respective OS conventions. The cross-platform aspect of the web and then of mobile destroyed that.
That’s not the only reasons. When you are used to how your operating system does things consistently, as a developer you naturally want your application to also behave like you’re used to in that environment.
This eroded on the web, because a web page was a bit of a different “boxed” environment, and completely broke down with the rise of mobile, because the desktop conventions didn’t directly translate to touch and small screens, and (this goes back to your point) the developers of mobile OSs introduced equivalent conventions only half-heartedly.
For example, long-press could have been a consistent idiom for what right-click used to be on desktop, but that wasn’t done initially and later was never consistently promoted, competing with Share menus, ellipsis menus and whatnot.
In single-text-input contexts, like search fields and the browser address field, and things like Save As dialogs. It’s the general expectation for dialogs with an OK or default button, just like Escape cancels the dialog.
That isn’t workable for chat apps, at the very least on mobile. And that’s the most-used text entry interface that users nowadays grow up with. So I think you need to make an exception for such applications.
Mobile makes this much easier actually, send can be a different button on the UI than the newline button on the touch keyboard without having to teach this to users. That's exactly how my phone is currently configured at least.
I don’t understand what difference you are seeing. On the desktop you would have a UI button as well, and likewise a key on the keyboard.
The difference I’m referring to is that Ctrl+Enter is arguably acceptable on the desktop, but has no equivalent on touch keyboards on mobile.
Regarding the UI button, the way many people chat they would consider it too much friction to have to tap a button above the keyboard for every send — more friction than Ctrl+Enter is on the desktop,
No one uses the UI button to send a message on the desktop though. Everyone just presses Return to send, which is the most common need, and then once in a while realise they need to enter a newline without sending, for which there isn't a button so they need to learn how.
Mobile doesn't necessarily have this issue because it can show the send button and the newline button at the same time and they're equally accessible.
Regarding your edit:
> they would consider it too much friction to have to tap a button above the keyboard for every send
My finger travels almost the same distance from the home row to hit the send button above the upper right corner of the keyboard as the newline button on the lower right. I've been doing this for ages.
Actually, I do. Or at least I do in very similar situations where for some reason there is no keyboard shortcut to submit from the input field, so I press Tab (which moves the keyboard focus to the submit button next to the text field) and then press Return or Space to press the UI button.
Regarding on mobile, I’m familiar with chat apps that require a UI button press to send, and consider it unnecessary friction. It’s a larger mental leap to have to leave the keyboard.
> It’s a larger mental leap to have to leave the keyboard.
I find this interesting! I've never considered myself "leaving the keyboard" on the phone as if I were task switching. When I'm done typing I flow directly to the send button and let the keyboard go. The fact that the button is above the keyboard makes no difference to me as long as it stays accessible.
reply