Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Worst API Ever Made?

mollyrocket.com

Post reply on HN
Print view View original

31–40 of 82 posts

Re: The Worst API Ever Made?

#31

Post by wfunction »

to3m wrote: post #30
balloot wrote: post #19

Earlier quoted context omitted.

When an engineer uses the word "trivial," what you should hear is "There are some complications that I'd rather ignore, so let's just hand-wave the answer".

What are these complications? The API's job appears to be to let you iterate through a list of log items/read data from a log buffer/however you want to imagine it. That sort of thing is not rocket science, no matter how difficult it was to make that data in the first place. (Besides, even if you don't think there's anything wrong with the way it provides the caller with data from the list, there's always the session…

> That sort of thing is not rocket science

Uh, for starters, the buffer doesn't have infinite size. It will overflow. What is the system supposed to do here? There are a million possibilities (discard old data, discard new data, allocate more memory, write to a file, call a callback, return an error, stall the rest of the system or halt the clock, etc.); some make sense, some don't. Between those that do, the user needs to be able to choose the best option -- and the time-sensitive nature of the log means you can't just do whatever pleases you; you have to make sure you don't deadlock the system. That's not by any means a trivial task, and I'd bet the reason you think it's so easy is that you haven't actually tried it.

Re: The Worst API Ever Made?

#33

Post by __david__ »

wfunction wrote: post #31
to3m wrote: post #30

Earlier quoted context omitted.

What are these complications? The API's job appears to be to let you iterate through a list of log items/read data from a log buffer/however you want to imagine it. That sort of thing is not rocket science, no matter how difficult it was to make that data in the first place. (Besides, even if you don't think there's anything wrong with the way it provides the caller with data from the list, there's always the session…

> That sort of thing is not rocket science Uh, for starters, the buffer doesn't have infinite size. It will overflow. What is the system supposed to do here? There are a million possibilities (discard old data, discard new data, allocate more memory, write to a file, call a callback, return an error, stall the rest of the system or halt the clock, etc.); some make sense, some don't. Between those that do, the user ne…

> What is the system supposed to do here? There are a million possibilities…

No, there are two: You dump old data or you dump new data. Everything else should be up to the user code. It's really not as difficult as you are making it out to be. There's certainly no excuse for a ridiculous API as described in the article.

Re: The Worst API Ever Made?

#34

Post by lafar6502 »

zyb09 wrote: post #10
kabdib wrote: post #4

Earlier quoted context omitted.

Well, the API in question (which I've used, and it was indeed an unpleasant experience) might not be solving something trivial , but it's certainly not well designed. My all-time worse API is SetupAPI, which despite its name is how you get access to USB devices on Windows. It's . . . pretty miserable. Runner-up is the COM-based stuff that manages the Windows firewall, which is not well specified and has 'interesting'…

My award goes to Extended MAPI. It took me weeks of trial and error just to read and send email messages through an Exchange Server. I remember people were selling 3rd party wrappers for the API, because it was so horrible.

Yeah, MAPI certainly deserved a mention

Re: The Worst API Ever Made?

#35

Post by wfunction »

__david__ wrote: post #33
wfunction wrote: post #31

Earlier quoted context omitted.

> That sort of thing is not rocket science Uh, for starters, the buffer doesn't have infinite size. It will overflow. What is the system supposed to do here? There are a million possibilities (discard old data, discard new data, allocate more memory, write to a file, call a callback, return an error, stall the rest of the system or halt the clock, etc.); some make sense, some don't. Between those that do, the user ne…

> What is the system supposed to do here? There are a million possibilities… No, there are two: You dump old data or you dump new data. Everything else should be up to the user code. It's really not as difficult as you are making it out to be. There's certainly no excuse for a ridiculous API as described in the article.

Huh? If you dump data you miss events. Imagine if Process Monitor decided to suddenly dump half of the system calls it monitored. Wouldn't that be ridiculous? For a general event-tracing system, there have to be more options provided. Maybe it wouldn't matter so much for context-switching per se, but for a ton of other types of events you really need to track each and every event.

Re: The Worst API Ever Made?

#36

Post by kibibu »

wfunction wrote: post #28
klodolph wrote: post #22

Earlier quoted context omitted.

I think it has to be the sheer number of APIs that Microsoft has developed: they just don't have the resources to care about very many of them. It stems from Microsoft's extremely insular culture in the 1990s and 2000s, where being a "Microsoft developer" meant that you just didn't read code for open-source projects, didn't look at competing APIs, just did everything your own way. Apple had its own bad APIs, and blew…

> OpenSSL [...has...] documentation Did you really praise OpenSSL for its documentation? Honestly, until now I thought it was the de facto example of poor documentation.

> well understood problems, with source code and documentation

Perhaps the comma should be removed.

Re: The Worst API Ever Made?

#37

Post by vl »

wfunction wrote: post #28
klodolph wrote: post #22

Earlier quoted context omitted.

I think it has to be the sheer number of APIs that Microsoft has developed: they just don't have the resources to care about very many of them. It stems from Microsoft's extremely insular culture in the 1990s and 2000s, where being a "Microsoft developer" meant that you just didn't read code for open-source projects, didn't look at competing APIs, just did everything your own way. Apple had its own bad APIs, and blew…

> OpenSSL [...has...] documentation Did you really praise OpenSSL for its documentation? Honestly, until now I thought it was the de facto example of poor documentation.

While OpenSSL has bad documentation - there are both source code and real-world usage examples (from open source products using it) to help.

Re: The Worst API Ever Made?

#38

Post by to3m »

wfunction wrote: post #31
to3m wrote: post #30

Earlier quoted context omitted.

What are these complications? The API's job appears to be to let you iterate through a list of log items/read data from a log buffer/however you want to imagine it. That sort of thing is not rocket science, no matter how difficult it was to make that data in the first place. (Besides, even if you don't think there's anything wrong with the way it provides the caller with data from the list, there's always the session…

> That sort of thing is not rocket science Uh, for starters, the buffer doesn't have infinite size. It will overflow. What is the system supposed to do here? There are a million possibilities (discard old data, discard new data, allocate more memory, write to a file, call a callback, return an error, stall the rest of the system or halt the clock, etc.); some make sense, some don't. Between those that do, the user ne…

Yes, that's reasonable. But I'm not sure how this doesn't just boil down to configuring how the list is built up. You'd still be iterating through the list afterwards.

The system's hands are somewhat tied, I think. The events are building up in kernel mode, so it can't just switch to the callback for each one, not least because the callback might be executing already (possibly it was even the callback that caused whatever new event has been produced). So all it can do, when an event occurs, is add the event to a buffer - handling overflow (etc.) according to the options the caller set - though I don't think a callback is practical as this would involve switching back to user mode - for later consumption by user mode code. In short, it's building up a list, and perhaps the API could reflect that.

This is not to suggest that it would be easy to get to there from here. I've no doubt it could be literally impossible to retrofit an alternative API without rewriting everything. Just that I don't see why in principle an event tracing API can't work in some more straightforward fashion.

Re: The Worst API Ever Made?

#39

Post by pcunite »

zyb09 wrote: post #10
kabdib wrote: post #4

Earlier quoted context omitted.

Well, the API in question (which I've used, and it was indeed an unpleasant experience) might not be solving something trivial , but it's certainly not well designed. My all-time worse API is SetupAPI, which despite its name is how you get access to USB devices on Windows. It's . . . pretty miserable. Runner-up is the COM-based stuff that manages the Windows firewall, which is not well specified and has 'interesting'…

My award goes to Extended MAPI. It took me weeks of trial and error just to read and send email messages through an Exchange Server. I remember people were selling 3rd party wrappers for the API, because it was so horrible.

I used the Extended MAPI API for years ... I thought there was something wrong with me as I struggled through the insanity ... until I saw modern APIs.

Re: The Worst API Ever Made?

#40

Post by perlgeek »

Another "fun" API is the one from MUMPS (matrix processing stuff) in Fortran.

See http://mumps.enseeiht.fr/doc/userguide_4.10.0.pdf , for example page 10.

It has lot of numbered "ICNTL" (input control) variables as well as named struct fields, and some of those struct fields are only valid if, for example ICNTL(26) has the values 0, 1 or 2.

ICNTL is actually an array with 40 elements, though "only" 1-33 are currently in use. And then there's CNTL (float control parameters), INFOG, RINFOG and what not.

Also, the number of calls you must do to the actual processing function depends on some combination of those magic variables.

Needless to say that there are no named constants for all those magic variables, because the code must be backwards compatiable with Fortran 77, where the behavior of code with identifiers longer than 8 characters is undefined, and differs from compiler to compiler (some truncate, some allow them, some error out). So names are actually in short supply.

Post reply on HN