Rationales for Swift standard library designs
1–10 of 13 posts
Re: Rationales for Swift standard library designs
#2I know this isn't quite the same vein, but I enjoy articles about "why you think you want X but it works like this because Y".
Raymond Chen is particularly good at writing them [1] [2].
[1] https://blogs.msdn.microsoft.com/oldnewthing/20110907-00/?p=...
[2] https://blogs.msdn.microsoft.com/oldnewthing/20160216-00/?p=...
Re: Rationales for Swift standard library designs
#3Yay, Apple, for opening up quite a bit. Boo, Apple, for including such a thing as this in any webpage ever:
Radars: rdar://problem/19705854
Re: Rationales for Swift standard library designs
#4Yay, Apple, for opening up quite a bit. Boo, Apple, for including such a thing as this in any webpage ever: Radars: rdar://problem/19705854 I really, really, really hope that Apple opens up Radar a la Microsoft Connect, and soon. It is stupendously frustrating to have an issue with an Apple product and run headlong into the brick wall of Radar.
If you listen to episode 146 of The Talk Show, John Gruber brings up this exact point to Eddy Cue and Craig Federighi (question starts at 48:15):
Re: Rationales for Swift standard library designs
#5Yay, Apple, for opening up quite a bit. Boo, Apple, for including such a thing as this in any webpage ever: Radars: rdar://problem/19705854 I really, really, really hope that Apple opens up Radar a la Microsoft Connect, and soon. It is stupendously frustrating to have an issue with an Apple product and run headlong into the brick wall of Radar.
If you listen to episode 146 of The Talk Show, John Gruber brings up this exact point to Eddy Cue and Craig Federighi (question starts at 48:15): https://daringfireball.net/thetalkshow/2016/02/12/ep-146
What did they say?
Re: Rationales for Swift standard library designs
#6Earlier quoted context omitted.
If you listen to episode 146 of The Talk Show, John Gruber brings up this exact point to Eddy Cue and Craig Federighi (question starts at 48:15): https://daringfireball.net/thetalkshow/2016/02/12/ep-146
What did they say?
Gruber brought up how in Apple Maps, if you suggest a correction, you are eventually informed when the fix is made.
However, with Radar, it is just a blackhole. You file your report and an awful lot of bugs, no matter how well written or even if they have example code, they will never hear back again about it.
He said that this was a negative feedback loop because developers will end up submitting less bugs because of this lack of communication.
Craig said that they aren't where they want to be with the "external interface" of Radar. They use Radar heavily internally but they face challenges with Radar and the general public.
He expressed that the Radars are read, but then the process is usually that they are duped with some internal Radar issue. Then they struggle with how to externally communicate what release a particular bug will be fixed in, or to make particular promises about certain bugs, etc.
But he reiterated that they had really fallen short on providing a good tool with feedback for the general public.
Re: Rationales for Swift standard library designs
#7Earlier quoted context omitted.
What did they say?
Gruber brought up how in Apple Maps, if you suggest a correction, you are eventually informed when the fix is made. However, with Radar, it is just a blackhole. You file your report and an awful lot of bugs, no matter how well written or even if they have example code, they will never hear back again about it. He said that this was a negative feedback loop because developers will end up submitting less bugs because o…
It's bad, but not quite a black hole. I have had the occasional feedback out of it, of the limited form "this should be fixed in the release that just came out. Please retest"
Re: Rationales for Swift standard library designs
#8Earlier quoted context omitted.
Gruber brought up how in Apple Maps, if you suggest a correction, you are eventually informed when the fix is made. However, with Radar, it is just a blackhole. You file your report and an awful lot of bugs, no matter how well written or even if they have example code, they will never hear back again about it. He said that this was a negative feedback loop because developers will end up submitting less bugs because o…
It's bad, but not quite a black hole. I have had the occasional feedback out of it, of the limited form "this should be fixed in the release that just came out. Please retest"
I enjoy the "duplicate, closed" that never gets fixed.
Re: Rationales for Swift standard library designs
#9Earlier quoted context omitted.
What did they say?
Gruber brought up how in Apple Maps, if you suggest a correction, you are eventually informed when the fix is made. However, with Radar, it is just a blackhole. You file your report and an awful lot of bugs, no matter how well written or even if they have example code, they will never hear back again about it. He said that this was a negative feedback loop because developers will end up submitting less bugs because o…
Well, perhaps they could start by looking at a feature of their own OS, introduced by Federighi himself (yet nothing new regardless): Tags.
If they simply started tagging things internally in some way that associates issues with external things like bug numbers and release numbers, they would have a start toward communication with the outside of the company.
Re: Rationales for Swift standard library designs
#10Earlier quoted context omitted.
What did they say?
Gruber brought up how in Apple Maps, if you suggest a correction, you are eventually informed when the fix is made. However, with Radar, it is just a blackhole. You file your report and an awful lot of bugs, no matter how well written or even if they have example code, they will never hear back again about it. He said that this was a negative feedback loop because developers will end up submitting less bugs because o…
Thanks! I'm glad they're aware of the trouble. I just hope they don't "fix" it worse like with that big UI revision they did a few years back.