Programming has come a long way. I am still relatively young (first Computer: C64), hence I take many things in programming for granted that were obviously introduced at some point and facilitated ways of programming that are now commonplace.
What follows is a (by no means complete) list of features, where I would love to know in which language and when they were introduced:
introduction of functions
compiled language
interpreted language
conditional & loop structures
the array
the dictionary (Hashtable)
allowance of multi-threading
functional programming (functions as data)
object orientation (do we need to be more specific? maybe inheritance was there earlier than interfaces?)
generics
aspect-oriented programming
meta-programming
If you can, try to back up your statement with some reference. If you feel I have missed an important programming language feature whose introduction should also be appreciated, please comment on this question such that it can be added to the list.
UPDATE:
I suppose that a programming language cannot introduce anything that wouldn't be possible in assembler, I'm rather looking for languages that made a certain feature available to "mere mortals".
Lisp. 1958.
Alternatively,
introduction of functions - Alonzo Church's lambda calculus, 1930
compiled language - Grace Hopper, 1952
interpreted language - Lisp, 1958, maybe something before.
conditional & loop structures - Bletchley Park Bombe 1940s ( ran in a loop ). Jacquard, 1801
the array - as a contiguous chunk of memory with an index, Bletchley Park or Manchester Baby, 1940s
the dictionary (Hashtable) - ?
allowance of multi-threading - Jacquard, 1801; Multix 1965
functional programming (functions as data) - Godel, 1930s
object orientation
Simula ( Dahl and Nygaard 1967 ) for class based OO with inheritance
CLU ( Liskov 1975 ) iterators had a common interface, and allowed abstract data types with encapsulated state and behaviour
Smalltalk ( Kay late 1970s ) 'everything is an object'
Eifell ( Meyer 1986 ) design by contract influenced Java's interfaces
generics - generic methods ( Lisp again ) or parametric types ( modula??? )?
aspect-oriented programming - common lisp meta-object protocol, late 1980s
meta-programming - lisp macros, sometime in the 50s or 60s
To the best of my knowledge (and with the help of Wikipedia), I would state the following:
Functions - Early Assembly, using instructions such as "jump to subroutine".
Compiled language - Arguably A-0 in 1952 or [FORTRAN](http://en.wikipedia.org/wiki/FORTRAN in 1957.
Interpreted language - Smalltalk (?) in the 1970s.
Conditional & Loop structures - Early Assembly, using branches/jumps.
Arrays - Used in the very earliest computers (1940s). Appeared as a language feature in FORTRAN. See this text.
Hashtable - Around the same time as arrays, since it only really uses a basic algorithm on top of an array data structure. As a class, perhaps Dictionary in Smalltalk.
Multi-threading - This is moreover a feature of the operating system/a library, though language features can of course facilitate multithreaded coding. It probably dates back to the 1960s/1970s, though, and I'd imagine it could be done in Assemby.
Functional programming - LISP in the 1950s, inspired by Alan Turing's lambda calculus.
Object orientation (OOP) - Simula in the 1960s.
Generics - CLU in the 1970s.
Aspect-oriented programming - Perhaps AspectJ in 2001. (Someone may need to correct me on this.)
Meta-programming - Early Assembly, with self-modifying code.
Please feel free to modify/update this with any additional information.
You could use a language graph here: http://www.levenez.com/lang/ and Wikipedia to find answers. For starters: functions, loops and conditionals are with us since Fortran. And then, in 1958 Lisp arrived, I think some will argue that the rest came then :)
Finding firsts always leads to hair splitting. I'll bet any of the things you mentioned were done several times over before they hit the big time. Nonetheless, here's an attempt:
functions -- FORTRAN, but not recursive. LISP or Algol for recursion.
compiled language -- FORTRAN
interpreted language -- LISP
conditional and loop structures -- FORTRAN, but Algol gave us structure programming
the array -- FORTRAN
the dictionary -- Snobol, I think
allowance of multi-threading -- PL/I
functional programming -- LISP but perhaps not in a strong sense.
object orientation -- Simula but Smalltalk was the real popularizer
generics -- dunno
aspect-oriented -- dunno
meta-programming -- perhaps C++, but then code generating code isn't a new idea
I think we can safely say "assembler". Most if not all of these concepts have been around for a very long time.
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.
As per my knowledge, Objective-C is an Object oriented programming languge and Categories is a feature provided by Objective-C.
So I would like to know that Category feature is coming under which OOPs concept
Abstraction
Polymorphism
Encapsulation
Inheritance, etc.
Thanks in advance.
Mrunal
#Abizern's answer is good. I would add that categories are a form of dynamic dispatch, in particular that they can be used to extend existing classes without subclassing.
That said, Object Oriented Programming is more a design philosophy than a set of language features. One might ask "what OOP feature does postfix increment correspond to?" The answer is "none; it's a language feature." Categories are not primarily used to implement OOP design (though sometimes they are, as noted above). Their original use was to break up large implementation files. Their later use was to provide informal protocols due to a flaw in the language (lack of #optional). And today, they're primarily used to split code along platform-specific lines (NSString+UIStringDrawing vs NSString+AppKitAdditions).
Extensions are similar to categories, and similarly are primarily a language feature rather than an OOP design feature. They facilitate encapsulation to some extent, but mostly are a side-effect of an arbitrary compiler requirement to define methods before they are used (I say "arbitrary" because this is not related to design or developer needs; it just simplifies the compiler). Extensions should not be confused with some deep OOP requirement.
So using categories to attach additional functionality at runtime is dynamic dispatch. Beyond that, it's just a language feature that's used for several non-OOP things.
According to the Cocoa Design Patterns book by Buck and Yacktman. Category is a pattern in itself, and one that is supported by the Objective-C programming language directly.
Probably closest to Encapsulation, when it comes to academic OOP concepts. But this really shows the difference between academic definitions of OOP, and the practical world of OOP Design Patterns.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
I'm watching a video course/lectures from Stanford. The course is "The Structure and Interpretation of Computer Programs"
In the first OOP lecture, the instructor (Brian Harvey) describes an OOP method as one that gives different answers for the same question, while a function in functional programming gives a certain output for a certain input.
The following code is an example of a method in OOP that gives a different answer each time it's called:-
(define-class (counter)
instance-vars (count 0))
(method (next)
(set! count (+ count 1))
count) )
Now although the course is illustrated by scheme, I didn't pay much attention to the language itself, and so I can't explain the code; but can't a similar function "next" do the same thing as this "next" function?
In C, I would declare a global variable, and each time increase it by one when calling next. I know C is procedural, but I'm guessing a similar thing can be done in Scheme.
Well. With all due respect to the lecturer, these are slightly fishy definitions of both "OOP" and "functional programming". Both terms are consistently used, well, inconsistently, both in industry and academic contexts, not to mention informal use. If you dig a bit deeper, what's really going on is that there are several orthogonal concepts--different axes along which a choice is made in how to approach a program--that are being conflated, with one set of choices being arbitrarily called "OOP" despite not having anything else tying them together.
Probably the two biggest distinctions involved here are:
Identity vs. value: Do you model things by implicit identity (based on memory location or whatnot) and allow them to change arbitrarily? Or do you model things by their value, with no inherent notion of identity? If you say x = 4 does that mean that x is an alias to the timeless Platonic ideal of the number 4, or is x the name of a thing that's currently a four, but could be something else later (while still being x)?
Data vs. behavior: Do you work with simple data structures whose representation can be inspected, manipulated, and transformed? Or do you work with abstracted behaviors that do things, representing data only in terms of the things you can do with it, and let these behavioral abstractions operate on each other?
Most standard imperative languages lean toward using identity and data--pointers to C structs are about as purely this approach as possible. OOP languages tend to be defined largely by opting for behavior over data, often leaning toward identity as well but not consistently (cf. the popularity of "immutable" objects).
Functional programming usually leans more toward values rather than identity, while mixing data and behavior to various degrees.
There's a lot more going on here as well but I think that's the key part of what you're wondering here.
If anyone's curious I've elaborated a bit on some of this before: Analyzing some essential concepts of many OOP languages, more on the identity/value issue and also formal vs. informal approaches, a look at the data/behavior distinction in functional programming, probably others I can't think of. Warning, I'm kind of long-winded, these are not for the faint of heart. :P
There is a page on the excellent Haskell wiki, where differences in Functional Programming and OOP are contrasted. The Haskell wiki is a wonderful resource for everything about functional programming in general in addition to helping with the Haskell language.
Functional programming and OOP Differences
The important difference between pure functional programming and object-oriented programming is:
Object-oriented:
Data:
OOP asks What can I do with the data?
Producer: Class
Consumer: Class method
State:
The methods and objects in OOP have some internal state (method variables and object attributes) and they possibly have side effects affecting the state of computer’s peripherals, the global scope, or the state of an object or method. Variable assignment is one good sign of something having a state.
Functional:
Data:
Functional programming asks How the data is constructed?
Producer: Type Constructor
Consumer: Function
State:
If a pure functional programming ever assigns to a variable, the variable must be considered and handled as immutable. There must not be a state in pure functional programming.
Code with side effects is often separated from the main purely functional body of code
State can be passed around as an argument to a function, this is called a continuation.
Functional substitutes for OOP generators
The way to do something similar to OOP style generators (which have an internal state) with pure functional programming is to approach the problem from a different point of view, by using one of these solutions depending on the use case:
1. Process some or all values in a sequence:
Type of sequence can be list, array, sequence or vector.
Lisp has car and Haskell has first, which take first item from a list.
Haskell also has take, which takes the first n items, and which supports lazy evaluation and thus infinite or cyclic sequences – like OOP generators do.
Both have first, and different map, reduce or fold functions for processing sequences with a function.
Matrices usually also have some ways to map or apply a function to each item.
2. Some values from a function are needed:
The indices might be from a discrete or continuous scale (integers or floats).
Make one pure function to generate the indices (events) and feed those to another pure function (behaviour). This is called Functional reactive programming. This is a form of Dataflow programming along with cell-oriented programming. The Actor model is also somewhat similar in operation, and a very interesting alternative to threads with handling concurrency!
3. Use a closure to confine and encapsulate the state from the outside
This is the closest subsitute to OOP way with generators (which I think actually originated to imitate closures), and also farthest from pure functional programming, because a closure has a state.
"Functional" in functional programming has traditionally referred to the meaning of mathematical functions. That is, the output of a mathematical function is based solely on the inputs passed to it. Nowadays such programming is more often called pure functional programming.
In pure functional programming reassigning state is not allowed, thus writing a function such as your C example would not be possible. You are only allowed to bind a value to a variable once. An example of a language where this would not be possible is Haskell.
Most functional programming languages (Scheme included) are unpure and would allow you to do so. Said that, what the lecturer is telling is that writing such a function is not possible in the traditional sense of functional programming.
Well, yeah, you could do that in C.
But its not the same - in C++ you can make each object have its own count.
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.