Archive for May 17, 2016

Tuesday, May 17, 2016

ABI Stability Deferred Until After Swift 3.0

Erica Sadun quotes Chris Lattner:

That said, it is also clear at this point that some of the loftier goals that we started out with aren’t going to fit into the release [Swift 3.0] – including some of the most important generics features needed in order to lock down the ABI of the standard library. As such, the generics and ABI stability goals will roll into a future release of Swift, where I expect them to be the highest priority features to get done.

Jeremy Pereira:

Compare the Swift-Evolution goals for Swift 3 to how they were before Chris changed them. They used to be Stable ABI; Resilience; Portability; type system clean up and documentation; complete generics; focus and refine the language; API design guidelines. Only two of those goals will be met – the last two.

Judged by its original goals, the Swift 3 release is a failure. Clearly we lost focus on what we were trying to achieve and we need to understand why. Unfortunately, Chris’s relocation of the goalposts is likely to obscure the fact of the failure and probably the same mistakes will be repeated for Swift 4.

I’m not worried because (a) I see a lot of the stuff that went into Swift 3 as more important than the stable ABI, and (b) I really want them to take the time to get Resilience right. ABI stability doesn’t affect app developers that much. The main issue is that it means you have to build from source, so you can’t include (Swift) libraries that were compiled by someone else, but I don’t see that as a common problem.

Update (2016-05-18): Greg Parker:

If we tried to rush Swift ABI stability out the door for Swift 3 we would certainly end up with deliberate or accidental flaws like the above. Being able to take the time to get it right is a rare luxury.

Erica Sadun:

The move to Swift 3.0 isn’t just going to be disruptive. It’s going to be traumatic. With its expansive renamification and redesigned core types and APIs, Swift 3 is going to be a tidal wave of retraining and refactoring. And with a list of objectives that didn’t quite make the cut, and a laundry list of of items that should have, Swift 3 just doesn’t have enough time or scope to be perfected.

So why not just push it back? Let us devs use Swift 2.2, which is terrific, for a few more years and get Swift 3 right the first time?

[…]

These arbitrary “update every year” advances that Apple has bought into are more than a little ridiculous when it comes to firmware and OS updates; for languages it pushes beyond the practical.

This is why I thought it was good to get the major source-breaking changes into Swift 3 at the expense of ABI stability. However, it remains to be seen whether that goal can be reached on schedule.

Update (2016-05-23): Joe Groff:

A late ABI is only late until it’s finished; a bad ABI is bad forever.

Ben Snider:

So while ABI compatibility might seem like a big deal to have been pushed off, it very likely doesn’t affect the day to day of most Swift developers.

The most compelling arguments thus far have been around the fact that some developers would like to distribute libraries in binary form so as to protect intellectual property, license agreements, etc. Not having ABI compatibility is actually a legitimate concern for developers wishing to distribute binary libraries, but I don’t really feel like that’s a very large number of developers.

[…]

Which leads to the second major concern: that Swift compile times are a) slow, b) unlikely to get much faster and c) will only get slower as projects increase in size and complexity. Having some libraries built as binary libraries that are simply linked with additional Swift sources would likely result in much faster build and test cycles.

Language Design Programming Swift Programming Language

7 Comments

Twitter to Stop Counting Photos and Links in 140-Character Limit

Sarah Frier (via Dan Moren):

The change could happen in the next two weeks, said the person who asked not to be named because the decision isn’t yet public. Links currently take up 23 characters, even after Twitter automatically shortens them. The company declined to comment.

It’s a step in a larger plan to give users more flexibility on the site. Chief Executive Officer Jack Dorsey said in January that the company was looking for new ways to display text on Twitter, and would experiment based on how people use the service. For example, some people tweet screenshots of longer text in articles, or send many tweets one after the other to tell a story.

Bravo.

Nick Heer:

Strangely absent from this scoop: any mention of also discounting @-replies and user handles. Sometimes, discussions can become deeply nested with many participants, and the character count can impede the discussion, particularly if it involves people with longer handles.

Previously: Twitter Removes 140-Character Limit From Direct Messages, Twitter Won’t Raise 140-Character Limit.

Update (2016-05-26): Twitter:

In the coming months we’ll make changes to simplify Tweets including what counts toward your 140 characters, so for instance, @names in replies and media attachments (like photos, GIFs, videos, and polls) will no longer “use up” valuable characters.

Michael Rockwell:

I’ve seen a lot of outrage in my timeline since this announcement — all of it directed toward the changes to mentions. Users don’t want cluttered timelines and I completely understand that complaint. But I think you’ll be surprised at how few tweets that start with a username are initiated without the reply button — I don’t think Twitter would have made this change if that wasn’t the case.

[…]

That “ceiling of 50 names” only matters specifically for replies. In order for usernames not to count toward your 140-characters, you’d have to reply to a thread that included 50 other users. It’s not as if spammers could just add 50 arbitrary names to a tweet and send it out without restriction.

Update (2017-01-23): David Heinemeier Hansson:

It’s been 8 months since Twitter announced links wouldn’t count against 140 limit. They still do. Oy.

Twitter

1 Comment

iTunes 12.4

Kirk McElhearn:

When I reviewed iTunes 12 back in late 2014, I said, “Overall, I find the navigation confusing—it requires too many clicks to get around.” I find the changes Apple has wrought to the interface of iTunes 12.4 to be both positive and intuitive, and I think all users will find these new ways of navigation to be more efficient, once they get used to them.

Navigating iTunes is now—or, again—centered on the sidebar and a single menu in the navigation bar. (You can show or hide the sidebar in the View menu.) Instead of a lot of confusing media kind buttons in the navigation bar, there is now a popup menu that Apple calls the Media Picker. Click it to choose a media library, edit the Media Picker menu, or mount another iTunes library with Home Sharing.

[…]

Apple has thankfully merged the two different types of contextual menus, in most locations. Instead of one menu displaying when you click the ... button, and another when you right-click an item, the menus are the same, and work in the same way.

Kirk McElhearn:

But there are a lot of little changes I’ve spotted in the latest version of iTunes. Here are some of them[…]

Doug Adams:

Apple released iTunes 12.4 today. It features a significant UI change as well as updates under the hood. And AppleScript additions!

Benjamin Mayo:

The sidebar is a resurrection from the days of iTunes 11. I like the sidebar better than the transient popover (OS X has enough screen real estate to allow such affordances) but it hasn’t been thought through. It’s shoddy and incomplete. There are distinct sidebar sources for Albums and Compilations and yet selecting Albums still shows Compilations in the detail view when you scroll down. Some media types do not hide the sidebar but have no sidebar items to choose between (Podcasts). Many media views have no sidebar at all, leading to jarring transitions between tabs, including all of Apple Music.