Wanking about Carbon vs Cocoa applications is only an indication of not knowing what someone is wanking about in the first place. Heck, a lot of Cocoa API's are just implemented as Obj-C wrappers around Carbon APIs.
Far more important is does something work, not what API is it coded in?
Mostly true Hiro, but perhaps overstating the case. While it is over simplification to generalize about all cocoa apps vs. all carbon apps. It is also over simplification to say that the difference doesn't matter. Developer tools and APIs certainly do matter, even though they aren't the only factors to look at.
Note that the original poster didn't make any claims about possible benefits of a rewrite. Rather he asked a reasonable question, has the finder been rewritten in cocoa?
Sorry, I don't know the answer to that question. Although I'd bet that the vast majority of its code base is carbon, or even older/lower. Keep in mind, programs can simultaneously rely on a mixture of carbon, cocoa, and other APIs.
Mostly true Hiro, but perhaps overstating the case. While it is over simplification to generalize about all cocoa apps vs. all carbon apps. It is also over simplification to say that the difference doesn't matter. Developer tools and APIs certainly do matter, even though they aren't the only factors to look at.
Note that the original poster didn't make any claims about possible benefits of a rewrite. Rather he asked a reasonable question, has the finder been rewritten in cocoa?
Sorry, I don't know the answer to that question. Although I'd bet that the vast majority of it's code base is carbon, or even older/lower. Keep in mind, programs can simultaneously rely on a mixture of carbon, cocoa, and other APIs.
Hope I'm not hijacking with this question, but I've just been taking my first baby steps into XCode and have been trying my luck with the Cocoa API. Are there any relative merits of one over the other re. Cocoa/Carbon in terms of what you can do?
The Cocoa API is accessed with Objective-C, whereas the Carbon API is accessed via C code. As mentioned, many fundamental Cocoa methods are not duplicated but are just wrappers for the corresponding method in Carbon. You can see this in action in the debugger - you will see the Carbon code called as a result of your calling the Cocoa method.
The benefit of Cocoa is that it has very sophisticated integration with the GUI, and very little code is required to draw the GUI. Also, Cocoa Bindings allows you to basically tie together an object on the GUI (the View) and a data value or object in your code (the model) so that a change in one is automatically reflected in the other.
You can mix Carbon and Cocoa calls as you wish, and there are many methods that are "toll-free bridged" between the two APIs, in the sense that the exact same parameters can be passed to either and give the same results.
The main difference is learning Objective-C for Cocoa.
EDIT: I should mention that Apple is pushing everyone to move to Cocoa. The last I heard, they were not going to make the Carbon frameworks 64-bit.
As a general rule, Carbon is only needed 1) For those who need to have their app run under OS 9; 2)Existing PowerPC apps being ported to OS X; and 3) Special-case low-level code that may be easier to write in Carbon. Apple has long advised all new applications be written to the Cocoa API.
I agree with lundy. And would say in my opinion Cocoa is easier once you have the basics of Obj-C in hand. You should be able to spend a bit more time on program features rather than working around C++ decoration and debugging.
dfiler, I take the "has the Cocoa love" as a bias indicator. The quote is too leading to be a simple innocent question. Hence the need for repeating the tired, age old standard about OS X APIs.
EDIT: I should mention that Apple is pushing everyone to move to Cocoa. The last I heard, they were not going to make the Carbon frameworks 64-bit.
Thanks for the answer, that clears up quite a few things in my mind. This may be a silly question, like I said I'm very much a beginner to coding, but given that 10.5 is still largely carbon but is also a 64-bit OS, does that imply that the XCode frameworks have nothing to do with the development of the OS itself?
I don't like them using the term Carbon as it implies it's old-fashioned. Last time I checked, most people still use C, C++. Objective-C usage is very small and I don't like using it.
If they wanted better uptake, they should have used better syntax from the outset.
Objective-C 2 helps so that when you address variables you can use:
Function calls would have been nice too so you could do Person.alloc().init().
To some it's a minor issue but when PHP, Javascript, Java, C, C++, Python and so on have largely the same syntax and Obj-C has all these funky brackets, it just makes it harder to learn unnecessarily.
given that 10.5 is still largely carbon but is also a 64-bit OS, does that imply that the XCode frameworks have nothing to do with the development of the OS itself?
Yes and no. I don't think we can know the details without more info from Apple, but in general, the OS itself does not always need to be 64-bit code in order to handle user apps that are 64-bit. For example, the Mach kernel is still 32-bit.
Apple could have updated those Carbon APIs that needed to be updated for the system to call into, and left the rest alone.
I think what they really are saying to developers is "don't think you can write a true 64-bit app by calling only into Carbon, because a lot of it isn't getting updated."
From what they always say at WWDC, yes, OS X is compiled in Xcode. To me, that means that the source is a mixture of C and Objective-C, with maybe a very very few assembler tweaks. Assembler isn't really needed in most cases of writing SSE or Altivec code, as that is handled by the super-optimized Accelerate framework.
Heh - agreed that Obj-C can be a bitch to get used to, especially for those of us with 40 years of writing procedural code. It's like using a Reverse Polish Prefix calculator - everything reads from right to left, sort of.
That's the main reason that Windows developers can't easily write a Mac app - a new one requires Objective-C.
The Cocoa frameworks were of course, NeXt routines, and wanted to be called from Objective-C code, so making them all callable from C or C++ may be a huge undertaking.
I agree that 2.0 cuts out some of the drudgery. With garbage collection and Cocoa Bindings, once you learn that, your coding speeds up astronomically because you don't have to worry about memory allocation or leaks or writing code to generate the GUI. But it is a fairly steep initial curve. And Apple's habit of naming everything with bizarre names does not help - Core Foundation, Foundation, Core Services, Cocoa....
I don't like them using the term Carbon as it implies it's old-fashioned. Last time I checked, most people still use C, C++. Objective-C usage is very small and I don't like using it.
If they wanted better uptake, they should have used better syntax from the outset.
Objective-C 2 helps so that when you address variables you can use:
Function calls would have been nice too so you could do Person.alloc().init().
To some it's a minor issue but when PHP, Javascript, Java, C, C++, Python and so on have largely the same syntax and Obj-C has all these funky brackets, it just makes it harder to learn unnecessarily.
It's not a minor issue at all - but not in the way you think. Having a distinct syntax for raw C vs. OO code makes writing the compiler *much* easier. No LR(n) shenanigans necessary. (Hell, C++ is an abomination because of this. It's just asinine in some boundary cases.) Not only that, but it provides a clean delineation between code that is going to pass through the Obj-C runtime, and code that is going to not.
I've never understood the anti-brackets mentality. Seriously, we can adapt to lolspeak, but we can't frickin' adapt to a minor change in punctuation? o.O The brackets carry semantic meaning distinct from the dot notation - wanting to merge them loses that unnecessarily.
I'm a big fan of the brackets and the verbosity too. The little bit of extra time spent typing that is way more than compensated for by clarity resulting in fewer decoration induced bugs.
Having a distinct syntax for raw C vs. OO code makes writing the compiler *much* easier.
Sure but I'd say that most code will have at least some mix of C, C++. I doubt that there are many programs that are completely Objective-C. In fact, I would bet most people do the GUI with OBJ-C because Apple practically make you use it and then do the back-end in C or C++. This makes writing code much harder - maybe not for everyone but for some it does.
A lot of programs that are ports will have to do things this way.
24057 projects on sourceforge using C++
20468 using C
1062 using Objective-C
Similar ratio to Apple's market share 20:1.
If Objective-C was a widely available language (i.e. libraries etc.) that had the possibility of uptake cross-platform then it might be a different story but I can't see Mac programs ever being more than hybrid C, C++, OBJ-C and the syntax will always be a hurdle when multiple languages are combined.
For the compiler parsing, they could easily have used something like what's used in web programming. <?php ?> braces between code blocks.
Brackets aren't as simple to change to as lolspeak. There you are simply replacing words. It would be like replacing punctuation as it changes the meaning of things entirely. Square braces have always been used for arrays. To use them for function calls and addressing variables is extremely confusing.
Quote:
Originally Posted by Hiro
The little bit of extra time spent typing
I'm not much of a fan of typing, I like to abbreviate code as much as possible. I see the advantage of meaningful names but you can be concise and maintain the same clarity. I wish XCode had some decent auto-completing functionality.
Sure but I'd say that most code will have at least some mix of C, C++. I doubt that there are many programs that are completely Objective-C. In fact, I would bet most people do the GUI with OBJ-C because Apple practically make you use it and then do the back-end in C or C++. This makes writing code much harder - maybe not for everyone but for some it does.
A lot of programs that are ports will have to do things this way.
24057 projects on sourceforge using C++
20468 using C
1062 using Objective-C
Similar ratio to Apple's market share 20:1.
If Objective-C was a widely available language (i.e. libraries etc.) that had the possibility of uptake cross-platform then it might be a different story but I can't see Mac programs ever being more than hybrid C, C++, OBJ-C and the syntax will always be a hurdle when multiple languages are combined.
For the compiler parsing, they could easily have used something like what's used in web programming. <?php ?> braces between code blocks.
Brackets aren't as simple to change to as lolspeak. There you are simply replacing words. It would be like replacing punctuation as it changes the meaning of things entirely. Square braces have always been used for arrays. To use them for function calls and addressing variables is extremely confusing.
I'm not much of a fan of typing, I like to abbreviate code as much as possible. I see the advantage of meaningful names but you can be concise and maintain the same clarity. I wish XCode had some decent auto-completing functionality.
Objective-C is a superset of C. Show me all the GUI based C programs running in OS X. I thought not.
Heh - agreed that Obj-C can be a bitch to get used to, especially for those of us with 40 years of writing procedural code. It's like using a Reverse Polish Prefix calculator - everything reads from right to left, sort of.
That's the main reason that Windows developers can't easily write a Mac app - a new one requires Objective-C.
The Cocoa frameworks were of course, NeXt routines, and wanted to be called from Objective-C code, so making them all callable from C or C++ may be a huge undertaking.
I agree that 2.0 cuts out some of the drudgery. With garbage collection and Cocoa Bindings, once you learn that, your coding speeds up astronomically because you don't have to worry about memory allocation or leaks or writing code to generate the GUI. But it is a fairly steep initial curve. And Apple's habit of naming everything with bizarre names does not help - Core Foundation, Foundation, Core Services, Cocoa....
C reads from right to left. It's the brackets you can't seem to grasp.
I don't think you're getting it, but I'll give it a shot.
Quote:
Originally Posted by Marvin
Sure but I'd say that most code will have at least some mix of C, C++. I doubt that there are many programs that are completely Objective-C. In fact, I would bet most people do the GUI with OBJ-C because Apple practically make you use it and then do the back-end in C or C++. This makes writing code much harder - maybe not for everyone but for some it does.
1) Obj-C is a strict superset of C. Any C program is also an Obj-C program, by definition.
2) Allowing mix and match of C++ is bad... how?
Quote:
A lot of programs that are ports will have to do things this way.
24057 projects on sourceforge using C++
20468 using C
1062 using Objective-C
Similar ratio to Apple's market share 20:1.
If Objective-C was a widely available language (i.e. libraries etc.) that had the possibility of uptake cross-platform then it might be a different story but I can't see Mac programs ever being more than hybrid C, C++, OBJ-C and the syntax will always be a hurdle when multiple languages are combined.
Again, ...
Porting an app to Obj-C from C is... nothing. It's done. Have a C library and want to use it in an Obj-C GUI Mac app? *Just use it*. There's *no* porting.
C++? Same thing. Just use it. You're done. Finis.
Quote:
For the compiler parsing, they could easily have used something like what's used in web programming. <?php ?> braces between code blocks.
This is what tells me you're really not getting it - going between C and Obj-C happens at the expression level. Going between C++ and Obj-C happens at the statement level. Go on, write such code with code block delimiters... try it out.
Quote:
Brackets aren't as simple to change to as lolspeak. There you are simply replacing words. It would be like replacing punctuation as it changes the meaning of things entirely. Square braces have always been used for arrays. To use them for function calls and addressing variables is extremely confusing.
[a]
[a b]
Yes, I can see how those are utterly confusing.
C++ mangled the dot notation of C, horribly overloading it. (And let's not get started on templates - suddenly a < is less-than, a template open bracket, or the first half of a left-bit-shift. Scan ahead one char to find out? Nope, sorry, it could be nested template brackets, keep going...)
Obj-C added bracket notation, and prepending of @ to Obj-C keywords. It is clear, simple, and obvious which bits of code are OO, and which are raw procedural. You simply cannot do that with C++ code. Quick, is the following subject to RTTI rules?
a = b.c + d->e();
Dunno. Could be that b and d are objects, but b could be a struct, and d a union holding a function pointer whose value is being called. You have no idea without going code diving. OTOH...
a = b.c + [d e];
Now you know that b is a POD type, and d is an object. You can see exactly which portions of code are subject to possible runtime
issues and optimizations, and which aren't. You also have a clear line between those sections of code that are MacOS X-only, and which are instantly available for porting cross-platform... or that came from an external cross-platform source.
Clear lines, simple delineations, and obvious semantics for both the compiler *and* the developer. The only reason C++ makes sense to you is that it's what you're used to. Having been around when the syntax wasn't exactly nailed down, and there was still a lot of discussion floating around on how things should be laid out... it's messy. It's more than messy, it's just plain nuts, if you ask me. They had an overriding concern to make object code look like procedural code, but keep procedural code around, and somehow not confuse anyone (or the compiler) between the two? Nuts.
Quote:
I'm not much of a fan of typing, I like to abbreviate code as much as possible. I see the advantage of meaningful names but you can be concise and maintain the same clarity. I wish XCode had some decent auto-completing functionality.
I assume you mean the named parameters? Sorry, have to disagree with you here - clarity trumps keystrokes in almost every case. Saving a second now to add hours, days, or weeks of code tracing and debugging later is lunacy. Code that can't tell you straight-up what it does without diving through layers of headers and source files is just a pain in the ass.
Ditto on the auto-completing in XCode - that's the proper way to solve the problem. You get reduced keystrokes, I get clear, clean code. Everyone wins.
Objective-C is a superset of C. Show me all the GUI based C programs running in OS X. I thought not.
Most of them will be. It's just the GUI that's written in OBJ-C. I know that OBJ-C is a superset of C but C code looks a lot different from OBJ-C because of the syntax.
Quote:
Originally Posted by Kickaha
Allowing mix and match of C++ is bad... how?
The ability to do that is not a problem but the syntax difference isn't easy to switch between. It's like writing dans French and English in une sentence. If I remember right you have to use a .cxx extension for cpp files you want to use with OBJ-C (they are called OBJ-C++ or something) and I think you have to use the dot notation from OBJ-C code to address C++ code. Once I had it figured out it wasn't too bad but it's not easy to begin with. For a language to become popular there just shouldn't be any barriers at all.
For someone who has come from coding C++ to approach OBJ-C, they have to weigh up the advantages and disadvantages.
Advantages: cleaner code and possibly more efficient code
Disadvantages: unique syntax that is different from most languages, Mac only pretty much, performance advantage due to efficient coding is negated by slower runtime (OBJ-C is generally slower in benchmarks than C and C++ doing the same job).
Quote:
Originally Posted by Kickaha
[a]
[a b]
Yes, I can see how those are utterly confusing.
Try doing that in a C function though and it won't work. Although OBJ-C is a superset of C, you still have to use different rules for each language so you're still using two languages at once. C++ resembles C way more than OBJ-C does.
Quote:
Originally Posted by Kickaha
You also have a clear line between those sections of code that are MacOS X-only
No code should be limited to one platform though and until OBJ-C gets cross-platform uptake then it will always be limited in usefulness.
Quote:
Originally Posted by Kickaha
The only reason C++ makes sense to you is that it's what you're used to.
Yes, I agree entirely. But that's the thing, I used to have notions of doing things the 'right' way as in the theoretically better way of doing something. However, when it comes to just getting the job done, that's not always the right option. I find that because I am so used to using a certain way of coding that changing over is very difficult. No doubt if I'd started with Smalltalk things would be different but I learned languages in the order C -> Java -> C++ -> Objective-C -> Python -> PHP and the most difficult language I ever tried to learn was Objective-C. It took me weeks just to get round the basics. I couldn't figure out where the program started from. NSWakeUpFromNib just wasn't getting through at all.
The other languages are so clear to me that I can step through and debug the code very easily. Theoretically the other languages may be less flexible but practically they just work better for me and I haven't found them to be limiting at all.
Try doing that in a C function though and it won't work. Although OBJ-C is a superset of C, you still have to use different rules for each language so you're still using two languages at once. C++ resembles C way more than OBJ-C does.
That's a big problem though! Yo can get all wrapped around what exactly that eerily similar C/C++ syntax is actually doing depending on the context of the syntax around it. Talk about a pain in the ass when you are trying to understand the code someone else wrote, or you wrote months ago!
With Obj-C, either the syntax is a pure C statement, or it is Obj-C statement. There is no room for confusion. Yes, getting to like this is a transition not all folks want to undertake, but in the long run it will make coding easier. And Apple is allowing folks to choose what they want to use where, with only the slightest of pushes about the future, but I do expect that to change over the long run.
With Obj-C, either the syntax is a pure C statement, or it is Obj-C statement. There is no room for confusion. Yes, getting to like this is a transition not all folks want to undertake, but in the long run it will make coding easier.
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?
Comments
Wanking about Carbon vs Cocoa applications is only an indication of not knowing what someone is wanking about in the first place. Heck, a lot of Cocoa API's are just implemented as Obj-C wrappers around Carbon APIs.
Far more important is does something work, not what API is it coded in?
Note that the original poster didn't make any claims about possible benefits of a rewrite. Rather he asked a reasonable question, has the finder been rewritten in cocoa?
Sorry, I don't know the answer to that question. Although I'd bet that the vast majority of its code base is carbon, or even older/lower. Keep in mind, programs can simultaneously rely on a mixture of carbon, cocoa, and other APIs.
Just wondering if it is still Carbon, or now has the Cocoa love.
It's all Carbon except the coverflow view, which uses HICocoaView.
Amorya
Mostly true Hiro, but perhaps overstating the case. While it is over simplification to generalize about all cocoa apps vs. all carbon apps. It is also over simplification to say that the difference doesn't matter. Developer tools and APIs certainly do matter, even though they aren't the only factors to look at.
Note that the original poster didn't make any claims about possible benefits of a rewrite. Rather he asked a reasonable question, has the finder been rewritten in cocoa?
Sorry, I don't know the answer to that question. Although I'd bet that the vast majority of it's code base is carbon, or even older/lower. Keep in mind, programs can simultaneously rely on a mixture of carbon, cocoa, and other APIs.
Hope I'm not hijacking with this question, but I've just been taking my first baby steps into XCode and have been trying my luck with the Cocoa API. Are there any relative merits of one over the other re. Cocoa/Carbon in terms of what you can do?
The benefit of Cocoa is that it has very sophisticated integration with the GUI, and very little code is required to draw the GUI. Also, Cocoa Bindings allows you to basically tie together an object on the GUI (the View) and a data value or object in your code (the model) so that a change in one is automatically reflected in the other.
You can mix Carbon and Cocoa calls as you wish, and there are many methods that are "toll-free bridged" between the two APIs, in the sense that the exact same parameters can be passed to either and give the same results.
The main difference is learning Objective-C for Cocoa.
EDIT: I should mention that Apple is pushing everyone to move to Cocoa. The last I heard, they were not going to make the Carbon frameworks 64-bit.
As a general rule, Carbon is only needed 1) For those who need to have their app run under OS 9; 2)Existing PowerPC apps being ported to OS X; and 3) Special-case low-level code that may be easier to write in Carbon. Apple has long advised all new applications be written to the Cocoa API.
dfiler, I take the "has the Cocoa love" as a bias indicator. The quote is too leading to be a simple innocent question. Hence the need for repeating the tired, age old standard about OS X APIs.
EDIT: I should mention that Apple is pushing everyone to move to Cocoa. The last I heard, they were not going to make the Carbon frameworks 64-bit.
Thanks for the answer, that clears up quite a few things in my mind. This may be a silly question, like I said I'm very much a beginner to coding, but given that 10.5 is still largely carbon but is also a 64-bit OS, does that imply that the XCode frameworks have nothing to do with the development of the OS itself?
If they wanted better uptake, they should have used better syntax from the outset.
Objective-C 2 helps so that when you address variables you can use:
Person *bill = [[Person alloc] init];
bill.location = @"Home";
NSLog(@"Bill's location: %@", bill.location);
instead of:
Person *bill = [[Person alloc] init];
[bill setLocation:@"Home"];
NSLog(@"Bill's location: %@", [bill location]);
Function calls would have been nice too so you could do Person.alloc().init().
To some it's a minor issue but when PHP, Javascript, Java, C, C++, Python and so on have largely the same syntax and Obj-C has all these funky brackets, it just makes it harder to learn unnecessarily.
given that 10.5 is still largely carbon but is also a 64-bit OS, does that imply that the XCode frameworks have nothing to do with the development of the OS itself?
Yes and no. I don't think we can know the details without more info from Apple, but in general, the OS itself does not always need to be 64-bit code in order to handle user apps that are 64-bit. For example, the Mach kernel is still 32-bit.
Apple could have updated those Carbon APIs that needed to be updated for the system to call into, and left the rest alone.
I think what they really are saying to developers is "don't think you can write a true 64-bit app by calling only into Carbon, because a lot of it isn't getting updated."
From what they always say at WWDC, yes, OS X is compiled in Xcode. To me, that means that the source is a mixture of C and Objective-C, with maybe a very very few assembler tweaks. Assembler isn't really needed in most cases of writing SSE or Altivec code, as that is handled by the super-optimized Accelerate framework.
That's the main reason that Windows developers can't easily write a Mac app - a new one requires Objective-C.
The Cocoa frameworks were of course, NeXt routines, and wanted to be called from Objective-C code, so making them all callable from C or C++ may be a huge undertaking.
I agree that 2.0 cuts out some of the drudgery. With garbage collection and Cocoa Bindings, once you learn that, your coding speeds up astronomically because you don't have to worry about memory allocation or leaks or writing code to generate the GUI. But it is a fairly steep initial curve. And Apple's habit of naming everything with bizarre names does not help - Core Foundation, Foundation, Core Services, Cocoa....
I don't like them using the term Carbon as it implies it's old-fashioned. Last time I checked, most people still use C, C++. Objective-C usage is very small and I don't like using it.
If they wanted better uptake, they should have used better syntax from the outset.
Objective-C 2 helps so that when you address variables you can use:
Person *bill = [[Person alloc] init];
bill.location = @"Home";
NSLog(@"Bill's location: %@", bill.location);
instead of:
Person *bill = [[Person alloc] init];
[bill setLocation:@"Home"];
NSLog(@"Bill's location: %@", [bill location]);
Function calls would have been nice too so you could do Person.alloc().init().
To some it's a minor issue but when PHP, Javascript, Java, C, C++, Python and so on have largely the same syntax and Obj-C has all these funky brackets, it just makes it harder to learn unnecessarily.
It's not a minor issue at all - but not in the way you think. Having a distinct syntax for raw C vs. OO code makes writing the compiler *much* easier. No LR(n) shenanigans necessary. (Hell, C++ is an abomination because of this. It's just asinine in some boundary cases.) Not only that, but it provides a clean delineation between code that is going to pass through the Obj-C runtime, and code that is going to not.
I've never understood the anti-brackets mentality. Seriously, we can adapt to lolspeak, but we can't frickin' adapt to a minor change in punctuation? o.O The brackets carry semantic meaning distinct from the dot notation - wanting to merge them loses that unnecessarily.
Having a distinct syntax for raw C vs. OO code makes writing the compiler *much* easier.
Sure but I'd say that most code will have at least some mix of C, C++. I doubt that there are many programs that are completely Objective-C. In fact, I would bet most people do the GUI with OBJ-C because Apple practically make you use it and then do the back-end in C or C++. This makes writing code much harder - maybe not for everyone but for some it does.
A lot of programs that are ports will have to do things this way.
24057 projects on sourceforge using C++
20468 using C
1062 using Objective-C
Similar ratio to Apple's market share 20:1.
If Objective-C was a widely available language (i.e. libraries etc.) that had the possibility of uptake cross-platform then it might be a different story but I can't see Mac programs ever being more than hybrid C, C++, OBJ-C and the syntax will always be a hurdle when multiple languages are combined.
For the compiler parsing, they could easily have used something like what's used in web programming. <?php ?> braces between code blocks.
Brackets aren't as simple to change to as lolspeak. There you are simply replacing words. It would be like replacing punctuation as it changes the meaning of things entirely. Square braces have always been used for arrays. To use them for function calls and addressing variables is extremely confusing.
The little bit of extra time spent typing
I'm not much of a fan of typing, I like to abbreviate code as much as possible. I see the advantage of meaningful names but you can be concise and maintain the same clarity. I wish XCode had some decent auto-completing functionality.
Sure but I'd say that most code will have at least some mix of C, C++. I doubt that there are many programs that are completely Objective-C. In fact, I would bet most people do the GUI with OBJ-C because Apple practically make you use it and then do the back-end in C or C++. This makes writing code much harder - maybe not for everyone but for some it does.
A lot of programs that are ports will have to do things this way.
24057 projects on sourceforge using C++
20468 using C
1062 using Objective-C
Similar ratio to Apple's market share 20:1.
If Objective-C was a widely available language (i.e. libraries etc.) that had the possibility of uptake cross-platform then it might be a different story but I can't see Mac programs ever being more than hybrid C, C++, OBJ-C and the syntax will always be a hurdle when multiple languages are combined.
For the compiler parsing, they could easily have used something like what's used in web programming. <?php ?> braces between code blocks.
Brackets aren't as simple to change to as lolspeak. There you are simply replacing words. It would be like replacing punctuation as it changes the meaning of things entirely. Square braces have always been used for arrays. To use them for function calls and addressing variables is extremely confusing.
I'm not much of a fan of typing, I like to abbreviate code as much as possible. I see the advantage of meaningful names but you can be concise and maintain the same clarity. I wish XCode had some decent auto-completing functionality.
Objective-C is a superset of C. Show me all the GUI based C programs running in OS X. I thought not.
Heh - agreed that Obj-C can be a bitch to get used to, especially for those of us with 40 years of writing procedural code. It's like using a Reverse Polish Prefix calculator - everything reads from right to left, sort of.
That's the main reason that Windows developers can't easily write a Mac app - a new one requires Objective-C.
The Cocoa frameworks were of course, NeXt routines, and wanted to be called from Objective-C code, so making them all callable from C or C++ may be a huge undertaking.
I agree that 2.0 cuts out some of the drudgery. With garbage collection and Cocoa Bindings, once you learn that, your coding speeds up astronomically because you don't have to worry about memory allocation or leaks or writing code to generate the GUI. But it is a fairly steep initial curve. And Apple's habit of naming everything with bizarre names does not help - Core Foundation, Foundation, Core Services, Cocoa....
C reads from right to left. It's the brackets you can't seem to grasp.
Sure but I'd say that most code will have at least some mix of C, C++. I doubt that there are many programs that are completely Objective-C. In fact, I would bet most people do the GUI with OBJ-C because Apple practically make you use it and then do the back-end in C or C++. This makes writing code much harder - maybe not for everyone but for some it does.
1) Obj-C is a strict superset of C. Any C program is also an Obj-C program, by definition.
2) Allowing mix and match of C++ is bad... how?
A lot of programs that are ports will have to do things this way.
24057 projects on sourceforge using C++
20468 using C
1062 using Objective-C
Similar ratio to Apple's market share 20:1.
If Objective-C was a widely available language (i.e. libraries etc.) that had the possibility of uptake cross-platform then it might be a different story but I can't see Mac programs ever being more than hybrid C, C++, OBJ-C and the syntax will always be a hurdle when multiple languages are combined.
Again,
Porting an app to Obj-C from C is... nothing. It's done. Have a C library and want to use it in an Obj-C GUI Mac app? *Just use it*. There's *no* porting.
C++? Same thing. Just use it. You're done. Finis.
For the compiler parsing, they could easily have used something like what's used in web programming. <?php ?> braces between code blocks.
This is what tells me you're really not getting it - going between C and Obj-C happens at the expression level. Going between C++ and Obj-C happens at the statement level. Go on, write such code with code block delimiters... try it out.
Brackets aren't as simple to change to as lolspeak. There you are simply replacing words. It would be like replacing punctuation as it changes the meaning of things entirely. Square braces have always been used for arrays. To use them for function calls and addressing variables is extremely confusing.
[a]
[a b]
Yes, I can see how those are utterly confusing.
C++ mangled the dot notation of C, horribly overloading it. (And let's not get started on templates - suddenly a < is less-than, a template open bracket, or the first half of a left-bit-shift. Scan ahead one char to find out? Nope, sorry, it could be nested template brackets, keep going...)
Obj-C added bracket notation, and prepending of @ to Obj-C keywords. It is clear, simple, and obvious which bits of code are OO, and which are raw procedural. You simply cannot do that with C++ code. Quick, is the following subject to RTTI rules?
a = b.c + d->e();
Dunno. Could be that b and d are objects, but b could be a struct, and d a union holding a function pointer whose value is being called. You have no idea without going code diving. OTOH...
a = b.c + [d e];
Now you know that b is a POD type, and d is an object. You can see exactly which portions of code are subject to possible runtime
issues and optimizations, and which aren't. You also have a clear line between those sections of code that are MacOS X-only, and which are instantly available for porting cross-platform... or that came from an external cross-platform source.
Clear lines, simple delineations, and obvious semantics for both the compiler *and* the developer. The only reason C++ makes sense to you is that it's what you're used to. Having been around when the syntax wasn't exactly nailed down, and there was still a lot of discussion floating around on how things should be laid out... it's messy. It's more than messy, it's just plain nuts, if you ask me. They had an overriding concern to make object code look like procedural code, but keep procedural code around, and somehow not confuse anyone (or the compiler) between the two? Nuts.
I'm not much of a fan of typing, I like to abbreviate code as much as possible. I see the advantage of meaningful names but you can be concise and maintain the same clarity. I wish XCode had some decent auto-completing functionality.
I assume you mean the named parameters? Sorry, have to disagree with you here - clarity trumps keystrokes in almost every case. Saving a second now to add hours, days, or weeks of code tracing and debugging later is lunacy. Code that can't tell you straight-up what it does without diving through layers of headers and source files is just a pain in the ass.
Ditto on the auto-completing in XCode - that's the proper way to solve the problem. You get reduced keystrokes, I get clear, clean code. Everyone wins.
Objective-C is a superset of C. Show me all the GUI based C programs running in OS X. I thought not.
Most of them will be. It's just the GUI that's written in OBJ-C. I know that OBJ-C is a superset of C but C code looks a lot different from OBJ-C because of the syntax.
Allowing mix and match of C++ is bad... how?
The ability to do that is not a problem but the syntax difference isn't easy to switch between. It's like writing dans French and English in une sentence. If I remember right you have to use a .cxx extension for cpp files you want to use with OBJ-C (they are called OBJ-C++ or something) and I think you have to use the dot notation from OBJ-C code to address C++ code. Once I had it figured out it wasn't too bad but it's not easy to begin with. For a language to become popular there just shouldn't be any barriers at all.
For someone who has come from coding C++ to approach OBJ-C, they have to weigh up the advantages and disadvantages.
Advantages: cleaner code and possibly more efficient code
Disadvantages: unique syntax that is different from most languages, Mac only pretty much, performance advantage due to efficient coding is negated by slower runtime (OBJ-C is generally slower in benchmarks than C and C++ doing the same job).
[a]
[a b]
Yes, I can see how those are utterly confusing.
Try doing that in a C function though and it won't work. Although OBJ-C is a superset of C, you still have to use different rules for each language so you're still using two languages at once. C++ resembles C way more than OBJ-C does.
You also have a clear line between those sections of code that are MacOS X-only
No code should be limited to one platform though and until OBJ-C gets cross-platform uptake then it will always be limited in usefulness.
The only reason C++ makes sense to you is that it's what you're used to.
Yes, I agree entirely. But that's the thing, I used to have notions of doing things the 'right' way as in the theoretically better way of doing something. However, when it comes to just getting the job done, that's not always the right option. I find that because I am so used to using a certain way of coding that changing over is very difficult. No doubt if I'd started with Smalltalk things would be different but I learned languages in the order C -> Java -> C++ -> Objective-C -> Python -> PHP and the most difficult language I ever tried to learn was Objective-C. It took me weeks just to get round the basics. I couldn't figure out where the program started from. NSWakeUpFromNib just wasn't getting through at all.
The other languages are so clear to me that I can step through and debug the code very easily. Theoretically the other languages may be less flexible but practically they just work better for me and I haven't found them to be limiting at all.
Try doing that in a C function though and it won't work. Although OBJ-C is a superset of C, you still have to use different rules for each language so you're still using two languages at once. C++ resembles C way more than OBJ-C does.
That's a big problem though! Yo can get all wrapped around what exactly that eerily similar C/C++ syntax is actually doing depending on the context of the syntax around it. Talk about a pain in the ass when you are trying to understand the code someone else wrote, or you wrote months ago!
With Obj-C, either the syntax is a pure C statement, or it is Obj-C statement. There is no room for confusion. Yes, getting to like this is a transition not all folks want to undertake, but in the long run it will make coding easier. And Apple is allowing folks to choose what they want to use where, with only the slightest of pushes about the future, but I do expect that to change over the long run.
With Obj-C, either the syntax is a pure C statement, or it is Obj-C statement. There is no room for confusion. Yes, getting to like this is a transition not all folks want to undertake, but in the long run it will make coding easier.
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?