Uhh, is there a platform there that isn't greatly improved by community libraries? At PSPDFKit we use a lot of additional third party tools and libraries on iOS as well, C++ practically needs community libraries to be usable, Python's biggest strength is in its excellent OSS library community, Ruby as well...

I mean, yeah, in perfect world we'd all have neatly packaged by Google, we'd write 6 lines of code and have the greatest app ever. But software development never kinda worked that way for me and I have a feeling it never will :/

C++ isn't a platform with a platform owner.

Python's biggest strength that lead to its adoption was being a language with "Batteries Included".

I'm not sure about the meaningful distinction here. Programming on any platform will be greatly improved by using good (preferrably opensource) libraries. What difference does it make who made them and why? It's such a strange nitpick.

Difference is at the beginning. When I started using Python I absolutely loved that stdlib covered almost everything I thought I could need. These days packages I use mostly come from elsewhere, but at the beginning it was great.

I'm fine with Javascript development these days because I built my fundamentals years ago. I am not sure how comfortable I would be otherwise and when I meet people who are where I used to be, they often look lost.

I am also thinking about learning Android development and don't really know where to begin.

Because outside the startup world, in many enterprises developers are only allowed to use sanctioned libraries outside what the platform owner advises as best practices.

So everyone suffers when anything more complex than hello world already required third party libraries, specially ones that aren't even acknowledged by Google.

A self inflicted restriction doesn't make a language bad.

It is not self inflicted, rather imposed by customers.

Also the Android operating system isn't a language.

Regardless, it doesn't reflect on the language/os/ecosystem/platform/system/library/runtime

If a company wants to vet all of their software, good on them! But that doesn't mean that anything that's not vetted by them is somehow worse for the majority of users, just that they haven't vetted it yet. So any arguments about how "library x" isn't usable by them won't apply to the vast majority of people, because most don't have that issue, or have no problems vetting that library as well.

Somewhat off topic. Is there a word that encompses the langauge, platform, runtime, etc...? I hate the word "ecosystem", but it seems like the best bet. And using any one of the others brings out comments of "well it's not a language" or "it's not a framework it's a library" or something else.

If you're using N separate libraries, that's N times the likelihood of breaking changes that force you to migrate at inconvenient times, and O(N^2) opportunities for bugs caused by incompatibilities.

Two libraries can misbehave because they share a common dependency.

If you assume a roughly logarithmic intersection of shared dependencies that's O(N^2 log n) chances for a bug. But in some communities I'm sure even that is optimistic.

Python biggest use case is a scripting language - you don't want to bother with dependency management and all that stuff when you're writing scripts.

When you have a more complicated project it's fine to rely on repo packages (Python does as well for eg. web frameworks like Django aren't in the core). In fact python std lib is hugely inconsistent stylistically as a result of needing to keep it stable over the releases as people expect it to be backcompatible and package versions are tied to language versions. If it had proper versioned dependencies doing breaking refactoring over the years would be really easy and non-intrusive.

Python is a very well-designed language and always has been. The batteries wouldn't have ever existed without that fact.

No it doesn't it's the same on iOS.

Apple didn't come up with dependency/package managers like Carthage or Cocoapods, the community did. There's just enormous amounts of OSS libraries provided by the community too, with ones like Alamofire smoothing out the rough edges of iOS's networking APIs.

The difference to me is that under iOS, you can go without these things (third party libs, Cocoapods/Carthage) and still be OK — you'll be at a relatively minor inconvenience, not ripping your hair out. Particularly with your example of Alamofire/AFNetworking, there's not a ton of functionality you're missing out on if you instead use NSURLSession, since they're both just light wrappers around it. This wasn't always true, but Apple recognized the gap in functionality and fixed it.

I have multiple personal Obj-C/Swift projects on iOS and macOS that don't use any kind of dependency management and use very few third party libraries and working on them has never been an issue or source of pain.

Actually, I make a point in my iOS projects to avoid third party libraries wherever possible. The first-party SDK is good enough that the dependency cost of libraries like Alamofire is usually not worth it. I had to do some Android development not too long ago, and I felt like I had entered some crazy la-la land until I found a bunch of third party infrastructure like Kotlin, RXJava and a pile of libraries to make life bearable.

> Actually, I make a point in my iOS projects to avoid third party libraries wherever possible.

Thats not a bragging point.

DRY can be taken to extremes. It is ok to sometimes write code yourself than to tie yourself and depend on some other library by "some guy". The whole NPM "left pad" debacle is proof of that.

What matters is the out of the box experience.

IMO, this is exactly right. Not only is the quality of APIs often a disaster, the recommendations/best practices that Google is broadcasting have been way off in the past.

Rememember that Google has been advocating AsyncTask in the past. You could use something else or roll your own, but it doesn't make sense to do that when AsyncTask is being communicated as the way forward. They should've embraced third-party libraries, but instead they still communicate how to use AsyncTask. Example: last March 2016 they published a video on how to use AsyncTask [0]. They do highlight the red-flags around it, but do not mention any of the third-party libraries that are considered standard for a lot of Android developers already.

The same goes for Fragments. It is still being advocated as the right way, but I have some doubts. I imagine they will be advocated against in a couple of years. They help at the time, but are far from logical/simple when you don't know all of the crooks and crannies (and there are quite a few).

Another API that needs serious work is the Storage Access Framework (SAF). Previously Android applications could use the Java File API to access files. With recent Android versions this has been closed off with good reasons and intentions. Instead of using the File API directly, you now need to use SAF. SAF doesn't support all operations you could do with the File API. I would say this is a regression and existing applications that relied on these features are now broken and unrepairable. In addition, applications now needed to explicitly ask the user for permission to specific directories or files. This was so badly implemented that every file manager needed to instruct the user on how to use the directory picker of Android using screenshots before showing the picker. This is still a problem and even if it is fixed, it will still be a problem for years due to phones being unable to update.

To give you an impression on how those APIs are designed: many calls of SAF will return null to indicate something went wrong. No exceptions or error-codes. There is often no indication why a certain file cannot be retrieved. It could be non-existing, it could be denied permissions, it could be some strange behavior in the rom. There is sometimes a way to find out why this returned null and that is looking through Androids global log. I've implemented this in the beta of my app so that I could find out why files weren't accessible on some devices.

Also, because of the slow adoption of Android versions, your application needs to support both SAF and the Java File API. The support library has wrappers for Java File API that works like SAF, but it's still a downgrade to use this API as exceptions from the Java File API are just ignored [1].

For me Gradle is actually a step in the right direction. Builds seem to be more reproducible and do not fail randomly compared to the Eclipse/Ant days. The performance is however awful. Incremental builds take 30 - 60 seconds. When comparing this to building pure Java projects it shows that it is an Android-only issue and not one with Gradle.

[0] https://www.youtube.com/watch?v=jtlRNNhane0

[1] https://github.com/guardianproject/android-support-library/b...