Building a Native OS X Desktop App: First Impressions

Comment

Comment by Stuart Malin on October 11, 2009 at 1:08pm

Wow, so much to talk about! And, of course, talking programming language can be as charged as talking about religion :-)

Regarding IB and Nibs -- while not obvious and subtle and of no import to the casual programmer, a Nib is NOT a description of the UI, and assembled at runtime. A Nib is a serialization of executable object instances. This is why IB allows you to "run" your GUI -- it is not a simulation, but the very selfsame code that will be built into the app. Again, for casual use this isn't material, but one can get deep into Nibs, loading Nibs, interacting with Nibs, bundling Nibs, and there are some powerful abilities (and some bizarre gotchas lurking) there. That all said, Nibs are another technology, distinct from Cocoa and distinct from Objective-C.

As for named parameters/arguments, again there is a subtlety here. Objective-C does bind by names, but these are not quite the same as named parameters. You can successfully compile a program with warnings about calls to methods for which there is no compile-defined matching method, yet such is sometimes done, and handled, by Method Forwarding, by the runtime availability of defining a method, of method signatures being objectified, and for an object to ask another object if it handles a Selector. All of which is dangerous to the unwary and powerful to the skilful.

Ah... gotta run now... but will add more later.

Good conversation!

Comment by Daniel Leuck on October 11, 2009 at 12:35pm

I'd argue that having these dynamic featured hacked on rather than being fundamental to the language like in Obj-C, Smalltalk, Ruby etc, means thatbthey aren't use as pervasively as they should be.

I understand what you are saying, but C#'s flexible method dispatch, multicast events, etc. were all baked into the language from its inception. Those things that were left to the libraries were done so as a conscious design decision. Anders Hejlsberg was well aware of Smalltalk and Objective C when he designed C#. Nothing in the language feels "hacked on". The "send a message to an opaque object and hope things work out" approach of Smalltalk was replaced by flexible method dispatching and a robust, language integrated event system. C# manages to do all this with the advantages of strong typing, and without sacrificing flexibility and terseness. If you need something more "dynamic" you can use a scripting language that compiles to CIL (Ruby, Python, Javascript, etc.) or run things completely dynamically in the Dynamic Language Runtime.

With Java 7, we will have true dynamic invocation and the ability to modify the structure of .... I don't know what more is really needed in terms of flexibility in the runtime. IMO, the rest is an issue for the libraries.

Now these XML based UI languages seem to me simply a different way of failing at the same problem. They let you go in and edit by hand what a UI builder outputs. If you need to edit a UI built with a UI builder by hand then that is a failure of the UI builder.

That isn't the intention, although its certainly possible. The simple XML definitions allow for easy portability between tools. Note that I like Apple's interface builder, and am in no way knocking its usability characteristics.

Obj-C does have some legacy bagage due to being built on top of C, though whether that baggage is a disadvantage is subjective. Personally I find headers to be a brilliant form of documetation.

I'll take my nice, hyperlinked JavaDoc and .NET docs ;-)

Of course one other thing that Obj-C has that Java and C# don't is interspersed arguments, which greatly improves the clarity of code by making methods naturally self documenting.

On this, we agree. I've been arguing for the addition of named arguments to Java for years. C# added object initializers in v3.

Example:

button.Painter = new Painter {
        GradientFill = new GradientFill {

            ColorA = Color.FromArgb(192, 192, 255),

            ColorB = Color.Navy

        },

        MultiBorder = new MultiBorder {

            OuterBorderSize = new Padding(1),

            TopOuterColor = lightBorderColor,

            LeftOuterColor = lightBorderColor,

            BottomOuterColor = darkBorderColor,

            RightOuterColor = darkBorderColor

        },

        ForeColor = Color.FromArgb(255, 255, 230)

    };

Comment by Martin Pilkington on October 11, 2009 at 11:34am

I'd argue that having these dynamic featured hacked on rather than being fundamental to the language like in Obj-C, Smalltalk, Ruby etc, means thatbthey aren't use as pervasively as they should be. Defining the actions that an object performs or connecting variables in your controller to you UI are things rarely done in code in Cocoa either, but the functionality is there for cases such as needing to change the action at runtime. Instead these are connected together in Interface Builder. Now these XML based UI languages seem to me simply a different way of failing at the same problem. They let you go in and edit by hand what a UI builder outputs. If you need to edit a UI built with a UI builder by hand then that is a failure of the UI builder.

Obj-C does have some legacy bagage due to being built on top of C, though whether that baggage is a disadvantage is subjective. Personally I find headers to be a brilliant form of documetation.

Of course one other thing that Obj-C has that Java and C# don't is interspersed arguments, which greatly improves the clarity of code by making methods naturally self documenting. A lot of people understandably find Obj-C to be a culture shock as the syntax is different and how it works internally is different, but there are many people who see so called "modern" languages like Java and C# to be very restrictive compare to Objective-C, due to their naturally static nature and the fact that any dynamism is hacked on

Comment by Daniel Leuck on October 11, 2009 at 11:08am

Hi Martin. Thank you for joining and for your response.

Martin Pilkington: The reason Apple uses Objective-C is because it is highly dynamic... That key part is message sending.

I'm familiar with Smalltalk style message passing, but I don't see it as an advantage. I know Objective C messages can be intercepted, routed, delegated and sent remotely, but all of these things are supported by Java and .NET libraries via event buses, AOP interceptors and, in the case of C#, other language features. At this point, the difference between message sending and flexible method dispatching is largely academic, leaving Objective C's message orientation as nothing more than a syntactic oddity.

Martin Pilkington: This allows for a much more dynamic language, with less code needing to be written to perform simple tasks. It's this that allows for Cocoa to adopt things such as the target action paradigm. So instead of the Java way of responding to a button press by creating an ActionListener in an inner class or separate class and implementing the actionPerformed method and then adding that as an action listener to the button, you just tell the button what message to send to what object when it is pressed. In a nutshell: [myButton setTarget:self];
[myButton setAction:@selector(myCoolMethod:)];

Yes, but nobody handles event wiring procedurally these days. In the SDL/Swing framework we use, the above code would be written in a separate declarative UI definition as:

    button ID="myButton" do="myCoolMethod"

...which would invoke a Java method in the controller called myCoolMethod().

A similar approach is used by Flex (MXML), WPF/Silverligh (XAML) and JavaFX. Compared to these systems, Objective C, with its old style header files and awkward syntax ends up being more cumbersome and verbose.

Comment by Martin Pilkington on October 11, 2009 at 10:25am

The reason Apple uses Objective-C is because it is highly dynamic. C# inherited much from Java, which took quite a bit from Obj-C (eg Java interfaces are almost an identical copy of Obj-C protocols). However, the one thing Java didn't take was the key part of Objective-C, and as such Java and C# are much closer to C++ than Smalltalk. That key part is message sending.

To quote Alan Kay: "OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things."

Message sending is a far more powerful and dynamic. For example, with method calling, which C# and Java use, the object you're calling the method on must implement that method at compile time. With message sending an object doesn't need to respond to a message, but can be queried if it does. If it doesn't respond to a message it is sent it can be forwarded to another object, or it can create an implementation for it dynamically at runtime. Also, the object the message is being sent to doesn't even need to be on the same machine. You can send messages over a network.

This allows for a much more dynamic language, with less code needing to be written to perform simple tasks. It's this that allows for Cocoa to adopt things such as the target action paradigm. So instead of the Java way of responding to a button press by creating an ActionListener in an inner class or separate class and implementing the actionPerformed method and then adding that as an action listener to the button, you just tell the button what message to send to what object when it is pressed. In a nutshell:

[myButton setTarget:self];
[myButton setAction:@selector(myCoolMethod:)];

Comment by Daniel Leuck on October 11, 2009 at 9:03am

Hi Stuart. Thank you for your comprehensive and thoughtful response. I promise to spend more time with the Apple technology stack and revisit this post. I have no doubt that the runtime has all the flexibility and power you describe, I just don't see why they couldn't use Java or C# at the language level. Both of these languages were inspired in part by Obj C but, having had the benefit of coming along later, were able to revisit C's syntax and come up with something much cleaner before incorporating new language features. Additionally, there are a lot more Java and C# developers in the world. :-) I realize some of this is subjective, and that we all gravitate toward that which is familiar.

> p.s. alas, still off-island, otherwise I'd love to have a Cocoa developers meetup at the MIC.

I'm sorry you won't be around for the iPhone meetup on the 29th. We will definitely make this a monthly event and perhaps expand it to include Cocoa development in general. I look forward to hearing about your Obj C <-> Erlang project.

Comment by Stuart Malin on October 11, 2009 at 1:45am

Dan, so glad you have given Mac OSX develpment a try, but: you have completely missed Objective-C for its perhaps outdated message-sending syntax!

It took me a while to get accustomed to the "awkward" notation of Objective-C, but to focus on that instead of the underlying power of the runtime would be a HUGE mistake. By the way, having now lived in Objective-C for a long while, I actually find its syntactic constructs comfortable :-) That you built an application in a day is a testament to both your tremendous intelligence and the tremendous capabilities of the Xcode/IB toolset. That said, to judge Objective-C based upon this initial exposure is to judge (proverbially) a book by its cover. Underneath, the Objective-C runtime is an incredible engine and much capability lies there, that you are actually taking advantage of without even knowing of it. Therein lie capabilities for ISA-swizzling (enabling the likes of Key-Value Observing), message packaging (for invocation and forwarding), and meta-data about language constructs and calls (enabling among other things amazing debug interface). To call the language outdated is a comment you can only make while still ignorant of the runtime; hence I urge you to understand the runtime and key consequences of its existence before so assessing. Yes, there are "patterns" in Cocoa (e.g., MVC, delegates) that have influenced other languages, but these are Cocoa patterns, not Objective-C; one must be diligent in distinguishing Cocoa from Objective-C -- the former is built on the latter.

Ken: yes, NextStep was built on top of Objective-C. Apple has continued to advance Objective-C. Whie MacRuby is interesting and useful if one is a Ruby affecionado, to use it is to add both the power and the delay of an interpreter to one's application. I find no need for it, and Apple has, in Snow Leopard, added closures to Objective-C, closing the meta-programming/introspection gap tremendously (that is, C code (of which all Objective-C is) functions can be first class objects).

Dan:
The Objective-C compiler does not support namespaces inherently, and so the developer community has taken to using two letter uppercase prefixes to enforce a kinda somewhat almost-there namespace partition. This is the reason Apple continues to use the NS prefix; this use has nothing whatsoever to do with nostalgia.

Finally, to say that Objective-C was a great language 20 years ago is to somehow also miss the fact that some of the best applications today are being built using Cocoa and Objective-C (at least in my mind). So, as I said, you need to "get over" your reaction to the syntax, and look beneath the outermost covering to truly evaluate the language -- you have barely scratched its surface, and so wondrous surprises remain.

What I can decry about Objective-C is that all the rich goodness is generally opaque, and quite challenging to find out about. There are brilliant programmers out there who manipulate the runtime for wondrous effects, but the documentation of deep effect is hard to make sense of.

I urge you to go further!

btw: my interests now include doing things like binding Objective-C to Erlang to create a Cocoa app that can be a node in an Erlang cluster. My point: because Objective-C is built on C, I get the benefit of cool libraries (everything from Erlang bindings to javascript or ruby interpreters to leading edge datastores like TokyoCabinet).

Onward Ho!!

p.s. alas, still off-island, otherwise I'd love to have a Cocoa developers meetup at the MIC.

Comment by Konstantin A Lukin on October 11, 2009 at 1:33am

Not being too well versed in history of computer languages, and having mostly Java background, at first was sort-of intimidated by Objective C development.. which is mostly primary reason not to get into it at the time. Do wish for language not to be a barrier for mobile progress, hence will likely wait for more inviting, standards-oriented alternative solutions.

Comment by Daniel Leuck on October 10, 2009 at 10:45pm

Exactly. Having sold NeXTcubes in school, I've very aware of the heritage. At the time they were the coolest thing since sliced bread.

The original NeXTSTEP developers, some of whom are still at Apple, are a nostalgic bunch. The component class names are still prefixed with "NS".

> MacRuby, although very rough, is supported by Apple and may become viable.

That is great, but the tools are still Objective C oriented. Even with some support for scripting languages, they really need a good systems-level language. I read about Ruby and Python support in the docs, but haven't tried it.

I'm a big fan of C#'s approach, where you can have all the GCed, VM abstracted goodness of Java and the ability to do low level memory manipulation and compile to binaries when necessary, all within the same language. .NET languages can transparently inter-operate and the tools support them all equally well. With LINQ and all the other great language features added in C# 3, its undoubtedly become the most evolved language in the C family. Its clean, consistent, terse (without sacrificing readability) and expressive.

I also like the direction Java is going with the language enhancements in v7. In particular, I'm looking forward to annotations on Java types (primarily for parameter constraints) and language level support for clean modularization. My main gripes are the lack of first order properties and events.

Anyway, my point is that C# and Java are much better options for modern desktop development than Objective C. It was a great language 20 years ago, but its starting to show its age.

Comment by Ken Mayer on October 10, 2009 at 9:22pm

It's mostly historical and inertia, I suspect; NextSTEP was built on top of Objective C and Mach. MacRuby, although very rough, is supported by Apple and may become viable.

• ‹ Previous
• 1
• 2
• 3
• 4
• Next ›
• Page