Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Objective-C is an object-oriented programming language that adds Smalltalk-style messaging to the C programming language. I understand that learning Smalltalk might be good in the same way that learning Lisp is good for one's knowledge, but I want to know if learning Smalltalk-specific concepts will help me to understand Objective-C more completely, given Smalltalk's role in its "origin story". If so, what specifically?
Assuming that one already knows C programming, what can we learn from Smalltalk? Obviously, there's a lot of concepts in Objective-C that just aren't in C (ie. messaging, interfaces, protocols, dynamic typing, delegation, reflection; it's object-oriented!) but are derived from Smalltalk.
Edit: I've added the C programming language to the question, as the general consensus is that learning C is a better use of one's time than learning Smalltalk (when it comes to programming in Objective-C).
Smalltalk is an incredibly compact language and remains one of the most pure object oriented languages. Objective-C is a pragmatic compromise between Smalltalk and C, which makes for some very substantial differences. For example, in Smalltalk everything is an object — even simple numbers — and every manipulation of an object is by message sending. Messages are evaluated in the same order irrespective of their name. So e.g. the following:
8 + 9 / 23 + 16 * 8
Is evaluated in strict left-to-right order because the operators '+', '/' and '*' have no special meaning to the language being just messages that are passed on to number objects.
Objective-C adds Smalltalk-style objects to C but is also a strict superset of C that retains C's primitive types and built-in operators. So in Objective-C the normal mathematical order of operations would be applied to the expression above — the division and the multiplication would be done first, the additions afterwards.
Learning C is absolutely essential to a thorough understanding of Objective-C. Objective-C is a strict superset of C and explicitly uses exactly the same syntax and semantics as far as they go. It grafts the concept of objects onto C by virtue of C's ability to retain a pointer to a thing without knowing how to apply any operations to the thing. It then extends the C syntax to provide a means for posting messages to objects and for declaring and implementing the messages an object may receive.
A lot of the general design of the Objective-C runtime, especially when coupled with Cocoa, comes directly from Smalltalk, including the concept of a selector, the use of metaclasses as factories for instances of classes, the hierarchy and system of inheritance, the division of model-view-controller (a Smalltalk original, albeit now almost ubiquitous) and a lot of the messages defined on the standard collections and objects.
Off the top of my head, Smalltalk also differs greatly in its system of flow control and has a similar but subtly different idea of a 'block' (though most newer implementations have brought the two into line). Apple have actually implemented blocks as an extension at the C level which is utilised by a lot of the newer methods on Objective-C objects.
That all being said, the Goldberg Smalltalk-80 book is extremely well written, easy to read and the language is so simple that you can learn the whole language in just two or three chapters. Most of the complexity is swallowed by the objects available in the runtime, and obviously that stuff doesn't transfer. The benefit to you is that the ideological stuff about objects and runtimes ends up very separated from the specifics in print. Conversely, C makes stuff like flow control and arithmetic a language feature, which means more syntax and more to read before you really feel you know what's going on.
So, in conclusion: the Smalltalk-80 book (the purple one) is definitely worth a read and extremely helpful but not necessarily entirely relevant. Learning C is essential in any case; my references to K&R are for comparison.
From Smalltalk you can learn real object-oriented programming. Hybrids like java, c# and Delphi don't seem to do so well. After ten years of hybrids, my coding style significantly improved after a few months of Smalltalk.
As an iPhone developer, you're probably more interested in the design of the libraries and the concepts used than the syntax. c is not going to be any help there (though you need to understand some basics). Programming in Objective C feels much more similar to programming in Smalltalk. The Smalltalk IDEs are far superior to the Objective C ones, and help you understand much better how object-oriented code works, and how to build it. It is much easier to keep your code clean and well-refactored in a Smalltalk (IDE) than in any other object-oriented language. The cocoa libraries are very well designed, at least when compared to the java or .net ones. They seem to be in somewhat better shape than e.g. the Squeak Smalltalk ones.
I have to disagree with Knodel just an example see this
[someObject message]
and see
someObject message.
You see Objective-C uses the same "positioning" and yes it comes from Smalltalk.
Learning Smalltalk is always a good investment of time. And the meaning in this area is 100% smalltalk send some message to either an Object or an Class which itself has some MetaClass.
And yes learning C is good to know how to use part of Objective-C but getting used to OO is not taught by C. So knowing C and Smalltalk makes it easier to use Objective-C. BUT Objective-C is not just the language the "power" comes from the class libraries. So spending time on that is surely good spent time.
And yes you better knew C and Smalltalk to make the best out of Objective-C.
Disclaimer: I don't know Smalltalk.
I'm sure your Obj-C skills would benefit from learning Smalltalk, but in my opinion, your time would be much better spent learning C. As someone who learned Obj-C before delving into C, the concepts taken from Smalltalk are easy to pick up, the concepts taken from C are much more difficult.
Yes, the Objective parts of Objective-C are very similar to Smalltalk. If you learn Smalltalk first, some of the concepts of Objective-C will be easier and the syntax of sending messages will be less of a shock. However, I don't think Smalltalk is necessarily any easier to learn than Objective-C, certainly not if you know C already, so you might as well learn Objective-C straight off.
Having said that, Smalltalk is a nice language IMO and worth learning for its own sake.
I think that the best background to learn Objective - C is C. If you know C, you'll easily become familiar with object-oriented programming and write in Objective - C.
Personally, I don't think learning Smalltalk us a good idea.
Getting used to passing messages to objects instead of calling methods is pretty easy without a SmallTalk background. However, SmallTalk doesn't look anything like C (except for the SuperCollider variant) and the language even treats code blocks and other crazy stuff as first-class objects: e.g. in SuperCollider {i < 5}.while({ // do stuff }) This behavior did not come over to Objective-C and will likely just confuse you as it does me.
Related
Java is considered an OOP language, despite it not quite being purely OOP. Java contains 8 primitives, and in an interview, James Gosling explains why:
Bill Venners: Why are there primitive types in Java? Why wasn't
everything just an object?
James Gosling: Totally an efficiency thing. There are all kinds of
people who have built systems where ints and that are all objects.
There are a variety of ways to do that, and all of them have some
pretty serious problems. Some of them are just slow, because they
allocate memory for everything. Some of them try to do objects where
sometimes they are objects, sometimes they are not (which is what the
standard LISP system did), and then things get really weird. It kind
of works, but it's strange.
So it seems that both memory and speed are issues that Java's primitives solve. However, this got me wondering how can a language be true, pure object-oriented?
If only a byte primitive existed, you could build from there. Creating integers, chars and eventually floats and doubles. But without any base structure at all, how could you build anything? Isn't at least some base primitive necessary? In other words, isn't a base data-structure needed in to expand from?
If you're asking if there are languages that have no way to interact with primitive types, then you might want to look at something like Scala. From that page:
Scala is a pure object-oriented language in the sense that every value is an object.
However, as you point out (for Kotlin):
the compiler maps them to JVM primitives when at all possible to save memory
If your definition of what object-oriented languages can be requires that everything is always represented as an object, then a purely object-oriented language is impossible. You can't build a language that runs on a real computer that only has objects. This is because the computer must have a way to represent the data natively. This is essentially what primitives in object-oriented languages are: The native forms of data that the underlying computer (or VM) can represent. No matter what you do, you will always need to have some non-object representation of data in order for the computer to do operations with it. Even if you built a JavaScript interpreter that really represented primitives as objects, in order to add two integers, the interpreter would have to have load the integers into CPU registers and use some form of an add instruction.
But that explanation sort of misses the point of object-oriented programming. A programming language is not the same as a program. Languages are just a tool for us to make computers do what we want - they don't actually exist at runtime. You would probably say that a program written in Kotlin or Scala is more object-oriented than a program written in C, despite both languages compiling to the same assembly instructions at runtime.
So, if you relax your definition of pure object-oriented programming to no longer be concerned with what the runtime representation of data is, then you'll find that purely object-oriented languages are possible. When programming Scala, you never interact with anything that's not an object. Even if your Int becomes a 'primitive' at runtime, it doesn't really matter, because you, as the programmer, never really have to think about that (at least, in an ideal world where performance and memory never matter). The language definition of Scala doesn't include the concept of primitives at all - they are part of the implementation of the language, not the language itself.
As far your example of Java goes, Java probably isn't a purely object-oriented language by most definitions. It is, however, mostly object-oriented. Java is often mentioned as the de facto object oriented language because it was much more object oriented than what came before it.
Even further, the term object-oriented doesn't really have a definitive meaning. To some people it might mean that everything has to be an object, and to others it might just mean that there need to be objects, some definitions require the concept of classes, some don't, etc.
I keep reading that object-oriented programming can basically be done in any programming language, and that in order to do so, explicit language support is not required. I.e. one can write object-oriented programs in, say, plain C.
What good examples of OO design using a procedural language are there, apart from GTK+?
Which open source projects are good examples of procedural design, on the other hand? (preferably C)
In C, OO programming usually takes the form of calling particular initialization and cleanup functions on struct pointers, and for polymorphism, passing around structs of function pointers. One example I can think of offhand is KVM.
I have some maybe stupid question. What is the difference between C++ and objectice-c. Is there IDE for objective-c for linux ?
I'm going to expand a bit on DaVinci's point 1.
First the similarities:
Objective-C and C++ were both originally based on C. Both languages support an object oriented model. That's where the similarities end.
Objective-C is a strict superset of C, C++ is not. Any C program is also an Objective-C program. This is not necessarily the case with C++.
The syntax of Objective-C's OO extensions is closer to the syntax of Smalltalk than that of C whereas the reverse is the case with C++.
The philosophies behind the OO models is completely different too. Objective-C's model is dynamic in the spirit of Smalltalk. C++'s model is more static. With Objective-C, you send messages to objects and the object decides at run time how it is going to respond to the message. With C++ the methods that an object responds to - even the virtual ones - are defined at compile time. This makes Objective-C's object model immensely more powerful than C++'s object model. For instance, you can add whole sets of new methods to existing classes without using inheritance. You can even replace method implementations on the fly.
This all comes at a cost of course. Sending messages to Objective-C objects is quite a bit slower than calling C++ virtual functions. However, I think the benefits are worth the cost and you can always drop back to C for performance critical sections of code.
NB there is also a language called Objective-C++ which is the Objective-C OO extensions built on top of C++ instead of C.
they are simply two quite different languages.
I think gnustep is the only objective-C environment/library, it also has a IDE: project center, however Objective-Cs home is primarily on Apple products.
Hi I'm writing this question because I'm a newbie in ObjC and a lot of doubts came to my mind when trying to make my fist training app. The thing is that I have a strong background in C, I've been programming in Java for the last year and I've done some collage stuff with Smalltalk (I mencione this because those are my programming references and those are the languages I'm comparing ObjC with).
The first problem I've encountered is that I don't know where to draw a line between ObjC and C, for example when dealing with math operations, Should I use math.h or there is a more "object-way" like you can do in Smalltalk (aNumber raisedTo: 3) ? How does a person with no background at all in C learns ObjC?.
Another thing that I couldn't find was a collection's protocol (I've looked over the Foundation Framework documentation given by Apple). Because I want to implement an expresion tree class and I wanna know if there are methods that all collections should implement (like in Smalltalk or Java) or I gotta check by hand every collection and see if there is a cool method that my new collection should have.
I don't know if I'm being too stupid or I'm searching for features that the language/framework doesn't have. I want to program in ObjC with the ObjC style not thinking in C, Java or Smalltalk.
Sorry if the question was too long.
Absolutely use <math.h>. You don't way to pay message sending overhead for functions that run in 30 cycles. Even function call overhead seems pretty steep at that point.
More generally, use as much or as little of C-style as you want to. I've seen Objective-C that was nothing but a couple C modules glued together with objective C messages, and I've seen Objective-C that essentially zero lines of code without the square brackets. I've seen beautiful, effective code written both ways. Good code is good code, however you write it.
In general, you'll use C features for numerical calculations. You'll generally use objects for most other things. The reason for this is that objects are way heavier than a simple scalar — there's just no benefit to it. Why would you ever write [[NSNumber numberWithInteger:1] numberByAddingNumber:[NSNumber numberWithInteger:2]] when you can just write 1+2? It's not only painful to read, it's far slower and it doesn't gain you anything.
On the other hand, Cocoa has rich object libraries for strings, arrays, networking and many other areas, and using those is a big win.
Knowing what's there — and thus what the easiest way to do something is — is just a matter of learning. If you think something should be there and you can't find it, you can ask either here or on Apple's Cocoa-Dev mailing list.
As for a collection protocol — there really isn't one. The closest thing to it is the NSFastEnumeration protocol, which defines precisely one method: countByEnumeratingWithState:objects:count:. This lets you use the for (id someObject in someCollection) syntax to enumerate the objects in a collection. Otherwise, all the collections define their own independent interfaces.
The first problem I've encountered is that I don't know where to draw a line between ObjC and C.
My rule is to use C wherever it makes sense to you. Objective-C has the benefit of letting you choose when to be procedural and when to be object-oriented. Go with what fits best with the code you're writing.
Another thing that I couldn't find was a collection's protocol [...] I want to implement an expresion tree class and I wanna know if there are methods that all collections should implement (like in Java) or I gotta check by hand every collection and see if there is a method that my collection should have.
Unlike Java, Objective-C does not have a master protocol for collections like the java.util.Collection interface. Also, there aren't a proliferation of specific container implementations as in Java. However, that gives you the freedom to implement a collection in a way that makes sense for your code.
For building a tree-like structure, you might take a look at NSTreeNode to see if it might be useful to leverage. (It may be more than you're need or want, but might be worth a shot.)
As far as rolling your own collection, I've learned a lot while creating CHDataStructures.framework, and you're welcome to use whatever you like from that code, or just look at my attempts at creating Cocoa-like structures, designed to complement the Foundation collections and operate similarly. Good luck!
Try to use each language for what it's good at. IMHO, this would include Obj-C objects but C-like code implementing methods. So use math.h and concise C code to implement logic, but don't be shy about using Obj-C classes to organize your larger blocks of functionality into something that makes sense.
Also, try to interact with the frameworks using their style so you're not running upstream.
As has been mentioned, there’s no real protocol for abstract collection classes (aside from the NSFastEnumeration protocol which provides the for(id item in collection) syntax when implemented), but there are conventions to follow.
Apple’s Introduction to Coding Guidelines for Cocoa covers some of this, and there is in fact a section on naming collection methods which covers the general cases (though note that generic container classes such as NSArray use the term “Object” as opposed to “Element” listed in the examples there – i.e. addObject:, removeObject:, and so on).
Following the patterns listed here (among others) is actually crucial when you want your classes to be KVC-compliant, which allows other users to observe changes in your object’s properties.
I have seen a number of different topics on StackOverFlow discussing the differences between Procedural and Object-Oriented Programming. The question is: If the program uses an object can it still be considered procedural?
Yes, and a lot of early Java was exactly that; you had a bunch of C programmers get into Java because it was "hot", people who didn't think in OOP. Lots of big classes with lots of static methods, lots of RTTI in case statements, lots of use of instanceof.
GLib has GObject which is object oriented programming implemented in pure C. While you can build up an API which begins to "feel" like OOP, it's still just plain "C" code with no actual classes (from the compiler's point of view). If you get far enough so you're starting to implement Object Oriented design patterns then I would call that OOP no matter what language it's written in. It's all about the feel of the code and how you have to think to write against it.
Procedural programming has to do with how you structure your program and model your domain. Just because at some point you instantiate an object, doesn't alone make your program oriented towards objects (i.e., object-oriented).
The distinction is entirely subjective. For example, if you code a C library using state passing, you are implementing something of a "tell" pattern, with the state as the object.
Classes can be considered as super types. When we converted from VB3 to VB6 our first pass was finding all the types we used, then finding all the subroutines and functions that took that type as a parameter. We moved those into the class definition, removed the parameter and then tested leaving the original flow of control intact
Then we refactored our flow of control to use various patterns and object oriented techniques.
The heart of object orientation is about how you decompose the problem into smaller parts, and how these parts work together. It's about the philosophy. Using OO language does not necessarily mean a program written in it is OO; it's just easier to do OO with a language that supports common OO concepts out of the box.
To answer the question: "If the program uses an object can it still be considered procedural?" - That depends on what your definitions of object and procedural programming are. But in my opinion, the answer is resounding "Yes". "Objects" are only a part of the philosophy that is OO and using them "somewhere in your application" does not mean you're doing OO.
The answer to your question is, yes. For example. I've got an old php legacy page to maintain. Most of the code is procedural but I decided that some things can be maintained much easier if I plug Zend Framework into the existing stuff and write some of my own classes to replace some of the old code. In general this application is still written and functioning in a mainly procedural way but here and then a class or another are instantiated and used. I guess there is no clear border between procedural and OO. You can do it cleaner or less clean. If you don't have enough layers for the size and complexity of your app you'll end up with more procedural code automatically too...