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

No Abstractions: our API design principle

increase.com

Post reply on HN
Print view View original

101–110 of 141 posts

Re: No Abstractions: our API design principle

#101

Post by meekaaku »

tadfisher wrote: post #36
lolpanda wrote: post #18

for any APIs related to money, should the currency be in strings as opposed to in floats? This will prevent accidental float arithmetic in the code. I always find it tricky to work with currency in javascript.

I will be the contrarian: JSON numbers are not floating point values, they are strings of characters matching the format "-?(?:0|[1-9]\d*)(?:\.\d+)?(?:[eE][+-]?\d+)?". You can choose to parse them however you want, and parsing libraries should provide a mechanism to decode to an arbitrary-precision value.

Yes, but say in javascript if you do a JSON.parse(), it will give you a double float right?

Re: No Abstractions: our API design principle

#102

Post by lazyasciiart »

eru wrote: post #85
lmz wrote: post #61

Earlier quoted context omitted.

Isn't there the issue of modifying the state enough through the low-level API such that it breaks the assumptions of the high-level one?

Just say that you don't support mixing both APIs.

Now you’re telling users to check the source code of any tools they use with your stuff? “We recommend using ToolOne only on content you do not also manage with ToolTwo”

Re: No Abstractions: our API design principle

#103

Post by jampekka »

dumbo-octopus wrote: post #76
jampekka wrote: post #63

Earlier quoted context omitted.

This. There should be a low level API to be able to do rarer more complicated cases, and a higher level simple API for common cases built on the lower-level API. Just today I was working with the Web File System API, and e.g. just writing a string to a file requires seven function calls, most async. And this doesn't even handle errors. And has to be done in a worker, setting up of which is similar faff in itself. Sim…

It's 4 async calls, and it can be done entirely in the main thread so long as you use the async API. https://developer.mozilla.org/en-US/docs/Web/API/FileSystemW...

For OPFS it's still 6 calls. And the async API doesn't support flushing writes.

https://developer.mozilla.org/en-US/docs/Web/API/File_System...

Re: No Abstractions: our API design principle

#104

Post by mbork_pl »

paulddraper wrote: post #51
Karellen wrote: post #46

> If you’re building an abstraction-heavy API, be prepared to think hard before adding new features. If you’re building an abstraction-light API, commit to it and resist the temptation to add abstractions when it comes along. You could always do both. Provide a low-level abstraction-light API that allows fine control but requires deep expertise, and write a higher-level abstraction-rich API on top of it that maps to…

Git is an example of this. [1] There are high-level "porcelain" commands like branch and checkout. And then there are low-level "plumbing" commands like commit-tree and update-ref. [1] https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Po...

Came here to say that.

Also, to some extent, Emacs. There are thousands of functions (actually, a bit less than 10k in stock Emacs without packages, and over 46k in my Emacs) performing various low-level tasks, and much fewer commands (~3k in stock Emacs, almost 12k in my config), i.e., interactive functions, often higher-level, designed for the user.

Re: No Abstractions: our API design principle

#108

Post by f1shy »

metalspoon wrote: post #66
jampekka wrote: post #63

Earlier quoted context omitted.

This. There should be a low level API to be able to do rarer more complicated cases, and a higher level simple API for common cases built on the lower-level API. Just today I was working with the Web File System API, and e.g. just writing a string to a file requires seven function calls, most async. And this doesn't even handle errors. And has to be done in a worker, setting up of which is similar faff in itself. Sim…

Tbf Vulkan is not intended for an endprogrammer. It is a deliberately low level standardization to allow directly control GPU hardware. The high-level approach (OpenGL) failed. The endprogrammer is supposed to use a third party middleware, not Vulkan itself.

So OpenGL is a total failure! I learned something today… What should I use?

Re: No Abstractions: our API design principle

#109

Post by wizzwizz4 »

f1shy wrote: post #108
metalspoon wrote: post #66

Earlier quoted context omitted.

Tbf Vulkan is not intended for an endprogrammer. It is a deliberately low level standardization to allow directly control GPU hardware. The high-level approach (OpenGL) failed. The endprogrammer is supposed to use a third party middleware, not Vulkan itself.

So OpenGL is a total failure! I learned something today… What should I use?

I like WebGPU: it's slightly higher-level than OpenGL, but the shader language is better. (For the actual web, use WebGL: like Wasm, WebGPU isn't actually suitable for use in websites.)

Re: No Abstractions: our API design principle

#110

Post by IggleSniggle »

campbel wrote: post #60
yen223 wrote: post #57

Earlier quoted context omitted.

It does double your API surface area, so that's the tradeoff you'll have to consider. It can be the correct decision in a lot of cases.

Unlikely to double. The low level API exposes all capabilities, the high level API exposes a subset of those capabilities under a smaller surface. The high level API will not be as large as the low level.

This reminds me of the git API.
Post reply on HN