Hacker News Reader

Comment by worstspotgain | Hacker News Reader

Android is an example of technical debt from poor caked-in design. Its problems are still stemming from being rushed to market (relatively speaking) two decades ago. It's had enormous success as the most viable iOS alternative, but at a cost.

On the flip side, consider PalmOS. It was SotA at its debut in 1996. In the early aughts, Palm made Treo smartphones when almost no one knew what a smartphone was. It had a multiyear lead, yet it got easily marginalized by iOS and Android. Its technical debt was from maintaining backward compatibility with 90's apps, and cost it dearly. To be fair, company management sucked too.

The moral is: caked-in issues suck, but if you're going all in with a design, the most important thing is to time it with the explosion of the market. Palm was too early, others like Maemo and Windows Phone were too late.

View on HN

Dart and Flutter were actually meant to be the better design. Lots of features from those were replicated on Kotlin-Jetpack, especially Compose. And lots of those features end up being copied to Java.

Dart-Flutter still supports them better natively though, instead of having to hack things like reactive programming via Kotlin Flow.

Flutter is at best no different IMO, as now not only do you have to deal with Flutter's build system for Dart, you also have to deal with Kotlin/the default Android build system when you want to do something not supported by the Flutter std libs, which last I tried was quite a lot. That was a few years back though so maybe its changed (though I doubt it). Jetpack Compose is similar in its "not much better"-ness to me.

I can't remember if it was Compose or Flutter, where I spent a ridiculous amount of time trying to get something to stay centered on the screen regardless of orientation. Something that I could do pretty easily and quickly with my own UI tech library in C++. However I can't use that code without having to jump through all the annoying hoops you have to jump through with JNI crap in order to use it. So I just don't bother with Android anymore.

Flutter is quite good now. Performance is actually better than SwiftUI out of the box and the ecosystem and tooling is mature.

Unfortunately with all the short-sighted cost cutting Google has been doing lately it's even harder to have faith that they won't axe it sometime soon.

Centering a widget regardless of orientation (and detecting the orientation) is incredibly trivial with Flutter. You might have just been tired at the end of a long day and missed something.

Yeah, my thought was it was someone unfamiliar with mobile measurements. It's meant to handle mobile UIs, which means "pixel" doesn't exist as measurement because screens are different densities, different aspect ratio. You could do a thing like make an empty block with full padding to the left or right, or just center align it.

I made a mobile game in Ren'Py and it was hard for me because of the fixed assumption that something was 800x600 and such and you'd add padding on the sides lol. Unfortunately with mobile, everything is relative to each other. iOS was a little easier back when it was one size, but now it's not.

It's still a lot easier to do than fixing sizes on CSS, flexbox, etc because you'd be able to have fine control over these things.

Now that I've thought about for a bit it was Compose I had that issue with.

I really just wish the Android group would get over their apparent disdain for native code and just let me write my app in C++ without having to deal with JNI BS.

Maemo was also too early I think. I guess the main problem was that the N800/N770 were not a smartphone, not mass-marketed and still too clunky for the general public (plus lack of unlimited mobile internet). Though the upgrade over PalmOS was impressive, went from barely able to load a modern web page to browing all the web smoothlessly while streaming online radios. (though this much shouldn't have been that impressive considering it's just basic multitasking and having enough RAM)

Ridiculously low-quality documentation, a build and development system that puts the local Rube Goldberg competition winner to shame, constant churn, total deafness or willful ignoring of wishes of dev ... and so on have nothing to do with what happened 20 years ago.

It's the classic "I would like to serve 5 terabytes"[0] Google problem.

(Their engineering culture reeks of this. See the tools they have released. Angular, Bazel, Go, Kubernetes, etc. The last one escaped the usual decline of incompetence because the community showed up.

Go has GOPATH. Even in a language designed for "simplicity" initially getting it set up had this roadblock.)

And no doubt the roots of the problem are manifold, but it seems all stemming from ongoing management incompetence (creation of shareholder value[1] maaaybe excluded, though I am very curious what kind of inane metrics the Android SDK team is whipped to chase).

[0] https://www.youtube.com/watch?v=3t6L-FlfeaI&t=0s

[1] https://www.wheresyoured.at/the-men-who-killed-google/

As primarily an end user of Android, it is fine. I like the more open nature of it.

But it is very clear that the guard rails were down especially for the first few years in trying to acquire functionality and market share by any means possible. Now Google is in space of trying to lock down the system while not breaking things.

macOS has decades-long technical debt as well (NSCell can still be found in the UIs you see), yet it remains incredibly robust aside from the years when Apple shake it with big visual updates.

It's incredibly robust compared to Windows

https://recorder.easeus.com/screen-recording-resource/macos-...

https://lifehacker.com/tech/mac-os-sonoma-update-fixes-scree... ... okay I don't even know what's this :D

Funny, for a lot of the functionality you get with Windows you have to pay some random dev for with MacOS. Window management alone feels like it's baby's first computer.

Last time I checked Windows still did not have anything like Quick Look, so for me it's the opposite. The only macOS enhancements I've been using since 2011 are Karabiner for keyboard customization and f.lux for warm colors at night.

of course, but that's on the feature completeness axis not on the stability (robustness), right?

I mean on macOS the Settings are so spartan it can really fit on an unfolded napkin. for power/battery management you need something like Amphetamine. Furthermore AFAIK there are no per-SSID network settings, so you either do DHCP or static IP. Have fun manually changing every time you go home-office. And so on.

What does caked-in mean?

It's a typo. OP meant baked-in.

https://dictionary.cambridge.org/dictionary/learner-english/...

> to be covered with a thick, dry layer of something

I read that, but it doesn't really make sense in context.

Sorry for the odd usage. The idea is taking a shortcut through a field and caking your boots in mud, or cheating in Game of Thrones and caking your sword in blood. I could have worded it better for sure.

FWIW, I think it was great (enough that it wouldn't hurt elaborating on the analogy when introducing it).

My mind went to machinery turning rigid and clunky over time due to being caked-in with a crust of thickening dust/rust/tech-debt, especially concentrated on sections "hot-fixed" with the metaphorical duct-tape/glue/lube/almost-fitting-spare.

If you want your machinery running smoothly and be easily servicable with off-the-shelf-parts, you can't skimp on maintenance for too long.

Reply on news.ycombinator.com