Curious of the most functional, enjoyable API's you've encountered on projects and why it was chock full of awesome, whether that was ease of use, sensible design, integration of other services, etc.
LINQ by Microsoft. It's expressive, elegant and very useful when dealing with all types of data. In addition, it pushed many OO programmers closer to functional languages.
> "...the design of LINQ query comprehensions was heavily influenced by the design of Haskell. Haskell expert Erik Meijer was on the C# language design committee when we designed LINQ; his insights were very valuable".
Twas down today for brief while, but Stripe API usually is rock-solid
I'd also check out a new trend in APIs that is sort of "visual editors for non-coders". Slack's Block Builder is a terrific example
Google Guava, Java Collections.
Most Java OSS library feels a lot better than NodeJS (been in JS land for more than 5 years and I can count "historically" stable JS library using my left hand)
That's very odd, since I moved from Java to NodeJS and felt the opposite. Especially, building and modifying API in NodeJS is just JSON.parse/stringify, while in Java you need a PhD in DAO.
> Especially, building and modifying API in NodeJS is just JSON.parse/stringify, while in Java you need a PhD in DAO.
First of all, I'm talking about OSS library as API not REST endpoint so I believe your statement is totally unrelated to my point.
Second, you don't need a PhD in DAO, it's just one simple pattern.
Third, you have a few options: have your JPA entity converted to JAXB-annotated java-class using Dozer (if it's a straight up mapping, you don't need XML). Or annotate your model with JPA and JAXB. Again, this is only if you use JPA which is heavily geared toward RDBMS. If you followed NodeJS "pattern" which implies the only arsenal is MongoDB... then it's a different story. Most projects that use MongoDB has simple(ish) data structure so you probably don't need to deal with DAO and whatnot.
Fourth, I can understand your statement coming from NodeJS since NodeJS doesn't even have a good ORM that can managed different DB providers. Specific vs Battle-hardened for years => design trade-offs. Heck, NodeJS forces you to choose a specific DB drivers...
the older i get, the more i appreciate java.
The most awesome was SAL, a vector math library by Mercury Systems.
Every function came in multiple varieties, specialized for the expected and desired cache hotness of the data. Suppose you wanted to multiply a couple matrices. There are two inputs and an output. The inputs could be cached, uncached, or one of each. The output might be needed soon, and thus should remain in cache, or it might be better to save the cache for other things. All of this could be specified.
That library could help a programmer to produce mighty fast programs.
Thank you based Mapbox Unity team.
When I saw this I actually laughed. But then I thought about it more. I’m actually inclined to agree with you, for a native API it is quite extensive, well documented, and fairly easy to use. I prefer its verbosity to Unix-style 6-character-long syscalls, though I can see why it made sense at the time it was developed. But it could just Stockholm syndrome after 5 years of use.
It's reliably stable. With a current Mac, running an app that was built 10+ years ago would be a nightmare if not impossible without source. With Windows, I can still run apps from the late 90's with little effort (with the exception of some DirectDraw issues).
I'm not really familiar with it, but I do know it went through a lot of revisions in the beginning when just about everything that could be exploited was.
So I would imagine it would be a time (battle?) tested, mature api.
stb_image.h - I've used plenty of image APIs and libraries in my time, and none have had the simplicity of just "load this" and just worked as I expected with (practically) no setup.
Scala collections API