036 iPhreaks Show – Other Languages

00:00
Download MP3

Panel Jaim Zuber (twitter Sharp Five Software) Pete Hodgson (twitter github blog) Ben Scheirman (twitter github blog NSSreencast) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Discussion 00:59 - Language Backgrounds 05:23 - Other Languages vs Objective-C Static Typing Go LINQ Semicolons First-Class Functions 18:46 - Benefits of Using Objective-C RubyMotion 25:44 - Building Apps Not Using Objective-C 29:36 - Xamarin 33:03 - Calatrava 33:39 - Appcelerator Titanium 38:01 - PhoneGap Picks Get an HD Antenna (Ben) FizzBuzzEnterpriseEdition (Jaim) Forecast (Pete) Stranger in a Strange Land by Robert A. Heinlein (Pete) MadTree Identity Crisis: A Black IPA from Cincinnati (Pete) The Walking Dead (Chuck) Duct Tape Marketing Revised & Updated: The World's Most Practical Small Business Marketing Guide by John Jantsch (Chuck) Next Week MVC Transcript CHUCK:  Hey everybody and welcome to episode 36 of the iPhreaks Show. This week on our panel, we have Jaim Zuber. JAIM:  Hello from Minneapolis. CHUCK:  Pete Hodgson. PETE:  Hello from San Francisco. CHUCK:  Ben Scheirman’s going to be joining us in a few. This is a weird Christmas episode that we’re recording a little bit early. I’m Charles Max Wood from DevChat.tv and I just want to announce really quickly that if you go to RailsRampUp.com and you sign up before the end of the year, the 31st basically, actually I’m going to give you a few extra days. If you sign up by the 4th, then you can get 30 percent off if you want to learn Ruby on Rails, which is a handy thing for backend stuff. Anyway, this week we’re going to talk about some of the differences between some of our language backgrounds that we have. Some of us come from more enterprise languages like .NET or Java and some of us come from the hippie languages like Ruby, so should be an interesting discussion. JAIM:  I think so. CHUCK:  So real quickly, besides Objective-C, what are your languages that come out of your tool bag when you need to do something different? JAIM:  Well for a long time, I did C# and .NET. Even before that, it was C and C++, embedded stuff, thick client stuff. So I can write C in any language, pretty much. [Chuckles] But things that I like with Objective-C is I’m getting more familiar with how a dynamic language really helps us out, especially with testing and being able to be more fluid with our development. So I like that. But I definitely do come from a static language background. I don’t know. What about you guys? PETE:  So I guess I’ve been all over the place. I started off my career in C++. So when I first started doing iOS development, that actually felt quite familiar in some ways, doing manual memory management and all that fun stuff. And then I bounced around a bunch. I did some C#. I did a fair amount of Ruby. I still do quite a lot of Ruby. I do a lot of JavaScript. I do my current project, I’m writing Scala. I’m doing embedded C++ development in my spare time at the moment with Arduinos. So I guess I’ve been all over the place. But my main, my language I reach for the most is probably Ruby, still. And yeah, it’s interesting. I guess I’ve come to my journey into Objective-C is the opposite where I’m coming more from a dynamic place and seeing how it’s actually quite nice to have a type system sometimes, or have a static type system sometimes, and annoying as well. CHUCK:  Very nice. BEN:  It was a good fight we have right now. [Laughter] PETE:  You know what? If you ever want to play with a strong type system, do some Scala development and you’ll either fall in love with type safety or you’ll absolutely hate it. It’s been driving me a little bit crazy but it’s also pretty cool. But anyway, that’s I guess a different podcast. CHUCK:  Yeah. My background, I did Java and C++ in college but didn’t really take it seriously.

Transcript

CHUCK:  Hey everybody and welcome to episode 36 of the iPhreaks Show. This week on our panel, we have Jaim Zuber. JAIM:  Hello from Minneapolis. CHUCK:  Pete Hodgson. PETE:  Hello from San Francisco. CHUCK:  Ben Scheirman’s going to be joining us in a few. This is a weird Christmas episode that we’re recording a little bit early. I’m Charles Max Wood from DevChat.tv and I just want to announce really quickly that if you go to RailsRampUp.com and you sign up before the end of the year, the 31st basically, actually I’m going to give you a few extra days. If you sign up by the 4th, then you can get 30 percent off if you want to learn Ruby on Rails, which is a handy thing for backend stuff. Anyway, this week we’re going to talk about some of the differences between some of our language backgrounds that we have. Some of us come from more enterprise languages like .NET or Java and some of us come from the hippie languages like Ruby, so should be an interesting discussion. JAIM:  I think so. CHUCK:  So real quickly, besides Objective-C, what are your languages that come out of your tool bag when you need to do something different? JAIM:  Well for a long time, I did C# and .NET. Even before that, it was C and C++, embedded stuff, thick client stuff. So I can write C in any language, pretty much. [Chuckles] But things that I like with Objective-C is I’m getting more familiar with how a dynamic language really helps us out, especially with testing and being able to be more fluid with our development. So I like that. But I definitely do come from a static language background. I don’t know. What about you guys? PETE:  So I guess I’ve been all over the place. I started off my career in C++. So when I first started doing iOS development, that actually felt quite familiar in some ways, doing manual memory management and all that fun stuff. And then I bounced around a bunch. I did some C#. I did a fair amount of Ruby. I still do quite a lot of Ruby. I do a lot of JavaScript. I do my current project, I’m writing Scala. I’m doing embedded C++ development in my spare time at the moment with Arduinos. So I guess I’ve been all over the place. But my main, my language I reach for the most is probably Ruby, still. And yeah, it’s interesting. I guess I’ve come to my journey into Objective-C is the opposite where I’m coming more from a dynamic place and seeing how it’s actually quite nice to have a type system sometimes, or have a static type system sometimes, and annoying as well. CHUCK:  Very nice. BEN:  It was a good fight we have right now. [Laughter] PETE:  You know what? If you ever want to play with a strong type system, do some Scala development and you’ll either fall in love with type safety or you’ll absolutely hate it. It’s been driving me a little bit crazy but it’s also pretty cool. But anyway, that’s I guess a different podcast. CHUCK:  Yeah. My background, I did Java and C++ in college but didn’t really take it seriously. I was a systems administrator for a long time and actually wrote a pretty extensive backup, or not backup, system update management system, cobbled together mostly with bash. And so I’ve done a fair bit of bash programming. And then I moved into tech support and I ran tech support stuff. So I was programming management. And then I realized that I liked programming more than I liked management. So by then, I had picked up Ruby and that’s been my mainstay for the last six or seven years. And then I’ve been learning Objective-C and obviously I do a bunch of stuff with JavaScript. And then I’m looking to do a few other languages. I’m starting to get interested in things like Erlang or Elixir. But I haven’t really played with them enough to speak intelligently about how they work. PETE:  My commiserations for your bash programming. CHUCK:  Yeah. PETE:  [Chuckles] That’s not something I would ever want to do. CHUCK:  It’s definitely an interesting approach. And I think of it as a high-level language but the problem is that most high-level languages tend to name things and set things up so that you can actually look at them and guess at what they do. And bash really isn’t that way. You have to understand what the commands are and how to determine what all of it is. And I spent a lot of time on Google. PETE:  Yeah. CHUCK:  If this directory exists, and then it’s if -d directory name or something. Anyway, and the syntax is a little bit funny too. So it really gets interesting pretty fast. But the other thing that’s interesting about it is that it’s mostly procedural stuff that you’re doing. So you’re really not approaching things from object-oriented or really a functional way of doing things. You can write functions. But they’re really not treated as first-class citizens. You’re calling them or you’re not and that’s about it. BEN:  You must have some pretty awesome post-build scripts. I’d like to see them. CHUCK:  [Laughs] Post-build scripts for what? BEN:  For iOS or whatever you’re doing. CHUCK:  Not really. BEN:  Okay. CHUCK:  I don’t do much bash programming these days. Though I have gotten into Chef, which is managed mostly again in Ruby. But yeah, you do get some arcane bash stuff going on in there too, just depending on what you got to get done. BEN:  Right on. PETE:  So, I’m interested to hear what you guys miss from those other languages when you’re in Objective-C. Chuck, what do you miss from Ruby when you’re doing iOS development? CHUCK:  So, the strong-typing typed systems where everything returns a specific kind of value and things like that, I miss a lot of the flexibility you get out of Ruby. In Ruby you don’t have to go and declare your methods in your header files. You don’t have to go and do a lot of this other boilerplate stuff. You can just, “Oh I want that,” and then you just make it happen. And I understand why it’s that way with Objective-C being an extension of C. I guess I should have mentioned I was a computer engineering major in college, so I also wrote a fair bit of C. And to be honest, Java was okay, C++ was painful, and I loved writing in C, which is weird for most people. [Chuckles] CHUCK:  But you know, Assembly was fun to write and hell to debug. But yeah, so I understand why it’s there. But at the same time, I miss being able to just on the fly go, “new method or new object” and not have to think about, “Okay, did I go and declare this all the right way somewhere else so that something else knows that this is part of the interface that I’m implementing?” Does that make sense? PETE:  It does make sense. But I guess that the argument that static typing fans would make maybe is that you get a lot of, the flipside of that is you get the kind of benefits of knowing what are the types that your method takes and your method returns. A, I guess you don’t need to write so many tests maybe because the compiler is checking more stuff for you. Have you noticed that? That you find less runtime errors in your code and more compile errors in your code. Because I’ve definitely, that’s something I really like about a more static typing system like Objective-C, is that you can just hit build and see what breaks. Like if you want to rename something, you can just rename it, hit build, and the compiler or the static analyzer can do a lot of the work that otherwise you’d have to do with tests in a language like Ruby or JavaScript. CHUCK:  Yeah, I was going to point out that for the most part I just write tests around things so if I’m expecting something to be a certain type, I’ll just write a test on it. That being said, yeah I have to do that manually. The benefits that you’re talking about though with the static typing, I tend to see a little bit more as a benefit of having a compiled language. And so your compiler when it does the static analysis and compiles it, when it compiles it, it basically has to pass a syntax check and it has to pass a certain level of sanity checks. And so since those are all built into the process of building, you get the benefit because it has to do all of that upfront. And so, you get that check just like you get the check when you write the tests in Ruby. The difference is that a lot of those tests are just built in because the compiler does that job for you. And so I don’t know if it’s statically typed languages as much as it is just that you have that step where you get a major sanity check right upfront because it won’t build if it’s not right. JAIM:  Yeah, you get all the uninteresting stuff thrown in for free. If that actually works or not, that’s not tested. But you get a lot of stuff thrown in for free but it’s not really the critical stuff. CHUCK:  Yeah, but at the same time, that’s really the stuff that you don’t want to think about and so to that end, it’s really nice. Is this giving me back what I expect? Well it has to because if it’s not then I’m going to get an error when I try and compile it or build it. Is it behaving in a specific way? Yes. Some of that, you get out of the compiler and some of that you don’t. So it’s that tradeoff. So it is a nice thing to have. It’s just I’m not completely sold that static typing is why that works out so nicely. PETE:  I think the two go hand in hand. You need static typing for the compiler to do its thing. And because you have the compiler doing that thing, that’s the point which the type system, the types get checked. Essentially, the type checking either gets done at compile time or at runtime. I don’t know if there’s any languages really, that do that much runtime type checking. I guess I think we’re in agreement. Just I’m looking at it in terms of the type checker and you’re looking at it in terms of the compilation. But I think they’re both pretty much the same thing. CHUCK:  Yeah, they’re both part of the same process. So, it just comes down to what you value. And I know a lot of people who, they take a look at a language like Ruby or JavaScript or Python or some of these other languages where you really don’t enforce type very often and it freaks them out. PETE:  It does take a while to get used to that. CHUCK:  Yeah, I can definitely understand where you get used to being able to just count on something having a specific set of behaviors, in other words being a specific type. It definitely makes sense. Are there any languages that are not statically typed that are compiled? PETE:  Yeah, I’m wondering. Well, I guess Go is kind of like that. It has inferred types I guess where you don’t give something a type. It has a bunch of methods that it implements. And when you define a method, you say, and this is me not having actually done that much Go development so if you actually know what you’re talking about, please forgive me. But with Go you say what interfaces your method’s going to take. Let’s say your method’s going to take a user object and a bank account object. You define two protocols that implement those two interfaces, if you will. And then when you’re actually implementing those classes, you don’t have to say, “Oh, I implement the user protocol,” or, “I implement the account protocol.” Go when it compiles actually just looks at your class and says, “Okay, you implement these four methods so therefore implicitly you implement that interface. So you can plug in here.” So, it’s still done statically at compile time but you don’t have to do as much explicit type decoration stuff where you say, “I am implementing the user protocol.” That’s the only one I can think of that’s more dynamic in that regard. BEN:  One question about that, and you might know, so what if you partially implement one of the classes or interfaces and try and use it. Do you get a compile error? PETE:  Yeah. BEN:  Okay. PETE:  Yeah, or it just says you can’t use, this object that you’re trying to pass in doesn’t implement this protocol or the equivalent words in Go [inaudible]. This thing doesn’t implement this protocol so you can’t pass it in here. So you still have that static analysis where it can check the types at compile time and say this thing does implement it or it doesn’t. So everything does have a static type but you don’t have to do as much explicit work. It’s a bit like how in C#, now there’s type inference where you don’t have to say foo foo = new foo. You just say var foo = new foo and it knows what type the thing is. It’s kind of the same thing but what protocol you implement. BEN:  Okay. Syntactic sugar, a little bit. PETE:  Yeah. And it is nice because it gives you a little bit of that flavor of Ruby where you don’t have to think about, like Chuck said, you don’t have to think about what interfaces you’re implementing. If it quacks like a duck, it’s a duck kind of thing, but actually statically checks [throughout] and you having to write a test that says, “Does it quack like a duck?” CHUCK:  Yeah, exactly. So in Ruby, you do have modules which you can think of sort of like protocols except that there’s no checking to make sure that it implements the protocol. And so you can actually go in and manually implement every method that you need to have that protocol and it still counts. And in Objective-C and some of these other languages, if you bring in a protocol, you implement some common interface between different types of objects, then it will actually check and say, “Did you explicitly include this protocol into your class?” And if you didn’t, then it does not implement that protocol even if it does behave like that protocol. And it makes sense. I do like that approach where it does have that built-in check. But sometimes it’s nice to have the flexibility to be able to just work around it and partially implement. PETE:  What about you Jaim? What’s your take coming from the other side? What do you miss from C# or from other static languages? JAIM:  Alright, so initially I missed properties and things like that, which Objective-C has caught up in the past few years or so. So it’s gotten a lot more familiar for people coming from an OO background dealing with properties and things like that. I think one of the things I miss is some of the language support. I did a lot of C# and C# has things like LINQ which is Language Integrated Query where you can do more a functional style of programming. So that’s one thing I really miss. And I realize there are some Objective-C libraries that do certain things and that’s available in Ruby, that type of thing being able to query over a set of objects. So I missed a little bit of the language features that I got in C#. But other than that, I like the features that I got from being able to test a dynamic language. I think if you try to write tests for C# or Java and you want to test something in the framework to make sure that’s interacting correctly, you end up having to do all these really  convoluted injection things where you wrap every framework element in some kind of class just so you can test it. And you inject their framework element, like a date. So I really enjoyed being able to just stub out things like a date, like date now or something, [notification]. So that’s something that I’ve really enjoyed learning coming into Objective-C is just being able to test code without doing all these convoluted tricks to get decent test coverage if I’m using framework elements. That’s what I learned. PETE:  I guess you get some of the LINQ type stuff now. Well, you can fake out some of the niceties of things like LINQ with blocks. But I think you end up, I don’t know. It doesn’t feel as easy to do. It doesn’t seem as fluid as using lambdas in LINQ or in a functional language or in JavaScript for example. JAIM:  Yeah, blocks are definitely more bulky than the C# version, the anonymous functions. But it’s a step forward. PETE:  They [inaudible] a bit of a leaky abstraction to me. You have to know under the covers. It’s like passing around references to things and you have to remember, “Oh is this supposed to be a strong reference or a weak reference and do I need to put [inaudible] there or not?” JAIM:  Do I have to nil this out if I’m done with it? Do I [inaudible] being hit? Yeah, you get into some weird edge cases on iOS that you don’t have to deal with as much in .NET. But overall, I’m glad they’re there. PETE:  What about Chuck? Is there stuff from JavaScript that you miss? Or is it more of the same kind of stuff as Ruby? CHUCK:  So it’s interesting. Between Ruby and JavaScript, I think the thing that throws me off the most often is semicolons. [Chuckles] And the nice thing is that.. PETE:  Hang on a second. You don’t use semicolons in JavaScript, Chuck? CHUCK:  Oh, I don’t use semicolons in Ruby. PETE:  Oh, okay. BEN:  But you can. You can write all your Ruby on one line. CHUCK:  That’s right. If you use a semicolon in Ruby and you don’t put another command after it, it complains at you. So in JavaScript, it does do the semicolon insertion. But it seems like I always find the cases where it screws it up. So I’ve gotten better about putting it in. I just switch my brain into JavaScript mode. But yeah, so JavaScript to Objective-C, I don’t know. They’re so different. JavaScript’s a prototypal based language and Objective-C is mostly object-oriented. It does have some functional aspects to it and so does JavaScript, but I don’t know. It doesn’t really, I don’t know. The two of them, comparing them, it just doesn’t make a ton of sense to me because they’re so different in the way that they approach so many things where the way that I approach thing in Objective-C I approach the same way in Ruby in a lot of cases. PETE:  I think for me, the main thing that, I guess I’m just restating. So unsurprisingly, I’m restating what I just said because it’s what made me think of the first-class functions, the fact that with JavaScript it’s really ridiculously easy to just create an anonymous function and pass it around. And if you compare that to blocks in Objective-C, then it’s really like night and day. And I guess part of that is because you’ve got a garbage collected language in JavaScript or something like that whereas in Objective-C, although it feels a lot of the time like you’re not doing memory management, you still have to be aware of the memory management. CHUCK:  Yeah, that’s definitely one thing I had to get used to when I first started playing with Objective-C. It was when ARC was real new and people didn’t trust it. So yeah, retain and release and all that fun stuff. PETE:  So one of the things that I really like about Objective-C, coming from the dynamic world of Ruby and JavaScript is having an IDE that actually knows what’s happening and being able to command click on things and actually go to the definition of the methods, and things like that. I get incredibly frustrated at how poor Xcode is at doing things like refactoring given that it does know so much about the types and what things are involved. But that ability to command click on things and go to the declaration or find usages and things like that, I think is really, really nice. And that’s the thing I miss a lot when I go from Objective-C to doing Ruby development or JavaScript development. CHUCK:  Yeah. BEN:  You know, what I find interesting is doing RubyMotion. You’re running through a UIKit but with a different flavor. So it seems like it would be a lot less code. It turns out it’s not. It’s not a lot less code. It’s slightly different syntax and sometimes more [favorable] syntax. But when you’re dealing with asynchronous code, you have the same problem with lots of callbacks and things like that. I feel like some of the beauty gets lost. Like when you’re doing a Rails app, a lot of times, you’re just in a web request and you’re going to go get some data from a database. You’re going to format it this way and render a template. And that’s all just line, line, line, and it’s all procedural. There’s no async code that you really have to worry about there, which I find to be liberating. It’s nice to write code like that. And then you go a smart device that has a main thread that’s painting the UI for you, you can’t interrupt that. So pretty much everything you do has to be on a background thread. So you end up doing a lot of the block callbacks or the delegate methods. PETE:  That sounds like JavaScript development actually. BEN:  It does, yeah. PETE:  I wonder if part of that is because people haven’t quite wrapped up the APIs nicely yet. BEN:  I don’t know. I have mixed feelings with that. On one hand, you have things like BubbleWrap and they’re pretty well-designed and handy for a lot of applications. But it ends up looking like a different thing. It might feel more like Ruby, but it feels less like UIKit. And so there’s a spectrum. On the left side, you’re just dealing with UIKit and all the UIKit classes but in Ruby and on the right hand side, you’ve abstracted everything so it doesn’t even look like UIKit anymore. And I think there are drawbacks to making everything, abstracting away UIKit because there’s a whole lot of power there. And if you just create wrappers for everything to make it easier, I don’t know. You could lose out on some of the powerful stuff underneath. CHUCK:  Yeah, one of the things that I really like about some of the wrappers that you get around some of the libraries out there is that if you’re just working the 80 to 90 percent case, it works great and then you don’t even have to think about a lot of that other stuff. And then when you have to drop into, “Okay well I’m in that 10 to 20 percent of stuff that really doesn’t fit the assumptions that this library is making,” then you can drop down into UIKit or something else and take advantage of it. PETE:  That’s as long as the abstraction you’re using or the higher-level thing you’re using hasn’t welded the hood shut so that you can’t get under there when you need to. CHUCK:  I guess that’s true. PETE:  But I think that’s more a property of what library you’re using or what abstraction you’re using rather than a fundamental problem. I’ve used some high-level frameworks that let you get down into the guts when you need to. Actually, I think the UIKit frameworks do a pretty good job of that. Like for core animation for example, I’ve also used some systems where you get that 80 percent done and then you’re like, “Okay now all I need to do is this one last little piece,” and you slam into the glass ceiling where you can’t do that last piece without rewriting the 80 percent that seemed so easy to do using the abstraction. JAIM:  That’s like the primrose path of [inaudible] of all the cross-platform frameworks. First 78 percent, it’s easy. [Chuckles] JAIM:  And the last 30 percent, 20 percent, very hard. CHUCK:  Say that five times fast, the primrose path [inaudible]. JAIM:  I’m surprised you got it out there. That was pretty good. BEN:  [inaudible] You know, I was going through a bunch of old videos that I have on my Mac. And I came across an old presentation I gave. We used to have this Houston geek dinner and we’d head to a good pizza place and have some beer and just talk shop. And that was around the time when I got into iOS development. This was probably 2009. Yeah, this was 2009. So it was Xcode 3 and I was watching myself type. And Xcode 3 was way more responsive than Xcode 4 was. I was running on an old 13-inch MacBook Pro, not a powerful device at all. And just watching myself type, it made me nostalgic for Xcode 3. Even though Xcode 4 brings a lot of cool stuff, it has certainly gotten a little bit clunky and soft around the middle as it gains in features. Have you guys noticed that or is it just the boiled frog phenomenon? PETE:  I think it’s both. So I’ve noticed the same thing with my, geez what type of iPhone is this? Why don’t they put the number of the iPhone? [Laughter] PETE:  The non-tall iPhone. I have the most… BEN:  iPhone 4S? PETE:  Yeah, probably one of those guys. And on iOS 7, it is noticeably a little bit laggy and I think that’s just because they’re expecting, they’re designing for, taking Moore’s Law, leveraging Moore’s Law and assuming that most people are going to be on newer hardware fairly soon. So, let’s write the software assuming there’s newer hardware. JAIM:  Yeah, even iOS 6. I had an iPhone 4 for a long time. iOS 6 was still a little bit laggy. I didn’t upgrade to iOS 7. I waited until the 5S came out and jumped on that. But that’s definitely how it goes. PETE:  I remember doing iOS development for, it must have been, when did the iPad first come out? Was that iOS 4? CHUCK:  I think so. I know that it’s stuck on iOS 5 now. PETE:  It was around that time BEN:  The iPad came out and they created a new version just for that. It was 3.2. PETE:  3.2, that’s right. So, I remember doing development in that era and we had to test it against an original iPhone or an iPhone 2 or something. And that thing just [sucked]. It was horrible to use, horrible, horrible to use. Just with iOS 3.2 and the oldest hardware that it would run on, it was just not an enjoyable experience to use that device. CHUCK:  So back to other languages, have you guys built any apps using languages other than Objective-C? I know that Ben, it sounds like you’ve done some stuff with RubyMotion. I have a license for RubyMotion, but I haven’t actually done anything with it yet. BEN:  Yeah, my license was just more for me to play around with just to see if it is something I should investigate further. I’ve probably mentioned this on the show before that I have a background in .NET and I like Ruby. And so when I came to Objective-C, I was fully planning on just ditching the language for MonoTouch. And if RubyMotion had been out at the time, I would have probably heavily considered that because I didn’t like the language at first. And over time, call it Stockholm syndrome or call it just my own maturity, [chuckles] I don’t know. Eventually, I just started to like Objective-C. And it’s wordy, but being wordy can pay off in very readable method names, very descriptive almost documentation-like method names. So I just decided I don’t need to ditch Objective-C. I kind of like it. And I also like that being on the blessed path has its benefits. CHUCK:  I do have to say, that was one other thing that coming from a language like Ruby or some of the other languages that I work in. Yeah, just the way that you define method names and you intersperse the arguments with them and all that. PETE:  Yeah. CHUCK:  That totally threw me for a loop. I was like, “Where do they get this stuff?” PETE:  It totally threw me and I really disliked that. CHUCK:  Yeah, I didn’t like it for a long time. And then after a while it was like, “You know if I write these names right, they really do tell me exactly what I’m doing here.” [Chuckles] JAIM:  Yeah. It almost reads like a sentence. PETE:  [Inaudible] like a classic thing. That was absolutely the thing that I really disliked and I vividly remember on that first iOS project that I was on whining to people about how silly this feature was. And now I really miss it in every other language I use. I really kind of almost wish all languages had that thing because it really annoys me otherwise. What I like doing a lot in other languages is that Objective-C thing of saying login with username blah and password blah because it reads more like a sentence, right? But if you do that with Ruby or JavaScript or Scala or whatever, what you end up saying is login with username and then you put the username in and then when you add a second parameter, you’re like, “Oh now I have to say login and then half my methods say login with username,” or something like that. And then my other methods say login using whatever else, but you can’t. If there’s more than one parameter, you can’t have that nice with blah, with blah, and blah using yadda, yadda. Does that make any sense? CHUCK:  You can in Ruby 2. PETE:  Not really. CHUCK:  Ruby 2.0 has named parameters. PETE:  Oh, it does, right. Yeah, yeah. Is that the same then? Can you have that style? BEN:  Yeah. It looks very similar to how they do it today, with just option hashes at the end. PETE:  Yeah, it’s not the same. BEN:  But I like the notion that they can have defaults. And it’s a little bit, I guess I haven’t really seen it in practice, but from my understanding is it’s easier to read and understand what parameters should be passed rather than just taking a hash. CHUCK:  Yeah. And they’re named, the order I don’t believe is significant. So if you’re passing them in as named parameters, you could put them in whatever order you need to. So you can have login with username or login with username and password and you can set defaults for the username and password or you could just leave it off and handle when it’s nil and all of that stuff. It plays nicely. JAIM:  Maybe it’s because I did a lot of C++ back in the day, but I really fear default in parameters. [Laughter] JAIM:  I just remember getting myself into so many problems as the codebase aged a little bit. CHUCK:  Yeah, you got to be careful with them, that’s for sure. PETE:  So Ben, you haven’t done any, you said you played around with RubyMotion. Have you played around with Xamarin, the MonoTouch stuff, at all? BEN:  Yes. So if I don’t say so myself, I was a pretty badass .NET developer. [Laughter] PETE:  You did say so yourself. BEN:  No, I’m just kidding. I was actually okay. I knew C# pretty well. I’ll just say that. And then fast forward three, three and a half years, almost four years now that I haven’t been doing .NET. And I don’t know, maybe six months ago, I tried to just fire up the Xamarin. They came out with their own Xamarin studio so you don’t have to use MonoDevelop anymore. And it looks really nice. I thought I’d give it another go. And it turns out I really suck at .NET now. [Laughs] It was funny. The characters were not flowing from my fingertips the way I expected them to. So that muscle has certainly atrophied. [Chuckles] And one of those problems was, similar to what I mentioned a minute ago, the difference between web programming and async smart device programming. The async stuff in .NET was not necessarily familiar to me because it’s not what I did on a day to day basis. I did a little bit of it. And on top of that, with .NET 4 I think there’s the await keyword and the async keyword that lets you write code in a more procedural style. However, it’s more like futures. All that stuff is new to me because I left .NET before that happened. So it turns out, yes I did try to do it and I’m kind of terrible at it now. PETE:  [Chuckles] See, all that stuff is the stuff that makes me really interested in Xamarin as a platform, is that it seems those features, the await and generators and all that stuff and then the first-class (well not really first-class) functions but make it really easy to make lambdas and callbacks and stuff like that feels like it would lend itself quite nicely to Objective-C development. Well not Objective-C development, iOS development I guess. JAIM:  Yeah, that was one of the things I really liked because I think I cut my teeth on iOS development with MonoTouch a few years ago, when it was still MonoTouch. But yeah, just being able to fire off an anonymous function when blocks were still pretty new and having properties when Objective-C didn’t really support them, that was one of the benefits I found from it. But I think Objective-C has caught up in a lot of ways with properties and autosynthesis as far as letting you be productive and creating objects and improving your code that way. PETE:  I do think that they’ve addressed some of the things that made it really easy to make fun of Objective-C like the new object literal, or not really that new anymore, but the object literal so I don’t have to say [end this] array, array with objects and all that cruft, I think that’s really… BEN:  Yeah, those are great. PETE:  It’s less easy to make fun of Objective-C now. I think really, the only thing left is the ridiculous method names, but I think we actually all said that we quite like that. BEN:  I like it, but it’s impossible to do without code completion, right? PETE:  Yeah. BEN:  And I really like vim for Ruby but that’s because I’ve committed what I need to know from Ruby and Rails to memory and I know how to look up the rest. So I appreciate the fast typing and quick in and out I can use with vim, but I just can’t do it with Objective-C. I’ve tried. [Chuckles] PETE:  Yeah, me too. So Chuck, you asked if we’ve done development with other languages. I’ve got an outlier in that I’ve done a small amount of iOS development with JavaScript using this cross-platform framework called Calatrava. I think I talked about it quite a while ago on the show. And that lets you do the business logic, or the app logic in JavaScript but you can do the actual UI coding in Objective-C. So you don’t have that glass ceiling thing of you get the 80 percent done and then you can’t do the rest. So that’s an interesting one, but that’s a little bit of an exotic example. CHUCK:  Yeah, I have to say I did a little bit with Appcelerator Titanium. [Laughter] CHUCK:  It was kind of, I don’t know. And this was a while ago. I know that they’ve added a bunch of polish to it. I don’t want to bag on it at all. BEN:  Oh no, no, no. No, no, bag all you want. It’s fine. CHUCK:  [Laughs] PETE:  Between me, you, and Ben I think we’re going to be [bagging]. CHUCK:  But the issue that I had was that it felt like all the pieces were cobbled together. There wasn’t a cohesive way to just build stuff. I’ve talked to a few people and I think that story’s gotten better. I know that there are some limitations in the way that they approach it because most of your stuff just runs in a web view and you don’t get all of the native stuff. And they go for the lowest common denominator between the different platforms that they support. BEN:  So, my understanding is that it doesn’t necessarily run in a web view. So if you use the Ti.iPhone.NavigationBar or whatever it’s called, that it is actually going to render a real iOS navigation bar. But that’s not going to be cross-platform clearly, because it’s got iOS in the namespace. So there are things like that that will run natively. So you can really do native table view based applications in it, but the code is still interpreted through a web view and that’s a web view embedded in your app that doesn’t benefit from the Nitro JavaScript engine that’s available on Mobile Safari. So that’s one issue that your code is never going to be as fast as raw Objective-C code. And in many cases, that might not matter. PETE:  That’s true, but also I think that’s actually only half-true now. So yes it’s going to be JavaScript not Objective-C so that’s compiled versus interpreted. But I think JavaScript core is… BEN:  Without Nitro? Without Nitro, I think it’s… PETE:  No, I think JavaScript core now has Nitro. Because it used to be that you had to use a web view and you didn’t get the, what’s it called, the code rewriting. BEN:  Oh, okay. PETE:  But I think, I feel like JavaScript core now does that… BEN:  Yeah, so when I used this, this was in UI web views, which I still think doesn’t use Nitro. But I’m not sure about JavaScript core, which is probably [inaudible] where their architecture is heading. It makes sense, rather than have an invisible web view that you use just for data in and out. But yeah, I had similar problems. I looked for guidance on how to build a real application and I got a bunch of really horrible hello world type examples. CHUCK:  [Laughs] BEN:  And they didn’t teach me. They didn’t follow conventions that Apple has, certainly. But maybe I shouldn’t expect them to because it’s cross-platform. But it just didn’t seem to have a real direction at all. So I thought it would be nice, sort of breath of fresh air, to be able to use CoffeeScript. And there’s a Ti gem that has some stuff that you can basically run your build on rake and there’s some testing support built in. I thought that stuff would be really, really cool. But turns out it wasn’t that easy to get going and I had serious questions about how the architecture of a large app would be. So I don’t know. In the end, this was just a one day hackathon that we did internally just to spread our wings so to speak and understand what’s out there. And I came over with a very sour taste in my mouth about Titanium. CHUCK:  Yeah, I do want to point out, so we’re talking about basically it allows you to write your iPhone apps. It also does Android and I believe Blackberry. You write them in JavaScript. And so that’s the appeal if you’re already doing JavaScript for other things. PETE:  I think that you [can learn]. CHUCK:  And PhoneGap is also JavaScript incidentally. PETE:  But PhoneGap’s different because that’s not got that native aspect. It’s just wrapping web views in enough of a native shell so that you can access the hardware and you can access the platform, which is good if you want, I don’t know. I’ve heard of some folks at ThoughtWorks who like PhoneGap for rapid prototyping. So building a version, not even a version 1.0 of an app but version 0.1 of an app or something, and throwing it together quickly with HTML and JavaScript. And then putting it out there and seeing how people use it and then iterating from that. And they end up, it’s a throwaway prototype basically. You build on it quick and put it out there and see whether people like it or not and then if you want to double down on it, then actually build it for real using some other technology. CHUCK:  Yeah, I can see the value there where you would basically use it to quickly prototype something out, get a proof of concept. It’s a proof of concept you can run on your phone, which is also very nice. PETE:  Yeah. And it’s also, for people who are, there’s a lot more competent, well maybe I’ll [inaudible] that statement. There’s a lot more HTML than JavaScript devs than there are Objective-C devs. So for people who want to get into the iPhone or iPad world, it’s like a lower barrier to entry maybe and you can get your feet wet. And then once you feel a bit more comfortable with the mechanisms of building a mobile app versus a web app, then you can maybe start getting serious about it and learn using square braces. [Laughter] BEN:  I don’t know. I’d like to push back a little bit on that. I think that it’s a good sales pitch to say, “Oh we already know HTML. We already know JavaScript,” except you don’t know this HTML and JavaScript, right? This is not creating web pages. And a really distilled example of this is you should never use a click event. And you’re like, “Wait a minute. That’s how I wire up in JavaScript. I click for a button to do something.” And what you may not realize if you’re not in this world is that you put your finger down on the screen and a web view has to say, “Wait, wait, wait. Is this touch or is this a scroll? Is he trying to click it or is he going to move his finger?” And so there’s a 30 millisecond delay before it will actually deliver a click event. And this is why the majority of general web page style apps just don’t feel right. There are ways around this. You can use mouse down events or whatever. There may be some more newer concepts. PETE:  There’s touch down. BEN:  The touch down, okay. So there are newer concepts. But this is my point, is that it’s not web development. So just because we have that skillset doesn’t mean we’re going to hit the ground running. I think it’s going to be the opposite. I think it’s going to be a familiar language structure, all new style of programming. And perhaps [inaudible]. PETE:  Okay, so your take is it’s like a false trend because it feels like you’ve got the tools but actually if you use them, you’ll end up doing the wrong thing. BEN:  Yep. JAIM:  It’s the hidden cause you worry about that don’t seem obvious up front. BEN:  Yeah. And you look at these case studies where somebody has done just these amazing jobs at creating a really awesome HTML5 app. And those people are freaking experts, complete top of their field. You know what I mean? The specific examples I’m thinking of is the Facebook rewrote their app to be more native because it was slow. And the [inaudible] guys said, “Well no, it doesn’t have to be slow. We’ll create our own version of Facebook and we’ll make it really fast.” And those people are seriously experts in this technology. So just your average web developer isn’t going to necessarily have the skills to understand the problems and have viable workarounds in HTML and JavaScript. Like infinitely scrollable lists, for instance. You have an image tag on a table view row or what’s essentially a div, right? And you scroll it up. And eventually that image tag needs to release that image. But if it’s still part of the DOM, then it’s going to continue to retain memory for that referenced image. So literally, you have to know when to clear out the image source attribute so that it can release that image. And if you start rewriting the DOM, then your scroll position changes. And there are just lots of edge cases. I think this is a choice and people can make this choice. And I’m sure you can make great apps with it. But I feel like you need to master that set of constraints and understand all the workarounds. And I think that is an equal amount of effort than just learning the native way. That’s my position. [Chuckles] PETE:  I totally agree that getting that last bit of polish to make a web app look anything close to native is really, really hard, like way more work than just learning Objective-C. [Chuckles] I guess my take is that for someone that wants to just build a to-do list, they might get intimidated trying to figure out all of the stuff of how to build a mobile app and a new language and new technologies and new IDEs and the rest of it at the same time. So maybe they can start off with building only one half, learning the mobile, what makes a mobile app useful, the UX side of things using familiar technologies. And then once they’ve learned that stuff then they can do the other half, rather than having to learn in all at once. But I definitely very much agree with your point that you’re not going to, none of these technologies are some silver bullet where you can suddenly keep using all of your familiar tools and not have a Facebook equivalent, just having to fundamentally learn lots of stuff. CHUCK:  That’s honestly one thing I think is so funny about people who go to RubyMotion, is that yeah you get some of the niceties that you get from Ruby, from the language, if you’re more familiar with that than some of the quirks of Objective-C. Of course, you could see that the other way. Those people like the quirks of Ruby. Either way. The thing is that you still have to understand all of the APIs because it statically compiles against those other libraries and so you still have to make those calls against the same functions in order to make your app work. So yeah, you get a native app, but the shortcuts are all language shortcuts. They’re not library shortcuts. And so you still have to familiarize yourself with all of the APIs that are available to build an app. And there’s no shortcut for that. PETE:  Yeah. And learning an API that was built for the idioms of another language is really quite hard. It’s quite jarring to try and follow idiomatic Objective-C APIs in another language like Ruby because it’s just fundamentally, the patterns are different, and the way that you name things is different. There are all these tiny little differences that make you feel like you’re a stranger in a strange land. CHUCK:  Yeah. Alright. Well, we’re getting toward the end of our time so I’d like to stop here and do the picks. Ben, do you want to start us off with picks? BEN:  Sure. I just have one. A while back, I cancelled cable. In fact, I have just the, whatever the call the basic package where it gives you the local channels but delivered through your cable box. And I only have that to get internet, because they come as a package deal. So I think that only costs $10 a month. But they give you standard def channels and they look terrible. And my kids like to watch football, as do I occasionally. And so, I just picked up an HD antenna. I wish I had done this many years ago. [Chuckles] HD Antenna. And if you can get a good signal, they just have a ridiculously good picture. And they’re free. You just get to grab them out of the air. So, go pick up an HD antenna if you’re one of those cable cutters like me. JAIM:  So, which one did you actually get? BEN:  You know, I was looking for it in Amazon. I went to Best Buy because it was a thanksgiving thing and we had a bunch of people coming over and I wanted to have nice-looking football on the television. It’s one of the flat ones. And it tends to work best if I just go to the, if I were to dangle a rope from the ceiling and hang it behind my TV, just 10 feet in the air. [Chuckles] It doesn’t work well if I have it down low, like in a shelf or propped up against a window. So, whenever I get a new house, I’ll probably be mounting one of these on the roof to really get a good signal. But I would say stay away from the cheap ones because you’ll be able to get some channels and not all of the channels. It just depends on where you live and houses near you and stuff like that. So higher is better. But yeah, it was one of the flat high gain antennas. It was about 60 bucks. JAIM:  Okay. I tried doing that a few years ago and I could get one channel consistently and other ones were pretty bad. But I’ll try hanging it from the ceiling, see if my wife will like that. [Laughter] CHUCK:  Man, every time I try to talk to my wife about cutting the cable, it’s like, “Think of the children.” BEN:  You know, think of it like this, Chuck. Let’s just assume you pay $60 a month for cable. CHUCK:  Oh, you’re preaching to the choir here. I would love to cut the cable. BEN:  Okay. So, $60 a month is a seriously low estimate for cable, I think. CHUCK:  Yes. BEN:  I was talking to somebody at thanksgiving. They spend over $200 on internet and cable TV a month. And I was like, “What?” I don’t even, that doesn’t compute. So at $60, the seasons of shows on Apple TV cost about $30. So you could buy episodes of Downton Abbey and Dexter and Game of Thrones and just buy all the seasons. And you still won’t be amounting to $60 a month. CHUCK:  Yeah. We have to do that for the kids’ shows is what my wife worries about. BEN:  My kids are content with Netflix for the most part. CHUCK:  Yeah. And sometimes she puts on the Netflix shows. So I don’t know. Anyway. BEN:  Yeah. Do it. CHUCK:  I think it’s just convenient for her to just point the tuner at the channel and then just leave it for an hour or so. BEN:  Yeah. CHUCK:  But Netflix will play the next episode automatically. So I guess that’s not even an issue. Anyway, interesting conversation. That sounds really cool. Jaim, what are your picks? JAIM:  Okay. There’s a lot of talk on how to recession-proof your career. I’m going to tell you guys how to apocalypse-proof your career. CHUCK:  Shotguns. JAIM:  So, okay. [Laughter] JAIM:  After the apocalypse, programming’s going to be a little bit different than what we’re used to. There’s going to be no Ruby so Chuck you’re out of luck. Ben, if you think we’re going to be able to fall back in our .NET stuff, not going to be around. What is going to be around? Enterprise Java. But… CHUCK:  I’m going to cry. [Laughter] PETE:  Please don’t pick Enterprise Java. Please don’t pick Enterprise Java. Please don’t pick Enterprise. [Chuckles] JAIM:  I’m not picking Enterprise Java. We have to survive. So, competition for jobs is going to be fierce. So, what do we do for job interviews? CHUCK:  Shotguns? JAIM:  We always do Fizz-Buzz, right? So everyone just goes and does the Fizz-Buzz, writes on the wall board. But for Java, I’m going to tell you how you can ace your job interview and it’s called FizzBuzzEnterpriseEdition. So, you can take your Fizz-Buzz code. You think you can just do [inaudible]. BEN:  Does it have a [inaudible] factory? JAIM:  I’m sure it does. It’s got serious namespaces, all sorts of things. This is a great way to just overanalyze everything. You think you can just add two numbers together or divide them? No. You need a strategy for that. So, I don’t know. This is a really funny website. Two things. It can help you learn what design patterns are. And another case, it’s also great to just laugh at often people into design patterns overdo them and this is taking a simple problem to the most extreme example. So, Enterprise Fizz Buzz. Check it out. CHUCK:  Awesome. JAIM:  That’s my pick. CHUCK:  Alright. Pete, what are your picks? PETE:  I’m so jealous of Jaim’s pick style, every time. [Laughter] PETE:  It’s just awesome. And I’m also loving just Chuck randomly in the background is like, “Shotguns.” [Laughter] CHUCK:  I’ve been watching The Walking Dead. That’s one of my [inaudible] PETE:  Me too. CHUCK:  I just barely started. PETE:  Oh man, I’m really into The Walking Dead. It messes with my head a little bit though. I find myself thinking dark thoughts after watching that show too much. [Chuckles] Sorry, this is a total sidebar. But Jaim’s pick particularly strikes a chord with me. We as part of the notoriously hard recruiting process at ThoughtWorks, we have a coding submission so people have to write a little solution to a little simple coding problem. And sometimes, I do see some amazing Java patterns. It’s a simple problem and people have got abstract strategy factory patterns and all sorts of nonsense. So, I can definitely relate to that stuff. JAIM:  ConnectionManager connections. PETE:  Yes. Manager is always a good thing to stick at the end of any class name. Makes it sounds more official, I think. JAIM:  ConnectionFactoryManagers. BEN:  Oh man, I’m going through this Fizz-Buzz thing. This is gold. [Laughter CHUCK:  It is so funny. BEN:  Java.com.SeriousCompany.business. [Laughter] CHUCK:  Package naming package. BEN:  Sorry. Continue. PETE:  Oh, man. Okay, so my first pick is, I’m pretty sure no one’s picked this yet. It’s a mobile web app called Forecast.io. So this came to mind when me and Ben were having a little debate there about using web technology. So this is a really good example that proves Ben’s point I think, that you have to really know what you’re doing to make a mobile or web app that feels like an actual application, not like a web page. But I think these guys do a really impressive job. It’s at least interesting to look at. And they also have a good blog where they talk about some of the crazy hoops that they jump through in order to make it feel like a native app. So Forecast.io. Go there on your cellphone and check that out. My second pick is extremely random. I just randomly said stranger in a strange land earlier, so I’m going to pick the book ‘Stranger in a Strange Land’ by Robert Hein-something. I can’t remember his second name. I’ve read this book three times. It’s classic sci-fi. It was written in the 50s or the 60s. So it’s actually pretty misogynistic. He has some pretty old-fashioned views about women’s place in the world. So you have to have some virtual earmuffs when you’re reading some stuff. But it’s a really good book. It’s just good classic sci-fi. BEN:  Thought you were going to pick Iron Maiden. PETE:  [Chuckles] That reference passes me by. I didn’t have that in my childhood for some reason. And my last pick is a beer because I like picking beer. I recently went to Cincinnati, Ohio. And while in Cincinnati, Ohio I had a MadTree Identity Crisis. The brewery is called MadTree. The beer is called Identity Crisis. It’s a black IPA. I’m generally not a fan of black IPAs. I think they’re a little bit of a hipster made-up thing, like, “Hey let’s take an IPA and make it black.” But this one is actually really good. It tastes quite stouty but it’s still got that big old west coast hops slow run. If you’re not a fan of black IPAs but you are a fan of IPAs and you’re a fan of stouts, then try this one and maybe it will expand your mind a little bit. That’s it. CHUCK:  Alright. Well, I’ve got a couple of picks here. My first pick is, as I said, The Walking Dead. I don’t know. I heard about it. I just hadn’t gotten around to watching it. And I couldn’t sleep a couple of nights of ago and so I watched two episodes and I was hooked. The funny thing is that most of the time, if I turn on a show while I’m trying to go to sleep, it’ll eventually wind me down and I can just lay down and go to sleep. The Walking Dead is not that show. PETE:  I know what you mean, man. BEN:  [Laughs] That’s why I don’t watch It’s Always Sunny before bed, because that is the most stressful thing to watch. CHUCK:  What is? The Walking Dead? BEN:  No, no. Sorry. It’s Always Sunny. Do you watch that show? CHUCK:  Uh-uh. BEN:  It’s hilarious, but it’s a bunch of people screaming at each other for 20 minutes. So it’s not quite the relaxing late night TV. CHUCK:  Yeah, makes sense. Anyway, so yeah. So I’m enjoying it. The only time I really have to watch shows is in the evening when I’m trying to unwind. But anyway, I’m really enjoying it. It just keeps me awake. So yeah, that’s one pick. Another pick. I’ve been reading another book. This one was recommended to me by somebody who reviewed some of the material for my upcoming freelancing class on how to find clients. And it’s ‘Duct Tape Marketing’ by John Jantsch. And I’m really enjoying it. And it really drove home a couple of things that I felt were missing from my class. And so I get to fill in those gaps now. And it’s also really helped me just sit down and figure out some of the stuff that I can improve on in my own marketing. And I’m pretty good, I think, at finding clients. But there’s always room for improvement. And in my case, improvement usually comes down to quality over quantity. It’s usually not hard for me to find work. But finding more of the people that are the people that I want to work with. I enjoy working with all kinds of people, but there’s a certain type of project with a certain type of entrepreneur that really gets me fired up. And so I’ve been working on that kind of marketing to get those kinds of people coming to my business so that I can work with them. So that’s been interesting. And since I’m talking about it, if you are working on an iOS app and you need some kind of backend built, I am supremely qualified for that. I can build it in Ruby on Rails and get you what you need. So anyway, I’ll just throw it out there too. And with that, I guess we’ll wrap up. I hope you all had a very merry holiday season, whether that’s Christmas or something else. And we’ll catch you all in a week.

Sign up for the Newsletter

Join our newsletter and get updates in your inbox. We won’t spam you and we respect your privacy.