Erik Eckstein:
We have seen that using -Osize reduces code size from 5% to even 30% for some projects.
But what about performance? This completely depends on the project. For most applications the performance hit with -Osize will be negligible, i.e. below 5%. But for performance sensitive code -O might still be the better choice.
[…]
But in contrast to -O, the compiler tries to avoid code duplication. For example, when inlining functions the compiler uses a lower size limit to decide whether a function should be inlined.
Compiler Optimization Programming Swift Programming Language
Tom Quisel (via Hacker News):
There could be two different interpretations for the question, and you just answered one of them. Then the population is evenly split on a question not because people feel strongly about the answer, but because they have different interpretations of the question. Knowing this can happen, we use the algorithms to help us understand the statistics behind each question, and we’ll try to identify questions that are the most likely to be mistaken in this way so that we can remove them.
We also examined messaging patterns as a backup, and correlated answers to other questions. So if the question is an outlier compared to many other questions, we’ll tend to count it less; or if messaging patterns don’t line up with answers to the question, we would sometimes use that as a reason to remove the question as well.
[…]
One change we debated quite a bit was our rating system. Originally we had a rating system that allowed people to score other people from one to five stars. And we thought, well, it would be a simpler user interface to just use a yes or no answer. That would be more straightforward, but then again we would lose a lot of information resolution, and was that really worth it? We were pretty torn on it, and couldn’t come to a decision through discussion alone, so we resorted to an experiment to understand which would lead to better messaging patterns.
[…]
The ethics around experimentation really depends on what you’re trying to accomplish with the question. The goal should be improving the product for people, and you should focus on not degrading the experience very much for any one person—don’t hurt someone too much for the experiment.
Design OkCupid Web
Dave DeLong:
If you’re adopting a protocol (especially one from the standard library), the tools don’t provide any help whatsoever in knowing what you actually have to implement.
[…]
Basically any time you find yourself using a PAT, you know that you’re either going to have to create a type eraser, or you’re going to have to make things generic that have no business being generic.
[…]
I wish the compiler generated type erasers for me.
[…]
I wish I could provide default implementations of protocol methods that assign to self.
[…]
I wish I could extend a protocol to conform to another protocol.
Previously: Swift Protocols With Associated Types, Swift Type Erasure, Patterns for Working With Associated Types.
Update (2018-03-05): See also: Swift Unwrapped.
Update (2018-07-27): Dave DeLong (tweet):
What I really want to do is this:
protocol Predicate<Element> {
func contains(_ other: Element) -> Bool
func union(_ other: Predicate<Element>) -> Predicate<Element>
}
Of course, the compiler doesn't let me do this.
I want to express the idea that union() can take any Predicate-conforming value with the same element type, and you're going to get back some sort of Predicate-conforming value that contains elements of that type.
Then in specific situations where I can provide a much more efficient implementation (like the IndexSet + IndexSet = IndexSet scenario), I want to provide those explicit overrides for that method, and otherwise default back to the implementations I provide in my protocol extension (which happen to return an OrPredicate<Int>)
Brent Royal-Gordon:
What I think you actually want here is the generalized existential feature. “Generalized existential” is a ten-dollar term for a ten-cent idea: “Swift should have built-in type-erasing wrappers for PATs, much like it has them for ordinary protocols.” Their syntax might be slightly different—they’d probably use a where clause instead of a generic parameter list—but they would do the thing you want to do here.
Language Design Programming Swift Programming Language
Josh (via Joe Groff):
First, we gathered market research data about Windows 3.1 users’ twenty most-frequent tasks. We then conducted several lab studies comparing Windows 3.1 and Windows 95, focusing on the top twenty tasks derived from the market research data. We also interviewed professional Windows 3.1 (and Macintosh, for comparison) educators, to learn what they found easy and difficult to teach about the operating system.
[…]
Although we had opted for an iterative design approach from the beginning, one legacy of the waterfall design approach remained: the monolithic design specification (“spec”). During the first few months of the project, the spec had grown by leaps and bounds and reflected hundreds of person-hours of effort. However, due to the problems we found via user testing, the design documented in the spec was suddenly out of date. The team faced a major decision: spend weeks changing the spec to reflect the new ideas and lose valuable time for iterating or stop updating the spec and let the prototypes and code serve as a “living” spec.
After some debate, the team decided to take the latter approach. While this change made it somewhat more difficult for outside groups to keep track of what we were doing, it allowed us to iterate at top speed. The change also had an unexpected effect: it brought the whole team closer together because much of the spec existed in conversations and on white boards in people’s offices. Many “hallway” conversations ensued and continued for the duration of the project.
[…]
Although we abandoned the idea of a separate shell for beginners, we salvaged its most useful features: single-click access, high visibility, and menu-based interaction. We mocked up a number of representations in Visual Basic and tested them with users of all experience levels, not just beginners, because we knew that the design solution would need to work well for users of varying experience levels. Figure 5 shows the final Start Menu, with the Programs sub-menu open. The final Start Menu integrated functions other than starting programs, to give users a single-button home base in the UI.
Design History Windows
Google:
Promises is a modern framework that provides a synchronization construct for Swift and Objective-C.
Google (via Peter Steinberger):
Functional operators for Objective-C: An Objective-C library of functional operators, derived from Swift.Sequence, that help you write more concise and readable code for collection transformations. Foundation collections supported include: NSArray, NSDictionary, NSOrderedSet, and NSSet.
Update (2018-03-01): Gianluca Bertani:
On the same domain, Opinionated-C looks way better[…]
Cocoa Google iOS Mac Objective-C Open Source Programming Swift Programming Language
