My Results Were Inconclusive
Marco:
john did anything bad happen in the last week and did like the world end or did any other negativity or horrible result happen in the last week i'm sure horrible things happened everywhere in the last week well did anything happen like to our show that was really horrible oh i don't think so oh okay uh because uh what was missing from last episode
John:
The song was there.
John:
Did you forget the modem thing in the beginning?
Marco:
No.
Marco:
John, John, John.
Marco:
Show notes?
Marco:
Nope, that was there too.
Marco:
Keep trying.
Marco:
What was just completely missing from last episode?
John:
Any mention of the thing that I was most excited about at WWDC?
Marco:
No, no.
John:
Are you talking about like the release show?
John:
Like the production process has fallen down?
John:
Oh my God, John.
Casey:
How have I figured this out and you haven't?
John:
I don't know.
John:
I just listened to the most recent episode.
John:
It had a song.
John:
I guess it had the modem beep.
John:
Did it have the ending noise?
Casey:
Yeah.
Casey:
We'll just sit here patiently.
John:
I don't know.
John:
All the ads?
Marco:
No, those are there too.
Marco:
All right, well, I guess we should do something up front in the show.
Marco:
Oh, because you didn't have follow-up for a WWDC show.
John:
We never do.
John:
We never have follow-up at a WWDC show.
John:
Because we always have so much to talk about.
John:
We haven't had it on any of the WWDC shows.
John:
Like, where would I get it from?
John:
Especially when we were live.
John:
I don't have notes in front of me.
John:
Oh, come now, John.
John:
We always have something to follow up on.
John:
Did we when we were in Macworld last year?
John:
No, I don't think so.
John:
Someone can look it up and see.
John:
But, like, certainly I didn't have a laptop in front of me, right?
John:
No, you just had a tremendous wallet.
John:
No, I mean, like, last year at the Macworld studio.
Casey:
Yeah, you still had a tremendous wallet.
Casey:
I'm quite sure.
John:
I don't know.
John:
Might not have been with me.
Casey:
Hey, speaking of wallets, and now we can segue into the follow-up that Marco's trying to avoid...
Casey:
We all went to dinner at our dear friend Jason Snell's house, and we left that house.
Casey:
We left Jason's house and got onto the interstate highway, freeway, whatever California calls it.
Casey:
And then you had an epiphany, John.
Casey:
Would you like to tell us what that epiphany was?
John:
I left my backpack at Jason's house.
Casey:
And somebody pointed out to me, I genuinely don't remember who it was, and so I'm sorry to whomever that is, that at two minutes, excuse me, two hours, two minutes and 45 seconds, you explained to us in the last episode how you would never lose your backpack.
John:
Did I lose my backpack?
Casey:
Briefly, yes, because you said you had no idea.
Casey:
Was it lost?
Casey:
Define lost.
Casey:
You didn't know where it was within Jason's house.
John:
I did know where it was.
John:
It was at Jason's house.
John:
Was I correct in believing it was at Jason's house?
John:
Yes, I was.
John:
Did I ever wonder where it was?
John:
No, I did not.
John:
I think you did briefly.
John:
No, I knew it was at Jason's house.
Casey:
So anyway, I just thought that was very funny that that it turns out that after declaring authoritatively that you would never.
Casey:
OK, yes, you said lose, but but I will take it.
Casey:
You will never leave.
John:
You mean you'll you will take it by changing the word that I said to a word that makes you right.
John:
And you will bask in that.
John:
Imagine the glory.
Casey:
This is the Internet.
Casey:
This is how these things work.
John:
Anyway, I did not lose my back.
John:
Even if I had got all the way back to the city, I would still have known exactly where it was.
Casey:
That is true.
John:
That is true.
Marco:
but jason is a slightly more trustworthy than the average citizens of san francisco well but you know i i think the the big picture here the lesson here is that had you owned a wallet that would fit in your pocket you probably wouldn't have brought a backpack to this dinner uh and it therefore it wouldn't have been a problem and it wouldn't have uh i probably would have bought it anyway i don't go anywhere it's like the towel another reference you don't get don't go anywhere without a hitchhiker's guide to the galaxy
John:
Hey, Casey read a book.
John:
All right.
John:
Anyway, yeah, I'm like that with the backpack.
John:
Even if it's just for like the little battery pack I have in there to recharge my phone.
John:
You never know.
John:
How big is the battery pack?
John:
I used to charge you.
John:
It's a little tiny Duracell thing, you know, but I got lots of crap in there.
John:
I think I even have my iPad in there.
John:
I don't remember.
Marco:
Honestly, I'm not trying to make fun of you here.
Marco:
Do you keep anything in your pants pockets?
John:
My phone.
John:
I mean, I tried... The 6 is a little bit big to have in my pocket, but...
John:
generally you know my phone is on me and it's in my front pocket i don't like to sit down a lot with it in my front pocket like when i get in the car i tend to well it's bluetooth i take it out and put it in the little cubby thing for bluetooth thing in the car but yeah basically my phone i guess my keys if i i don't know yeah my keys if i'm going like if i go to the store i'm not bringing my backpack with me right so my wallet has to go in my pocket when i go to the store or something but that's not a usual
John:
thing but wwc is a different different experience i'm uh it's like uh going out into space you got to get your space suit on i could see some of that yeah i can understand that but anyway i don't know why you're arguing with this like i agree i need a thinner wallet uh and i thank everyone who has sent me all the suggestions for thin wallets and now i feel slightly overwhelmed by the million possible choices the only thing i know is i don't want one that makes your money visible on the outside because that makes me uncomfortable
Casey:
Yeah, that's why I like the one that I have, which is a Ubi wallet, Y-U-B-I.
John:
You said it's discontinued.
Casey:
Yeah, and that's the thing is after we talked, I was like, you know what, I should go ahead and order a new one because some of the elastic after the last couple of years has kind of fallen off or whatever.
Casey:
And it was originally a Kickstarter.
Casey:
Then I believe it was either an individual or a company that...
Casey:
um was selling it you know outside of kickstarter and i went looking to try to find it and i could not find it anymore and i'm really bummed about that because part of the beauty of the yubi was that you had cards on either side of the wallet and then there was like a little cubby if you will it's a terrible description but a little slot where you could stick bills and it was i i thought it was really clever and i really liked it and um
Casey:
So now I'm going to have to figure out what you buy, John, and buy one of those for myself because I don't know what to do now.
Casey:
I can't get another Yubi.
John:
There are a lot of choices, though.
John:
Seriously, it's overwhelming how many.
John:
This is not a new trend, the slim wallet thing, but there's a million of them, and everybody loves the one they have.
John:
And I look at them all, and I'm like, they all look very similar.
John:
I feel like it's something I need to see in person.
John:
It'll be difficult to buy online just by looking at pictures.
John:
You've got to kind of feel it, how squishy it is, how bendy it is.
John:
how big it really is, how nicely the credit cards fit in and stuff like that.
Marco:
Yeah, I don't know.
Marco:
I personally can very... I'm very happy with my Slimmy wallet by a company called Koyono.
Marco:
Don't call it Slimmy.
Marco:
Nope, it's a Slimmy.
Marco:
It's black outside with red inside.
Marco:
It looks really cool.
Marco:
And it's relatively inexpensive.
Marco:
I guess right now they're selling it for $45.
Marco:
And it's really nice.
Marco:
I've been using it now for something like four or five years.
Casey:
Yeah, but this is a non-starter for me, though, because it's a front pocket wallet, and that's just barbaric.
John:
What makes it a front pocket wallet?
John:
You can keep it in any pocket.
Casey:
It says in the URL, slimmy minimal front pocket wallet.
John:
Yeah, but what makes it?
John:
Other than the words, what makes it a front pocket wallet?
John:
It doesn't have one of those weird curves in it or anything.
John:
It's still a rectangle.
John:
If you put it in your back pocket, it will have one of those curves.
John:
That's true.
John:
Like Casey's Field Notes.
John:
That's very true.
Casey:
Anyway, I'm giving you a hard time about the backpack thing.
Casey:
Just out of fun, I am already envisioning all the emails I'm getting about how wrong I am and how right you are.
Casey:
Because anytime anyone doubts you, John, the internet comes to your defense.
Marco:
I'm sorry to ruin your fun with facts.
Marco:
Ultimately, though, the wallet is not your problem.
Marco:
It's the contents of the wallet.
Marco:
You have to fix yourself before you can fix the wallet.
John:
Obviously, you know...
John:
Taking stuff out of my wallet now will only help so much because it is a very large wallet.
John:
So obviously, if I got a slim wallet, not everything would make it from the old wallet to the new one, clearly, right?
Casey:
Yep.
Casey:
That's true.
Casey:
All right.
Casey:
Well, anyways, what else?
Casey:
Oh, the entire internet wrote to tell us, and we observed ourselves at WWDC, that the Notes app, as written by Apple, the back end is now indeed iCloud.
Casey:
It is no longer IMAP.
John:
um thank you to the entirety of the internet for uh for letting us know that because that is the case and there's a one-time porting of your data like kind of like what do they do with that in uh in yosemite like you uh maybe it was icloud photo library i don't know something else anyway you're talking about the the documents move to icloud drive oh yeah yeah when they change the storage the document you know there's a one-time operation we say are you ready to move everything over to the new system once you do that you have two sets of information one visible on the pre uh
John:
El Capitan systems and one visible in the post and they're divorced after that.
John:
And anyway, so I'm very happy to hear that it's not IMAP.
Marco:
And specifically, in case you said iCloud, specifically it's CloudKit, which is worth noting because iCloud as an umbrella term has a fairly mixed reliability history because some of the parts of it were not that great, like the core data sync or the original document store.
Marco:
A lot of people had problems with those.
Marco:
Whereas CloudKit-based things, including the new Photos app and a lot of apps written since last year, tend to be pretty well regarded.
Marco:
I don't think anybody has really had major problems with CloudKit so far.
Marco:
And even like any issues people have had with the Photos app seem to be related to the locally running code in the app itself, not the cloud backend, which seems pretty solid.
John:
That's another follow-up item.
John:
I'm pretty sure I said this to you in person and not on a podcast.
John:
This is the problem about seeing each other in person.
John:
Talking about my experience using photos on the MacBook One and the Apple Store.
Marco:
How did it go?
John:
Yeah, so I went to the Apple Store finally to see the MacBook One and try the keyboard.
John:
I'm not going to talk about the keyboard now.
John:
Maybe we'll save that for later.
John:
The short answer on the keyboard is my results were inconclusive.
John:
Anyway...
John:
it also had photos on it i was trying to make the thing heat up like oh it's fanless blah blah can i do something to make this heat up and i immediately thought of you running the new photos app surely that will make it heat up it will grind away when it launches and everything like that uh and the macbook one has a very wimpy cpu i haven't looked at the specs but i'm going to guess that it's
John:
probably in the same ballpark as my mac pro like maybe even slower possibly it might i mean in parallel tasks it's almost certainly slower um in single threaded it it's roughly equivalent to like a i think it was like a 2011 era macbook air cpu right and that's what we have here we actually do run photos on the our 2011 air that's back there i can hear the fans whirring now because it's doing some backup stuff
John:
and i wanted to try it out uh to heat up the the macbook one and i was shocked by how incredibly fast and responsive everything was on that macbook one using photos i did all my normal stuff it launched fairly quickly i went through photos i selected them my favorite of them i added keywords i added keywords to big selections of things like everything was instant
John:
And the only thing I can think of is their photo library was, of course, like 2,000 photos and mine is 60,000.
John:
And the MacBook One, does it have 8 gigs of RAM?
John:
Yes.
John:
And it has twice the RAM.
John:
So I still don't quite know exactly what it is about my 2011 MacBook Air that is so brutalized.
John:
My best guess now is...
John:
like you know i imported from my photo so i imported from my photo i assuming it shoved all the metadata into whatever it's using probably maybe a sqlite database or something maybe all the operations i'm doing cause a database operation that takes a ton of time because my database is stuffed with everything and if i took all these photos out and re-imported them fresh with no metadata it would be fast i don't know
John:
Uh, I'm not excusing the photos app because like I basically did exactly what Apple expected me to do.
John:
I bought their program.
John:
I use it to store my family photos for years.
John:
The new one came out.
John:
I did the import process and imported my photos and everything is super duper slow.
John:
Uh, so I'm, I'm disappointed, but I have some amount of hope seeing that it's, it's obviously not CPU related.
John:
I, I can't tell if it's Ram related.
John:
I'm hoping somehow things get faster in a future version because the experience of using photos when everything is fast is actually not horrible.
Casey:
Excellent.
Casey:
The other piece of follow-up we have, and then I think we're done, is the keyboard trackpad thing on iOS 9.
Casey:
Is there a name for that?
John:
Swipe not to type?
John:
I don't know.
Casey:
I think it was called QuickType.
Casey:
Well, whatever it's called, whatever that thing is, it apparently does work on not only the 6 Plus in the iOS 9 beta, but interestingly, the 6 as well.
Casey:
Serenity Caldwell, friend of the show, has a 6 that she put iOS 9 on, and it was working on her phone as well, which was slightly surprising to me.
Casey:
Not a bad thing, of course, but a little surprising.
Casey:
So we should point that out as well.
Casey:
Are you guys running iOS 9 on your carry phones?
Marco:
no who would do that uh apparently serenity some people do that actually some people have to do it for a living we don't three or four years ago i probably would have done that but no this year i i have it on my ipad which i hardly ever use and it keeps i keep coming back to it every couple of days to do something on it and the battery is just completely dead
Casey:
My experience on my beloved RetinaPad mini, hi, Stephen Hackett, is not quite that bad, but it is certainly very slow.
Casey:
It is certainly randomly rebooting.
Casey:
And I know that because it says when you reboot, you have to enter your passcode once you reboot, blah, blah, blah.
Casey:
And it definitely is not getting the battery life I'm used to it getting.
Casey:
However, I do like it.
Casey:
And I did use picture in picture when I was on the plane back from San Francisco.
Casey:
I was watching the complications video while doing something else.
Casey:
I don't recall specifically what.
Casey:
And the picture-in-picture, even on my now almost two-year-old iPad mini, was really, really cool.
Casey:
And it worked reasonably well.
Casey:
The only problem is it only works, as with all these new hotness features, it only works with Apple apps, or at least that's been my experience so far.
Casey:
But all in all, two thumbs up in principle for iOS 9, one thumb up for the beta so far.
Marco:
Our first sponsor this week is Automatic.
Marco:
Automatic is a connected car adapter that plugs into your car's diagnostic port.
Marco:
And then they have smartphone apps that you can then do cool stuff with this.
Marco:
And it integrates with over 20 different apps to give you a better driving experience.
Marco:
They've sponsored us before.
Marco:
There's a bunch of new stuff since then.
Marco:
So what it's always been able to do is you pair it with the automatic iPhone or Android app.
Marco:
And then it can do a few cool things.
Marco:
It can diagnose your check engine light.
Marco:
It can tell you...
Marco:
In plain English, what's going on?
Marco:
It lets you clear the error code if it's a temporary error, like you left your gas cap open or something like that.
Marco:
It can give you a log of your trips and your parking locations so you can track things like your fuel efficiency.
Marco:
You can never lose your car in a parking lot.
Marco:
If you have an accident, it can automatically call emergency services for you to help get you the help that you might need.
Marco:
And then it can also evaluate your driving efficiency.
Marco:
It gives you a score.
Marco:
You can match your goals so that you can save money on gas.
Marco:
This can really add up to big savings over time.
Marco:
Now, they actually launched their own little app store for the car.
Marco:
They have over 20 apps available, and this allows you to use your car's data in all kinds of ways.
Marco:
So just a few examples here.
Marco:
They have an app called Concur, which lets you pull your trips easily into your expense reports.
Marco:
So if you work at a company, Casey, you might have to do things like this.
Marco:
They also have integration with If This Then That, IFTTT, which gives you the power to build all kinds of recipes based on your driving.
Marco:
Recipes, of course, is an IFTTT term for various workflows and triggers and various things you can do based on certain events or stats that happen while you are driving.
Marco:
They also have a developer platform so that you, you developers, can build apps using the car's data as well.
Marco:
There's three levels of data available for developers.
Marco:
There's a REST API, a real-time events API, and a streaming SDK.
Marco:
The REST API is very, very full-featured.
Marco:
You can request driver's trip histories, distance, routes, times, locations, miles per gallon, and then you can even quickly launch your app on Heroku, Casey.
Marco:
You can use your dinosaurs or whatever and make that work.
Marco:
Anyway, go to developers.automatic.com to learn more about that.
Marco:
So anyway, back to automatic the device.
Marco:
Check it out, whether you're a developer or not.
Marco:
If you are a developer, this is a pretty cool way to do new stuff that you can't really do without something like this.
Marco:
If you're not a developer, check it out to help improve your driving and to give you all the cool features to maybe to use some of these cool apps, use some of the APIs, use some of the triggers, or just look at your metrics and get your measurements or check your engine light, stuff like that.
Marco:
Very cool stuff.
Marco:
Normally, this is 100 bucks.
Marco:
But for us, it's 20% off automatic.com slash ATP.
Marco:
That's automatic.com slash ATP for 20% off brings it to just 80 bucks.
Marco:
That's free shipping and just two business days, 45 day return policy.
Marco:
And there is no subscription fee per month.
Marco:
You don't have to pay like, you know, five bucks a month for the service or whatever.
Marco:
No, you buy the, you buy the automatic device upfront for 80 bucks with our coupon code automatic.com slash ATP, 80 bucks upfront.
Marco:
And then that's it.
Marco:
No monthly fee.
Marco:
Ships to you in two business days.
Marco:
Check it out.
Marco:
Automatic.com slash ATP.
Marco:
Thanks a lot.
Casey:
All right.
Casey:
So we should probably talk a little more about what was released and discussed at WWDC to the best of our ability.
Casey:
I don't know what is and what isn't ND8 anymore.
Casey:
As far as I know, nothing's ND8, right?
John:
You can download all the WWDC videos without logging into Apple's website.
John:
So I think we could talk about anything that is in the WWDC videos.
Casey:
Excellent.
Casey:
So with that in mind, let's talk a little bit about the State of the Union and some of the stuff that's been making the rounds over the last couple of days in the really nerdy developer circles, specifically around bit code.
Casey:
So, John, do you want to kind of give us an overview as to what this is?
John:
Uh, first, like after we recorded our episode of WWDC, I realized that we didn't talk about BitCode.
John:
I'm like, oh my God, did I totally space on that?
John:
Did I forget because we didn't have any notes and I was just sitting there?
John:
And no, because we said we were going to cover the keynote and we went through the keynote and BitCode was not in the keynote.
John:
Uh, so that in itself is interesting that what, uh, this is what I was referring to before the, the announcement that I was most excited and intrigued about at WWDC was bit code and state of the union.
John:
And for the rest of the week, like, boy, I can't wait to learn more about bit code in the sessions.
John:
And I, you know, obviously you can't go to all the sessions cause it's a multi-track conference.
John:
I didn't go to all the sessions.
John:
None of the sessions I went to mentioned the word bit code.
John:
Nor, I believe, did any of them have the word on a slide.
John:
I later found out from someone tweeting screenshots that the app thinning session that I did go to previously had bitcode in the description of the session and that was later removed.
John:
And having gone to the session, I don't think bitcode was mentioned there either.
John:
so that didn't tell me much of a bit code but uh the reason i was excited by it is in the state of the union a video that we will link in the show notes because everybody can download it and you don't have to you know log in or anything was that it was going to be a way to have a processor agnostic platform agnostic or slightly more agnostic representation of your application that would be optimized for the specific platform that it's downloaded for
John:
uh and this was an intriguing announcement because it freaked developers out and because it is great fodder for uh speculation about rumors right now when you submit an app to the app store you compile it you build a release build you upload it in some what is it like is it's all through xcode right i don't i've never actually done this so i don't know marco
Marco:
The regular way to do it is now, it used to be like build an IPA, zip it up, upload it through a terrible web interface.
Marco:
Now you leave the terrible web interface to go to Xcode to prepare the upload and do it off there.
Marco:
There's probably a way to do it without that.
Marco:
There's probably some kind of like advanced enterprise tool.
Marco:
Yeah, but the way almost everyone does it is through Xcode.
John:
But anyway, it does a release build with all your optimizations enabled and it uploads the result to Apple.
John:
And that is, you know, obviously it's signed by Apple and they do some other things with it.
John:
But in general, there's the expectation that the thing you built on your machine, especially for Mac apps where it's like literally running on the thing, like it's not, you know, maybe less so for iOS apps where you're always running into the simulator and then you do the release build and you're running that on your device or whatever.
John:
But anyway...
John:
The expectation is the binary that you have made and tested is going to be the binary that lands on people's computers, and that binary is a compiled binary targeting a specific architecture.
John:
You can make it for x86-64.
John:
You can make it for ARM7, ARM7S.
John:
There's all sorts of processors you can target that limit the hardware you can go on, but the bottom line is you are creating a native binary executable
John:
that can run in ios or os 10 exactly as it is and if you were to do an md5 checks on well maybe not for the signing i i don't know i i'm trying to express the idea that like the thing that you debugged on your device you make a release build put it on your device and you use it that's the same code that's going to be executing on somebody else's device uh when they download the app from the store but bitcode is saying we're going to build something that is not native code for any processor
John:
And that's what we're going to have on the store.
John:
And at some point in the future, I assume at the point of download, but it really could be almost any time, that code will be converted to native code that is specifically optimized for whatever it happens to be running on.
John:
uh bitcode itself is not new as part of llvm since i think version two previously i think they called it bytecode i don't know if it ever was bytecode or just differences how the stream format is made but either way it's just a binary compact binary representation of llvm ir which is the intermediary representation
John:
And boy, there's a lot of acronyms for explaining.
John:
LLVM originally was an acronym that stood for low-level virtual machine.
John:
Now LLVM encompasses a much larger project.
John:
That's kind of a misnomer at this point.
John:
But LLVM IR really is kind of assembly code for an imaginary processor with some vaguely idealized characteristics.
John:
I guess we'll link to my Swift thing.
John:
I think I talk about LLVM IR in there.
John:
So BitCode is just LLVM IR, but instead of looking like text, it is a compact representation.
John:
If you can think of compiling your code, starting from source code, and it being transformed several times until it eventually ends up at a binary, LLVMIR is slightly before it's changed into machine code.
John:
So they're saying, we're going to turn your program into LLVMIR and code that LLVMIR as bitcode, and that's what we'll have on the store.
John:
And when someone...
John:
Again, we don't know when this is going to take place.
John:
I assume it's on download, but you could take that bitcode and download it to everyone's device, and when they run it, it could be compiled just in time for their particular architecture.
John:
I assume they're going to do it when you download it.
John:
So that's the technical...
John:
just of what they're doing here.
John:
Again, they didn't talk a lot about it, so we don't know when this is all going to take place.
John:
Bitcode is, I'm going from memory here, mandatory for native WatchKit apps, is that correct?
John:
I believe that's right.
John:
And it said optional for iOS apps for now.
John:
Yeah, and it didn't say anything about the Mac, but I mean...
John:
There is nothing technical that makes BitCode not able to work on the Mac or that means it would have to be mandatory in the watch.
John:
These are policy decisions.
John:
But why is it mandatory in the watch?
John:
Well, that's the newest platform.
John:
Nobody has made a native app for the watch except for Apple.
John:
So it's not like it's a big change to say, look, this is just the way it is in the watch.
John:
You're going to submit BitCode, right?
John:
Your release bills are going to upload BitCode to us and then everyone else who gets it is going to get a
John:
a executable binary optimized for the particular piece of hardware they have it on uh so when they made this announcement in the keynote i made a bunch of uh silly tweets about uh how this uh you know could the the obvious rumors to people are going to say is oh my god this means r max because
John:
if you're trying to change the application representation to be this thing that's not specific to any one processor, and then you optimize it on the fly, then you could change the processor architecture at any time, right?
John:
And then you would just recompile this bitcode for the new architecture.
John:
So if they got everyone onto bitcode and they changed to ARM Macs, developers wouldn't even need to rebuild their apps and resubmit, and you wouldn't need to have fat binaries.
John:
It would just be everything is bitcode, and then you download it to your ARM Mac, and it turns it into an ARM executable, and you download it to your x86 Mac, turns it into an x86 executable.
John:
That is the immediate fantasy rumor when people hear about bitcode.
John:
Unfortunately, as fun as that would be to speculate about, that's not really how LLVM IR and bitcode work.
John:
LLVM IR, although it is kind of imaginary assembler for an imaginary processor, it has things in it that are specific to an instruction set or an architecture.
John:
uh it's not completely pinned down but it's it's not the type of thing where uh i think you brought this up when we were talking about with the end in this in my research i've determined that uh there's much more instruction set specific stuff in lvr ir than you would imagine and it's not as trivial to say well lvmr is completely processor agnostic and when we turn into machine code we can turn into machine code for any processor
John:
That seems not to be the case.
John:
I've been trying to find out what are the nature and number of those things.
John:
What is it about LLVMR that's pinned down to a particular instruction set and how deep does it go?
John:
I haven't been able to find any good examples.
John:
At the point I'm looking at the LLVM source code, I realize I'm in over my head.
John:
I don't quite understand that.
John:
But anyway, if you are entertaining fantasies of bit code,
John:
Meaning that if all our apps are updated to bitcode, they can change processors without any problem.
John:
That, as far as I can tell, is absolutely not the case.
John:
So the next question is, why the hell does bitcode exist if not for my fantasy scenario of enabling our Macs?
John:
You guys have any theories?
Marco:
Well, I mean, there's a lot of other optimizations they could do.
Marco:
Maybe this would just help them.
Marco:
First of all, there's just better optimizations for the next step.
Marco:
I don't know quite how low level the bitcode is.
Marco:
But I imagine it's not just a text version of assembly code.
Marco:
I imagine it's a little bit higher than that.
Marco:
So if they develop new optimizations for how they translate that into the assembly language, even within the same CPU family, just over time, they develop some cool optimization, they can then apply that to apps.
Marco:
More significantly, probably, they could...
Marco:
When you make a minor update within a CPU architecture, do you go from ARMv7S to ARMv7K?
Marco:
I don't know all those code names and which ones are minor.
Marco:
Or when Intel releases a new CPU with new streaming instructions, new vector instructions, if there's a way for them to use bitcode to...
Marco:
retroactively optimize apps for new instructions and things like that for more minor CPU revisions, that could be useful.
Marco:
I don't know how useful that is as a percentage of overall performance.
Marco:
I don't think...
Marco:
I don't see why this is worth the trouble yet.
Marco:
And I think over time, we will see why it's worth the trouble.
Marco:
But right now, it is not immediately apparent because you're right.
Marco:
The big changes would involve things like byte order changes where that's a bigger problem and this can't automatically deal with that properly just because of the level at which byte order assumptions happen.
John:
This can't do it.
John:
I think it's even deeper than that.
John:
I think even if you had an architecture that had the same byte order, that LLVM IR still pins things down with a target architecture in mind.
John:
Because that representation is the thing that the optimizer can work on.
John:
It's like it's marked up more than assembly would be.
John:
Like the thing that consumes LLVM IR and outputs machine code, it knows much more about the structure of things.
John:
Because LLVM IR is sort of annotated with much more information than assembly would be to indicate performance.
John:
uh, you know, types and from whence each bit of code came and, uh, you know, what, what a function is and all like, it's not just, it's not just a, an ASCII representation of machine code far from it.
John:
So that's, that's why the, the, the thing that produces a machine code can, uh, can optimize it in ways that you can't,
John:
if you just have a .s file and say, oh, now optimize that.
John:
There's lots of optimizations you can't do to play an old assembly because you just don't know enough about the meaning of the original program.
John:
It's like, well, this assembly does what it does.
John:
I don't know if it's safe to make this transformation, but LVMIR has more information about it.
John:
Before we get into the worth the trouble, before we get into the trouble aspect of it,
John:
It's interesting to think about why this is even possible or a thing.
John:
This is only possible if only feasible because Apple controls the means of distribution for all iOS and watch applications, setting aside jailbreak and blah, blah, blah.
John:
Right.
John:
that means that they can a they can mandate this and say guess what you're going to submit bitcode for the watch you're like all right i guess i'm going to submit bitcode for the watch uh and b they know where everybody's getting their watch kit apps from so if the only source for watch kit apps only ever has bitcode any benefits which we'll talk about in a second that that might that they might have will benefit the entire platform it's not like well it'll benefit like on the mac if they did on the mac well benefit for people down from the mac app store but people can
John:
put dmgs up on their websites that do or don't have bitcode in it so you know like you're not getting that advantage across the platform but for ios and the watch whatever benefits apple thinks it's getting it gets everywhere um ios of course would have to go through a conversion the watch will be bitcode all bitcode from the beginning so uh lots of interesting things become possible when all of your software funnels through a single point lots of good things and bad things and i think apple's hoping this is one of the good things
John:
Right.
Marco:
And the bad things, I think, about bitcode, what scares me as a developer, you know, like a lot of developers are saying, well, this is going to change my binary.
Marco:
I'm worried about crashing and stuff like that.
Marco:
That's valid.
Marco:
I'm not necessarily worried about that myself, although that does introduce an interesting problem of this would then like, you know, if this is, say, crashing on an iPhone 5S.
Marco:
and you don't have an iPhone 5S because now that's old and you don't have one anymore or you never got one to begin with, then you might have to go get an iPhone 5S just to even reproduce the crash, if you'll even be able to.
Marco:
So that's a problem.
Marco:
I think that's a minor one, though.
Marco:
To me, the bigger problem here is...
Marco:
If you look at what you mentioned earlier about how developers want to be able to build their final binary, ship it to Apple, and then have Apple ship that to devices so they know the final bits they've built.
Marco:
In reality, that has never quite been the case because of code signing.
Marco:
And even though it's not technically part of the app binary, it's an important enough part that...
Marco:
Every so often, as I ran into with Instapaper a long time ago, and as still happens with somebody every few months, every so often, code signing breaks on Apple's side.
Marco:
And something goes wrong where apps reach the App Store with invalid code signing by Apple.
Marco:
And so what happens to the user is they tap to open them and they appear to just crash immediately on launch.
Marco:
You might see the launch default image, but for the most part, they just crash on launch.
Marco:
They appear to be, at least.
Marco:
In reality, code signing is just failing and exiting.
Marco:
But every so often, you have this problem as a developer where your app crashes because Apple messed up while modifying it on the way to the store.
Marco:
BitCode is now giving them another way to do that.
Marco:
It's giving them another opportunity for things to go wrong.
Marco:
What worries me is not that a BitCode abstraction would be insufficiently tested, that a BitCode optimization would go wrong.
Marco:
What worries me is like now there's another step between me and the customers.
Marco:
Regardless of what that step is, there's another step that can cause problems when it breaks.
Marco:
And I'm not even going to say if it breaks.
Marco:
We know these things break sometimes.
Marco:
That is what is the big risk here is like yet another thing that Apple is going to modify about my app on the way to the customers that might occasionally go wrong.
John:
yeah and that's what developers are wary about is it's a loss of control like already you know you're not controlling who your app is distributed to and so on so from a technical perspective you always want to you always want to have the ability to have the exact same thing running that the customers have even if you can't actually communicate with them you you want to know you want a predictable uh chain of events and there's always parts that are not pretty even though xcode is running on your system
John:
you don't know the internals of the compiler.
John:
There could be a compiler bug in a point release of Xcode that hosts your binary that somehow makes it run.
John:
You know, there's always bugs, but adding more of those things makes developers feel uncomfortable and it's uncertainty.
John:
Like we've been battling with code signing for tons of years now and it drives people crazy for a variety of reasons.
John:
But this just adds another thing.
John:
So is this going to be worse than code signing is in terms of things you have to fight with?
John:
I think it'll probably be better just because especially in the short term, this is just sort of stopping short of that final step targeting at this point a single architecture because there only is one Apple Watch.
John:
Right.
John:
So there's some runway for them to work out the kinks in this.
John:
uh because the idea is like oh i don't know how it's going to be well you will know how it's going to be built because when you upload the bitcode to the store it's going to convert it to a binary exactly the same way it does in your system because everybody has the same watch because there's only one watch right so it's an ideal platform to test this out on what people are worried about is i test it on all my devices but like you said that when when the bitcode gets converted to the a5 it turns out the optimizer does something bad on the a5 and it crashes and i don't have an a5 device
John:
Maybe that would still happen with the binary, but you're not entirely sure.
John:
Like, for example, if the compiler emitted an instruction that has bad performance characteristics or reveals a bug or something on the A5, you wouldn't know that unless you ran it on an A5.
John:
So not having an A5 could be a problem in all situations.
John:
Trying to think about why Apple would want to do this again, I'm basically ruling out, oh, this makes it this makes us able to change processor architectures easily.
John:
I don't think this is helps or hurts in that regard.
John:
But Apple does change, as Marco said, the minor parts of the architecture.
John:
They make their own chips essentially at this point.
John:
Different chips have different vector units.
John:
Maybe they add an instruction here or two.
John:
Maybe they tweak something.
John:
Maybe they try to change one of their underlying frameworks or libraries to do something smarter on the new A9 or the A10 or the A11.
John:
All these things might seem like minor concerns, but from Apple's perspective, if they do something really cool in the A10 and they, you know, change around a bunch of things having to do with like number of registers, pipeline depth, size of the vector units, like a new specialized instruction for a particular thing.
John:
they're helpless to change all the what is it millions i don't know how many apps there on the app store lots and lots of apps on the app store that are already compiled into machine code and there's nothing they can do short of nagging developers saying hey uh your app not so much would run faster but your app would be much kinder to our battery if you would just recompile it because actually all of this whatever core audio core image whatever like
John:
uh, VDSP, whatever little library you're using on, on, in your app.
John:
Uh, if you could recompile it for the a 10, it would be much nicer for battery life or for the S two or for the S three or whatever.
John:
Uh, yeah, I'm thinking mostly in terms of battery life, not performance because that's where Apple's been concentrating these days.
John:
And they have no leverage to do that.
John:
So Apple, you know, is such a control freak as a company, but like, you know, it makes their products better.
John:
How can they convince a million developers to rebuild their apps?
John:
They can't.
John:
And people will just keep downloading apps.
John:
They keep slaughtering their batteries.
John:
Even though Apple has done this super hard work in the A9, A10, A11 or whatever, S1, S2, S3, S4, to try to make a more battery efficient architecture.
John:
And because they do control the means of distribution of all the apps,
John:
Like we've got all these apps, we've got all these binaries, but they're not taking advantage of all this hard work we're doing.
John:
Ah, but on the watch, if they make a bit code from day one, they can be assured that if they make the S2 or the S3 massively more battery efficient by tweaking the particular instructions that they have, that they don't need developers to rebuild their apps.
John:
They will do it.
John:
They will, when they optimize the bit code.
John:
uh to make the native binary for the s3 they will do the transformation that uses the new instructions that are nicer on the battery on the s3 so your same app that you didn't have to recompile that you never looked at that you just put in the store or whatever your you know little doohickey or and probably not gonna be a lot of games but that would be the ideal case will suddenly be more battery efficient on the s3 without you having to do anything
John:
And that may seem like a minor thing, but I think that is more than enough reason for Apple to want to do this, because this is exactly what they always want to do.
John:
What can only Apple do?
John:
Only Apple makes its own CPUs, makes its own compiler, controls the distribution of all the applications.
John:
They have the complete package here, and this is one of those things you can do when you have the complete package.
John:
And I think that's probably much more exciting for Apple than it is for us on the outside.
John:
And I think Apple is going to
John:
endure the potential scariness for developers i mean they've proven they'll do that with sandboxing they'll do they'll do it with uh code signing the developers will endure it because that's where the customers are and that's where the money is and you got to do what you got to do um but i definitely think this is the most interesting and probably least understood including by me because apple said nothing about it announcement at wwdc and i'm very interested in learning more about it from anyone who's willing to tell me anything about it
Casey:
No, I think you hit the nail on the head, John, that basically this is about keeping their options open.
Casey:
And Apple tends, from what we can tell, to like to keep their options open.
Casey:
So I'm curious to see, like you said, where this goes and if we'll ever hear of a time where Apple says, which I doubt, but, you know, hey, this is all possible because of BitCode, you know.
Casey:
We've all kind of realized that, say, iPad multitasking is possible because of auto layout and size classes.
Casey:
And that's kind of been a wink and a nod from Apple that has indicated.
Casey:
Well, obviously, we could all put it together, but also indicated that.
Casey:
So I'm anxious to hear more about this as time goes on.
Casey:
I don't know.
John:
I wonder if they'll even mention it again.
John:
But like in terms of like, oh, future possibilities, it's not so much future from Apple's perspective because the, you know, the A9, the S2, the S3, the A10, those are all real things inside Apple with like probably, you know, some of them probably done.
John:
Some of them have design.
John:
So if they're going to...
John:
fiddle with some instructions for battery efficiency those instructions already exist they're already in that situation where they say when we release the s2 all of our watch binaries are not going to take advantage of these great new instructions that we've that we've added or that we've tweaked or these new execution units or the different register layout or whatever uh because the machine code has already been built and the loops have already been unrolled and the the you know all that stuff
John:
Like, you know, we can't rely on the rename registers to do all the shuffling for us.
John:
Like if only we could rebuild all the watch binaries, take advantage of what we know is going to be a great feature of the S2 or S3 because it's already done.
John:
They already have those features.
John:
So from our perspective, it's like, oh, this opens up possibilities from Apple's perspective is we're doing this now because we know for sure because we're making the chips that we don't want a bunch of binaries built for the S1 to be stuck in the store for years and years because we can't get developers to recompile them.
John:
uh and ios again they have to transition that and the mac they're stuck in the situation where the bottom line is i don't know if it's most but certainly not all mac software comes from the mac app store so i'm not sure what they're going to do there but like i said this technology they could do it in the mac app store they are doing it on ios and the watch um it just seems like it has less less of an advantage there and frankly they don't care that much it seems probably on the mac like oh you you know want to rebuild your binaries to
John:
Because they don't make the CPUs.
John:
Intel does.
John:
And so they're not as privy to Intel's roadmap as they are to the A line of processors.
Marco:
I wonder also how much of this is in response to and preparation for the world we live in now, which is back in the olden days, 2008, 2009, early days of the App Store, Apple could announce any change, really, or at least any new hardware that
Marco:
And a very large portion of apps in the store would be updated within a reasonable amount of time to account for that, to accommodate that.
Marco:
They could release the iPad, and developers adapted to that.
Marco:
They eventually released... Even as recently as the iPhone 5, they would release a new screen size, and most apps got updated relatively quickly to it.
Marco:
But I think as we're seeing, the rate of that is slowing down dramatically.
Marco:
So now we have apps like...
Marco:
The iPhone 6 is now almost a year old and 6 Plus.
Marco:
They're now almost a year old.
Marco:
We're seeing apps from people who have a lot of users but don't necessarily care about their apps like banks.
Marco:
We're seeing apps like...
Marco:
I still have so many apps on my phone from companies that have plenty of resources to update them that don't even run natively on the iPhone 6 screen.
Marco:
Still.
Marco:
Some of them are even adding other features.
Marco:
Like, I think somebody said their bank supports Apple Pay now, but their app still doesn't support iOS 6, or, I mean, the iPhone 6 screen.
Marco:
Like...
Marco:
There are so many of these things.
Marco:
And the way Apple usually adds these new features or new support to apps is they build in some kind of compatibility mode where the app just scales to the new screen size or whatever the case may be or doesn't get the new features or whatever.
Marco:
And only apps that are built with the new SDK that are compiled against the new SDK, only they get the new features.
Marco:
And they do this so that when you update OSes, a whole bunch of apps don't break.
Marco:
The downside to this is right now, everyone's installing the beta of iOS 9 on their iPad Air 2 to try split-screen, and none of the third-party apps work yet.
Marco:
Because only third-party apps built with the week-old iOS 9 SDK that are somehow now available to their customers, which can't even exist in the App Store yet.
Marco:
It's only through TestFlight.
Marco:
Only those will be running in split-screen mode.
Marco:
And so you have this new feature.
Marco:
And then when iOS 9 is released this fall, presumably with a larger iPad also, there's going to be the vast majority of iPad apps out there are not going to be compatible with these new features.
Marco:
They might not be compatible with the new iPad screen size.
Marco:
And that hurts Apple.
Marco:
It hurts Apple's hardware ambitions and pushing the roadmap forward and pushing the software SDK forward.
Marco:
It hurts them that so many apps are not being updated in a reasonable amount of time to their new stuff.
Marco:
So they have to come up with ways to increase the chance that they can just opt everyone in rather than right now where everyone gets opted out of new changes.
Marco:
And so one of those things is auto layout.
Marco:
One of those things is launch image storyboards instead of just flat images.
Marco:
And maybe BitCode is part of that too in what is probably a small way.
Marco:
But it has to be related because this is a big problem Apple faces in the app library these days.
Marco:
And I see it only getting worse in the future as not only as the economics of the app store get harder, but also as Apple seems to be increasing the rate at which they are adding new device capabilities, adding new screen sizes.
Marco:
And on the watch...
Marco:
Maybe when watchOS 3 comes out next year, presumably, the watch layout is so simple.
Marco:
It's this kind of stack view-based hierarchy.
Marco:
What you get on the watch layout-wise, UI-wise, is so simple that if they added a new watch screen size next year or this fall or spring or whatever, if they add a new screen size to the watch...
Marco:
they might be able to just opt everyone in.
Marco:
They might not have to do the default opt-out and then scale it to some stupid blurry resolution.
Marco:
They might be able to just opt everyone in and it just works because apps are so limited in what they could do layout-wise.
Marco:
They've been beating us over the head from day one with WatchKit saying, don't assume a screen size.
Marco:
And with things like bit code and auto layout, maybe this is all going towards that goal.
Casey:
Only time will tell.
Casey:
But what else is awesome these days?
Marco:
Our second sponsor this week is Squarespace.
Marco:
Squarespace, build it beautiful.
Marco:
You can build so many kinds of websites with Squarespace.
Marco:
It is so hard to justify building a website any other way for so many types of things.
Marco:
So let's say you're building a site for yourself.
Marco:
You have a blog, a portfolio.
Marco:
Maybe you're a photographer.
Marco:
You have a photo portfolio.
Marco:
My wife uses it for that and she loves it.
Marco:
Maybe you have a restaurant or a business.
Marco:
You want a site for that.
Marco:
If you want to have a store where you sell t-shirts, you can do that.
Marco:
If you want to have a site for a book or an album or whatever, you can do all this with Squarespace.
Marco:
There are so many kinds of sites you can make with Squarespace.
Marco:
Now, I've used a lot of tools for building websites before.
Marco:
And I can build my own websites from scratch.
Marco:
I know how.
Marco:
I know how to run servers.
Marco:
But in so many cases, it's just not worth it.
Marco:
Even for geeks like us, it is so often just worth hosting on Squarespace rather than setting up your own server somewhere or building your own CMS from scratch.
Marco:
It is so really worth doing that.
Marco:
So...
Marco:
Squarespace makes it simple, powerful, and beautiful to make websites.
Marco:
They have a robust and reliable platform, state-of-the-art technology powering your site.
Marco:
They ensure maximum stability under load.
Marco:
If you get slammed by a big traffic load, they will keep your site up.
Marco:
They have maximum security.
Marco:
You don't have to worry about your site getting hacked.
Marco:
I don't think I've ever heard of a Squarespace hack, honestly.
Marco:
I certainly can't remember one, which is pretty impressive for a service that size.
Marco:
All their designs are beautiful and professionally designed, and they're all responsive.
Marco:
So your design looks great on every device every time.
Marco:
The screen sizes change over time, and as new things are added, Squarespace is on top of it.
Marco:
As I mentioned earlier, if you want to have a store with commerce, you can sell digital or physical goods.
Marco:
It's all included in the platform.
Marco:
So check all this out.
Marco:
There's so much you can do on Squarespace.
Marco:
Everything is WYSIWYG.
Marco:
You know, what you see is what you get.
Marco:
I don't know if I'm allowed to pronounce that like that, but I'm going to...
Marco:
I'm going to say WYSIWYG.
Marco:
Everything is WYSIWYG.
Marco:
You can drag and drop and you can move things around.
Marco:
Or if you want to actually inject code, you can do that too.
Marco:
You can write and mark down if you want to.
Marco:
Really cool stuff.
Marco:
Check it out.
Marco:
Now, normally they have a free trial with no credit card required.
Marco:
Now, they have a special deal now.
Marco:
If you start your trial soon, before June 30th,
Marco:
If you sign up for Squarespace's professional or business plan, you will get a free year of custom email and business tools when you sign up.
Marco:
So start your free trial now to get in on this deal before June 30th.
Marco:
Then when you buy, you can get the free year of custom email and business tools for the professional or business plan.
Marco:
So check it out.
Marco:
Otherwise, if you don't need that or if you missed the deadline, don't worry.
Marco:
Try it anyway.
Marco:
Go to squarespace.com.
Marco:
Use offer code ATP to get 10% off your first purchase and to show your support for our show.
Marco:
So once again, squarespace.com.
Marco:
Start a free trial.
Marco:
No credit card required.
Marco:
It's great.
Marco:
Build a site.
Marco:
See if you like it.
Marco:
If you do like it, use coupon code ATP for 10% off your first purchase.
Marco:
Thank you very much to Squarespace.
Marco:
Build it beautiful.
John:
I just want to save you from feedback that you may get, Marco, after your last talk about the analogy between size classes and all of those stuff.
Marco:
Oh, no.
John:
Marco was not suggesting that BitCode will allow your applications to run at different screen sizes.
John:
He was making an analogy.
Marco:
Right.
Marco:
And I'm saying like, you know, I think it's part of this overall picture of like trying to get to the point where Apple can make a new device that might have a new screen size, that might have a new CPU.
Marco:
They can make a new device and they can opt apps into the new features rather than right now where apps are all opt out until they're built to the new SDK.
Marco:
Right.
John:
Yeah, Apple's getting much better at that because like you can feel Apple's frustration of, you know, I mean, they kind of did it to themselves.
John:
Like, well, what do you mean an iPhone SDK?
John:
I guess here, let's slap this together.
John:
Like it was, you know, it's everything was fixed size and they changed the screen size and they had, you know, it's like they're working, as we said in past years, they're working their way up to what they have now, which is a much more flexible layout system that can lend itself to features like split skin.
John:
But it took them a long time to get there.
John:
But it's really hard to do that.
John:
Like even on the watch, like you said, the watch UI is so limited.
John:
surely the people doing the watch kit and everything like keep in mind that screen sizes may change so we should do everything we can because we've done this we've been through this once before so in the watch kit thing make sure we do everything so that nothing is fixed size nothing is specified and those you know like just really uh keep a very limited api but even then it's so hard to do things in a general way it's not like they're trying not to telegraph future stuff there it's just so hard to do everything in a general way and a good example is
John:
What was it?
John:
One of the sessions they were talking about the complication sizes and the graphics that you can include.
John:
And it was like, you can include one graphic for the 38 millimeter size, one graphic for the 48 millimeter size, and then an at 2X size.
John:
And they said, you know, if you don't include any of the other ones, we'll just fall back to at 2X.
John:
Also, if there's a watch that is not 38 and not 42 millimeters, we'll use the 2X.
John:
And so they don't want to say we're going to make...
John:
a 38 a 42 and a 46 because that would telegraph they're having a 46 but at the same time if they come out with a different watch size good app developers are going to want to make a pixel perfect native size for the new watch size but because they don't know what that watch size is they just have one kind of fallback that they can kind of use in a pinch so
John:
You know, it's better than not having a fallback.
John:
It's better probably than scaling the 38 to the 42 size up.
John:
But, you know, it's just so there are some things that just have to be fixed for the device you're doing, particularly artwork, because, you know, the whole fantasy back in the day was like, everything will be vectors and it will look good.
John:
But that's not the reality of pixel art, you know.
John:
good good ui designs especially when they're microscopic like they're on the watch someone's got to sit in there with the individual pixels and lay them out if they come up with a new size having something scaled is better than nothing but you're going to have to go through and change it anyway and i mean it just goes sort of like this you can't make it so that we can do anything and all your apps will run perfectly and take advantage of all the new features they're just doing trying to do everything they can and bitcode is the hardware side of that like
John:
Under the covers, we keep doing a bunch of crap down there, and we hate the fact that your binary that you haven't updated in two years is going to be plunking onto people's phones because they love your game or whatever.
Casey:
Or feet.
John:
Yeah.
John:
So the motivation for Apple to do this is so clear to me, and the discomfort from developers...
John:
i don't i don't want to make a prediction but i'm really hoping that it turns out to be mostly a non-issue in the same way that you know like compiler bugs and stuff like that or even code signing difficulties like in the grand scheme of things uh app review policies feel like a much larger both potential and actual damage to the experience of developers than bugs because bugs get fixed bugs even when they did that thing with the code signing like that was pretty much the biggest disaster you could possibly imagine
John:
They fix it, right?
John:
Whereas App Store policies try to convince someone that it's a bug.
John:
Is it a feature?
John:
Is it a bug?
John:
Is it intended?
John:
Is it not?
John:
Is it accidental?
John:
What are the actual effects?
John:
Much more difficult.
John:
So I have confidence that bugs will be addressed and fixed, and I hope there aren't too many of them.
Casey:
All right.
Casey:
We should probably talk about Swift 2.
Casey:
And I don't remember if we got to this during the last episode or not.
Casey:
But among other things, it's going to be open sourced later this year, including support for Linux coming directly from Apple.
Casey:
Which is pretty exciting and interesting.
Casey:
And I, for one, am extremely curious to see what kind of adoption it gets from the Linux neckbeards and all the server-side developers that run on Linux.
Casey:
And Marco, you're one of those.
Casey:
I'm curious to see how that goes, because obviously JavaScript seems to, in many ways, be the flavor du jour for new server development, obviously Node.
Marco:
Which just goes to show that it doesn't need to be a good language to get successful on the server.
Casey:
Although JavaScript isn't that bad.
Casey:
But anyway.
John:
The whole reason JavaScript is on the server is because it's on the client.
John:
Because people are like, I don't want to have two different code bases to do similar things.
John:
Can I have the same code in all places?
John:
I can't change the code in the browser, therefore I can only have to change it.
John:
It's a tragedy is what it is.
John:
It's like an infection that's just leaking out.
John:
I've never played Pandemic, but I imagine this is what the game board looks like.
John:
Board game reference for Marco.
Marco:
I have Pandemic, thank you.
Marco:
I'm sure you do.
Marco:
I'm waiting for next year's big web framework thing to be VBScript.
Casey:
Oh, God, no.
Casey:
Just no.
Casey:
But anyway, so with Swift 2, we're going to get Swift for Linux.
Casey:
And the other thing that was interesting about Swift 2, and this seems to be kind of the darling WWDC talk of this year, more so than I can recall from previous years, everyone seems to be consistently pointing to, what was it, protocol-oriented programming in Swift?
Casey:
Is that correct?
Yeah.
John:
Before I take a big dump all over this protocol extensions, I wanted to say one thing about Swift for Linux.
John:
Like we did talk about open sourcing Swift in the previous show because that was in the keynote.
John:
The reason I put it in there is what we didn't talk about is what you just mentioned, like that Apple said, hey, we're open sourcing it, blah, blah, blah.
John:
And open source, you know, the standard library and Swift will be available for, you know, iOS, OS X and also Linux.
John:
The word Linux was on a slide in Apple keynote presentation.
John:
Apple is not, I assume, making Swift for Linux the goodness of their heart.
John:
And so you have to ask, why are they making it?
John:
One potential reason is if you're going to open source something with the idea of, you know, we talked about this last show.
John:
making Swift viable for a larger community.
John:
Languages can't be confined.
John:
It can't be proprietary.
John:
That limits, you know, you're not going to get world domination with Swift if it's just an Apple thing.
John:
It has to be everywhere.
John:
And if you just open sourcing, it isn't enough to show that it's everywhere.
John:
It helps to have a place where you can port it to say, see, it actually is portable.
John:
It's not just a bunch of source code that you can't even build anywhere else.
John:
Linux is a super popular platform.
John:
Linux is the open source darling.
John:
Here is a Linux version of Swift that you can compile and run on Linux and do Swift things on Linux, both to prove to ourselves that we are correctly open sourcing things, which I haven't yet, by the way.
John:
This is like by the end of the year.
John:
And to to show that it's real, to show that it's not like an empty political gesture.
John:
The other possibility is that and depending on how cynical you are, potentially the more likely possibility is that Apple has a bunch of servers, too.
John:
And I'm pretty sure Apple servers aren't a bunch of X serves at this point.
John:
And I'm sure Apple probably has more Swift code than any other corporation in the world at this point.
John:
I can pretty much guarantee that.
John:
One would hope.
John:
And they might want to run the same code or the same libraries on both their clients, which are iOS devices and Macs, and their servers, which presumably, again, are not XServs running OS X. So if Apple has Linux servers...
John:
And Apple has devices that, you know, libraries that they make in Swift that can run on these devices.
John:
It would be nice if they could run Swift on the server because they actually happen to have servers.
John:
So I don't know the lineage of Swift for Linux, if it was always a thing inside Apple or if it came out of the open source effort.
John:
But I think the reason Apple has Swift for Linux is for their own use.
John:
And that's not why they're open sourcing.
John:
Open sourcing, again, is because they want the language to be bigger than just one company.
John:
But Swift for Linux being a thing really makes me think that they want to run or at least want to experiment with.
John:
Maybe it's not going to be a thing.
John:
Maybe it won't work out or whatever.
John:
But at the very least, it's something they want to try internally.
John:
And it makes perfect sense for them because...
John:
you know when we talk about the web browser if you're if you're a google it might make sense to run job well i don't think they're on javascript on the server side either maybe they do but anyway having libraries that run in everyone's browsers and being able to not having to duplicate that code on the server side and if apple has a bunch of libraries that run on everybody's phones that do some operation or whatever it would be nice not to have to duplicate all that code on the server side so you can do it both client and server side so that is my tinfoil hat theory for swift for linux it is not out of the goodness of apple's heart
Casey:
Does Apple really ever do anything out of the goodness of their heart?
John:
Well, open sourcing is pretty much as close as you can get because you could argue, and I'm sure they have this argument in Apple, like, does it really benefit Apple?
John:
We'll say, oh, yeah, we'll have more eyes on Swift and more people using it.
John:
And if Swift becomes the next really popular language and it's adopted everywhere, that's good for us because Swift will become better the more people use it.
John:
All of that is true.
John:
But the counter argument is, well, Objective-C technically was not like Apple proprietary, but really we're the only one using it and interesting.
John:
And that seemed to work out fine for us.
John:
It's not like we suffered by the world not hacking on Objective-C for us, even though they could have been in theory.
John:
So what's the big deal?
John:
Swift can be proprietary Apple language.
John:
We don't care if the world adopts it.
John:
We only care if Apple and Apple developers adopted, and that's fine.
John:
um so but open sourcing like the all all the arguments against that eventually stray into altruism and uh you know sort of the the new we didn't talk about this the new message at the bottom of apple's press releases did you guys read that
Casey:
No.
John:
Did I read the footer of a press release?
John:
It used to be Apple ignited the personal computer revolution with the Apple II and blah, blah, blah, blah, blah.
John:
Then they took out the Apple II and talked about the Mac and then moved on to iPhone and iPod.
John:
It's like a paragraph at the bottom of every press release that explains who the heck Apple is.
John:
And the current version, I believe, starts with the Mac and then says iPhone, iPad, blah, blah, blah, watch.
John:
I don't know if it says watch.
John:
Anyway...
John:
They added a bit that says, like, Apple employees are blah, blah, blah, and dedicated to leaving the world better than they found it.
John:
Like, it's a Tim Cookism that is now added to the end of the little paragraph.
John:
Leaving the world better than we found it.
John:
That's altruism.
John:
Like, it's not, you know, making the most money possible, increasing value for our shareholders, making the world better than we found it.
John:
That's all that, you know...
John:
diversity stuff the renewable energy stuff and you know maybe throw open sourcing swift in there so i'm i'm not too cynical to believe that you know that that wording change and that add to you see it it comes from tim cook this is his he's putting his stamp on the corporation and it's a stamp that i like
Marco:
Yeah, I'm going to be interested to see what comes of this.
Marco:
Does it get used at all, or does it just kind of sit there in obscurity like Apple's other open source efforts mostly have?
Marco:
And you've got to figure, as a server-side developer, as a web developer, as a services developer, why would you choose to use this over something else?
Marco:
And you're right, code sharing...
Marco:
is a big part of it but again like until the library situation shakes out uh you know yeah like they said you know obviously like the swift standard library will be there but that's there's not a lot in the swift standard library there's there's like a lot of things that almost every kind of app would need that uh or would need like one of that don't exist there uh so that is going to be a problem and it's gonna be a limitation for for a long time
Marco:
So I think like, you know, you look at other languages that are out there that have more library or framework or community support behind them.
Marco:
And even languages that are cool and new and modern.
Marco:
If you want to throw Node in there, you can.
Marco:
I will allow that temporarily.
Marco:
I would also say things like, you know, Python and Java somewhat, Go, Rust, you know, like the newer ones.
Marco:
I won't even say PHP, but, you know, people know it and there's a lot there.
Marco:
It's going to be a tough sell for people to use Swift over this almost embarrassment of riches of other well-established good web languages that have tons of libraries and great frameworks already, a huge community around them, finding bugs before they hit you, documenting things, making tutorials, writing books.
Marco:
There's so many languages out there already that have great resources and great support behind them
Marco:
I wonder if Swift will be able to get a foothold in that the way Apple is most likely to operate and with the limitations it's most likely to have, especially in the area of libraries.
Marco:
And that I think we'll just have to wait and see.
John:
Well, someone could always take it and run with it.
John:
It's not just the website.
John:
Someone could use Swift as an alternative to C++ for the new thing they're making.
John:
I mean, I have no idea what Pebble's SDK is like or what it is.
John:
But say you're making some...
John:
small device and you decide you don't want to use C++ to make you know you're going to be the one making the API and the framework maybe you want to use Swift for it like the Rust is you know those are the Mozilla guys right they're they're using that as a better a memory safe alternative to C++ to do kind of the same type of job of C++
John:
there is not it's not just all about web apps you know again the whole thing with swift is it's supposed to be a language that can span from writing an operating system all the way up to you know they don't say this but you know like it could be an alternative to javascript in the web browser from the lowest of the low level to the highest of the high level uh and swift that's that's aspirational at this point
John:
uh it's certainly aspirational because like no one has actually written an operating system in swift and nobody actually has used swift in a web browser as an alternative to javascript but it is expanding outward and by open sourcing it you're never going to be able to expand to fulfill your your uh you know your aspirational uh target if you don't open source as a prerequisite and so you're right it's there are lots of barriers between here and there but
John:
Right.
John:
Right.
John:
So I think there is no downside to open sourcing other than the resources they're going to have to spend to deal with the open sourcing.
John:
But those type, you know, I feel like you can hire people to do that.
John:
And it's kind of a fun job and they don't need to be multi-year experts to handle it.
Casey:
Yeah, the other thing that strikes me is Swift seems to be a language written by a compiler guy for kind of compiler guys and for those sorts of people that really kind of get off on the nitty-gritty about a language.
Casey:
And that's not a bad thing at all, but...
Casey:
If there was any audience or any group or any way to target compiler men and women, then I would imagine that the Linux crowd is the way to do it.
Casey:
And so it very well may pique some interest in that circle.
Casey:
And certainly this is a group that loves having a new JavaScript framework every day.
Casey:
So who knows?
Casey:
Maybe somebody will decide, you know what, this is pretty cool and I'm going to build my Swift framework.
John:
um a question i wanted to ask the two of you guys do you think this is the beginning of the end of web objects was there a beginning of web objects well you know what i mean of apple's reliance i think we're like we're like into phase 17 of the end of web objects it's just it's a really long and i i don't see a bright future for web objects but i know apple has a lot of code written in it
Casey:
Well, that's the thing.
Casey:
That's what I'm driving at is, you know, yes, I think we can all agree that they want web objects to die in a fire, but I don't see any particular impetus or perhaps compulsion for them to get rid of it other than it being old and not well-supported technology.
Casey:
And if they're going all in on Swift across the corporation, then maybe that includes, you know, like the iTunes Music Store, among other things.
John:
I don't think they're going all in.
John:
I think this is, you know, baby steps here.
John:
But like, I think the problem they have with WebObjects is, all right, what do we replace it with?
John:
And all the choices are things that Apple controls less.
John:
Regardless of how much better you may believe they are than WebObjects,
John:
Things that Apple controls less and you don't want to rewrite a bunch of working code and Apple, unlike Google, is not constantly thinking about how it can improve every aspect of all its web operations.
John:
Like there are key things that it is concentrating on.
John:
And I think with good reason, like, hey, how about CloudKit is a great example.
John:
Let's do CloudKit.
John:
That is a big paid point.
John:
although people may not like web objects if you can click through our stores and buy stuff it's performing fine even if it's like defunct and not really being enhanced and doesn't have a bright future it's more important to uh to concentrate on other things so so maybe long term they can like you know swift for linux they could try it out in some small application uh server side thing and see if it works out like these are very early days but yeah like
John:
someone is staring at that web objects and going, it's like, you don't want it to end up like COBOL code where the only people who know how to deal with it at all are 60 years old and really expensive because they don't want to work anymore.
John:
And you just let it go too far.
John:
Web objects is not at that phase yet.
John:
And who knows?
John:
Someone could resurrect it someday.
John:
You never know.
John:
Stranger things have happened.
Marco:
Well, but that, like the talent aspect, I think might be a big part of this.
Marco:
Like imagine, you know, Apple already seems to have some issues retaining talent because they're, you know, the things they do are, you know, increasingly, you know, they have an increasing number of like boring things that have to be done.
Marco:
And there's so many other things.
Marco:
Like if you work at Apple, you probably get an itch constantly to go make your own app.
Marco:
Like I bet that's a big problem they have.
Marco:
Anyway, so to help retain talent, I think, or to help attract talent in the first place, if they're going to grow their cloud services stuff, which they almost certainly are and almost certainly need to, they need to figure out how do we attract more programmers who want to work on this stuff.
Marco:
And if you think about the prospects of a job where you're writing WebObjects code as the primary role of your job...
Marco:
Not only are those people harder to find, but, you know, if you want to find somebody who has experience with it before, but also you're probably like, if that's your job, that's not very interesting or cool to most people.
Marco:
And that's going to be, it makes it especially hard probably to hire young people.
Marco:
And so if they want to hire more people more easily to work on their cloud stuff and to have them be higher quality coders who want to stay there longer and who are going to choose that over some other job at Google or Facebook or whatever, having it be in a modern, cool language that everybody wants to write code in instead of an old language that has a pretty bad reputation that is not really useful anywhere else in
Marco:
that is hard to get experience in and is probably not the best language to work in these days when you are accustomed to more modern things.
Marco:
I think having Swift on the back end and having this be available, that would be enough reason right there, just for Apple's own recruitment and retainment efforts.
Marco:
That would be enough reason to do this.
Casey:
What else is cool these days?
Marco:
Our final sponsor this week is Igloo.
Marco:
Igloo is an intranet you will actually like.
Marco:
So with Igloo, you can share news, you can organize your files, you can coordinate calendars and manage projects all in one place on your corporate intranet or your group intranet.
Marco:
So Igloo is like taking the best of the web and productivity apps.
Marco:
They have calendars, they have Twitter-like, microblogging, file sharing, task management, wikis, document annotations, and more.
Marco:
All available privately and securely for your company or group.
Marco:
Igloo intranets are highly functional, stylish, and easy to use with a widget-based drag-and-drop interface.
Marco:
Now, their latest upgrade, Viking, revolves around documents and how you interact with them, gather feedback, and make changes.
Marco:
So they have a couple of cool features here.
Marco:
First of all, you can have basically read receipts for documents.
Marco:
You can track who has read critical documents, critical information to keep everybody on the same page.
Marco:
You can do this, for example, to track whether employees have read and acknowledged new policies, signed off on legal agreements, confirmed completion of training materials, all sorts of possible professional and regulatory uses here.
Marco:
And all this is built on their advanced HTML5 platform.
Marco:
And this is really advanced.
Marco:
It's fully responsive, first of all.
Marco:
So it works great on every device.
Marco:
Computers, iPhones, Android phones, even BlackBerrys.
Marco:
And then what I think is the coolest part of this is they have all this document previewing and document annotation that
Marco:
there's no flash any of that it's all this document parsing code all this document annotation code that's all in html5 so you can do annotations you can do you can view you know spreadsheets and stuff like that you can do all that just on your phone if you want to or just on your computer without having flash installed which is the devil so you really don't want flash
Marco:
And when new devices come out, new screen sizes come out, it just works on there.
Marco:
It is so great, so advanced.
Marco:
So if your company has a legacy intranet that looks like it was built in the 90s like most corporate intranets do, you should definitely give Igloo a try.
Marco:
Now what's even better is that if you have a group of 10 or fewer people to use it, it's completely free to use for as long as you want.
Marco:
So if your company is 10 or fewer people, or if you want to use it for a group project or a side thing, whatever you want to do, 10 people or fewer, it's free forever.
Marco:
And then when you get larger than that, it's very reasonably priced.
Marco:
So check it out today.
Marco:
Sign up for a free trial.
Marco:
See if it's right for you.
Marco:
igloosoftware.com slash ATP.
Marco:
Once again, igloosoftware.com slash ATP.
Marco:
Thanks a lot to Igloo for sponsoring our show once again.
Casey:
So, John, I hear you have thoughts about protocol extensions.
John:
Protocol extensions are great, but the protocol-oriented programming talk, there's always a couple of weird talks at WWDC that are structured as narratives or that have a framing device.
John:
And this was one of them.
John:
It was like a single presenter.
John:
The framing device was like a hypothetical discussion between an old, a cranky programmer and a young one used to demonstrate something.
John:
And the reason I find these
John:
interesting i was mostly joking about dumping out but i find them interesting because these are these talks all wwc but specifically these talks about like i'm going to tell you uh the way uh the way that we think you should use our language to make your programs better are aimed at an audience that's not me it's aimed at people who develop ios and mac apps it's aimed at like long-time objective c developers it's aimed at people whose programming culture is very very different than mine um
John:
and so sometimes that means the message goes past me and sometimes it means that like they're they're trying to the context is practices that i don't have and never had and they're trying to persuade me as hard as they can to not do this thing that i think is crazy and would never do anyway or vice versa tell me to do something that seems alien to me and then try to convince me that it's good and so
John:
protocol extensions was trying to show all the sort of uh traps that you can run into not in an explicit way but like you're used to doing this in objective c and these these problems are why objective c is the way it is like why did why are there delicate patterns all over objective c well because inheritance has these problems or so on and so forth and a lot of the stuff this is the one that gets me the most a lot of the stuff both having to do with swift and objective c and everything at wwdc
John:
uh focuses heavily on types and if you use a language that does not have uh that has dynamic typing uh where you don't worry about types you don't worry about matching type signatures you don't that's like that's not even a thing a lot of the stuff that is super important to people who deal with languages with types is irrelevant like it's one of the things people talked about the the gang of four patterns book like a lot there was an article about it years ago when the patterns book first came out someone
John:
had the epiphany after reading the patterns book you know what a lot of this crap is totally irrelevant to me because i don't use c++ or java or any other strongly type language like a lot of these patterns exist so that you can make your program flexible in this way but maintain static type safety everywhere and if your your language doesn't even have static type safety you're like well that pattern makes no sense you know how i do that pattern i just do this and i don't have to worry it works all the time i don't need seven versions of this i don't need a
John:
concrete and abstract implementation.
John:
I don't need protocol extensions so the type smack it up.
John:
All the problems they described in the protocol extensions thing, a lot of those just don't exist in languages like JavaScript where you just don't have to worry about that, right?
John:
Maybe ES6, that'll be a problem or whatever.
John:
So that's one aspect of it.
John:
And the second one is I'm heartened to see
John:
ideas from the crazy highfalutin mumbo jumbo languages that i use uh and even from things from pearl sex and stuff filtering down to the uh troglodytes who use these languages with pointers and stuff or swift where you have you know unsafe unmanaged uh hose myself by scribbling over remember anyway uh the lower level languages and i think the idea that was sort of from my perspective the idea that was buried in in the uh protocol rnt programming language thing was
John:
The idea of traits, which I think were from small talk roles in Pearl Pollance, uh, another, a better managed alternative to sharing code, uh, sharing interface and code without screwing with your inheritance hierarchy, without forcing data to be shared, without doing all that other stuff.
John:
So it was a talk that just seemed very alien to me, uh,
John:
But everyone who saw who was in the correct audience, you know, who was this talk was meant for them, seemed to like it.
John:
And it seemed to open their eyes to the possibility of how they can program differently in Swift and how Swift attempts to solve problems.
John:
The same problems that Objective-C solved by sort of skirting them.
John:
Swift has a different way to take the same approach.
John:
So I hope people watch that session and come away.
John:
With new ideas about how they can structure their programs to satisfy all their languages' static type constraints.
John:
And new ways to share functionality and interfaces without inheritance and without a million delegates everywhere.
Casey:
Now, this is one of those talks that I was in as well, and I enjoyed it a lot, although the framing, whatever, was a little bit weird.
Casey:
Krusty, the old programmer, I think, was the character they used.
Casey:
But anyway, the talk was very good, but it's one of those that I feel like I need to go back and watch it again because it didn't entirely sink in.
Casey:
And I think that's partially because I, too, am not necessarily the right audience because I don't live and breathe Objective-C every day.
Casey:
But there were a lot of things, and I've said this about Swift in the past, there's a lot of things that they talked about that reeked of C-sharp style implementations of the same idea.
Casey:
Protocol extensions smelled a lot like extension methods to me, and I'm sure they're different in nuanced ways that I'm not considering as I'm talking, but...
Casey:
But they seem very similar.
Casey:
And so I think that I'd like to rewatch this and perhaps consider what patterns I can apply to even my C-sharp code that maybe I can be inspired by from this talk.
Casey:
But it was very interesting.
Casey:
And like I said earlier, just about anyone who has seen it has said, wow, that was really cool and you should definitely see it.
Casey:
And I concur.
Yeah.
Casey:
I don't know, Marco, any thoughts?
Casey:
You're probably the target audience more than anyone.
Casey:
Did you see this one?
Casey:
I didn't do my homework.
Casey:
Of course.
Casey:
To be fair, I didn't do it since I got home.
Casey:
I just happened to be in that talk when we were there.
Marco:
No, I have also heard from everybody that I have to see this talk, and so it is on my list of talks to watch, but I have not watched it yet.
John:
Protocol extensions are separate from this protocol oriented.
John:
The protocol extensions are mostly people in the chat room are saying extensions are like categories.
John:
Swift has always had extensions.
John:
Protocol extensions allows you to extend protocols, which previously you couldn't do.
John:
If you look at the Swift standard library and see all the different
John:
things they had to do to make things that are like well this is equatable and sortable and this inherits from that and this conforms to this like to try to make just their basic types of like you know arrays and dictionaries and all the other things that they want to work with all their map and sort things again problems don't exist if you don't have types it's like well how can we have this that works a generic form of that and that and trying to get away from all the angle bracket t generic thing that was making swift look all super ugly oh good i hate those yeah well
John:
And that and like the standard library itself, because that's probably the biggest source of Swift code in the world at this point, as far as we know, is the Swift standard library itself.
John:
Because all that stuff, all their hashes and dictionaries and intinals, that's all written in Swift.
John:
That's their standard library, right?
John:
And having map and filter and all those other things work on all the different types and also on your extensions of those types and your subcategories of types and also enums and structs, which can also have methods.
John:
It's really complicated.
John:
And in writing the Swift Standard Library, they ran into all of the, I'm assuming, they ran into all the ways that the language is making things annoying.
John:
I mean, anyone who's done any sort of large object-oriented program has inevitably found themselves in a situation where...
John:
And either you start wishing for multiple inheritance or the flip side, you start using it.
John:
And in both cases, you have regrets, right?
John:
Like, oh, but I need this needs to be that and that needs to be that.
John:
And really, there's no way to arrange this hierarchy of this.
John:
So they're going to have this if I have these multiply inherited, but I want this, but I need to override that over there.
John:
But this needs to come from over here.
John:
Like you make a mess, you know, because you don't foresee everything.
John:
You end up making a mess.
John:
That's that's an anti pattern that anyone in any object oriented language experience.
John:
And I feel like Apple must have experienced that doing the standard libraries like, oh, well, we need everything to be sortable and equatable.
John:
And and we need them to be able to be mapped from one thing to the other.
John:
But, you know, we want all the types to match up.
John:
We want people to be able to extend it, but then to have their extended versions also work with all the built in things.
John:
And you end up it's really complicated problem.
John:
and protocol extensions give them one more vector for sharing that like they'll define these protocols that don't affect the inheritance hierarchy and then you can extend the protocol so then everything that conforms to the protocol gets your extension it's different than doing a category where you're like oh now all instances of ns string have this method you can have like all instances of things that are equatable have this new extension right and that's that is a powerful feature that uh i think a lot of people wanted when they saw swift one and i think the people probably wanted it the most were the people writing the swift standard library and i think this probably made their life
John:
a lot easier and then the protocol oriented programming is like hey protocols period like you can share code by instead of just making a series of subclasses and making a big inheritance hierarchy you can have this this unit of code you can have like you know java interface that has no code and that's powerful and then you can uh you can share uh those implementations and override them among any classes like you're not it's not part of the inheritance hierarchy everything you can make all your different things
John:
uh conform to this protocol and then when someone extends the protocol they've enhanced all the things that uh i keep trying to use pearl parlance the pearl parlance their their roles and classes consume them which sounds weird and gross but it's nice to have a distinct word for it so yeah everybody who consumes this role now i guess the advantage there are there are no role extensions in pearl and i was thinking like oh why don't we have role extensions and i thought about it for a while and i think it's probably because we don't need them because you would just
John:
You know, Pearl's like Ruby.
John:
You can do whatever the hell you want.
John:
We stick methods.
John:
We stick methods to any class we want.
John:
We screw with the hierarchy at runtime.
John:
It's the Wild West.
John:
But anyway, it's an interesting talk.
John:
Sounds awesome.
John:
Yeah, it is.
John:
It is pretty awesome.
John:
It's better than Ruby.
John:
Ruby did mix-ins, which is just like, you know what?
John:
Here's some methods.
John:
Bam, they're in your class.
John:
Oops, did I overwrite something?
John:
Sorry about that.
John:
Rolls, at least, when your class consumes them.
John:
It will tell you if, you know, a class at class composition time, it consumes the roles and it will tell you you can't consume those roles.
John:
They conflict in this, this and this.
John:
Right.
John:
And roles can also make requirements of the classes that consume them.
John:
You can consume me, but you need to implement methods X, Y and Z. Otherwise, you know, and that having that happen at class composition time is way better than the Ruby thing where you just keep.
John:
loading ruby modules until like the the the uh integer class has 17 people fighting over the method that's called like whatever inverse or first or like happy birthday or whatever the hell people are shoving into you know and they just silently overwrite each other and you know so it's a more formalized system of non-inheritance based interface and code sharing anyway uh cool stuff swift 2 looks really good
Marco:
I'll tell you one thing.
Marco:
I'm honestly very glad I haven't learned Swift yet.
Marco:
Because they keep adding these... First of all, they keep changing things, and they keep adding really cool things.
Marco:
And honestly, if you have a large body of Swift code, that to me seems more like a liability at this point.
Marco:
Even though they have some of the translation tools and everything, but I would rather come to Swift with a totally clean mind and no existing code...
Marco:
Once it has stabilized a little bit more.
John:
I was going to say, I don't think your mind is entirely clean with all that PHP in there.
Marco:
You know what I mean?
Marco:
I don't have any existing knowledge of Swift, really, that's of any use.
Marco:
I don't have any Swift assumptions or Swift design habits I've already started getting into.
Marco:
So when I do start using Swift, it'll be from a clean slate, as if that was version 1.0 of the language.
John:
Well, it's nice to... I think the people who have used Swift 1 and run into all these problems, A, they appreciate the Swift 2 features more.
John:
It's like, oh, God, I've been fighting that for a long time in Swift 1.
John:
It's great to see it in Swift 2.
John:
And B, I think it will help you understand the features of the language.
John:
If you haven't fought with all the foibles of Swift 1...
John:
It may not be clear why certain features in Swift 2 exist.
John:
So I think experience is still useful.
John:
But what I wanted to get at was the point you brought up of what is the strategy?
John:
They said this from the very beginning.
John:
The strategy of Swift is they're going to make Swift and we're going to change the language in ways that are just entirely incompatible with the Swift code you're writing now.
John:
furthermore that swift code that you wrote last year that's not even a compile anymore like not only is you know it's like oh okay well my app is written in swift one no it's not if you want to ship your app it cannot be written in swift one because swift one will not build in the new version of xcode their entire strategy at this point anyway is we will take your swift one code and convert it to swift two uh
John:
And that's that's they've been saying that from the start.
John:
They don't guarantee source compatibility, which means their compiler will not compile your Swift one.
John:
They don't care about your Swift one.
John:
You got to convert to Swift two, which is very aggressive.
John:
And like, you know, all the work they did with the compiler infrastructure and Xcode and the integration between them.
John:
And the static analyzer allows them to have a conversion thing that does this in a sensible way and does most of the work for people.
John:
It's still kind of annoying, though.
John:
But I'm not entirely sure this is a long-term strategy.
John:
OK, so Swift 1 to Swift 2, Swift 2 to Swift 3.
John:
At a certain point, Swift 16 to Swift 17, are you really going to invalidate what Apple would hope is the millions of lines of Swift 16 code that are out there when you change to Swift 17?
John:
No, it's got to end at some point.
John:
uh so i don't know what point that is but for now the policy is not only marco might you have been wasting your time writing in a language and learning idioms that are going to change when the next order of swift comes out but you'd also have the task of converting all of your swift one code to swift two like it's not even an option to keep the swift one code around um and i think that will continue
John:
until the language reaches the point where apple's like all right this is settling down now we'll start to i hope they'll start to treat it like a regular language where we don't invalidate your objective c code when objective c 2.0 comes out when they start versioning objective c we try to encourage you to move to 2.0 the 64 bit rundime to is 2.0 only blah blah blah blah but your old code will keep building for a really long time we did they didn't force you to constantly convert all up convert all your code
John:
And they kept it backward compatible.
John:
Whereas Swift 1, they changed some of the keywords.
John:
Like do became repeat.
John:
They'll change anything they want.
John:
And now do means something else.
John:
Yeah.
John:
Now it basically means try.
John:
No, there's try inside the do.
John:
There's a Yoda joke in there somewhere, but I cannot get it out.
John:
That's a reference to something, Casey.
Casey:
That's Star Trek, right?
John:
Yes, that's right.
John:
Yeah, next generation.
Yeah.
John:
this is this is a thing to watch for when when apple thinks swift has finally settled down when they stopped doing the thing the thing that they always said they were going to do they just never said how long they're going to do it for it just seems like something that is not sustainable long term but certainly for swift one two and presumably next year swift three uh
John:
They'll probably keep it that maybe four, maybe five, maybe five.
John:
It settles down.
John:
But that's something to keep an eye on.
John:
But anyway, I love seeing this this aggressive strategy of like not doing the old Microsoft thing of like, well, you can't break people's old apps and you can't their source code has to compile and work exactly like it always did.
John:
Apple's like, no, we are racing forward as fast as we can.
John:
You better come along for the ride.
Marco:
And that's great.
Marco:
I mean, there are so many languages that get kind of unfortunate cruft almost immediately after their launch because they don't do that.
Marco:
And because they have developers instantly who are like, well, we're not going to tolerate you breaking the code we wrote for this two-month-old language last month.
Marco:
And Apple's willing to say, yes, we'll break it.
Marco:
And we'll try to make it easy on you by having these translation tools.
Marco:
But that's it.
Marco:
That...
Marco:
It's going to end up being a really good language in all likelihood.
Marco:
I think even the Swift 2 changes, the changes they've made since last year, since 1.0, they did a number of updates over the winter and the spring, and they changed some pretty big things.
Marco:
And now with the officially named Swift 2, which seems kind of more like Swift 1.5, but whatever, with all that, they've made some really big improvements since 1.0 last year.
Marco:
And yeah, you're right.
Marco:
It's going to slow down.
Marco:
That's fine.
Marco:
And I'm totally fine to jump on when it slows down.
Marco:
And a lot of people, some of the people in chat are saying, and I've heard from a lot of people, don't you want to be part of this process?
Marco:
Don't you want to help direct the language with your input and get used to it now and become an expert in it now?
Marco:
And the answer to all of those is, no, I don't.
Marco:
I really don't.
Marco:
First of all, I think there's this division of programmers.
Marco:
There's people who are really into the tools for their own sake and the science of the tools and the design of languages, the design of tools, the art behind the language design.
Marco:
And then there's other people who don't really care about that and just want to use it.
Marco:
And they get satisfaction out of the things they build with it rather than necessarily the way they build them.
Marco:
I own the latter.
Marco:
I do not care about languages really much at all.
Marco:
That's why I try to learn as few languages as possible and choose to really deeply master them rather than exploring tons of languages that come out and being shallowly familiar with lots of them.
Marco:
And in some ways, that does hurt me.
Marco:
I think overall, I think I'm making the right decision for what I'm trying to accomplish, which is one person trying to write complete apps and write and maintain complete apps that do non-trivial things.
Marco:
I think my way is better for that approach.
Marco:
There are so many people who care so much about the language and how it's designed and what it can do and how it does it.
Marco:
They are willing to jump on early and they are willing to tolerate all the bumps and the source kit crashes and the changes in the syntax and the changes in the idioms and things.
Marco:
They're willing to do that.
Marco:
That's great.
Marco:
We need them to exist.
Marco:
But I don't need to be one of them.
Marco:
And I'm perfectly fine with that.
Marco:
And I appreciate what they do.
Marco:
And they probably think I'm an idiot, but that's fine.
Casey:
Yeah, I agree.
Casey:
I don't care about being a trailblazer anymore.
Casey:
And you've talked about this a lot, Marco, just now on Build and Analyze.
Casey:
Being a trailblazer when it's something that is important, when money is riding on it, that's just not my cup of tea.
Casey:
I'd rather use the old and boring technology, not as old and boring as PHP or Perl, but old and boring technology that is well proven and actually works well.
Casey:
And occasionally I'll fiddle like something that's fun and on the side.
Casey:
Like my website, for example.
Casey:
Node is reasonably stable as JavaScript frameworks that change every 10 seconds go.
Marco:
As long as your integers stay small and you have a lot of memory, then you're good.
Casey:
Then no problem.
Casey:
But that's not something that I'm really making any money off of.
Casey:
It's just my silly little website.
Casey:
I don't think I would be as keen on using Node if this was the sort of thing where money is riding on what I'm doing.
Casey:
So I'm with you.
Casey:
I don't get the architecture astronaut, like, you know, total...
Casey:
I don't know.
Casey:
I don't get off on that like I used to when I was a kid.
Casey:
It's just not my thing anymore.
John:
Pearl is far from boring, Casey.
John:
It's one thing you can say for Pearl.
John:
It's not boring.
John:
I would say the same thing for PHP.
John:
PHP is far from boring.
John:
It's perhaps the most exciting language ever made because it's terrifying.
John:
Every second, it will sell you the whole air on, but you only need the edge.
Marco:
Oh, God.
Marco:
All right.
Marco:
I think that wraps it up for this week.
Marco:
Thanks a lot to our three sponsors this week.
Marco:
Automatic, Squarespace, and Igloo.
Marco:
And we will see you next week.
John:
Now the show is over.
John:
They didn't even mean to begin.
Marco:
Because it was accidental.
John:
Oh, it was accidental.
John:
John didn't do any research.
John:
Margo and Casey wouldn't let him.
John:
Cause it was accidental.
John:
It was accidental.
John:
And you can find the show notes at ATP.FM.
John:
And if you're into Twitter.
Marco:
You can follow them at C-A-S-E-Y-L-I-S-S, so that's Casey Liss, M-A-R-C-O-A-R-M-N-T, Marco Arman, S-I-R-A-C, USA Syracuse.
Marco:
It's accidental.
Marco:
Accidental.
Casey:
They didn't mean to.
Casey:
Accidental.
Casey:
Accidental.
Casey:
Tech podcast so long.
John:
I think language wonk is the phrase you're looking for, not architecture astronaut.
Casey:
Yeah, I couldn't think of what it was.
Casey:
Thank you.
Marco:
The architecture astronauts, they're all working on Java and PHP.
Marco:
Oh, God.
Marco:
That's true.
Marco:
PHP got so badly infected by Java people.
Marco:
It drives me nuts.
John:
Yeah.
John:
But anyway, I am a language wonk.
John:
I like this language stuff.
John:
Hell, anyone who knows about the existence of and loves Perl 6 is definitely a language wonk.
Casey:
I mean, I don't have a problem with language wonkery, if such a thing is how you would describe it.
Casey:
I enjoy learning about Swift, but goodness, would I never consider using that, at least right now.
Casey:
I think you guys hit the nail on the head that the right time to use Swift is when the velocity of Swift kind of calms down a little bit.
Casey:
Maybe it doesn't stop moving forward or anything, but it just calms down.
Casey:
Now is not that time.
Marco:
Well, now might be that time, honestly.
John:
Yeah, I think it's close to that time.
John:
Like, because next year, like, all right, so we didn't even talk about the error handling.
John:
But anyway, error handling stuff was... There was a bunch of things that were obviously missing from Swift 1.
John:
And one of them was, how do you deal with errors?
John:
Because in-out params and NS error and all that crap was, like...
John:
ugly it did look it was it looked like a and was a thing that existed and fit in with the objective c language and app kit and all that stuff it wasn't a good fit for swift so now you've got their whole don't really call it exceptions because it's not really an exception but kind of exception handling in swift 2 that filled a big gap uh obviously i still want regular expressions
John:
uh maybe just of course just copy pearl six grammars and you'll be done um you got to save something for next year uh but but yeah like and now people looking at swift too it's all right what's left besides that the stuff that is mentioned now the picture is becoming clear and then the final thing that i think you're missing is all right who's going to be the first sucker to write uh a swift only framework uh
John:
uh or like to use swift in in earnest so that like because all the apis you're calling from swift are you know ui kit app kit things that were written originally in objective c and they've tried so hard to make it so that you can do things in a swifty way not knowing that there is you know an ns error parameter going in there like that's lots of magic having to do with bridging those two worlds um
John:
eventually you're gonna have to decide what does if you were to write a framework now starting from scratch and swift what would that look like right uh we don't know the answer to that but that's like the final piece of the puzzle and after that it's just just a matter of time so swift 2 swift 2.5 the dawning of swift 3 i think that is probably the sweet spot for
John:
Maybe not for Marco, but I think for most people doing, you know, if you're not a one person shop and you have to like make decisions based on like you don't have people like, oh, this guy can go off and he'll just learn Swift this year and he'll teach it to the rest of us.
John:
Marco doesn't have that option.
John:
But that's a reasonable time frame.
John:
And if you want to be on the cutting edge or you're young or you're coming in like.
John:
Say you're going to write your very first application and you're just out of school.
John:
That's the perfect time to learn Swift because you don't know Objective-C.
John:
There's no point in becoming an Objective-C expert right now.
John:
You might as well just go right into Swift.
John:
So Marco's decisions, as always, are not necessarily applicable to everyone listening.
Marco:
Oh, no.
Marco:
And somebody asked me on Twitter, I think two or three days ago, like, you know, I'm just starting out.
Marco:
Should I start with Swift?
Marco:
And I said, yeah, probably.
Marco:
Because I think, yeah, if you're starting from scratch right now, a year ago, I had a much more complicated, like, well, it depends, maybe.
Marco:
This year, you know, I'm saying almost certainly, yes, you should start with Swift.
Marco:
Like, if you're starting from scratch now, start there.
Marco:
But, you know, but if you...
Marco:
If you already are an Objective-C expert and you're trying to get a lot of work done quickly, it's hard to justify making the transition right now as opposed to, you know, in a year or two.
John:
I mean, but you should think back to your Go experience.
John:
Like, you had the same thing.
John:
Like, well, is it worth learning a new language?
John:
What are the benefits?
John:
And you have to speculate what is going to be the, you know, risk-reward strategy.
John:
like what what is the expected benefit of me spending this time to use go is he really going to make that much difference or are I just going to waste a bunch of time fighting with language I don't know that well and end up with something with a bunch of bugs and I think the go experiment worked out pretty well for you but going in you don't know for sure I think the uncertainty about Swift when it first came out was seriously Apple is this a thing are you really going to do this like people didn't didn't really believe uh maybe people who don't have a lot of experience with Apple like no they're deadly serious right it could still be a disaster like there's still room for disaster but
John:
So far, signs are good that it's not going to be entirely a disaster.
John:
And Apple seems very dedicated to it.
John:
I don't know if we talked about this in the last show, but we did in the pre-WWDC.
John:
So, hey, do you think we're going to see Swift on all the slides or Objective-C in Swift?
John:
And I think I said I thought it would be a mix.
John:
I think this year's WWDC, Apple tried very hard to make all of their examples use Swift.
John:
They failed.
John:
There were plenty of sessions with Objective-C in some or all of the examples.
John:
Some of them were exclusively Objective-C, but you could see the effort.
John:
It was like, wow, I'm surprised at the amount of Swift I'm seeing, and I'm shocked at how little Objective-C I'm seeing.
John:
Again, Apple can do that.
John:
It's top-down command and control.
John:
It's their conference, but they're clearly signaling their intent.
John:
Swift is the future of
Casey:
you know unless something super terrible happens yeah in all the sessions i went to i only noticed one and i don't recall which one it was that actually had objective c in it and everything else either had both or in more cases than than not uh only had swift which was relatively surprising to me that it was that quick but you're right john that they're pushing it and they're pushing it hard
John:
Yeah, just download all the WBC PDFs and search them in square brackets.
John:
You'll find out how many sessions I actually had.
John:
What was one of the ones?
John:
Was it Metal or what's new in SpriteKit or something?
John:
One of the sessions I went to seemed to not have any Swift.
John:
It was just square brackets, square brackets.
John:
It was like going back in time.
John:
You realize how how many of the other sessions are just like they don't even mention it.
John:
They're just like, oh, and here's this code and here's this and here's this.
John:
It's amazing they've done this.
John:
They made a new language suited for a new API with totally new idioms, but still able to call into all the old stuff with, you know, with all these conventions and all this crazy markup they're doing to objective.
John:
Oh, and they added generics to Objective-C so you could have typed collections, mostly to benefit Swift so they could tell that your NS array is full of NS strings and they don't have to make it full of any object in the Swift world.
John:
But hey, even if you're just in Objective-C, Marco, you could use the new generics thing if you feel like it.
John:
It's going to make you feel better about knowing that you have a homogenous set of objects inside your array instead of God knows what.
Marco:
Yeah, no, when I saw that, I was very happy with that.
Marco:
I mean, again, I'm probably going to start writing Swift code in the next year or two with the majority of my effort.
Marco:
But until then, and while I still have this fairly large Objective-C code base, that's very good to have.
Marco:
When Swift came out, it became pretty clear that almost every year before that, they were adding interesting features to Objective-C.
Marco:
And then when Swift came out last year, and they added basically nothing to Objective-C, the writing seemed like it was on the wall that, well, I guess that's the end of this language's progress.
Marco:
And
Marco:
Obviously, I think we're close to the end of this language's progress.
Marco:
But I think this is a nice little thing that, okay, well, even though it was in the service of making Swift interact better with this language, this language still is improving.
Marco:
And that is nice.
John:
The things they added to Objective-C before you knew Swift existed...
John:
almost all of those were also in service of swift in hindsight we now realize why does arc exist you know what that's the way memory management is done in swift instead of garbage collection like they or like test beds for things that would be necessary in swift or even just like if you want to go we just talked about how do we convert your swift one code to swift two code static analyzer lvm like think of pilot infrastructure all those things like boy this is great they're really enhancing objective c uh you know
John:
And you can draw a line through all those changes and say, hmm, this was all leading to make Swift possible.
John:
And if you look at the timeline, you know, some of it might have been happy accidents, but some of it is clearly intentionally like, I'm doing this for Swift, but it's going to be revealed to the world as an Objective-C slash compiler feature.
Marco:
Well, keep in mind also that Apple still has the vast majority of their code in Objective-C.
Marco:
We were even hearing not that long ago that their build system couldn't even include Swift yet.
Marco:
Their standard build procedure couldn't even do Swift yet as of fairly recently.
Marco:
It probably can now, I assume.
Marco:
But the fact is...
Marco:
Apple has probably the largest collection of Objective-C code in the world.
Marco:
And anything that benefits Objective-C benefits Apple.
Marco:
And so all these features, static analyzer, stuff like that, anything that helps Objective-C coding get more efficient and have fewer bugs, they could have just been doing for that.
John:
And I think it is... So that's how you sell the features.
John:
Because it's like, I have a Skunk Works project that seven people know about in a new language.
John:
here's what the new language needs it's like well okay how do you sell that well even if my new language ends up bust these are all great things for objectivity so we just do them anyway it's like all right keep going keep going it's just how you strategically pick the things you're going to enhance an objectivity hmm they all seem to and and they had to get rid of garbage collection which by the way is finally deprecated oh is it it wasn't already not not deprecated uh removed as in your you can't as in like the runtime doesn't support it anymore i'm pretty sure it either won't run or you can't build new ones with the new version of xcode or both
John:
But basically, it's the end of Garbage Collection.
John:
The supported life of Garbage Collection is now where it's been deprecated for years, right?
Casey:
Yeah, what else is going on?
Casey:
Programming!
Casey:
More of it?
John:
That's going on?
John:
I'm just saying that was this episode.
John:
Every once in a while, we do this.
Casey:
And we always get angry email.
John:
And people will have to endure it.
John:
Guess what?
John:
WWDC is a conference for developers, and we are all developers, even if not all for the same platform.
John:
And so it's impossible to soak in a week's worth of sessions about programming and not talk about programming.
John:
So we did.