header

Torsten Curdt’s weblog

Developing on Mac

While Jesse and Marcus could not have more opposite positions. I found the truth to be somewhere in the middle.

Visual Studio is not great – but let’s face it neither is Xcode. True they did add refactoring support and intellisense – but how long did it take? And last time I checked it was still miles away from what IDEA of Eclipse can do. No official plugin API and a terrible window behavior for Xcode. Let’s not talk about unit testing integration. Awkward DLL hells you can run into with Visual Studio on complex builds and many frustrations that I’ve just repressed over time. Let’s just be honest – both have their strengths and weaknesses. There is no clear winner.

As for the mobile platform: I am sure things have changed since the time I was developing for Windows CE. But I am scared for the rest of my life. I can barely speak the words “active” and “sync” together in one sentence without shaking. The iPhone environment seems like heaven to me – at least from the developer point of view. Haven’t really made up my mind about the AppStore yet. We’ll see.

While some things I do find terrible frustrating when programming for Mac it’s the best fun programming I’ve had in years. You really have to get used to the (terrible) syntax of Objective-C that so doesn’t fit the all-shiny Apple image. But I would have never believed it – after a while you can really read it. And I finally really dig how the selectors are build up (like “named parameters”). I hated that in the first place.

Accept to “Think Different” and you gonna have some fun.

  • James Gregurich
    one thing that can put your mind at easy over the bracket notation is to re-train your mind think in terms of sending a message to an object....rather than calling a function.

    When ever you approach a new tool, it is best to try to learn it as it was intended to be used rather than try to coerce into fitting what you already understand about some other tool. Doing so can be a challenge, but it works out better in the long run.
  • @James:

    Syntax: I agree - perl is terrible. And as said - I also really started to like the fact that you can read functions like almost like sentences in Objective-C. The [[[[]]]] terror is still not very nice though.

    Tabs/Windows: I guess this really is just a matter of preference. I guess I don't like the fact that the windows are out of context with Xcode and clutter my system. I use Expose a lot and while I have to say the Xcode window behavior is consistent with other document based apps, I think a document application with 40+ files open reaches the limit of usability. This is not the number of documents you have open with a normal document based application. And that really is the problem. I agree the tabs just move the problem into the IDE space - but at least they don't affect the usability of the whole system. (-> Expose)

    Java: I can't comment on building desktop apps with java. (I never have and guess I will just never do) Java is fine for server side stuff though. But that really is not the point. This is not Objective-C vs Java. This is Java tools vs Objective-C tools. And I just miss some of the conveniences from either IDEA or Eclipse in Xcode.
  • James Gregurich
    I'm a commercial application developer. I have no use for Java. I'm glad Eclipse works for you and you like it. By all means, use it.

    As for tabs and windows...I just did a quick count...I have 42 windows open and 11 apps in the dock going. That is a light load for me. I've probably had 42 windows open just in xcode at one time or another. Its just how I work. What do you think the experience is on Visual Studio when I have 42 tabs on my one window? I don't see much difference in hunting for one window in 42 or one tab in 42.

    As for Gimp...I used to use it a bit years ago. it was ok. Didn't really do any heavy lifting with it. Worked well enough that I didn't need to buy photoshop for the bit of graphics work I had to do.

    Let me explain what I mean by the black-box comment. The macosx environment is very extensible. This translates right into the Cocoa APIs. For instance, cocoa screen widgets are designed to allow the developer to dig deeply into their internals and modify their behaviors. That is why there are few cocoa widgets compared to what you get from MS. Apple doesn't give you many, but what you get can be adapted to most anything you need.

    One time, just for the educational exercise, I decided I wanted to put together a movie player. If the Windows was minimized to the dock, I wanted the movie to play in the dock. However, all Apple at the time allowed you to do was put a static image in the dock tile. So, here is what I did. I created a custom subclass of NSImage. I figured out which method was being called to paint the image into the graphics context for the dock tile and I overrode it with my own implementation that painted movie frames into the context instead. All I had to do was instantiate my custom image and feed it to the supported setApplicationIconImage method. Worked like a charm with a couple hours of tinkering. Another time, for educational purposes, I decided I wanted to subclass NSColor. NSColor is an umbrella class that hides private subclasses that map to different color spaces (RGB, CMYK etc). Therefore you can't subclass NSColor. when you work with an NSColor instance, you are actually working with a private class that implements the NSCOlor interface. What I did was dig down to the objc runtime API. I created a NSCOlor instance of the space I desired and dynamically, I changed the superclass of my NSCOlor subclass to be the private subclass. I dynamically modified the class hierarchy at runtime to use a custom NSColor subclass.

    Why could I do these things? Because the APIs gave me access to things like the graphics context used to draw the dock tile and the ability to get the class pointer for a private subclass and work with it.

    Back in the day when I used to be a Visual Basic developer, I had very little opportunity to modify the internals of MS' predefined screen widgets. If I needed a class to do something it wasn't intended to do, I had to go to VC++ and write my own widget from scratch.

    You should now have some idea of where I am coming from. Now, my impression of Java is that it also has a black box mentality just like Windows. However, I could be wrong. I have played very little with Java.

    The fact that xcode is a front end to gcc and gdb is very useful. You get very rich build logs that help you troubleshoot problems. you can copy and paste statements from the build log and issue them manually on your own terminal. Visual Studio's build logs aren't as rich. I once had to get an Adobe Indesign sample plugin to build. I couldn't figure out how Adobe was setting the header search paths. I dug into the build log and I found no options there to set header search paths., but I did nothing something like "@suchandsuch.rsp" at the end of the build lines. After much digging through MS documentation, I discovered they were using an option called "response files". that is where Adobe was setting the header search paths. By comparison, their xcode sample was configured just as wackily but it was much easier to figure out what they were doing because you don't have to start right-clicking on every icon on the screen and every menu in the menu bar to find some obscure place where some option is being set. Its all right there in the target settings.

    As for readability of objc, those of us who just accept the syntax and work with it can read it just fine. In fact, one can often remember objc member functions easily because they read like a sentence when you write them. Its just unfamiliar to you.

    as for "Fanboy-ism", I have my complaints about Apple dev tools and technologies, but objc syntax and tabbed code browsing aren't one of them. I'd much rather complain about the lack of a rich memory editor in the debugger or how sluggish its interaction with gdb can get when you have a function with a lot of variables on the stack. These are the things that are meaningful to me....not cosmetic issues.

    I don't need all these training-wheel features in Xcode 3 like code completion. Frankly, I find they get in my way because they often guess wrong and screw up what I am trying to type. However, I'm trying to give them a chance and get used to them before I turn them off.

    I have tinkered with Ruby.....not much of an opinion. looks like one more scripting language to me. If you want to complain about syntax....try perl. I've done shell script programming but I find perl practically unreadable. However, I have never made any great effort to learn perl either.
  • @James: I was not referring to C/C++ development on Eclipse. I was talk about java development. And like it or not - that is quite smooth in Eclipse and IDEA.

    Now that I switched to the "one-window" perspective in Xcode things are much better. As a Mac developer I am surprised to you don't understand that there is a big difference between many windows and tabs. (This attitude makes me think of Gimp. Really like that approach? At least many people don't.)

    The fact that Xcode is a front-end to gcc I also see as a big plus. I am coming from the Linux world (and frankly don't understand why it's "Windows/java" in your comment). So I do know what it means to dig down as deeply as I need to. The fact that I am on Mac though is that I don't want to anymore - unless I really really have to. And when I think about unit testing in Xcode I am feeling it's more digging that I would want to.

    The syntax - sure you learn it and move on. That does not make it nice and readable though. If you ever get around to do some Ruby you will notice that syntax DOES matter.

    I also dislike the MS tools. But I do think that Xcode is not the tool it could be and many people in their fanboy-ism are just fine with it without looking somewhere else.
  • James Gregurich
    Last time I used eclipse, it was slow, clunky and the c/c++ plugin didn't support PowerPC assembly display in the debugger. Given it didn't know what to do .nib files or how to structure a mac application bundle, it was certainly not very appropriate for mac application development. It was very java centric, and I don't care two bits about Java.

    I do use Visual Studio. Frankly, outside of the debugger, I don't see much advantage to it over Xcode. Xcode is much easier to configure and manage. its a much more logical system and you have great access to the low-level details. Visual Studio is a black box approach that can be very difficult to troubleshoot when something goes wrong. Frankly, the tabbed design of the UI in VS is redundant since you have access to the list of files on the left in the project browser to allow you to switch between the files. Why take up screen real estate for a redundant feature? Secondly, what is the difference between dozens of windows hanging around and dozens of tabs you have scan through to find what you want?

    I think one thing people coming from a Windows/java world don't get is that the tools on unix are designed to be layered and accessible. unix is not at all about black-box designs where large chunks of functionality are complete mysteries to the user. OSX and its developer tools reflect that mentality. That mentality makes it a much more pleasant developer experience because you can really dig down into the system as deeply as you need to go to get what you need done.

    I really don't get all the consternation over ObjC syntax. ok. it has a different syntax....you just learn it and move on. what is the big deal? Every language has its own syntax preferences picked by its designers.


    I really don't get why there are these people out there who think all dev tools should follow the design decisions made my Microsoft. Microsoft's tools are really poorly thought out and encourage poor software design if you blindly follow the paths they lead you upon. It is a blessing that there is a different approach out there that doesn't suffer the same limitations and set of mistakes that comes from MS.
  • @Martin: Good point. So let's talk about it ;-)
  • I use the all in one window model so I don't end up with the thousands of windows all over. Just click the "toggle embedded editor" toolbar icon and it works quite similar to Mail. One of the big problems with Xcode is that people generally tend to miss that it has things and either get pissed off with it, or struggle by, when there is a better way of doing things that they just haven't found. I mean, you have this problem with all IDEs, but because Xcode isn't as widely used as VS or Eclipse, you don't see quite as many people talking about what it can do.
  • @Martin: I've just switched to another window mode and see how it goes. Basically I find it annoying that you sometimes end up with thousand of windows. If you are on a big screen less a problem. But sometimes you end up with two windows for editing the same file! (Urgh!) What modes are you guys using?
  • I agree that the refactoring has been long overdue, but Xcode has had code completion since 1.0 back in 2003, so it's not exactly new (not sure if Project Builder had it or not). The lack of some sort of API is a bit annoying, but I wouldn't want it to go the Eclipse route and just become a tangled mess of plugins on top of plugins. Out of interest, what is it you dislike about the window behaviour in Xcode?
  • @MatzeLoCal: If we could just get rid of the [[[[[ ;-)

    But seriously. Xcode's lack of an official plugin API is bad (TM). I miss a non-file but object based view of my project and the unit testing integration is embarrassing. At least for me these are already quite substantial drawbacks. It's still a good IDE ...but it still has to catch up on couple of things IMO.
  • As I have no experience with VisualStudio, I can't judge on that, but I have a background in eclipse and a bit netbeans and I love Xcode. I agree that refactoring isn't implemented well, but overall for me Xcode is a much nicer IDE than eclipse. And for the Objective-C syntax: As soon as you get used to it you will never miss it. It is so straightforward in reading...
blog comments powered by Disqus