The Opposite of Final
Marco:
hello everybody we are live from las vegas with our ces extravaganza i thought it was extravaganza is it extravaganza no not really no i'm just kidding instead we're going to talk about star wars for three hours
John:
There's a little exchange between one of our listeners and the ever watching, ever listening up there, folks.
John:
They're in the cloud.
John:
That's why I see everything.
John:
Peter Brockenhauer was tweeting at us about this and he said, an FYI up there is hosted on AWS.
John:
Little snitch told me so.
John:
AWS is Amazon's web services.
John:
and little snitch is a firewall program that tells you what your computer's connecting to yeah uh and up there on twitter responded not true we built our own stack from the ground up and host our service on this stack so i'm not quite sure what little snitch was on about maybe it connects to aws or some ancillary things but straight from the up there horse's mouse mouth they are not using aws they have built their own stack which is what i was talking about in the last show whatever mysterious technology they're using
John:
Presumably the whole point of the company is not to write an iOS and a Mac app that connects to S3.
John:
Like that's not, you don't, I don't, I don't think Bertrand Serlet would do a startup and focus on that because there's a million of those things already.
Marco:
Well, I mean, they could have also just been working a layer above that.
Marco:
Like, they could have been using EC2 servers or, like, some other part of AWS as part of their... You know, just like how iCloud uses some AWS stuff and some Azure stuff, as far as we knew forever ago.
John:
Yeah, but, like, what would they use for me?
John:
Even EC2, like, I don't know.
John:
It just seems counter... Because that's all there is.
John:
That's all there is stuff there.
John:
There's no... iCloud is built on top of it.
John:
There's a whole bunch of other stuff.
John:
Like, that's just this...
John:
You could use S3 for the storage backend, or if you don't want to have your own data centers or whatever, maybe you could EC2 for compute stuff.
John:
But I don't know.
John:
I just always imagine whatever they're doing being more interesting than that.
Casey:
Fair enough.
Casey:
Any other follow-up?
John:
I threw this in follow-up just because it's... I don't know if there's any information here, but it's... You threw in some follow-up just because you couldn't stand to not have any...
John:
No, I mean, I had this in the topic section before, but I said, you know, we talked about this on a past show, and so it's kind of follow-up, but I'm not sure how filled with information it is.
John:
A friend of mine was messaging me today, and he's like, so how do you feel about the headphone port going away from the iPhone 7?
John:
And I said, A, you obviously don't listen to my podcast.
John:
And B, what are you talking about?
John:
Did I miss some news or something?
John:
He's like, oh, yeah, they were talking about it before, but it wasn't confirmed until today.
John:
I'm like, what are you talking about?
John:
I really thought that Apple had announced that there was going to be no headphone port on the iPhone 7.
John:
i forget that regular people don't know what confirmed means so this is a forbes article wow this is a forbes article that says the headline is iphone 7 leaks confirm in single quotes apple abandoning headphone jack i said they put they they did the work for you they put it in scare quotes in the headline at least they have the decency to say confirm i'm doing air quotes now confirm anyway uh more so we talked a lot about this on a past show uh
John:
um more rumors more supposed park leaks this one has a neat little concept image because if you're gonna have a rumor story you gotta have someone do a mock-up image of the iphone 7 and i'm looking at this mock-up image and what do you guys think it looks a little thin to me but anyway this is more smoke for this potential fire of the headphone port going away i don't know i think it's too early to make any kind of call but
John:
Not that Forbes has a great track record, but it's making me think about it again.
John:
It's making me think how Apple could explain this inevitability, if not this year, then next, or the year after, or the year after.
John:
And I think a lot of the stuff in this article is a good way that they might explain it.
John:
The idea being that...
John:
The phone would be smart about where it sends its audio output, depending on context.
John:
I wish all of Apple's devices would get smarter this way.
John:
All of Apple's service and devices.
John:
So if I'm listening on my wireless headphones, you know, I'm in my car, it's playing through Bluetooth.
John:
I get out of the car, it's just on my wireless earbuds or whatever.
John:
I sit down at my desk and it switches to outputting through the headphone jack of my computer or something.
John:
You know what I mean?
John:
Like situational awareness where you don't have to be plugging and unplugging things where it will just know based on your location, what other devices there, what your preferred sound output devices that.
John:
And then you say, I see.
John:
Isn't that better than a headphone jack?
John:
And you say, yeah, that actually works.
John:
That would kind of be better than a headphone jack.
John:
And it lets you make your phone thinner.
John:
So everybody's happy.
John:
I don't know if that world is going to arrive in time for the iPhone 7, but it's one way to sell this feature, I guess.
Marco:
Yeah, I mean, we talked about this to death a few episodes back, so I don't think we should spend too much time on it.
Marco:
But I do think that the world of not having the headphone jack is probably on its way.
Marco:
I think, as we discussed last time, it's probably still a few years off.
Marco:
I mean, I think one of the biggest supports for this is to look at the MacBook 1.
Marco:
And the MacBook One has two ports, the multipurpose USB-C slash charging port and a headphone jack.
Marco:
And they couldn't justify any other ports on that, but they could justify a headphone jack.
Marco:
And I think that goes to show just how often they're used.
Marco:
And Bluetooth headphones do exist.
Marco:
They've used it for quite some time.
Marco:
There are some decent ones.
Marco:
There are very few good or even great ones.
Marco:
And there's a lot of tradeoffs to Bluetooth headphones that make them not only less good in some ways, but actually unusable for certain applications.
Marco:
So it's...
Marco:
It is not a clean transition.
Marco:
I'm guessing that that one kind of crazy translated a million times from different languages story that we got back then, back a month ago or two, that one story about how there would just be a passive special lightning adapter for this new revision of the lightning port that would...
Marco:
basically have a DAC on the phone and have it be able to send analog audio through a cheap passive adapter through the port into a headphone jack port through a little breakout cable.
Marco:
I think that's pretty plausible.
Marco:
And so that, I think, is the most plausible explanation I've heard for why this might not be a big deal, is if they can make a cheap little passive adapter like that and just sell that to you or even include one in the box if it's really that cheap and passive.
Marco:
They probably won't.
Marco:
It'll be more likely they would sell it for $30, but we can dream.
Marco:
But I think where there's smoke, there's usually some fire, and I think there's enough smoke around this that I would move it from unlikely to somewhat likely.
Marco:
And I think if we consider that special lightning adapter, passive adapter thing, that makes it more, I don't know, digestible.
John:
it's like it makes it suck less basically with all these type of stories like there's a build to the inevitability until we eventually get the real parts leaks especially with the phones you know as the date of the new phone approaches we're pretty far away now so i was thinking that this next round of stories about this rumor nudge it slightly more towards the realm of possibility but it's still so far out that
John:
It's within the realm of things that could end up being totally wrong, but we'll keep watching.
John:
We'll keep watching it nudge ever closer.
John:
I mean, we'll basically know for sure when the real parts leaks come out because I don't think we've had a significant iPhone revision in a long time where we haven't gotten a look at pretty much every piece of this thing.
John:
well disassembled uh before it arrives i mean we'll probably know like by april or may i mean and especially like this like you may not know everything like because can you not you can't figure out all the the software features obviously and then the hardware features sometimes are hard to tell from parts but things like uh does it have a hole for the headphone port to go in we'll be able to tell it just by looking at cases yeah and like the back case is often one of the very first parts to leak so it can't probably that's what i'm saying like we'll probably know this one by the spring you know really
Casey:
All right.
Casey:
What's awesome these days, Marco?
Marco:
Our first sponsor this week is audible.com.
Marco:
Audible.com has more than 180,000 audiobooks and spoken word audio products.
Marco:
Get a free 30-day trial at audible.com slash ATP.
Marco:
If you want to listen to it, Audible has it.
Marco:
Listen to audiobooks from virtually every genre, anytime, anywhere.
Marco:
You can play Audible's audiobooks on phones, tablets, computers, most Kindles, even iPods if you're Stephen Hackett.
Marco:
Now, audiobooks are great for flights, long road trips, even your daily commute.
Marco:
You may think you don't have time to read books, but you'd be surprised how many audiobooks you can hear each year, even if you only listen to and from work every day.
Marco:
With more than 180,000 audiobooks and spoken word audio products, you will find what you're looking for.
Marco:
We have a book recommendation, don't we?
Casey:
Indeed.
Casey:
I believe John has one and I have one if you'd like one as well.
Marco:
We'll do John's this time and yours next time.
Marco:
How's that?
Marco:
Sounds good.
Casey:
Or do you want to go first?
Casey:
No, no, no.
Casey:
It's cool.
Casey:
Especially since John is going to make fun of my book selection.
Casey:
So we can definitely save that.
Casey:
Oh, let's do yours then.
Casey:
Shouldn't have said it.
Casey:
So I really enjoyed the book Ready Player One by Ernest Cline, which I made the mistake of listening to The Incomparable about it.
Casey:
And they basically spent an hour and a half talking about how terrible it is.
Casey:
Anyway, his second book came out, I believe it was in 2015.
Casey:
I could be wrong about that.
Casey:
And it's called Armada.
Casey:
And it is not as good as Ready Player One, which at this point, John is seriously rolling his eyes.
Casey:
But it is good.
Casey:
I did like it.
Casey:
If you happen to be a fan of Ender's Game, you'll like this and or Ready Player One.
Casey:
And it is also narrated by Wil Wheaton, who is kind of an internet darling.
Casey:
And I mean that in a not sarcastic way, in a not derisive way.
Casey:
So I definitely recommend it.
Casey:
It's apparently just a shade under 12 hours.
Casey:
So that's what, like two ATP episodes?
Casey:
And it's available on Audible.
Marco:
So check it out today with more than 180,000 audiobooks and spoken word audio products.
Marco:
You will find what you're looking for.
Marco:
Get a free 30-day trial today by signing up at audible.com slash ATP.
Marco:
That's audible.com slash ATP.
Marco:
Thanks to Audible for sponsoring our show.
John:
Ready Player One is mostly harmless, silly, garbage.
John:
You really sold it, John.
John:
We had fun making fun of it on The Incomparable, but it's all in good fun.
John:
I think just because we had a lot of things where it's easy to ridicule the book and poke at it and find flaws, it's still a fun read.
John:
I don't regret reading it.
John:
i guess that makes me feel a little better it's not i don't like to use guilty pleasure because i don't like that concept but it's kind of like it's like junk food it's like a bag of potato chips whatever just chomp it down it's fine
Casey:
goodness all right well anyway um yeah you should check out you should check out audible all right so what else are we talking tonight talking about tonight uh we see that somebody has fixed apple's grievous mistake with the macbook one there's two kinds of mistakes or just two things that i just happened to see recently and i'm sure there's more um the macbook one has got the one little lonely usb type c port on the side of it but usb type c can do all sorts of stuff
John:
um that's why it's one port you can put the power through it uh and you can do all sorts of other things and so the first uh link in this uh two links set here is for a griffin device that you plug into your usbc port on your macbook one
John:
And it gives you back a MagSafe connector, sort of.
John:
Basically a magnetic thing that if someone trips over the cord, it will become disconnected.
John:
Now, I find this interesting for a couple of reasons.
John:
When we were first talking about the MacBook One, we, of course, discussed the fact that this one connector also replaces MagSafe.
John:
What happened to MagSafe?
John:
Isn't MagSafe great?
John:
Doesn't everybody love MagSafe?
John:
Doesn't everybody love being able to trip over a cord and not have it yank your computer off the thing or break your adapter or whatever?
John:
Isn't MagSafe a great feature?
John:
Why would they get rid of it?
John:
And my question, which I still don't have an answer to because I don't have one of these and neither do any of us, was maybe you don't need MagSafe because maybe the USB-C connector is so small that if you trip over it, it just pops out anyway harmlessly.
John:
Like the connector is so small that MagSafe is no longer needed.
John:
I still don't know if that's the case.
John:
Obviously, Griffin thinks that people think it's not the case.
John:
Or maybe they know themselves that it's not the case.
John:
But they're saying, hey, buy this adapter whose sole purpose is to provide a magnetic breakaway connection for the power for your laptop.
John:
And I don't know.
John:
I feel like I would buy this thing, buy the laptop by itself, and I would see.
John:
It is tripping over the... I mean, I don't know how I would find out.
John:
Maybe I'd find out by yanking the thing onto the floor and watching the screen crack or something.
John:
Maybe just do some experiments to see.
John:
But boy, it seems a long way to go to fill the one and only port on your thing with this giant adapter, $40 giant adapter, not yet available, that gives you a big magnetic thing.
John:
Weird, weird product, weird product.
Marco:
Yeah, this is, I don't know.
Marco:
Whenever there's a computer or technology thing that comes out and lacks something that came before it, there's always a market for third parties to come in and offer the comforts of the previous thing in some kind of bolt-on thing that costs between $40 and $100.
Marco:
This is true of all technology whenever any progress is made.
Marco:
And sometimes it's worth using.
Marco:
Usually it's not.
Marco:
In this case... And Griffin's stuff, I've had... Honestly, I've had mixed success with Griffin's stuff.
Marco:
So I'm not even sure I would trust this to work and be of high quality.
Marco:
So I don't know.
Marco:
I don't really see...
Marco:
why people would want to to go through the hassle of this and as you said to kind of like bulk up that port ruin that port i don't know it doesn't seem it seems like this is a problem that that is not worth solving because the solution to it is too clunky itself
John:
I don't even know if it's a problem.
John:
Like we don't know.
John:
And the other thing is there's no USB pass-through.
John:
This take your one and only port.
John:
This fills it with power and that's it.
John:
So, you know, I can't believe they didn't even provide a pass-through so you could.
John:
You sure about that?
John:
That makes it suck, really.
John:
Yeah.
John:
So $40 to fill the one port.
John:
Anyway, it shows like that's kind of how product companies work.
John:
Like you said, you hit the nail right on the head saying someone always makes one of these things.
John:
And it's mostly to make people, like you said, feel more comfortable.
John:
Like I used to have MagSafe.
John:
And regardless of whether I need MagSafe now, I want to still have it because it makes me feel comfortable.
John:
Maybe it's needed.
John:
I don't know.
John:
I haven't done the experiment, and as far as I know, nobody has.
Marco:
Another solution to this would be if Apple just put enough battery life in that laptop that you wouldn't need to plug it in all day.
Marco:
You've got to plug it in sometime.
John:
Even if you're just putting it somewhere to charge and someone walks by your desk and yanks the thing.
Marco:
Yeah, but the MacBook One has pretty mediocre battery life among the rest of the lineup.
Marco:
It's pretty small.
Marco:
Yeah.
Marco:
The Skylake revision will presumably get noticeably better, but it's still going to probably require being plugged in if you're using it all day.
John:
so the next one is another thing that takes advantage of the versatility of the usb type c port it is even bigger it's a big like rectangular thing that pokes out the side of your macbook one but it gives you a whole mess of ports it gives you two big normal size usb it gives you sd card looks like a cf card and also has to pass through for usbc and this one is from hyper
Casey:
This looks nice to me.
Casey:
I was just talking at work today with someone.
Casey:
So I think I'd mentioned in the past that where I'm working these days, there are cinema displays everywhere, or well, really Thunderbolt displays, I should say.
Casey:
And I've always been so jealous because I've always kind of wanted one of those so that I could just sit my laptop down, plug in just a couple of cables, and then I'd be connected to Ethernet and my microphone and whatnot.
Casey:
And
Casey:
And this is a $50 on sale, you know, like kind of mini docking station.
Casey:
And although it doesn't have Ethernet, which is a little bit of a bummer, this is the sort of thing that if I had a MacBook one, I would absolutely stick one of these on my desk and make it a little easier to use.
Marco:
What's promising about this, too, is there have always been similar products, although never very many of them, for Thunderbolt.
Marco:
And they were always basically from $200 and up.
Marco:
So it's promising that USB-C stuff is so cheap to make, even though it is obviously a little more limited technically than Thunderbolt.
John:
but this is nice what's it a few more interesting things first of all this is very very small and it like seems to fit the profile pretty well of the laptop so that's nice yeah it is small but like it's compared it's a small laptop compared to the size it adds significantly to the laptop percentage wise i feel like like it changes you from your little tiny portable thing to something that's really big and here's the thing that worries me a lot when i look at it
John:
Is the USB-C port the only mechanical connection between this, again, like, small and absolute size, but large and relative size?
John:
Is that the only connection to the thing?
John:
Like, what if you tried to pick this thing up from the side with the adapter on it and accidentally grabbed a little bit below the USB-C port?
John:
Would you twist and crack the thing off?
John:
It doesn't seem to have any other...
John:
means of connecting itself to the thing other than the usbc but i'm sure it's it's lightweight and everything it just what it looks like is extending your laptop sideways by an inch but it's not it's like i don't know it just seems like it is a lever made to break that connector
Marco:
Yeah, that's a good point.
Marco:
Well, and again, you can look at this stuff.
Marco:
I think if you're going to be connecting things to your MacBook on a regular basis, the MacBook One is probably not the right model for you.
Marco:
Because we know a lot of people who have these things, most of whom love them.
Marco:
And the number one thing we hear from these people who love them whenever the port conversation comes up is they don't really ever plug anything in, so it's fine.
Marco:
And I think if you're going to be plugging things in, just get either an Air or the presumed soon-to-becoming Skylake 13-inch Pro, which should probably be pretty competitive thinness and lightness-wise to the 13-inch Air, but we'll see.
John:
yeah i dig this though especially the price like you said mark i mean that is stunningly cheap yeah 50 bucks i mean you can't get a thunderbolt cable for 50 bucks seriously well you probably can now please don't email me but you couldn't at first it reminds me of like a pc peripheral because it's like a cf card reader really no it's not it's not no no it's sd and micro sd yeah well yeah maybe i'm misjudging the size then because everything is relative to the size of the macbook and i keep forgetting how darn small that thing actually is so yeah
John:
But anyway, the SD and the micro SD, if you took out those two slots, then you wouldn't have such a long lever with which to crack off the USB-C connector.
John:
But, you know, then there would be it's almost as if I think like go full length and just add like seven more slots or go even shorter and just add the full size USB.
John:
you know, and the pastor, I don't know.
John:
I don't know.
John:
Anyway, people apparently buying them.
John:
So like I said, you can't really go that far wrong for 50 bucks.
John:
And I would definitely recommend this for people who have their laptop on their desk, like not for people who are constantly picking it up and carrying it from place to place.
John:
Or if you want to travel with it and like, if you want to be like on the plane, but you have like plain old USB peripherals that you need to use, or you want to be swapping SD cards to do, but you know, pulling pictures off cameras while you're sitting in your plane seat.
John:
I wouldn't want this thing hanging out the side while I'm trying to handle my thing on the tray.
John:
Anyway.
Marco:
Well, see, to me, I think this would actually, I would go the opposite way.
Marco:
I would say for a desk, you'd want something with like one cable that plugs in and then has some kind of breakout box with the other stuff in it.
Marco:
That way you can kind of get it away from the side of the computer and not have the stress on there every single day and kind of make a cleaner desk if you can hide that stuff somewhere behind the desk or under it or whatever.
Marco:
Whereas this one, I think, would be better for travel because you get adaptability to these three different port types in one small thing that doesn't have itself its own cable.
Marco:
So for size and tidiness in a travel bag full of other cables and adapters and computer junk, this would actually be a big win, I think.
John:
I was saying on the desk, uh, mostly because then there's less chance of someone lifting it up and cracking the thing off.
John:
You know what I mean?
John:
Cause it's like, it's laying flat on the desk and you can manipulate it and stick the things into it.
John:
But you're right.
John:
Like on a desk, even better would be a cable that snakes away from the thing.
John:
And it does work well for travel in terms of clutter, but I don't know.
John:
It just makes me nervous just looking at it.
John:
Like I keep looking at the closer pictures.
John:
Like it really is just that little tiny connect there.
John:
It just, it doesn't seem, it doesn't seem right.
Yeah.
John:
yeah that that would make me nervous as well to be honest but i mean it's not and the thing is i think you're not going to break the computer with that you're going to break the adapter because the computer has the aluminum case like laser cut opening around that that's not you're not going to break the computer by twisting the thing i feel like you're going to break the or maybe it would be just a battle between the two pieces of aluminum to see which one i don't know the world's least interesting battle yeah well it's exactly all these people are doing like the uh what was it uh
John:
mkb hd or whatever was doing his uh stabbing the the iphone 6 supposed iphone 6 screens with a knife and everything we need the even more boring equivalent of that of let's let's stress test the connector on this usb hub type thing because that's that's our domain if we had a youtube channel it would be all usb hubs
Marco:
okay you hear it you heard it here first hyper shop send us one of these to review along with a macbook one that you don't want and we will do this test on the air for you marco will film it on his fancy still image camera that's also kind of a video camera yeah yeah goodness all right anything else on this thing
Marco:
I can't believe this is the news this week.
Marco:
This is why I hate CES, because the only news that happens is either pie-in-the-sky stuff that will never come out, or USB port news.
John:
There was some CES news.
John:
People keep sending me the stories about the OLED TVs that are going to be shown or announced at CES, and maybe they have been by today, but I haven't caught up on the stories.
John:
I
John:
I basically just wait for CES to be over and then find the summary stories to pick out the three things that were actually good or interesting at CES and then just read that.
John:
That's really all.
John:
But CES is good for people who are interested in TVs.
John:
You either find out that it's not an interesting year where nothing good has happened or you find out like, oh, everyone is still obsessed with 3D or everyone is still obsessed with curved screens or some other gimmick that you don't like.
John:
This year, the gimmick seems to be high dynamic range.
John:
which I am interested in and I hope is an emerging standard and will be like this is a picture.
John:
It's a legitimate picture quality improvement, not something that's gimmicky like 3D and not something that's ridiculous like the curve.
John:
So I'm glad for that to be the new thing this year.
John:
But if it's the new thing this year, that means all the televisions that have any kind of support for this this year are going to be like the very first generation that tries to support it.
John:
And maybe they're competing standards and that's all got to work itself out.
John:
So it's still,
John:
not time to buy a tv but i would like to read about that but i haven't yet so i don't think ces is a total loss it's just like a 98 loss wow what a low bar that we've said oh god so so john your summary of the tv news coming out of ces is i haven't read it yet that's my i will give next week i will know more but yeah my summary is it seems like uh dynamic range is the thing this year
John:
And I don't know whether everyone is over the curved screen thing yet.
John:
Breaking.
Marco:
I would love to send you to Las Vegas for this week just to capture the misery of that trip.
Marco:
I would go for that if it was just to film you being there.
John:
Nobody wants to go to CES.
John:
Nobody does.
John:
That's the thing that I think people don't understand.
John:
For those of us who know a lot of people who cover CES as part of their job, nobody likes it.
John:
Like people like going to back in the day, people like going to Macworld to cover it.
John:
If you're interested in Apple stuff, people like going to WWDC.
John:
People like going to Google IO.
John:
If you're interested in Google stuff, nobody likes going to CS.
John:
Nobody.
John:
I think a lot about who is this for?
John:
And I guess it's, is it for like retailers or advertisers?
John:
Yeah.
Casey:
John, it's the Consumer Electronics Show.
Casey:
Come on.
Marco:
I mean, it seems like there's a lot of legitimate reasons for some people to be there.
Marco:
It seems like there's a lot of meeting with the reps that happens in private meetings that can be very useful to people.
Marco:
But to actually be on the show floor, I don't really know who that's for necessarily.
Marco:
Besides people who are tasked with covering it and who, as you said, usually hate this job because it is grueling and pretty intense.
John:
but even the people who are meeting with the reps behind closed doors i think they like the meetings but they wish they could meet basically anywhere in the world other than ces like i'll come to your city where is your company located i will fly to your city and do i mean i guess maybe it's i just i just never heard anyone say i can't wait to go to ces nobody not vendors not people who are going to meet with vendors
John:
like maybe the only circles on traveling are like people who are like a some a buyer for a big store chain like the best buy person or something who wants to go to see what they're gonna buy for that maybe they look forward to it it just seems it's like the worst of it think of everything that's bad about conferences and concentrate it and then i can multiply it by five it's kind of like e3 used to be but at least e3 was exciting for people who weren't there like even when e3 was at its worst i've never been to e3 but i know a lot of people have even when e3 was at its worst it was just completely overblown
John:
and uh nobody really you know it was exhausting and nobody wanted to cover it it was exciting for people who weren't there because you would say i can't wait to see what's announced at e3 so you know if you want you wanted to read the coverage you get excited but my impression of ces is that people who are there don't want to be there and people who aren't there don't want to read about it it's mysterious
Marco:
We'll be right back.
Marco:
Thank you.
Marco:
Everything can be optionally social with comments, like buttons, revisions, messages, and anyone can add content based on their permissions with drag and drop widgets and a what you see is what you get editor.
Marco:
And Igloo makes use of responsive web design, so it looks fantastic on all of your devices.
Marco:
Whether they exist today or whether they're going to come out tomorrow, it'll already look good because it is fully responsive, modern web design with modern social and collaborative features so that you won't have your employees going out to use things like Dropbox and Twitter and all this stuff that is public that you want to keep this stuff inside your company, inside your intranet.
Marco:
Igloo is very corporate-friendly.
Marco:
They're very secure.
Marco:
They have all these granular permissions, all the stuff that you need to sell to your company.
Marco:
It's even free to use forever for up to 10 people.
Marco:
So check it out today, igloosoftware.com slash ATP.
Marco:
Free to use up to 10 people and very reasonably priced after that.
Marco:
And at any size, you get a free trial.
Marco:
So check it out today, igloosoftware.com slash ATP for that free trial.
Marco:
Get started now.
Marco:
Thanks a lot to Igloo, the intranet you will actually like.
Casey:
So, a few weeks ago, we started talking about Swift being open-sourced, and then we got sidetracked by... I'm not even sure what.
Casey:
But here we are again, scraping at the bottom of the barrel.
Casey:
So, why don't we talk a little more about Swift open-source, and actually talk about something that's cool, which is the Swift Code of Conduct.
Marco:
Or if you want to be talking about the Mac Pro some more.
Casey:
So, about the Swift Code of Conduct.
John:
Yeah, we'll get to the equivalent of... Well, we'll get to some programming topic after this.
John:
But the Code of Conduct is a thing...
John:
that has been happening over the past i'd say year or so has become more popular every sort of open source project or volunteer based community thing or conferences around sort of any sort of ad hoc collection of uh people especially in the tech world has been starting to have an actual written down code of conduct that is exactly what it sounds like it's sort of a set a set of rules or expectations of behavior like
John:
Just to give examples, you could have a code of conduct for, I don't know, a website where people join and want to talk about knitting.
John:
And the code of conduct could say, if you want to participate in our knitting forums and talk about knitting, we don't want you to use curse words or whatever.
John:
Uh, and then you can decide, Hey, I don't want to be part of a community where I can't curse.
John:
So you won't join that knitting community.
John:
Right.
John:
But it sets clear expectations.
John:
Like here is how we expect people to behave.
John:
And it gives you something like if someone misbehaves, you can point into the code of conduct and say, Hey, we have a code of conduct here.
John:
This is how it's going to be.
John:
These are the rules.
John:
If you don't like it, you should go someplace that has a different set of rules.
John:
Um,
John:
And it's like that for open source projects or conferences where like, hey, I'm going to show up to this conference.
John:
It's going to be a conference in my favorite programming language.
John:
And there's going to be talks and everything.
John:
What are the expectations?
John:
What kind of behavior is and isn't allowed?
John:
How are the people in this community expected to behave?
John:
There's been minimal pushback to the idea of a code of conduct because a lot of nerds are very literal minded and don't really see the nuances and things as a code of conduct doesn't actually make people behave in a certain way.
John:
You're right.
John:
It doesn't.
John:
But by writing it down, you're setting expectations like you do for kids or whatever or any sort of it just it's it's more comfortable to know.
John:
what is expected because that lets everybody decide if they want to be a part of a community with this set of sort of rules and guidelines if you know getting the knitting thing if you think not being allowed to curse is stupid you know right away this is not the knitting community for me i should go someplace else where people are knitting and also like the curse right um and on the other stuff in terms of like making jokes at other people's expense or like uh any sort of uh uh
John:
aggressive behavior and even just writing down stuff like no violence no hitting other people so again it's mostly like you do for little kids you set the expectations of you know here's how you're expected to behave in preschool no biting your friends we expect you to share when the teacher is talking we expect you to listen you know everybody eats at this time and naps at this time or whatever it doesn't mean that's all going to happen but you just want to write it down
John:
And like I said, the pushback is mostly of people thinking that, are you saying if we don't have a code of conduct, we allow those things?
John:
Or this stuff should go without saying?
John:
Or writing it down makes it seem like we are telling people that are coming here that are going to behave badly.
John:
Why do we need to write down stuff like don't murder people like they should know that already?
John:
Or are you trying to make it sound like we're a bunch of murderers here?
John:
Or really what's under the covers a lot of it is,
John:
Say, just coming up with the code of conduct can be like, especially on like programming projects or whatever, like if there are debates about technical issues, which we'll get to in a second, debate the issue.
John:
Don't debate the person.
John:
Don't.
John:
No ad hominem attacks when you're discussing some feature of some programming language or open source project issues.
John:
don't call the other people the person a jerk or an idiot do not attack the person or that person's personal history keep your debate to the topic at hand and again this may sound like yeah these all sound like reasonable rules whatever it's like little things to do for kids but at a certain point people push back against it an example is the linux kernel mailing list where uh linus torvalds or linus or whatever you want to say it
John:
uh the creator of linux very often is uses very salty language so again like the knitting forum uh linux kernel mailing list totally allowed to use curse words that's in you know if they had a code conduct which i'm not sure if they do but if they did it would be in there because that's that's sort of what they expect
John:
and has been known to say pretty mean things about people not just about their thing you know like it's it's a it's a there is a fine line am i calling when i say this is the stupid idea i've ever heard i'm kind of criticizing the idea but i'm also kind of being mean about it or whatever anyway that community has pushed back against the idea of trying to be more civil to each other or more civil to each other's ideas or anything like that so that's you know that's the kind of community they want if you were to come in there and they were to try to come up with a code of conduct
John:
uh and they make a set of rules that past behavior doesn't fit into the people with that past behavior feel like they're now being excluded from the community that they're an important part of anyway um all this is a big rambly way to say that swift is doing what i think is the right thing which is from the very beginning having a code of conduct and i looked at the code of conduct and it seems pretty sane and and pretty tame and i think
John:
it is a good thing for anybody whether it's in a preschool or a knitting club or an open source project or a website or a web form or anything to write down their code of conduct as early as possible and revisit it as needed and amend it and clarify and so on and so forth just to have a starting point and a guideline instead of just assuming everybody will behave and all agree about what proper behavior is
Casey:
Yeah.
Casey:
Yeah.
Casey:
And I agree with you that this is a good thing to have.
Casey:
This reminds me of the post by – was it Randy Harper?
Casey:
Is that right?
Marco:
Because that shows what happens if you don't have a code of conduct and if you don't think about these issues.
Casey:
Right.
Casey:
So she had posted – this is FreeBSD – well, the woman who used to be known as FreeBSD Girl, she –
Casey:
She posted recently a really, really good and not terribly long post about how she was treated in the BSD community, and it's really pretty deplorable.
Casey:
And you could argue, just like Marco just said, that that is in no small part because they didn't really have an established code of conduct.
Casey:
And then even when they did, if you believe what she says, which I do, they didn't act fairly once there were issues escalated.
Casey:
which is really too bad.
Casey:
But we'll put a link to that in the show notes.
Casey:
And if you work in any sort of community, I highly recommend reading her post because it was fascinating.
John:
And a code of conduct, as many people point out, does not guarantee good behavior because there's issues of enforcement and there's debates about how should things be enforced?
John:
Is it enforceable at all?
John:
Like,
John:
another reason people shy away from code of conducts is they think it opens up this big can of worms and they all have to debate but these are these are important things to talk about and it's better to talk about them before anything has happened like sort it out amongst yourselves not in not in light of some actual event because it's so much harder to figure it out and like you know it's very difficult to come up with a good set of rules and to figure out how you're going to enforce them and to follow through on it but it's
John:
it's so much better to engage in that process than to bury your head in the sand because engaging that process will first of all for people making the policies it will force you to think about things like hopefully you'll go and say let me look at other people's code of conduct let me look what they wrote down and i think collectively all the codes of conducts of various communities and open source projects are getting better by looking at each other in the open source kind of way and say what have they written down how they phrase this what kind oh i didn't even think of that we should put that in too because i believe in that but it wouldn't have even occurred to me to write it because
John:
is i'm not in that group of marginalized people and didn't realize it was a thing we had to write down but i totally agree with it now that i see it and you know get it all down ahead of time um and then you're gonna have uh you know incidents and then you have to figure out how to deal with them and then you look at how other people dealt with events and read you know read randy's thing and say
John:
here's how this community tried to deal with this event and here's how it went badly how can we avoid that what kind of policies can we have in place to help with it no one's going to be perfect it's not a guarantee of anything it just shows that you are engaged in the process that you are committed to the idea that you can manage your community to be
John:
what you want it to be to be a more welcoming community to be a successful community for the kind of people that you want you can make a code of conduct that sets totally different kinds of rules but it's so much better to just think about like who do i want who do i want here do i want people who are really technically skilled but also really really angry and mean all the time if you want that like right into your code of conduct like
John:
that there's an expectation that you'll be berated and cursed at um and we only accept people who have you know the highest of skills like build the community you want for yourself whatever it is that you want but it's much better to to take on that task as an actual thing rather than falling ass backwards into it it's sort of like you just end up with this community and you're not quite sure how you got there um
John:
So that's what I think the important part is.
John:
And Swift is very sensible and they're coming relatively late in the game because Swift wasn't an open source project until recently.
John:
And I think they're benefiting from all the other code of conducts that have come before them.
John:
And at this point, it's kind of the type of thing where if you are a community or an open source project without a code of conduct, people are going to ask, why?
John:
Why don't you have one?
John:
maybe you should think about not that they're saying you're bad or anything but they're saying you may not have thought too much about this but history has shown that this is a good thing to have and the act of thinking about it will lead you to be a better community agreed
Casey:
All right, what else is going on with Swift?
John:
This is a programmer-y topic.
John:
I don't know if Marco talks all about all these on Under the Radar, but I saved one for here.
John:
I don't think you got to this one because it's kind of esoteric, but I continue to follow the Swift Evolution mailing list, or try to follow anyway.
John:
It's still pretty high volume.
John:
People talk about the future of Swift.
John:
And make proposals and debate them and go through all sorts of other things.
John:
This big process of evolving Swift is becoming more formalized with different phases of whatever.
John:
Anyway, this one particular proposal that I thought started to get at the heart of what seems to be one of the big internal struggles between Swift and the community formerly known as the Objective-C development community.
John:
I guess they're still known as that.
John:
But anyway, all the people who are writing all the code in Objective-C...
John:
uh and apple is saying you guys should think about moving swift at some point because we are and this is a debate around things that are allowed and disallowed static and dynamic uh you know free or clamped down and this particular one is about whether classes should be final by default in swift as in uh
John:
if you don't say anything one way or the other and you define a class in swift should that class be subclassable and amendable and be able to be you know extended and have things overridden or by default should it be all closed up and you can't screw with it and it's not really a question about capability because no one is saying all classes should be all closed up and final or all classes should be open it's just a question of what the defaults are and the defaults have two effects one is
John:
um obviously it affects uh the actual code because a lot of people just take the default right uh you know and and so if no one does anything and they just declare class they don't know about this particular keyword they don't think about it what do they get by default and the second thing is by choosing the default if people think about it for a little bit they'll see it's like a signal from the design of the language we think most of your classes should be like this it's the default um
John:
But if you have special needs, make your class like this.
John:
And like I think in Java, you know, the default is not final.
John:
I don't know anything about Java.
John:
I think that's the case.
John:
And so what they're saying is by default in Java, if you declare a class, you can subclass it.
John:
But we think that's the common case.
John:
But if you have special needs, like say for performance reasons or you really don't want people extending your class, you can declare it to be final by adding this other keyword.
John:
And so that means that most people who just like a Java class, blah, blah, blah, blah, blah.
John:
They're all getting classes that can be subclass and extend and all that other stuff because that's the default.
John:
And also, philosophically speaking, it's so clear that Java really expects people to subclass your stuff and that the exception to the rule is, oh, you want to make your thing final and be all closed off or whatever.
John:
Sorry if I'm getting this Java mistake.
John:
This Java default thing backwards.
John:
I haven't touched Java in a really long time.
Marco:
Somebody named javanut13 in the chat says it is not final by default, and I think they would probably know because their name is javanut.
John:
Well, yeah, there's no way they could have changed their username to javanut.
John:
No.
John:
Anyway, yeah, I think my recollection... Anyway, so the proposal for Swift is to default to final, and this would make Swift one of those languages that's saying...
John:
Most of the time when you make classes, we expect them to be like done.
John:
But sometimes you might want someone to be able to extend your class.
John:
And in that case, we want you to have to put a special keyword or whatever in there to say, oh, other people like I'm writing a base class and other people are supposed to subclass me and override these three methods and do this other thing.
John:
And this is really, again, it's not really like a technical debate because both things would still be possible.
John:
This is really a sort of battle for the heart and soul of what Swift is and what Objective-C has been.
John:
I pulled a little quote out here from Jordan Rose, who I think is someone at Apple, although it's very difficult to tell on the Swift evolution list.
John:
When people are speaking for themselves as users of Swift or as contributors to the open source project, and when they were speaking as Apple employees, kind of implicitly,
John:
No one is ever speaking for Apple because no one speaks for Apple except with Tim Cook, I guess.
John:
But when there's an at Apple.com and their email address, I don't know, does their opinion carry more weight?
John:
I still haven't quite sorted out the sort of uneasy dance between at Apple.com people like Apple employees working on Swift and the unwashed masses of the Swift community and how that power balance works.
John:
And for the most part, the back and forth has been very polite and mostly useful.
John:
I think that most people realize, look, Apple's doing most of the work here.
John:
Apple made the language.
John:
Apple is going to do most of the work here.
John:
So while we can have some input, the bottom line isn't, are you going to develop Swift on your own?
John:
Are you seven people are going to take Swift and run with it?
John:
No, probably not.
John:
So all you can really do is give your opinion.
John:
But anyway.
John:
uh a lot of what this default final thing comes down to is the expectation by objective c programmers that any sort of framework uh anything in the framework that's like not behaving correctly or that you're making a subclass of that you can just override methods that you want to behave in a slightly different way like you can you can do a lot of interesting things with ui kit and app kit but
John:
by overriding things in subclasses even things that you know overriding them in ways maybe that you know to turn something into a no-op or to make something have an aside effect when it didn't have before or even to do things like the objective c runtime reach in and do what i think they call it method swizzling where you just reach in there and you screw with the implementation of a base class not even a subclass but you say you know you've got a blah method um
John:
i would like your i'll save a reference to what the original blah method was but instead point your entry for the blah method to my code that will do some other crap and then call your code and that will modify everybody who uses this class not my subclass but the base class everywhere um and those are the types of things you can do when classes are not entirely closed off when you have access to their guts and you can screw with them and then you know subclassing above and beyond that so again get back to what jordan rose said here
John:
He says, supporting arbitrary code injection to someone else's framework is a non-goal for Swift, perhaps even an anti-goal.
John:
If you replace a method on someone else's class, you don't actually know what semantics they're relying on.
John:
Of course, Apple code will have bugs in it.
John:
Trying to patch over those bugs in your own code is, one, obviously not an answer Apple would support, but also, two, fraught with peril, and three, likely to break in the next OS release.
John:
This is referring specifically to third-party developers saying...
John:
when things are open and able to be screwed with sometimes that's the only way we can ship our damn app because you've got a bug somewhere deep in your framework and sometimes we can you know a subclass isn't enough for us to fix sometimes we have to reach into the guts and and mess with the method just to make our app not crash we can't wait for you to fix the bug apple in a 0.1 release because that could be two months from now and we need to ship now and
John:
And our application doesn't run on the new OS that you're about to release.
John:
So we love to be able to go into some framework thing and nuke one of your methods or mess with it in a certain way to work around some strange bug.
John:
Or even if it's just as simple as like an animation bug or something that crashes your app but nobody else's app.
John:
Third-party developers are used to be having the freedom of the Objective-C runtime to mess with these things.
John:
But Swift really doesn't want that type of thing to happen.
John:
Swift would like it if in the future that it's not something they want to support.
John:
They don't want you to be able to reach into anyone's framework, Apple's or anybody else's, and say...
John:
Oh, you have a bug in there.
John:
I'm going to fix your bug for you.
John:
Or I want, your thing almost does what I want, but there's this one behavior it doesn't have.
John:
I would like it that if you did this one thing, it actually didn't trigger this other action.
John:
So I'm just going to reach into your guts and screw with it.
John:
And programmers who get used to that freedom, it's kind of like a...
John:
it's a last resort but it's nice that it's there but if you are a developer of frameworks you don't want anywhere reaching into the guts of your crap and messing with it because like you don't know what you don't know what the semantics of my framework are you don't know what invariants that you're violate you're you're violating by messing with that value i don't want you touching my this this member variable you're not even supposed to know exists that might disappear in the next next os version
John:
I don't want you messing with anything inside my code because you don't have the source code.
John:
You don't understand it.
John:
Even if you did, it's my framework.
John:
It's supposed to be like a black box to you.
John:
Just use the public API.
John:
Don't mess with my implementation.
John:
I thought this battle, which is... We'll link to the MJ Sai's blog post that links to a bunch of this discussion and to the mailing list itself, the Swift Illusion mailing list.
John:
I thought this discussion was fascinating because...
John:
It really does get at the heart of the old guard versus the new guard in Swift.
John:
And I really wanted to hear both of your opinions.
John:
I guess I don't know what the C-sharp world is like, but I do know what the Objective-C world is like.
John:
So Marco, if he's ever had to reach into some Objective-C framework and screw with it to get his application to ship.
John:
And Casey, what he thinks of this entire battle between the world of framework authors versus the world of application developers.
Marco:
I've never had to swizzle to do anything.
Marco:
That, to me, is over the line of you really, really shouldn't do that.
Marco:
That is more dangerous.
Marco:
Subclassing things that aren't intended to be subclassed, especially in UIKit, I do that a lot.
Marco:
Or not a lot, but I've done that numerous times over the years.
Marco:
I'm pretty sure Overcast does a little bit of that.
Marco:
Reimplementing my own methods to override parent methods in those subclasses that aren't intended to be overridden, I've done that.
Marco:
I totally get it from the developer perspective of almost always there is something you want to do in an app that there's just no other way to do it besides subclassing some UI kit thing and implementing my own child version of a method and just hoping I call super at the right time if I have to at all and just hoping nothing bad happens, testing it on the one release that I have access to and then shipping it and hoping it doesn't break in the future.
Marco:
That, to me, and this is all like, you know, you're subclassing, when I do this, I'm subclassing public methods.
Marco:
So there is some documentation on them, some public expectation of how they should behave.
Marco:
They're fairly stable.
Marco:
So that has never actually caused problems that I know of to do that that way.
Marco:
And there really have been a lot of these occasions where there's a limitation in the public API of there's just no better way to do this or there is no other way to do this at all.
Marco:
And so you have to do stuff like that.
Marco:
This is one of those things where, in theory, it would be nice if you never had to do this and if you could then have all the technical advantages of not doing this.
Marco:
In a similar way that, in theory, it would be nice if every Mac app was sandboxed.
Marco:
And then in practice, these strict technical limitations get in the way of reality and real-world use, and they kind of require a level of competence and perfection and expansiveness from Apple and its frameworks that in reality probably won't come.
Marco:
And so it's one of the things... In theory, it's great.
Marco:
In theory, having everything be final by default and having no overrides possible, that sounds great for academic theoretical safety.
Marco:
But in practice, I don't think...
Marco:
Modern developers with Apple's frameworks are really able to go that way.
Marco:
The reality is it doesn't support that.
Marco:
Apple is not that great, and developers aren't that flexible to be required to avoid this entire class of functionality and possible bug avoidances and bug fixes that simple things like subclass overrides can provide.
Casey:
You know, it's really hard.
Casey:
Let me start by just quickly establishing that C Sharp, unsurprisingly, takes the same approach to this as Java does, except where you say final, I would say sealed.
Casey:
No, seriously.
Casey:
Totally different language, I swear.
Casey:
Yeah, right, exactly.
Casey:
It isn't a Java clone.
Casey:
No, not at all.
Casey:
So yeah, so it's sealed classes to me, not final.
Casey:
But everything else is exactly the same, and they are not sealed by default.
Casey:
And in fact, it is striking, even within Microsoft frameworks, to see something that's sealed.
Casey:
That's very peculiar.
Casey:
That being said, I think the problem is that, and John, you alluded to this earlier, so much of Objective-C seems to be about subclassing and subclassing.
Casey:
But over time, even from my perspective as someone who doesn't live in it, it seems like that's starting to go away between blocks, between – shoot, I had something else on the tip of my tongue.
Casey:
Anyway, it's going away.
Casey:
But a lot of legacy Objective-C seems to be about subclassing and –
Casey:
So subclassing, when the author of that class hasn't deliberately decided for that to be subclassed, is inherently dangerous.
Casey:
And so much of Swift seems to be about, at least in comparison to Objective-C, about preventing danger, about having stronger typing, about doing more compile time to check and make sure you're not doing something stupid.
Casey:
So much about Swift seems to be about preventing danger and about being safer.
Casey:
And having carte blanche access, with a few exceptions, to subclass anything is inherently dangerous.
Casey:
And so it seems to me that the academic answer is unequivocally that classes should be final by default.
Yeah.
Casey:
That being said, one of the things I've struggled with lately, and a coworker of mine that we've worked together on a couple of projects lately, it's been a really interesting experience because he is extremely academic, or at least that's the way I think of him.
Casey:
He really likes to do things by the book, and he really likes to do things the rightest way possible.
Casey:
By comparison, of course I like to do that too, but by comparison I feel like I'm considerably more pragmatic or perhaps loosey-goosey is maybe how he would describe it.
Casey:
I would say pragmatic.
Casey:
And I come down, I think, in the same way that Marco does, that yes, academically everything should be final by default, but realistically I don't see how that's really possible.
Casey:
And what I think...
Casey:
Looking at it from my point of view, what's difficult about this is Apple has a tendency to kind of assume they know better than everyone.
Casey:
And so even if we had classes final by default, I think it's pretty clear that Apple wouldn't allow classes to be extended and subclassed very often because they tend to assume we know better than you.
Casey:
You shouldn't touch this.
Casey:
And while in principle that should be true, that Apple should know better than us, in reality, there's so many just minor bugs and issues and things that developers need to do in order to get around small problems that I don't think that's reality.
Casey:
And so in the end...
Casey:
The academic in me says, yes, it should be final by default, but I come down with Marco that this seems to be a little too broad and a little too aggressive a change to be right.
John:
Is there an Objective-C, like at keyword or something, for doing the equivalent of final or sealed?
John:
I don't think it's possible.
John:
So my take on this so far from looking at this thread and thinking about it a lot is that Swift seems to be, like Casey pointed out, like the whole thing with Swift is it's trying to be less open.
John:
less open to interpretation less open to possibilities than objective c in terms of will this variable be initialized when will it be initialized can i what can i guarantee about these things do i at what point do i have a half initialized object floating around somewhere in my thing like well you know can i be sure that this method i'm calling is going to exist on this thing how sure can i be how sure do i want to be um
John:
Some of that is for performance, some of that is for safety, some of it is for both, but that is definitely the direction Swift is going.
John:
It's trying to have its cake and eat it too.
John:
It's like, oh, we do things that are safer and we do things that are faster and we can do it with less typing and less code and less code means fewer bugs.
John:
And so more power, more safety, more speed, everything's good, right?
John:
But less flexibility is kind of floating around and they're rattling around.
John:
All right, more power, more safety, more speed.
John:
is it as flexible as it used to be well how do you define flexibility and app kit and the objective c apis have really really have been built around the ideas of subclassing so much so that it seems like it's the expectation if not of the framework offers then at least of the application developers that
John:
If you have some kind of problem, maybe you can solve it with a subclass, right?
John:
Maybe that class does everything you need, but you need to add a little extra functionality.
John:
So subclass it.
John:
And categories are like, subclass too much trouble because there's a million other places inside the framework that use NSString.
John:
Eh, throw a category in NSString.
John:
Now all your inner strings have a route 13 method.
John:
Yay.
John:
Like very sort of open to like, this is a giant world of toys and you can screw with that world of toys.
John:
And Swift tries to do some of that.
John:
Swift has extensions, which are like categories.
John:
Like, oh, you want to throw a method on every string or number in your thing?
John:
Go ahead.
John:
You want to make a new operator that works on all integers?
John:
You can do that.
John:
Like, yeah, go nuts.
John:
But it tries to do it in a safer way.
John:
So given that safety is such a concern of the language, I think it's natural.
John:
It fits the Swift language to say final by default.
John:
And furthermore, I think that the technique of building user interface libraries where everything is assumed to be subclassable by everybody...
John:
leads to a substantial amount of the sadness that necessitates the weird subclassing and eventually, in rare cases, the swizzling to happen.
John:
Not because the application developers are bad, but because the people making the framework...
John:
aren't giving like when they're writing you know all these classes that make up the frameworks that people use they're not thinking about designing for subclass ability versus not they're they're in whatever mindset they're in it's like someone could subclass me so i should make this class subclassable but they're also probably thinking but who's going to subclass this one or they're thinking when i need to update this class boy i'm about to update this class in a new major version of this os and
John:
What about people who subclass the old one?
John:
Am I breaking their crap by changing it?
John:
And it's like, well, I can't know.
John:
I can't really know what they did in their subclasses.
John:
Like, I had no real way of expressing the things that I didn't expect to vary versus the things that I did.
John:
And if they overrode this method and did some weird thing or there was some, you know, timing or ordering thing having to do with this, that I don't know what the subclasses are doing.
John:
And the thing I think that final defaults will force people to do
John:
is especially framework authors think more about which parts of this framework should be subclassable like what what are the extension points what are the things that can vary versus the things that can't vary maybe they'd come to the same decision uh this is the other thing about the final default maybe it turns out that the people who are writing ui kit or whatever like
John:
the next Swifty version, you know, as they're writing core foundation Swift, as they work their way up the stack, maybe those people who are writing those frameworks will come to the same conclusion that all the same classes that you can override in UI kit, that you'd also be able to override in some Swifty equivalent of the same type of UI framework.
John:
Like they would, they would, you wouldn't lose any flexibility at all, but at least they will have been forced to think about it.
John:
I would imagine what they'd come up with is to, to reduce the surface area of things that you can mess with.
John:
uh to make it clearer what what classes you're expected to subclass and maybe to document it better like how you're how you're expected to subclass like how does a well-behaved subclass of this thing you know is it possible to subclass this in a way that makes that will break with the next update of this thing or just making some classes not subclassable at all because you're not supposed to mess with that if you really need to mess with it you should instead extend it or use composition to make your object have one of these instead of be one of these
John:
And it just seems like a more natural fit to Swift to me because I think long term, forcing everybody involved by changing the default, forcing everybody involved to think more about subclassing instead of it just being the default.
John:
Like, well, of course, I can subclass everything.
John:
It's like it's my it's like, you know, it's my right.
John:
It's like the first dominion, freedom of speech and freedom to subclass.
John:
Thinking more about it will will cause everybody involved, both the framework authors and the programmers to try to.
John:
To try to reduce the sort of the anti pattern that we see in the existing frameworks where everything is up for grabs.
John:
And anytime something updates, nobody is really sure about what they're breaking because they have no idea what people subclassed and how.
Casey:
So I understand all of that, but the problem I come down on is I don't think Apple would be a good citizen of this mindset.
Casey:
And this is what I was saying earlier, that Apple would assume, no, all of our stuff is flawless.
Casey:
We don't want you to subclass this.
Casey:
There's no reasonable reason for you to ever have to subclass this.
Casey:
So we're not going to allow you to.
Casey:
And I don't think that they would be pragmatic enough to realize, well, we don't see any particular reason that anyone would need to subclass this class.
Casey:
But...
Casey:
You never know, and you shouldn't hurt anything if you do.
Casey:
So we'll just allow you to... What is the opposite of the final keyword in Swift?
Casey:
Whatever it may be.
Casey:
So we'll mark it as not final.
Casey:
And I just don't think they'll be a good citizen of this environment.
Casey:
I think other framework authors might because they seem to be less aggressive, for lack of a better word.
Casey:
But I just don't think Apple would be a good citizen of that environment.
Marco:
No, I mean, modern Apple is restrictive by default in many ways towards developers.
Marco:
And in most ways, that has worked out well for them.
Marco:
And so that pattern of being restrictive by default is something that is so ingrained in them that I don't think they're going to revert course in that.
Marco:
I mean...
Marco:
Objective-C is only as flexible and loosey-goosey as it is because it's ancient and it came from a time and a culture and a company that was very different from today's Apple and where dynamism was the goal and was considered very advanced for the time.
Marco:
Now, modern Apple does things like this, where Swift will be all locked down and rigid and strict and final by default.
Marco:
I see them doing this mostly because it just fits in with the things they see now as being correct.
Marco:
And in many ways, these things go in waves in programming.
Marco:
Programming is not a young practice anymore.
Marco:
It's been going on for decades.
Marco:
Things go in and out of fashion.
Marco:
And there are trends, and there are fashions, and there are fads and everything.
Marco:
And
Marco:
Open versus closed, loose typing versus strict typing, dynamic versus static.
Marco:
All these things go in and out of fashion at different times, often just reacting to what was popular previously.
Marco:
They just go in cycles.
Marco:
And we're in a cycle now where what is in fashion today is strictness and formalism and compile time checks, compile time safety.
Marco:
Apple is right up there with everyone else with Swift in that regard.
Marco:
And also in just the environment that apps run in, with iOS being locked down, sandboxed, everything, Mac App Store being sandboxed only, if anybody still uses the Mac App Store, a whole separate discussion.
Marco:
Having technical blocks in front of calling private APIs and App Store apps, things like that.
Marco:
This is the direction Apple is going and has been going for quite some time.
Marco:
So I agree that this is not... I wouldn't expect today's Apple to... If given a choice to redesign something from scratch, as they have with Swift, to take the option to say, you know what?
Marco:
We're going to let people subclass our stuff.
Marco:
No, they're looking for ways to lock it down.
Marco:
And I think...
Marco:
Ultimately, I think what we've learned as a profession, as programmers, over the last few decades of having popularized OO programming, I think what we've learned is that subclassing really is messy and has tons of anti-patterns and tons of potential for weird, unforeseen bugs and problems and a lot of dysfunction that becomes possible with OO programming.
Marco:
And of course, it's true of everything.
Marco:
But I think as a working programmer, I look around at my friends and I see people who are all programmers who are kind of evaluating, like people who are smart, like Brent Simmons, kind of evaluating how we should be doing things moving forward.
Marco:
And subclassing in general is going out of fashion very quickly among programmers.
Marco:
Not just among Apple and Swift, but among all programmers I know, subclassing is really out.
Marco:
It is going out.
Marco:
It is possibly out now.
Marco:
so you can look at Apple and you can say as I have that I really don't see them choosing any differently on this if given the choice I see them going final by default just because it's Apple and that's how they are these days but also I think there's enough support from programmers now for that you can't really say Apple is exclusively at fault ignoring what everyone's saying I think you can say you can make a good case for there being enough support that Apple's kind of making the right call for the whole community
Casey:
Yeah, and that's the thing.
Casey:
So to look at it from the flip side, we don't know the sorts of things that Apple has to deal with.
Casey:
We don't know the sorts of crazy, ridiculous hacks that third-party developers do that aren't as skilled as the Brent Simmons of the world.
Casey:
What makes a Brent Simmons really good at what he does is that he knows when a hack is the right answer and when it's not.
Casey:
And typically, since it's being called a hack, the answer is not often.
Casey:
But we don't see the sorts of BS they have to put up with by the really shoddy developers that aren't really thinking things through properly.
Casey:
And so I think if I were in Apple's shoes, it's easy to get lulled into trying to lock things down because you genuinely do feel like you know better.
Casey:
And when you're looking at all these really disgusting hacks...
Casey:
you do know better.
Casey:
It's not just a feeling of knowing better.
Casey:
You do know better.
Casey:
But the problem is, it's just the bazooka approach to something that really you need a scalpel for.
Casey:
And I mean, I think what makes this discussion so fascinating, what makes me enjoy engineering, sorry, Dr. Drang, so much, is that it's these sorts of difficult decisions that make our job so much fun.
Casey:
to weigh these options and figure out, well, what is the right answer?
Marco:
Well, and also, I think you can look at modern-day Apple as, in being in this position of authority, if you look at things like the App Store restrictions, like private API restrictions, like sandboxing on both platforms, but especially on the Mac...
Marco:
I think if Apple presented with the option of... Do you let developers ship something that needs to ship?
Marco:
And this is like... As you mentioned, this is... You might be able to say, well, if you're smart enough, you're allowed to break the rules.
Marco:
But that isn't... First of all, that isn't usually true.
Marco:
And you still generally shouldn't.
Marco:
Because A, it's still a bad idea.
Marco:
And B, you probably aren't smart enough.
Marco:
But...
Marco:
And even for the people who are smart enough, they still probably shouldn't be doing that because everyone is dumb at some point while programming.
Marco:
And the idiot who wrote that was probably just your past self.
Marco:
But anyway, if you look at the problems of shipping things and the problems in the real world, especially so much of the business these days is consulting.
Marco:
And as you know from being a consultant...
Marco:
Shipping is often of utmost priority above things like doing things in exactly the best architectural way or by best practices.
Marco:
You know, you just got to ship stuff and that's it.
Marco:
But that isn't Apple's problem.
Marco:
And Apple doesn't necessarily play by those rules with the way it treats other developers.
Marco:
If Apple's given the choice of letting developers ship more functional stuff more quickly at the expense of security or restrictions or calling private APIs, Apple doesn't choose to let them ship things.
Marco:
Apple says, you know what?
Marco:
That's not our problem.
Marco:
We would rather have you not ship a product at all or ship a lesser product or ship a later product.
Marco:
than break any of these rules.
Marco:
And there's no better example of that than everything that's ever happened in the Mac App Store.
Marco:
Apple would rather lose apps to the app stores and to their platforms.
Marco:
They would rather lose apps completely or have apps be reduced functionality and lose features over time or never have certain features.
Marco:
They would rather not allow those things or have fewer apps or have later or worse apps than have apps that are in a more permissive environment.
Yeah.
John:
I'm not sure everything they do in the Mac App Store has that much forethought.
John:
I think there's a lot of unforeseen consequences, unforeseen by Apple as well.
John:
They have a goal in mind.
John:
They didn't realize it would be difficult to get from there from here.
John:
So I think that's off to the side a little bit.
John:
Getting back to something that both of you said earlier about...
John:
What will Apple do?
John:
Like, you know, you can't trust Apple with this because they're going to lock everything down because that's the kind of company that they are.
John:
I think it's appropriate for Apple to be more conservative because they're not just a company that writes a bunch of frameworks people use.
John:
They are the platform.
John:
They are the foundation.
John:
They are the thing upon which everybody else builds.
John:
they should be more conservative than you are with your own classes and stuff.
John:
That's, that's their role.
John:
Like, so not that Swift is just made for them, but in any language, uh, if there are tools to be conservative and to try to reduce the surface area, try to reduce the public API, try to reduce the number of things that other developers call into like they do with like, you know, stopping private APIs on their app stores.
John:
And that's all part of the same process.
John:
Uh,
John:
They should do that.
John:
That's because they are they're underneath everything else.
John:
So they have a responsibility to be more solid and more resilient to people doing crazy things on top of them than the people who are building on top.
John:
And your application code be all loosey goosey all you want.
John:
You can get away with that because the people building layers below you don't get to be as loosey goosey.
John:
um and for apple say apple does that and they follow through on what you think is their instinct to close stuff up which i'm not entirely sure that they would because again it would be the same people who wrote app kit and ui kit doing the thing and ui kit isn't any more closed than app kit they just change the change the vectors change the they knew which things would be more likely to vary which is why ui kit seems like so much nicer to deal with than app kit because they learned oh when people use this kind of thing mostly they want to vary x y and z and so we'll build our classes to make those things vary but anyway
John:
if apple was to close things off uh in the the new swift frameworks or whatever um that would basically force people like developers like well i can't work around this anymore because i can't even subclass this thing and override your thing because your stupid framework is all closed off and i don't have your source code and it's a binary framework so the only thing left for me is to file bugs and what that will mean is that many more developers
John:
are forced essentially to like they have no work around they have to tell apple hey i can't make my button you know tint color and this button blue in this scenario because there's you know because of the way the framework works i have no access to that little knob to turn and i can't subclass it and do that so
John:
Please, like, you know, I'll file the bug and I can't ship my app.
John:
You're preventing me from shipping my app because there's no workaround.
John:
And Apple, in response to this, has added pressure to consider these requests because they can't say, oh, yeah, no, that's a bug.
John:
But for now, you can just work around about overriding this method.
John:
Like, there is no workaround.
John:
Both parties know, geez, there's no workaround.
John:
We didn't think about...
John:
this this way that people use the frameworks that they can't get it that they can't change this thing that seems eminently reasonable to change that's going to force apple to reconsider maybe if we don't have a way to do this can we have can we provide a supported way to do this
John:
And there's much more motivation to provide a supported way to do this if it's really a common thing that tons of developers are asking about.
John:
And there is literally no workaround.
John:
And there's no workaround because of what Apple did.
John:
And the workaround isn't, oh, just open that class up.
John:
The fix is, well, we don't want to just open the class up because we know what kind of problems that leads to.
John:
It ties everyone's hands in the future and makes it so that an OS upgrade could break your app and stuff.
John:
But if people really want to change this thing, we should provide a supported way to change it, because there is no workaround.
John:
And so you would hope, like, what you're hoping, like, this is, like, all the best laws.
John:
You're hoping that it motivates everyone involved to behave better.
John:
Like, this is something pressing in on a system, and you're hoping what it causes to happen is for the system to shape itself around this pressure and this force to become a better thing, making everybody become better.
John:
It's difficult for more people.
John:
It would be easier if they could just do whatever the hell they want, but then you just end up with chaos, right?
John:
And in general, the larger issue about this whole thing, about Swift and frameworks and Apple being the foundation layer and everything, is less code and increased safety is what you need when you want to create large, complicated systems.
John:
And our systems keep getting better and keep getting more complicated.
John:
And one of the biggest tools we have to fight against that is reduce the number of things that can go wrong.
John:
Reduce the number of things that you can do.
John:
Make more things deliberate and less things accidental.
John:
Ding.
John:
Yeah.
John:
And I think that's...
John:
It's in the spirit of Swift, and it's just in the spirit of the advanced technology.
John:
Mark talked about this going in cycles and dynamic versus static or whatever.
John:
I think some of that stuff does go in cycles, but increased safety is an arrow in one direction.
John:
Very, very rarely do we see the world of writing programs.
John:
for that arrow to reverse and say we had this kind of safety where it was impossible to scribble over memory but we'd like to add that in in the next language that we propose it always goes towards more abstraction and more safety and that safety can take different forms people will be misguided about what you need to provide that safety or how you know because small talk is pretty darn safe but it certainly looks nothing like swift right um
John:
so the move towards higher level languages and increase safety however that may manifest that is an arrow that is essentially always going in one direction and i think just the gyrations and getting there and the different paths towards that goal are separate and so is the dynamic versus static because you can have an eminent again like small talk an eminently dynamic language that is very very safe and you can also have an eminently static language that is also very very safe um so static and dynamic uh
John:
i i think does go in cycles not just based on fashion but based on theory and everything like that but increased safety everybody always wants that and that's the direction i think swift is going so i i don't know if this i forget who proposed this i don't it might have been a third party proposal or whatever but bottom line for me is
John:
i think that since this doesn't change capabilities all it does is make everyone involved think about things differently and because the default will be different than objective c i hope it will cause cause everyone involved to to think differently than they used to think about it and
John:
that Apple will nail more things down and it will cause more inconvenience to developers and Apple's will send the feedback and then Apple developers will send the feedback to Apple and Apple will be forced to think about the feedback and provide a way to do it because they're reasonable requests and there is literally no workaround.
John:
And the end result should be for users, programs that have fewer bugs, third party applications that break less frequently with OS upgrades and just generally more solid, stable code for everyone going forward.
Marco:
Our final sponsor this week is Warby Parker.
Marco:
Go to warbyparker.com slash ATP.
Marco:
They make buying glasses online easy and risk free.
Marco:
Order your free home try-ons today.
Marco:
So Warby Parker offers contemporary eyeglasses that are extremely affordable and fashion forward.
Marco:
Glasses should be viewed as a fashion accessory, not costing as much as an iPhone.
Marco:
Warby Parker offers prescription eyeglasses starting at just $95, including prescription lenses.
Marco:
And they also have a titanium collection starting at just $145, which includes premium Japanese titanium and French non-rocking screws.
Marco:
They also offer prescription and non-prescription sunglasses.
Marco:
So even if you're 20-20, there's still something for you at Warby Parker.
Marco:
All Warby Parker glasses include anti-reflective and anti-glare coatings, an excellent hard case.
Marco:
We have one of these in our house.
Marco:
This thing's a bit like a tank, the hard case they come with.
Marco:
It's awesome.
Marco:
and a cleaning cloth, all at no additional charge.
Marco:
Whether your eyesight is pretty good or absolutely abysmal, they have you covered with a wide range of prescription options, from simple reading glasses to advanced digital free-form progressive lenses.
Marco:
For those of you with very strong prescriptions, they offer ultra-thin high-index lenses to avoid the Coke bottle look.
Marco:
Now, buying glasses online sounds like it would be tricky.
Marco:
Warby Parker makes it easy and risk-free.
Marco:
Their home try-on program lets you order five pairs of glasses to evaluate for free.
Marco:
They ship them to you for free, and you can try them on in the comfort of your own home and get feedback from anybody around you if you want to.
Marco:
You can keep them for up to five days.
Marco:
Then you can send them back also for free with their prepaid return label, and there's no obligation to purchase anything.
Marco:
If they aren't for you, you can just stop right there, and you spent nothing.
Marco:
You're done.
Marco:
If you decide they are right for you, they can get started on your order right away.
Marco:
They can get prescription glasses to you within 10 business days and usually even faster.
Marco:
They also believe in giving back to the world.
Marco:
For every pair of glasses Warby Parker sells, they distribute another pair to somebody in need.
Marco:
So whether you could use a nice pair of eyeglasses, reading glasses, or even sunglasses, go to warbyparker.com slash ATP.
Marco:
Order your free home try-ons today with free shipping both ways and no obligation to buy.
Marco:
Once again, that's warbyparker.com slash ATP.
Marco:
Thanks a lot to Warby Parker for sponsoring our show.
Casey:
So John, what does open source Swift mean for the future of Go and Rust?
John:
I don't know.
John:
I just thought it was an interesting question.
John:
So there's a lot of languages out there that are very similar in spirit and visually even, or the ideas behind them.
John:
Make a language that is kind of like C, but without the nasty pointer stuff that is fast like those compiled languages, but that has lots of more safety guarantees where the compiler can figure out all sorts of stuff for you.
John:
So you don't have to do manual memory management, but you get the speed of a language like C or C++.
John:
So Go, Rust, and Swift all kind of fall into that family, and they're all relatively new.
John:
uh open source swift as we saw from the project being open and the crazy activity on the swift evolution mailing list and just the sheer number of ios developers who this is this language is potentially for uh and they're just even just a general excitement at wwc when swift was announced in the first place that swift is pretty popular just because because it belongs to apple like if swift had just been a project you know off to the side by some random person we wouldn't be having these shows about it but it's because it's coming from apple that it's very popular
John:
go is from google another big company they use it internally that is a tractor to pull on go being very popular it's also made by some of the folks that made c so that uh has some you know celebrity cachet behind it rust i think is uh from the mozilla folks primarily i don't know the full backstory on rust but so if you have to compare the sizes of these communities you would think that like
John:
apple and swift is the most powerful not because they're a bigger or more important company than google but merely because google uses all sorts of languages google uses a lot of java google uses python uh google uses go so it's not as if there's like this one google language and if there was go probably wouldn't be it but with apple apple has been for a long time now objective c is their one language and they're moving over to swift so they kind of speak with one voice all the apple wood is behind that one arrow right and
John:
google would have to come in second with go and like yeah google does have lots of different languages and has always been kind of like encouraging of using lots of different language and they have dart their own language and all sorts of things lots of languages are mixing around in there but google is a big company and they write a lot of stuff and go is a fairly important language and then finally google has more languages than i have mac pros like that's they just they make a new language like every six months you never know where it goes
John:
so it doesn't it doesn't have much behind and then rust i think is even smaller because it's like well mozilla they make a web browser and a bunch of other stuff and they're important but and rust is really interesting and it's not like you have to use all these languages general purpose languages that you could use for anything but they all have communities around them they're all fairly open and you could in theory write anything you want and go marco even wrote a thing for overcast and go and rust you could use to write any kind of same thing with swift right
John:
But Swift coming on the scene and being similar to those other two languages and having the full weight of Apple behind it could potentially do one of two things.
John:
Either it could suck people away from those things and they can say, well, I was interested in Go and Rust, but Swift seems very similar and it just seems to be like more popular and has a better IDE and I keep hearing about it and whatever.
John:
Or I like it better or something like that or just because Apple's behind it.
John:
Or I could have the opposite effect where it's like, I wasn't going to consider one of these alternate languages, but now that Swift is out, it seems like all bets are off on what used to seem safe, C, C++, or C Sharp, or Java.
John:
That's all old and busted, and now it's time for me to try out all sorts of new languages, so maybe go and receive a huge influx of activity and pull requests and people contributing to their communities as well.
John:
Might as well check back in a year and see, you know, I don't know how you'd measure this.
John:
Maybe you'd like go to GitHub or whatever and see like what happened to the Go and Rust communities.
John:
And, you know, is there any way we can measure that?
John:
Was the effect of Swift to cause those communities to swell in importance and those languages to mature and become more popular?
John:
Or was the effect to sort of pull people away from those two communities and have them sort of wither more now that the giant sun that is Swift is shining down from WWDC every year?
Yeah.
John:
All right.
Marco:
All right.
Marco:
Thanks a lot to our three sponsors this week, Audible.com, Igloo, and Warby Parker.
Marco:
And we will see you next week.
Marco:
Now the show is over.
Marco:
They didn't even mean to begin because it was accidental.
Marco:
Accidental.
Marco:
Oh, it was accidental.
John:
Accidental.
Marco:
John didn't do any research.
Marco:
Marco and Casey wouldn't let him.
Marco:
Cause it was accidental.
Marco:
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.
Marco:
So that's Casey Liss.
Marco:
M-A-R-C-O-A-R-M-E-N-T.
Marco:
Marco Arment.
Marco:
S-I-R-A-C-U-S-A Syracuse.
Marco:
It's accidental.
Marco:
Accidental.
Marco:
They did it in me.
Casey:
Accidental.
John:
Accidental.
John:
Tech.
John:
Podcast.
John:
So long.
Marco:
I mean, I don't know anything about WebObjects, but I do know that it is blamed for a lot of the shortcomings of Apple's web services.
Marco:
And I would guess it's probably not all about WebObjects.
Marco:
I'm guessing that it's much more about the entire rest of the stack.
Marco:
And that is probably a small part of the problem, if it's even still part of the problem at all.
John:
it's probably connected to it but just like the consequences what does it mean what what are the consequences that spin out from the fact that you're using web objects well then we have to have it on this platform and well then we have to have it on this os and well the way web object applications work is they have to be factored in this way and you can't really split this up from that and you can't this isn't horizontally scalable and these aren't these are tightly coupled instead of loosely coupled we can't replace this with the better version of this component you know there's consequences
John:
that ripple outwards from web objects so web objects itself i would think is not a big deal but i don't know i i just wonder with a technology like that that just seems to be like the only person left in the world using it is apple which is fine but at a certain point like every company even if you're google has to be like is this going to be a thing we do if it is we should probably make it open and try to get other people to use it because if it's just us using it we'll kind of do a crappy job
John:
Like it's better to get everybody else on board like they're doing with Swift or Go or Rust than to try to say, oh, we just use this internally.
John:
We can support our own weird web framework indefinitely, can't we?
John:
Maybe not.
Casey:
What else is going on?
Marco:
You want to talk about the Chevy Bolt that Sam the Geek suggested in the chat?
Marco:
The what?
Marco:
Is that the smaller Bolt?
Marco:
Yeah, it's battery only.
Marco:
It claims up to a 200-mile range, which would be substantial.
Casey:
$30,000.
Casey:
It's not attractive.
Casey:
It looks like the i3.
Marco:
Yeah, I saw an i3 in person again the other day.
Marco:
It's one of those things like whenever a new model of a new crazy design comes out, at first it seems wacky and crazy and ugly, and then
Marco:
Over time, you kind of get used to it as you see them more and more and it gets less new.
Marco:
The i3 has not followed that progression for me.
Marco:
The i3, every time I see it, is worse than the last time I saw it.
Marco:
Oh, it's so bad.
Casey:
Yeah, I didn't read anything about this.
Casey:
I've thought about it in the past.
Casey:
I'm not in the market for a car, but...
Casey:
Wait, aren't you though?
Casey:
Kind of for Aaron?
Casey:
Well, for Aaron, yeah, but not for me.
Casey:
But I've been thinking, and this would not be for Aaron, it would be for me.
Casey:
I rarely drive more than 100 miles in a week, maybe.
Casey:
Like my commute up until I went and did Staffog, which is Marco's favorite thing, my commute was like five minutes.
Casey:
And so I would drive maybe 10 miles in a day, maybe.
Casey:
You could take a hoverboard to work.
Casey:
Yeah, pretty much.
Casey:
Which, by the way, I just realized tonight that the hoverboards everyone are talking about is like a segue without the handlebars.
Casey:
I had no idea what everyone was talking about.
Marco:
Basically, yeah.
Marco:
I mean, it's a lot simpler and less sophisticated, but that's basically it.
Casey:
Yeah, I didn't realize that was a thing.
Casey:
But anyway...
Casey:
There's no reason for me not to have an electric car because I drive very little.
Casey:
It would absolutely charge itself overnight.
Casey:
There's no reason for me not to have one except that every single electric car I've ever seen other than the Tesla is either hideous, slow, or both.
Casey:
And I'm just not into that.
Marco:
So good at Tesla.
Casey:
I need to work like three jobby jobs.
Casey:
So we're sponsored this week by four more people.
Casey:
Exactly.
Casey:
I need three more jobby jobs or you guys need to not take sponsorship money for the next like six months and then maybe we can think about it.
Casey:
I don't know.
Casey:
But this is interesting, I guess.
John:
The Bolt looks like an American Prius is what it looks like.
John:
Yeah, kind of like it's small.
John:
It's a small, fabulous car.
John:
It's not like the Model S where it's trying to be like a full sized, regular shaped car that also happens to be electric.
John:
There's some what was that other one?
John:
I forget what the name of the company was, but some kind of basically taking Teslas and putting a different body on them.
John:
Oh, yeah.
John:
Was it Faraday or something?
John:
is that what that was about yeah it's just it's like the tesla like the little the thing you see in the tesla store in the mall just like the battery and the drivetrain and the wheels and then they build a different car on top of it and sell it for presumably more money and it seems silly and it's ugly and it was uh it was it's like the ff zero or something like that which which made me happy because it's a play on the f zero uh super nintendo game which i love if it was they would be sued
Marco:
Speaking of which, how about that Apple Watch clone from this Swiss mechanical watchmaker?
Marco:
Did you see the black Milanese loop?
Marco:
Yeah, I saw it on a rumor site.
Marco:
That looks interesting.
Marco:
But, I mean, there's no reason why Apple couldn't do that, like, off the top of my head.
Marco:
I mean, unless there was some kind of manufacturing challenge, but...
Marco:
Tell you what, the... So right now, I'm still on my mechanical watch thing, but the black, the space black link bracelet that I got, I don't know, six months ago now for my Apple Watch, that black DLC coating is the real deal.
Marco:
It is still flawless.
Marco:
And any kind of stainless steel band or the stainless steel watch itself gets scratched to hell in like a second.
Marco:
The black, the space black with the DLC on it is...
Marco:
Just literally, mine has no scratches on it at all.
Marco:
It is crazy how good that coding is.
Marco:
So I welcome Apple adding more options that have DLC because it's just awesome.
Marco:
It is just so good.
John:
This mechanical Apple Watch is not good.
Casey:
I don't understand what they're... Yeah, I just looked at it the moment you started talking.
Casey:
That's... Wow.
John:
Why?
John:
Apple had to make it like that.
John:
You don't.
Marco:
And to me, it's like... The world of mechanical watches, if you look at mechanical watches and the appeal that they have, and you look at the complaints that mechanical watch people have about the Apple Watch, one of the big complaints is that the Apple Watch just isn't that attractive of a watch.
Marco:
So why would you make one that looks just like it?
Marco:
Like, it seems... First of all, Apple's going to sue the crap out of you and make this stop immediately.
Marco:
Second of all... Like, why?
Marco:
Third of all, they're only selling it in gold.
Marco:
So it's like 25 grand.
John:
They've got to make enough money to pay for lawyers.
Marco:
Who's going to buy that?
Marco:
Like, who's going to spend 25 grand on that?
John:
Yeah, I don't know.
John:
Just...
John:
seems silly but i mean you like it's like these watchmakers like what what's what's going on what's exciting in the watch world this entire year all we heard about is a stupid apple watch how can we get in on that excitement somehow how about we make it like we can make a smart watch it's like we don't know how to do that how about we make a regular watch let's make it look like the apple watch all right
Marco:
Similar to the Tag Heuer.
Marco:
I don't know how that's pronounced.
Marco:
I'm assuming it's Tag or Tog Heuer.
Marco:
Their smartwatch that they released a few months ago.
Marco:
It looks just like a regular round mechanical watch thing.
Marco:
face uh but it is just a black screen like the apple watch most of the time it seems like and then like you know it turns on and it has a face that looks like a tag hoyer watch uh you know but like to me again like that kind of ruins the point if you're gonna have a watch where the screen's black all the time and then eventually you look at it and you glance at it and there's like a computer you have to manage then i think the apple watch is the one to get because if you want a computer watch that seems like it's probably the best computer watch
Marco:
I don't get it.
Marco:
Now that I've seen this world just a little bit, I totally see the value of a good mechanical watch.
Marco:
And I totally see the value of a computer watch.
Marco:
And I don't think those things should be crossed.
Marco:
I think crossing them destroys the value of both, really.
Marco:
This is going to get now emailed from all the watch people.
John:
oh we've already gotten even i have gotten a lot of uh stuff from the from the watch people you know i've been thinking in the watch world and speaking like smart watches and mechanical watches and everything i've been impressed so far anyway still by the way another year but impressed with how fitbit has reacted to the challenge of the apple watch reacting by
John:
basically making newer and more capable series of things that are mostly featureless bands with very simple screens incorporated into them in subtle ways i saw a picture of the president wearing one and a lot of people have the newer fitbits like they found kind of in the same way that the pebble didn't or maybe you know pebble had some good ideas too but like trying to find like
John:
how am i different than the apple watch but still a valuable product like what is the road that is still available to me to go forward and fitbit seems to be i mean who knows they could be like the flip remember the flip camera back in those years before before the iphone shot video oh yeah the flip camera had a really great business for like three years yeah right and so it it still remains to be seen if fitbit will find a way like out of the woods but so far like their reaction to in the post apple watch time has been pretty good no they found it it's it's the fitbit blaze
John:
Is that a real thing?
Casey:
Yeah, look at it.
Casey:
That's how they're getting away from the Apple Watch.
John:
The one thing that looks like an Apple Watch with the corners punched out?
John:
Yeah, this is not the way I would say you would go towards it, but I'm talking about the other Fitbit products.
Marco:
The Wythings Activity Steal, this, I think, is a more... This is a better competitor.
Marco:
At least, I haven't seen one in real life, but on their website, it looks really nice.
Marco:
This is the kind of thing... I can see buying that and valuing that rather than an Apple Watch before I could see the big Fitbit corner cut off Apple Watch.
I don't know.
Marco:
It's a smart approach.
Marco:
It's mostly a mechanical watch, basically.
Marco:
It's mostly a regular watch with some very slight activity tracking and sleep alarm kind of thing.
Marco:
It still has all the battery advantages of a regular watch.
Marco:
It's low cost.
Marco:
It's under $200.
Marco:
Long battery.
John:
It can be more attractive.
Marco:
Yeah, I think from these pictures it looks pretty attractive.
Marco:
Who knows what it looks like in real life, but it looks pretty decent, under $200, activity tracking, built-ins.
Marco:
That seems like that's a better kind of approach to try to compete with the Apple Watch rather than to be a full feature computer platform because you're not going to do that if you're Wythings or Fitbit.
Marco:
You're not going to be able to compete on that front.
John:
yeah the blaze looks more like like a fitness like totally focused on fitness gps type thing but i was thinking of the charge and the charge hr and even the flex like the evolution of the flex into increasingly large rubbery bands with a tiny little screen that that appeals to people for athletics like it's for activity and athletics just so focused on fitness fitbit's right in the name like you i guess they do have a clear path like fitbit like we're not
John:
going to be a general purpose platform for smart watching everything we do is going to be about fitness and so you can make this whole line of products with a similar value proposition of we track the stuff that you do and your heart rate and your activity and we connect to your smartphone with an app and do all that stuff but there's no real brains in our thing it's just an accelerometer and a tiny simple screen and some magic invisible bluetooth that just you know make it work and even even the blaze thing looks like
John:
you know like those garmin gps things like a really a fancier version of a thing you wear when you exercise i do not buy the one where they show like the woman in like with jewelry with her fancy purse i do not buy that scenario at all for this thing because it is huge and i i absolutely don't buy it as anything oh boy it looks bad
Marco:
Yeah, the one where it's a woman and a man going on a date, a man's wearing a whole suit, and it's like, he's wearing a suit with this watch.
John:
Yeah, I didn't know this existed.
John:
I may have to take back some of my credit to Fitbit.
John:
But the other things, I see them around a lot.
John:
I see them around a lot in regular people, and they so clearly have... Because they're so cheap compared to the Apple Watch, and they're so, like, not disposable, but they're made of plastic, and they're rugged, and they have such a clear purpose, and...
John:
They're simple and you don't have to worry about rebooting them or updating the OS or getting apps for them.
John:
Again, remember the flip camera.
John:
We'll come back to this in a year and see how this is all shaken out.
Marco:
I really do think there's going to be a healthy market for inexpensive, more focused smartwatches that are not full-fledged app platforms.
Marco:
You could argue, looking at the Apple Watch, how
Marco:
The Apple Watch really isn't a great app platform either.
Marco:
It tries to be, and maybe it will be in the future, but at the moment it isn't.
Marco:
And what people tend to like most about the Apple Watch is the stuff that a $200 less capable watch with a longer battery life probably could do most of, you know?
John:
Yeah, like this Withings or Wythings thing.
John:
As the price of compute drops to zero, eventually smart guts go into everything just because it's so freaking cheap.
John:
Why would you have just a regular quartz watch without some very basic accelerometer step tracking and computer smarts and wireless connectivity?
John:
Because eventually the thing that does all that on one tiny system in a chip five years from now, it's like...
John:
that costs less than the little metal bar that we use to connect the straps like just put it in it's free and so everything has some amount of smarts in it and then apple is making the high-end one where they're always pushing the envelope like what kind of crazy computing stuff can we put in here but it's like you know like the internet of things eventually it's just like we're gonna put a smart chip in everything and we think that will make it better and it probably won't in the beginning but it just becomes so cheap that
John:
Yeah.
John:
Yeah.
John:
Yeah.
John:
food well you just put wood in the stove what about you know toasting your bread i just put it in the oven why does electricity need to be in everything it's just gonna make everything worse and in the beginning it did but eventually everything's got freaking electricity so it's gonna be the same with uh with cpus
John:
not everything has cpus now but it is inevitable they will in the same way they all get electricity because and we'll have to endure the stupid years where adding it makes everything worse you know like i'm i'm absolutely sure that the first electric stoves were hated by everybody who was used to the quote-unquote real stoves that didn't have electricity but eventually we worked it out and even even today some people still have giant gas stoves but um i don't know computers coming watch out
Marco:
Yeah, I don't know.
Marco:
As I said last time, and now that I've spent some time wearing a mechanical watch, it is really nice to have something that does not need to be charged or have software updates.
Marco:
It's so nice because everything else in my life now has to be charged and require software updates.
Marco:
And by the way, works 97% of the time, but not that last 3%.
John:
even the crappy mechanical ones that's what i'm talking about when the compute comes everywhere it'll be so small that you won't need to charge it all the time like it'll probably charge itself from the motion of your wrist or something and you won't need to update it with software because it will do so few things and it will be a fixed set of functionality but there will still be a cpu in there like in the same way that half of these vacuums you're testing probably have some microprocessor somewhere inside them you never need to update it you're never going to update it just does what it's going to do you don't even know it's there you don't have to think about charging it because you plug it in uh
John:
but it's in there in the same way all of our cars have a bazillion computers in them now for the most part we're not running software well marco is now but most of us are not running software updates on our computer on our cars but they're just they're filled with cpus so that's the progression if you're still thinking about it and having to charge it and run software updates that's clearly like on the on the leading edge of adding computers to things
John:
When we stop even knowing there's a computer in it, that's the trailing edge of adding computers to things.
John:
I don't know if cars are on the trailing edge because cars have this whole other revolution of having their interiors become computerized, but the engines have long since been computerized, and that ship has kind of sailed, but now we're computerizing all the rest of the car.
John:
I'm trying to think of another example of something in our house, maybe dishwashers or washing machines.
John:
They used to just be like circuit boards with a bunch of fixed circuits and stuff, and eventually they just all got CPUs.
John:
And we don't think about it.
John:
And you don't update them.
John:
And you don't have to charge them.
John:
And it's not a hassle.
John:
And they don't crash.
John:
Because what they do is so stupid and so simple.
John:
And, you know, for the most part.
John:
I don't know.
John:
Maybe I'll come up with a better example.
Marco:
Yeah, that's fine.
Marco:
The stuff that's basically a sealed box where you can't get a firmware update for your dishwasher.
Marco:
I'm sure it's possible for service people to do it, but that isn't something that consumers are expected to ever do or even able to do because what they do is so simple and basic.
Marco:
You hope there would be no need for such a thing.
Marco:
But where the danger of being annoying and unreliable comes in is when you have something as complicated as an app platform.
Marco:
Like a device that has an app platform, like a smartwatch.
Marco:
That is complicated.
Marco:
So now you're expected to have a smartwatch, a phone, maybe a tablet, certainly a computer or one of those things.
Marco:
So you have all these devices and then your cars are getting smarter.
Marco:
They have software that whether it gets updated or not, it probably needs to.
John:
like like my car now does not have over-the-air updates the way tesla does but it has plenty of software bugs that should be fixed like yeah it's they just don't get fixed you know well yeah the platform thing is interesting because i think we're in the process of trying to figure out what things should be platforms and what things shouldn't i think like for the most part thus far we've decided that washing machines should not be application platforms i think we're all pretty much in agreement there so far but people are willing to try things out should watches be application platforms
John:
should phones it should like should televisions we're finding out the answers to those things now i think we pretty much found out phones yes they should probably be application platforms to televisions jury kind of maybe still out watches jury still out uh cars i think you're figuring you're gonna figure that out for us marco right i mean maybe like this is not really you know it
John:
Everything is potentially one, but they can't all be.
John:
There is no future where everything is an app platform in the way that we think of app platforms today.
John:
But everything will have CPUs.
John:
Everything could be getting magic wireless software updates.
John:
Again, as the price of computing drops to zero, as the power consumption of computing drops to zero, as it becomes just so damn cheap and so power and ubiquitous wireless networking everywhere with low power, you just put it in everything.
John:
uh and if you can come up with the sort of the wireless internet enabled equivalent of the dumb embedded cpu that's in your rice cooker that does the fuzzy logic to figure out when to stop cooking your rice if that has some little minor bug or even they just want to patch something because the international data authority decides we're going to skip january 15th in the year 2027 for some reason or whatever
John:
that all the devices in your house will wirelessly get updates to handle that date thing and you won't think about it that'll be great like that's a that's a potential cool future and it's eminently possible but it still doesn't make your rice cooker an app platform because that just doesn't make any sense you know practically speaking
John:
because what would you use it for you just want it to be reliable and like you said with the bmw it may have bugs and you would like it if those bugs would be fixed but you don't want to deal with that crap nobody wants to deal with it you just want it to happen automagically with no possibility of error like the rules for embedded systems are so different than the rules for things that are app platforms and then when we're out there on the bleeding edge like the apple watch and and smartphones and our pcs perpetually on the bleeding edge that's where things get all unreliable and crappy and it's just a whole different set of rules there and getting back to the swift discussion
John:
If they can try to drag those leading edge platforms towards more safety at the price of more restrictions, as long as they do it in a sane way and understand what the consequences can be, unlike these sort of unintended consequences of trying to drag the general purpose Mac platform to be like a smartphone with sandboxing, then I think things can work out eventually.
John:
Probably will mostly be dead, but I plan to live for a long time, so we'll see.