The Bridges
John:
By doing this podcast tonight, my wife asked me what I was going to do.
John:
I said, well, I might be doing a podcast depending on what Marco, his schedule or whatever.
John:
But if not, I have a blog post that I want to do.
John:
Since Dan Frakes' thing about the Mac Pro Mini thing, I'm like, all right, I have this week's blog post.
John:
I need to write that.
John:
And I still haven't had a chance to do it.
John:
I wrote two or three paragraphs of it while taking my son to swim lessons today while he was in the swimming pool.
John:
I actually wrote it on my iPad.
John:
I was inspired by Jason Snell to do that.
John:
It actually wasn't that awful.
John:
But anyway, I came back here, and I started writing again, and then I started your email.
John:
So you are thwarting me from posting to my blog.
John:
Last night I had a podcast, couldn't blog about it.
John:
Tonight I got a podcast, couldn't blog about it.
John:
You can talk about it.
Marco:
I actually was hoping we would talk about that particular topic.
John:
In the podcast last night that I was on, one of the questions on this topic came up, and I debated saying something, but I said, okay, well, here it is.
John:
And I talked for like two and a half minutes, and I said, okay, now just make that coherent and put it in writing, and that's what my blog post is going to be.
John:
That's always the challenge.
John:
so yeah oh yeah i mean i many of my podcast discussions were inadvertently drafts for blog posts that were much better considered and that's that's what my podcast is you know talking it out rambling and then you distill it down or whatever but uh but yeah i said but you know what i should do it anyway because like the podcast i was on last night is going up on like the 20th or something so by the time it goes up my blog post will have been up for weeks right we can put this up you know tomorrow
John:
But anyway, I don't want to talk about the mini Mac Pro.
John:
Every time I think of a blog post, I'm like, you just got to write a blog post.
John:
It doesn't matter if it's two paragraphs.
John:
I'm like, oh, I have a great two-paragraph idea.
John:
And it never comes out as two paragraphs.
John:
Not that it goes out for pages and pages, but I look back at it and I'm like, that was supposed to be two paragraphs and it's eight.
John:
If it was two paragraphs and it came out as four, I'd be okay.
John:
But eight, I feel like there's something going wrong.
John:
So I have one very simple example.
John:
idea that it should be really three sentences, but then I write those three sentences, and I say, if you don't already know what I mean, you won't understand those three sentences, so I expand, and I expand, and I expand until I feel like I'm bringing some new people along who don't already know what I'm saying and don't already agree with me.
Casey:
So are we going to not talk about it then?
John:
No, I'm not going to talk about the Mac Pro.
Casey:
Fine.
John:
Marco should already know.
John:
I live in fear of Marco just blogging.
John:
This is such an obvious idea that if I mention it, all of you are just like, yeah, everyone knows that.
John:
It's stupid.
John:
Let me write two sentences about it on my blog post.
Marco:
I think with this thing, everyone has been talking about what they could do with the Mac Pro.
Marco:
Every six months, there's a wave of discussion about it.
Marco:
And so many people...
Marco:
think that it's going to be some kind of weird modular thing where you get a bunch of mac minis and connect them via some mystery thunderbolt that's fast enough to do anything meaningful with this i heard that what's the playstation 3 is going to be like with the cell processor you'll be able to have multiple ones together to make it to make your games look better did you hear about that yeah
Marco:
All these fantasies that people have about this, in addition to having a lot of technical challenges, mostly involving the speed and bandwidth of the connectors between the individual parts, but it would just be an amazingly complicated, really inelegant setup.
Marco:
What I hate about the iMac is that...
Marco:
Once you have some kind of powerful demand with an iMac, you usually end up having a desk covered in hard drive enclosures and all these bolt-on things shoved on the outside or connected to it that with the Mac Pro you could just put inside.
Marco:
And with many advantages there.
Marco:
So I feel like any move towards less internal storage, less internal capacity for expansion...
Marco:
Any move in that direction really eliminates quite a lot of the Mac Pro's appeal.
Marco:
And a lot of people don't really distinguish between the Xeon line and the regular consumer CPU line.
Marco:
But that's also a very important distinction because the Xeon line means you can have two sockets and lots of RAM slots.
Marco:
and you get all sorts of benefits, like ECC RAM, which, you know, it just makes your computer a little bit more stable, like a little bit less likely to have some problem down the road, or, you know, it'll crash, it'll kernel panic, like, three fewer times in its lifespan, but those might really matter to you.
Marco:
Like, there's all sorts of these benefits that you get with the server-grade components, with these giant, expensive motherboards, with these giant PCI Express slots that have really, really high bandwidth that, you know, if you have...
Marco:
If you want to do multiple video cards to have six monitors, you can do that with a Mac Pro.
Marco:
You can't do it with anything else.
Marco:
There's all these edge cases that with the Mac Pro, you can do all of them.
Marco:
Most people don't need all of them, but a lot of people need one of them.
Marco:
So I feel like...
Marco:
So my blog post kind of made it sound like I thought that the iMac could solve all these problems, and it can't.
Marco:
My point with the blog post was not that the iMac is good enough for most Mac Pro customers necessarily, but that it's a good enough solution for Apple to release to address most of these customers.
Marco:
And that's a weird distinction to make, but it's good enough for Apple to deal with them by just releasing this.
Marco:
And as a user, I as a user can say, I wouldn't like that as much.
Marco:
And almost everybody has responded saying, I work in video or I work in science or something like that.
Marco:
I work in something where that would suck in some way.
Marco:
And that's true.
Marco:
But there's already tons of small markets that Apple doesn't address, usually because they're too small and they're relatively unprofitable.
Marco:
If a whole bunch of high-end workstation users had to switch to Windows, which many of them already have for different video editing programs since Apple pissed off all the video editors with Final Cut Pro X,
Marco:
if some of those people have to switch to Windows for their video editing needs, I don't think Apple cares that much.
Marco:
Yeah, if they can avoid it easily, they will, but I think that that specialized market is something Apple's willing to lose.
John:
I'm going to be sad to see my tower filled with server-grade hardware go, because I don't know if I can attribute it to it having server-grade components in it, but this machine has been so incredibly reliable.
John:
My 2008 Mac Pro, it has been the most reliable, probably the most reliable computer I've ever owned, because even my favorite Mac ever, the SE30,
John:
That had some reliability problems, mostly related to the fact that I had a color video card shoved in it, which is something Apple never foresaw.
John:
So it had some flaky issues there and had a bum power supply early on.
John:
But, like, this Mac Pro has just been 100% champ.
John:
Like...
John:
nothing has gone wrong i think i had one bad dim that went wrong and when it went wrong it was so obvious that it went wrong you could like the machine booted but it just had less ram and you'd go to the little thing and it would show which bank wasn't showing up you know it was just like everything worked exactly the way it's supposed to i've put a million different hard drives in it i've added to the ram never any problems with noise heat no fan bearings have gone bad you know just nothing like and i i can't imagine the machine replacing it
John:
being more satisfying than this was when it was new you know oh yeah because because in 2008 like and it was cheap it was before they were like super duper expensive for a crappy thing and so it's and i don't know if it's because is it because it has etc ram is it because the the cpus are relatively underclocked to what they could possibly be clocked to is it because the cooling is such overkill because of the case was like freaking g5 you know like whatever it is about it
Marco:
uh it's gonna i'm gonna be sad to see this thing go or go into my attic because that's not gonna actually leave my house of course yeah oh man i i sold i sold my version of that computer to dan and uh it costs like 140 bucks to ship it to him it's nuts yeah
Marco:
But yeah, the Mac Pro is a fantastic computer for these type of users.
Marco:
I don't ever see myself going laptop full-time and being that happy with it.
Marco:
I did it last year for a while, and it was okay...
Marco:
But there are just so many downsides to it for me and so many little annoyances.
Marco:
I mentioned on Neutral that I like everything to be stock and clean.
Marco:
That's why I hate having a desk covered in wires and hard drive enclosures.
Marco:
I don't want to have to bolt on a million different things to make my computer fast and stable and have enough space for what I'm using it for.
Marco:
And...
Casey:
Yeah, but couldn't you just get one of those absurdly overpriced Thunderbolt docks?
Casey:
Not dock, but port replicators.
John:
Well, I could, but... You can't.
John:
You can't put a video card in it.
Marco:
You can't put a high-end video card in it.
Marco:
Right.
Marco:
And there's a lot of people for whom that solves their problem.
Marco:
A lot of video editors don't use internal storage for their projects.
Marco:
They use external drives with RAID 0 and just giant drives.
Marco:
Well, then they have a fiber channel card.
John:
Then they have a fiber channel card inside their MacBook.
Marco:
Well, I mean, a lot of them, not necessarily the big production houses, but a lot of smaller shops and individual video editors will just use those external G drives or, let's see, all the high-end enclosures that are made of metal and just have two consumer drives in them.
Marco:
They'll just use those.
John:
I think those people, it's not so much that they need a Mac Pro, it's that they need a machine that's built with the philosophy of the Mac Pro in terms of reliability.
John:
They'd rather pay more for something that'll be reliable than pay less for something that's just as good, but is made sort of to consumer spec.
Marco:
I'm that way too.
Marco:
If my computer gets flaky, that is a severe problem for me in so many ways.
Marco:
It'd be a problem for this podcast or any podcast.
Marco:
It'd be a problem with my work, with my coding, if I have to be randomly rebooting every few days for some weird issue or some weird reason.
Marco:
That's a severe disruption.
Marco:
That adds up.
Marco:
And
Marco:
For people who that really is disruptive to, it is worth it to pay more to get a high-end tower.
Marco:
And you said these things last forever.
Marco:
Your 2008 Mac Pro is still pretty good by today's standards.
Marco:
My 2010 Mac Pro is still the fastest Mac for most single-threaded tasks and among the fastest Macs for anything parallelizable.
John:
you know it's certainly i'm still playing games that are released this year right on my mac so like i mean even though i have you know the 8800 is not amazing a good video card it's still you know it's better than what you get in a macbook right maybe not anymore but but certainly for not in a mac maybe not in a macbook pro i'm saying a macbook like that's what people buy like when you get a kid gets a laptop and they go off to college they get a macbook because the parents just want to get them a laptop and
John:
And you can't play modern games and that thing, and here I am with my 2008 computer, and I can play them.
John:
Right.
John:
So that's the kind of investment I want to make.
John:
That's why I always want to get the biggest, hottest, fastest video card they have, stick it in a box with lots of RAM slots, make it reliable, and give me internal storage, and I'm happy.
Marco:
Oh, yeah.
Marco:
And when you do want to get rid of that computer, if you sell that computer in the next year, you'll still get over $1,000 for it.
Marco:
I don't sell my children, Marco.
Yeah.
Casey:
But you'll lease puppies.
John:
They go up into the attic.
John:
I'm trying to think of something to do with this thing.
John:
If it didn't take so much power, I would put it in the basement and make it a video server or something.
Marco:
That's always the problem with old hardware.
Marco:
It's not worth the power or heat or noise.
John:
I guess if you keep buying Mac Minis, I would put an old Mac Mini in the basement if I ever had bought a Mac Mini.
Casey:
See, but the problem I have with the Mac Pro, having never owned one, is that it seems contrary to everything that Apple wants.
Casey:
Even within the laptop line, now RAM is getting soldered on the board and hard drives are getting soldered on the board.
John:
But you don't carry around the Mac Pro.
Casey:
You're right.
Casey:
But what I'm driving at is everything about all the consumer-grade Macs, even the MacBook Pros, for the purpose of this conversation, I'm classing that as consumer-grade Macs.
Casey:
All of those are becoming more and more integrated to cite the overly used word.
Casey:
And the Mac Pro is contrary to all of that.
John:
Consumers don't want crap in their way.
John:
That's the basic thing.
John:
The story I was told about my sister when I convinced her to finally replace her.
John:
She had a sunflower iMac, you know, the one with the little stand thingy.
John:
And she was all right with that one.
John:
And then I convinced her to upgrade to get the flat panel ones.
John:
And her favorite thing about that computer was that when we put it on our desk and started to get it set up, she says, where's the computer?
John:
And I said, that's it.
John:
That's all there is.
John:
And she's like, that's all there is?
John:
That's great, because that's what I always wanted.
John:
I just want the screen.
John:
I don't want some other thing in my life that gets in the way of me doing stuff.
John:
They recognize that they need a screen, because you need something to look at, and you need a mouse, and you need a keyboard.
John:
But do I need anything else?
John:
No.
John:
And so that's why the iMac, you know, like making the iMac go away, consumers love that.
John:
And the Mac Pro is the opposite of that because it's the opposite of going away.
John:
It's humongous.
John:
It's heavy.
John:
It's, you know, you can't even fit it on a desk because it'll just dominate you and if you're
John:
So it's anti-consumer because consumers do not want to see crap like that.
John:
Whereas if you're someone who needs a Mac Pro or someone who wants it to play games or whatever, you are the type of person who is willing to accept that intrusion into your life of this big thing.
John:
Space Eater.
Marco:
And so much of the Mac Pro commentary that's out there from tech blogs and writers and stuff, so much of the commentary that focuses on I want it to get smaller, I want it to get sleeker, that's from people who have never owned one.
Marco:
And the people who own them usually love them and usually don't care how big it is because it's on the floor.
Marco:
It's out of sight.
Marco:
You tuck it away under the desk and you don't really... If my Mac Pro got 30% thinner, I wouldn't even notice.
John:
I can stand for it.
John:
I don't see it because I want it to take up less room, but I'm like, you know what?
John:
Once you ditch the space for two optical drives and you convert some of the storage area to be taking SSDs instead of 3.5-inch disks, I'm like, at that point, maybe you're wasting space and maybe you can slim it down.
John:
And some of it is also like fashion.
John:
Like I would be interested in seeing a new fashion iteration considering we've been with this case for a long time.
John:
But it's not like I'm saying glom it all to the back of the LCD because I don't want it in my way.
John:
Like there's a dedicated spot on the floor where it goes.
John:
I could put something slightly smaller there, but I would be fine if they kept it the same.
John:
I mean, at this point we're desperate.
John:
It's like bargaining.
John:
Please just keep the same case.
John:
Just give us a new one that's not crap.
Marco:
And also, a lot of the people who make arguments about it or have theories about it or who judge it unfairly don't realize how expensive Xeons are.
Marco:
So they'll say, oh, this thing is overpriced.
John:
I mean, it's overpriced, but it's not Apple's fault.
John:
Intel is gouging on that price.
Marco:
Exactly.
John:
If you look at any other workstation... But at this point, it is Apple's fault because they charge so much money for what is an ancient piece of crap computer at this point.
John:
that's now it's apple's fault well the funny thing is intel still charges that much for these processors i know but like add it up like great so build your own mac pro like okay so intel let's buy let's pretend we buy the processors at retail price which apple doesn't right and then let's pretend we buy the ram at retail price which apple doesn't pretend you buy all the parts at retail and you're like boy that case must cost 1200 to make i guess yeah yeah i mean certainly it does not add up no it doesn't add up but but it isn't as far off as a lot of people think
Marco:
And especially, like, the add-ons, once you go to, like, okay, well, I want to bump it up to dual socket with, you know, 2.66 gigahertz.
Marco:
Then you look at the difference that costs, like, $1,500 extra?
Marco:
What the hell?
Marco:
And then you look, oh, well, actually, Intel charges, like, $1,200 more for the CPUs.
Marco:
But, you know, and I think...
Marco:
It is such a beast, but if you did anything to really slim it down, if you eliminated a few drive bays, or if you made it single socket only, which would save a lot of space on the bottom, then you are limiting who will buy it.
Marco:
You are taking people who used to buy Mac Pros, and you are really significantly reducing their motivation to buy a Mac Pro again.
Marco:
And that's why I just think...
Marco:
I do hope that Apple keeps it around.
Marco:
I do hope that the next revision has some kind of solution for Retina on the desktop.
Marco:
Hopefully that they will release some kind of Retina Cinema Display, and then there will be some kind of insane video card in the new Mac Pro that can drive it for some insane price premium, probably.
Marco:
But I'm hoping that's where they're going with this.
John:
It'll be the Apple 15-inch Retina Cinema Display.
John:
Oh, God.
John:
It's just what you wanted, right?
John:
Oh, man.
John:
It's like traveling back in time.
Casey:
The thing that I can't reconcile in my head is that to me as a non-Mac Pro user, because a laptop is sufficient for me, it seems so obvious to me that the Mac Pro just cannot continue in any even vaguely similar form to the way it is now because everything Apple is doing is going in the other direction.
Marco:
I know I just said that, but the more I hear you guys talking...
Marco:
first of all, it is a very high-margin product.
Marco:
They don't make a whole lot of them, but it is high-margin.
Marco:
And they could even raise the price premium by another $500 per case, and we'd all still buy them, right?
Marco:
Most Magpro users would continue to buy them even if the price premium was even bigger.
Marco:
So the profitability angle of them, I think, is probably covered.
Marco:
I don't think if they treated it as a unit of the company, I don't think it would be losing money.
Marco:
But...
Marco:
A lot of people will say, oh, well, it doesn't sell very many.
Marco:
They should just cut it out.
Marco:
Well, they don't sell very many Macs relative to iPhones and iPads.
Marco:
But no one's saying they should stop selling Macs.
Marco:
Some people say that.
Marco:
Well, yeah.
Marco:
Most people don't say that, though.
Marco:
It's not...
Marco:
People tend to develop these rules in their head about how Apple works and how they make decisions.
Marco:
I listed a whole bunch of these when I wrote about the iPhone Plus speculation.
Marco:
So many people are like, oh, they're not going to add another SKU because that's not the way they do things.
Marco:
No, that is how they do things when it makes sense.
Marco:
It's the iPhone math, Marco.
Marco:
Yes.
Marco:
So yeah, people have all these theories.
Marco:
They're like armchair Apple commentators, which yes, granted we all are, but the armchair commentators will come up with some rule that Apple will always follow.
Marco:
And in practice, there are very few of those rules.
Marco:
Apple breaks its own rules all the time.
Marco:
And so many decisions Apple makes are inconsistent.
Marco:
with previous decisions they've made and future decisions they will make, that you can't say, oh, well, they're going to get rid of this line because they hardly sell any of them.
Marco:
That doesn't necessarily mean they should get rid of something or that they will.
John:
Speaking of the iPhone Plus, we should start thinking now of how Apple is going.
John:
We've seen enough of these presentations already.
John:
What does Apple put up on the slides when they introduce the iPhone with the bigger screen?
Marco:
like what's the what's the how do you sell that i would say they're going to put it right between the iphone and the ipad like when they introduced the ipad and they had like the iphone on one side and the laptop on the other like what can go in between these things right i think they're going to completely ignore the competition which of course is all that size now and uh and just say here's an iphone here's an ipad you know we think there's room for something in the middle
John:
Well, see, the way Steve Jobs would have done it is his jerky way to do it would be kind of like we made the iPhone and we thought the size was just perfect.
John:
And, you know, we decided that, you know, a couple of customers said they would like a little bit bigger.
John:
So we made it a little bit taller.
John:
And, you know, if you want a little bit bigger screen, there you go.
John:
And then some people said they still wanted it to be bigger.
John:
And so, like, every time it's like, well, what we made was perfect, but you people just kept asking for some other things.
John:
So, like, we made it taller.
John:
That wasn't enough for you.
John:
So, fine.
John:
Here's, like, kind of in a jerky kind of way.
John:
Like, that's one way we'd go with it.
John:
The other way to go with it is just pretend you'd never said all those things in the past about the iPhone size being appropriately sized and just say, here's the new iPhone.
John:
It's got a beautiful display.
John:
It's, you know...
John:
4.5 inches or whatever the heck it is.
John:
We've always been at war at East Asia.
John:
And no, and no, then don't even say anything about it.
John:
And it's great.
John:
And you know, like you don't have in your own presentation, you're not obliged to address the fact that the previous phones had smaller screens.
John:
Yeah.
Marco:
And that's how they're going to do it.
John:
You know, if this thing's real, it's a new phone and it's great.
John:
And here it is.
John:
Look at this beautiful display.
John:
Uh, you know, and they'll just give you the measurement of display.
John:
They don't need to mention that that measurement is larger than the other one.
John:
Of course, it'll be the same res, you know, at whole nine yards.
John:
Uh,
John:
If they continue to sell the old size as well, then they might have to mention it.
John:
But I don't know.
Marco:
Oh, I think they'd sell both.
Marco:
Because with the iPhone 5 versus the 4S, they're not going to keep both of those sizes around forever.
Marco:
Once the 4S is out of the cycle of being the cheap phone, they're not going to keep that size going somehow.
Marco:
But I think the iPhone 5 size...
Marco:
The primary iPhone size or one of the primary iPhone sizes will always be that ballpark.
Marco:
And then if they have a bigger one, it'll always be that ballpark also.
Marco:
The 4S to the 5 is such a small difference in the outside dimensions of the phone.
Marco:
And the 5 is so much thinner and lighter.
Marco:
I mean, a lot of people with the 4S look at the 5 and they're angry because they bought the 4S, not the 5.
Marco:
Or they're angry that the upgrade would be too expensive or something.
Marco:
And they want to justify keeping the 4S and not getting the 5.
Marco:
So they're like, the 5 sucks.
Marco:
I don't want something that big.
Marco:
I hope Apple keeps these sizes around forever.
Marco:
Most people, though, who have owned the previous phones, who have ever picked up and held a 5, are like, oh my god, I can't believe how light this is.
Marco:
I want this.
Marco:
And even if they don't immediately go and upgrade, because not everybody can do that, most people recognize that the 5 overall is better.
Marco:
And that if the 4S went away, and the 5 was the smallest iPhone you could buy, very few people would say, I want something smaller.
Marco:
It's pretty great.
Marco:
So...
Marco:
So that, I see them keeping that around.
Marco:
But if they only made the big one, I think you'd have a lot of people demanding something smaller.
John:
You know, after reading Andy's, have you been reading Andy's Android conversion stories?
Marco:
I haven't read it yet, no, but I've seen some quotes, and it does sound pretty compelling.
John:
So one of the things he brought up, which I hadn't thought about too much before, is I always...
John:
I've seen Andy's... Andy's always got different phones that he's testing, right?
John:
And since they're not always Apple phones, they're bigger phones.
John:
And one of the things I hadn't noticed, because I'm not actually using them and just sort of playing with and feeling around that he brought up in the thing, is not so much that like, oh, the bigger screen is nice, which is true.
John:
And we know all the people who like bigger screens, people who have vision problems, people who just like it bigger.
John:
But that Android in particular...
John:
does something with larger screens that iOS is probably going to have slightly more difficult to doing, which is it uses the larger screen to actually show more information.
John:
So like the phones with larger screens have larger resolutions.
John:
So you, you know, the apps are designed to show more stuff.
John:
Whereas we're all assuming a bigger iPhone is just simply going to be all right.
John:
Same res, but just bigger, which is, which gives you half of what a big new screen can do.
John:
But Andy's saying what made him go over is not so much just that it's physically larger because the eyesight is fine.
John:
Right.
John:
But that,
John:
apps on that phone for that bigger screen showed more stuff and were designed to have more stuff on the screen.
John:
Not so many more items in the list view, but just more context in the side and just more room for information.
John:
It wasn't simply the same image you'd see on a smaller Android screen made larger because your vision is bad.
John:
So that half of the equation, I'm not sure what Apple can do there because all of its user interfaces on all the iPhone apps are designed for a thumb reaching around the screen.
John:
And by making it bigger,
John:
Yeah, it's easier to see, but you don't get to take advantage of that extra room because you're keeping the res the same to keep the developers from freaking out.
Marco:
Yeah, I wonder how... Because with iOS 6, they introduced auto layout, which is way more capable and mature and flexible than the old auto-sizing system they had in place.
Marco:
So now the frameworks are getting in place for...
Marco:
for ios apps to be like more flexible sizes android has always had that because android phones have always been a wide variety of sizes so you know android is is like all the apps are designed at least the good ones are designed to to be pretty flexible with the size that they're willing to render at and will and will work at just because they've always had to
Marco:
So that is definitely one advantage.
Marco:
But I wonder how Apple will do this in the future.
Marco:
They're laying the groundwork with auto layout, and by having the iPhone 4 and the 5 be these two different sizes, they're laying the groundwork for a future where we can more easily support more sizes, and iOS developers expect that and do that.
Marco:
But...
Marco:
it does add so much complexity and it is so much harder to design apps that way that I wonder if they're ever going to pull that trigger and make things that are a wider variety of sizes.
John:
I think they'll be forced to eventually.
John:
And I think the way they'll get away with it, because the stumbling block is not so much going to be the apps.
John:
Because assuming everyone gets on the auto layout train and everyone's had a trial run with making their apps taller, which you don't necessarily need to adopt auto layout to do, but it's pretty easy to do, right?
John:
But the sticking block is always games, right?
John:
And what I think they're going to do with games, you know, things designed for a fixed screen size.
John:
They're not using any real UI.
John:
It's just a big OpenGL view, you know.
John:
So, like, what I think they're going to do there with games is the same thing they did on the Retina MacBook Pros, which is...
John:
And they did this intent.
John:
There was no reason they were forced to do this in MacBook Pros, but they did.
John:
They said, okay, well, so you have native retina size, but we also have a size that's even bigger than that, and we'll just scale your whole freaking screen and put it in retina.
John:
And you're like, oh, that's going to look horrible in LCD at non-native res, but it turns out if you make the pixels small enough, it is not as horrible as you might think.
John:
So what do you do with the games that don't update on your bigger screen?
John:
You just scale them.
John:
And you would think it would look hideous and it doesn't look as good as it could.
John:
But because the pixels are so small, you are not incredibly sore that, you know, like as long as you keep the aspect ratio the same.
John:
Oh, this game wasn't updated for the iPhone 7.
John:
So it doesn't show any new information.
John:
All it does is scale the one that used to run on the iPhone 6.
John:
You know, it scales it horizontally and vertically in proportion, and now it fills my screen, and maybe that game guy never has to go back in port.
John:
And going forward, he can make games that work at all the different reses natively, but he never has to backport that.
John:
And then everyone else just deals with the auto layout issues.
John:
and tries to do something nice.
Marco:
I mean, one of the problems with apps, though, is that designers have been accustomed to... Before the iPhone 5 came out, designers were really accustomed to having pixel-perfect control over the whole screen, knowing that every iPhone...
Marco:
every iPhone slash iPod touch app would always have a screen that's exactly this shape exactly this physical size exactly this resolution so they could like they could design the entire app as like one bitmap basically yeah and web developers used to make web pages out of HTML tables with sliced up images but the world moves on right and so like you know now like now with the iPhone 5 they've broken that
Marco:
for a lot of apps and games.
Marco:
This does affect games too with UI.
Marco:
Not necessarily the main viewport of the game into the engine can be different sizes in most cases without too much work, but the UI usually can't.
Marco:
So that...
Marco:
That is challenging for games and apps alike.
Marco:
But once they've gotten people accustomed to it with the iPhone 5, maybe now it'll be easier and people will start adapting.
Marco:
Also, stylistically, what's in fashion right now in design is moving out of those extremely detailed pixel-perfect textures and into flat design, which scales into different aspect ratios way easier.
Casey:
that fad will probably be over by the time they change the screen size but we'll cycle back again and we'll be back to making everything look like it's made with uh wood yeah wow now the thing that that where i'm not on the same thought train that you guys is that you guys are is everyone i've ever spoken to which to be fair is a very small sample size but everyone i've ever spoken to who's tried auto layout has not had good things to say
Casey:
And I think, was it Brent Simmons that just posted something?
John:
Yeah, I think it's not auto layout that's bad.
John:
It's auto layout plus IB.
John:
I totally agree with what Brent said, and I've seen that in action with people trying to do stuff with auto layout.
Marco:
I still don't use auto layout because I can't figure out how it works in Interface Builder.
Marco:
So I just don't use it.
Marco:
I just use the old system because it's good enough for my needs.
Casey:
So, and I guess maybe the answer is that we use the, what is it, visual format language or whatever.
Casey:
We all start drawing ASCII art.
John:
I think it's a bit of a learning curve.
John:
And maybe you bail on that learning curve if you know the old system well enough that it's not worth it for you to climb it.
John:
But like, I mean, what Brent said is like the way it has to be.
John:
Yeah.
John:
When you lay something out with a GUI tool, like auto layout is not going to leave, leave in like sort of an open ended question.
John:
It's going to, you have to have sort of a, it has to behave in a certain way.
John:
It has to be deterministic.
John:
So it's going to add the missing constraint that you have not yet specified.
John:
And if you don't know what all those implicit constraints that it's adding for you are, you're like, well, I didn't add that constraint.
John:
It's like, well, you need something there to balance the equation.
John:
So the thing knows what it's supposed to do when you resize.
John:
Right.
John:
Uh,
John:
and that can be frustrating.
John:
But I think if you, if you really, really knew auto layout, it would be obvious to you what implicit constraints interface builder is adding.
John:
And you wouldn't be surprised by when you lay something out without a layout interface builder, add one constraint and see how it behaves because you'd know what all the other ones would have to be to fill it in.
John:
Like, I mean, there's still room for variation in there that IB could be adding things that you don't think it, it should close the equation in a different way or whatever.
John:
But, uh,
John:
I think it's a solvable problem and Apple will iterate on it until they get something that works reasonably well.
Marco:
Also, it's kind of a chicken and egg thing.
Marco:
Right now, most apps are able to adapt to the iPhone 5 without significant changes because it just stretched vertically.
Marco:
And any app that has a vertically scrollable content area in the middle, any kind of table view or list app, that was a really easy transition for most of these apps to make.
Marco:
So...
Marco:
it wasn't that painful to adapt to the iPhone 5.
Marco:
If they would add a whole new resolution that was wider and taller, that was different in both dimensions, even if it's a different aspect ratio, then that adds even more complexity.
Marco:
If they do that,
Marco:
then it's going to be so much work to adapt a lot of these apps to it then maybe it'll motivate developers to convert to auto layout or to start using it for new projects whereas now the value proposition isn't that strong for it because it's like well the old system works well enough for so many cases and we already know it and we only have to support two devices and it's fairly easy to support them both now so you know it's it's it's a lot less compelling now
John:
Do you remember – I'm trying to remember the auto-layer demos at WWC.
John:
Did you go to those sessions?
Marco:
I did, yeah.
John:
So, like, I'm trying to think of if they had the ability to do the thing where, like, okay, so now when – they were showing it on the Mac.
John:
But, like, so now when your window is a little bit bigger, suddenly new information and or UI elements come into existence that weren't previously there.
John:
Sort of like responsive design when they have parts of the navigation disappear and stuff.
John:
I think that's important.
John:
Because that's –
John:
Because that's what you really need for like, you know, you're trying to avoid a situation where we have now.
John:
It's like, okay, I make my app for the iPod and or for the iPhone.
John:
And then I have to, you know, if I'm going to do a good job, I got to do different UI for the iPad because it's just so different in size.
John:
You can't just take the phone thing and scale it up.
John:
Well, if you have a larger iPhone, like getting back to Andy's point.
John:
If you really want to do an awesome job for those people, you're going to say, okay, now I have more room to put stuff.
John:
I shouldn't really just take my iPhone screen and make sure everything scales correctly.
John:
In fact, I have room for another button here.
John:
I have room for an ancillary display with some other information.
John:
That's what the AAA guys are going to do.
John:
And the question is, if they're doing that, does auto layout a factor or do they just make three different views?
John:
The regular iPhone, the bigger iPhone, and then the iPad.
John:
And if auto layout has the ability to sanely let people say, okay, well, here's the iPhone one.
John:
If you make it a little bit bigger, you know, another control goes into view and another like display thing.
John:
And then I'll still have to do another layout for the iPad, you know?
Marco:
Yeah.
Marco:
See, like I bet most good developers or especially good developers, good designers, like most good developers will want to code those separately anyway, because a lot of times, even if it's like, if it's okay, well, we'll show or hide these controls or rearrange them.
Marco:
Even then, a lot of times the iPad interface probably should work even more differently than that.
Marco:
And so I think we're always going to have people who want that.
John:
That's the iPad, of course, what I'm saying, from the small phone to the bigger phone.
Marco:
And that's a smaller jump, hopefully, in what you want to be different.
Marco:
So auto layout could take care of that in a lot of cases, I'm sure.
Marco:
But I still think so many people are going to want to custom design things to just be more different than what the layout engine is capable of providing.
John:
And Carter is the old curmudgeon syndrome.
John:
If you know how the regular layout works, is it worth it to you to learn how the – because then all you're doing is like you're going through an abstraction layer that's preventing you from just setting the things that you know you want to set.
John:
Yeah.
John:
In some cases, auto layout can do things that you would have to write code for.
John:
And that's the kind of case where you're like, am I writing the stupid freaking layout code to recalculate the distances between these things based on the... It's like, you know, if springs and struts can't do it, but auto layout can, auto layout is saving you from manually writing that code to do some stupid math on points to figure out how far things are.
John:
And that's the type of thing that probably would demo well at WWDC to say, if you didn't have auto layout, the amount of code you'd have to write for this...
John:
would make you not want to use this feature and would make you not make your layout act this way.
John:
But look how easy it is in auto layout versus like, I could do this in springs and struts.
John:
There's no reason for me to use auto layout.
John:
It's just getting in my way.
Casey:
Well, the other thing that I find interesting about auto layout is, although I, like I said earlier, I haven't heard a lot of people sing its praises.
Casey:
I certainly haven't heard a lot of people say this is supposed to work, but doesn't a la iCloud.
Casey:
You know, it doesn't seem like the technology is bad.
Casey:
It's just a big learning curve, like the both of you guys have been saying, whereas iCloud seems to have somewhat of a big learning curve and it's a piece of crap.
Casey:
Right.
John:
You can't learn anything if it doesn't act in a deterministic way.
John:
So a local API and a framework on your system, you have a fighting chance of figuring out.
John:
But when you're communicating to a black box over the network and you can't figure out why it works the way it does, it does not converge on a solution.
Marco:
Well, when Apple makes new APIs and frameworks and things like that, they're solving a number of problems with these APIs.
Marco:
Some of them appear to be designed not necessarily for everyone to use as their new default of how they build things, but for rapid development or for less sophisticated developers to get something working well and quickly.
Marco:
So I think one of the biggest examples of this is Arc versus storyboards.
Marco:
Arc is a really great feature that they obviously want everybody to use.
Marco:
There's really very few downsides to it overall.
Marco:
And even power users, even very skilled developers, will get a lot of value out of using Arc with almost no downsides.
Marco:
Storyboards are a very restrictive...
Marco:
and limited structure that your app uses, they can save a lot of time for rapid development or for less experienced developers.
Marco:
They can save tons of time and provide a nicer framework for certain things, but they're so limited that a lot of high-end developers really can't use them for much.
Marco:
And so maybe auto-layout is...
Marco:
Not quite to the level of storyboards, but maybe it's not quite to the level of arc either.
Marco:
It's there for people to use maybe sometimes, or as they go forward, maybe new developers learn this, but maybe it isn't intended to capture a lot of the older developers quite yet, because maybe the value isn't quite that clear on it.
Marco:
And certainly, once you have one of those situations where you're laying out something with the old system that's really a pain to do it, once you have one of those situations, yeah, maybe then you start learning it.
Marco:
But I think there's very little reason for developers to convert things to auto layout if they're working fine with springs and struts.
Marco:
Or to absolutely use auto layout for everything in their next project.
Marco:
It might not make sense to do that yet.
John:
Maybe it's just the circles that we travel in and the people who read, but the number of people who have a grumpy face about IB, which is not like a fancy new technology.
John:
It's come from the next days, right?
John:
They're like, I'll just do it in code.
John:
It just shows that sometimes, no matter how – that was a big selling point in the next days.
John:
It was like, look at Interface Builder.
John:
It's amazing, right?
John:
And, you know, some people just say, I'd rather just do it in code.
John:
And, you know, that's just what they would rather do.
John:
And you're not like, no matter how nice you make the tool, if people don't want a tool that does that, if it's not solving a problem they think they have, it will just sit there.
John:
So like...
John:
Auto layout, even if they make it awesome and perfect, just like Interface Builder, there'll be some people who say, nah, I prefer to just do it in code.
John:
And they will.
Marco:
Interface Builder, I've always thought has been comically unintuitive.
Marco:
My background, as Casey knows, because he was there, my background was Visual Basic.
Marco:
And...
Marco:
Microsoft does a lot of things badly.
Marco:
Gotta give them credit for that.
Marco:
They do so many things badly, it's quite impressive.
Marco:
However, their development tools are really good.
Marco:
And they're especially good at not having a really huge learning curve to get started on something.
Marco:
And Visual Basic, and now of course it's way more sophisticated with all their new stuff, but I started using Visual Basic with version 1.0.
Marco:
Literally.
Marco:
Visual Basic 1.0.
Marco:
Even then, it was really easy to use.
Marco:
You drag out a control, and you double-click it, and there's the function.
Marco:
It was so easy to use that I could figure it out as an extreme novice in seventh grade.
Marco:
It was really easy to figure out.
Marco:
Interface Builder has so many weird little things about it, weird behaviors that aren't necessary.
Marco:
It's not like...
Marco:
oh, you're going to have some advanced need at some point, and you might need to know this.
Marco:
No, it's like, if you're going to use this to do anything at all, you need to know these weird things about it that aren't very intuitive.
Marco:
And it's always been that way.
Marco:
And they keep saying it's getting better, and in some ways it gets better, and then it adds new weird things that you need to learn in some weird way.
Marco:
So Interface Builder has never been particularly easy to use.
Marco:
Casey, I'm curious because you've come to this way more recently than John and I have.
Marco:
What do you think of Interface Builder?
Marco:
Have you had those problems?
Marco:
And you have used all the Microsoft stuff more recently because you were a Windows guy for so long at work and you still are, kind of.
Marco:
What do you think about this comparison?
Casey:
uh i think for the most part i agree with what you said uh i don't have any hate for interface builder and i think that largely comes from the fact that a i haven't done you know years upon years of ios development and b all the ios development i've done is tended to be with reasonably simple and straightforward user interfaces um
Casey:
I do agree, though, that it is not intuitive.
Casey:
Like when you were talking about how you drag a button onto a form in current Windows forms, parlance or parlance, however you pronounce that word, esoteric.
Casey:
Regardless, you just drop it on a form, you double click, and there's your method, just like you were saying.
Casey:
Whereas with Interface Builder, as you're describing this, I'm thinking, well, how does that work in Interface Builder?
Casey:
Well, you have to have something on the header or perhaps the M file.
Casey:
that is an ib action or an ib outlet well wait what's the difference between the two oh well you see an ib action is for a function or a message and an ib outlet is where you just want to have a reference and it's already it's like oh my god just shut up so i don't think it's terrible i don't have a problem with interface builder but i would agree with everything you said about the microsoft developer tools really are good and it's funny because i've been teaching a co-worker objective c and coco and whatnot
Casey:
and he's really enjoyed it and got over the ugly ugly ugly syntax a lot quicker than i did but one of the things that it's hysterical to watch is when he's trying to figure out um what the right method is to do something like for example to make a string lowercase rather than go to the documentation
Casey:
What does he do?
John:
He tries to auto-complete it.
Casey:
Yep.
Casey:
He uses it.
Marco:
That's the Windows developer for you.
Casey:
Because Windows is so good at that.
Marco:
That's the thing.
Marco:
He's so good at it.
Marco:
When you're programming in anything .NET for the first time, all you need to know is the first word, system.
Marco:
Is it still system, is it?
Marco:
Yep.
Marco:
So yeah, you can know nothing about the language you're programming, or the API that you're programming against, at least.
Marco:
Language, of course, there's always things.
Marco:
But you can know nothing about the API you're programming against, and just type in system .NET.
Marco:
And just start there.
Marco:
And you will probably find what you need.
Casey:
Yeah, you're absolutely right.
Casey:
And that's the funny thing is watching him use Xcode's crummy IntelliSense.
Casey:
I know it's not called IntelliSense, but whatever they call it.
Casey:
And it's gotten better.
Casey:
I remember everyone freaking out at WWDC.
Casey:
They were so excited when somebody announced that when you start typing NSS rather than... NSStream.
Casey:
Yeah, or whatever it was.
John:
I was just trying to remember what the bad match was.
John:
It was NSStream, right?
Casey:
Or set, maybe?
John:
I was trying to formulate a Google query for it.
John:
I was going to type NSString auto-completion annoying.
John:
Yeah, it was probably on a stream.
Casey:
Whatever it was.
Casey:
Everyone went berserk because they finally got the autocomplete to the point that it sort of made sense.
Casey:
But it's not a great documentation browser, whereas in .NET, you really never need to kick open any documentation.
Casey:
You can just sit there with IntelliSense and you'll find what you need.
Marco:
I have to have that organizer window open and I have to have it to the documentation tab and I'm going over there and searching in a search field like every five minutes for something like it, cause the, the, any kind of built in, you know, pop-up automatic documentation is usually not enough for what I'm looking for.
Marco:
And, or I don't know the name of what I'm looking for exactly.
Marco:
And I, and you know, I can't autocomplete it or, or the autocomplete is freaking out because of some thing that it choked on, you know, a hundred lines up that I don't know about yet.
Marco:
Uh, and it's just not working.
Yeah.
John:
You whippersnappers.
John:
I'm writing all my code the old-fashioned way.
John:
I don't have auto-completion.
John:
I just memorize every single freaking function, its name, and the arguments, and the return values.
Marco:
That's how I write PHP, which all my backends are still in PHP.
Marco:
That's how I write that, because I'm writing it all in TextMate, which doesn't really have IntelliSense-type features.
Marco:
Or if it does, I don't know how to activate them.
Marco:
And please don't email me.
Marco:
I really don't care.
Marco:
I can write that way, but...
Marco:
It's so nice when you don't have to, and it really is a major productivity booster to have things like IntelliSense.
Marco:
Doing that well makes a really big difference to coding, especially when you're new to a language or an API.
Casey:
You're absolutely right.
Casey:
And I think...
Casey:
Part of the problem might be that Objective-C is such a verbose language, and method names are string by replacing occurrences of string with string with options, or whatever the hell it is.
Casey:
I forget what it is off the top of my head.
John:
That's one letter in Perl, S. Exactly.
Casey:
Then delimiters.
Casey:
Well, let's be honest.
Casey:
All of Perl is just regular expressions anyway.
Casey:
You can read one of them.
John:
I think we can talk about that on some future podcast.
John:
At a certain point, the verbose names do not help understanding your reading.
Marco:
Well, except once you do get familiar with Apple's crazy API naming style, then you can start guessing the names of things before you know them, and you can usually guess correctly, at least to the point where that autocorrect will help you.
John:
That's so true.
John:
You know it to begin with, because once you learn the words for the event,
John:
handlers for will and did and finish and all that stuff.
John:
Then at least you have a fighting chance on the prefixes.
John:
But the words that come after the prefixes, that's kind of like people are writing little essays in their parameter names and the order that they put, like the adjectives and verbs and where the with comes and the option and error and all that.
John:
Yeah.
John:
There's a rich history of scrambling up the fake name parameter things.
John:
That's what they should do.
John:
They'll never do this, but give Objective-C real name parameters so the order doesn't matter anymore.
John:
That'd be great.
Casey:
Oh, God.
Casey:
That would be a different language.
Casey:
That would be a different language.
Casey:
It's funny, though, Marco, because just today, I was trying to remember, I was working with my coworker who's learning the language in the API, and I was trying to remember, wait, how do you get a lowercase string?
Casey:
It's not too lower.
Casey:
That's .NET.
Casey:
No, that's not how Apple would do it.
Marco:
Lowercase string.
Casey:
No, you know what?
Casey:
I bet Apple would do lowercase string, and sure enough, that's what happens.
Marco:
Or like string by converting to lowercase.
Marco:
Yeah, so that's what I'm saying.
Marco:
That's true.
Casey:
That's true.
Marco:
Like earlier today, I had an array that I wanted to join with a string.
Marco:
And join all the components with a string.
Marco:
And so I had the array, and from the array I started typing string by.
Marco:
And I'm pretty sure that was correct.
Marco:
It's string by joining components with string, or something like that.
Marco:
And because I'm familiar enough with Apple's style, I was able to guess that method without looking it up.
Marco:
And I was right.
Marco:
And so...
Marco:
An interface builder is actually very similar.
Marco:
Once you get it, then you can see, oh, okay, I can see why they thought that made sense, and now it makes sense to me, and now I'm past it.
Marco:
But the learning curve is just ridiculous.
John:
I understand the verbose naming thing, that someone who has never seen Objective-C before can look at that and guess that you are taking a string and joining a bunch of other strings with some other string, and they can tell which is which.
John:
You know what I mean?
John:
But the visual...
John:
the mental and visual space that that call takes up as compared to like S equals a dot join, and then single quotes, the joining string.
John:
Like maybe someone doesn't know what that means, but once you know the language and know a little bit about the basics of the API, it's,
John:
It's just – that's why people are alerted to verbose things, not because verbose is so much bad, but because there's a limited common vocabulary that people feel like should not be that verbose because it happens so often.
John:
And that's why a lot of Objective-C code looks like a lot of visual stuff like squint, a lot of black on the page for doing operations that in some higher level, more dynamic language like JavaScript even or Perl or Ruby or Python would just be so much –
John:
take up so much less room and be so much faster to scan because you wouldn't have to read.
John:
You know what I mean?
John:
Like it's just join map grep filter, you know, replace substitute instead of the big English sentences with stuff hanging off of it.
Marco:
Right.
Marco:
Although the big English sentences are substantially easier to read if you aren't familiar with the API that they're calling.
John:
That's true, but I'm saying there's a subset of really super common functionality.
John:
So I guess maybe it would be weird to have a language where... I mean, I don't know if it's weird.
John:
I think it's reasonable.
John:
They call it in Pearl-Huffman coding, where you take the things that are common and make them concise.
John:
And as you get more esoteric, you get more verbose.
John:
So the built-in stuff is super-duper short, lowercase is LC, right?
John:
But...
John:
the really more esoteric things like you know creating a socket with timeouts and a binding port and stuff that is verbose and has big name parameters and everything's long and spelled out right whereas in objective c and not the language but the api and the coco and foundation apis everything is verbose even like basic string functions even like things dealing with numbers and formatting like everything is verbose they don't say okay people are going to change a string to lowercase way more often than they're going to like set up some sort of
John:
for some event or whatever, set up an NS notification center, right?
John:
So shouldn't one of those be shorter because it's going to be more common?
Marco:
To be fair, the lowercase string method is one of the shortest method names.
John:
It's not two letters long, right?
John:
And substitution, like running regular expressions matches and substituting, like, you know, Perl thought it was important enough to put syntax in the language for it, and so did Perl.
John:
sort of JavaScript, kind of put syntax in the language for it, and a couple other things too, but, you know, okay, so fine, an object received, it's not a syntax in the language, but the API for things that deal with strings don't have any recognition of how common they are.
John:
Like, they are just as verbose as everything else.
Casey:
Well, and NSString is monolithic as hell as well.
Casey:
It has so many different weirdo methods, like for paths.
John:
It doesn't have data type things related to URLs.
John:
It's like, I thought you were a string.
John:
What do you have methods that have to do with URLs?
John:
Well, I kind of know about those two.
Marco:
Yeah, there's a whole bunch of things.
John:
Why?
John:
Why do you know about URLs?
Marco:
Your string class.
Marco:
The core, like, useful foundation classes, like NSString, NSData, NSArray, like, there's so much weird, like, okay, I want to convert this to this, which object has that class, or has that method, which class has that method, and a lot of times it's not the one you expect it to be.
John:
It's not, you gotta do, like, you know, init with, and then you pass the NSString, or do you call a method on NSString that returns the thing?
John:
String from data, yeah, and yeah, it's,
Casey:
Yeah, string to data gets me every time.
Casey:
I always assume the wrong one has the method I need, and I always have to spend two minutes looking through documentation.
Marco:
I actually have a macro, IP string to data.
Marco:
That's it.
Marco:
And IP data to string, which is also a very common one.
Marco:
Like when dealing with web services, you get back data.
Marco:
I use those constantly.
Marco:
I also have... I have a whole string category that I stick on my strings.
Marco:
There's...
Marco:
I stole XPath's string functions, so I have substring before, substring after, contains, and a few other little things like that.
Marco:
Like, you just parse strings and check them, because it's just, even contains, it's like a way more compact syntax.
Casey:
Oh, God, yes.
Marco:
If n is not found, does not equal string by range of string, and yeah, it's so much more compact.
Marco:
So terrible.
Marco:
So I'll definitely add helpers for things like that that I do very commonly.
Marco:
URL encoding, the default method of string by replacing percent escapes using encode, that big long method that converts a string to URL encoding doesn't do it right for OAuth.
Marco:
there's a few characters that that method doesn't encode that whatever RFC OAuth requires does require them to be encoded.
Marco:
So I have my own IP URL encode string methods.
Marco:
I have weird add-ons like that that just save me time.
Marco:
And the whole idea of having categories on classes is awesome, that you can extend the built-in system classes
John:
You think that's awesome?
John:
Yeah, you love Ruby.
John:
Monkey patching your brains out.
John:
You're going to go blind.
Marco:
Certainly it can be done badly.
John:
And also, haven't you heard?
John:
It's three letters, please, for third-party codes.
John:
Yeah, that's crap.
John:
In the prefixes.
John:
You're just going to stick with IP because that'll never conflict with anything having to do with the technology stack, right?
John:
Yeah, exactly.
Casey:
I don't understand why there are no namespaces.
Casey:
I mean, I understand because it's all C. It's just C with a runtime.
Casey:
I know, I know.
Casey:
But God, namespaces would be so nice.
John:
Well, you know, like baby steps.
John:
All these problems you're talking about would be solved if they just had a better, nicer, higher level language.
John:
But, you know, not... It'll never happen, John.
Casey:
He's been bitching about that for years.
John:
Well, this year is going to be type inference, right?
John:
So...
John:
Yeah, well, we're lurching towards something, but like all that crap with the strings and the data and like, you know, dealing with stuff like that.
John:
It's just it completely goes away.
John:
If you have a language that has, I don't know, native strings and, you know, a little more laissez faire attitude about data types where you can just, you know.
John:
sling things around and not worry about if it's a float or an integer number oh no you can't do that that language is useless i know i know all the reasons why objective c is living on and it's way more efficient and so on but you know everyone wants to have their cake and eat it too so right now at least apple has its cake i honestly i like that analogy works but
Marco:
I like Objective-C and all of Apple's recent stuff with it.
Marco:
I mean, yeah, it's not perfect, but I think if you think any language is perfect, you don't know it well enough yet, or you don't have enough experience as a programmer, honestly.
Marco:
And so every language has problems and shortcomings, and...
Marco:
And just by the nature of these things, it's not really possible to design a perfect language.
Marco:
And certainly, Objective-C has a lot of ancient baggage that it's still carrying that it can probably never get rid of because of the kind of language it is.
Marco:
But...
Marco:
apple's doing some pretty awesome stuff with it like you know even simple things like they did reduce a whole lot of that boilerplate uh last year when they introduced uh compact syntax for you know array access dictionaries stuff like that like you know the compact primitives like they they they introduced a lot of that stuff that you can that they are making real progress you know making synthesize optional like you
John:
And they'll get rid of the double name stuff with the type inference, where you won't have to declare the variable being of type whatever, and then call the class method to give you a new one of those.
John:
Didn't I just write that name?
John:
Exactly.
John:
Well, that's the one.
John:
Of course, that's the class that I'm going to call the method on to instantiate one of those, because that's the type of the variable.
John:
Why can't you figure it out?
John:
So that's my next guess for what they're going to add.
John:
But I still feel like at a certain point, you can't – it's like HFS+.
John:
At a certain point, you can't just keep adding crap or fixing crap or trying to make it better.
John:
At a certain point, you need a new boat.
Marco:
Oh, right.
Marco:
As long as it's like a C-based language, you're always going to have – there's going to be a pretty hard limit on a lot of these modern niceties that you can add to it.
John:
They should, I mean, like the transition I see, you know, I'll keep predicting this until I'm dead or until Apple is out of business is that like, you know how now you have core foundation, which is just straight C and you've got the objective C APIs and everyone's like, Oh, I got to deal with core foundation API.
John:
It's like lower level and it doesn't have all this stuff or whatever.
John:
Uh,
John:
If they come up with something higher level than Objective-C, which I think a higher level language is much more appropriate for most of the stuff you do.
John:
Catching events, figuring out when they click this button, bring this view into view.
John:
That crap does not need to be in a C-based language.
John:
It's just like monkey work of connecting up things in the UI.
John:
But there will always be parts of it that need to be in a lower level language.
John:
So then you have a continuum of like, all right, I wrote most of my code in whatever this higher level language is.
John:
And then some portions of it are objective C because it's so much more efficient.
John:
And then presumably some portions are still in core foundation.
John:
Like it's a layer cake of like, all right, well the open GL crap is, you know, still a straight C API because that's really performance sensitive.
John:
And then somewhere in the middle is something that's like, it's not like high level UI dealing with, but you know, it's a little bit lower level than that.
John:
And then at the top, you'd be right.
John:
Overall structure.
John:
We have most of the time you're writing this very high level language.
John:
Yeah.
John:
I could see them going to something like that.
Marco:
I think that served them very well, though, in these early years of mobile computers, because they have gained so well.
Marco:
They've benefited so much from just the sheer efficiency of the C-based language.
John:
The things that benefit them early suddenly become disadvantages later, because then suddenly everyone else's less efficient language, like the CPUs catch up, and it's like, oh, that was the great advantage for you back then, but...
John:
Now not so much.
John:
Now that advantage is insignificant.
Marco:
If webOS came out five years from now, it would have a way better chance in the market.
Marco:
It wouldn't be dog slow.
Marco:
Everyone wouldn't be complaining about its terrible battery life and terrible performance.
Marco:
It wouldn't be that big of a difference from anything else that was out there.
John:
It's kind of like Android.
John:
Java is disgusting, right?
John:
But Android like it is, it is using a higher...
John:
It is using a high-level language, and it was slower for a long time.
John:
And arguably, iOS still has the performance advantage there, but the gap has really closed.
John:
Hardware is getting better.
John:
There's more memory.
John:
There's more stuff to indulge Java's foibles.
John:
And if you believe that the things you don't have to worry about in Java, like segmentation faults and crap like that, are an advantage, then...
John:
suddenly Android's platform in this particular respect becomes more attractive to development, you know, to doing new developments.
John:
You don't have to learn about Arc.
John:
You don't have to learn about pointers for crying out loud.
John:
Like, you know what I mean?
John:
Right.
Marco:
You don't have all these weird stars before your variable names that new programmers have no idea what they're there for.
John:
Yeah.
Marco:
And why it weirdly breaks when they forget one.
John:
Luckily for Apple, in the continuum of things that make someone go on a platform or not, the crappiness of language is very low on the list, as evidenced by the fact of all these bazillion people suddenly learning Objective-C, because that's where the money is.
John:
All right, we'll learn your crazy-ass language with square brackets.
John:
Just get out of my way.
Marco:
And that's always how it's been, except on the web.
Marco:
On the web, you can write in pretty much anything as long as you can find some server software to run it.
Marco:
So the web has tons of great languages to choose from, and it doesn't really matter which one you write in.
Marco:
But on native platforms, there's always been one language and one framework on every major native platform where you really should be writing things in that.
Marco:
And Windows for a long time has been C++, and then more recently it's moving into .NET stuff.
Marco:
OS X has always been Objective-C.
Marco:
iOS has always been Objective-C.
Marco:
They're adding some of the frameworks.
Marco:
There's always that push that if you want to develop on this platform, you should really be doing it in this language everywhere except the web.
Casey:
So if I agree with that, that is a very interesting point.
Casey:
My question for the two of you gentlemen is if you were to pick the language today that would replace or supplement Objective-C, what is it?
John:
John, this is all you.
Casey:
uh what are my what are my criteria like what what what realistic bounds do i have to stick within here you it has to be language that exists today which by the way i don't think apple would necessarily play by that rule no they definitely and it and it has to it has to prevent john syracuse from continuing to bitch about what languages are available for use on apple platforms
John:
No choices to fill those criteria.
Casey:
Okay, it will get him to complain as little as possible, which is an extremely lofty but theoretically plausible goal.
John:
This is a good question because it makes me realize all this time I've been talking to this, I've never been pushing for Apple to adopt any existing languages.
John:
I've always been thinking that they will do their own thing.
John:
like pretty much as they have been like objective C at this point is their own thing.
John:
Like it may have started out as the old, but like at this point, whatever, whatever crazy fake version number they apply to the language, they've changed it so much.
John:
They're completely fearless about changing it.
John:
So I always imagined whatever thing replaced, it would also be of their own invention, exactly tailored to what they need the language to do.
John:
Uh, and no language, like there's no language out there that I like well enough to say they should just do that one.
John:
Like,
Casey:
And I think you're right, and I think they would do their own thing.
Casey:
But then that John Syracuse guy would continue to complain about the fact that everyone has to learn this weird new language.
John:
No, I never complained about learning.
John:
I've never made a single complaint about, oh, you've got to learn this new language.
John:
Never.
Marco:
Well, here's an idea.
Marco:
What if they are doing it already?
Marco:
So similarly how Objective-C in its first implementations was basically a macro language on top of C.
Marco:
Is that accurate?
Marco:
I've always heard that.
Marco:
You're thinking of C++.
Marco:
Okay.
Marco:
No, I don't think so.
Marco:
I think it was C. Anyway.
John:
C++ was C with classes.
John:
Yes, that is also true.
Marco:
But I think Objective-C started out the same way.
John:
It always had to have a runtime, right?
John:
I mean, it wasn't just macros.
John:
It had to have a runtime.
John:
It had to have a library of code to, you know, somewhere Objective-C message sent had to be written and you had to call into that library to call a method.
Marco:
Right.
Marco:
Anyway, so Objective-C started out as a bolt-on on top of C, and it has matured a lot since then, and the C roots are still all there, but now the tools are all native of Objective-C, the compilers are all native of Objective-C that Apple's writing.
Marco:
That is the language now.
Marco:
What if their next big language...
Marco:
is what they're doing with Objective-C now.
Marco:
That's moving towards it.
Marco:
And then at some point in the future, they enable some kind of new syntax mode where it adds a lot of the stuff that we want.
Marco:
It adds a lot of the complex stuff.
Marco:
It hides pointers and things like that.
Marco:
Built on top of Objective-C temporarily, or in version 1.
Marco:
And then over time, and exactly what you said, you'll have to drop into that syntax to use some low-level APIs, but most of everything will be available right there.
Marco:
I think they're moving – because if they were going to replace this language in five years, I don't think they'd be putting this much effort into it now.
Marco:
They're doing radical changes to it now.
John:
I know.
John:
The objective C without the C thing seems to be the path they're going on, but this does not entirely satisfy me.
John:
I'm sure they're taking this into account with their plans.
John:
They are, totally.
John:
They're listening right now somehow.
John:
The people who are making decisions about what to do disagree with me about the –
John:
about what the ideal situation would be.
John:
I think they would be perfectly happy to slowly evolve the objective C to eventually bifurcate it into objective C without the C part where safety is much more guaranteed than it is and you could have an unsafe, you know, sort of realm.
John:
And then most people eventually get most people doing their coding in the safe part where you can't scribble all over your own memory remotely.
John:
where you just call into Objective-C APIs and just use the escape hatch for the other stuff.
John:
But I really, like I mentioned, I really think that ideally, and of course you can't have the ideal, but ideally a higher level language with more safety guarantees and less fussiness about types is
John:
wouldn't just mean, oh, well, we've got that language, we're all set.
John:
It would also necessarily imply different APIs.
John:
In a language with built-in strings, and a string doesn't exist.
John:
You don't instantiate a class to get a string in a language that has native strings.
John:
In a language that has language-level support for regular expressions, that's not like a library you call.
John:
That's not like...
John:
as things get pulled into the language, you necessarily change the way API works.
John:
Whole, whole concepts of APIs change based on what the language supports.
John:
So you, so you, that's why I like these bridges are so terrible.
John:
Like if you have Python, you're like, Oh, I have this amazing, you know, Python, it's high level language, but you're just calling the same freaking APIs and they don't, they don't mesh.
John:
It seems like, boy, no one would ever write a Python API like this.
John:
It's so clear that I'm calling into an Objective-C API, not just because of the naming inventions, but just because of, like, you know, write out error parameters where you pass in an error and it's going to write back to it and crap like that.
John:
Like, that doesn't happen in high-level languages because, you know, I mean, you could.
John:
You could pass references in languages with references, but it just doesn't.
John:
It's not how you design the API.
John:
And like I said, the whole NSString thing.
John:
wing of the language just disappears.
John:
And then like Ruby, you have all the strings be objects and you have methods on them, which isn't that the same thing?
John:
Well, not really, because it's not like you're saying new string and putting... I just feel like the language and the API are a match set.
John:
and you can't change one without changing the other.
John:
And if you change the language sufficiently, if you keep evolving this language to the point where it starts becoming higher level and more safe and less work for the developer, it will be a shame if the API still looks like, oh, why does the API look like this?
John:
Well, it used to be it was just the C-based language, and this is the way everything was.
Casey:
Well, see, I'm not sure I agree, though, because everything you just described is .NET.
Casey:
Or at least to my ears.
Casey:
And it's weird because I have no love for Microsoft, but I do think .NET is actually a pretty cool language.
Casey:
And to a .NET developer, you, generally speaking, can use the Win32 API without ever touching C++ or C.
Casey:
Because .NET consumes all of that and acts as the bridge.
Casey:
And even when I'm calling into these APIs, I don't need to worry about pointers.
Casey:
I can, but I don't need to.
Casey:
And generally speaking, I don't need to worry about any of that crap because .NET has encapsulated all of it and is putting a facade in front of it.
Casey:
So I don't have to worry about that.
Casey:
That being said, if I have an old C API that I want to call or C++ API I want to call, I can P invoke into it.
Casey:
And I can say, hey, there's DLL here.
Casey:
Here's the structure of the method I need to call.
Casey:
And I can even do it unsafely.
Casey:
And I have an unsafe keyword where I can manage my own memory and do all that crap.
Casey:
So everything you just described, believe it or not, is .NET.
John:
I know about .NET.
John:
I think .NET is way far ahead of where Apple is, technologically speaking.
John:
Maybe not necessarily API-wise, because Microsoft seems to have more trouble figuring out what it wants out of an API and sticking to it.
John:
I don't remember what iteration of, you know, no, you should use this toolkit for UIs.
Casey:
Change every five years.
Casey:
No, seriously.
John:
Yeah.
John:
Yeah, they have problems there.
John:
But like the CLR and that whole idea behind it, that is a foundation that if Apple had that foundation now and it was performant and they'd put as much time into it as Windows had, they would be in a much stronger position to say, look, everything is common language runtime and we have all these escape hatches for unsafe and we can put new languages on it.
John:
And, you know, a Python on the CLR is just straight up Python.
John:
You write your Python functions and we can provide a Python API.
John:
You're right, they have to do bridges, but hopefully they don't just do straight bridges.
John:
Wrappers are different than bridges.
John:
A wrapper is like, I want to use a convenient API that hides all the stuff that's irrelevant to me because I'm in a high-level language.
John:
And wrappers have a cost in terms of performance, but they're a better semantic fit than bridges are.
Casey:
Absolutely.
Casey:
And that's what I'm used to, is seeing a bunch of wrappers and facades that under the hood are doing P invokes and all the nasty, crappy things that I don't want to have to do.
Casey:
But to me, I'm just calling system dot whatever dot whatever.
John:
The disadvantage that Microsoft has is that the API that it's wrapping is much more disgusting.
John:
You know what I mean?
John:
When 32 is compared to Core Foundation, it's not really a contest.
John:
Oh, it's awful.
John:
They're just wrapping wrappers of wrappers because in the very bottom is just this terrible slime that no one wants to touch.
Casey:
It's true, but you still haven't answered my question.
Casey:
If you were to pick a language today, what would you pick?
John:
Do I get to pick Pearl 6, even though it doesn't really exist?
Marco:
That's kind of a cop-out, because you don't really know what's so bad about it yet.
John:
Well, I mean, I know what's so bad about the language.
John:
I just don't know what's so bad about the implementation.
John:
The language exists as a spec.
John:
It's just no one has implemented it.
John:
So, like, does it really exist?
John:
Right.
John:
That's kind of a question there.
John:
A half implementation or whatever.
John:
But, like, language-wise, I think Perl 6 is the most exciting language that sort of kind of almost exists.
John:
Yeah.
John:
I dislike Python more than I dislike Ruby.
John:
So I would probably have to go with Ruby.
John:
Ring endorsement.
John:
I really do dislike several things about Ruby pretty vehemently because I feel like they should have known better.
John:
But I dislike Python more and I definitely dislike JavaScript more.
John:
So I guess I would have to go with Ruby as much as it pains me to say that, as much as I am not a fan of Ruby really.
John:
And Python is just totally distasteful to me.
John:
And JavaScript is just too primitive.
Marco:
You know, nothing about Apple modernizing Objective-C and eventually adding this new syntax layer on top of it, if that's what their plan is, that doesn't preclude them from also modernizing the APIs along with that.
John:
Well, I mean, they would have to wrap them.
Marco:
Well, temporarily.
Marco:
But, you know, compare with the bridge.
Marco:
A bridge, when it wraps things...
Marco:
I agree with everything you said.
Marco:
A bridge sucks because you get these weird APIs that obviously are not written with that new language in mind.
Marco:
But that's because bridges are usually written by people who aren't the API platform owners.
Marco:
If Apple would make a new bridge, and the Java bridge was its own thing that was doomed, but if Apple decided this is the new thing, this new language layer rebuilt on top of Objective-C now, or that's backed by Objective-C that's now this whole different language layer on top, this is our new thing, this is the way forward, then within a few years they could have all their APIs modernized to it.
Marco:
Or at least all the ones people actually use on a regular basis.
John:
Yeah, or some of them.
John:
I mean, what you would hope is that... I guess you would hope that the bottom layers roll up eventually.
John:
Kind of like the assembly.
John:
Assembly has been basically completely rolled up.
John:
Original Mac operating system, tremendous amount of assembly.
John:
And the amount of assembly...
John:
in operation that anyone has to write or deal with or call or anything has just shrunk up to the point where now it's like in a couple device drivers in the kernel and some libraries for doing math, right?
John:
Like, that's it.
John:
Like, it's a low-end curls up, and it's just gone from the operation of the operating system, the things dealing with the GUI, you know, like... And you would hope that eventually...
John:
The C part of things starts to roll up too.
John:
Not the objective C part, but let's just start with the C part.
John:
Okay, well now the C is only in the kernel and in device drivers or whatever.
John:
And it used to be everywhere.
John:
Everything used to be C. If you count objective C as it... I would like to see...
John:
progress at the high end but also rolling up in the low end because if you're not if you don't do that all you're doing is making putting more layers on layer cake and that you know at a certain point like no matter what kind of performance you get this is a great article that someone should put in our non-existent show notes but at a certain point no matter what kind of performance you get from the hardware if you keep putting layers on the layer cake performance won't be your problem it'll be like latency did you read that article from uh john carmack talking about uh latency of vr headsets
Marco:
No, but that sounds good.
John:
It's like we have amazing technology with GPUs and we can do amazing texture fills and shader operations operating on millions and millions of pixels 15 times per frame and we can do these amazing frame rates and none of that matters because if you can't react to me turning my head within 20 milliseconds and get a new image in front of my eyes, it's motion sickness inducing.
John:
And so all this great technology we have actually impairs the ability, because there's so many layers in the layer cake of, like, this goes through this stack and goes through the USB thing and converted there and then goes through the input system and then goes through the OpenGL and out to the graphics card and comes back out and has to be displayed.
John:
Like, all the layers we've added to the layer cake for this amazing performance kills latency.
John:
Yeah.
John:
This is not a direct analogy because it's not like there's latency in the API stack, but it's the same idea that we can't just keep adding layers on a layer cake.
John:
You have to curl up the lower ones too.
John:
You have to pop ones off the bottom as you add ones to the top.
John:
So that's the kind of progress I'm looking for in my lifetime.
John:
If anyone's listening, get on that.
Marco:
I think they're doing that.
Marco:
We haven't really seen the next big step yet, but it looks like, based on the actions that we have seen, I think that's a plausible prediction of where they're actually heading.
John:
I mean, they're not going in the wrong direction.
John:
It's not like we're, you know, it's just like quibbling about the details, like, and the pace.
John:
You know, mobile set everything back, you know, a decade or two.
John:
So, fine.
John:
I understand that, you know, it makes perfect sense, right?
John:
But, like, you know, I would like to see...
John:
There's more advancement in the high end and more curling up in the low end.
John:
It's just like the road they're taking to it is perhaps more circuitous and slower than I would like, especially when I see things like CLR existing for such a long time.
John:
And it's like the technology was there.
John:
And, you know, yeah, your entire stack is still better than Microsoft's now.
John:
But like...
John:
My whole thing with this is it's not something you can do overnight.
John:
And if you're going to try to do incrementally in pieces, I think you will end up running into a barrier where there has to be discontinuity somewhere.
John:
And if there isn't, you're going to end up with a sort of mongrel at the end of it, like HFS+, where you just took this old thing and slowly modified it a bit at a time, but never sat down to say, okay, what is this new thing that we want?
John:
You know what I mean?
John:
It's like if iOS was just an incremental revision of slowly adding mobile-savvy features to macOS 10.
John:
It wasn't.
John:
They...
John:
They start over conceptually from the UI perspective, right?
John:
I'm a fan of that kind of clean break, and I worry that slowly creeping up on Objective-C without the C will result in a language that no one can really love.
John:
And maybe that won't ever hurt Apple because, like we said, it's not a big deal as long as you're doing great in the market and everything, but that's what appeals to me.
John:
So I think it's like a philosophical difference, and obviously I'm probably more idealistic than...
John:
not being the person whose job it is to make this decision for the biggest company in the world or whatever.
Marco:
And you could also question, I think it's worth considering, is it too late to do something like that?
Marco:
Are these systems so complex?
Marco:
Are these devices and APIs so feature-rich and so mature?
Marco:
Would it be too big of an undertaking for them to do this now?
John:
It's never too late.
John:
Never too late.
John:
I mean, if anything, I would say, when is the time that you should be thinking about this?
John:
It's when you're, like, at the height of your power.
John:
Because if you try to do it, like, on your way down, like, Palm is like, wait a second.
John:
Did you know our OS sucks?
John:
We should make an all-new one.
John:
Like, too little, too late.
John:
Like, rim.
John:
Rim, rim, you know, you know what I mean?
John:
Like, you gotta, you know.
John:
So, whatever their plan is, like, they have a plan.
John:
Like, if it takes them longer and they do it in a smaller series of steps or whatever, but, like, you know, that...
John:
Either the company will go out of business or the day will come when they need to have this better, higher level thing.
John:
And they will have arrived at it through a series of small steps and perhaps ended up at a destination that's not quite as pretty as if they had made a larger discontinuous jump.
John:
But, you know, it's out there, I think.
Casey:
And I think the only thing I wonder is perhaps we should pay a little more attention to any mentions of LLVM and Clang at WWDC.
Casey:
Because it seems to me if they were going to sneak in a new language or a new framework or something like that, I would suppose that we would see traces of that there first.
Casey:
Like ARK, I believe, was...
Casey:
if I'm not mistaken, was a build off of the static analysis that was in one of the two of these guys.
Casey:
And I'm opening up a whole new can of worms that I don't want to open, but I'm just curious to see what LLVM and Clang are doing lately and what will be announced that relates to that.
John:
Well, that's why I'm thinking of type inference because it's like a natural progression of what they're doing.
John:
They pretty much almost have the metadata in there for it.
John:
Static analysis combined with the knowledge required to make ARC work
John:
makes it seem like they could do some reasonable... Maybe it's not enough bang for the buck for them yet.
John:
Maybe they say, okay, yeah, well, we could do type inference, but it's not such a big win to be worth the confusion, so we're just going to bail on it.
John:
But assuming they actually think it's worthwhile, it's an obvious next step of things they can do to make it so you have to type less crap, but you're not really changing the language.
John:
It's like the fast enumeration crap.
John:
It's not a change in language, really.
John:
It's just like, oh, you don't have to type too much stuff.
John:
Also, now you can do auto or var or whatever the hell word they use to indicate...
John:
Look, don't mind me.
John:
You know what type it's going to be.
John:
It's clear from the code.
Marco:
And also, I think the pace of those improvements has increased dramatically in the last few years.
John:
Yeah, once they got totally free of GCC.
Marco:
Right.
Marco:
Now we're seeing this explode.
Marco:
This past year, they added all those little shortcuts and so many little benefits just in one year.
John:
And the year before, they added more stuff.
John:
They still have C++11 kind of weighing them down.
John:
Like, they got out from under GCC, but they still need to do a lot more to, like, fully support the monster language that is C++.
John:
So, like, that probably still absorbs a lot of their time.
John:
Like, finally nailing down all the little crazy-ass idiosyncrasies of C++.
Marco:
Is that even possible?
John:
I mean, like, the point is that GCC... I don't know, maybe not GCC as much, but, like...
John:
C++ compilers that have been compiling production C++ for a long time are still ahead of where Clang C++ support was as of a year or two ago.
John:
Maybe they've closed the gap now.
John:
But it's a lot of work, and it's kind of annoying work because Apple barely uses C++ compared to how much Microsoft uses it, for example.
John:
And so it's like, oh, well, we've got to make our stupid compiler support.
John:
We don't care about this language, really.
John:
We have enough support for our stuff.
John:
And it's like, all right.
John:
Because if you want Clang to be a popular widespread compiler,
John:
you have to make it support C++, even if Apple doesn't use it that much.
John:
And that means all the stupid esoteric features, because if you can't build important stupid projects, if you can't build Boost or whatever, they don't have that problem now, but they did early on.
John:
And if you can't support the new C++11 lambdas and all this other crap, that's still in the background, the catch-up stuff that they have to do before they can totally fly free, you know?
Marco:
Is C++ Ox still a thing?
Marco:
What happened with that?
John:
That's what we came to C++11, didn't it?
Marco:
I don't know.
John:
I don't follow the C++ world at all.
John:
Yeah, neither do I. I try not to, but it leaks into my worldview occasionally.
Casey:
And we're done.