Hacker News new | past | comments | ask | show | jobs | submit login
Rationales for Swift standard library designs (github.com/apple)
39 points by acire on March 15, 2016 | hide | past | favorite | 12 comments



Yay, 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?


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.


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.


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.


Trouble is, that "please retest" message is boilerplate that's often sent out regardless of whether any work is done in the offending area.


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.


I 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=...


It's telling of Swift that Apple feels a need to defend the many weird things they did with it.


I don't follow—what does it tell? That it does in fact have weird things in it? Or that some of the weird things aren't accidental?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: