11–20 of 60 posts
In all honesty this is how a typical developer experience has been for a long time in a number of systems. Expecting someone to pre-chew your programming food is silly.
> Why was that so hard? Why are the models here separate from the ones in the right click menu? Too many questions.
The very screenshot above this paragraph actually answers this, in what admittedly might be an uncharacteristically clear UI: "Siri and Safari will always run translations online."
For me the worst APIs by far are on Android. They are even worse than win32.
Nope, Google AI APIs are second to none. That shit will make you question whether their services are worth it. Edit: Come to think of it, both are made by Google :')
API design isn't just about functionality. it is about discoverability and if your right-click menu uses different models than your API and your error messages don't explain why, you are just creating friction for no reason.
Sometimes the "proper" solution isn't worth the super complicated maze.
For me the worst APIs by far are on Android. They are even worse than win32.
All of this is written with a sense of anger and sarcastic invective that doesn't seem appropriate. This is part of learning any new language or API. Going in with an attitude of "I should already know how all this works, why am I forced to do research or look at docs?" seems unfair and will spoil the experience of learning anything. > Why was that so hard? Why are the models here separate from the ones in the right…
Reading and understanding the docs and reference material has always been part of the work.
Aside from the commentary it read like an advertisement for how great the swift/macos translation APIs are. PEBCAK
All of this is written with a sense of anger and sarcastic invective that doesn't seem appropriate. This is part of learning any new language or API. Going in with an attitude of "I should already know how all this works, why am I forced to do research or look at docs?" seems unfair and will spoil the experience of learning anything. > Why was that so hard? Why are the models here separate from the ones in the right…
Like, how can it run a command that has an `async` main despite the fact that you didn't extend the async version of command?? That should've been an error (e.g. "bro, you cannot have an async main in this class, you need the Async version of this class which is called AsyncWhatever").
Not awaiting on an async function should be at least a warning. Another frustrating lack of feedback: it just lets you run it and nothing happens.
The version thing: it should show all possible variants in the enum, even the ones you should not be able to use, and then when you try using it, show an error saying "you need to change the version of this file to at least blah to use this". Why can't the Swift LSP do that? Apple has a trillion dollars, they can afford polishing their stuff.
The author is used to Rust, which would've made it very clear what was wrong in all cases.
Swift, being as modern as Rust, should be doing better than that. Languages that fail to give you proper error messages and warnings are just not worth it: just one of these "wtf is going on?" moments can cost you hours. Just use a better language if you can.
This page was much simpler 22 years ago (I don't remember this HSSF stuff, whatever that is), but it still looks familiar. Basically everything I needed to do had examples in there. I remember thinking that the authors cared about the users of the library (although the Javadoc seems a little bare.. but I am not sure I needed the Javadoc much).
If I ever create an OSS library, I would certainly also create a "Busy Developers' Guide".