Live data from Hacker News

The unbearable frustration of figuring out APIs

blog.ar-ms.me

31–40 of 60 posts

Re: The unbearable frustration of figuring out APIs

#31
My favourite approach to documentation is the "4 kinds of documentation" - whether it's about an API, a library or anything else. I think it's a very clean way of explaining "good/poor" documentation.

In a nutshell, which type of documentation we need depends on the goal we have. Any API missing one of the kinds of documentation will feel like it is missing something. Once I read about it, I've been noticing how the documentation I like tends to have all these aspects covered.

https://www.writethedocs.org/videos/eu/2017/the-four-kinds-o...

Re: The unbearable frustration of figuring out APIs

#32

I must be missing something here. Why would anyone want to use Apple's god awful translation models? Is it perhaps better at translating individual words? Anytime I've used it for article translation it has been unequivocally terrible.

Did you use it recently? I used it to translate a Chinese website to English and was surprised to see everything made sense. Even the texts on the images were translated (in Safari).

Re: The unbearable frustration of figuring out APIs

#33
post #17

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…

This is a story about the risks of AI-induced brainrot. You get so used to having the computer just do your work, that the second you need to engage your noggin you’re lost at sea. Or at least just frustrated. 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

I remember reading and hearing similar rants from programmers 15 years ago, long before LLMs. The author kept going and figured it out, and probably got some pride and enjoyment from finishing the project in spite of the frustrating moments. That’s what learning to code has always been like.

Re: The unbearable frustration of figuring out APIs

#35
Tangentially related, I did a project (forked, but fully rewrote) to be able to avoid the Package.swift file for single file projects like these. [1]

The general idea is a bit like uv if I have understood uv correctly. Basically you do your imports normally and add a comment next to them that tells where the imports should be found. Then instead of running your project through swift directly you run it through swift-sh (or `swift sh`, swift will find the `swift-sh` binary automatically, just like git does for plugins). swift-sh will download and compile the dependencies, then add the proper options to swift so it will know where to find them.

It is even possible to add a regular shebang to swift-sh at the beginning of the file, chmod +x it, and just run it like a regular script!

Or use swift-sh to compile it.

(And installing swift-sh itself is as easy as `brew install xcode-actions/tap/swift-sh`.)

[1] https://github.com/xcode-actions/swift-sh

Re: The unbearable frustration of figuring out APIs

#36
post #20

Way, way back in 2003 or thereabouts, I had to add an "open this report in Excel" function to an existing product. But first I had to figure out how to convert the report to Excel format (with freeze panes, etc.). I found Apache POI and was very happy with its API documentation, especially this "Busy Developers' Guide to Features": https://poi.apache.org/components/spreadsheet/quick-guide.ht... This page was much sim…

Every library I have ever considered using and almost all of the ones that I onboarded have a "Quickstart" section. eg Guava, Guice,

Re: The unbearable frustration of figuring out APIs

#37
post #3

This is strangest read I had in a while. It is like saying that operating a submarine is very counter intuitive, I know how to operate an airliner, both are vehicles.

It was my first taste of Swift, and has destroyed any lingering curiosity I had about it.

As a Swift dev, I have to say this was a frustrating read.

Apple’s documentation is often very poor, and I will note that Swift Packages (especially CLIs) doesn’t always feel great. As another commenter noted, anything other than Xcode feels like fighting an uphill battle.

But many of your frustrations could be solved by checking not API docs, but just the Swift language guide. You seem perturbed, for example, that the Package initializer expects ordered arguments. It is a basic part of Swift’s design that arguments are always ordered and exclusively are either named or unnamed (never optionally both).

The ghost’s use of semaphores with async/await is a massive red flag in terms of mixing two asynchronous frameworks (Concurrency and GCD). I’d not be surprised if it worked, but that’s really against the grain in terms of how either framework were designed. This is the shortfall of relying on bottled ghosts to learn new tools. I know from experience that the documentation on Concurrency (async/await) is pretty good, and lays out a clear rationale for how it’s intended to be used, but that is a huge piece of documentation and it’s a big hill to climb when all you’re building is a small tool. This is the risk we run when asking AI for help when it itself is ignorant of the actual intended use of the apis and is only trained on the output of developers. Here it’s easy to see that it was faced with a problem of synchronous access to an async function and reached for a common solution (semaphore), despite the fact that semaphores are part of a 10 year old framework, and the async/await keywords are only 2-3 years old!

Anyway, the article reminded me of the challenges of learning a new (programming) language. There’s more to it than just following tutorials and blindly directing AI. I know the feeling, having to currently learn c# at the moment. I can write simple functions and follow the syntax, but I can’t intuitively understand what’s happening like I can with Swift. Is that because Swift is better than C#? Not really- it’s just that I’m fluent in one but not the other. Ironically I guess you probably get this already from learning Mandarin, but you’ve not written an article about how frustrating it is that it inexplicably insists on using tones to express meaning, when English is fine without it(!).

I’m sorry you had a bad experience with Swift. I do genuinely think it’s a great language to write, and the open source Swift Evolution team are great. They are continually pushing for more openness and more cross platform compatibility, and I do like the way that the core of the language is strongly opinionated in a way that makes it clear what’s happening if you do understand the syntax. What’s hard is then the application of Apple’s APIs which are wildly inconsistent and often incomplete. Some are maintained while others are still wrappers for 15 year old objective C that have no concept of modern Swift paradigms. That said, I’d still encourage you to persevere with Swift. Once you get past those rough edges of stdio and UI and get into the heart of a Package, I would expect most of these complaints to disappear!

Re: The unbearable frustration of figuring out APIs

#38
post #34

I don't understand why people who think like this get (or want to get) jobs as software developers It's clearly not enjoyable for them so why doesn't the author pivot to something else and stop doing things they hate? It's weird

Me neither, but it does explain why AI is so popular…

Re: The unbearable frustration of figuring out APIs

#40

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…

Disagree here. APIs are meant for using and not learning. But the context matters here. For some paid system, there better be an API thats easy to use or I am throwing AI at the problem or hoping someone else will do it. If its something worth learning - say Guava data structures or RocksDb core - yup I'll invest the time to learn. That learning transfers over. But trying to learn some shitty AWS api and its nuances, no thanks. Some payment system that a handful of people use - no thanks again.
Post reply on HN