Wow, there sure is a lot of hot air being blown around. How many of you have actually taken the time to write Cocoa programs? No? Then shut up, you don't know squat.
I'm a dyed-in-the-wool C++ programmer, and a C programmer before that, going back longer than I care to admit. I also write C#/.NET applications, and have used Python, Lua, and various other languages. When I first saw the Obj-C syntax my eyes bugged out and I thought, "never in a million years...". Then I wrote a pair of small Obj-C Cocoa apps. Now I wish I could do all my GUI work in Obj-C/Cocoa, especially on Leopard. This environment completely dominates everything except C#/.NET ... that environment is closer, but for most things I'd still choose Cocoa.
The syntax? Code in it for a couple of days and you'll get it. It is about sending messages to objects instead of calling functions. It carries a different conceptual connotation and so you want it to look different than function calls. So what if it uses square brackets instead of parenthesis, get over it.
[object method parameters];
isn't so different from
object->method(parameters);
If anything there is less syntax in the Obj-C. And the named parameters is a huge win in practice -- you can read method invocations like sentences. Auto-completion ought to eliminate most of the typing.
Full integration with C++ happens just by naming your files *.mm instead of *.m ... both of my first two apps had C++ cores and Obj-C GUIs. Now with all the CoreData and MVC stuff in Cocoa I would think hard about whether to do that or embrace Obj-C throughout -- that will mostly be a function of whether it needs to be portable to other operating systems or not. You should be factoring your GUI from your core application regardless of your development environment. Porting usually requires re-writing the GUI portion anyhow so having to do it in Obj-C isn't a hardship (C# is worse in that respect).
The Obj-C 2 improvements are nice. Properties are convenient syntactic sugar (which is something often treated dismissively, but shouldn't be). The garbage collector is a hugely important addition and critical to being productive in modern programming. People who turn their noses up at GC typically don't understand GC, or they are hardcore optimization types who ought to realize that time saved not doing memory management is time available to spend doing optimizations where they count.
As for Obj-C method dispatch efficiency, it is irrelevant. Perhaps back on the original NeXT with a 25 MHz 68030 (IIRC) it mattered, but on modern multi-GHz machines it doesn't matter. C#/.NET pays a higher penalty for its fully managed JIT environment, and even that isn't a big deal and can be worked around where you need to. In Obj-C you switch to function calls or C++ member functions where it counts.
I think that's why Apple added the dot syntax to Objective-C 2 and advertise it as an advantage. Whether or not it should make life easier once people are accustomed to it, in the short time that people have been exposed to it, developers have been complaining that the syntax makes their work harder. What other reason would there be for syntax change at all?
The 'dot syntax' is for properties which are conceptually like member variables to the user of a class. That's why they use the dot notation, not to make it more palatable for non-Obj-C users.
It sounds like you have roughly the same background as I do, but I don't understand your hang-ups about it. "Stepping through and debugging" Cocoa is virtually identical to all other languages. Your one specific complaint is about not understanding the Cocoa framework, but that holds true of many GUI frameworks and the solution is usually looking at more examples, reading the docs, and/or buying a book. There are a bunch of great Cocoa books, if you haven't read one. In the end the best way to familiarity is practice. Obj-C (actually mostly Cocoa) has a fairly steep learning curve initially, but it is well worth getting over it. And once you're over it, it seems easier to pick up additional frameworks than it does in other languages/environments.
How many of you have actually taken the time to write Cocoa programs?
I have written a fairly complex program using it - the project was close to 13,000 LOC, 3,000 being OBJ-C. It was a 3D modelling-type program so it had OpenGL in there too. I contributed all the OBJ-C and 1,000 LOC C++. It's still the hardest language I've ever used.
Little things like getting NSText from the GUI, converting to char* to pass to the C++ core and then back to NSText to print something in the GUI were just annoying. I saw places where the Cocoa libraries made things nice such as having a buffered NSOpenGL context that continuously updated on resizing but at the same time shortcomings that were hard to make up for like not storing a preview by default on minimizing (Carbon AGL seems to do this) and you were left trying to create an image preview yourself.
The program was also unstable because I wasn't sure of where the program was entering the code and I was creating instances all over the place just trying to get the program to run. Now yes, at the time I didn't have much experience at all and Cocoa was young so online tutorials were hard to find but my point is that there shouldn't be such a steep learning curve to OBJ-C. If people won't learn it then it won't take off.
It's all very well if someone who knows how to use roller skates tells a noob to keep learning as it will pay off. There's only so many times you smash your head on the concrete before you just say nope, there are easier and less painful ways to get the job done.
Quote:
Originally Posted by Programmer
Now I wish I could do all my GUI work in Obj-C/Cocoa, especially on Leopard.
I loved the interface tools overall - quickest interface builder I've used. But the interface only works with OS X so in future, if I need to write other interfaces, I'll probably use Qt. At least it uses a language I'm familiar with and is cross-platform.
Quote:
Originally Posted by Programmer
The syntax? Code in it for a couple of days and you'll get it.
3 months, no go. I just don't like it and I have no intention of using it again. I've used it once in the past 5 years but no more. The only languages I use these days are C, Python, PHP and Javascript. OBJ-C put me off low-level programming for good so I mainly use programming for application scripting and websites.
Quote:
Originally Posted by Programmer
[object method parameters];
isn't so different from
object->method(parameters);
It is because I use arrays all the time and it confuses me. When I was using OBJ-C, I got compile errors all the time from using the brackets wrongly. I know, I'd just need to learn it but it just didn't stick.
Quote:
Originally Posted by Programmer
Full integration with C++ happens just by naming your files *.mm instead of *.m ... both of my first two apps had C++ cores and Obj-C GUIs.
Yep same here. I found that kinda stupid, why couldn't it just use .cpp?
Quote:
Originally Posted by Programmer
People who turn their noses up at GC typically don't understand GC, or they are hardcore optimization types who ought to realize that time saved not doing memory management is time available to spend doing optimizations where they count.
I agree, I don't get it when people say they hate GC and won't use it.
Quote:
Originally Posted by Programmer
As for Obj-C method dispatch efficiency, it is irrelevant. Perhaps back on the original NeXT with a 25 MHz 68030 (IIRC) it mattered, but on modern multi-GHz machines it doesn't matter.
If two developers are equally good at C++ and OBJ-C and C++ runs faster then I'd say it matters. If OBJ-C was significantly easier to use then fine but for me it was much harder.
Quote:
Originally Posted by Programmer
And once you're over it, it seems easier to pick up additional frameworks than it does in other languages/environments.
I found Java much easier to pick up and it has a portable GUI but I don't like Java in general.
Excellent comments. Just a couple bones to pick...
Quote:
Originally Posted by Marvin
It's all very well if someone who knows how to use roller skates tells a noob to keep learning as it will pay off. There's only so many times you smash your head on the concrete before you just say nope, there are easier and less painful ways to get the job done.
My experience was that the cocoa API took infinately longer to learn than obj-C syntax. I think that the learning curve of the two are commonly, but mistakenly, conflated .
Quote:
If two developers are equally good at C++ and OBJ-C and C++ runs faster then I'd say it matters. If OBJ-C was significantly easier to use then fine but for me it was much harder.
It is also good to figure in ease of maintenance. The explicit verbosity of obj-c makes it easier to dive into someone else's code.
My experience was that the cocoa API took infinately longer to learn than obj-C syntax. I think that the learning curve of the two are commonly, but mistakenly, conflated.
Now you mention it, I do recall having problems with Apple's documentation. I don't have a very good memory and I always need a good reference handy and the ones supplied with Xcode were very difficult to use.
That was actually more time consuming than dealing with the syntax itself. I still had issue with the syntax but I'm sure I would have overcome them given enough time. Over the years I've become familiar with a few different languages and their quirks so maybe OBJ-C wouldn't be as much of a hurdle now.
Now you mention it, I do recall having problems with Apple's documentation.
So true.
A few years ago when I was learning Cocoa, much of the documentation simply didn't exist yet. Accessing that documentation revealed a page title and a couple section headers, but no content. Aggravating to say the least.
But that's one place where obj-c's verbosity helped somewhat. Finding an example online was often enough help to figure out exactly what was going on.
Now you mention it, I do recall having problems with Apple's documentation.
Apple's tools & docs have improved enormously -- Leopard's Xcode 3.0 sets a respectable standard and is comparable to .NET's docs (if not better in some ways). There are also some 3rd party tools (AppKido, for example) that are quite handy to keep the docs at your fingertips.
Strange that you guys had such troubles with the framework... I find it remarkably consistent and well designed. They have developed a set of well thought out patterns and applied them rigorously across the whole API. The learning curve is steep, but certainly not infinite... just one or two projects and most programmers are right at home. As with most environments you learn the tricks (such as NSString <-> char* conversion) and apply them as needed. The hardest part traditionally was usually the retain/release reference counting paradigm, and that has been replaced by the new GC.
For GUI programming in particular I find that Obj-C is far easier to use and less error prone than C++... and in my circles I'm regarded as something of a C++ guru.
I found Java much easier to pick up and it has a portable GUI but I don't like Java in general.
I learned C++ first, so Java was in some ways easy and in some ways far more maddening.
<rant> What idiot decided that all of the Java base classes should be declared final so you couldn't do something as simple as overload the == operator to intelligently compare the objects for yourself? And -- since they took control of the pointers away from the programmer -- how is it beneficial that their implementation of == compares whether they point to the same object? </rant>
Regardless, I wasn't aware that many people were still using the whole Java portable GUI thing. Most of the Java programmers I know are doing server-side programming to a web interface.
Strange that you guys had such troubles with the framework... I find it remarkably consistent and well designed.
It wasn't so much that I had trouble learning the framework, but rather that learning obj-c syntax was much simpler.
As with any API, familiarity is key and familiarity takes a while to achieve. I think people sometimes conceptually merge the two learning curves and come away thinking that obj-c systax was the source of their struggles. When in fact, obj-c was the easy part, followed by months of getting acustom to cocoa.
It's reassuring to hear that Apple has fleshed out the cocoa documentation. I seem to remember nearly 1/3 of the topics being "TBA" (or some such phrase). It made my early days, of learning cocoa, reliant on a bunch of guess work and trial and error. It sounds like new cocoa programmers have it much easier now.
Comments
I'm a dyed-in-the-wool C++ programmer, and a C programmer before that, going back longer than I care to admit. I also write C#/.NET applications, and have used Python, Lua, and various other languages. When I first saw the Obj-C syntax my eyes bugged out and I thought, "never in a million years...". Then I wrote a pair of small Obj-C Cocoa apps. Now I wish I could do all my GUI work in Obj-C/Cocoa, especially on Leopard. This environment completely dominates everything except C#/.NET ... that environment is closer, but for most things I'd still choose Cocoa.
The syntax? Code in it for a couple of days and you'll get it. It is about sending messages to objects instead of calling functions. It carries a different conceptual connotation and so you want it to look different than function calls. So what if it uses square brackets instead of parenthesis, get over it.
[object method parameters];
isn't so different from
object->method(parameters);
If anything there is less syntax in the Obj-C. And the named parameters is a huge win in practice -- you can read method invocations like sentences. Auto-completion ought to eliminate most of the typing.
Full integration with C++ happens just by naming your files *.mm instead of *.m ... both of my first two apps had C++ cores and Obj-C GUIs. Now with all the CoreData and MVC stuff in Cocoa I would think hard about whether to do that or embrace Obj-C throughout -- that will mostly be a function of whether it needs to be portable to other operating systems or not. You should be factoring your GUI from your core application regardless of your development environment. Porting usually requires re-writing the GUI portion anyhow so having to do it in Obj-C isn't a hardship (C# is worse in that respect).
The Obj-C 2 improvements are nice. Properties are convenient syntactic sugar (which is something often treated dismissively, but shouldn't be). The garbage collector is a hugely important addition and critical to being productive in modern programming. People who turn their noses up at GC typically don't understand GC, or they are hardcore optimization types who ought to realize that time saved not doing memory management is time available to spend doing optimizations where they count.
As for Obj-C method dispatch efficiency, it is irrelevant. Perhaps back on the original NeXT with a 25 MHz 68030 (IIRC) it mattered, but on modern multi-GHz machines it doesn't matter. C#/.NET pays a higher penalty for its fully managed JIT environment, and even that isn't a big deal and can be worked around where you need to. In Obj-C you switch to function calls or C++ member functions where it counts.
I think that's why Apple added the dot syntax to Objective-C 2 and advertise it as an advantage. Whether or not it should make life easier once people are accustomed to it, in the short time that people have been exposed to it, developers have been complaining that the syntax makes their work harder. What other reason would there be for syntax change at all?
The 'dot syntax' is for properties which are conceptually like member variables to the user of a class. That's why they use the dot notation, not to make it more palatable for non-Obj-C users.
It sounds like you have roughly the same background as I do, but I don't understand your hang-ups about it. "Stepping through and debugging" Cocoa is virtually identical to all other languages. Your one specific complaint is about not understanding the Cocoa framework, but that holds true of many GUI frameworks and the solution is usually looking at more examples, reading the docs, and/or buying a book. There are a bunch of great Cocoa books, if you haven't read one. In the end the best way to familiarity is practice. Obj-C (actually mostly Cocoa) has a fairly steep learning curve initially, but it is well worth getting over it. And once you're over it, it seems easier to pick up additional frameworks than it does in other languages/environments.
Now that we know you're still lurking, your lurking gig is up. Cough up those posts already.
How many of you have actually taken the time to write Cocoa programs?
I have written a fairly complex program using it - the project was close to 13,000 LOC, 3,000 being OBJ-C. It was a 3D modelling-type program so it had OpenGL in there too. I contributed all the OBJ-C and 1,000 LOC C++. It's still the hardest language I've ever used.
Little things like getting NSText from the GUI, converting to char* to pass to the C++ core and then back to NSText to print something in the GUI were just annoying. I saw places where the Cocoa libraries made things nice such as having a buffered NSOpenGL context that continuously updated on resizing but at the same time shortcomings that were hard to make up for like not storing a preview by default on minimizing (Carbon AGL seems to do this) and you were left trying to create an image preview yourself.
The program was also unstable because I wasn't sure of where the program was entering the code and I was creating instances all over the place just trying to get the program to run. Now yes, at the time I didn't have much experience at all and Cocoa was young so online tutorials were hard to find but my point is that there shouldn't be such a steep learning curve to OBJ-C. If people won't learn it then it won't take off.
It's all very well if someone who knows how to use roller skates tells a noob to keep learning as it will pay off. There's only so many times you smash your head on the concrete before you just say nope, there are easier and less painful ways to get the job done.
Now I wish I could do all my GUI work in Obj-C/Cocoa, especially on Leopard.
I loved the interface tools overall - quickest interface builder I've used. But the interface only works with OS X so in future, if I need to write other interfaces, I'll probably use Qt. At least it uses a language I'm familiar with and is cross-platform.
The syntax? Code in it for a couple of days and you'll get it.
3 months, no go. I just don't like it and I have no intention of using it again. I've used it once in the past 5 years but no more. The only languages I use these days are C, Python, PHP and Javascript. OBJ-C put me off low-level programming for good so I mainly use programming for application scripting and websites.
[object method parameters];
isn't so different from
object->method(parameters);
It is because I use arrays all the time and it confuses me. When I was using OBJ-C, I got compile errors all the time from using the brackets wrongly. I know, I'd just need to learn it but it just didn't stick.
Full integration with C++ happens just by naming your files *.mm instead of *.m ... both of my first two apps had C++ cores and Obj-C GUIs.
Yep same here. I found that kinda stupid, why couldn't it just use .cpp?
People who turn their noses up at GC typically don't understand GC, or they are hardcore optimization types who ought to realize that time saved not doing memory management is time available to spend doing optimizations where they count.
I agree, I don't get it when people say they hate GC and won't use it.
As for Obj-C method dispatch efficiency, it is irrelevant. Perhaps back on the original NeXT with a 25 MHz 68030 (IIRC) it mattered, but on modern multi-GHz machines it doesn't matter.
If two developers are equally good at C++ and OBJ-C and C++ runs faster then I'd say it matters. If OBJ-C was significantly easier to use then fine but for me it was much harder.
And once you're over it, it seems easier to pick up additional frameworks than it does in other languages/environments.
I found Java much easier to pick up and it has a portable GUI but I don't like Java in general.
It's all very well if someone who knows how to use roller skates tells a noob to keep learning as it will pay off. There's only so many times you smash your head on the concrete before you just say nope, there are easier and less painful ways to get the job done.
My experience was that the cocoa API took infinately longer to learn than obj-C syntax. I think that the learning curve of the two are commonly, but mistakenly, conflated .
If two developers are equally good at C++ and OBJ-C and C++ runs faster then I'd say it matters. If OBJ-C was significantly easier to use then fine but for me it was much harder.
It is also good to figure in ease of maintenance. The explicit verbosity of obj-c makes it easier to dive into someone else's code.
My experience was that the cocoa API took infinately longer to learn than obj-C syntax. I think that the learning curve of the two are commonly, but mistakenly, conflated.
Now you mention it, I do recall having problems with Apple's documentation. I don't have a very good memory and I always need a good reference handy and the ones supplied with Xcode were very difficult to use.
That was actually more time consuming than dealing with the syntax itself. I still had issue with the syntax but I'm sure I would have overcome them given enough time. Over the years I've become familiar with a few different languages and their quirks so maybe OBJ-C wouldn't be as much of a hurdle now.
Now you mention it, I do recall having problems with Apple's documentation.
So true.
A few years ago when I was learning Cocoa, much of the documentation simply didn't exist yet. Accessing that documentation revealed a page title and a couple section headers, but no content. Aggravating to say the least.
But that's one place where obj-c's verbosity helped somewhat. Finding an example online was often enough help to figure out exactly what was going on.
Now you mention it, I do recall having problems with Apple's documentation.
Apple's tools & docs have improved enormously -- Leopard's Xcode 3.0 sets a respectable standard and is comparable to .NET's docs (if not better in some ways). There are also some 3rd party tools (AppKido, for example) that are quite handy to keep the docs at your fingertips.
Strange that you guys had such troubles with the framework... I find it remarkably consistent and well designed. They have developed a set of well thought out patterns and applied them rigorously across the whole API. The learning curve is steep, but certainly not infinite... just one or two projects and most programmers are right at home. As with most environments you learn the tricks (such as NSString <-> char* conversion) and apply them as needed. The hardest part traditionally was usually the retain/release reference counting paradigm, and that has been replaced by the new GC.
For GUI programming in particular I find that Obj-C is far easier to use and less error prone than C++... and in my circles I'm regarded as something of a C++ guru.
I found Java much easier to pick up and it has a portable GUI but I don't like Java in general.
I learned C++ first, so Java was in some ways easy and in some ways far more maddening.
<rant> What idiot decided that all of the Java base classes should be declared final so you couldn't do something as simple as overload the == operator to intelligently compare the objects for yourself? And -- since they took control of the pointers away from the programmer -- how is it beneficial that their implementation of == compares whether they point to the same object? </rant>
Regardless, I wasn't aware that many people were still using the whole Java portable GUI thing. Most of the Java programmers I know are doing server-side programming to a web interface.
Strange that you guys had such troubles with the framework... I find it remarkably consistent and well designed.
It wasn't so much that I had trouble learning the framework, but rather that learning obj-c syntax was much simpler.
As with any API, familiarity is key and familiarity takes a while to achieve. I think people sometimes conceptually merge the two learning curves and come away thinking that obj-c systax was the source of their struggles. When in fact, obj-c was the easy part, followed by months of getting acustom to cocoa.
It's reassuring to hear that Apple has fleshed out the cocoa documentation. I seem to remember nearly 1/3 of the topics being "TBA" (or some such phrase). It made my early days, of learning cocoa, reliant on a bunch of guess work and trial and error. It sounds like new cocoa programmers have it much easier now.