I didn't mean the distinction between class and instance methods is unintuitive, I meant the keywords themselves are unintuitive. What could possibly be intuitive about "+" meaning a class method, or "-" meaning an instance method?
Perhaps "intuitive" does not mean what you think it means. The meaning of "int" is intuitive. The meaning of "+" in front of a method definition is not.
Yes, I am aware. I was more referring to the meaning behind what "+" and "-" are assigning to the methods.
In C++ terms, "+" makes the method a static member function, and "-" makes the method an instance member function.
Now, I didn't mean to say that they should have specifically used that keyword, I only showed it as a suggestion. My point was that "+" and "-" are about as unclear as you can possibly be, and it makes absolutely no sense that they did not add new keywords for the purpose.
> Cocoa might be a quality framework, I don't know; Why not?
The second half of that sentence answers that question... I'm surprised you didn't see it, considering you quoted it next. Since apparently I was unclear I'll restate: Xcode is such a failure of an IDE that it gets in the way of everything, including learning Cocoa, and therefore I will never know whether Cocoa is a decent framework.
I doubt I will ever find myself in a situation where I would need to use Cocoa without needing to use Xcode as well.
> Xcode is such a failure of an IDE that I'll never be able to tell What?
> and I can't force myself to endure Objective-C long enough to try building an application with Cocoa entirely in code. Giving zero credibility to this rant.
So my comments are not credible merely because I do not want to subject myself to more of the language I find distasteful?
Suppose you hate pineapple for various reasons, so you make the statement that you will never know whether pineapple upside-down cake is good enough that you wouldn't mind the pineapple because you can't make yourself eat it knowing there's pineapple in it. Such a statement would not remove your credibility regarding the reasons for your dislike of pineapple.
stored in variables etc are object references ("identifiers" in Obj-C parlance)
See this is what I mean. We already had a word for that: pointers! Objective-C feels like it's trying to be different from C even when it's really not. Is it any wonder I find it confusing?
I suppose an apology is in order; I should not have been so vehement about Objective-C when in reality I both misunderstood the language and blamed the language for the (perceived) failings of one framework.
This is similar to various resource management schemes imposed by various C libraries (such as Gtk), where you still pass raw pointers around, but have to use special foo_release, foo_addref/release etc functions to manage them as you do.
Something being common does not necessarily mean that thing is good;) People use smart_ptr in C++ for a reason.
I understand the semantic difference between std::string and [const] char*, and why they're not implicitly convertible to each other. (Well, char* is implicitly convertible to std::string, but only because of a std::string constructor.) I'm still allowed to be annoyed by it;) It seems silly to provide two standard types of strings which are just incompatible enough to be annoying, yet not so incompatible that you decide to stick with just one...
This is getting off-topic, but std::string feels like the ugly cousin nobody wants to play with when I use it with the rest of the STL. For example, ifstream's open() doesn't provide a const std::string& overload for passing the filename. Calling c_str() on my strings all the time gets old.
As another example, the "right" way to read strings that may contain whitespace into a std::string with istreams, by calling getline(is, str), is not compatible with the "right" way to read other values from istreams (the >> operator). You can't use both methods without manually resetting flags on the stream when switching methods.
The inverse is not true - for ostreams, the << operator is the "right" method for all types.
I like C++, but there are things about it I find quite frustrating.
Sorry, I don't see how APIs being inconsistent would ever become intuitive, and no amount of documentation is an excuse for inconsistency.
Yes, I have indeed conflated the language and Cocoa. This is perhaps unfair to the language. But when Cocoa is by far the most common framework used with this language, can you really fault me for the mistake? (Not saying I wasn't wrong to do so, just that it's hopefully an understandable error.)
However, one specific complaint (using "+" and "-" as keywords in method definitions) is enough to make me choose another language (any other language!) if given a choice. Neither of those keywords is remotely intuitive in meaning. (Just because you can learn the meanings does not mean those meanings are intuitive.)
Fair enough. But why they think it's better to do that at runtime instead of compile-time is beyond me. Imagine if Java used reflection for every method call... sure, reflection is useful in some cases, but it's hardly a good idea to use it everywhere.
IMO it would have been far better to use standard function calls except where necessary. Using messages for getters and setters is not necessary, and only introduces more potential for bugs. This is especially true given that Objective-C supports standard function calls, so it would not have been difficult to do this instead.
Yes, I seem to have been conflating Cocoa and Objective-C; hopefully that's understandable given that using the two together has been the most common use of the language.
You learn the syntax of a language, and as far as such things go, Objective-C is pretty easy to grasp.
We'll just have to disagree, here, because my point is precisely that I find Objective-C's additional syntax rules to be unintuitive and unclear. I found Scheme far easier to learn, even coming from a C++ background as I was.
Surely you're just trolling here. Xcode isn't even remotely a "failure of an IDE". There are definitely other IDEs out there that some people like better than Xcode, but it's a damn fine IDE.
No, not trolling, just expressing an opinion based on the month I spent fighting with it. Couple of glaring problems off the top of my head:
- Code completion (its attempt at Intellisense) is horribly broken, *especially* for Objective-C code. This is unacceptable for a modern IDE. - There are two file browsing panes. The pane on top only includes the files selected in the left pane. WTF? - If you double-click a file in a file browsing pane, Xcode is inconsistent about when it opens the file in the existing code window and when it opens a separate window. - The UI editor is an entirely separate program. WTF? - Deleting a file from the project does not omit it from the compilation process unless you also delete it from disk. If this results in compilation errors, the IDE gives you no indication of where the error occurred other than the compiler output. WTF?
Apple claims that Xcode is what Apple's programmers use for their own software. I'm torn between pitying them for being stuck with this crap, and admiring them for what they have accomplished despite it.
I'm willing to admit that my impression of Objective-C is colored by Cocoa's... quirks. It's entirely possible that the resulting judgement is unfair to the language.
I've obviously misunderstood Objective-C's memory management. I also obviously wasn't clear on how exactly parameter passing works in Objective-C; this is partially due to confusion about when library functions affect reference counts and when they don't, which @property settings do what and how, as well as what is (in my opinion) unclear method definition syntax. Misunderstandings feed misunderstandings.
I should also point out that I am rather annoyed by the C++ STL's inconsistency with respect to std::string vs char*.
But you do not have to have every class extend from NSObject - you can write your own.
I didn't say you have to, I said you'd never not want to. (Would you argue less if I said "extremely rarely"?)
Ok, ObjectiveC first got garbage collection in V2.0 - a very recent version. It has nothing to do with reference counting so I don't know what you are talking about in that respect.
When run in backwards-compatible mode, the runtime turns reference counting operations such as "retain" and "release" into no-ops.
If reference counting were unrelated to the language's garbage collection, there would be no need to turn "retain" and "release" into no-ops, so clearly they are not unrelated. (The Wikipedia statement implies that they conflict with each other.)
At any rate, I did indeed misunderstand Objective-C's memory management - there was not and is not a garbage collector in the version of Objective-C in use on iOS devices.
However, I maintain that the memory management practices enforced by Objective-C (or, if you prefer, the NextStep framework that Objective-C's compiler assumes you are using) are unintuitive and difficult to use. (Not reference counting itself, but the fact that various APIs and @property tags are inconsistent about which things retain objects and which things don't. It's not fun having your program crash because you assumed a built in collection object would retain your object, but it didn't, even though other similar objects in the same framework do retain things you give them.)
It is one of the reasons why all objects inherit from the NSObject object - that is where the reference counting takes place. It's part of the Cocoa/NextStep framework - not the language.
That's not entirely true. As I mentioned before, prefixing your string constants with @ turns the string constant into an NSString, so clearly the compiler assumes that at least some portion of the NextStep framework is available.
You cannot say "it's not part of the language" if the syntax of the language itself transforms something into an object in that framework.
What are you talking about? The example you call insightful is very readable.
It's the brackets and the "initWithThing:x otherThing:y" paradigm that I find unintuitive and difficult to read, most especially the "let's combine the method name with the name of its first parameter!" idea. Why did they throw out perfectly understandable function call syntax in favor of surrounding everything with brackets? I know they're trying to pretend they're sending "messages", but what they ended up with is virtually identical to the standard in C except in superficial syntax.
Why did they throw out C's perfectly readable struct-definition syntax in favor of this "@interface" and "@end" and "@property" nonsense?
Why do you have to manually derive all interfaces as children of NSObject? That would be like Java requiring you to explicitly derive every class from Object. You're never not going to want your class to be derived from NSObject, so it should be assumed.
Why do they use "+" and "-" for static methods vs instance methods? Did they really think "+" and "-" were more intuitively clear than, I don't know, using the 'static' keyword that was already in the language? Is it so absurd to want method specifiers that are actually clear in their meaning?
Why did they throw out perfectly understandable pass-by-value and pass-by-address parameter passing?
None of these changes from C are for the better.
I will say that #import is an improvement over #include; I wish something similar had been adopted in C++. Still, tiny improvements like this do not offset the idiocy with which the rest of Objective-C was designed.
I suspect you are more of a "get off my lawn" type who thinks things should be done the way you learned them and anything different is to be feared.
I have used languages with widely varying syntaxes and design philosophies (I enjoyed working with Scheme, for example). I don't "fear" different ways of doing things; I do have opinions about which ways of doing things are stupid. Having a negative opinion about a specific language you like does not automatically mean I'm just shaking my bony fist in the air and shouting "get off my lawn".
Let me make myself clearer: what bothers me most about Objective-C is that it tries to pretend it's like C even while doing everything it can to be different from C without being so different that it can't have the C in its name anymore, all while retaining several of C's disadvantages and gaining very few of the advantages it claims.
renew/release isn't very difficult to understand, but if you can't keep up, Objective-C has garbage collection.
No, it's not particularly difficult to understand, but that's not my point; Objective-C's garbage collection only collects objects whose reference counts are zero. That's the whole reason you have to properly handle your reference counting. In other words, Objective-C gives you all the downsides of being forced to manage memory, combined with all the downsides of garbage collection.
(I realize garbage collection has advantages; however, by forcing you to manually handle reference counting, Objective-C negates those benefits by design. In other words, all Objective-C gains you is that instead of freeing your memory at predictable times, the garbage collector will come along at unpredictable times and slow down whatever it is your program is doing.)
Objects != string pointers, and that's a problem for you? Seems like a fairly basic idea to grasp.
It's not that, it's that nothing in Objective-C even works with char*s, other than the one init method on NSString. Want to display a char* in your UI? Hope you don't mind converting it to NSString first!
Worse, by default, string constants in your code are char*s, not NSStrings! If you want your string constant to be an NSSt
What I find unintuitive and difficult to read is the whole paradigm of "let's combine the method name with the name of the first parameter!" idea that Objective-C is so fond of, plus the "let's surround everything with square brackets!" idea that they layered on top of it.
Foo* foo = [[Foo alloc] initWithBar:bar];
Really? initWithBar? Is that really better than this:
Foo* foo = new Foo(bar);
The whole paradigm is designed for IDEs that can't show you the names and types of function parameters as you're typing. Granted, that sort of feature wasn't around when C and C++ were put together, but to claim it as a "benefit" of Objective-C now just means you aren't using a modern IDE. (Which I suppose isn't surprising, since Xcode is a horribly, horribly sucky IDE, most especially that particular feature.)
Claiming Objective-C is "familiar to far more programmers" is a stretch at best. I'm a C/C++ programmer, and I've been working with Java for a long while now, but I still find Objective-C's "messaging" syntax and its idiotic class definition syntax to be unintuitive and nigh-unreadable, despite the language's C-like appearance much of the time.
Seriously, what idiot decided "+" and "-" are better choices for distinguishing between class methods and instance method than using C's existing "static" keyword for one and defaulting to the other?
Objective-C has the most unreadable and unintuitive syntax of any language I've ever worked with, to say nothing of its memory management "best practices". What good do reference-counted pointers do me if I still have to manually release everything to avoid memory leaks? What good does its ability to mix C in with the Objective-C code do me when just mixing their two string types (NSString and char*) is a good way to make my program misbehave?
I can't help but conclude the language was built by a couple of guys saying "wouldn't it be cool if..." without thinking about the consequences. I'm baffled how the summary can claim this is "probably for the better".
I didn't mean to imply that I advocate mandatory globally unique IDs (I don't, nor do I support no-fly lists). I simply meant to point out that that situation is the only one in which a no-fly list might actually function as desired.
That's supposedly their goal, yet they haven't caught anyone trying to do any of the things they're searching for. Plenty of drugs, but nothing you could call terrorism. Is the off-chance a terrorist will be stupid enough to try something obvious really worth such extreme violation of our rights?
It's far more likely that we'll die in the car on the way to the airport than die in the airport or on the plane. Why are we so obsessed with implementing measures that don't actually increase security on planes?
No-fly lists do far more harm than good, not to mention they're trivially easy to defeat. This is especially true of the current no-fly list; all it is is a list of names. There are no nationalities, ages, genders, or anything else linked to the name. The government suspects Jim Smith of terrorism, so they put the name on the no-fly list; suddenly no Jim Smith in the country can get a plane ticket. (Unless they use their middle name to buy the ticket; that's legal and it circumvents the no-fly list.) Does your three year old's name match a name on the no-fly list? That's too bad, the airlines don't exercise any common sense, even if you're there buying the ticket with your child in person.
If there were mandatory globally unique IDs, then sure, a no-fly list would make sense. But today, there isn't a good way to implement a no-fly list that doesn't hurt far more than it helps.
In this case, the "think of the children" defense is actually relevant - an adult can legally consent to another adult touching his or her genitals, but a child can't. (Which is not to say that adults should consent to the TSA's groping.)
Slashdot Mirror
I didn't mean the distinction between class and instance methods is unintuitive, I meant the keywords themselves are unintuitive. What could possibly be intuitive about "+" meaning a class method, or "-" meaning an instance method?
Perhaps "intuitive" does not mean what you think it means. The meaning of "int" is intuitive. The meaning of "+" in front of a method definition is not.
Don't most compilers warn you if you do signed/unsigned arithmetic? I'm pretty sure gcc does, at least with -Wall...
Yes, I am aware. I was more referring to the meaning behind what "+" and "-" are assigning to the methods.
In C++ terms, "+" makes the method a static member function, and "-" makes the method an instance member function.
Now, I didn't mean to say that they should have specifically used that keyword, I only showed it as a suggestion. My point was that "+" and "-" are about as unclear as you can possibly be, and it makes absolutely no sense that they did not add new keywords for the purpose.
> Cocoa might be a quality framework, I don't know;
Why not?
The second half of that sentence answers that question... I'm surprised you didn't see it, considering you quoted it next. Since apparently I was unclear I'll restate: Xcode is such a failure of an IDE that it gets in the way of everything, including learning Cocoa, and therefore I will never know whether Cocoa is a decent framework.
I doubt I will ever find myself in a situation where I would need to use Cocoa without needing to use Xcode as well.
> Xcode is such a failure of an IDE that I'll never be able to tell
What?
I answered this question here.
> and I can't force myself to endure Objective-C long enough to try building an application with Cocoa entirely in code.
Giving zero credibility to this rant.
So my comments are not credible merely because I do not want to subject myself to more of the language I find distasteful?
Suppose you hate pineapple for various reasons, so you make the statement that you will never know whether pineapple upside-down cake is good enough that you wouldn't mind the pineapple because you can't make yourself eat it knowing there's pineapple in it. Such a statement would not remove your credibility regarding the reasons for your dislike of pineapple.
Integer division is always a fun unintentional bug.
you should know that trying to handle primitive data types and objects in the same way is a big no-no.
One could argue that string should be a primitive data type.
stored in variables etc are object references ("identifiers" in Obj-C parlance)
See this is what I mean. We already had a word for that: pointers! Objective-C feels like it's trying to be different from C even when it's really not. Is it any wonder I find it confusing?
I suppose an apology is in order; I should not have been so vehement about Objective-C when in reality I both misunderstood the language and blamed the language for the (perceived) failings of one framework.
This is similar to various resource management schemes imposed by various C libraries (such as Gtk), where you still pass raw pointers around, but have to use special foo_release, foo_addref/release etc functions to manage them as you do.
Something being common does not necessarily mean that thing is good ;) People use smart_ptr in C++ for a reason.
I understand the semantic difference between std::string and [const] char*, and why they're not implicitly convertible to each other. (Well, char* is implicitly convertible to std::string, but only because of a std::string constructor.) I'm still allowed to be annoyed by it ;) It seems silly to provide two standard types of strings which are just incompatible enough to be annoying, yet not so incompatible that you decide to stick with just one...
This is getting off-topic, but std::string feels like the ugly cousin nobody wants to play with when I use it with the rest of the STL. For example, ifstream's open() doesn't provide a const std::string& overload for passing the filename. Calling c_str() on my strings all the time gets old.
As another example, the "right" way to read strings that may contain whitespace into a std::string with istreams, by calling getline(is, str), is not compatible with the "right" way to read other values from istreams (the >> operator). You can't use both methods without manually resetting flags on the stream when switching methods.
The inverse is not true - for ostreams, the << operator is the "right" method for all types.
I like C++, but there are things about it I find quite frustrating.
Sorry, I don't see how APIs being inconsistent would ever become intuitive, and no amount of documentation is an excuse for inconsistency.
Yes, I have indeed conflated the language and Cocoa. This is perhaps unfair to the language. But when Cocoa is by far the most common framework used with this language, can you really fault me for the mistake? (Not saying I wasn't wrong to do so, just that it's hopefully an understandable error.)
However, one specific complaint (using "+" and "-" as keywords in method definitions) is enough to make me choose another language (any other language!) if given a choice. Neither of those keywords is remotely intuitive in meaning. (Just because you can learn the meanings does not mean those meanings are intuitive.)
Fair enough. But why they think it's better to do that at runtime instead of compile-time is beyond me. Imagine if Java used reflection for every method call... sure, reflection is useful in some cases, but it's hardly a good idea to use it everywhere.
IMO it would have been far better to use standard function calls except where necessary. Using messages for getters and setters is not necessary, and only introduces more potential for bugs. This is especially true given that Objective-C supports standard function calls, so it would not have been difficult to do this instead.
Yes, I seem to have been conflating Cocoa and Objective-C; hopefully that's understandable given that using the two together has been the most common use of the language.
You learn the syntax of a language, and as far as such things go, Objective-C is pretty easy to grasp.
We'll just have to disagree, here, because my point is precisely that I find Objective-C's additional syntax rules to be unintuitive and unclear. I found Scheme far easier to learn, even coming from a C++ background as I was.
Surely you're just trolling here. Xcode isn't even remotely a "failure of an IDE". There are definitely other IDEs out there that some people like better than Xcode, but it's a damn fine IDE.
No, not trolling, just expressing an opinion based on the month I spent fighting with it. Couple of glaring problems off the top of my head:
- Code completion (its attempt at Intellisense) is horribly broken, *especially* for Objective-C code. This is unacceptable for a modern IDE.
- There are two file browsing panes. The pane on top only includes the files selected in the left pane. WTF?
- If you double-click a file in a file browsing pane, Xcode is inconsistent about when it opens the file in the existing code window and when it opens a separate window.
- The UI editor is an entirely separate program. WTF?
- Deleting a file from the project does not omit it from the compilation process unless you also delete it from disk. If this results in compilation errors, the IDE gives you no indication of where the error occurred other than the compiler output. WTF?
Apple claims that Xcode is what Apple's programmers use for their own software. I'm torn between pitying them for being stuck with this crap, and admiring them for what they have accomplished despite it.
I'm willing to admit that my impression of Objective-C is colored by Cocoa's... quirks. It's entirely possible that the resulting judgement is unfair to the language.
I've obviously misunderstood Objective-C's memory management. I also obviously wasn't clear on how exactly parameter passing works in Objective-C; this is partially due to confusion about when library functions affect reference counts and when they don't, which @property settings do what and how, as well as what is (in my opinion) unclear method definition syntax. Misunderstandings feed misunderstandings.
I should also point out that I am rather annoyed by the C++ STL's inconsistency with respect to std::string vs char*.
Fair enough, but it would still be a lot clearer than "+".
I like C++ and its syntax, but I still find Objective-C's to be unintuitive and difficult to read.
But you do not have to have every class extend from NSObject - you can write your own.
I didn't say you have to, I said you'd never not want to. (Would you argue less if I said "extremely rarely"?)
Ok, ObjectiveC first got garbage collection in V2.0 - a very recent version. It has nothing to do with reference counting so I don't know what you are talking about in that respect.
Wikipedia indicates otherwise:
When run in backwards-compatible mode, the runtime turns reference counting operations such as "retain" and "release" into no-ops.
If reference counting were unrelated to the language's garbage collection, there would be no need to turn "retain" and "release" into no-ops, so clearly they are not unrelated. (The Wikipedia statement implies that they conflict with each other.)
At any rate, I did indeed misunderstand Objective-C's memory management - there was not and is not a garbage collector in the version of Objective-C in use on iOS devices.
However, I maintain that the memory management practices enforced by Objective-C (or, if you prefer, the NextStep framework that Objective-C's compiler assumes you are using) are unintuitive and difficult to use. (Not reference counting itself, but the fact that various APIs and @property tags are inconsistent about which things retain objects and which things don't. It's not fun having your program crash because you assumed a built in collection object would retain your object, but it didn't, even though other similar objects in the same framework do retain things you give them.)
It is one of the reasons why all objects inherit from the NSObject object - that is where the reference counting takes place. It's part of the Cocoa/NextStep framework - not the language.
That's not entirely true. As I mentioned before, prefixing your string constants with @ turns the string constant into an NSString, so clearly the compiler assumes that at least some portion of the NextStep framework is available.
You cannot say "it's not part of the language" if the syntax of the language itself transforms something into an object in that framework.
What are you talking about? The example you call insightful is very readable.
It's the brackets and the "initWithThing:x otherThing:y" paradigm that I find unintuitive and difficult to read, most especially the "let's combine the method name with the name of its first parameter!" idea. Why did they throw out perfectly understandable function call syntax in favor of surrounding everything with brackets? I know they're trying to pretend they're sending "messages", but what they ended up with is virtually identical to the standard in C except in superficial syntax.
Why did they throw out C's perfectly readable struct-definition syntax in favor of this "@interface" and "@end" and "@property" nonsense?
Why do you have to manually derive all interfaces as children of NSObject? That would be like Java requiring you to explicitly derive every class from Object. You're never not going to want your class to be derived from NSObject, so it should be assumed.
Why do they use "+" and "-" for static methods vs instance methods? Did they really think "+" and "-" were more intuitively clear than, I don't know, using the 'static' keyword that was already in the language? Is it so absurd to want method specifiers that are actually clear in their meaning?
Why did they throw out perfectly understandable pass-by-value and pass-by-address parameter passing?
None of these changes from C are for the better.
I will say that #import is an improvement over #include; I wish something similar had been adopted in C++. Still, tiny improvements like this do not offset the idiocy with which the rest of Objective-C was designed.
I suspect you are more of a "get off my lawn" type who thinks things should be done the way you learned them and anything different is to be feared.
I have used languages with widely varying syntaxes and design philosophies (I enjoyed working with Scheme, for example). I don't "fear" different ways of doing things; I do have opinions about which ways of doing things are stupid. Having a negative opinion about a specific language you like does not automatically mean I'm just shaking my bony fist in the air and shouting "get off my lawn".
Let me make myself clearer: what bothers me most about Objective-C is that it tries to pretend it's like C even while doing everything it can to be different from C without being so different that it can't have the C in its name anymore, all while retaining several of C's disadvantages and gaining very few of the advantages it claims.
renew/release isn't very difficult to understand, but if you can't keep up, Objective-C has garbage collection.
No, it's not particularly difficult to understand, but that's not my point; Objective-C's garbage collection only collects objects whose reference counts are zero. That's the whole reason you have to properly handle your reference counting. In other words, Objective-C gives you all the downsides of being forced to manage memory, combined with all the downsides of garbage collection.
(I realize garbage collection has advantages; however, by forcing you to manually handle reference counting, Objective-C negates those benefits by design. In other words, all Objective-C gains you is that instead of freeing your memory at predictable times, the garbage collector will come along at unpredictable times and slow down whatever it is your program is doing.)
Objects != string pointers, and that's a problem for you? Seems like a fairly basic idea to grasp.
It's not that, it's that nothing in Objective-C even works with char*s, other than the one init method on NSString. Want to display a char* in your UI? Hope you don't mind converting it to NSString first!
Worse, by default, string constants in your code are char*s, not NSStrings! If you want your string constant to be an NSSt
What I find unintuitive and difficult to read is the whole paradigm of "let's combine the method name with the name of the first parameter!" idea that Objective-C is so fond of, plus the "let's surround everything with square brackets!" idea that they layered on top of it.
Foo* foo = [[Foo alloc] initWithBar:bar];
Really? initWithBar? Is that really better than this:
Foo* foo = new Foo(bar);
The whole paradigm is designed for IDEs that can't show you the names and types of function parameters as you're typing. Granted, that sort of feature wasn't around when C and C++ were put together, but to claim it as a "benefit" of Objective-C now just means you aren't using a modern IDE. (Which I suppose isn't surprising, since Xcode is a horribly, horribly sucky IDE, most especially that particular feature.)
Claiming Objective-C is "familiar to far more programmers" is a stretch at best. I'm a C/C++ programmer, and I've been working with Java for a long while now, but I still find Objective-C's "messaging" syntax and its idiotic class definition syntax to be unintuitive and nigh-unreadable, despite the language's C-like appearance much of the time.
Seriously, what idiot decided "+" and "-" are better choices for distinguishing between class methods and instance method than using C's existing "static" keyword for one and defaulting to the other?
Funny? More like Insightful :(
Objective-C has the most unreadable and unintuitive syntax of any language I've ever worked with, to say nothing of its memory management "best practices". What good do reference-counted pointers do me if I still have to manually release everything to avoid memory leaks? What good does its ability to mix C in with the Objective-C code do me when just mixing their two string types (NSString and char*) is a good way to make my program misbehave?
I can't help but conclude the language was built by a couple of guys saying "wouldn't it be cool if..." without thinking about the consequences. I'm baffled how the summary can claim this is "probably for the better".
What country could be so bad that we'd want to move to Australia instead? ;)
Ack. Why did this post anonymously? I swear, sometimes the "post anonymously" checkbox checks itself.
I didn't mean to imply that I advocate mandatory globally unique IDs (I don't, nor do I support no-fly lists). I simply meant to point out that that situation is the only one in which a no-fly list might actually function as desired.
That's supposedly their goal, yet they haven't caught anyone trying to do any of the things they're searching for. Plenty of drugs, but nothing you could call terrorism. Is the off-chance a terrorist will be stupid enough to try something obvious really worth such extreme violation of our rights?
It's far more likely that we'll die in the car on the way to the airport than die in the airport or on the plane. Why are we so obsessed with implementing measures that don't actually increase security on planes?
No-fly lists do far more harm than good, not to mention they're trivially easy to defeat. This is especially true of the current no-fly list; all it is is a list of names. There are no nationalities, ages, genders, or anything else linked to the name. The government suspects Jim Smith of terrorism, so they put the name on the no-fly list; suddenly no Jim Smith in the country can get a plane ticket. (Unless they use their middle name to buy the ticket; that's legal and it circumvents the no-fly list.) Does your three year old's name match a name on the no-fly list? That's too bad, the airlines don't exercise any common sense, even if you're there buying the ticket with your child in person.
If there were mandatory globally unique IDs, then sure, a no-fly list would make sense. But today, there isn't a good way to implement a no-fly list that doesn't hurt far more than it helps.
In this case, the "think of the children" defense is actually relevant - an adult can legally consent to another adult touching his or her genitals, but a child can't. (Which is not to say that adults should consent to the TSA's groping.)
Everyone gets searched at the airport, not just "a few randomly selected ones".