Programming languages evolve over time. For example, data protection was added to Obj-C in a fashion that borrows the idea from C++. And reflection was added to Java allowing dynamic hooks into the runtime in a fashion similar to Obj-C.
In the hope of exploring what makes for better languages, I want to propose turning your criticisms into questions:
1. ObjC is not strongly typed language.
Q: What are the advantages and disadvantages of both strongly and weakly typed languages? What about a mixed-language that allows compile-time type checking while being lenient about enforcement?
2. ObjC does not support data protection.
Q: What are the uses of data protection? Instance-variable and method levels of protection? Should this be a language feature or something that can be easily implemented within the language?
3. ObjC has horrible syntax.
-- A matter of opinion, and I partly agree. The question: "What are good syntaxes?" seems contrived. Instead I'll just say that as syntax is often a barrier to learning a language, and as some are easier to learn than others, we may wonder: What qualities should be sought in a language's syntax? I for one think that if a general syntax for most O-O technologies could be developed that would be a big help. The syntax of Java seems to be the fore-runner.
4. ObjC development framework is very poor (except on Mac platforms). No standard framework exists.
The need for multi-vendor support. I'm increasingly a fan of open-source. So maybe that's a criteria: that you can get a standard development package as open-source.
5. ObjC is pure dynamical like SmallTalk. Thus itís extremely slow
Q5a: What are the advantages and disadavantages of a dynamic languages.
Q5b: How should speed/performance be measured? What about measuring the actual time to do real-world execution, i.e., measure the system performance. In that context is a nominal (.7) overhead at the invocation level an issue?
And I'd like to add a different question as well. One of the ways I like to think of languages/compilers is in terms of information. When one write code (be it in C++, Java, Obj-C, or any other language) much of the information is the design of the class hierarchies: their interelation, their names, what methods they have, etc. This information is the real intelligence of the system's design. If we look at a C++ compiler and compare the input to the output what we see is a great loss of information. After compiling a class "knows" nothing about itself. There's no way to ask for even the most basic information, like what's the name of the class or it's parent(s). (I understand that as of 5 years ago there was a push to correct much of this, so it might be dated. The issue here isn't a slight on one language or another, per se, but a comparison of features and values to see what collectively might be the best parts of diverse langauges.) So (again, as of 5 years ago) you were stuck writing silly little "getClassName()" methods that made available (usually via a hard-coded string of char) the information you'd just typed into your editor when defining the class. What this means, in short, is that the compiler loses a lot of information.
So the rule that I started to develop when looking at languages had to do with the basic question: how much information am I putting into my code that I'm not getting out from the compiler? For a procedural language this doesn't matter so much. In an O-O language, this type of information is generally very useful. And if, you want the power of a dynamic language this information is essential. At the end of the day I find that one does have good need of this "meta-information" and that access to it makes a language trully powerful.
I imagine this chain of discussion is as good as dead, but these long-un-experssed thoughts have been triggered by your comments. Thanks for that and perhaps if this is read it might start a fruitful discussion.