I'm a dinosaur and I'm about to go extinct!
Post: #5
You are of course entitled to your opinion, even if it's wrong 
Here's some thoughts:
1) Objective C has never been independent of Foundation, at least as far back as I can remember @"..." has created an NSConstantString object. Note that knowledge of this class has been embedded in the compiler (it creates it in the data segment) and the framework (the class responds to retain, release, autorelease, copy, and all the primitive string methods that the rest of the NSString cluster is built on).
2) The notion of a language without a library is absurd. I can't think of a single (serious -- BF doesn't count!) language that lacks a standard library. Why should ObjC be different? Yet it traditionally has been.
3) Manual reference counting is an entirely automatable design pattern. There are strict rules about the "logical retain count" of objects in ivars and globals (+1), objects returned from most methods (+0), objects returned from specific methods such as -init*, -copy*, +new* (+1) and objects passed into methods as arguments (+0). Any time something is completely automatable, it would be crazy not to automate it and save humans from doing the work.
4) Automating this means moving the language/library line a little. Now rather than being Foundation conventions, -retain, -release, -autorelease, -dealloc, NSAutoreleasePool and some naming conventions must be part of the language. This isn't any different from any other language with memory management features, e.g. -finalize in Java or destructors in C++ being part of the language.
5) Handwaving a little more, syntactic sugar is a part of most languages (C++ and Ruby have operator overloading, Python and Lua turn operators into method calls like __add__, etc.) and syntax for common data structures is a part of most languages (Perl and Ruby have regex literals, almost all the scripting languages have array and dictionary literals, etc). C++11 adds the ability for initializer lists to be "a literal for" any custom class. So yes, indexing operators, and array/dictionary/number literals for ObjC push the language/library line a little further, but not into untrodden or even uncommon territory.
6) Realistically, ObjC without Foundation has never been sane or sensible. Even if you were writing ObjC for another platform, you've always used one of the open-source Foundation libraries anyway. Pushing NSNumber, NSArray, NSDictionary and NSString down to join NSConstantString is not actually going to impact anyone's life.
So in conclusion, it feels kind of hypocritical to me to pick on ObjC for becoming less like a thin set of syntactic extensions and more like a language, given it's now MORE like any other language than it was before (and a lot easier and nicer to program with to boot).
As ObjC becomes more popular, I imagine the quality of the open-source runtimes and Foundations will improve too, since it will benefit more people to care. But you're right, for now, if you want to be super cross-platform, ObjC isn't the best choice. Then again, it never was.
Here's some thoughts:
1) Objective C has never been independent of Foundation, at least as far back as I can remember @"..." has created an NSConstantString object. Note that knowledge of this class has been embedded in the compiler (it creates it in the data segment) and the framework (the class responds to retain, release, autorelease, copy, and all the primitive string methods that the rest of the NSString cluster is built on).
2) The notion of a language without a library is absurd. I can't think of a single (serious -- BF doesn't count!) language that lacks a standard library. Why should ObjC be different? Yet it traditionally has been.
3) Manual reference counting is an entirely automatable design pattern. There are strict rules about the "logical retain count" of objects in ivars and globals (+1), objects returned from most methods (+0), objects returned from specific methods such as -init*, -copy*, +new* (+1) and objects passed into methods as arguments (+0). Any time something is completely automatable, it would be crazy not to automate it and save humans from doing the work.
4) Automating this means moving the language/library line a little. Now rather than being Foundation conventions, -retain, -release, -autorelease, -dealloc, NSAutoreleasePool and some naming conventions must be part of the language. This isn't any different from any other language with memory management features, e.g. -finalize in Java or destructors in C++ being part of the language.
5) Handwaving a little more, syntactic sugar is a part of most languages (C++ and Ruby have operator overloading, Python and Lua turn operators into method calls like __add__, etc.) and syntax for common data structures is a part of most languages (Perl and Ruby have regex literals, almost all the scripting languages have array and dictionary literals, etc). C++11 adds the ability for initializer lists to be "a literal for" any custom class. So yes, indexing operators, and array/dictionary/number literals for ObjC push the language/library line a little further, but not into untrodden or even uncommon territory.
6) Realistically, ObjC without Foundation has never been sane or sensible. Even if you were writing ObjC for another platform, you've always used one of the open-source Foundation libraries anyway. Pushing NSNumber, NSArray, NSDictionary and NSString down to join NSConstantString is not actually going to impact anyone's life.
So in conclusion, it feels kind of hypocritical to me to pick on ObjC for becoming less like a thin set of syntactic extensions and more like a language, given it's now MORE like any other language than it was before (and a lot easier and nicer to program with to boot).
As ObjC becomes more popular, I imagine the quality of the open-source runtimes and Foundations will improve too, since it will benefit more people to care. But you're right, for now, if you want to be super cross-platform, ObjC isn't the best choice. Then again, it never was.
