5 ms·

That's also why (forcing more people to use XCode and thus the official APIs, BitCode, and so on), they can introduce a whole new architecture like AS

That's also why (forcing more people to use XCode and thus the official APIs, BitCode, and so on), they can introduce a whole new architecture like AS and have macOS apps support it from day one, or old x86 apps running smoothly translated. It's a failure of HN culture that posts like this get downvoted. You can like it, loathe it, or feel somewhere in the middle. However, this is factually true, and it is a relevant and legitimate response to issues raised by the parent poster.

rfoo 6y ago
... Or maybe it is not factually true? You can't beat Hyrum's law by simply "forcing more people to use official API", with enough code people still depends on every implementation details in your code.
- sjwright 6y ago
  Given that Apple has explicitly stated this benefit and given that Apple has explicitly utilised these exact benefits in the real world on multiple occasions, it's rather bold to propose that it might not be factually true. Obviously it's not the only reason that Apple does things the way they do. It's probably not even the number one reason. But it's certainly one significant reason which seems to fit the objective criteria of being factually true. (To be clear, I am stating no personal opinion about whether Apple's approach is "good" by any criteria.)
- coldtea 6y ago
  >You can't beat Hyrum's law by simply "forcing more people to use official API", with enough code people still depends on every implementation details in your code. That's neither here, nor there though. You can still beat the biggest part of fragmentation by "forcing more people to use official API". Doesn't have to be perfect, just good enough to make moving forward, porting to your new architectures and APIs, etc, easier. In fact, Apple just showcased it works with the move to M1 (and to a lesser degree earlier with the move to x64 and the move to 64bits).
apple_innocent 6y ago
Yeah but there's nothing that says the Xcode experience has to be so painful[1] or that people have to pay Apple or that software has to be approved by Apple in order to preserve this flexibility. Purchasers should have options, including the option to write software (for themselves) that works on the computer they paid for but might not work if Apple introduces computers based on a new architecture, which the existing Apple customer may or may not choose to buy in the future. 1. Painful for the parent commenter. It is painful for me, too. It might, or might not, be painful for others.
- coldtea 6y ago
  >Yeah but there's nothing that says the Xcode experience has to be so painful Well, who says it is objectively painful (as opposed to just not what the grandparent is used to or prefers)?
  - josephg 6y ago
    Its pretty bad. XCode (with swift) seems to crash on me regularly just with normal usage. The last time I used it occasionally it would lag so badly that it sometimes lost characters I was typing, and my code would come out completely garbled (what!?). A few weeks ago I tried to do a local build of Signal's iOS app and the swift compiler errored out on some random function. Apparently it spent so long doing type inference that it decided to just generate a compilation error instead. I guess I'm not wealthy enough to even compile swift code slowly. (For reference, this on a $3000 (AUD) macbook pro from 2016 with 16 gigs ram, the latest xcode and nothing else open). Back in the objective-C days I used to really like XCode and loved interface builder. The documentation and ecosystem seemed top notch. But in the last few years its gotten much, much worse. Its like the old guard have left and a young generation have come in to develop the swift ecosystem - and they just don't have good judgement yet. The documentation is halfbaked at best. The whole environment is an overcomplicated, buggy, laggy mess. Its a pity too, because I think Swift is a lovely language and I love what they're doing with SwiftUI. In comparison I find microsoft's tooling around their languages to be excellent. Visual studio + vs code are fast, stable, feature rich and responsive. Particularly with microsoft's own languages: C# and typescript.
onelovetwo 6y ago
is downvoting even a thing in HN?
vbezhenar 6y ago
Linux with gcc supported plenty of architectures without much fanfare.

rfoo 6y ago

... Or maybe it is not factually true? You can't beat Hyrum's law by simply "forcing more people to use official API", with enough code people still depends on every implementation details in your code.

sjwright 6y ago
Given that Apple has explicitly stated this benefit and given that Apple has explicitly utilised these exact benefits in the real world on multiple occasions, it's rather bold to propose that it might not be factually true. Obviously it's not the only reason that Apple does things the way they do. It's probably not even the number one reason. But it's certainly one significant reason which seems to fit the objective criteria of being factually true. (To be clear, I am stating no personal opinion about whether Apple's approach is "good" by any criteria.)
coldtea 6y ago
>You can't beat Hyrum's law by simply "forcing more people to use official API", with enough code people still depends on every implementation details in your code. That's neither here, nor there though. You can still beat the biggest part of fragmentation by "forcing more people to use official API". Doesn't have to be perfect, just good enough to make moving forward, porting to your new architectures and APIs, etc, easier. In fact, Apple just showcased it works with the move to M1 (and to a lesser degree earlier with the move to x64 and the move to 64bits).

apple_innocent 6y ago

Yeah but there's nothing that says the Xcode experience has to be so painful[1] or that people have to pay Apple or that software has to be approved by Apple in order to preserve this flexibility. Purchasers should have options, including the option to write software (for themselves) that works on the computer they paid for but might not work if Apple introduces computers based on a new architecture, which the existing Apple customer may or may not choose to buy in the future. 1. Painful for the parent commenter. It is painful for me, too. It might, or might not, be painful for others.

coldtea 6y ago
>Yeah but there's nothing that says the Xcode experience has to be so painful Well, who says it is objectively painful (as opposed to just not what the grandparent is used to or prefers)?
- josephg 6y ago
  Its pretty bad. XCode (with swift) seems to crash on me regularly just with normal usage. The last time I used it occasionally it would lag so badly that it sometimes lost characters I was typing, and my code would come out completely garbled (what!?). A few weeks ago I tried to do a local build of Signal's iOS app and the swift compiler errored out on some random function. Apparently it spent so long doing type inference that it decided to just generate a compilation error instead. I guess I'm not wealthy enough to even compile swift code slowly. (For reference, this on a $3000 (AUD) macbook pro from 2016 with 16 gigs ram, the latest xcode and nothing else open). Back in the objective-C days I used to really like XCode and loved interface builder. The documentation and ecosystem seemed top notch. But in the last few years its gotten much, much worse. Its like the old guard have left and a young generation have come in to develop the swift ecosystem - and they just don't have good judgement yet. The documentation is halfbaked at best. The whole environment is an overcomplicated, buggy, laggy mess. Its a pity too, because I think Swift is a lovely language and I love what they're doing with SwiftUI. In comparison I find microsoft's tooling around their languages to be excellent. Visual studio + vs code are fast, stable, feature rich and responsive. Particularly with microsoft's own languages: C# and typescript.

onelovetwo 6y ago

is downvoting even a thing in HN?

vbezhenar 6y ago

Linux with gcc supported plenty of architectures without much fanfare.