Filed under: Developer, Windows, Macintosh, Apple
Dev Chair : My love-hate relationship with Apple development
by Alex Hung Feb 12th 2007 at 11:00AM
First, let me start with the full disclaimer: I develop Windows .NET application by day (and by night too for ecto) and use Mac OS X at home for everything else. Before getting my Mac Pro last December I used to work on ecto using a second Windows machine, but since then I have been using Visual Studio 2005 in an XP virtual machine using Parallels.Whether you love or hate Microsoft, you have to give them credit for popularising programming on Windows. While I was a junior programmer fresh out of college learning C++ and working on train control software, truckloads of CS/Engineering graduates were learning to program in Visual Basic. Whatever faults VB has, the way it allows even beginner or causal programmers to learn the craft and produce quick and dirty applications means that programming for Windows was no longer the eminent domain of the traditional CS/Engineering graduates, where FORTRAN and C/C++ rules. Microsoft continues this trend with C#/VB.NET and the .NET Framework, providing a lot of built-in functionality that used to require hand-crafted code or expensive third-party libraries, freeing up developers' time to concentrate on problem solving instead of mechanics.
With OS X, Apple began with Objective-C and Java as the programming languages of choice but ever since version OS X 10.3 Java had been put onto the back burner and is expected to be phased out eventually. Unfortunately, making Objective-C the sole language of the platform also makes it difficult and 'expensive' for Windows programmers, such as yours truly, to join the party. The difference in syntax (despite the 'C' in the name it does not have much resemblance to C or C++), difference in framework and API, difference in IDE philosophy, and the lack of refactoring tools (ReSharper, CodeRush, etc.) and unit testing tools (NUnit, JUnit, etc.) mean that some of the more open-minded programmers (mostly Java and .NET) will not take an active interest in Apple software development.
The upcoming Xcode 3 looks like it would make a big step in closing the gap, but the IDE still lacks the tools mentioned above to attract the time-constrained, less hard core developers from the Windows side of the world. The dark horse may be the combination of Eclipse IDE and Mono project. The Eclipse IDE is mature and has a flexible plug-in architecture so refactoring and unit testing tools can be integrated into the IDE by third party developers. Meanwhile the Mono project has been making lots of progress as far as compatibility with Microsoft's implementation is concerned. And the ability to take code written in Windows and runs it in Linux or OS X (with some limitation, of course) will appeal to Windows developers, at least as a starting point.
In fact, Eclipse/Mono may actually achieve what Sun tried to do with Java all those years ago. Remember 'Write once, run anywhere'?
With Halloween fast approaching, it's a great time to get in some practice defending your territory against zombies. In Graveyard Shift, you take aim at zombies and other creepy-crawlies, blasting them into splatters of cartoony green guts. It's a casual first-person shooter, and it's very easy to get the hang of - use the mouse to aim, click to fire. Graveyard Shift has at least 15 levels, and it might even have some secret stages I haven't unlocked yet.
They key to getting good at Graveyard Shift is learning to use ...
Reader Comments (Page 1 of 2)
justelise said 1:04PM on 2-12-2007
"And the ability to take code written in Windows and runs it in Linux or OS X (with some limitation, of course) will appeal to Windows developers, at least as a starting point."
Did you mean appeal?
At any rate, I think Apple made it more expensive for developers to come over from other platforms and start programming in Objective-C to perhaps force a crop of programmers to spend the money to go to classes and actually learn the language so that they could put out quality applications. There are a lot of self-taught windows developers who put out horrible applications with disastrously bad GUI. Maybe Apple didn't want these people flooding the software market with poorly developed apps either.
Reply
Sergio said 1:13PM on 2-12-2007
Can you create Mono apps in OSX that look like real OSX (Cocoa) apps? Or will they look awful like the Java counter-parts?
Reply
Alex Hung said 3:28PM on 2-12-2007
@justelise, thanks for point it out. I've amended it.
Yes, Apple is making it expensive so to deter the 'weekend warriors' type programmers. But the bar is so high that most experienced Windows programmers will not be willing to meet, unless they make programming for Apple their main job.
Reply
Ruminator said 2:38PM on 2-12-2007
For the weekend people, you have Automater (it does what most people would need). If you really want a VB style development tool, try RealBasic - http://www.realsoftware.com/
Reply
William W. Lin said 3:12PM on 2-12-2007
Wow. I'm totally in the same boat - I program in C# / .NET for my day job, have a Mac for my home machine, and would love to get into developing on the Mac. But I can't spend the time necessary to get into Objective-C, which, frankly, has little use outside of programming for the Mac. I would like to humbly suggest to Alex, however, that he check out RealBasic ( http://www.realbasic.com/ ), which is apparently a lot like a cross-platform VisualBasic, utilizing a similar language and drag and drop controls, etc. It's not "real" Mac programming, I suppose, and may not have access to all the low-level API's (though I don't know that for sure), but it may allow for tinkering and developing small utility apps to make your life easier.
Reply
Alex Hung said 3:31PM on 2-12-2007
@Ruminator & William, I have not tried RealBasic but that's mainly because my unfounded bias against anything with 'Basic' in it ;-)
Reply
JC3 said 4:26PM on 2-12-2007
I am a Mac convert. I work, professionally, as a Windows programmer but use, personal, a Mac. I have dabbled in O.C. can sympathize with overall "support" (user, Apple or otherwise) out there for budding OS X developers.
Learning a language, either via classical or books training does not equate to one becoming a quality programmer. Despite the tired analogy about programming to art (writing or otherwise) it is still a solid one. You can teach someone to understand and appreciate Cubism but you can't teach them to paint it if he/she doesn't have the intrinsic talent to do so.
So, with that said, Apple could provide potential Picasso better resources and support to help those willing to try and see what they can create in the wonderful word that is Mac OS X. It also wouldn’t hurt if the existing development community was a bit more willing to help usher us in as well…
Reply
Oliver Charles said 6:34PM on 2-12-2007
Am I the only person who really disagrees with the content of this article? I hope not. It seems to be some strange assult on Apple because the poster is not familiar with Objective C, and Apple's developer tools. In my opinion, it has been approached from an unfair angle - would you find starting with Windows easier?
I doubt that. Apple deliver developer tools and documentation on the CD with all macs, so if you're curious you've got everything you need, even if you don't have internet connectivity.
Objective C is an "interesting" language, I agree - sharing principles with many languages such as smalltalk and C, while doing a bit of it's own stuff. However, once you understand how it works it's easily just as powerful as you want it to be.
All it takes is for people do the same thing as before, start reading around and learning... it won't code for you, but it's much easier than windows.
To wrap this comment up, I too am primarily a C# programmer, using Windows. I have a MacBook sat next to me, and I'm gradually getting into it more. Sorry if I got the wrong end of the stick, but I thought I'd voice my views.
Reply
Alex Hung said 8:59PM on 2-12-2007
@Oliver, the point of this article is not about starting from fresh. In fact, if I were to start afresh and knowing what I know now, I would prefer Xcode/Obj-C for its MVC Interface Builder and more 'pure' OO construct in Obj-C.
But my point is that these fundamental differences are making it more difficult for existing Windows developers to join in. Our Windows skills are not transferable and since most of us have life outside work/programming we simply don't have the time to learn a language and an environment from anew.
Reply
JC3 said 12:38AM on 2-14-2007
@Oliver
Actually, I would take it a step further than then the author by saying it's not a question of familiarity with Objective-C or the IDE - it the lack of "support" at the entry level for new developers. Syntax is easy, it can be taught in 20 pages or less. What I think he and the rest of us are asking for are more things like MSDN – both the web portal and their Help system, downloadable workshops, full end-to-end product samples (not just conceptual samples) and, at least for me, a more user friendly user community.
As I stated earlier either you get it or you don’t i.e., either you code well or don’t - ease of use won’t make you a better (or worse) programmer. And, yes, Microsoft does make it much easier to get your feet wet and hit the ground running that any other platform because of but not limited to the things I mentioned in the paragraph above.
So to clarify, this is not "an assault" on Apple but a criticism, and a constructive one at that, of some of the shortcomings. So, if I were Apple I would take for what it is: A plea from a segment of the industry - some of which they are actively courting (i.e., a switcher like me) and long time supporters - asking for a lifeline. We could do it without the help but it will take longer than it should otherwise. In essence help us help you make OS X the best operating system on the market. Apple does many things very well. This is just a small wedge that needs a bit more attention and polish.
Reply
Blake Seely said 12:37PM on 2-13-2007
But Xcode already provides unit testing tools - OCUnit is integrated with Xcode already. You can even add a pre-built unit testing target to your projects... It's all there.
Reply
Alex Hung said 1:25PM on 2-13-2007
Thanks Blake, it looks pretty good. Now, where is the refactoring tool...
Reply
Gus Mueller said 3:12PM on 2-13-2007
@Alex Hung:
I don't see why programming on OSX is expensive. You get a free compiler, ide, unit testing tools, and freaken' amazing profiling tools like Shark. And that's only on 10.4. 10.5 is bringing more to the table with an upgrade to objective-c, refactoring tools in xcode, built in support to write cocoa applications in Python and Ruby, and another amazing profiling tool named "xRay". All for free.
And once you learn the frameworks (that's the learning curve) It's completely reasonable to make a quality application "on the side" as I have done myself :)
Reply
Alex Hung said 3:58PM on 2-13-2007
@Gus
I was referring to development cost, mainly time, instead of monetary cost. Time to learn new language, new IDE, time to search for examples, time to figure out the best way to do thing without re-inventing the wheels.
Reply
Gus Mueller said 9:12PM on 2-13-2007
@Alex:
Gotcha. Of course, if it was just like windows... what's the point? :)
Some good places to start are:
http://cocoadevcentral.com/
http://cocoadev.com/
And of course Apple's site. They've served me well in the past (and still do today obviously)
Reply
Farhan Ahmed said 11:26PM on 2-13-2007
@ Alex:
I'm not sure what you meant to say in this article/blog post. Can you please explain.
Thanks.
Reply
Robert Pritchett said 9:24AM on 2-14-2007
Why not sign up for Apple's Worldwide Developers Conference in June?
http://developer.apple.com/wwdc/
Or read Jonathan Hoyle's column articles in macCompanion? All issues are free to download at http://www.maccompanion.com
Reply
Erik Buck said 9:15PM on 2-15-2007
As one of the authors of "Cocoa Programming" ISBN: 0672322307, I may have a different view on this subject.
I don't think Apple is trying to discourage new developers by setting a bar high. In contrast, by providing professional (and in some cases best of breed) development tools free with the operating system, Apple is only encouraging adoption.
I too am a professional Windows programmer, and I think the available resources for Apple far exceeded what is available from MSDN. Try developer.apple.com sometime. You might also notice that the complete source code for the TextEdit application (along with others) is already on your hard disk if you have installed developer tools/examples.
In my experience, re-factoring tools are much less needed with Cocoa applications than with many other types of development, but I concede that re-factoring is a weak spot with xCode.
Finally, Cocoa is the successor to Openstep, in in many respects, Openstep was/is the only successful write once run anywhere framework. http://en.wikipedia.org/wiki/OPENSTEP It is only Apple's licensing and not technology that keeps Cocoa applications off Windows.
Reply
Alex Hung said 10:12PM on 2-15-2007
@Erik
I've visited Apple's ADC site before and also recently. The amount of resources are good but nothing in compares to MSDN. Microsoft has a huge amount of sample code, application, and code snipets for almost every corners of the entire SDK/Framework.
Bundling Xcode for free with OS X is nice but Microsoft also offers Visual Studio 2005 Express edition for free.
I am curious as to what makes Cocoa much less need for refactoring. How does a framework or language make us write better code? I am obviously a novice in Cocoa and Obj-C so I will be interested in finding out more.
Reply
Erik Buck said 12:31AM on 2-16-2007
When I re-factor code, it is typically because I have thought of a better design or the existing design will not scale. I suppose I also rename variables and methods or add and remove method arguments, but those sorts of re-factoring can be handled with a good text editor, FileMerge.app, and global replace capability.
I theorize Objective-C and Cocoa require less re-factoring because of the following in no particular order.
1) I accomplish the same goals with a lot less code using Cocoa. The fact Core Data models do not strictly have to generate code and bindings often require no code and Interface Builder does not generate code results in a lot less code. Steve Jobs used to say something like the following: "It doesn't matter whether a human or a computer generates the code; every line of code is a potential bug and a potential source of future maintenance" Every line of code is also a potential re-factoring target.
2) I subclass a lot less with Cocoa. One of the most common reasons to re-factor is to change an inheritance hierarchy. For example, if B is a subclass of A, I might decide that there are reusable features in B that really should have been in am intermediate class and end up with B is a subclass of C which is a subclass of A. B->A becomes B->C->A. With Objective-C, I can add methods to base classes using categories instead of subclassing. Cocoa uses ubiquitous delegates and notifications which reduce subclassing. See http://www.stepwise.com/Articles/Technical/2000-03-03.01.html and http://www.stepwise.com/Articles/Technical/CategoricallySpeaking.html With fewer subclasses (and fewer classes total), there is less re-factoring.
3) Another reason to re-factor is to move methods and instance variables up and down in an existing inheritance hierarchy. I find it easier/more convenient to make such changes using Core data and categories than out traditional code re-factoring.
4) Achieving good separation of concerns is another reason to re-factor. Categories really help with this. As an example, I have a 3D engine that uses a data structure called a QuadTree to organize objects of type EBNQuadElement in a scene. The QuadTree is part of the Model (as in MVC) and is implemented in a shared library. The exact same Model is used in several applications, most of which used OpenGL to render and one of which uses Direct X to render. In the OpenGL applications, I have a category implemented in the View layer that provides methods like -drawTerrain:inFrustum:cullDelegate:glContext:. First, I can cleanly separate and separately maintain code that is View related from code that is Model related. In the Direct X application, a different category defines different methods for drawing. The Model is completely re-usable. I didn't need to create new classes just to add specialized drawing capability and yet concerns remain separated. This type of capability mitigates the need for major re-factoring and limits the area of effect when re-factoring does happen.
Reply