11 ms·
> lowest common denominator on feautures That's pretty much standard behavior in the mobile world. Services and activities are made available and the app petit
by geezerjay 9y ago
> lowest common denominator on feautures
That's pretty much standard behavior in the mobile world. Services and activities are made available and the app petitions the OS to access those "lowest common denominator features".
Although you've decided to reffer to it in disdain, it's also a very basic principle in software design.
>geometric increase in bugs
Only if you believe that developing and maintaining specialized programs somehow increases the bug count "geometrically".
- blowski 9y agoI understand the OP’s ‘lowest common denominator’ comment to mean all good but unique features can’t be included in the abstraction. For example, only Google has Streetview or anything like it, so you can’t abstract it. As a result, you end up not using the abstraction for the most part.
- barrkel 9y agoOnly if you believe that developing and maintaining specialized programs somehow increases the bug count "geometrically". I think if a program developed with one version of n components might have x bugs, a program with two versions of n components may have (n^2)x bugs; that is, for every new version of any given component you add to the system, you multiply the number of possible configurations of the program. Again, if it's all loose coupling, it'll work (but won't be very interesting). But if you have lots of random calendars, different mapping components, different messaging subsystems - it all becomes much, much more complex. Abstractions leak, break down. They have different ordering semantics, different performance, different failure modes, different concurrency support; there's no end to the number of problems introduced by trying to be flexible about what dependencies you plug in.