3 ms·
no stable driver interface, they are still learning how to cope with this. There is a ton of cruft in the APIs, like any large project would have. One of the
by on_and_off 8y ago
no stable driver interface, they are still learning how to cope with this.
There is a ton of cruft in the APIs, like any large project would have.
One of the engineer in the Android framework team described creating APIs as generating future regrets.
Some of the mistakes are pretty small. Like internally the system reuse drawable instances in order to save memory, but instead of making this process entirely automatic, before calling let's say `setTint(color)`, you need to call `mutate()` so the UI framework spins a copy of the drawable for you.
it would have been easy to integrate this behavior by default without having you know about mutate but since it was done differently, this behavior has been preserved in order to do not break retrocompatibility.
There are many small API issues like this. Big issues of course are corrected but often preserve the old behavior in case you are targetting an old version of the OS.
The View system is incredibly complex. Some of it is due to the inherent complexity of the problem, but some of it is due to the constraints of the time and some decisions that could have been better.
So there are many things you can improve by restarting from scratch and it is often easier than having to deal with the legacy APIs too.
- menckenjr 8y agoThen, of course, there's this: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
- Analemma_ 8y agoI would argue there's a difference between "rewriting the project" and "building something new based on additional decades of experience in the domain". Taken too literally, your comment suggests we should never e.g. write a new filesystem. Should Apple have taken Joel's advice and stuck with HFS+ forever? Sometimes the world changes enough that you can't keep grafting onto the old system, and need a new one. I don't know if Linux/Fuchsia meets those criteria, but given that there are extremely smart people at Google working on it, I would think that it's at least plausible.
- on_and_off 8y agoSo much this. IF you consider that there are some fundamental flaws in the Android Framework at the surface level, either oversights or just based on what the landscape looked like 10 years ago, then we have to reach a tipping point where it makes more sense to do a full rewrite than to continue building on this codebase. FWIW, there are major incremental improvements made at each release, most of them with very few changes to the high level APIs. The VM itself evolves at each release and has even been completely replaced from Dalvik to ART. The permission system has moved from install time (designed by engineers .. ) to iOS-like incremental runtime permissions. Not everything can be updated that way though. So it might be worth redesigning the OS with better assumption about its usage and by totally rewriting the APIs from scratch in order to avoid the mistakes made by Android (of course Fuchsia will also make some mistakes in its APIs .. all immense projects do, it does not mean that it can't improve on Android) And I don't think the OP article applies very neatly here. Android is still being worked on and is constantly improved. We are not in a situation where Android's development is going to freeze for 5 years while Fuchsia is being worked on. Completely different teams work on the 2 projects. If anything, Fuchsia has a lot of pressure in order to catch up with Android. And it might want to start supporting kotlin so that the dev experience gap is not too wide and to add an Android VM for retrocompat before starting to consider competing with Android.