5 ms·

I have more hope in projects like fuchsia, where separation of concerns is taken seriously - there are providers for "things" and on the fly configuration can g

by malkia 9y ago

I have more hope in projects like fuchsia, where separation of concerns is taken seriously - there are providers for "things" and on the fly configuration can glue several independent components to serve as one - for example instead of "Google Maps", "Bing Maps", or "Apple Maps" - you would have several map data providers (maybe some with higher data quality for specific regions), several map data viewers, several events, places, traffic, etc. providers - and you end up with one combined view of all them, e.g. not application but an user "story", as briefly explained here: https://fuchsia.googlesource.com/modular/+/master/docs/module.md https://fuchsia.googlesource.com/modular/+/master/docs/modul...

jcoffland 9y ago
Seems susceptible to dependency hell.
- geezerjay 9y ago
  Do you see any dependency hell in requesting that the OS launches a web browser or email client?
  - rootw0rm 9y ago
    Normally, yes.
barrkel 9y ago
What you describe sounds like a recipe for the lowest common denominator in features combined with a geometric increase in bugs. If it's just linking, loose coupling, it might work OK (for something like document creation or messaging) but it won't be integrated at a higher semantic level.
- 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 ago
    I 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 ago
    Only 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.
bastawhiz 9y ago
> you would have several map data providers (maybe some with higher data quality for specific regions), several map data viewers, several events, places, traffic, etc. providers - and you end up with one combined view of all them I think the doc you linked to doesn't support your idea; it sounds much more like the replacement for activities and intents in Android than what you described. The service providers have no incentive to supply data independent of a full experience (why would Bing let you show maps in your app without agreeing to a ToS? what if the map provider has different streets than the traffic provider?), the app developers have no incentive to do this (if one phone might display Bing maps and another Google in my app, how does that make my life easier?), and the user probably doesn't want this (why am I seeing grainy black and white satellite imagery in one area and high fidelity color imagery in another?). Think of the headache gluing all that data together. Every map viewer would need to support the data format for every map provider. Every traffic service would need to expose a protocol for querying traffic data on a stretch of road, and you pray that they mostly work the same and know which streets are which. You hope that every point-of-interest provider exposes the same set of fields and level of detail you need to make them useful. And that doesn't begin to touch on the intersection of rendering things well and the data needed to make that work (which streets to show at each zoom level, arrangement of points of interest, knowing which streets are important enough to show traffic for, special cases like when freeways are closed...).
- nine_k 9y ago
  There's a difference between the systems where this is difficult, and systems where this is outright impossible. On gluing things together: look at your nearest npm-based software project. It may not be very pretty, but it works in a reasonable way.
  - SahAssar 9y ago
    NPM does not make it any easier to glue stuff together, we have had packaging for decades. Just because you can pull in a package does not make it easy to work with the api in a standardized way.
endorphone 9y ago
This sounds like the dreamy infinitely versatile paper design for countless failed projects. "And our database will be one table with Int64 possible properties and Variant data for any type, and..."
- rootw0rm 9y ago
  This is the most polite way to express exactly my thoughts.
yoz-y 9y ago
Doesn’t Windows phone also work like this?
- mcny 9y ago
  *didn't It is time to give up on Windows Phone.
  - pjmlp 9y ago
    I will do it when my device dies, maybe by then Google has had the guts to force OEMs to actually push Treble updates. My WP 10 has received more updates than all my Android devices altogether.
  - yoz-y 9y ago
    I get your point but it still exists and "didn't" would imply that they have removed the feature.
tomc1985 9y ago
Will publishers ever stand for that? Or will they bitch and moan about feeling "unable to provide a satisfactory customer (read: branding) experience" while they go and reinvent the wheel (read: write their own proprietary version)?
baudehlo 9y ago
This basically sounds like OLE. Ah memories!
- tfolbrecht 9y ago
  What is OLE?
  - purerandomness 9y ago
    https://en.wikipedia.org/wiki/Object_Linking_and_Embedding https://en.wikipedia.org/wiki/Object_Linking_and_Embedding
BillinghamJ 9y ago
Are you a Java developer by any chance? Honestly that sounds disastrous. Idealistically, sure it’s a nice idea. Practically, it’d be unusable.
- pjmlp 9y ago
  If I understood him/her correctly, it looks pretty much like COM, or the component models in iOS and Android. They seem to be doing pretty well.

by malkia 9y ago

jcoffland 9y ago

Seems susceptible to dependency hell.

geezerjay 9y ago
Do you see any dependency hell in requesting that the OS launches a web browser or email client?
- rootw0rm 9y ago
  Normally, yes.

barrkel 9y ago

What you describe sounds like a recipe for the lowest common denominator in features combined with a geometric increase in bugs. If it's just linking, loose coupling, it might work OK (for something like document creation or messaging) but it won't be integrated at a higher semantic level.

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 ago
  I 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 ago
  Only 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.

bastawhiz 9y ago

> you would have several map data providers (maybe some with higher data quality for specific regions), several map data viewers, several events, places, traffic, etc. providers - and you end up with one combined view of all them I think the doc you linked to doesn't support your idea; it sounds much more like the replacement for activities and intents in Android than what you described. The service providers have no incentive to supply data independent of a full experience (why would Bing let you show maps in your app without agreeing to a ToS? what if the map provider has different streets than the traffic provider?), the app developers have no incentive to do this (if one phone might display Bing maps and another Google in my app, how does that make my life easier?), and the user probably doesn't want this (why am I seeing grainy black and white satellite imagery in one area and high fidelity color imagery in another?). Think of the headache gluing all that data together. Every map viewer would need to support the data format for every map provider. Every traffic service would need to expose a protocol for querying traffic data on a stretch of road, and you pray that they mostly work the same and know which streets are which. You hope that every point-of-interest provider exposes the same set of fields and level of detail you need to make them useful. And that doesn't begin to touch on the intersection of rendering things well and the data needed to make that work (which streets to show at each zoom level, arrangement of points of interest, knowing which streets are important enough to show traffic for, special cases like when freeways are closed...).

nine_k 9y ago
There's a difference between the systems where this is difficult, and systems where this is outright impossible. On gluing things together: look at your nearest npm-based software project. It may not be very pretty, but it works in a reasonable way.
- SahAssar 9y ago
  NPM does not make it any easier to glue stuff together, we have had packaging for decades. Just because you can pull in a package does not make it easy to work with the api in a standardized way.

endorphone 9y ago

This sounds like the dreamy infinitely versatile paper design for countless failed projects. "And our database will be one table with Int64 possible properties and Variant data for any type, and..."

rootw0rm 9y ago
This is the most polite way to express exactly my thoughts.

yoz-y 9y ago

Doesn’t Windows phone also work like this?

mcny 9y ago
*didn't It is time to give up on Windows Phone.
- pjmlp 9y ago
  I will do it when my device dies, maybe by then Google has had the guts to force OEMs to actually push Treble updates. My WP 10 has received more updates than all my Android devices altogether.
- yoz-y 9y ago
  I get your point but it still exists and "didn't" would imply that they have removed the feature.

tomc1985 9y ago

Will publishers ever stand for that? Or will they bitch and moan about feeling "unable to provide a satisfactory customer (read: branding) experience" while they go and reinvent the wheel (read: write their own proprietary version)?

baudehlo 9y ago

This basically sounds like OLE. Ah memories!

tfolbrecht 9y ago
What is OLE?
- purerandomness 9y ago
  https://en.wikipedia.org/wiki/Object_Linking_and_Embedding https://en.wikipedia.org/wiki/Object_Linking_and_Embedding

BillinghamJ 9y ago

Are you a Java developer by any chance? Honestly that sounds disastrous. Idealistically, sure it’s a nice idea. Practically, it’d be unusable.

pjmlp 9y ago
If I understood him/her correctly, it looks pretty much like COM, or the component models in iOS and Android. They seem to be doing pretty well.