Live data from Hacker News

The Worst API Ever Made?

mollyrocket.com

51–60 of 82 posts

Re: The Worst API Ever Made?

#51
post #49

Poster has not worked very deeply with Win32, is unaware of its conventions. Film at 11. For example: > Yes, that’s right, every user of the Event Tracing for Windows API has to do the arithmetic and layout of the packed structure format themselves. These represent very common idioms in Windows. One common idiom is about binary compatibility. Microsoft can change the length of the structure in a future rev of the SDK…

Ha, was my first thought as well: you could write this same article about essentially every aspect of the Win32 API.

And that article, having the same tone, would be about it being bad. But not understanding the conventions is not the same as being bad. A lot of this coding style is hard fought and battle tested.

Re: The Worst API Ever Made?

#52
post #19

"The API is simple because the problem it’s solving is trivial." I beg to differ -- as ridiculous as the API interface may be, the problem it's solving is most certainly not even close to being trivial. High-performance logging for something as low-level as the thread scheduler is not something you can write in your sleep.

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".

At Sun, whenever an engineer claimed a task or problem was "trivial", the work was assigned to him or her.

A lot fewer problems were deemed "trivial" after that.

Re: The Worst API Ever Made?

#53
post #49

Earlier quoted context omitted.

Ha, was my first thought as well: you could write this same article about essentially every aspect of the Win32 API.

And that article, having the same tone, would be about it being bad. But not understanding the conventions is not the same as being bad. A lot of this coding style is hard fought and battle tested.

No question about it. My answer would actually be a lot more about the history of both Win32 and Win16, both of which I programmed in C++ for years. Looking at something like that now and proclaiming it bad is about the same thing as deploring the Mongol invasions.

Re: The Worst API Ever Made?

#54

Poster has not worked very deeply with Win32, is unaware of its conventions. Film at 11. For example: > Yes, that’s right, every user of the Event Tracing for Windows API has to do the arithmetic and layout of the packed structure format themselves. These represent very common idioms in Windows. One common idiom is about binary compatibility. Microsoft can change the length of the structure in a future rev of the SDK…

Yes, that's frequently done in win32 land, but in this case, I'd argue the following should have been done

1) Why provide a copy of the parameter at the end of a struct?

2) How will you ever expand that struct given the fact that you put a variably-sized member at the end?

3) Why doesn't the current version of the header come with a

    char[] SessionName;
member as last member, so it's at least halfway convenient?

4) No seriously - why is it copied in at the end and not a pointer?

5) That struct doesn't even have a DWORD size member as first member, are we expecting to get coupling between some flag and "oh and expect there to be additional members after that char array"?

Even for Win32's usual badness, it's pretty bad.

Re: The Worst API Ever Made?

#55

Poster has not worked very deeply with Win32, is unaware of its conventions. Film at 11. For example: > Yes, that’s right, every user of the Event Tracing for Windows API has to do the arithmetic and layout of the packed structure format themselves. These represent very common idioms in Windows. One common idiom is about binary compatibility. Microsoft can change the length of the structure in a future rev of the SDK…

Dude worked at RAD, so I'm willing to bet he's got some experience.

In your LPSTR example, that could've been to silence compiler warnings about doing pointer arithmetic.

EDIT:

From bio:

The most significant project I’ve created to date has been The Granny Animation SDK, a complete animation pipeline system that I first shipped in 1999 and which, 15 years later, still is in active use at many top-tier game studios. "

So, uh, yeah. Maybe do some reading before spouting off on another's presumed abilities?

EDIT2:

Downvote all you want, but what code of yours has been in production for 15 years?

Re: The Worst API Ever Made?

#56
post #49

Earlier quoted context omitted.

Ha, was my first thought as well: you could write this same article about essentially every aspect of the Win32 API.

And that article, having the same tone, would be about it being bad. But not understanding the conventions is not the same as being bad. A lot of this coding style is hard fought and battle tested.

A cumbersome API is a cumbersome API, regardless of why the developers thought it should be that way. Author understood conventions, I wager, but was treating it under the lens of "If I had to design this now, the sane way, where would the mismatch be?"

The only saving grace of a lot of the MS stuff is that the MSDN docs are usually pretty good--usually.

Re: The Worst API Ever Made?

#57

"The API is simple because the problem it’s solving is trivial." I beg to differ -- as ridiculous as the API interface may be, the problem it's solving is most certainly not even close to being trivial. High-performance logging for something as low-level as the thread scheduler is not something you can write in your sleep.

I think that may be part of the author's point. The api isn't solving the underlying problem it's solving the api problem and they're different. Quite often a lot of the implementation complexity is exposed even though there's no real need as far as the api is concerned. Largely because no-one really designed the api, it followed on from the implementation. Not that I'm defending the implementation but I do have one…

Well put.

A great example of this is the OpenGL API for fixed-function stuff (say, pre 2.0).

Simple glBegin, glEnd was easy to understand, but hid a lot of complexity. As new features were added (and, woefully, old calls supported and not deprecated) the API got more complicated and harder to use without trampling internal state.

APIs (usually) should be as simple as possible for most use cases, regardless of how gnarly the implementation is.

Re: The Worst API Ever Made?

#58

I offer a simple API decision which has condemned generations of programmers to useless toil. The decision in .Net to not map database NULL to programming language null. Perhaps there was some higher level philosophical distinction being drawn which mere mortals are not capable of understanding.

> The decision in .Net to not map database NULL to programming language null.

What specific API in the .Net framework does this (or doesn't do this)? Definitely hasn't been my experience but I am using Entity Framework so...

It goes so far as to mark null-able database types as (bool?) (nullable bool) which is super helpful and you can use == null for comparisons.

Re: The Worst API Ever Made?

#59

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.

My point was that even though OpenSSL documentation is bad, enough people understand how it works that using OpenSSL may be preferable to designing a new API... unless/until you have the resources to design a better API.

Re: The Worst API Ever Made?

#60

Poster has not worked very deeply with Win32, is unaware of its conventions. Film at 11. For example: > Yes, that’s right, every user of the Event Tracing for Windows API has to do the arithmetic and layout of the packed structure format themselves. These represent very common idioms in Windows. One common idiom is about binary compatibility. Microsoft can change the length of the structure in a future rev of the SDK…

Dude worked at RAD, so I'm willing to bet he's got some experience. In your LPSTR example, that could've been to silence compiler warnings about doing pointer arithmetic. EDIT: From bio: The most significant project I’ve created to date has been The Granny Animation SDK, a complete animation pipeline system that I first shipped in 1999 and which, 15 years later, still is in active use at many top-tier game studios. "…

You don't ever need to cast from char * to char * . Period.

In 16 bit land the "L" meant something but that hasn't meant anything since long before the API he is calling existed.

Post reply on HN