English is pretty fluid. Like yourself I don’t love the buzzword-y feel of business slang (oh how we’ve destroyed the impact of “impact” with “impactful”; please slap me if I utter “ideating”), but without the flexibility to produce those horrors, we wouldn’t have delights like lit, hangry, and sus.
I dunno a lot of migrations to X technology are pitched as valuable on one quality dimension. We improved performance by Y%! When software “quality” should really consider many criteria: correctness, performance, developer productivity, maintainability and others.
I’d rather hear about a set of tradeoffs in these sorts of articles (performance was critical so we traded Y for X) than just bragging about one dimension of improvement.
> I dunno a lot of migrations to X technology are pitched as valuable on one quality dimension. We improved performance by Y%!
I'd add that more often than not these performance impacts are not due to changes in programming languages/frameworks/libraries/whatever but because some architecture or algorithmic constraint is done under the scope of the migration.
TLDR: Native language wins over JVM optimisations.
In my recent but limited experience of working on iOS apps, they do need any performance boost they can get anywhere. Coming to the Apple ecosystem (appstore connect, testflight, xcode etc) it's quite a shock on how slow it all is (using xcode on a Mac Mini M4 for development, and as for web updates/approvals etc I now understand the pain others have mentioned here).
I wonder how long their build time is. The article from the “Things” folks said their system took 10 minutes to build despite being only 30k LoC, which seems really bad. I can’t help but think they must have done something off for it to take that long.
Hence, I wonder how long it take a to build what is probably a medium size system when done by a team at Apple.
14 comments
[ 2.7 ms ] story [ 42.2 ms ] threadWhat would make it inappropriate?
The Uplift War
https://en.m.wikipedia.org/wiki/The_Uplift_War
I’d rather hear about a set of tradeoffs in these sorts of articles (performance was critical so we traded Y for X) than just bragging about one dimension of improvement.
I'd add that more often than not these performance impacts are not due to changes in programming languages/frameworks/libraries/whatever but because some architecture or algorithmic constraint is done under the scope of the migration.
In my recent but limited experience of working on iOS apps, they do need any performance boost they can get anywhere. Coming to the Apple ecosystem (appstore connect, testflight, xcode etc) it's quite a shock on how slow it all is (using xcode on a Mac Mini M4 for development, and as for web updates/approvals etc I now understand the pain others have mentioned here).
That sounds like a phenomenal reduction in complexity!
Hence, I wonder how long it take a to build what is probably a medium size system when done by a team at Apple.