goto fail;
Casey:
All right, do you want to do some follow-up?
Casey:
Okay, sounds great.
John:
There's hardly any.
John:
Is there any today?
Casey:
Kind of.
Casey:
Not really.
Casey:
Yeah, I'm lumping something that probably isn't by the strictest definition follow-up into follow-up.
Casey:
And that is after our discussion about what comes after Objective-C, a lot of people have come out of the woodwork and said, hey, guys, have you seen this Wolfram language thing?
Casey:
That's going to be the next big thing.
Casey:
That will replace Objective-C.
Casey:
And it's not.
Casey:
So anything else?
Casey:
It is pretty cool, though.
Casey:
Oh, it's cool as hell.
Marco:
I have no idea what I would use it for, if anything.
Marco:
I think I'm not smart enough to use it, actually, but it's really cool.
Casey:
I mean, all kidding aside, it is very, very cool, but it's serving a completely different purpose.
Casey:
And I don't see a mechanism by which that's going to be the way in which we build apps.
Casey:
And of course, somebody will say to us, oh, well, but didn't you watch the whole video?
Casey:
They had sliders on there and other UI elements and blah, blah, blah.
Casey:
Yeah, but that's not really the point.
Casey:
It's not the sort of thing you'd build an app with.
Casey:
It's the sort of thing that you would do some really impressive and very cool data computations with, but it's not something you'd build an app with.
John:
Did either one of you guys have to use Mathematica in school?
Casey:
I did, and I've long since forgotten all of it.
Casey:
No, I used MATLAB.
Casey:
I'm sorry.
John:
Mathematica, what's his name, Stephen Wolfram?
John:
Yep.
John:
Mathematica is to him as Emacs is to Stallman, basically.
John:
He's a super genius, crazy person who made an environment where he can sort of fulfill his dreams of computation and has just added to it and added to it over the years.
John:
Only Wolfram is a little bit more successful and a little bit more determined by
John:
uh and not quite as afflicted with rsi and i think hired a bunch of other people to do things i think the difference is that wolfram had a business that made money that let him indulge his uh his tastes to do this type of thing so he's built this amazing thing for himself that works the way his mind works that is basically like start with mathematica and just expand out to fill the universe but
John:
I'm not going to say something about it that's like, oh, it's just a, and insert word here, because it's not just a anything.
John:
What it does is very impressive, and it's a life's work, and it is very interesting and impressive, but I think it's an application.
John:
Exactly.
John:
It's an application that you can program with more than a programming language.
John:
But anyway, regardless of what you think it can apply to,
John:
Everything in that demo shows that it's good at doing the stuff in that demo.
John:
But Apple, of course, would need a language that's good at doing the things that Apple needs to do.
John:
And what does Apple need to do?
John:
They need to let developers write applications.
John:
They need to write applications themselves, and they need to write an OS.
John:
And for all of those purposes, this language is not useful.
Casey:
Right.
Casey:
And don't let me kind of shrugging it off as a replacement for Objective-C to take away from the fact that you're absolutely right.
Casey:
It is unbelievably impressive, the things that can be done with it, but it is serving an entirely different purpose.
Casey:
And that's the only point I'm trying to make.
Marco:
Yeah, like I'm not going to be writing the next, you know, Instapaper killer in Wolfram language.
John:
Yeah, and one of the aspects that it has going against it is that thus far computer languages that lean heavily on, like in the sort of cloud of what are you closer to, that sort of start grouping towards the math side of things.
John:
while always very interesting and powerful tend not to so thus far i mean it doesn't mean it can never happen but so far the ones that tend to be more math like have not caught on as much as the ones that are less math like and you know i don't know why that is but i mean for example haskell is another one of those languages that looks more like you're doing math or is more math like or even something like lisp kind of sort of uh
John:
And this definitely is towards the math side.
John:
I mean, you can solve integrals with it as part of like language features, all the symbolic stuff.
John:
I mean, it started from Mathematica.
John:
How could it not be math based?
John:
But yeah, so far, languages like that haven't caught on with the masses, no matter how cool they are for the people who use them for the things they're good at.
Marco:
One problem I think I'd have trying to use this for anything is that, kind of similar in this only one way to AppleScript, I think it would be hard for me to start into this and to even know the kinds of things I could do.
Marco:
And, you know, because it can do so much, and in that way, it's pretty unfocused.
Marco:
It's very broad, and you're presented with, like, here's this shell, basically, this command shell, and this interactive prompt that you can do whatever you want with.
Marco:
And, like, the demos that he was showing off in the video look amazingly cool.
Marco:
I don't know necessarily how useful they would be for me, but they were still amazingly cool.
Marco:
Yeah.
Marco:
But I was looking at the kinds of syntax he was using, the kinds of commands he was using, the kind of structures he was using, and I don't even know where I would begin with something like that.
Marco:
And I've had that same problem ever using Wolfram Alpha as well, where every time I've tried to use Wolfram Alpha, I've tried...
Marco:
phrasing things in a certain way, and I never guess the correct syntax, and it never does what I want.
Marco:
I can tell there's a lot there, but it's really hard to get started.
Marco:
It's really hard to know, like, okay, what can I do here, and how do I ask it to do that?
John:
I think like Lisp, I think the language itself is probably super simple.
John:
I think there's only a few things that exist.
John:
You know, they probably have like tuples and some syntax for function calls and a couple other symbolic things to write math and ASCII that get converted into symbol representations.
John:
That is the language, but the language is pointless.
John:
Like if you looked at that big, they kept paging through those
John:
page after page, those little rectangles underneath each one of those is a vocabulary, which is basically like a library, you know, like what, what functions can I call?
John:
What things can I type?
John:
That's not part of the language per se.
John:
It's not as if those are keywords like if, and you know, uh, loops and, and function declarations like, uh,
John:
The language syntactically looked very simple to its discredit, I think, in that it looks like it would be very cumbersome to do anything remotely complicated.
John:
But the power of the thing is look at all these basically libraries that we have.
John:
Look at all the different functions we have.
John:
Look at what the options to those functions are.
John:
Look at how those functions can be composed with each other.
John:
And so it's kind of weird to call it a language.
John:
That's why, you know.
John:
It's more like an application or a set of libraries.
John:
And the set of libraries look huge.
John:
Surely there's some function that does the thing that you want, that has the options that you want.
John:
And if you can't find it exactly, you can build it by composing it out of other really powerful pieces and put it all on a web front end and get it through a web services API.
John:
Lots of cool stuff in there.
John:
But I think it's more like an application.
John:
It's more like an API than it is a language.
John:
Yeah.
John:
Whatever it is, it's not suited to write GUI applications or operating systems for phones or desktops.
Casey:
Right.
Casey:
I've had the same thought, that this would be a potentially extremely powerful add-on or processing, not unit, but I guess like a dynamic library for something in Objective-C if you could get some sort of interface into it.
Casey:
But I don't see it replacing Objective-C or anything like that.
Casey:
Very cool, though.
Casey:
Very, very cool.
Casey:
So what else is going on?
Casey:
You want to talk about this SSL bug?
Casey:
Go to fail.
Casey:
All right.
Casey:
So moving on.
Casey:
No, I'm just kidding.
John:
It was like meme ready.
John:
It came pre-memed.
Marco:
I love that gotofail.com was actually available.
Marco:
Not for long, but yeah.
Casey:
And it was useful once it became a thing.
Casey:
I don't know if I have all that much to say about this.
Casey:
I'm not sure I concur, Marco, with your tinfoil hat reasoning that this was a deliberate act.
Casey:
And I'm happy for you to convince me that I am wrong.
Casey:
But I'm not saying it wasn't deliberate.
Casey:
But to me, it didn't reek of being deliberate like you seem to think.
Casey:
Do you want to kind of recap what leads you to believe that?
Marco:
Sure.
Marco:
I mean, I think – I'm not saying this was definitely an NSA security breach where – my theory that I think is potential.
Marco:
I don't even know if I would say the most likely, but –
Marco:
I think it's reasonable to look at these events that this one duplicated line was inserted into this SSL.
Marco:
It was a certificate verification code or a common name checking part, wasn't it?
John:
It was the step that checks that the common names match and it skips over that step.
Marco:
I believe so.
Marco:
It was some part of the certificate verification step, so that you could make sure that the SSL server that you're talking to is who they say they are, and not a man-in-the-middle who... Man-in-the-middle attacks... I'm probably not even qualified to explain everything properly, but...
Marco:
Somebody who could, like, intercept your network traffic at an ISP or a wireless router in a coffee shop or whatever the case may be, your school, your workplace.
Marco:
Somebody who could intercept your government.
Marco:
Somebody who could intercept your network traffic.
Marco:
Normally, SSL is designed, if everything's done right, so that the server and you can talk securely and you know when you connect to the server, you can verify through these series of cryptography steps, you can verify that the server you're talking to really is who they say they are and nobody else in the middle is listening in in a way that they can decode your data.
Marco:
this bug broke that assumption.
Marco:
And so that somebody could have been listening in and breaking SSL and watching your traffic and the operating system was just skipping that verification step or a part of it.
Marco:
So the way this was inserted in the file...
Marco:
And the files are open source.
Marco:
Not every revision is open source.
Marco:
But you can see the version that shipped in 10.8 and the version that shipped in 10.9.
Marco:
And you can see the diff there.
Marco:
So the diff is not entirely convincing because there could have been a lot of intermediate revisions between.
Marco:
You don't know what happened between those two.
Marco:
All you see is beginning point and ending point.
Marco:
But if you look at the diff, not a lot in the file has changed between the two releases.
Marco:
There's this context parameter to some of these security calls that was removed, basically.
Marco:
It looks like the API just changed minorly so that this one argument was no longer necessary or something like that.
Marco:
Some of the calls had this very basic change to them that just removed this argument.
Marco:
There were almost no other changes in the entire function.
Marco:
And then this one extra go-to-fail line inserted in the middle.
Marco:
And so if you look at this, if you just look at the diff, it looks pretty bad.
Marco:
It looks like, wow, no edits happened in the surrounding lines between these two releases.
Marco:
Just this one line was inserted kind of in the middle of nowhere.
Marco:
And it looks pretty bad.
Marco:
Of course, as I said, though, you can't rely only on that.
Marco:
I think what...
Marco:
What worries me and what makes me think that this could have been nefarious – and again, and I want to say to my tweets, I don't necessarily believe that Apple itself officially knew about this or introduced this intentionally or was working with the NSA.
Marco:
I think it's much more likely seeing how the NSA works, knowing that they have a program where they – New York Times reported this.
Marco:
I'll have to find the link, but –
Marco:
I believe it said they had an annual budget of $250 million to go do things exactly like this, where basically the NSA will get to an engineer who works at one of the big tech companies, or they'll have people sitting on standards bodies trying to argue for different standards to be –
Marco:
subtly weakened or have these backdoors introduced, or the people who work at tech companies will become NSA supporters, agents, whatever they're called.
Marco:
So we know that that kind of thing happens.
Marco:
We know all of that from the Edward Snowden leaks and from the associated reporting that's gone on since then.
Marco:
All of that, that's not like an artificial tinfoil hat thing.
Marco:
That kind of thing does happen.
Marco:
And so for this bug to be inserted...
Marco:
At this time, and again, another little piece of circumstantial evidence, this bug was inserted in, I believe it was fall of 2012.
Marco:
It was the month before one of the NSA slide decks claimed that Apple had joined the PRISM program in some way.
Marco:
And that timing is really suspect as well.
Marco:
So you can look at this, and we don't know yet at least.
Marco:
We don't know what happened.
Marco:
We probably will never know what happened.
Marco:
It could have been an innocent mistake, an innocent line paste out of a VI buffer or a weird merge artifact when the files were merged.
Marco:
Who knows, right?
Marco:
We can't tell exactly, but...
Marco:
Normally, when you try to rule out a kind of nefarious tinfoil hat conspiracy theory kind of thing, you do it by saying, well, the simpler, more likely explanation is honest reason X. And I think in this case, looking at the environment we're in, looking at the kinds of things that we now know go on with the NSA and what they do with tech companies, and you look at exactly, I mean, for a one-line bug like this, this is a hell of a line to pick.
Marco:
What it did, in the way it did it, it was so subtle.
Marco:
It was subtle enough.
Marco:
If you think about it, it's perfect.
Marco:
It's subtle enough that...
Marco:
it would, it passed a lot of any kind of internal review they had.
Marco:
And we can talk about that.
Marco:
They probably had insufficient review and insufficient tests, but any kind of internal review, it would, it might, it might skip by because it looks, it's, it blends in.
Marco:
It's not obvious.
Marco:
It's not even obvious that it is a bug.
Marco:
Once you even, once you spot it, you kind of have to notice and be like, Oh, wait a minute.
Marco:
Like you have to think about it for a second.
Marco:
Oh, that's, that's wrong.
Marco:
And yeah,
Marco:
it could be explained away if somebody was caught inserting it.
Marco:
It can be explained away by saying, oh, I must have hit paste wrong or merged wrong.
Marco:
So there's like a plausible explanation if you get caught.
Marco:
And it's exactly at the right point where it wasn't breaking all SSL.
Marco:
It wasn't making all SSL validate, but it was making this one particular class of thing validate that the NSA has been known to do.
Marco:
So...
Marco:
It's just a little too convenient in so many of these ways.
Marco:
The timing, the kind of thing it is, the perfection of exactly the right part of the file to cause a very convenient backdoor for the NSA...
Marco:
And in a way that looks really subtle and hard to find and hard to attribute blame for once you do find it.
Marco:
I'm sure they can look at their version history and they can see which employee inserted that.
Marco:
But again, there's like a plausible reasoning.
Marco:
Oh, it must have been a mistake during the merge or something like that.
Marco:
So it's just a little too convenient.
Marco:
to be a dumb, honest mistake, given the context, given the time it happened, what it did, the results it had, and what we now know about what our government does.
Marco:
So that's why I think, again, I wouldn't say that it's definitely the NSA, but I would say it would be naive to brush it off and say, oh, it probably wasn't them.
Marco:
I think the chances are better than that, that it was them.
Casey:
You know, I can't really argue with any of that.
Casey:
And I don't know.
Casey:
I just I guess I just want to believe that people aren't jerks like that and that our government doesn't do things like that.
Casey:
But to be honest, that's me to keep my head in the sand.
Casey:
So, I don't know, John, what do you think about all of it?
John:
For the timing thing, I think that's just as reasonably explained by saying the NSA knew that this bug was in there, and joining the program basically means the NSA now has the capability to intercept traffic to Apple devices because of this bug that it knows about.
John:
And how would it know about the bug?
John:
Well, through its own testing.
John:
Uh, through trying to do man in the middle attacks, perhaps having someone working at Apple who looks at the code before it's released to tell them that this is in there.
John:
So that would explain the timing and that doesn't require the NSA to have caused the bug to be entered in any way.
John:
Uh, so I, the timing I think is a wash, uh, for if I had to put money on it, I would bet that it's a merge error and it was accidental.
John:
Uh,
John:
Um, and that doesn't mean the NSA wasn't exploiting it to do what they do because it seems like they knew about it based on the timing.
John:
And if they knew about it, I'm sure they would be exploiting it.
John:
The reason I think it's a merger is because I don't think it's all that subtle.
John:
I think if they were going, if the NSA were going to intentionally plant something like this, they would do it in a less discoverable way because once it's discovered, it gets patched.
John:
And the NSA's goal is not to be discovered.
Uh,
John:
This is not a, you know, it's if you glance at it, you might miss it, you know, casually visually inspecting it, but it's a type of thing that will be found both in terms of the code and in terms of the massive effect it has like you, if they planted one, you would hope they would plant one.
John:
that isn't so easy to find because this is like, I can spoof a certificate and it just accepts everything.
John:
Like it accepts any garbage.
John:
It skips that entire, it's not like if I carefully construct a certificate with a particular thing or like, you know, like it's not exploiting a subtlety.
John:
It's the type of thing.
John:
It's amazing that it went undiscovered for as long as it did because of apparent Apple's apparent total lack of testing of their security frameworks.
John:
Uh, so that I think argues against it being intentional and, uh,
John:
The thing about plausible deniability, this is the really creepy part, is that I can imagine that Apple has automated merge tools for bringing builds together.
John:
So if you were to find the commit that did this, I would imagine there's a good chance that it could be attributable to an automated merge tool.
John:
And then who do you blame, right?
John:
Like, oh, well, someone was really clever and set up these series of dominoes such that they knew when we did this merge with that merge and that merge, it would mess something up.
John:
And...
John:
If the only validation of a merge is a human being visually inspecting it and signing off, well, yes, that's easy enough to miss.
John:
Or if the validation of a merge is it compiles and passes our apparently completely inadequate test suite, then that would let it go through too.
John:
So...
John:
I think we all agree that it is entirely possible that the NSA did this and the government did this because, like Marco said, this is something they do.
John:
But I think this is below the level of competence and sneakiness that I would expect from them.
John:
So I give it a less than 50% chance that it was done intentionally, more than 50% chance that it was done unintentionally, and almost 100% chance that the NSA both knew about it and exploited it.
Marco:
Overall, I agree, John.
Marco:
I agree that all of these factors could be explained away in reasonable, plausible explanations.
Marco:
It's just like when you add it all together, and again, if this would have happened a year ago before we knew so much from the Snowden leaks, before we knew all this stuff, a year ago I would have looked at this and thought, oh, it looks like somebody made a stupid mistake.
Marco:
But now that we know that this stuff happens, and because of how convenient it would be, yeah, you're right that disabling these entire steps of SSL verification are pretty ham-fisted.
Marco:
However, they got it through, and it was there for over a year, right?
Marco:
So I think...
Marco:
I'm sure they don't just try one thing.
Marco:
And maybe the other things they tried got caught or didn't ship.
Marco:
Or are still there.
Marco:
Yes.
Marco:
Thanks.
Marco:
Sleep well tonight.
Marco:
Or are still there.
Marco:
And I'm sure they don't just leave themselves as one option.
Marco:
Again, I think by looking at just the fairly broad stroke that this bug used...
Marco:
For the same reason that you wouldn't rule out the timing.
Marco:
I wouldn't rule out the possibility of them doing this just because of how fairly ham-fisted it is.
Marco:
Because in many other ways, it's quite elegant in how innocent it looks and how hard it was to catch.
Marco:
Yeah.
Marco:
And, you know, I'm sure they try many things, and some of them are ham-fisted, and some of them are really clever.
Marco:
And the really clever ones, maybe they didn't work, and maybe they're still there, but this one we happen to find.
John:
Well, none of us are ruling anything.
John:
I was just like, you're over 50% for thinking it was intentional, and I'm under.
John:
But that's basically it.
John:
We're all around the middle, you know.
Marco:
Yeah, and again, I'm not too far over 50%.
Marco:
I might say 60%, but normally conspiracy theories, you've got to be like, well, there's just too many coincidences to believe your conspiracy theory.
Marco:
Too many coincidences would have to happen.
Marco:
This, I think it's subtly the other direction.
Marco:
You'd have to ignore a lot of coincidences that are the case to believe that this was totally innocent.
John:
so do you think apple will ever say anything publicly about the investigation that undoubtedly is taking place inside the company to determine the cause of this oh i really doubt that and the second question is will they use their disclosure canary thing you know like where they the previous disclosure they said we have not been contacted by government agencies to blah blah blah blah blah and i figure what the word for that is someone in the chat room will look it up but uh
John:
They put that in there so they can, so that when you see that message disappear, you will know that they have been contacted by the government and told not to say anything about it.
John:
So that's, I guess, the thing we can actually watch for that's actionable.
John:
The next time they do one of those security disclosure statements, if the whatever canary statement is not there, again, we can't directly connect it to this incident, but at least, you know, for example, if we see the statement again, we'll know that Apple investigated it internally, and
John:
That they like I don't see if it was the government and they and they haven't been forced by the government not to disclose it was the government.
John:
I don't see why they wouldn't make that public because they would basically be saying, hey, in essence, you know, our government hacked us.
John:
You know, they'd be angry.
John:
They'd talk to Congress about it, all this type of stuff like that.
John:
If that if they determine that to be the case.
John:
But if it was just an internal error.
John:
They probably won't say anything.
John:
And if the little canary statement is still there, then we also know that the NSA is not the one making them not say anything.
Casey:
See, but I thought that the canary statement was more about getting at user data.
Casey:
I thought that the canary statement was something about how we haven't received any requests from the NSA to do crap we didn't want to do.
John:
I know, but this would be a request to sit to – you're not allowed to say anything about the NSA mole that you discovered in your organization.
Yeah.
John:
You're right.
John:
It's different categories.
John:
We've never given them user data and blah, blah, blah.
John:
It was a fairly wide-ranging statement.
John:
They can't anticipate what they may be forced not to say anything about, but I would imagine they would remove that.
John:
They would just simply not put that statement in there because it's not an admission of anything.
John:
That's the whole point of the canary.
John:
You can just remove it, and that's their signal to the outside world that
John:
Government people have come and told us not to say anything, and we can legally just simply not say anything, and you can interpret that as a sign that we're being told not to say something about something.
John:
Yeah, maybe, but it is two different things.
Casey:
Yeah, it says – I have it here.
Casey:
The very last line – this is a thing from Matthew Panzarino.
Casey:
The very last line of Apple's report today states, quote, Apple has never received an order under Section 215 of the USA Patriot Act.
Casey:
We would expect to challenge such an order if served on us.
Casey:
Which to me sounds like something separate than what we're talking about.
John:
Well, I mean you'd have to look up what Section 215 of the Patriot Act says.
John:
Knowing the Patriot Act, it probably says the government can do whatever the hell it wants and you have no rights.
John:
Oh, you're right.
John:
In some sort of vague language that's brought.
John:
But I mean that's all we've got because they can't go back in time and put in a canary about we've never been infiltrated by the NSA.
John:
They've never added bugs to our code intentionally.
John:
And honestly, I don't know how they would ever determine that.
John:
Because like Marco said, if the best case scenario that it actually is an individual developer, what are they going to do?
John:
Waterboard the guy?
John:
It could have been a legitimate mistake.
John:
They can ask him, did you put that there intentionally?
John:
But if he did it intentionally, of course he's not going to tell you that he did.
John:
And you can't force him to tell you.
John:
And you'll just never know because it is 100% plausible as a bug.
John:
People write bugs all the time, right?
John:
It just, you know...
John:
lines get pasted twice like marco said like there is no literally no way to force someone to to like you'll never know if that guy's telling truth you could torture him to death and he dies and he never said that he did it and you still don't know whether he was lying or not
Casey:
Let me tell you a story, and then maybe, Mark, you can tell us about something sweet.
Casey:
In my first job, I wrote bingo-based slot machines, which is a weird and odd story that's not worth explaining right now.
Casey:
But this was done in DOS using the Whatcom C++ compiler.
Casey:
And because it was done in DOS, debugging, in the traditional sense, wasn't really a thing.
Casey:
So you basically had to print out a bunch of log statements and so on and so forth.
Casey:
Well, the machines that we built and the software that we built, basically it had a menu and then a series of different slot machine games.
Casey:
And what we were noticing all of a sudden is that after some arbitrary amount of time of going into a game and going to the menu, going to the game, going to the menu, going to the game, going to the
Casey:
After like 30, 40, 50 times, all of a sudden we would get a hard crash.
Casey:
And we couldn't figure out what it was.
Casey:
And we had some really, really good C++ developers there.
Casey:
The team at that point was only like 20 people.
Casey:
But there were some really smart guys there.
Casey:
Now, I'm straight out of college, so I don't know what the crap I'm doing.
Casey:
But after a while, it was on me to try to figure out, and a co-worker actually, to try to figure out
Casey:
Where is this crash coming from?
Casey:
Why is it happening?
Casey:
And some of my much more experienced, much better co-workers had looked through diffs.
Casey:
They'd looked through check-ins.
Casey:
Nobody could figure out what it was.
Casey:
And eventually I figured it out.
Casey:
And I can't recall if I just spotted it or if I looked through the version history of all the files that had been changed lately.
Casey:
But what it ended up being was a fall through in a switch statement.
Casey:
And in the switch statement, in each case, we were instantiating an object that was fairly big.
Casey:
I forget exactly what it was, but it was big.
Casey:
So what that means is we would create this new object and allocate a bunch of memory for it.
Casey:
And then there was an accidental fall through that we didn't mean to have.
Casey:
And so we would create another one.
Casey:
And that first object, all that memory got leaked.
Casey:
And it took us forever to find it.
Casey:
It took seriously, I believe it was two weeks of myself and a coworker just digging through code for two straight weeks, trying to figure out what it was.
Casey:
And I bring this up because it looked, aesthetically, it looked very similar to this go to fail issue.
Casey:
There was what appeared on the surface to be a perfectly valid switch statement.
Casey:
And it just so happened that we had forgotten to put the word break with a semicolon after it.
Casey:
We were leaking memory.
Casey:
And after 30 to 50 times going back out to the menu, that's what caused the error.
John:
If you had instruments, you would have known that.
John:
Because you could have run the little graph that shows the memory.
John:
You would have seen the leak.
Casey:
You're absolutely right.
Casey:
I know you're slightly being snarky, but that is absolutely true.
Casey:
And that's part of the reason why I think none of us are necessarily that excited to get rid of Objective-C.
Casey:
But I bring this up because here was a situation where we had a handful of really good C++ developers.
Casey:
Now, we didn't have a lot of process processing.
Casey:
You could say our methodology was not very good.
Casey:
But regardless, we didn't have a lot of process.
Casey:
But nevertheless, we had some really bright guys and girls going through this stuff, and nobody could find it because it wasn't something that was visually, almost aesthetically obvious.
Casey:
And I see this as being a very, very, very similar situation.
Casey:
Just food for thought.
John:
There's examples of language misfeatures that lead to bugs.
John:
The language misfeature you cited is the fall through where you need the break statement.
John:
The language misfeature I think in this bug was that you can have single clause conditionals without the braces that make it slightly less obvious.
John:
And some people say the language misfeature is that white space is insignificant and the Python people will tell you how this will never happen in Python.
John:
I mean, all the talk about whether this is intentional or not,
John:
Like, bugs happen all the time that aren't securely related.
John:
They're just plain bugs and cause things to crash.
John:
And language features do lead to more or fewer bugs.
John:
And I don't... I would love to see some stats on, like...
John:
Bugs that are attributable to human error that could potentially have been influenced by language features.
John:
So the single clause if thing, I bet, is probably pretty high up in any language that allows that type of thing.
John:
Because it's just so easy to accidentally put a line underneath it or to indent things wrong in a misleading way.
John:
the break and the fall through for case statements with forgetting the break i mean i can't count how many times i've done that i like it i do it you know usually it's so obvious because there's nothing works at all but if you get unlucky enough and things happen to sort of appear to work uh you won't notice it because you just write it out and it looks it's all indented the way you want it to be and you just forgot to put the word and who doesn't forget to put the word that's like a rite of passage when you learn the scene you learn the case statement you will forget to put in break and you know your thing won't work right
Marco:
Man, I found a nasty bug this week in my PHP framework.
Marco:
In my sort function... So I have my model class, and I have a couple of convenient model sort functions to do common things.
Marco:
And one of them is if you have your array... And PHP arrays are all hashes slash dictionaries.
Marco:
It's all arbitrary key to value.
Marco:
It can be strings or numbers.
Marco:
Okay.
Marco:
So the idea is if you have an array of numerically indexed models and you want them to instead be indexed by one of the values on each one, like say go id to object instead of just like 0 through n, I had a function to assign the key of each object to be that property that you specify.
Marco:
And I had it work on the array in place.
Marco:
Oops.
John:
See the problem?
John:
Does PHP have defined semantics for what constructs allow you to modify the thing you're iterating over in place, and which ones don't?
Marco:
Not really.
Marco:
PHP, you can generally modify things as you iterate over them most of the time, and it usually works.
John:
Reassuring.
Marco:
It's kind of a problem that I have to say most of the time and usually there.
Marco:
But, yeah, so as a result, I was, as I was going through, you know, going through the numeric indexes, and I would say, all right, well, I have this property value of this one.
Marco:
So unset the numeric index that it was at and set it to the string index.
Marco:
Cool.
Marco:
So what happens when the value of one of those things is, like, what happens at the value of the one that was previously at ID zero is two, right?
Marco:
Then you go to ID1, do that, go to ID2, and then that one gets unset.
Marco:
And so the resulting array can clobber certain elements based on their value and can actually have fewer elements in it than the input array.
John:
What I was getting at was, say you pulled off the first one and its ID value was 77, and you shoved it into 77, would you later on find yourself iterating over 77?
John:
Because the iteration thing now sees a new entry down at 77.
John:
Yeah.
John:
I think so, but the fact that I don't even know that for sure is a problem.
John:
Self-modifying code.
John:
You could, in theory, get yourself into an infinite loop where these things keep getting shoved to the end and making new entries that you then iterate over that cause them to be shoved to the end again.
John:
Yeah, it's crazy.
Marco:
That was an obvious... If you looked at the code, it looked reasonable.
Marco:
Until you thought about it and you're like, oh, wait a minute.
Marco:
This was a utility function in my framework that's been there for about seven years.
Marco:
And so like, hmm, I wonder how many bugs that has caused because I don't use this function a lot.
Marco:
But when I do use it and maybe all the time I've used it so far, like most of the time, it just never it never had that situation.
Marco:
So I didn't notice it.
Marco:
But yeah, that was a problem.
Marco:
Anyway, we are sponsored this week.
Marco:
Our first sponsor, 30 minutes in, our first sponsor is Picture Life.
Marco:
Now, we talked a while back, many times, about hosting your pictures online, photo storage, photo backups, stuff like that.
Marco:
So Picture Life is the one app you need for your photos and videos.
Marco:
Starting with seamless backup and deep integrations into iPhoto and Aperture, Picture Life auto-organizes your photos and gives you the power to view and quickly search through them on any device.
Marco:
Picture Life's private sharing lets you easily control who sees which photos and their editor works on the web and iOS.
Marco:
Plans start at just $5 per month and ATP listeners get 30% off for life.
Marco:
Sign up at picturelife.com slash ATP.
Marco:
They've never done this before so really give this a shot.
Marco:
Make them love their sponsorship with us.
Marco:
You save 30% on the monthly fee for life.
Marco:
That's awesome.
Marco:
And so they have all sorts of cool features.
Marco:
They have a deep search.
Marco:
It's very, very powerful.
Marco:
It uses the face detection, all that other stuff that's really cool these days.
Marco:
They have apps for the Mac, apps for iOS, but they also even support Windows and Android.
Marco:
Android just launched in December and is very quickly coming up to speed.
Marco:
And, you know, this company was founded by people who really love photos.
Marco:
They love creativity and they love technology.
Marco:
Founders of this include Charles Foreman, who I actually know.
Marco:
Charles Foreman of OMG Pop, Jacob DeHart of Threadless, and Nate Westheimer of the New York Tech Meetup.
Marco:
I know him too.
Marco:
Yeah.
Marco:
And this is backed by our VC friends at Spark Capital, and I know them too.
Marco:
They were the main VC behind Tumblr.
Marco:
So I'm very familiar with all these people.
Marco:
They're really good people.
Marco:
Anyway, Picture Life is the one app that your photos really needs.
Marco:
So you can back up, search, edit, and share on Mac and iOS.
Marco:
Go to picturelife.com slash ATP, and you can get 30% off for life.
Marco:
Thanks a lot to Picture Life for sponsoring our show.
John:
And if you don't want them to go away like Everpix, sign up.
John:
And unlike Everpix, they don't have an unlimited storage thing.
John:
So hopefully they'll have a more viable business model of where you actually pay for what you use.
Marco:
Yeah, it seems that way.
Marco:
Also, Charles Forman, that guy is a machine.
Marco:
You remember Draw Something?
Marco:
That was the big thing?
Marco:
That was their big thing.
Marco:
But he had a site before that that I socialized with him a bit while he was working on that through David Karp at Tumblr.
Marco:
We would go out to dinner a few times here and there.
Marco:
And that guy, he's incredibly smart.
Marco:
And he's just like a coding output machine.
Marco:
I've rarely seen anybody be able to produce as much as he does.
Marco:
And he really, really knows his stuff.
Marco:
So I would certainly trust this.
Casey:
Nice.
Casey:
Now, to go back from before the sponsor break, it would be wrong of me not to mention that in Objective-C – no, I'm sorry, not Objective-C.
Casey:
I've been writing Objective-C today, which is why I'm all confused.
Casey:
In C Sharp, there are interesting language features that prevent both of the bugs that Marco and I are talking about.
Casey:
Firstly, you can't have a fall-through in a case in a switch statement unless that case is completely empty.
Casey:
So you would literally have one line, case one, colon, the next line, case two, colon.
Casey:
And if there's anything in between without a break statement, it's a compiler error.
Casey:
And the other thing is if you try to modify pretty much any innumerable collection in place, you get a – I believe that's a runtime error, not a compiler error.
Casey:
And so that's just really nice ways to protect you from yourself, and that I really appreciate.
John:
Do I have to tell you that Pearl would protect you from these things too or we just assume it now?
Marco:
Opera did it.
Marco:
Ding.
John:
Pearl requires braces on single statement ifs.
John:
It doesn't let you do it without them.
John:
And that was intentional to avoid this feature because the people who wrote Pearl were writing Pearl in C and hated that.
John:
And there's no switch statements, so problem solved there.
John:
There is a terrible deprecated one that's part of a CPAN module, but it doesn't count.
John:
It's not part of the language.
John:
And the... What was the other one?
John:
Oh, modifying sets.
John:
If you iterate over the keys of an associative array, you can actually modify the array because it gets the key list ahead of time and it doesn't make reference to the thing.
John:
Unfortunately, if you get the keys and values, then it does the good old PHP way where it's just madness.
John:
But...
John:
There are other reasons not to do it.
John:
They should just deprecate getting the keys and values at the same time anyway because I don't want to go into Perl details.
John:
But suffice it to say that it's not a – they have to keep an iterated value on a per-variable basis, and that just leads to more madness.
John:
So that should be deprecated but isn't yet.
Marco:
This is one of those things, too.
Marco:
The go-to-fail bug, there's actually a compiler warning that warns on unreachable code blocks.
Marco:
And so if you have a function that contains return zero and then a bunch of lines of code below it, well, those lines will never be reached because that return statement, that unconditional return will execute and then everything else in the function will never be reached.
Marco:
GoToFail thing, again, if you have this unconditional GoTo statement, which is what the bug line was, that skips over the big block of the function, then that code is unreachable.
Marco:
And so compiler, there's a warning for that.
Marco:
I don't know if it's in GCC, but it's at least in LLVM.
Marco:
And the problem is it's not part of the wAll option that a lot of nerds use.
Marco:
it's not part of the all warnings default set.
Marco:
Um, because I, I think I, I was reading a little bit about this.
Marco:
I, I think the main reason why, uh, is because there's a lot of like, you know, libraries and stuff that, that it would fail on for various reasons.
Marco:
And so, you know, that's, you know, that's always, it's always a tricky balance with warnings when, when you're striking that.
Marco:
Like I, I recently in my PHP framework, um,
Marco:
I always had, for the last few years, I've used what I call strict development mode, which is when you're in the development environment, everything, even the notice, the lightest level of PHP warnings, everything became an exception because I don't want my code to ever emit a notice.
Marco:
And I don't care if it's going to be littered with is set statements all over the place.
Marco:
I don't care.
Marco:
Everything, there should be no errors in development.
Marco:
And I recently, just even a couple of weeks ago, I think it was, I recently decided, you know, why...
Marco:
Why shouldn't that also apply to production?
Marco:
If I'm throwing exceptions on any minor error in development, that for, I think, good reasons, why should I be more lenient in production?
Marco:
In reality, if things are failing anywhere, I want to know about that so I can stop it, so I can fix it, so I can do the right thing.
John:
There's a reason it shouldn't apply in production if you don't control your own servers, which a lot of people don't like.
John:
They're sort of deploying to, they have some baseline they need to support for their deployments, but they don't control every single detail.
John:
Like they don't have their own machines, basically.
John:
They're not the one who install PHP, for example.
John:
They're not the one controlling Apache and the upgrade cycle and stuff like that.
John:
And you don't want to run with all your warnings turned on, especially with warnings turned into fatal errors in that situation, because someone will do a minor point upgrade to Apache PHP or some other thing, which will suddenly cause warnings where once there were none, and then your production is down because of something you didn't do.
John:
But in your case, since you control all the you control the version of everything, it's not going to get upgraded behind your back.
John:
So it is slightly more reasonable to do that.
Marco:
I think I would disagree on that.
Marco:
I think I would want that to break because that's a problem that you should know about immediately.
Marco:
And if the people who are controlling the servers do any kind of testing, like if they maybe deploy it on a development server or if you deploy directly to production with stuff like PHP updates, at least do it on one server first and see what happens at least if you're going to be that sloppy.
Marco:
And if –
Marco:
in all those cases, I'd rather the app actually crash and burn immediately.
Marco:
It's like the fail early and completely or often, whatever the statement is, fail early.
John:
The warnings are always going to be something like, this language feature is going to be deprecated sometime in the next two years, so you should stop using it.
John:
And it's like, that should not cause your app to go down in production.
John:
If that did, you'd be mad that it went down because you'd be like, that's not important enough for production to stop working.
John:
And you'd be mad because they upgraded something and it broke your stuff or whatever.
John:
But the
John:
Like, historically, in my working career, the reason warnings get turned off in production is precisely this reason.
John:
Even sometimes when we do control the entire stack, merely because a different department in the same company controls, like, the upgrade cycle and stuff like that.
John:
And the other department doesn't want that department possibly screwing them up by, you know...
John:
changing something that causes a warning that is totally bogus and immaterial and stupid and really does not have anything to do with the functioning of the application is practically like the developers just like waving at you and saying we made a new message here look at our message hi how you doing message message and you're like i don't want my program to stop working because of that i'll see it fine we go and patch up that thing so it doesn't emit the warning anymore it's not like it'll be invisible but uh turning it into a fatal error in production is usually a bridge too far
Marco:
I still disagree.
Marco:
I see your point.
Marco:
I don't think that's a good enough reason.
John:
Well, for a one-man shop that controls everything, yeah, that's fine.
John:
But things get much more complicated as the organizations get bigger and things get farther away from the control of the people writing the code.
Casey:
Yeah, I completely agree with John.
Casey:
And I think that comes from the fact that John and I have real jobs and it's just you by yourself.
Casey:
So it's not easy.
Casey:
It's not easy to deal with those sorts of issues.
Casey:
And even in consulting, it's an even finer line because a lot of times, you know, myself and my team will build something, hand it off to the client and then walk away.
Casey:
And so in many cases,
Casey:
the company for which we've built something may or may not really have the talent in-house to figure out when some esoteric warning happens and what to do about it.
Casey:
And we're not necessarily contracted with this client anymore, so they're on their own.
Casey:
And not to say that we silently squash all exceptions or anything like that, but for non-fatal things,
Casey:
Oftentimes it's not in our or our client's best interest to cause a ruckus over those sorts of things.
John:
The C tool chain is better about doing this, which is basically why minus wall doesn't print so many errors, because whoever defined wall way back when.
John:
now no one can change it because if you did you were like oh this compiled cleanly and now it doesn't your compiler is broken right that's why there's w everything because wall is not historical baggage like that whereas in the much looser uh higher level languages and the fancier tools that people have no problem throwing out the next version the next minder version of like ruby or node or something like that and adding a bunch of warnings because
John:
Because they're trying to influence the people who are using the language, because they're trying to warn about deprecating features, because they think they've decided that this could potentially be a problem.
John:
Because their warnings are like, we don't know this is wrong, otherwise we wouldn't have compiled it.
John:
But there might be something you might want to look at here.
John:
this may be a new warning so you don't have a statement above it that says don't warn me about that thing like you were saying with the is set but like there's lots of other things you could like put pragmas and lexically scoped warnings restrictions to say look I know normally a warning would be emitted here but I know what I'm doing let this thing go past and you write that right into the code well you can only do that for the warnings you know about and although your C compiler is not going to suddenly add a bunch of things to minus wall lots of other languages and open source projects that are newer and moving much faster
John:
We'll have no problem adding crap like that.
John:
And eventually just the fatigue of the organization keeping up with these things is like, you know, politically speaking, they'll be like, can't we just not make the warnings into exceptions in production and just look at the logs?
John:
And when we see new warnings, fix them.
John:
That will very quickly go through once production is down a few times and bosses and bosses bosses are.
John:
yelling down to develop and asking why production was down.
John:
And at that point, Marco will have a much harder time explaining to his boss or his boss's boss why it actually really is a good thing that production went down because now we know about this failure right away.
Marco:
See, I think this is a lot like ending a list program with a bunch of closing parentheses just in case you make a mistake.
Marco:
which was actually the recommended thing in my CompSci 201 or whatever class when we were learning Lisp.
Marco:
The professor actually instructed us to put a bunch of closing parentheses at the end of the file to make it easier while learning.
John:
He might have been joking.
John:
But basically, from a practical perspective, if your company is a 24-7 online company and they lose, let's say, $5,000 in revenue for every 60 seconds your servers are down, it is much harder to make the argument that Marco has made.
John:
Yeah.
John:
it really depends on the situation.
John:
And some reasons are stupid, like institutional reasons where there's, you know, kingdoms within the company that are fighting each other and, uh, the developers are distant from the code and they don't control the deployment.
John:
Like those are sicknesses within the company, but then there are legitimate reasons.
John:
Like we'll say it is a company where everybody works together, but you know, you lose X amount of dollars for every minute the server is down.
John:
Uh,
John:
It only takes one night of that happening to equal one developer's salary that they could have had for the thousands of dollars they lost for their servers being down during that time.
John:
And so, yeah, sometimes you just practically speak and don't have the luxury of turning all warnings into exceptions.
Marco:
See, I think this is a... Everything you've just said, where it's really critical that if this happens in production, it's a really big problem, that's all the more reason why you shouldn't be reckless deploying updates in production to your critical code, like your language interpreter.
Marco:
If you're deploying a new version of PHP to your production servers that you've never tested your code on in development, and you have...
Marco:
the kind of situation where you're going to lose tons of money every minute that your site is down in the middle of the night because you updated it in the middle of the night, and you have to wake up your programmers.
Marco:
To me, there's a number of things wrong with that, and it's not your warning level.
John:
dynamic languages can emit unexpected warnings not just because they upgraded the version of dynamic language interpreter but simply because that code path didn't have coverage and you know it's like they run they basically run time warnings like that they're that exists that's the thing in dynamic languages especially for web programming that if you don't execute that code path that warning will never be committed but if you have all warnings immediately become fatal exceptions and in production someone actually hits that code path no one upgraded anything
John:
But your server still, you know, died because that turned into a fatal exception.
Marco:
there's always between, with any kind of non-error, any kind of warning or notice, there's this balance that you're striking between convenience and easiness and tolerance of edge cases versus trying to be correct all the time.
Marco:
And it's kind of like security.
Marco:
There's a balance you have to strike between convenience and ease and the right thing.
Marco:
And
Marco:
If you're to the point where you're permitting lots of warnings to happen in production unexpectedly, I think that's a sign that something's wrong.
John:
Well, you're not permitting them.
John:
You just don't want them to be fatal errors.
John:
You'll address them as soon as you see them.
John:
Because a lot of them could be data-driven.
John:
For example, value comes in and it's undefined.
John:
And how is that value undefined?
John:
It's okay for it to be undefined, but there's some warning that if you use an undefined value and there's one function that says this is unexpected and you totally thought it should be expected, someone forgot to put...
John:
Please don't give me warnings about undefined values when I pass this in because it's okay for it to be undefined.
John:
But you never hit that code in your testing and it gets admitted.
John:
Like warnings aren't necessarily... I know people like to turn them all on in development so they can just get things clean because it's much easier to verify that there's nothing there because once you let any leak through, then it becomes an avalanche and you start ignoring them.
John:
But in production, like...
John:
So enabling these things isn't necessarily saying we are telling you there's something wrong with your code.
John:
In fact, almost all the time, it's not telling you there's something wrong with your code.
John:
And it's just really hard to be at the whim of these messages that don't actually tell you anything useful about your code in production, turning them into fatal errors, leave them on in production, log them, immediately address each one of them so that you get the volume of those warnings down to zero again, but turn them into fatal exceptions.
John:
Like I said, I think that's too much.
Marco:
But you see, I think that – and people in the chat have also suggested like you should just log them and then have a policy to deal with them.
Marco:
I think in reality that's much more likely to just get ignored or to be, oh, well, it only happens once a week for a few hours or we've only ever seen this message five or six times, so we'll just ignore it.
Marco:
And I think that's the wrong approach for a lot of situations.
John:
Okay.
John:
But you don't need to know it.
John:
You'll know exactly what line it came from.
John:
You can get a stack trace with it.
John:
It's usually so easy to address because you'll immediately look at the warning, look at the line of code, and say, is this an acceptable condition?
John:
If it's an acceptable condition, you just put in the pragma that says, don't emit that warning from this line anymore.
John:
Done and done.
John:
If it's not an acceptable condition, then congratulations, you've been alerted to a potential bug and you need to change your code.
John:
Both of those situations, one is either dispensed in two seconds, and so there's not a barrier to entry to that.
John:
And the second one is you found a legitimate bug, and I think developers will want to fix that as well.
John:
I don't think people will ignore them, especially if you're running all development in the fatal errors mode, because that will ensure that your volume is zero in development.
John:
It's just when you get to production that you want to crank it back one notch, basically to make yourself not go down for reasons that you wouldn't want to be down.
Marco:
But again, I think the human behavior, like the reality of human nature is such that if you tolerate those warnings in production, even if the policy says you shouldn't, in practice, that's going to lead to a lot of messy code staying there indefinitely.
Marco:
Whereas if it actually breaks, it forces you to fix it.
John:
Big organizations are good at one thing.
John:
It's making policies, annoying policies.
John:
So I actually have more faith in a large corporation's ability to make a stupid policy that it requires zero war, not stupid, to make a policy that people don't like following because it's human nature to not want to deal with those things and to enforce it.
John:
It goes the other way.
John:
The policy that says you've got to have all warnings on when you build your application.
John:
A lot of individual developers won't like that because they find it tedious to go trace down all those errors and everything like that.
John:
Indie developers tend to have to psych each other up to say, I know I should be running with W everything, but I'm not.
John:
And they kind of have to encourage each other to do that because they know it's good for them, but it's human nature not to want to do that.
John:
It's like flossing.
Yeah.
John:
In an organization, you have someone two levels up who doesn't have to touch the code who can just force everybody to do that and make it a policy.
John:
I think as Casey has said this many times in the past, and it's true if anyone works in big companies, whenever anything goes wrong, someone wants to make a policy to prevent it from ever happening again, which eventually leads to
John:
a gigantic web of policies that paralyzes the company and makes them stupid and dumb but like i said that's that's the one thing they're good at is this bad thing happened make a policy so it doesn't happen again and like they would institute the policy we must have zero warnings by the tuesday after the build all warnings must have tasks assigned for them with due dates and like that that is i think something that big organizations are good at
Casey:
Right.
Casey:
And I think, Marco, what you're maybe losing sight of is that a lot of times having a production failure, it just isn't an option, even for seconds.
Casey:
And John was alluding to this earlier.
Casey:
But you're coming from the position, as you should, of someone who is not only the peon coder,
Casey:
but is also the boss.
Casey:
And so if Overcast is out in the wild and it goes down, who do you have to answer to?
Marco:
Everyone will know why now.
Casey:
Yeah, exactly.
John:
Date default time zone set.
John:
You know, you were modifying another collection while iterating over it.
Marco:
Well, now we at least know that you shouldn't use my framework if you have this situation.
Casey:
Right.
Casey:
But you know what I mean?
Casey:
Like you have to answer.
Casey:
Yes, you have to answer your customers.
Casey:
And that is kind of crummy.
Casey:
But your customers can't fire you.
Casey:
They could walk away.
Casey:
OK, we can go and we can go down that rabbit hole if you really want to.
Casey:
But in a direct sense, they can't fire you.
Casey:
They can't not give you a bonus that year.
Casey:
They can't empirically hurt you.
Casey:
And it's very different for I think I speak for John and saying it's very different for he and I, because if we make some sort of decision that we think that dying in production is better, somebody many, many, many rungs up the ladder from us may not agree with that.
Casey:
And I guarantee you, the bigger the company, the more well, in my experience, the bigger the company, the happier they are to find a head to chop off and let roll.
John:
Well, the big thing is you will not be able to convince them, even if you're 100 percent right, because there are many situations where you really are right.
John:
And this was like ignore whether we're talking about warnings like this was a legitimate reason.
John:
It is actually better that this happened than it not happened.
John:
Good luck convincing somebody three levels up in the org chart of that.
John:
Even if you are just so right and that everybody who is a sibling to you in the org chart and below you agrees and they all sign a petition and they all get out in the parking lot and say we're right.
John:
Yeah.
John:
the COO or the CTO and certainly the CEO, you will not convince them.
John:
And that's the harsh world that we live in.
Marco:
You know, let me challenge our listeners here.
Marco:
I'm honestly curious.
Marco:
I would like to know if you work at a company that has a big, important online infrastructure...
Marco:
Amazon, Google, stuff like that.
Marco:
Big, important companies where you do things well online, and it's really important that they stay up.
Marco:
I'm curious, what is your policy?
Marco:
What is your company's policy?
Marco:
And you can write us on the feedback form anonymously.
Marco:
You can use throwaway Twitter accounts.
Marco:
We don't need this to be like...
Marco:
On the record, I'm just curious to know what do the big companies do in reality where this stuff really does matter and where they are technically generally well-run companies?
John:
I think at that scale, it's kind of different because I think Google and Amazon and Netflix and stuff like that have to design for expected failures.
John:
So they have to have basically instead of an organism that is like clean and running, they have to make one where –
John:
cell death is expected and they just have little busy robots going through and cleaning up the dead cells and stuff so that is that's a little bit different and i'm thinking of like the medium term ones where you're not that big every human in the world is not hitting your server but it has to be up it just absolutely has to be like stock trading or banking things whereas only a few computers in this network and they're directly hacked into by crazy fiber optic wires and they're doing high frequency trading or they're doing something like that they're doing bank transfers but
John:
These three or four computers have to always be up.
John:
Otherwise, people lose millions of dollars.
Marco:
But again, that's more reason why you should be really careful what code runs on them and why you probably shouldn't ignore a warning.
John:
Well, you're not ignoring it.
John:
We're just going around circles.
John:
It's the question of do you want something that doesn't necessarily have to be fatal to be fatal or to cause a piece of work to be put into someone's bin to fix that with a deadline because that's the policy and so on and so forth.
John:
But anyway, people can send us feedback on whatever they think the policy is.
John:
I think you'll be horrified to find that.
John:
People don't enable warnings, period, even in development.
John:
Forget about ignoring them.
John:
They're not even enabled.
John:
Like if we actually took a mass survey, what we'd find out is there would be like warnings.
John:
No, we turn those off.
John:
Those annoy us.
Casey:
Yeah, you're absolutely right.
Casey:
You're absolutely right.
Casey:
And the other thing I should point out is that you saying, Marco, that you only care – well, I shouldn't say that.
Casey:
The way you phrased the question was if your livelihood, your company's livelihood is based on some sort of online service or website or whatever, but what you're losing sight of is –
Casey:
A lot of times my clients at the job in which I work, we oftentimes, but not always, do like a corporate intranet, you know, the same sort of thing that Igloo does.
Casey:
And a lot of times we're told this cannot go down, when in reality...
Casey:
Nothing will go broken if the Internet is down.
Casey:
You know what I mean?
Casey:
So a lot of times from on high, they say this Internet will be up always.
Casey:
But really, it doesn't matter.
Casey:
And so we have to make decisions as consultants.
Casey:
based on the requirement from the client, even if we think it's bull.
Casey:
And I think that John was alluding to that earlier.
Casey:
And so a lot of times, even if you could say, well, it doesn't really matter if this goes down.
Casey:
So a lot of times clients will say, well, it better frigging be up or we're coming and calling you guys and we're going to be pissed on a happier note.
Casey:
You want to tell me about something cool?
Marco:
Yeah, and before – one final thing.
Marco:
Sorry.
Marco:
I think that you're right that for your situation where if it's a consulting gig where you have to build some system for somebody and then effectively it's going to have zero maintenance for a while, whether that's weeks or years or decades.
John:
Mm-hmm.
Marco:
Then I think that's a different environment where you expect the software to just tolerate existing and whatever upgrades happen on its server, which probably won't even be a whole lot, honestly.
Marco:
But in reality, let's be realistic here.
Marco:
But this thing has to operate with no programmer intervention indefinitely.
Marco:
Then it's a different story.
Marco:
Then I completely agree that you're already doing something that's...
Marco:
by software development standards, pretty bad.
Marco:
In that, like, you're going to have unmaintained software in production use for a long time, right?
Marco:
But in reality, that happens all the time.
Marco:
And so you're right that, like, you know, in practice in a lot of places, you have to accommodate for that.
Marco:
But that's typically not the kind of place, as you just said, it's not the kind of place where it's super important that there be no technical errors, you know, all the time.
Marco:
So anyway.
Marco:
All right.
Marco:
We are sponsored this week also, once again, by our friends at HelpSpot.
Marco:
Are you still using email clients for customer support, Casey?
Marco:
I do customer support?
Marco:
I mean, yes.
Marco:
Yes, I am.
Marco:
You're probably losing track of important tickets.
Marco:
I bet I am.
Marco:
Trying to use Mark as on Red as an organizational tool, and I am in coworkers to see who's working on what.
Marco:
That's ridiculous.
Marco:
It's time to get organized.
Marco:
Okay.
Marco:
Most helpdesk software tries to be all things to all people.
Marco:
Infinite feature creep, these huge, complex messes.
Marco:
HelpSpot is focused.
Marco:
It deals only with customer inquiries and self-serve knowledge bases.
Marco:
There's no built-in asset management or password resetting or other unnecessary features to get in your way or require complex integration work with your application or your infrastructure.
Marco:
Helpdesk software is also usually really expensive.
Marco:
A lot of them are like around $600 per user per year, which is really high.
Marco:
HelpSpot is just $2.99 per user once.
Marco:
You own it for life.
Marco:
It's not per month.
Marco:
It is $2.99 per user one time.
Marco:
You own it for life.
Marco:
And there's no lock-in.
Marco:
You can download the software and host it yourself, or you can have it hosted for you.
Marco:
Either way, even if they host it for you, you always have access to the database that you can directly query, export, and take elsewhere.
Marco:
HelpSpot is not some new startup.
Marco:
They've been available for nearly a decade and they've been adopted by thousands of companies and organizations.
Marco:
Customers from single-person startups to Fortune 500 companies all use HelpSpot to manage their support teams.
Marco:
So you can start a free trial today.
Marco:
Go to helpspot.com slash ATP.
Marco:
And then when you're ready to buy it, if you use coupon code ATP14 for the year of 14, code ATP14 will save you $100 off your already very well-priced purchase.
Marco:
So thanks a lot to HelpSpot for sponsoring our show once again.
Marco:
Remember, go to helpspot.com slash ATP and use coupon code ATP14 for $100 off.
Casey:
So here's the thing that we're kind of dancing around, and I think it might be time to pull the Band-Aid off.
Marco:
No, I wanted to do the script notes thing.
Marco:
I thought that's what you were talking about because it's perfect.
Marco:
It's exactly what you were just talking about.
John:
I know what he wants.
John:
He wants to solve our methodologies.
John:
He always does.
John:
We kind of touched on it a little bit, but we don't have time for script notes.
John:
You don't want to save it to F4F, the second sponsor.
Casey:
John, it's happening.
Casey:
I hate to break it to you.
Casey:
It's happening.
John:
I've listened to that Script Notes podcast for nothing.
Casey:
Well, so did I. I even listened to the follow-up today just to make sure I had it done for this episode.
Casey:
Gentlemen, relax.
Casey:
This is the way it's going to have to be.
Casey:
Daddy Casey has spoken.
Marco:
We are also sponsored this week by Squarespace.
Casey:
You're such a jerk.
Marco:
The all-in-one platform that makes it fast and easy to create your own professional website or online portfolio.
Marco:
For a free trial and 10% off, go to squarespace.com and use offer code Casey.
Marco:
Yay.
Marco:
Squarespace has always been improving their platform with new features, new designs, and even better support.
Marco:
They have beautiful designs for you to start with and all the style options you need to create a unique website for you or your business.
Marco:
They have over 20 highly customizable templates for you to choose from.
Marco:
They've won numerous design awards from prestigious institutions, and it's incredibly easy to use and customize.
Marco:
If you want some help, Squarespace has an amazing support team that works 24 hours a day, seven days a week, with over 70 employees right here in New York City.
Marco:
All of this starts at just $8 a month and includes a free domain if you sign up for a year.
Marco:
And you can start a free trial today with no credit card required.
Marco:
It's a real free trial, no credit card.
Marco:
And when you do decide to sign up, use offer code Casey for 10% off to show your support for our show as well.
Marco:
And one more cool thing, two more cool things actually.
Marco:
You know what?
Marco:
I'm going to go all out.
Marco:
Three more cool things.
Marco:
Squarespace has introduced this new thing called Squarespace logo.
Marco:
In addition to building your website, you can now build your own logo for your site, business card, shirt or whatever you want.
Marco:
Also, all Squarespace plans now include the commerce functionality.
Marco:
You can have a store where you sell physical or digital goods.
Marco:
They have all sorts of great integration there.
Marco:
It's so easy to set up.
Marco:
You can finally have your own online store with very, very little effort.
Marco:
It's really amazing.
Marco:
And every Squarespace plan now includes the commerce functionality at no additional charge.
Marco:
And finally, Squarespace is hiring.
Marco:
If you interview for an engineering or design position before March 15th,
Marco:
They will invite you and your partner to be New Yorkers for a weekend.
Marco:
They will fly you out to New York, put you up in one of the city's best hotels, and give you a long weekend of checking out some of their favorite attractions, cultural icons, and restaurants in the city.
Marco:
Squarespace will pick up the entire tab for this awesome trip to New York.
Marco:
They've been voted one of New York City's greatest places to work for two years running, so really put them on your short list.
Marco:
They're looking to hire 30 engineers and designers by March 15th.
Marco:
So go to beapartofit.squarespace.com.
Marco:
That's beapartofit.squarespace.com to learn more about this cool offer.
Marco:
Thanks a lot to Squarespace for sponsoring our show once again.
Marco:
So about the Script Notes episode.
Casey:
Don't even start with me.
Casey:
Are you really going to be that?
Casey:
If you really want me to abandon software methodologies, even though it perfectly fits the thread of this episode, then we can move on.
Marco:
John, what do you think about this episode?
Marco:
God, I hate you so much, Marco.
John:
Casey, you've got to assert yourself.
John:
If you want to talk about Sawher Methodologies, you can.
John:
I would say, though, with the time left in the episode, don't you think it deserves to be kind of like in the prime spot with more time?
John:
I leave it up to I'm abstaining from this vote.
John:
So it's Casey versus Marco.
John:
Decide what we're going to talk about next.
John:
I'm prepared for both.
John:
I kind of feel like Sawher Methodologies is a big enough topic that we wouldn't want to try to jam into the end of the show.
John:
But I'll go either way.
Marco:
I actually am going to agree with John's non-vote, which actually is a vote, but I'm going to agree with John's non-vote and say that I'm not trying to avoid it.
Marco:
I do think it deserves more time than this.
Casey:
You know, you're probably right.
Casey:
And God help you trying to edit this episode because now I've turned it into a complete cluster.
Marco:
Oh, this is all in.
Marco:
Just one horn needed.
Marco:
That's it.
Casey:
It's all in.
Casey:
I'm excited about that.
Casey:
This is what people tune in for, Casey.
Casey:
Oh, is this the show?
Casey:
All right.
Casey:
So we should probably catch people up on Script Notes as I...
Casey:
curse this topic internally even though it actually is very interesting so a lot of people came and told us oh you should really listen to this script notes episode and script notes is a podcast by two screenwriters and i couldn't even tell you who they are off top my head john august and some other guy thank you that's what i knew too but i wasn't gonna say that
John:
Yeah.
John:
And I only know who John August is because he was on other podcasts that I listened to.
John:
And I've seen his movies and I like them.
John:
And I'm like, oh, he's the guy who did that.
John:
But yeah, I don't know the other guy.
John:
Sorry, other guy.
Casey:
Now that other guy knows exactly how I feel.
Casey:
Anyway, so there's this podcast about screenwriting.
Casey:
And apparently the de facto industry standard for screenwriting is called what?
Casey:
What is it called again?
Casey:
Final draft.
Casey:
Thank you.
Casey:
I kept wanting to say final cut.
Casey:
Final draft.
Casey:
And so it's a screenwriting application, and it is, like I said, the industry standard.
Casey:
So from what I gather, the screenwriters, John August and Casey, we'll call him, they don't particularly care for final draft.
Casey:
His name is Craig Mazin.
Casey:
Thank you.
Casey:
So John and Craig don't really care for final draft.
Casey:
And they actually, I guess I complained about it in prior episodes, but this past episode at the time we record this –
Casey:
So they had actually had the CEO of the company that makes Final Draft as well as what, a product manager?
Casey:
Is that right?
Marco:
Product or project?
Marco:
I don't know the difference.
Marco:
I live in my own little world here with one.
Marco:
Fair enough.
Marco:
So some other guy.
John:
We'll just call that person long-suffering employee.
Casey:
Right.
Casey:
So that other guy.
Casey:
So the two of them came on the show, which I really respect because it was clear from the get-go that this wasn't going to go well for them.
Casey:
And so John and Craig had these two other guys on the show and started telling them all the things that they don't really like about Final Draft and why they feel like they've been wronged.
Casey:
By not only the high purchase price of what, $250?
Casey:
Is that right?
Casey:
Something like that.
Casey:
Something like that.
Casey:
$250 or so for Final Draft, but also the slow updates.
Casey:
And it was a really fascinating view of both sides of the coin of software development, both as the company and the people who create software...
Casey:
And the people who consume it and how they don't entirely understand what we go through is in the same way that the CEO and that other long-suffering employee don't really understand what their customers go through either.
Casey:
And I have some takeaways from this, but let me open the floor to you guys and see.
Casey:
Marco, what did you think about all this?
Marco:
Well, first, I think – so I listened to the podcast.
Marco:
I made my own opinions of it, and I even made a whole post about it.
Marco:
And all that was before I had read this follow-up article from – there's a guy named Kent Tessman who writes a competing product called, I believe – called Fade In.
Marco:
Here we go.
Marco:
And he's been a longtime critic, I gather, of Final Draft.
Marco:
And that's one of the reasons why he started writing his own because he hated Final Draft so much.
Marco:
So he started writing his own.
Marco:
And he's clearly a programmer tech guy but also a film guy.
Marco:
And –
Marco:
And he broke down... Here, I'll put the link in the show notes here.
Marco:
He broke down exactly some of the problems with Final Draft, technically.
Marco:
Like, for instance, that it still doesn't support Unicode.
Marco:
Like, really, like, major, major shortcomings.
Marco:
And that one of the reasons why they had so much trouble going Retina was not necessarily because it was using Carbon, because you can do Retina with Carbon.
Marco:
It's because they were using Quickdraw.
Marco:
which was deprecated, what, 20 years ago?
Marco:
10 years ago?
Marco:
A long time ago, at any rate.
Marco:
They've built up quite some technical debt.
Marco:
And so there's some problems there.
Marco:
It basically seems like they wrote this application in the 80s and 90s and have not...
Marco:
been kind of sitting on it and not doing the really hard migrations and not modernizing all this time.
Marco:
And then all of a sudden, they were forced to by their customers with things like Retina, and they were forced to suddenly do this quickly, and it became a really big thing.
Marco:
And so it's a pretty typical story of pretty severe technical debt being ignored for way too long.
Marco:
I think what I got out of the CEO's comments and attitude was that...
Marco:
He wants to make all of his problems your problems.
Marco:
The reason why I think it's important for developers to hear this is because you can see both sides of it.
Marco:
You can see the CEO arguing the business side and the difficulties of the business side.
Marco:
And then you can see the customers arguing that, well, your business stuff is your problem and it's not serving us at all and you're kind of treating us badly and your product needs a lot of work and is really stagnant and outdated.
Marco:
So you can see both sides of it and you can kind of see as a programmer or especially as a company owner, if you own your own company or make your own products, you can see how you could become that CEO and it should scare the crap out of you.
Marco:
Because that's a plausible outcome for so many software developers.
John:
I think developers should listen to this because people with technical knowledge of both sides of the software industry or people who listen to this podcast or just Mac nerds or are into the indie development scene will have the unique experience of listening to a podcast with two camps of angry people, both of whom are just massively wronged.
John:
fundamental level about the major points of their arguments like the customers are wrong about like your product should be free and how hard is it to do this and like you know from the outside they think everything is easy and they think everything should be free and apple gives away the os for free why can't you give away final draft
John:
Like, they're just so out of left field.
John:
Like, you know where they're coming from, but it's like, man, they have no idea what the reality of software.
John:
And as Marco pointed out, the CEO is being defensive in ways that are not appropriate for his job as a software.
John:
Like, it's his job to figure out a way to keep your software up to date.
John:
Those are all your problems.
John:
You have to figure out a way.
John:
That's called being a software entrepreneur.
John:
You have to figure that stuff out.
John:
You can't throw it back in customers' faces and say, you don't realize it's really hard to do this.
John:
And it's clear that the CEO doesn't have a lot of technical knowledge, so he doesn't even know the detail things.
John:
I felt like I wanted to jump into the podcast and explain to each one of them why they're positioned, why they're both wrong.
John:
Look, things can't be free, and you're crazy, and let me explain why your reasoning is wrong.
John:
And you, CEO, you don't even know why this is hard, but it is really hard.
John:
And if you had a clue how hard it was, you would have started on these transitions years and years ago.
John:
And yes, they might have destroyed your company, but look how many other companies have been left in the wake of not being able to keep up with the changes in OS X and iOS.
John:
That's your job.
John:
You want to be a big boy in the software world?
John:
It's not easy.
John:
The best example is something like BBEdit, which started on classic macOS.
John:
And it has had to go through.
John:
It's so similar because it's a text editor.
John:
It had to go through all these things.
John:
They had Quickdraw.
John:
They had to get rid of that.
John:
They were Carbon.
John:
They had to find a way to, you know, go on modern OS X. They had to adopt Unicode.
John:
They had, they went through like, you know, they used to like at sweet and like core text and whatever the hell they've gone to multiple different underlying text engines.
John:
You have to do that.
John:
Otherwise, you're dead.
John:
And if some other nimble competitor who doesn't have your legacy concerns makes a new application, and the only reason you're staying successful is because you're an entrenched interest or whatever, we've all seen this play out a million times.
John:
So those two camps of people were just both angry, both talking past each other, and just both fundamentally wrong about their complaints about the other person.
Marco:
Oh, yeah.
Marco:
And you can't have an app that has a code base that like you can't write an app in 1990 and still be around in 2014 and not have to have gone through a few really painful transitions in that time.
John:
Unless you coast on like, well, we're just so entrenched.
John:
We're the big gorilla.
John:
We can afford to like, even if you do that, your time, you have a longer timer, but it's still a timer because like eventually your app doesn't launch anymore.
John:
And you're like, well, now I guess it's the time we have to move away from quick draw.
John:
It's like, nope, sorry, too late.
John:
Now you're dead.
John:
Like, I don't think final draft is in that situation yet because they are such an entrenched interest.
John:
But hell, look at Adobe.
John:
Look how long it took them.
John:
We mentioned this.
John:
Look last show.
John:
Look how long it took them to go cocoa.
John:
The only reason they can get away with that is because they're Photoshop.
John:
You know, we are Photoshop.
John:
We are the image editor.
John:
We ate up all the other ones.
John:
You know, we bought Macromedia or whatever.
John:
Like, and even then, like eventually the OS is like, no, seriously, you want to be 64 bit.
John:
You got to be Coco, right?
John:
Like even then they're forced to upgrade.
John:
But yeah, the final cut, the CEO didn't understand, doesn't seem to understand what his, what his company does or should be doing.
John:
Like, what does your company do?
John:
We sell and maintain a software application.
John:
Like, that's a dynamic business.
John:
You can't just keep making the same thing and, like, expect, I don't know, expect everyone else to do your job for you and to make it so that you don't have to, your company doesn't have to do the hard things.
John:
I don't know.
Casey:
Yeah, and there were some quotes in this, only a handful that I'd like to quickly go over, that just really stuck out to me.
Casey:
So one of them, and actually John, you already quoted it, was, well, and this is John and Craig, well, Apple gives an entire operating system away for free.
Marco:
No, that wasn't them.
Marco:
That was the CEO citing that as a problem that they have.
Marco:
Yeah.
John:
No, I think it was – the CEO pointed out to them that they make money from selling the phones, but I think it was the complaining customers who were saying – if it wasn't the OS, it was something about, like, look how cheap software is.
John:
Like, software has been devalued, therefore your thing should be $1 or free.
John:
It's like selling – telling Adobe that Photoshop should be free or, like, $0.10 because Angry Birds is $0.10.
Marco:
Well –
Marco:
To be fair, they were not complaining that Final Draft is not free.
Marco:
From what I gather, they were complaining twofold, both that it is not a high enough quality product to be worth the high price anymore, and that the upgrades are not worth the upgrade price because of how little progress is made, relatively speaking, in each upgrade.
Marco:
That seemed like their bigger complaint, not that the app should be free or very, very cheap.
Marco:
It seems like they'd be very happy to pay the $250 for the app if it was a better app.
John:
Well, but even then, they want to pay $250 10 years ago and never pay again and just continually have the app updated.
John:
I didn't get that impression.
John:
I definitely got that impression.
John:
I did not.
John:
I got the impression that they would have hated to spend $250 way back when, and then they just want that app to work forever and to continue to be updated with the OS and to get Retina and to get Unicode support and everything all for free.
John:
They seem to have an entitlement complex that was not...
John:
not proportional to the the value of the value that they're deriving from the software and it was kind of like compounded by the fact that this is crappy software that hasn't been updated so they feel burned by any amount of money they put towards it like it's mostly because they have a resentment like they feel like they have to have this program because like everybody uses it i think that's that's the core of their dissatisfaction is like
John:
It's like an abusive relationship with like, well, you have to get final draft because everybody uses final draft.
John:
And then you're already bitter at this thing.
John:
And if it's not the most amazing program that does everything perfectly, then you're just going to be pissed when anything is wrong with it.
John:
And there seems to be a lot wrong with this program.
Casey:
I think Marco is right, though, that I don't think they were embittered necessarily about paying for it.
Casey:
It just seems that they thought that it was an order of magnitude too expensive.
Casey:
And I'm making numbers up.
Casey:
I'm putting words in their mouth.
Casey:
But instead of $250, it should be $100 up front for the first release.
Casey:
and like 20 bucks for every supplementary release and additionally i think they were extremely embittered that these upgrades or updates whatever they called them were a heck of a lot of money and even i would probably agree to this a heck of a lot of money for really not that much update and retina was cited several times i think they said it was like a hundred dollars for the retina upgrade update whatever it was
John:
It was like $80 or something, and maybe I'm crazy, but if it was an application that I used for my livelihood, I would pay $80 for a retina upgrade.
John:
I wouldn't blink at that because say you use Photoshop to do your work, you're a graphic artist, and a Photoshop update comes out and the only upgrade in it is that the UI is retina and a couple of bug fixes, and it's $80 for the upgrade.
John:
I mean, I would pay it.
John:
Wouldn't any of you pay it?
John:
Yeah.
Casey:
I mean, I suppose I would.
John:
I mean, like maybe we have different, I guess we probably value software differently because we kind of know what goes into it.
John:
But like, but it's not like it's like 50 grand.
John:
I mean, it's not, you know, it's not a site license to some CAD program.
John:
Like, they just don't know.
John:
Like,
John:
they're just that's why i think they just they're getting used to the world where everything is like cheap or free and but it's like but this is part of your livelihood this is how you make money and i think it all gets back to it's because they don't like this tool they feel like they're forced to use it if they had their choice they would use something different and better and it's like if you're gonna force me to buy it and then now suddenly i'm not happy of it like say you hated photoshop and you needed it for your work like it's like say you hate microsoft word and you have to get it because you deal with stupid people all day who insist that you send them everything in doc format
John:
Right.
John:
Then you'd be pissed that you're going to do like an $80 upgrade to Office and the only change was that it was Retina incompatible with Mavericks.
John:
Then you'd be pissed.
John:
But you're mostly pissed because you hate words so much that any money you put towards continuing this charade of having to use this program on behalf of other people, like that's where I feel like they're coming from.
Casey:
I think it's that, but it's also that what was once a decent product has stagnated.
Casey:
The impression I got, and I've never used Final Draft, but the impression I got was that it was at one point a good thing.
Casey:
Like what they were saying about how based on the length of the PDF or the printed document, you could take a guess at about how long the script was.
Casey:
That was very cool and apparently something that at least the CEO seemed to think that that was unique to them.
Casey:
Well, anyways, the product started pretty solid and pretty good, but kind of never really went anywhere.
Casey:
And these two guys, John and Craig, were, for example, really embittered that it took so long to get retina support in there.
Casey:
And then on top of that, they got charged for it.
Casey:
And so they were saying to the CEO, you knew this was coming.
Casey:
You knew this was coming.
Casey:
How did you not figure this out?
Casey:
How did you not do it?
Casey:
And at first, I was like, well, you know, it's hard.
Casey:
I still don't have my fast techs.
Casey:
Update out for Iowa 7 because I'm a slacker and I have better things to do with my time.
Casey:
But, you know, I can understand that.
Casey:
Well, then the CEO says, and this is another one of my quotes, you know, well, we're 40 people.
Casey:
And I think to myself, OK, so how did you not get Retina done with 40 people?
Casey:
But then later on, he says, well, but 10 to 15 percent of us are programmers.
John:
What the hell is everyone else doing?
John:
Sales and marketing.
John:
The best part was when he said, you know how we learned about Retina?
John:
Someone brought a computer into the office and showed it to us.
John:
If that's how you learned about Retina, it shows you're not engaged with the platform on which you deploy your software.
John:
You don't even subscribe to Macworld.
John:
You do nothing.
John:
Forget about going to WWC, which of course you should do if your job is that you write a software product for the Mac, for crying out loud, right?
John:
Yeah.
John:
This was kind of depressing.
John:
The CEO, he did himself and his company a disservice by coming on this program and saying all these things because every word out of his mouth was like Marco said.
John:
The answer to every single one of his comebacks was like, that's your problem.
John:
That's not my problem.
John:
You know what I mean?
John:
It may be that the natural way of things is that you've now painted yourself into a technical corner and you must go out of business and it will be a blessing for the industry because we can all give our money to these other hungrier developers who...
John:
If they're unlucky, we'll go through exact same cycle as you get big, become popular, not update their software for a decade, crumble under their own weight, and the cycle will continue.
John:
But like, that's not your customers problems in any way, shape or form.
John:
And so like, it's, I don't, I guess he doesn't have people telling him, don't,
John:
go on to a program and and tell even when your customers are actually wrong about like everything should be free and you know all this stuff like don't you can't go on to a program and and tell them about all your woes and and and they're gonna go oh well now i like i guess maybe he was hoping for empathy like that they would put themselves into his shoe as the non-technical ceo of a company that made terrible strategic decisions for the past decade and go oh well now i feel bad for you it's all right i feel better about buying your software
Marco:
One thing – I noticed, Casey, you have this in the notes, and so I might as well bring it up now.
Marco:
One of the more interesting parts of this dynamic, I thought, was that the CEO opened the conversation basically by saying that –
Marco:
They've done surveys, and I believe it was 92% of the people said that they are very happy with Final Draft, and therefore they think they're doing great.
Marco:
And that's so flawed on so many levels.
Marco:
And John and Craig briefly mentioned, well, that's only people who responded to the survey, which is obviously going to be mostly people who like you.
Marco:
That's so not a random sample of what people think of your product.
Marco:
And the CEO's entire attitude seemed to just be that, well, we keep hearing from people who like it, and therefore everything's fine.
Marco:
His attitude from the very beginning was, we're fine because some people like us, and therefore we don't need to make any changes at all.
Marco:
And it's so easy.
Marco:
For people to fall into that trap, if you select what you're listening to, and I've never seen this app, and even I know everyone hates it.
Marco:
I've heard about this app for years now about how much people hate this in random edge conversations here and there.
Marco:
And not even being in the business, I know people hate it.
Marco:
Obviously, that's a pretty widespread problem.
Marco:
And it's so easy to surround yourself only by the inputs that you want to believe.
Marco:
I'm sure there's a term for that.
Marco:
It's so easy to fall into that that...
Marco:
This guy, honestly, I think he honestly thinks that everything's fine, that he's in complete denial of any major problems, and therefore that's, I think, why he was so weirdly defensive and aggressive in his responses.
John:
I don't know.
John:
really believe that he was sincere that he really believed that but like it's possible because the denial is pretty strong but i think the reason you've heard about it and i have as well even though we're not screenwriters is because we travel in software development circles and anybody who knows anything about software can look at this application and you can you can smell like the death on it or you know like i think
John:
Like, even if you don't know it's using Quickdraw, you're like, oh, geez, this program has not been updated for a while.
John:
Like, you see old, again, I have no idea how this looks, but I bet we could pick up, like, it's using older controls when it should be using newer ones.
John:
Like, maybe for a long time the text wasn't properly anti-alias or looks like it was rendered differently because it's Quickdraw.
John:
And, like, you know, just we could tell that there are problems with it.
John:
Yeah.
John:
and the reason i i think he may be right if you took a random sampling of their customer base is because their customer base are not technical people and they view this as kind of like especially if you since it's such an institution they view it as if you want to become a screenwriter this is what you get and this is the tool you deal with and everyone complains about it but like you know you might as well complain about the weather because to do your job you have to use final draft in the same way that you might say you have to use photoshop if you're a
John:
do a graphic designer you just you know there's no no other choice out there but they're non-technical people so they're not equipped to to understand what's wrong with this program and why and and they're more willing to accept that like whatever's wrong with it like what that's just the way it is what can you do uh so in that respect they may have good survey responses but the thing it makes me think of in the worst case scenario is i will bet you in 2007 2008 2009 maybe even 2010 if you were to survey all blackberry users they would say they love their blackberries
John:
it doesn't matter black rim is still doomed right you could think all the people who have blackberries love it it's like yes but the time has passed it by and customers may have it and may love it and maybe stockholm syndrome or they maybe not know better but like from the outside we all can see bye bye blackberry
Casey:
Yeah, and the other thing that I found interesting about this, and it's the only other quote that I want to bring up, is apparently there was a feature called – they called it collaborator, which I guess was some sort of collaborative writing thing where you can work on a screenplay.
Casey:
Two people can work on a screenplay at the same time.
Marco:
Yes, it sounded a lot like that.
Casey:
Yeah, that's a very good analogy.
Casey:
And so they said, and this should be pretty much verbatim, Collaborator was built when it was on a peer-to-peer technology with no security.
Casey:
It would still work like that today.
Casey:
What they were saying was when they built this feature that was designed to be used between two people, probably not co-located, they did it without even thinking about firewalls.
Casey:
And unless they wrote it in 96, are you kidding me?
Casey:
Like, how is that okay?
Casey:
And that just completely sealed the deal in my mind that... Screenwriters don't have firewalls, Casey.
John:
You think they have IT departments?
John:
They're lonely people in their apartments with dial-up internet connection slaving away and that's great script.
Casey:
And every router since 2001 hasn't included a firewall in it.
John:
Yeah, he wouldn't know about this stuff anyway if he was talking about it.
John:
But, yeah.
Casey:
And that's the thing.
Casey:
That is such an obvious technical hurdle that you would have to get over to do that kind of feature.
Casey:
And they shipped it, at least for a little while, and I guess they've pulled it since.
Casey:
They shipped it without even thinking about that.
Casey:
Like, how is that possible?
Casey:
Yeah.
Casey:
It just – it reminds me that there are terrible software developers out there or if these developers are good, just unbelievably indescribably out-of-touch management or both.
John:
If I was on that podcast, I would have also brought up the meta point, which is that the screenwriting format is ridiculous and anachronistic and –
John:
It really deserves to be destroyed and torn down, and it is held aloft by tradition, basically.
John:
This is the way it's always done.
John:
This is what a screenplay looks like.
John:
Let me tell you about all the great qualities of it.
John:
Oh, you can always tell exactly how long a thing will be in minutes by looking at the number of pages.
John:
There's always a certain number of pages every day.
John:
Everyone knows it.
John:
It can continue to be held aloft by that sort of oral tradition and indoctrination of new people into the industry that this is what a screenplay looks like.
John:
But the format is dumb.
John:
It's a monospace font.
John:
It's formatted crazily.
John:
Lots of things are in all caps.
John:
And everyone who enters the industry and everyone who gets used to it comes to like it and will not accept any other format.
John:
But bottom line, objectively, wipe out all the people who have ever seen a screenplay.
John:
Show the new people this format.
John:
They'll be like, ugh.
John:
like it is it is not of this time it is of a different time of a time of typewriters and monospace fonts and all caps and not you know it's dumb and so what the best the ideal thing to happen for the entire industry would be to not only for final draft to be disrupted but for the entire screenplay format to be replaced by something better i have dim hopes of that ever happening because if there's any group of people who is not not raring for you know amazing disruption innovation it's
John:
It's screenwriters in the entertainment industry.
John:
They just want their format.
John:
They want it to be the way it is.
John:
They just want slightly better tools to work on it, and they will consider that a victory.
John:
But from the outside, it's clear that the screenplay format is stupid.
Marco:
Well, and to be fair, in the follow-up episode of their podcast, John and Craig did address that a little bit in talking about things like how the one page per minute thing is this kind of...
Marco:
uh, elementary assumption that, you know, it's like, it's like three paragraph essay you're taught in middle school.
Marco:
It's, you know, it's like, it's a very basic thing that, you know, in, in practice, once you get, once you're a real professional, it doesn't really, it's not that simple or it's not necessary to rely on things, you know, assumptions like that, or these tenants like that.
Marco:
Um, and there's also this thing called fountain, which from what I gather is like a Markdown like or Markdown based, uh, plain text format that does away with, uh,
Marco:
manual pagination and stuff like that.
Marco:
And so it does sound like they are actually moving forward.
Marco:
And the problem really seems to be that Final Draft is not.
Marco:
Because Final Draft has this position of power right now where, or at least they have to date, where they were the standard.
Marco:
And they have their own file format, and they're relying on...
Marco:
these invariants that okay well pagination matters above all else and all this other stuff and then and the reality is that industry is being disrupted just like so many other uh technical industries where now there's a whole lot of other apps coming out some of them cheap and terrible but some of them good uh that are doing things more in a more modern way and and that's the problem like
Marco:
Just like so many other industries, I don't think Final Draft is going to be disrupted and replaced by one thing.
Marco:
I think it's going to end up being disrupted and replaced by a few standards and then a few different apps that read and write those standards.
Marco:
And it seems like this Fountain format is probably going to be that standard.
Marco:
But again, I think it's funny.
Marco:
Now all three of us are talking about something we all know nothing about.
John:
Yeah, we're going to get all the email of people explaining the various features of the screenplay format that were created intentionally for a specific reason.
John:
And I'm sure the formatting and the layout and everything had a purpose originally, but some aspects of it are clearly just artifacts of the technology that was available at the time, specifically...
John:
you know, the all caps, the monospace font, the layout being done basically by a series of spaces with the monospace font.
John:
Like all those things are done because that's what you had.
John:
That's how, you know, you weren't going to typeset it like a book because that's not efficient for the production process.
John:
You need people to be able to type these things up.
John:
It's kind of the same way that you see like the, the, uh,
John:
opening parentheses used to make ascii art to make the little boxes on the front of legal documents marco must be familiar with this phenomenon like oh yeah like the fact that that's still it doesn't really matter as much in legal documents like whatever lawyers everything they do is all made up and crazy with their legal language anything but screenplays could benefit from a format that took advantage from of modern technology keep all the good stuff about the old format in terms of visually blocking out things with white space and making it easy for actors to read and all you know all i'm just making up what the features may be of the format there
John:
There are probably good things about the format, but the bad things are just being carried along like those parentheses on legal documents, and they're just ridiculous at this point.
Casey:
All right.
Marco:
Thanks a lot to our three sponsors this week.
Marco:
Picture Life, HelpSpot, and Squarespace.
Marco:
And we will see you next week.
John:
Now the show is over.
John:
They didn't even mean to begin.
John:
Because it was accidental.
John:
Oh, it was accidental.
John:
John didn't do any research.
John:
Marco and Casey wouldn't let him because it was accidental.
John:
It was accidental.
John:
And you can find the show notes at ATP.FM.
Marco:
And if you're into Twitter, you can follow them at C-A-S-E-Y-L-I-S-S.
Marco:
So that's Casey Liss, M-A-R-C-O-A-R-M-E-N-T, Marco Arment, S-I-R-A-C-U-S-A, Syracuse.
Marco:
It's accidental, they didn't mean to.
Casey:
Accidental.
Casey:
Accidental.
John:
Tech podcast so long.
John:
Someday, Casey.
John:
Someday.
Casey:
I cannot believe I let you railroad me.
John:
Well, the script notes is timely.
John:
But no, I abstained.
John:
So it was you and Marco could have worked that amongst yourselves.
John:
If Casey had insisted, I would have gone along with it.
John:
He didn't really abstain.
John:
i did i abstain i gave i gave my opinion but i am abstaining from the vote i was what i was trying to convince casey was that uh not getting it done today does not mean it will never get done and in fact it may be done better in the future but he still could have insisted and i would not have opposed him why don't you do it next week we'll say right now next week will be software methodologies and nothing will happen bold statement nothing yeah when apple buys nintendo we won't talk about it at all
Casey:
Oh, God.
Casey:
Now you've jinxed it and we'll never talk about it ever.
Casey:
This podcast will end.
John:
If it results in Apple buying Nintendo, your sacrifice will have been noble.
Casey:
You saying that we will do it next week, whether or not you're serious, has pretty much absolutely prevented that from happening ever.
Casey:
That's the equivalent of saying, well, this will be a short show.
Casey:
Oh, God.
Marco:
If Apple buys Nintendo and there's no John Syracuse, a podcast to talk about it, did it really happen?
John:
Yeah.
John:
This is my third podcast in like three days.
John:
I did an incomparable.
John:
I did command space.
John:
Now we're doing this.
John:
I'll have to just take a rest to get ready for the big Nintendo announcement.
John:
Oh, I hate you too.
John:
I know.
John:
And we didn't even talk about driving with glass.
John:
That was another remarkable topic.
Marco:
Yeah, I mean, is there that much more to say on it?
John:
I just wanted to say that I have looked into this zero amount as is my way for the show.
John:
But what I assumed when I saw the headline of that story flying by on Twitter was that they were only lobbying to allow you to wear it in the car.
John:
Like, for example, if you get it with prescription lenses and you need them to see to drive, they didn't want they wanted to make it illegal.
John:
So you didn't want it to be illegal for you to merely wear them.
John:
I didn't think they were lobbying for it to be legal for you to have it turned on and using it.
John:
But since I didn't read any of these articles, I have to say I don't know.
John:
Did you read them and you can tell me?
Marco:
I don't think we know to that much detail.
Marco:
Hell, might as well address this here.
Marco:
I've mainly heard mostly support of my position, and briefly my position is that for Google to actively lobby against Google
Marco:
States that want to prohibit glass use while driving, I think that's incredibly irresponsible by Google.
Marco:
And, you know, I think it's, you know, pretty much all reasonable people agree that texting while driving is dangerous and should be prohibited and certainly avoided.
Marco:
People will do it anyway, but I think even the people who do it know that it's unsafe and wouldn't really argue that strongly that it was safe.
Marco:
Um, and I think texting while driving and using Google Glass are pretty close.
Marco:
Like, I don't think there's a huge difference in safety in a car between doing those two things.
Marco:
I don't think one is dramatically more safe than the other.
Marco:
It's both, like, it's engaging your visual attention, um,
Marco:
in a way that you have to interact with a multi-step process with a computer system where you're not looking at the road.
John:
Well, actually, now that I've thought about it for the five minutes that you've talked, what about if they are envisioning something like the HUD on your M5?
Marco:
There are arguments that people have made that say things like, well, this is just like looking at a nav screen, or it's just like looking at a heads-up display.
Marco:
And I think the difference is that...
Marco:
First of all, nav screens and heads-up displays are designed very, very carefully and conservatively to be maximally safe and also to minimize how long you have to look at them in ideal cases.
Marco:
Some of them won't even let you enter an address in navigation if you're moving, for instance.
Marco:
There's all sorts of safety things that car systems use to either prevent or discourage you from using it very irresponsibly.
Marco:
Things like how DVD players... Sometimes there will be these DVD players that can play video in the front seat, but you can only technically play it while you're parked.
Marco:
And yeah, some people will hack that and disable it, but there's all these things in place for things that are installed in cars, especially things that come stock from the manufacturers.
Marco:
There's all these safeties in place to try to make them as non-distracting as possible.
Marco:
And a heads-up display displaying your speed...
Marco:
Well, that's no more distracting than a speedometer.
Marco:
You don't have a lot of reasons to stare at that for a while.
John:
Well, what if the heads-up display in your glass was showing nav overlaid on the street in front of you?
Marco:
If that is what it's showing, that's fine.
Marco:
But I think, again, this is like a human nature, human behavioral kind of thing.
Marco:
Yeah.
Marco:
The reality is we've banned, in most places, we've banned handheld use of cell phones.
Marco:
Now, you could also say, well, what if you're using the cell phone in your hand looking at a navigation screen?
Marco:
And that's in places where handheld cell phone use is banned, that's banned.
Marco:
And I think this is one of those cases where, you know, the reason why that's banned is that, yeah, maybe you might be doing that.
Marco:
But there's also a very good chance that a lot of people who do that are also going to like, you know, oh, send a quick text.
Marco:
It'll just take a second.
Marco:
And there's all this potential for these multipurpose general computing systems, like smartphones, like Glass.
Marco:
There's all this potential for misuse.
Marco:
And misuse is so easy and so common that they should probably ban it outright because they know that, like, yeah, you might be using it for navigation, but there's a pretty good chance you're not.
Marco:
Or there's so many other things to do with it that aren't navigation that, you know, in reality people would, like,
Marco:
be reading a text message or dictating a message or reading Twitter or reading an email that just came in.
Marco:
There's so many potential abuses there.
Marco:
And it is so much more distracting than the in-car systems because you're interacting with a computer at that point.
Marco:
It's a multi-step interaction.
Marco:
You're visually engaging it in a way that it's non-trivial and takes more than a split second of your attention.
Marco:
And so I do think there's a significant difference there.
Marco:
And...
Marco:
And some people have also said like, oh, well, what if glass is – what if you can wear it but you have to keep it off?
Marco:
Again, same thing.
Marco:
You can't tell from the outside whether it's on or off.
Marco:
So a lot of people would just sneak by and say, oh, well, you know what?
Marco:
I'm just going to leave it on because I'm responsible.
Marco:
I'll be okay.
Marco:
And that's a problem, too.
John:
That's why I'd like to know what Google was lobbying for.
John:
Basically, were they lobbying for you're allowed to wear it, but it has to be off versus you're allowed to wear it and use it?
Marco:
I'm pretty sure it was the latter.
Marco:
I'm pretty sure they didn't distinguish between on and off, that they just wanted you to be able to wear it.
John:
Yeah, well, I think Google's bet, and I think they're right on this bet, is that augmented reality, as they call it, is probably the future of more or less everything.
John:
But I think you're right that if that is the future of everything, we are unfortunately going to have to wait for it to be built into cars because then it will be...
John:
More or less single purpose.
John:
And even if it's the exact same technology, the exact same kind of display where it like overlays the nav on top of the street in front of you and shows you where you should turn with a little arrow.
John:
Like you can imagine lots of really cool features like because I think that is actually safer than looking down at a nav screen.
John:
Like to see the little arrow in your little picture of your car going.
John:
If you could just continue to look out the window and it just looked like a little red line was painted on the road turning to the right.
John:
That's safer.
John:
And I think that is definitely coming.
John:
If that comes from your glasses, though, chances are good.
John:
Even if you have like a driving mode and if the glasses have to be certified by like the Highway Association, like it's so much safer when it's built into the car.
John:
A, because car technology moves so slowly that they're super conservative.
John:
Everything sucks there anyway.
John:
And B, if it's built into the car, the car maker is extremely motivated to make sure that you can't read text on it.
John:
right like the car the car maker could not ship that and like yeah and they're they're more liable with that kind of stuff like like you could you could plausibly sue the car maker for designing a very distracting system a lot more easily than you could sue google for making uh you know right because it's built into the car google is going to say you shouldn't have been doing that while you're driving but you're like if it's built into the car you're going to say but you put it in the car exactly and that's why that that's why you can't enter the address when you're moving because the car makers like if we allow them to do this they will they'll crash and they'll sue us
Casey:
For what it's worth, I can actually read text messages on my iDrive in my BMW.
John:
Like on the screen?
John:
Mm-hmm.
John:
Well, you should crash into something and steal a BMW and get a better car.
Casey:
I just wanted to point that out real quick.
Casey:
I'm sorry, Marco.
Casey:
Go ahead.
Marco:
All right.
Marco:
So part of my position on this was a pretty severe condemnation saying like if Google is actively lobbying for something that I believe is pretty clearly very unsafe for driving –
Marco:
And car accidents are no joke.
Marco:
Like, it's a really... Car accidents are a serious problem.
Marco:
So many people get injured or die in car accidents.
Marco:
And for the most part... And, you know, things that we pay a lot of attention to, like plane crashes and terrorism...
Marco:
that ends up killing way fewer people than car crashes.
Marco:
Car crashes are a big problem.
Marco:
It's a really big deal.
Marco:
And car safety should really be taken very, very seriously and not at all lightly and not at all recklessly.
Marco:
And so for Google to actively lobby against
Marco:
car safety, basically, to actively lobby for their own self-interest in a way that's pretty clearly unsafe in general use for cars.
Marco:
People are probably going to die as a result of that.
Marco:
And if Google Glass becomes really popular...
Marco:
Which, you know, it probably won't, in all honesty.
Marco:
But suppose it does.
Marco:
Imagine how big of a problem that would be and how many people might unnecessarily die because Google fought safety legislation.
Marco:
That's serious.
Marco:
That's not a joking matter at all.
Marco:
So a lot of people said, well...
Marco:
Isn't Apple at fault for people texting while using their phones and crashing?
Marco:
And no, that's a completely different situation because Apple has not, to my knowledge, actively fought against anti-texting laws.
Marco:
And if they have, let me know.
Marco:
I would love to know that.
Marco:
But that is not at all the same thing, and it's not comparable.
Marco:
Obviously, manufacturers on both sides of this weirdly political debate, manufacturers on both sides can potentially do more to prevent people from using their phones while driving.
Marco:
Now you can think, okay, well, Apple has this new M7 processor that can supposedly detect when you're in a car...
Marco:
It probably can't detect whether you're driving or a passenger, but it could detect whether you're in a car, maybe show some kind of warning or something.
Marco:
There are things they could do, but they're not actively fighting against safety legislation.
Marco:
And that, I think, puts a very different type of action on it.
Marco:
What Google is doing, I think, is actively harmful, whereas the inability to...
Marco:
to try to prevent people from texting in a car is, you know, like inaction is not as bad as like actively harming safety actions, I think.
John:
Well, Google's also in the position to potentially bring the largest safety increase in car transportation ever, which was through their self-driving cars, assuming that continues the pace and does not fade away and they continue to be successful with it.
John:
I'm not saying that balances out.
John:
Therefore, you're allowed to do something that's going to kill more people now.
John:
That's a bad idea.
John:
But historically speaking, if history goes out, everyone will forget that briefly they killed a bunch of people with Google Glass.
John:
I think what they're thinking is in the Google Glass is –
John:
They also believe that augmented reality is the future.
John:
Just look at that crazy whatever that was, the phone thing that maps out the runes and everything.
John:
The tech for doing that augmented reality stuff is getting better and better all the time.
John:
It's going to be everywhere.
John:
And Google was like, if we wait for the car makers to do this, it will take forever to get here and it will be crappy.
John:
And all of that is true, but I think they just have to...
John:
the alternative is they should either make their own car with this built in hey buy tesla go nuts like have a go at it but trying to put it into a general purpose computing device that you wear in your face a you have to get everyone to wear that stuff in your face and b like they would have they would have to sign up for all of the sort of liability type concerns that the car makers do uh in terms of regulation and everything and like they're not prepared to do that they want they want the freedom to do whatever the hell they want and
John:
Just don't bother us because eventually we're going to get to this awesome algorithm reality that's coming eventually anyway, and we're going to get there first because we can move faster.
John:
But that's playing a little bit fast and loose with people's lives, I agree.
Marco:
And that also seems like almost a childish and naive...
Marco:
That's Google for you.
John:
Exactly.
John:
Exactly.
John:
That's the problem.
John:
It's like... Well, that's what we love about... That's what I love about Google.
John:
Like, the self-driving cars is the same type of thing.
John:
That's what we love about it, but at the same time, it gets them into that.
John:
Like, that's why I always think of Google's corporate mindset not as evil, more as like...
John:
uh naive hacker type of you know like denizen of reddit like technology is cool we can do cool things with technology and let's just go do that cool things because it's cool and let's not think too much about the consequences or whether it will make money or anything like that you know that's what we love both love and hate about google all right titles go to fail how's the title not go to fail someone put it in all caps this isn't basic
Marco:
Haven't you seen the code?
John:
Oh yeah, that's one point we didn't address about the GoTo thing that I wanted to address.
John:
All the people who have never seen a C program or a Unix C program were like, GoTo?
John:
Who uses that?
John:
If you are a C programmer and you've come from the old... Just look at the source code, your favorite units.
John:
Look at BSD, look at Linux or whatever.
John:
You'll find GoTo everywhere because they didn't really have exceptions.
John:
And the control flow necessary with lots of nested ifs to get you out of an if, you end up having to make like flag variables and really contorted logic.
John:
GoTo is actually the cleanest solution in those situations where you want to get out of the normal flow of the program and go down to it, you know, or you could do a set jump or whatever you want.
John:
But GoTo is the idiom that, believe it or not, I know the only thing you've heard about programming is that GoTo is evil because there's a paper that you've never read that got passed around the internet 10 years ago.
John:
but look at any real c source code and goto is there and it's used for exactly this purpose and it has all these same problems and this is not what the paper about goto was against really but you can see goto does contribute to this anti-pattern but you know that's why uh newer better languages have exceptions
Marco:
yeah and you know and like the go to is like there's things like break and continue in a loop that i would argue break and continue uh especially break like that's really not a whole lot cleaner than go to like if you think about it like it's what but you need like if you have like very contorted logically you have a condition and then a condition and a condition and you want to break all the way out of it then you even break doesn't save you then you just end up with flag variables and it makes the code incomprehensible
Marco:
The people who read up the function a little bit and saw the type of the variable, OS status, pretty sure if you knew what that was, you were not surprised to see the go-to.
Marco:
I think that's like if you've been around old C APIs long enough, you've probably seen that.
Marco:
And it's a typical thing where it's like you call a bunch of API calls, and if they return zero, everything's cool.
Marco:
And if they return non-zero, something bad happened.
Marco:
And so if you want to do this eight-step process where you have to call these eight different API functions, and you have to have error checking code around every single one of them and say, if any of these return non-zero, fail.
Marco:
That's what this was.
Marco:
That's exactly what this was.
Marco:
And fail, in this case, the fail label didn't mean it has failed.
Marco:
The fail label was the destination of where to jump to if it had failed, which is basically go to the end.
Marco:
Go to the end of this logic block.
Marco:
That's what it was.
John:
That's another Objective-C thing that we could have talked about in the Copeland 2010 show is that, you know, it's the convention in basically COCO, not so much Objective-C, but COCO to not use exceptions for control flow.
John:
Is that correct?
John:
Yeah.
Marco:
Yeah.
Marco:
I mean, except, like, in Objective-C, objections, like, are by, like, policy and...
Marco:
and the API norm, exceptions are not meant to happen in running code most of the time.
Marco:
It's not meant to be control flows.
Marco:
You're probably not meant to catch an exception in Objective-C.
John:
Right.
John:
And it's not so much a language feature as it is an API convention, but still, that type of thing leads you to these... The tedium of...
John:
you know, right param error conditions, you know, where you pass an address to some error thing that's going to be filled out, or return values where it's some status, whether it's OS status or any other type of thing.
John:
That type of thing is seen as slightly barbaric in languages that do allow you to use exceptions, do expect you to use exceptions for flow control.
John:
And then, of course, there's the pathological case of like, you know, check exceptions and all the Java crap.
John:
And like, it can go too far in the other direction as well.
John:
But
John:
I would put that on the list of things that Objective-C that other languages do differently that people find cumbersome and tedious and error-prone and lead to these type of situations where you find yourself needing a go-to.
Marco:
As far as I know, in my Objective-C code I've written so far, Instapaper, Bugshot, The Magazine, and Overcast, I don't think I've ever written a try-catch block.
Marco:
I think I've always made exceptions blow up the whole thing.
John:
Yeah, because in Cocoa, exception is supposed to be exceptional.
John:
My understanding of the policy is that it's not for control flow.
John:
It's not just get me out of this nested block.
John:
It's like something has gone wrong, and maybe you can put up a dialogue and exit your app or do something like that, but you're not supposed to use it as a form of flow control, even though I assume you can if you wanted to.
Marco:
It's more like an assertion failure in Objective-C.
Marco:
That's how you're more supposed to use it.
Marco:
In fact, I think assertion failures might even throw exceptions.
Marco:
I don't remember exactly, but anyway.
Casey:
All right, titles.
Casey:
Go to fail is obvious.
Casey:
I'm not against it.
John:
A lot of podcasts, I think, are going to have that title this week, though, so we might want to avoid it so we can be cool.
John:
So we can be cool.
John:
I added ish.
John:
Everything is relative.