The Church-Turing thesis is one of the foundation stones of computer science. It tells us that any programming language that can simulate a Turing Machine can be used to implement any algorithm. But this doesn’t tell us much about a language beyond a simple yes or no answer to the question "Is this language Turing-complete?" In almost all cases, the answer is yes; few useful languages are not Turing-complete. One example is Adobe’s Portable Document Format (PDF), which began life as a non-Turing-complete subset of PostScript. This was created so that the time required to render (and hence print) a document was bounded by its size. PostScript contains loop constructs that PDF lacks, and so it’s possible for a PostScript program never to terminate.
Anyone who has criticized C will be familiar with the defense "but you can implement that in C!" This is true, of course. Any Turing-complete language can be implemented in any other. Prolog, for example, can be implemented in about 20 lines of Lisp. If you write a program requiring 1,000 lines of Prolog and include with it a 20-line Prolog interpreter written in Lisp, is it fair to call it a Lisp program?
The same principle applies in many other languages. The Objective-C runtime is usually implemented in C, so obviously you can do anything in C that you can do in Objective-C. The question is whether this practice makes sense. Is it more sensible to write your own dynamic object system, or to use one that other people are working on and constantly optimizing?
Of course, we’re assuming that the features you would need to implement are actually useful. If a language lacks a feature that isn’t useful anyway, that’s not a limit to its expressiveness.
A good question to ask is how many language features you have to throw away to gain a useful feature. In Smalltalk, you send messages to objects. This is the equivalent of calling methods in a language such as C++ or Java. If the object doesn’t have an explicit handler for that message type, then the runtime system delivers this message and its arguments to the object’s doesNotUnderstand: method. This setup allows for a lot of flexibility in programming.
Consider Java’s RMI mechanism. Each class to be exposed through RMI must be run through a preprocessor that generates a proxy class, which passes the name and arguments of each method through to the RMI mechanism. In Smalltalk (or Objective-C, for that matter), you don’t need to do all this. You can just create a single proxy class that implements the doesNotUnderstand: method and passes the message to the remote class. This one class can be used as a proxy for any other class.
If you wanted to implement something comparable in C++, however, you would need to throw away the C++ method-call mechanism and replace it with your own custom message-passing system. Each C++ class would implement a single handleMessage() method, which would then call the "real" methods. By the time you’ve done this, you’ve thrown away a lot of the convenience of using C++ in the first place.