8 ms·

I agree with you, but I do not believe in Google. Google provided worst commercial platform I ever had experience developing for. I had a lot of different platf

by Svoka 8y ago

I agree with you, but I do not believe in Google. Google provided worst commercial platform I ever had experience developing for. I had a lot of different platforms in my past - pretty much all consoles, desktop and fringe, like smart TVs or various smartphones released since 99'. Only Google changes rules of the game on developer. They do not realize that they are make •a platform•, not a product. Stable, comfortable platform that software runs on. I honestly don't give two cents about all their struggles to make "a better OS". OS is to launch apps, and making those apps is a miserable experience, where I have full time people just to keep up with Google 'improvements'. Somehow every other platform is fine. I hardly had to change code written 10 years ago for iOS, for consoles or Windows - not at all! But Google keeps making their own special PhD driven darlings.

hortense 8y ago
It will increase stability in a very important way because they apparently want stability of drivers, which Linux does not offer.
- yc12340 8y ago
  > they apparently want stability of drivers Strangely, the only Android drivers, that can be trivially ported between Android version, are those "unstable" bits in Linux kernel. Take any postmarket smartphone firmware — if something does not work after porting to new Android version, you can bet, that it is a proprietary userspace blob. Who develops HAL for those blobs? — Google. Who controls it's API? — Google. What "stability of drivers" are we talking about here? Certainly not the kind, helpful to users.
  - ebg13 8y ago
    > Strangely, the only Android drivers, that can be trivially ported between Android version, are those "unstable" bits in Linux kernel. That's only because the Linux kernel is actively hostile to the idea of maintaining a stable driver interface. Windows 7 drivers from 10 years ago still work in Windows 10.
- imtringued 8y ago
  ARM and the SoC Vendors don't like open sourcing their drivers. They prefer to just dump binary blobs and stop support after 2 years. The users couldn't care less because they buy a new phone anyway. (except me)
  - phkahler 8y ago
    If the OS and APIs were stable, nobody would ever need to update a driver unless they wanted a bug fix.
    - ufo 8y ago
      Even Windows has a hard time keeping their OS APIs stable. Drivers written for Vista didn't necessarily work on Windows 7 and so on. This is one of the reasons why Linux highly encourages open sourcing the things so that the driver code can be updated when an API needs to change.
      - deleted 8y ago
        [deleted]
      - nicoburns 8y ago
        My understanding is that this is something that a microkernel design ought to be able to improve upon...
      - lbenes 8y ago
        > Drivers written for Vista didn't necessarily work on Windows 7 This is patently, provably FALSE[1] MS goes out of their way to NOT to break APIs. My ancient ATI netbook can run Windows Vista graphics drivers on Win 10. MS only breaks driver API when massive kernel/underlying APIs demand it. ex. 98->NT, XP->Visa. Now contrast that with Linux. Linux kernel devs are openly hostile to binary blob drivers so they make no attempt to preserve ABI stability. I've see this happen multiple times with ATI binary drivers in GNU/Linux and when I was running cyanogenmod on my phone. [1] https://www.techadvisor.co.uk/how-to/windows/how-get-drivers-for-windows-10-3620841/ https://www.techadvisor.co.uk/how-to/windows/how-get-drivers...
Jyaif 8y ago
That's very surprising that you mention iOS as being stable. To me it's the worst offender. Most of the apps I worked on needed to be updated for every single iOS release because of deprecated APIs.
- m45t3r 8y ago
  > That's very surprising that you mention iOS as being stable. To me it's the worst offender. Most of the apps I worked on needed to be updated for every single iOS release because of deprecated APIs. As a user, I concur with this. I can install Android apps created in 2012 that still work in Android 9. In iOS, I remember that each major update made half of my apps broken (in some cases, completely broken).
  - pjmlp 8y ago
    That will change with the new target requirements for Play Store.
izacus 8y ago
> I agree with you, but I do not believe in Google. Google provided worst commercial platform I ever had experience developing for. I had a lot of different platforms in my past - pretty much all consoles, desktop and fringe, like smart TVs or various smartphones released since 99'. I really find it hard to believe that Android is worse than proprietary, undocumented, Windows-only toolchains of Symbians, Tizens and bunch of other embedded crap, not to mention the horrors of what was PS3 toolchain at the begging. I think you might be overdramatizing this a bit.
- sterlind 8y ago
  I started my first Android app recently, and decided to go with their "Jetpack" stack recommendations. I wasted hours trying to get Dagger 2 injection working, only to discover I had to write tons of glue code which obviated the purpose of the DI framework in the first place! I don't want to worry about transitive dependencies over an object graph and writing ViewModelProviderFactories (actual name) and persisting my data with Room.... I just want widgets, logic and layout. Next I tried GKE and it was an absolute joy. I had a simple web app serving traffic an hour in. Probably because unlike Android, they have to make people like GKE to sell it.
  - izacus 8y ago
    Why are you bringing in Dagger 2, a non-platform separate dependency injection library here? :) Do you think a proprietary Windows C++ compiler for an embedded platform will make your DI uses easier? :)
    - sterlind 8y ago
      The Android Jetpack guidelines strongly recommend Dagger 2, and it's a Google product so I thought I should comply.
- pjmlp 8y ago
  Please give me back Symbian C++ versus the experience of using the Android NDK. And if you prefer a more modern example, Android is indeed worse to use than UWP or iOS. When they release stable releases, they are actually betas, and updated documentation is scattered around Medium and G+ posts, alongside Google IO and DevBytes videos, why bother updating the official documentation. After 10 years, the NDK still feels like a 20% job from a team that is forced to accept that Android should provide a bit more than just 100% Java.
blago 8y ago
My experience with android has been very similar. For example, last week I ran into a bug that seems like a simple omission that was reported back in 2010 (https://issuetracker.google.com/issues/36918490 https://issuetracker.google.com/issues/36918490). It took until Feb 12, 2019 to get an official response: > We're planning to implement a new more powerful network request interception API in a future version, which will be available to L+ devices with a recent enough WebView via AndroidX. Being able to read POST bodies is one of the features we're intending to include. Unfortunately we can't share schedule information about when this may be available, but we are aware of this use case and intend to support it. Instead of fixing bugs and making incremental improvements, they seem to have a strong propensity for grand rewrites. I got tired of the constant parade of new Google APIs, libraries, and technologies years ago and have been choosing alternative products whenever possible.
- vondur 8y ago
  This sounds suspiciously like CADT, as described by JWZ: https://www.jwz.org/doc/cadt.html https://www.jwz.org/doc/cadt.html
  - deleted 8y ago
    [deleted]
  - snvzz 8y ago
    Considering how that site handles links from HN, you might want to consider linking it through https://nullrefer.com https://nullrefer.com or the like. http://nullrefer.com/?https://www.jwz.org/doc/cadt.html http://nullrefer.com/?https://www.jwz.org/doc/cadt.html
    - blago 8y ago
      Haha, so this is what happened? I had a big WTF moment.
      - ktpsns 8y ago
        Apparently the author of jwz.org doesn't like HN. This is him, by the way: https://web.archive.org/web/20170125134508/http://sleepmode.hetnieuweinstituut.nl:80/en/jamie-zawinski https://web.archive.org/web/20170125134508/http://sleepmode....
wwright 8y ago
People say this a lot, but I think their behavior makes more sense when you view the end user as the product. Who cares about API stability, the advertisers are getting exactly what they want.
vgoh1 8y ago
My thoughts exactly. I have two apps out on Google Play. They are full featured, stable, and people still like them. I just want them to to continue to work. But they don't. I need to constantly take away from my time developing new apps to fix my newly broken old apps. How many times, Google, are you going to try to "fix" the problem of apps draining battery in the background? It never seems to end. On the flip side, my first programs that I wrote for myself in the 90's still run. Yeah, I know that DOS is emulated now, but MS made them still work, and I didn't even have to re-compile. I have this conspiracy theory that Google is purposefully trying to make things difficult to get rid of developers that don't have a lot of resources.
- iainmerrick 8y ago
  I have the same problem. I think Hanlon’s Razor applies -- this isn’t intentional, it’s just unfortunate mistakes. I think the main driving factors are: - Many Android APIs were badly designed from the start; - Android was not designed for easy OS updates, so many users have old OSes; - Google like Apple’s approach of aggressively deprecating old APIs, and try to do the same. But unlike Apple, they still have to deal with old OS versions, and their fundamental OS design is not as sound. The end result is what we see, messy and buggy APIs.
- ColinWielga 8y ago
  Same
- georgeecollins 8y ago
  >> I have this conspiracy theory that Google is purposefully trying to make things difficult to get rid of developers that don't have a lot of resources. I agree and Apple does this on iOS as well. It's a way of clearing out old apps.
xiphias2 8y ago
> But Google keeps making their own special PhD driven darlings. I'm really sorry that you have this feeling, but this has nothing to do with PhDs. It's impossible to get promoted by bug fixes inside Google, and people are promotion driven. There were many people who tried hard to fix a lot of bugs, but they usually burn out due to lack of recognition inside Google.
- asark 8y ago
  It really, really shows. That and documentation. And some periphery work related to larger efforts, especially on any platform that's not the Web. It's the only explanation for how an organization like that can produce so much broken and half-assed software—bad incentives, and probably a serious middle management problem, in that they don't have leverage or motivation to make ICs do "boring" and follow-through work. Maybe it's working for them from a bottom-line perspective, but it's made their brand as an engineering company clownish.
  - xiphias2 8y ago
    The key question is the bottom-line, as you wrote. Management is really hard to scale, but right now innovation is a better prediction of growth than bug fixes, so I think it's not even clear how to improve the promotion process without hurting growth of the company. I think Google is too big at this point already, but that's an orthogonal question.
    - asark 8y ago
      A non-"rockstar" hiring process and parallel job track (with potential for cross-over) so they can get in people who are happy to do "boring" work on an interesting product might do it. Probably can't be in the Valley or anywhere else ultra-high COL. I think part of the problem is they (seem to?) only staff folks who both can and are inclined to leave quickly if they don't get to do the fun stuff. Again, though, may not make sense for them from a $$$ perspective. Jank and rough edges galore may be something they're willing to live with. [EDIT] How this works in my head: Manager: Could you take a look at the Android developer documentation? Some of it's badly outdated and have you actually tried using it? A lot of the advice is... kinda bad. Also maybe look at a few of these UI components we had the Summer interns make, they've got bizarre implementations and are difficult and inconsistent to customize. Oh and god have you looked at our issue tracker? Has anyone, actually? Like, ever? Developer: Hey so have you heard of this place called Amazon? Manager: Uh I mean how about we start a fourth greenfield instant messaging product instead? Developer: That's better. Amazon? Who's Amazon?
derefr 8y ago
Android wasn't created by Google. They acquired it, and then had to deal with the legacy cruft that was already a part of it by then. The "platform-level" changes they've made since the acquisition—e.g. replacing Dalvik with ART—have mostly been sound engineering choices. > They do not realize that they are make •a platform•, not a product. Consider: maybe Fuchsia isn't a platform? ChromeOS certainly isn't a platform: developers don't develop "for ChromeOS." App developers target the WebExtension ABI (or, more recently, the Android ABI), and ChromeOS just runs their apps using mysterious virtualization magic that doesn't matter to the developer. You don't target the OS; you just target a stable ABI. (Other examples of this: the Linux kernel ABI used by Docker on {Linux, macOS, Windows}; the Linux kernel ABI used by Illumos branded zones; the Linux userland ABI used by the Steam Runtime.) Essentially, you can think of ChromeOS not as an OS in the traditional sense, but as a hypervisor. The libs your apps depend on aren't part of the OS; they're part of your ABI's zonal environment, which is stabilized separately from the OS. I would expect that Fuchsia is doing the same: being an OS but not a platform. The only people who will have to directly target Fuchsia are Google engineers.
mkss 8y ago
Forget about believing in Google, try at least for consistency within a single paragraph, as in: > They do not realise that they are make •a platform•, not a product and then: > OS is to launch apps And I still can't stop laughing after reading: > Somehow every other platform is fine To paraphrase JWZ's CADT article linked below "writing thoughtful critique" is not fun, "making useful suggestions to improve something" is not fun but "writing a snarky, resentful rant on HN" is fun. ps. most developers on Android are not game developers, maybe time to think about seeing the world from other peoples point of view?

by Svoka 8y ago

hortense 8y ago

It will increase stability in a very important way because they apparently want stability of drivers, which Linux does not offer.

yc12340 8y ago
> they apparently want stability of drivers Strangely, the only Android drivers, that can be trivially ported between Android version, are those "unstable" bits in Linux kernel. Take any postmarket smartphone firmware — if something does not work after porting to new Android version, you can bet, that it is a proprietary userspace blob. Who develops HAL for those blobs? — Google. Who controls it's API? — Google. What "stability of drivers" are we talking about here? Certainly not the kind, helpful to users.
- ebg13 8y ago
  > Strangely, the only Android drivers, that can be trivially ported between Android version, are those "unstable" bits in Linux kernel. That's only because the Linux kernel is actively hostile to the idea of maintaining a stable driver interface. Windows 7 drivers from 10 years ago still work in Windows 10.
imtringued 8y ago
ARM and the SoC Vendors don't like open sourcing their drivers. They prefer to just dump binary blobs and stop support after 2 years. The users couldn't care less because they buy a new phone anyway. (except me)
- phkahler 8y ago
  If the OS and APIs were stable, nobody would ever need to update a driver unless they wanted a bug fix.
  - ufo 8y ago
    Even Windows has a hard time keeping their OS APIs stable. Drivers written for Vista didn't necessarily work on Windows 7 and so on. This is one of the reasons why Linux highly encourages open sourcing the things so that the driver code can be updated when an API needs to change.
    - deleted 8y ago
      [deleted]
    - nicoburns 8y ago
      My understanding is that this is something that a microkernel design ought to be able to improve upon...
    - lbenes 8y ago
      > Drivers written for Vista didn't necessarily work on Windows 7 This is patently, provably FALSE[1] MS goes out of their way to NOT to break APIs. My ancient ATI netbook can run Windows Vista graphics drivers on Win 10. MS only breaks driver API when massive kernel/underlying APIs demand it. ex. 98->NT, XP->Visa. Now contrast that with Linux. Linux kernel devs are openly hostile to binary blob drivers so they make no attempt to preserve ABI stability. I've see this happen multiple times with ATI binary drivers in GNU/Linux and when I was running cyanogenmod on my phone. [1] https://www.techadvisor.co.uk/how-to/windows/how-get-drivers-for-windows-10-3620841/ https://www.techadvisor.co.uk/how-to/windows/how-get-drivers...

Jyaif 8y ago

That's very surprising that you mention iOS as being stable. To me it's the worst offender. Most of the apps I worked on needed to be updated for every single iOS release because of deprecated APIs.

m45t3r 8y ago
> That's very surprising that you mention iOS as being stable. To me it's the worst offender. Most of the apps I worked on needed to be updated for every single iOS release because of deprecated APIs. As a user, I concur with this. I can install Android apps created in 2012 that still work in Android 9. In iOS, I remember that each major update made half of my apps broken (in some cases, completely broken).
- pjmlp 8y ago
  That will change with the new target requirements for Play Store.

izacus 8y ago

> I agree with you, but I do not believe in Google. Google provided worst commercial platform I ever had experience developing for. I had a lot of different platforms in my past - pretty much all consoles, desktop and fringe, like smart TVs or various smartphones released since 99'. I really find it hard to believe that Android is worse than proprietary, undocumented, Windows-only toolchains of Symbians, Tizens and bunch of other embedded crap, not to mention the horrors of what was PS3 toolchain at the begging. I think you might be overdramatizing this a bit.

sterlind 8y ago
I started my first Android app recently, and decided to go with their "Jetpack" stack recommendations. I wasted hours trying to get Dagger 2 injection working, only to discover I had to write tons of glue code which obviated the purpose of the DI framework in the first place! I don't want to worry about transitive dependencies over an object graph and writing ViewModelProviderFactories (actual name) and persisting my data with Room.... I just want widgets, logic and layout. Next I tried GKE and it was an absolute joy. I had a simple web app serving traffic an hour in. Probably because unlike Android, they have to make people like GKE to sell it.
- izacus 8y ago
  Why are you bringing in Dagger 2, a non-platform separate dependency injection library here? :) Do you think a proprietary Windows C++ compiler for an embedded platform will make your DI uses easier? :)
  - sterlind 8y ago
    The Android Jetpack guidelines strongly recommend Dagger 2, and it's a Google product so I thought I should comply.
pjmlp 8y ago
Please give me back Symbian C++ versus the experience of using the Android NDK. And if you prefer a more modern example, Android is indeed worse to use than UWP or iOS. When they release stable releases, they are actually betas, and updated documentation is scattered around Medium and G+ posts, alongside Google IO and DevBytes videos, why bother updating the official documentation. After 10 years, the NDK still feels like a 20% job from a team that is forced to accept that Android should provide a bit more than just 100% Java.

blago 8y ago

My experience with android has been very similar. For example, last week I ran into a bug that seems like a simple omission that was reported back in 2010 (https://issuetracker.google.com/issues/36918490 https://issuetracker.google.com/issues/36918490). It took until Feb 12, 2019 to get an official response: > We're planning to implement a new more powerful network request interception API in a future version, which will be available to L+ devices with a recent enough WebView via AndroidX. Being able to read POST bodies is one of the features we're intending to include. Unfortunately we can't share schedule information about when this may be available, but we are aware of this use case and intend to support it. Instead of fixing bugs and making incremental improvements, they seem to have a strong propensity for grand rewrites. I got tired of the constant parade of new Google APIs, libraries, and technologies years ago and have been choosing alternative products whenever possible.

vondur 8y ago
This sounds suspiciously like CADT, as described by JWZ: https://www.jwz.org/doc/cadt.html https://www.jwz.org/doc/cadt.html
- deleted 8y ago
  [deleted]
- snvzz 8y ago
  Considering how that site handles links from HN, you might want to consider linking it through https://nullrefer.com https://nullrefer.com or the like. http://nullrefer.com/?https://www.jwz.org/doc/cadt.html http://nullrefer.com/?https://www.jwz.org/doc/cadt.html
  - blago 8y ago
    Haha, so this is what happened? I had a big WTF moment.
    - ktpsns 8y ago
      Apparently the author of jwz.org doesn't like HN. This is him, by the way: https://web.archive.org/web/20170125134508/http://sleepmode.hetnieuweinstituut.nl:80/en/jamie-zawinski https://web.archive.org/web/20170125134508/http://sleepmode....

wwright 8y ago

People say this a lot, but I think their behavior makes more sense when you view the end user as the product. Who cares about API stability, the advertisers are getting exactly what they want.

vgoh1 8y ago

My thoughts exactly. I have two apps out on Google Play. They are full featured, stable, and people still like them. I just want them to to continue to work. But they don't. I need to constantly take away from my time developing new apps to fix my newly broken old apps. How many times, Google, are you going to try to "fix" the problem of apps draining battery in the background? It never seems to end. On the flip side, my first programs that I wrote for myself in the 90's still run. Yeah, I know that DOS is emulated now, but MS made them still work, and I didn't even have to re-compile. I have this conspiracy theory that Google is purposefully trying to make things difficult to get rid of developers that don't have a lot of resources.

iainmerrick 8y ago
I have the same problem. I think Hanlon’s Razor applies -- this isn’t intentional, it’s just unfortunate mistakes. I think the main driving factors are: - Many Android APIs were badly designed from the start; - Android was not designed for easy OS updates, so many users have old OSes; - Google like Apple’s approach of aggressively deprecating old APIs, and try to do the same. But unlike Apple, they still have to deal with old OS versions, and their fundamental OS design is not as sound. The end result is what we see, messy and buggy APIs.
ColinWielga 8y ago
Same
georgeecollins 8y ago
>> I have this conspiracy theory that Google is purposefully trying to make things difficult to get rid of developers that don't have a lot of resources. I agree and Apple does this on iOS as well. It's a way of clearing out old apps.

xiphias2 8y ago

> But Google keeps making their own special PhD driven darlings. I'm really sorry that you have this feeling, but this has nothing to do with PhDs. It's impossible to get promoted by bug fixes inside Google, and people are promotion driven. There were many people who tried hard to fix a lot of bugs, but they usually burn out due to lack of recognition inside Google.

asark 8y ago
It really, really shows. That and documentation. And some periphery work related to larger efforts, especially on any platform that's not the Web. It's the only explanation for how an organization like that can produce so much broken and half-assed software—bad incentives, and probably a serious middle management problem, in that they don't have leverage or motivation to make ICs do "boring" and follow-through work. Maybe it's working for them from a bottom-line perspective, but it's made their brand as an engineering company clownish.
- xiphias2 8y ago
  The key question is the bottom-line, as you wrote. Management is really hard to scale, but right now innovation is a better prediction of growth than bug fixes, so I think it's not even clear how to improve the promotion process without hurting growth of the company. I think Google is too big at this point already, but that's an orthogonal question.
  - asark 8y ago
    A non-"rockstar" hiring process and parallel job track (with potential for cross-over) so they can get in people who are happy to do "boring" work on an interesting product might do it. Probably can't be in the Valley or anywhere else ultra-high COL. I think part of the problem is they (seem to?) only staff folks who both can and are inclined to leave quickly if they don't get to do the fun stuff. Again, though, may not make sense for them from a $$$ perspective. Jank and rough edges galore may be something they're willing to live with. [EDIT] How this works in my head: Manager: Could you take a look at the Android developer documentation? Some of it's badly outdated and have you actually tried using it? A lot of the advice is... kinda bad. Also maybe look at a few of these UI components we had the Summer interns make, they've got bizarre implementations and are difficult and inconsistent to customize. Oh and god have you looked at our issue tracker? Has anyone, actually? Like, ever? Developer: Hey so have you heard of this place called Amazon? Manager: Uh I mean how about we start a fourth greenfield instant messaging product instead? Developer: That's better. Amazon? Who's Amazon?

derefr 8y ago

Android wasn't created by Google. They acquired it, and then had to deal with the legacy cruft that was already a part of it by then. The "platform-level" changes they've made since the acquisition—e.g. replacing Dalvik with ART—have mostly been sound engineering choices. > They do not realize that they are make •a platform•, not a product. Consider: maybe Fuchsia isn't a platform? ChromeOS certainly isn't a platform: developers don't develop "for ChromeOS." App developers target the WebExtension ABI (or, more recently, the Android ABI), and ChromeOS just runs their apps using mysterious virtualization magic that doesn't matter to the developer. You don't target the OS; you just target a stable ABI. (Other examples of this: the Linux kernel ABI used by Docker on {Linux, macOS, Windows}; the Linux kernel ABI used by Illumos branded zones; the Linux userland ABI used by the Steam Runtime.) Essentially, you can think of ChromeOS not as an OS in the traditional sense, but as a hypervisor. The libs your apps depend on aren't part of the OS; they're part of your ABI's zonal environment, which is stabilized separately from the OS. I would expect that Fuchsia is doing the same: being an OS but not a platform. The only people who will have to directly target Fuchsia are Google engineers.

mkss 8y ago

Forget about believing in Google, try at least for consistency within a single paragraph, as in: > They do not realise that they are make •a platform•, not a product and then: > OS is to launch apps And I still can't stop laughing after reading: > Somehow every other platform is fine To paraphrase JWZ's CADT article linked below "writing thoughtful critique" is not fun, "making useful suggestions to improve something" is not fun but "writing a snarky, resentful rant on HN" is fun. ps. most developers on Android are not game developers, maybe time to think about seeing the world from other peoples point of view?