3 ms·
> we as computer scientists and programmers really don't (yet) have a good handle on what the "right" abstractions for big/monster data problems It's more that
by frisco 15y ago
> we as computer scientists and programmers really don't (yet) have a good handle on what the "right" abstractions for big/monster data problems
It's more that the underlying technologies aren't good enough to support these abstractions, so they end up breaking down as we need to debug things.
- carterschonwald 15y agoIf an abstraction breaks, its not a good abstraction, in which case the Prismatic folks are doing precisely what you're advocating anyways, spending time getting things working rather than overengineering before they need to solve the problem. My point though, is if an abstraction breaks, its not a good/real abstraction, and a new abstraction / solution needs to come into play. There is no reason why a data store library can't be parameterized (whether internally, or visible to the client user) over the semantics of the various backends and work differently in the underlying manipulations accordingly. (note I am not saying that the prismatic folks are or are not doing this, just that an abstraction is only a good abstraction if you can't break it) I agree that the underlying technologies do not have a uniform data store semantics. However, not preclude client side library logic that can provide a uniform semantics to these stores, and/or warning when they cannot.