Submitted by Scott Stevenson at InformIT interviews Aaron Hillegass about the new edition of Aaron’s “Cocoa Programming for Mac OS X” book, programmers’ fear of the NIB file, and why there aren’t more Macs in corporate America. There are some real gems in this interview, so read on.One of the questions regarding the new edition of his book, which is now updated to match Xcode 3.1 and Mac OS 10.5 Leopard, concerns if developers who already know the basics about Objective-C can still make use of the book. “The typical self-taught Cocoa programmer has mastered a few concepts and uses them in every situation. By going through the book from beginning to end, the reader gets familiarity with a large collection of ideas and technologies,” the author explains, “This deeper understanding results in better, more reliable applications – because the reader uses the Cocoa frameworks as they were intended to be used.”
To developers trying to figure out if they should learn Objective-C or use one of the Cocoa scripting bridges, he says:
For fifty years, there has been a heated debate going on about programming languages. In the meantime, real programmers have been solving real problems with imperfect languages like Perl and Objective-C. Why?Perl and Objective-C have three things in common:
- They come with incredible libraries. Perl has CPAN and Objective-C has Cocoa.
- They don’t get in your way. Both languages have good performance and loose typing.
- They are easy to learn.
Ruby and Python are lovely scripting languages, and you can write Cocoa applications with them after you learn Objective-C!
The Mac has been making serious inroads into the consumer market, but InformIT wonders if Hillegass feels that the Mac is also making inroads into the corporate world. His answer is, shall we say, clear.
Apple seems to doing its best to keep Macs out of the corporate world. Most dialogues between Apple and a corporation go something like this:Corporation: Hey, does Cocoa include something to help us write apps that talk to our Oracle database?
Apple: Um, nope. But isn’t GarageBand cool?
Corporation: Hmm.
VP: A lot of our employees are using Macs. What do you know about them?
IT: They only had Windows in my community college classes.
VP: Write up an e-mail on something that is wrong with them and we’ll announce they are un-supported.
Nice interview, I liked it. I certainly wish more developers were exposed to Mac development at university, and using the NIB and the Interface Builder is a pretty interesting experience. However, that is all down to demand, and that gets us on to another story.
Apple is certainly doing its best to ensure Macs don’t get used by a lot of companies to replace PCs, but that is just repeating every mistake they’ve made for the past twenty years. They generally start well, but run out of puff in the long-run. What programming tools people learn is generally down to demand and who pays their wages, and few businesses outside of a few market segments use Macs on a widespread scale. That means that when people look at developing applications for the iPhone, few people are familiar with the tools to do it. Without that whole support ‘ecosystem’ in place you’re on to a loser in the long-run, because there’s nothing to support your market share.
True, yet this WWDC is the first one sold out [over 5000 developers] and the Fortune 500 are signed up for the iPhone Touch platform.
Well, considering that Apple are probably hoping for some kind of knock-on effect where the iPhone can drive Mac sales, but they’re telling these same Fortune 500 companies that they don’t want a Mac, I sincerely hope they have a platform to actually develop on for the iPhone ;-).
I fully identify with that! Coming from a Visual C++ background, Xcode and particularly NIB files and the Interface Builder scare the crap outta me. I like seeing my message maps, signals/slots or message pumps. The NIB file hides all that and I’ve found that it makes it very hard to allow me to visualize how the code all fits together.
Granted, it’s taken quite a while to get used to NIB files but I think I’m getting there.
I started of in a very similar situation. I originally developed using C++ and QT. The first time I was exposed to Cocoa I wanted to write the GUI by hand and hated the .nib files. A few weeks later, and I love it. It saves you a lot of time and serious headaches, and the whole MVC paradigm has helped me organize and plan my code better.
I also agree on the statement that to appreciate and use Cocoa you should use Objective C. Writing code in Objective C allows you to integrate nicely using the Cocoa design patterns, and for me, you get the best of both worlds (i.e. A quick compiled language, with interpreted language like features)
I read this part of the interview in amazement – what a nightmare, a monolithic gob of stuff that describes your entire user interface in one file? I had no idea such poor design choices had survived this long. How the hell does a .NIB file work with version control systems?
It might be a of a lot easier to learn to love the .NIB if you are going to develop for the Mac, but there simply has to be a better way to solve this problem. MS’s XAML and Adobe’s MXML come to mind.
One of the primary drivers for Adobe’s choice of the MXML format for user interface layout description was the fact that the monolithic blobs their older products produced weren’t human readable, and were a nightmare to version control.
You don’t develop with NIBs, as those files are for deployment only. You use .xib files when developing and these are text based NIB files, which integrate easily with version control software.
Read more about it at http://developer.apple.com/documentation/DeveloperTools/Conceptual/…
That’s not the case at all. You can have multiple NIB files… one for the menu, one for the main window, another for preferences, another for secondary windows, etc.
I agree with you that it is weird to have your UI in binary files… but version control just keeps the files for you, and if you need to revert back to previous versions, you just go get the older NIB file from the history in the repository.
Something to understand is that if you made a mistake with your design of 1 part of your NIB file, it is often faster and easier just to fix the mistake than go to the repository. Interface Builder makes writing Mac OS X apps very fast and easy!
…to see this guy interviewed. I bought my first book on programming Cocoa back in 2002 I think and haven’t looked back.
Obj-C coupled with Cocoa is a beautiful thing and now MacRuby and other bridges such as Python are available, the world of Cocoa is looking very interesting…
Nibs (Xibs) are an interesting concept and one that do take a little time to get used too…
I am loving CoreAnimation and CoreData too.
Please remember, Obj-C/Cocoa are just tools like anything else, use them when needed…
Have to agree on the comments about the corporate world. The problem I see for apple is that the corporate world is reliant upon interactions between the client and the server using custom software.
Apple on the server-side is particularly weak. Their servers might be nice hardware, but the software stack is inflexible, tied to major os versions and performs fairly badly.
Apple’s excrutiating focus on Obj-C is disconcerting. Carbon is dying, Java integration is currently dead. Newer scripting languages are sexy, but I think they have diseases. I’d like to see Apple really step up support for developers of all colours.
We’re considering going Mac’s for desktop and laptop stations.
I hear what you’re all saying, but the thing we had to start considering was whether or not technology was going to dictate business practices, or whether good business practices would dictate the type of technology we used.
Microsoft has done a poor job in keeping my company satisfied with the level of technology they’ve provided us. So we decided that we’re going to start looking for “cross-platform” solutions when possible so that we’re not feeling behind the MS “8-Ball” each time a major change to an OS is made.
For those positions in which there is no Windows equivalent, we use virtualization or Citrix based application environments.
Java is still there, but dead for graphical programming.
The point here is for enterprise adoption. If you consider python and ruby diseases, well with microsoft tools like vbscript and cmd, RIS crap, it’s a lot more horrible and unreliable than what a OS X has to offer. Windows is also pretty bad for corporation, the difference is that people are use to deal with it.
I am not sure if one would say Java is dead for graphical programming. There Java3D and with Java 6 all the 2d and 3d stuff can take the help of DirectX and Opengl pipelines! Also Swing has come a long way. Was not there a mashup not too long ago that took Swing, Google, and some other web services to create a sort of travel logbook tool that was really snazzy and had all sorts of awesome glass looking interfaces? Aerith or something? People just say Java is dead but have you all taken a look at Java 6 lately? It really has a lot of cool stuff and with Netbeans having Matisse as the Interface builder…its pretty cool. But I do believe that writing Swing apps the right way with threading and responsiveness in mind is NOT easy at all and that is probably coupled with Java’s bundled Look and Feels is what leaves a bad taste for a lot of developers.
My 2 cents!
I wasn’t clear, sorry.
I mean for developping cocoa base application.
That’s truly rich. All of NeXT’s money came from the Fortune 500 and writing 3-tier MCCA application suites for Merrill Lynch, Suisse Bank, and hundreds more that included the CIA, et.al.
The toolkits are deeply rich with capabilities. What you do have is a lack of dedicated focus on making an Enteprise Branch and dedicated Consulting Services Branch taken for granted at NeXT that needs to be at least twice or three times that at Apple.
It’s one of the main reason many of us from NeXT left Apple.
Well, Garageband is cool.
[quote]
Aaron: Apple seems to doing its best to keep Macs out of the corporate world. Most dialogues between Apple and a corporation go something like this:
Corporation: Hey, does Cocoa include something to help us write apps that talk to our Oracle database?
Apple: Um, nope. But isn’t GarageBand cool?
Corporation: Hmm.[/quote]
Wow, where was this guy for EOF????
What about webobjects?
Wow… just wow. What happened to DBkit?
Edited 2008-06-04 21:08 UTC
I worked with Aaron at NeXT. The man is very humble about his programming prowess.
He worked for Eiffel before moving to NeXT.
He didn’t work on EOF. Enterprise Object Frameworks original architects left Apple before WebObjects 5 came out.
DBKit is an interesting story. The concept of SOUPS was ready to go from the creator of DBKit but as the inside story goes he left NeXT in a very `disgruntled’ state of mind.
NOTE: Someone, at the time, allowed this Dev to have all of DBKit within their User Networked Account. When he left NeXT they wiped his account and without knowing it wiped out all his current work and theories on SOUPS.
When I first worked at NeXT in 1996 I got the scoop on it and just looked at those discussing it with a stunned look on my face. TThat’s one way of learning to make sure everything is backed up.
EOF 3.0 in Pure Cocoa would be a blessing to everyone wanting Apple to re-enter the Enterprise. Hell, a WebObjects Cocoa renewal with Ruby/Python integration would be a welcome present as well.
That’s pretty incredible (the DBKit story) …
By curiosity, what’s the SOUPS concept ? Anything to do with NewtonOS soups ?
SOUPS was Group Collaborative Context Editing without collisions and addressed the last saved issue of document changes.
Edited 2008-06-05 20:39 UTC
Wow someone with the inside scoop…
That’s insane with the dbkit thing! Where I currently work we’ve gone through the same thing with a certain machine holding all the spec documents and source for an older release, and some tech formatting the box to play some dammed game……..
The real killer is that we spent a year reversing binaries in production, to only find a CD containing the source a year later.. Oh well that’s fate I guess.
It’s always been disapointing the whole shift from EOF to the java WebObjects… Although I’m sure I’m not the only one that keeps a copy of the older ObjectiveC EOF handy for mining & prototyping… even EOF 1.1 will talk to Oracle 11!
It was a shame they killed the yellowbox, it really would have been OPENSTEP everywhere…
I really like Aaron.
He taught me basics of ObjC/Cocoa through the first version of his book.
Aaron, keep on the good work !