Hacker News Reader

Comment by 16890c | Hacker News Reader

So what software actually uses this / what compiler supports this if it's neither supported nor documented by Apple?

Applications use it via a higher level interface: Apple's Accelerate framework[1]

1: https://developer.apple.com/accelerate/

Speaking of which, is anyone aware of example code using the LSTM? I've been trying to get this to work, but there seems to be information missing e.g how to setup the input/output descriptors and how to manage input data: https://developer.apple.com/documentation/accelerate/bnns/us...

It’s just like with private APIs. It’s functionality that they don’t know (¿yet?) whether they want to support it in the future, but they do provide calls that use them indirectly.

There also could be bugs in the hardware that they carefully programmed around.

Why do people act as if “private APIs” (which is somewhat of a contradiction in terms) is nefarious? An API is something that is publicly documented that the vendor promises to support where the behavior won’t change.

Raymond Chen has been blogging for close two decades about all of the hacks that MS had to put into Windows because vendors used undocumented APIs.

I agree that people tend to get a bit too worked up about it, but I don’t think it’s a contradiction in terms as such - an API is really just any interface where two distinct pieces of software interact in some way. It doesn’t need to be formally described or published or anything like that, and the idea of a private API is pretty common generally.

Where it starts to piss people off though is where those private APIs are used to allow first-party software access to platform features that third-party software doesn’t get. For some applications that’s not so bad, but in the case of a general-purpose operating system platform or similar it’s kind of an anticompetitive move and we should complain when companies do it.

Once you make an API public, no matter how badly designed it is, you have to support it forever.

I would much rather an API be private, let the company dog food it and let their internal employees use it, and then make it public. It also gives them the freedom of completely changing the internal workings.

The extensions API and the Siri integration for third parties are great examples. The Siri intent based API is very usable and reminds of the Amazon Lex based API - the AWS version of the consumer Alexa skills SDK.

>Once you make an API public, no matter how badly designed it is, you have to support it forever

That's simply not true.

There are two ways of dealing with apps using private APIs though: Microsoft indeed goes out of its way to maintain backwards compatibility, sometimes at the expense of sanity, but Apple breaks stuff — this API is private for a reason, you had to reverse engineer how to call it, and you knew your risks when you decided to use it, so if your app breaks, you get to keep both pieces.

Yes, and I suspect this is informed by Apple historically having APIs that were much more open and prone to what we would know call abuse by developers — but was then just cleverly taking advantage of the environment — during the Apple II/early Mac era.

Here are the docs: https://developer.apple.com/documentation/accelerate

Presumably first party software that qualifies. I’m thinking siri, or their AR stuff. It’s possible it’s also used by something like CoreML where there is a public facing framework that utilizes this under the hood.

I have no special info, these are just guesses.

Reply on news.ycombinator.com