brnstnd@stealth.acf.nyu.edu (04/08/90)
In article <DAVIS.90Apr6151002@muscle.pacific.mps.ohio-state.edu> davis@pacific.mps.ohio-state.edu (John E. Davis) writes: [ what's life, the universe, and everything? ] 42. ANSI C is the C standard settled upon by ANSI; it's generally better than the old language, but most C compilers today don't understand it. > Also what is object oriented programming? The latest name that young urban computer science types have applied to the old idea of adding another level of indirection to function calls. Followups to comp.lang.misc. ---Dan
tneff@bfmny0.UU.NET (Tom Neff) (04/09/90)
>>> Also what is object oriented programming? >> The latest name that young urban computer science types have applied to >> the old idea of adding another level of indirection to function calls. >Bravo! But, I doubt you will hear many more positive responses to that >statement. Few ideas are totally new. Most have precursors. Useful new disciplines can involve combining not-so-new ideas in new ways. OOP combines information hiding and functional indirection to create something fairly powerful. I can sympathize with grumbling veterans who see recognizable ideas at the center of OOP and feel like dismissing the result as Not That Big A Deal. (If I had been around at the time, I probably could have mustered similar sympathy for old line machine language hackers sneering at those new "high level" languages.) But you can't turn back the clock. If programming were perfect it wouldn't need any new approaches. I am not too impressed with our current state of perfection, are you? -- To have a horror of the bourgeois (\( Tom Neff is bourgeois. -- Jules Renard )\) tneff@bfmny0.UU.NET
jlg@lambda.UUCP (Jim Giles) (04/09/90)
From article <6000:Apr720:31:1490@stealth.acf.nyu.edu>, by brnstnd@stealth.acf.nyu.edu: > In article <DAVIS.90Apr6151002@muscle.pacific.mps.ohio-state.edu> davis@pacific.mps.ohio-state.edu (John E. Davis) writes: > [...] >> Also what is object oriented programming? > The latest name that young urban computer science types have applied to > the old idea of adding another level of indirection to function calls. Bravo! But, I doubt you will hear many more positive responses to that statement. J. Giles
Chewbacca@cup.portal.com (Paul Frederick Snively) (04/10/90)
brnstnd@stealth.acf.nyu.edu writes: >> Also what is object oriented programming? > >The latest name that young urban computer science types have applied to the >old idea of adding another level of indirection to function calls. At best this definition is grossly naive and misinformed; at worst it is just plain wrong. There doesn't seem to be a "definitive" description of the fundamentals of object-oriented programming, so the best that I can do is to provide you with a list of the things that come to my mind when I happen to think of object- oriented programming: * Encapsulation (the association of data with the procedures that operate on them), whether rigidly enforced or not. * Inheritance (the notion that these combinations of data and procedures can be described as increasing specializations of their ancestors, e.g. an AVL tree might be a specialization of a binary tree, which in turn might be a specialization of a tree, etc. Many object-oriented systems use terms like class, superclass, and subclass to refer to this relationship). * Polymorphism (the notion that I should be able to plug-and-play objects as long as I send them the right message with the right interface, e.g. asking a string object to "print" itself and asking a floating-point object to "print" itself should both work as I expect, regardless of how the "print" mechanism for each of those types does its thing). Object-oriented languages run quite a gamut--everything from the deliberately simplistic Object Pascal to the bordering-on-the-eldritch Common Lisp Object System. Hopefully this is a reasonable introduction to the underlying concepts. Some readers may point out that none of the features of object-oriented programming is impossible to accomplish without using object-oriented programming languages, and of course, they are correct--as usual, the issue is solely one of whether you wish your language to assist you in such architectural trivia or not.
grover@brahmand.Sun.COM (Vinod Grover) (04/10/90)
In article <28742@cup.portal.com> Chewbacca@cup.portal.com (Paul Frederick Snively) writes: >brnstnd@stealth.acf.nyu.edu writes: > >>> Also what is object oriented programming? >> >>The latest name that young urban computer science types have applied to the >>old idea of adding another level of indirection to function calls. > >At best this definition is grossly naive and misinformed; at worst it is just >plain wrong. > >There doesn't seem to be a "definitive" description of the fundamentals of >object-oriented programming, so the best that I can do is to provide you with >a list of the things that come to my mind when I happen to think of object- >oriented programming: > >* Encapsulation (the association of data with the procedures that operate on > them), whether rigidly enforced or not. Who says encapsulation cannot be provided by functions? >* Inheritance (the notion that these combinations of data and procedures can > be described as increasing specializations of their ancestors, e.g. an AVL > tree might be a specialization of a binary tree, which in turn might be a > specialization of a tree, etc. Many object-oriented systems use terms like > class, superclass, and subclass to refer to this relationship). Block structure (lexical scoping in newspeak) can provide some of these too.
cs2591aq@carina.unm.edu (aNk1ez) (04/10/90)
OOPS is a term coined by some unknown programmer when his code accessed the data the wrong way. :-) Seriously, everyone.. I haven't seen one *real* use of objects, except to confuse people. (But then, i'm one of those people who still believes the best way to handle data is to do your own memory accessing.) Techs / cs2591aq@carina.unm.edu aNk1e Byt0rZ klUb common account.
new@udel.EDU (Darren New) (04/10/90)
In article <2239@ariel.unm.edu> cs2591aq@carina.unm.edu.UUCP (aNk1ez) writes: >Seriously, everyone.. I haven't seen one *real* use of objects, except to >confuse people. What do you mean by a "*real* use of objects"? I have an application in which each item is an object and all respond to some messages ("redraw", "pick a good default graphic", ...) and some contain heterogeneous (sp?) lists of other objects and so on. I think this is "real" objects. Why is it not "real" objects to you? (BTW, it's a FD program for animating Estelle specs, if you are interested) -- Darren
rick@tmiuv0.uucp (04/12/90)
In article <28742@cup.portal.com>, Chewbacca@cup.portal.com (Paul Frederick Snively) writes: > brnstnd@stealth.acf.nyu.edu writes: > >>> Also what is object oriented programming? >> >>The latest name that young urban computer science types have applied to the >>old idea of adding another level of indirection to function calls. > > At best this definition is grossly naive and misinformed; at worst it is just > plain wrong. > > There doesn't seem to be a "definitive" description of the fundamentals of > object-oriented programming, so the best that I can do is to provide you with > a list of the things that come to my mind when I happen to think of object- > oriented programming: > [list of items deleted] The best "thumbnail" sketch of OOPS (Object Oriented Programming Systems) I can offer is that your programming style (well, actually your problem solving style) changes. Currently, C causes you to think "procedure-wise". In other words, you think about _how_ to solve the problem, writing a list of procedures that will accomplish the task. This involves how to manipulate the data objects you're playing with at each step of the way. In C++, the OOPS version of C, you think "solution-wise". You simply write code which treats your data objects as though they were standard C variable types. You don't have to worry about "Gee, now, if I want to add these two structures, I have to add each member of one to the corresponding member of the other" and write the code to do that each time. Instead, you simply say "c = a + b", where a, b, and c are the structures you are playing with. Later on, you write a "data abstraction" which defines what the structures look like, a set of functions and operators which perform the operations on the data, and which parts of the structures are visible to the outside world. Once that's done, your code is much more readable, since you're not writing "c.mem1 = a.mem1 + b.mem1;", just "c = a + b". That's simplifying it a bit, but the general idea is correct. C++ can really make some nasty and complex code a heck of a lot easier to deal with. -- .-------------------------------------------------------------------------. / [- O] Rick Stevens (All opinions are mine. Everyone ignores them anyway.) \ | ? +--------------------------------------------------------------------| | V | uunet!zardoz!tmiuv0!rick (<-- Work (ugh!)) | |--------+ uunet!zardoz!xyclone!sysop (<-- Home Unix (better!)) | | uunet!perigrine!ccicpg!conexch!amoeba2!rps2 (<-- Home Amiga (Best!!) | \ 75006.1355@compuserve.com (CIS: 75006,1355) (<-- CI$) / `-------------------------------------------------------------------------' "I bought some instant water, but didn't know what to add." - Steven Wright
davies@sp20.csrd.uiuc.edu (James R. B. Davies) (04/13/90)
In article <539@tmiuv0.uucp>, rick@tmiuv0.uucp writes: |> The best "thumbnail" sketch of OOPS (Object Oriented Programming Systems) I |> can offer is that your programming style (well, actually your problem solving |> style) changes. Currently, C causes you to think "procedure-wise". In other |> words, you think about _how_ to solve the problem, writing a list of procedures |> that will accomplish the task. This involves how to manipulate the data |> objects you're playing with at each step of the way. |> |> In C++, the OOPS version of C, you think "solution-wise". You simply write |> code which treats your data objects as though they were standard C variable |> types. You don't have to worry about "Gee, now, if I want to add these two |> structures, I have to add each member of one to the corresponding member of |> the other" and write the code to do that each time. Instead, you simply say |> "c = a + b", where a, b, and c are the structures you are playing with. Later |> on, you write a "data abstraction" which defines what the structures look like, |> a set of functions and operators which perform the operations on the data, and |> which parts of the structures are visible to the outside world. Once that's |> done, your code is much more readable, since you're not writing "c.mem1 = |> a.mem1 + b.mem1;", just "c = a + b". |> |> That's simplifying it a bit, but the general idea is correct. |> |> C++ can really make some nasty and complex code a heck of a lot easier to deal |> with. |> Well, I for one don't always write the absolute lowest-level inline-est code possible when using ANY language. My first impulse when I want to copy one string to another isn't to think "Gee, now, if I want to copy one string to another, I have to move each byte of the first string to the corresponding byte of the second string" and then write register char *cp1,*cp2; for (cp1=string1,cp2=string2;*cp1;cp1++,cp2++) *cp2 = *cp1; *cp2 = '\0'; Instead I write strcpy(string2,string1); Admittedly, it might be nice to just write string2 = string1; but I'm comfortable with function calls instead of operator overloading. What you're describing used to be called "information hiding" and "modularity" and "reusability" and maybe "functional decomposition" and probably "structured programming". The argument about "C makes you think of methods" versus "C++ makes you think of objects" is a rehash of an old claim by the function-language crowd. I've seen little evidence that it has any validity among trained, experienced programmers - they can write in any language successfully. And, as it has oft been stated, it is possible to write bad code in any language (even C++). All in all, I tend to agree with Mr. Bernstein - the same old stuff using some new words.
) (04/13/90)
Yes, it is possible to write bad code in any language (esp since
C++ will accept C code), and no, it can't FORCE you to think in any
particular style... (a better word would be encourage, but that still
has nothing to do with what I"m about to say).
The first OOPS was Simula... Smalltalk evolved from something that
evolved from Simula.. and thats that.. Simula, as you can sort of tell
from the name, was a language written for creating simulations.
It also happens that the data hiding features of the language are
encouragable things to a "well structured program". The DoD liked the
way it handles object, and had it encorporated into Ada (since Ada is
designed to work with actual systems, having somthing that deals with
actual objects real well is good).
My reason for liking the language is that I *LOVE* C, and happen
to be very interested in simulation work..and C++ gives me a lot of tools
and system features to do things.
An interesting note is that the first C++ compilers didn't output
native code (executable), they output C code... so anything you do in
C++ *can* be done in C...just not so cleanly (it basically checks your
code and does some syntactic modification..
string1 + string2
becomes
string.add(string1,string2)
where string.add is a pointer to a function that adds strings by whatever
your definition of "string addition" is (it also returns whatever you
tell it to).
though, g++ does output executable.
Johndjones@megatest.UUCP (Dave Jones) (04/13/90)
I've lost track of who contributed how many levels of greater-than's ">". >>>> Also what is object oriented programming? > >>> The latest name that young urban computer science types have applied to >>> the old idea of adding another level of indirection to function calls. > >>Bravo! But, I doubt you will hear many more positive responses to that >>statement. > As others will point out, with varying degrees of indignation, the indirect function call idea is only part of it. "Oop" is a collection of old ideas -- exactly which collection it is is the subject of endless debate. Nothing wrong with that, of course. Invention is always accomplished through recombination and synthesis. > ... > I can sympathize with grumbling veterans who see recognizable ideas at > the center of OOP and feel like dismissing the result as Not That Big A > Deal. I'm one of those veterans. So far, no need for a drool cup, but I keep the medical prosthesis company's phone number handy. Be that as it may. Guess what? I like C++. No, it's not that big a deal, but I like it and use it when I can. (Thanks, Bjorne.) I also enjoyed some of the books on OOP. (Thanks, Brad.) Discussions can indeed be a little irksome for us crusty old silver-backs when we think we hear the young geniuses crowing about having saved software from our ineptitude. How smart they are and how well they understand. What big words they invent. The only consolation is the certain knowledge that most of them will grow up, and there will be a brand new crop of geniuses lecturing them! The growing up doesn't usually even take very long. Two or three years full time at a real job usually does it. > (If I had been around at the time, I probably could have mustered > similar sympathy for old line machine language hackers sneering at > those new "high level" languages.) The analogy is not quite fair. For one thing, I don't think it ever happened that way. FORTRAN was an immediate, smashing success, even with -- especially with -- the "old line" machine language hackers of the time (who were mostly in their twenties). The big advantage was not so much that it is "high level" -- I have never yet figured out what that means -- it was that it is machine-independent. Some ideas are so obviously good that there is not much room for argument. For that matter, I don't think there is much argument that the techniques of "object-orientation" are useful. I, and no doubt many others, independently came to use so-called "OOP" techniques, long before I ever heard the term "object-oriented". But I do not think languages which assist in automating such programming are nearly so revolutionary as the first machine-independent languages were. But if you think all that has much to do with the irk-factor, you really don't understand the nature of irk. Irk has nothing to do with being right or wrong. Recipe for irk: Mix equal parts of presumption, vanity, and stubbornness. Add ignorance to taste. Allow to fume. As one how-to book on fiction writing I recently read put it, if you want to make a character irksome, you can make him "self-appointed". > >But you can't turn back the clock. > Sometimes the clock turns itself back. When I was young-and-easy-about- the-lilting-house, "top-down design" and "piecewise refinement" were going to save the software world, and the hot new item was Pascal. There were whole sections in the computer bookstores devoted to those topics, just as there are now for OOP. It took us a few years to figure out how much off the mark all that was, but eventually, the clock turned back. > If programming were perfect it wouldn't need any new approaches. I am > not too impressed with our current state of perfection, are you? Yes! Imperfect though it may be, how can you fail to be impressed? I am very much impressed indeed! It is easy to be cynical when you are intimately familiar with a field of endevour. And it is true that the discipline can, and will, get much better. But look around you and marvel at the number and variety of machines you see being dependably controlled by computer! As recently as a dozen years ago, you saw virtually none. Now they are everywhere. And somehow, in spite of the imperfect way we develop and test them, the programs work -- not always, and not always perfectly, but they work damned well, and they are getting better all the time. For the most part, the check gets printed, the brakes don't lock, the airplane lands. The call goes through, the tee-shirt logo gets stamped, the newspaper gets printed. The elevator elevates. Last night on the TV, I heard a Bach cantata sung by a coloratura soprano computer so expertly that it was chilling! Not only do the programs work, but they are now developed in a small fraction of the time it would have taken fifteen years ago. As long as I am in this business, I will try to improve software development techniques and disciplines, but I see no reason to sneer at what has been done so far, in so short a time. I find it utterly amazing!
brnstnd@stealth.acf.nyu.edu (04/14/90)
In article <28742@cup.portal.com> Chewbacca@cup.portal.com (Paul Frederick Snively) writes: > brnstnd@stealth.acf.nyu.edu writes: > > > Also what is object oriented programming? > > The latest name that young urban computer science types have applied to the [ obtw, credit to Rod Schmidt for noting the abbreviation ``Yuckies'' ] > > old idea of adding another level of indirection to function calls. > At best this definition is grossly naive and misinformed; at worst it is just > plain wrong. I stand by my definition. For fun I implemented so-called ``strictly type-checked fully polymorphable objects with multiple inheritance'' in C macros a few months ago. From the point of view of the macros, objects were either another level of indirection to both function calls and structure element accesses, or another level of indirection to just function calls, depending whether they were compiled for space or for speed. Followups to comp.lang.misc once again. ---Dan
Chewbacca@cup.portal.com (Paul Frederick Snively) (04/14/90)
brnstnd@stealth.acf.nyu.edu writes:
[description of OOP system done solely with C macros deleted]
I think we're functionally agreeing to disagree. :-)
My basic point was that your description was incomplete; the system that you
describe having implemented sounds like it fits my conception of OOP better
than the definition that you posted.
I didn't mean to imply at all that OOP cannot be achieved in a "non-OO"
language; that would be silly. Most C++ translators are merely preprocessors
to C. A great many object systems in Lisp are created by some fairly simple
fiddling around with closures and continuations.
I see the current emphasis on OOP as _legitimizing_ the approach in much the
same way that structured programming was legitimized by languages that, to one
degree or another, enforced a structured approach to writing code. I can
write structured pretty-much-anything, even assembly language, if I want.
Similarly, I can write object-oriented pretty-much-anything, if I want to
write the support code myself, but why bother when there are languages that
institutionalize it?
For what it's worth, I think there _is_ a cultural gap involved--I've seen
too many good programmers find themselves in a time capsule of their own
construction because they didn't wish to apply any new methodologies--whether
of their own creation or not--to the tasks facing them. Some of them have
gone on quite nicely in environments that tend to be pretty technologically
stable. Others, such as in my world (I work in Macintosh Developer Technical
Support at Apple Computer) move in a considerably faster-paced world: the OSes
and application-development toolkits keep getting larger and more complex
every day. The Mac OS/Toolbox by now has well over 700 calls available to
developers, and the architecture is, frankly, pretty weird. OS/2, X-Windows,
SunView, etc. developers are faced with similarly large application
interfaces. OOP tends to help factor the complexity of such systems by
allowing the developer to easily map from the concrete to the abstract: you
can see a window on the screen. It is an object. As such, the window object
consists of these data structures and knows how to do these things (instance
variables for the data structures, methods for the things it knows how to do).
If nothing else, it seems to me that the OOP methodology (apart from any
language that may or may not implement that methodology) is quite useful in
the world of graphical user interfaces.