Slashdot Mirror
Anthropomorphism and Object Oriented Programming
An anonymous reader writes: We've all been warned about how anthropomorphizing animals and machines can lead us astray. But Edsger Dijkstra once cautioned (PDF) developers against thinking of their programs that way as well. "I think anthropomorphism is worst of all. I have now seen programs 'trying to do things,' 'wanting to do things,' 'believing things to be true,' 'knowing things' etc. Don't be so naive as to believe that this use of language is harmless. It invites the programmer to identify himself with the execution of the program and almost forces upon him the use of operational semantics." A new article fleshes out Dijkstra's statement, providing a good example of where an anthropomorphized analogy for Object Oriented Programming breaks down when you push it too far.
Dijkstra spends time building an analogy, then explains how it's flawed, and uses that to argue against 'anthropomorphizing'.
That's nice, and I certainly agree that the analogy can only go so far, but he was the one to build that analogy in the first place. This is not a valid argument against anthropomorphizing at all.
I do agree with the conclusion that anthropomorphising is not a reason to call OOP better than procedural.
---
"I don't know how many of you have ever met Dijkstra, but you probably know that arrogance in computer science is measured in nano-Dijkstras"
Object oriented programming, the "crystal healing therapy" of computer science.
EOF
I used to have a procedural toaster which cooked the bread until it became toast. Then I upgraded to a much more elegant OO toaster, which simply sends a "toast yourself" message to the bread. Unfortunately, bagels don't have a self.toast() method, so i still have to have a backup procedural toaster to handle the older API.
anthropormphism sounds like a chick thing
If there were true, FurCons would be glorious.
I get it that the author wants to make a point about abstraction (which is what it's really about, not just anthrom... whatever). However, I think he theorizes too much (CS) and misses the practical aspect of programming (reaching an end goal imperfectly).
In the end, every programming language is just coded instructions making the computer or robot or whatever, do whatever heck you want it to do. Sometimes procedural is the best fit. Sometimes OOP is nice (yes, you can call it abuse, but if it fits the problem space, it can be very satisfying, quick and easy to keep tabs on). Sometimes a framework fits neatly and saves man-hours and number of developers (hello ActiveRecord!). Sometimes even functional or logic (Prolog) can be a better fit (never had a use for it myself but for those masochistic enough I'm sure it's VERY satisfying).
Summary: Use the best tool that fit your needs. Don't forget: The tool is just a tool. A map is not the terrain itself. Etc.
Btw, some of us have created "living" data structures that we can't anticipate what will do next (chaotic systems). Sometimes we even call them "games". Welcome to 2000!
Btw, in reality procedural and object oriented are just two different views and controls on the exact same datastructures and process-flows. If you really would like to, you could even say it's all machine code in the end too. Obviously though, it does not make sense to constrict yourself to just one tool or perspective out of sheer idealism. Nor is it very productive to attempt for perfection for something that will from experience age pretty quickly.
Ya, sure. It is so much better to use the phrase: "The program contains a variable that stores your name", instead of: "The program knows your name". English, ect. all was not designed to work that way. Unless you want to take a week to describe a single program, it really helps to anthropomorphise it.
Troll is not a replacement for I disagree.
Like all, this one works up to a point. Learning something new without analogies is probably going to be very slow. It's not like this is the downfall of programming, but it's passing-interesting as a note.
"Win treats sysadmins better than users. Mac treats users better than sysadmins. Linux treats everyone like sysadmins."
My code wants to be antropomorhized!
If something breaks down when you push it too far, then don't push it too far.
For me, I prefer OO programming (c++/java) to functional programming (C-lang), just due to encapsulation. I like having an object, with methods for its attributes, public/private methods, and such. Then having the objects interact in my program. It kinda makes sense to how I think.
However, I also think that if a team or individual programmer can release software that serves a useful purpose, and is maintainable, then those are the only things that matter. Which language, functional or object-oriented 'way' that was used to get there? Seems less important.
Uh, Linux geek since 1999.
Something that Dijkstra wrote in 1983, and a crap article that gives some examples of bad programming to show a bad point.
...they hate that.
OO isn't about anthropomorphism, it's about isolation and providing a clear API. If this was a large scale project with fifty people working on code that could move students, I don't want them implementing fifty different versions of move_student that will break whenever the Student or Classroom model changes.
I know it's trendy to hate on things that have been around a while, and OO indeed isn't the answer to everything, but it's still a useful way of keeping a complex program from getting out of control.
How can I believe you when you tell me what I don't want to hear?
He says that anyone who uses the term 'object oriented programming' is crazy. I don't think he's realized that OOP means that the functions go with the data.
"First they came for the slanderers and i said nothing."
One of the worst things about OOP is the stupid analogies used to explain it. If the people you're explaining it to can't understand it in abstract, programming terms then they're not worth wasting your time on because they'll be useless programmers anyway. But, of course, it's probably not the audience that's the problem, but the writer - who's incapable of communicating without resorting to stupid analogies.
Yeah, probably true.
I _meant_ function-al programming, .like as in using functions in C, as opposed to OO.
Uh, Linux geek since 1999.
Dijkstra makes an argument about what he calls object oriented programming, but doesn't really use OOP. That he happens to base his argument around two styles of coding, one that is clearly procedural, and one that happens to use objects, is merely accidental. His argument is centered around poor code organization, plain and simple. He passingly slaps down some code modeling Student as an object, neglecting to mention anything about why one would do that (e.g. encapsulation), and completely fails to even mention other OOP ideas such as composition, inheritance, polymorphism, etc. In short, he bashes horrendous code organization, and calls that OOP, without addressing a single reason typically given in favor of OOP. Frankly, that article was awful.
self.fuck
After working with decades of procedural software apparently modeled after spaghetti, I think object oriented models are a bit better.
His argument against anthropomorphism assumes that the person writing the code actually believes that their code magically acquires the qualities of a full blown human being with a consciousness. I'd wager that anyone that stupid (insane?) wouldn't be able to write computer programs that execute, let alone work as a programmer.
disingenuous clickbait in my book.
I think what this article highlights is that not everything Dijkstra said was gold. Nor does slavishly following his missives make you a better programmer.
One of the more stupid blog-level postings I've read. I use "blog-level" as an insult, btw. because blogs are generally a source of shallow thinking, because it just is too convenient to publish some thoughts. When it is more trouble, you're also forced to polish them more.
Firstly, to understand the difference between trying to do and "trying to do", read some Dennett. If correctly understood, anthropomorphisms like the attribution of intention to a non-intentional entity can be extremely helpful.
Secondly, not even his example is anywhere near what he's trying to explain. Yes, the analogy breaks down but it has nothing to do with the convulted reasoning he's applying. The cause for the analogy to break down is that there's no equivalent to walking to the classroom in his example. All of his code simply assigns a classroom number, without any equivalent of the walking part. As soon as you add that - magic ! - the analogy works again.
Assorted stuff I do sometimes: Lemuria.org
The insensitive clod who wrote this is clearly not working in AI.
Left MS Windows for Linux Mint and never looked back!
Vote for Bernie in 2016!
Often "the code is trying to..." is just shorthand for "the person(s) who coded this had the code to do...." It is always risky to speak informally about a formal system, but it is also a risk to be too formal - humans have a much harder time following formal language. The formal language, indeed, *is* the code, and the reason we don't just talk in code is that our brains are not wired that way.
When you have an influx of "developers" who also believe in elephant-gods and other various cloud-sitters, it's not hard to see why "computer science" in general has become irrational.
Oh FFS. Look on the bloody Bagel packet before you buy. If it doesn't say 'implements toastable' then don't buy em. Yeh , they may be a few bucks more, but thats your own fault for getting a toaster that is made by the same people who make the bagels.
Everywhere there was death as my process exited. So many destructors got called as objects self immolated, returning the souls of their allocations to the heveanly heap...
Felicia disagrees with you.
Get free satoshi (Bitcoin) and Dogecoins
This is why I like Python. Python allows object-oriented programming styles or procedural, or a mix. Python has a lot of warts, but it's really refreshing to me to use. Every time I look at Java, I'm turned off by the forcing of class-based object-oriented programming for everything, even when the program is really just procedural with a static main. Perhaps this tends to make programmers try to shoehorn OOP when it's not the best fit.
the OO way can be parallelized in a much more reader friendly way than the procedural one:
List group1=fetchGroup(1);
group1.parallelStream().forEach(Student::moveToRoom(2));
Even if this is a java-ism, the same things could be expressed in an even more concise fashion in C++ using Concurrency::parallel_for, now try do that in c99 while being as readable
The procedural code would not have been able to "know" when the bread is toast, it would just cook something for X seconds at T temp.
This is exactly what OO solves.
(but I still lol'd at the joke)
OOP is a tool, and like any tool it has places and times where it is useful, and places and times where it is not. Knowing when to use it and when not to is part of the art and craft of programming. Does OOP improve the overall organization, reading, and flexibility of a given portion of software to change? If you don't have a good answer, then consider skipping it.
All-or-nothing zealots are usually full of squishy stuff. In the past, one was told to model all domain nouns as objects and/or classes (depending on language flavor). That doesn't always work well, especially if a database is being used. Domain nouns are often poor candidates for OO-ness. Objects seem better suited, however, for computing-domain nouns, such as GUI's, report columns, files, sockets, security profiles, etc. That's my experience.
(However, lately GUI's seem to have outgrown OOP, as multi-factor and situational grouping and searching becomes more important for managing mass attributes and event handlers, and I'd like to see research in database-driven GUI engines, perhaps with "dynamic" relational or the like.)
Table-ized A.I.
If someone would spend a little time and look at the history of programming languages, then they'd quickly realise that OOP wasn't about Anthropomorphism, polymorphism, or any other 'isms. OOP came about for the simple reason of maintainability! If you look at the history of programing languages, then you'll find that new programming paradigms appeared when programming maintainability suffered. Assembly gave way to high level procedural/functional languages, which gave way to OO languages, which gave way to "Interface" abstractions and now we are moving into the Message Passing type paradigm as a result of needing to build massive scale. (I read somewhere way way WAY back that effective maintainability for procedural languages maxes out at about 5M likes of code, OOP was about 50M lines max, whilst Interface oriented methodologies was somewhere above 50M...although that was based on the fact that you could organise you code better by not having to have libraries derive from ACMEObject, although these those base classes form the runtime type info/serialisation/etc. within language BCLs, whereas the BLCs generally are organised around multiple, unrelated trees of objects these days). Whilst many of the concepts are not new (e.g. functional languages are fairly old), it has taken time for languages to integrate those concepts into base languages...some of the more recent languages incorporate these concepts...some are bolted on as libraries. One interesting aspect to the whole history is that whilst functional languages existed very early one (I heard hat a functional language was the second high level language after FORTRAN...possibly wrong...but early...non the less), functional languages don't see to suffer as much from the whole saleability issues...probably a result being more expressive, and being able to represent the target program state using less types/objects. There's a lot to learn about software...just take a look at the history, and you'll be a better developer for it.
That's why I love Apple's Swift, it's multiparadigmatic and can be procedural, OO or functional.
A dash of anthropomorphism is actually quite helpful to a programmer - the trick is that people are just not applying it in quite the right way; instead of considering a program or objects as a rational kind of being that does what you tell it, instead consider that code and objects are all malevolent entities that exist only to twist what you tell them to do into the most horrific possible result.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Anthropomorphism is degenerate no matter the situation.
True. Anthropomorphism is always trying to get into trouble and ruin other people's lives.
I often don't like the choices people make, but I like the fact that people make choices. That's why I'm a conservative.
Comment removed based on user account deletion
They don't really "know" or "think". It might look to some amateurs like apes (especially "homo sapiens") do that, but that's only because they are programmed to pretend to be thinking and knowing and in the end it's just a really complicated neuronal network that results in the "behaviour" you're observing. Basically it's all just a chemical reaction meant to make copies of chromosomes. If people wouldn't anthropomorphize everything, we would probably have found a more efficient way to produce chromosomes without the need for complex life decades ago!
Don’t anthropomorphize computers, they hate that notes that most developers do use anthropomorphic language. I think there are probably a variety of good reasons for it, too. Here's one speculation: When we communicate with a human, we must use some language that will be more-or-less understood by the other human. Over the years people have developed a variety of human languages that do this pretty well (again, more-or-less). Human languages were not particularly designed to deal with computers, but languages have been honed over long periods of time to discuss human behaviors and their mental states (thoughts, beliefs, goals, and so on). In any case, the problem isn't anthropomorphic language, it's the use of a bad analogy.
- David A. Wheeler (see my Secure Programming HOWTO)
First I would like to point out that OO and procedural are not so much different. The main difference is that in OO the procedure run is governed implicitly by the class the call is made on and not explicitly by the code that makes the call. Saying OO vs procedural is a false dichotomy. I will refer to "procedural" as non-OO
The example in the blog is overly simplistic and does not show the strengths of OO. It use OO where it is not needed. Here are some issues with the OO implementation;
1. Too few classes. What about teachers.
2. Class specific method; "move_students_to_classrooms" should not be a method it should be "move_people_to_classroom"
By adding teachers, teaching assistants, etc as classes that can all be told to "move" and do what each different class needs to do.
Try the following;
Class: Person
Abstract method move(cl)
Class: Student extends Person
Method move(cl){
Select desk;
remember cl
}
Class: Teacher extends Person
Method move(cl){
Count students;
Write name on board;
remember cl;
etc.
}
Class Principal extends Teacher
Method move(cl){
Super(cl)
Inform secretary;
}
Method move_people_to_classroom(List people){
for_each (person in people)
{
Classroom* cl = reg[student.name()];
person.move(cl);
}
}
Notice in this example the Principal would be doing the same thing in the classroom as a teacher plus a bit more.
In this example the the method move_people_to_classroom does not care what sub type of person is in the list it just tells them to move to the classroom. In the non-OO method one line of code "person.move(cl) would be replaced by something like the following;
Person_type = getType(person);
switch(person_type)(
case "Student":
move_student(student, cl);
break;
case "Teacher":
move_teacher(student, cl);
break;
case "Principal":
move_teacher(student, cl);
break;
default:
}
Now what happens if a new class of Person gets added and they do something different when they move to the classroom. One would have to remember this code and update it. In the OO implementation the code would be in the new class and much more obvious as the 'move' method is not implemented so the code would not compile. The beauty of OO is the ability ignorant of the type of person, give them the same command and have them do different things.
"The program doesn't know to check for" is in fact more accurate than "The program wasn't designed to check for". The second statement could mean that it wasn't designed to do something, but might do it anyway - what the program ACTUALLY does is left somewhat ambiguous (this is a technique lawyers will often use answering in court). In the first instance the statement makes it quite clear the program DOES NOT KNOW HOW to do what you are talking about.
You can shorten something so far for clarity, but if you go to far you end up with less clarity.
The "thinks" part at the end could go though, removing that does no harm to clarity.
The thing is, writing clearly is just plain hard - being able to use anthropomorphic kinds of terms helps make it simpler to add clarity to description at the cost of somewhat wordier sentences... kind of like how sometimes you make a program a little more verbose so that a different programmer coming across the code later can understand it.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
If programming were strictly about efficiently providing instructions to computers, then anthropomorphism would be wasteful and counter-productive. Think about all of the code and processor cycles devoted to displaying data as windows, folders, icons, or just plain aesthetics. Those metaphors are highly wasteful of computer processing power.
But the point is, computers are, above all, a tool for people. So why not make them function in a way that is understandable to people? If anthropomorphism helps programmers understand the interconnections of complex software, then by all means, we should use it! If the metaphors break down, fix the metaphor, or use a different one. It's how we think. It's OK if it's not perfect, as long as it gets the job done.
This has been going on since before object-oriented programming existed. In Unix, for example, processes have "parents", "children", and can be "killed".
I anthropomorphize my computer just to piss it off.
Lets say you're a traveling auto salesman, and you would like to sell your cars to different stores around the state. You could either drive each car, one at a time, to each assigned destination and hitchhike back to your starting point (always with a towel). Or you could come up with an algorithm for taking all the cars, putting them into a truck, and finding the shortest path that visits each auto store, saving gas and giving you the street credibility to comment on the appropriateness of OOP vs procedural languages. Then, after having spent a more fulfilling life than most people by being so efficient, you can watch as people invoke your name, and come up with a poor analogy which doesn't really explain OOP vs procedural languages that shows up on Slashdot.
Humans are bad at abstract logic. Not just bad, but shockingly, horribly bad. It requires many years of teaching to get them to learn how to reason according to logical principles and to avoid logical fallacies. Most people never get there at all.
OOP is a step in the right direction, for some kinds of programming. You don't always need to tell a story about your concept space. Sometimes what you're doing is so simple, and so shortlived, that it doesn't matter. However if you want long term maintainability and something that other people are going to be able to learn as quickly as possible, OOP wins. Consider the following example:
English:
John loves Sally. People like to spend time with others that they love. Does John like spending time with Sally?
If you are human and not deeply mentally impaired, you will quickly answer "yes" to the above question
Symbolic logic:
Derive Q (John likes spending time with Sally)
P (Assertion)
P -> Q (Modus Ponens)
Did you immediately think in your brain the following:
Q (Consequence of premises 1 & 2)
A lot of people who stare at that sequence of symbols will require a few moments to process it. Very few will read it as trivially as they read the English expression, although both expressions communicate the same relationships and information. Why is that? It is because the logical derivation is an abstraction above the English expression (which itself is of course an abstraction of something else). Every level of abstraction adds to how difficult it is for a human to comprehend something. It doesn't mean they can't get it, it means it will take longer (though depending on the person it might mean they can't get it).
Do you want people to be able to read your code in the future? The best chance of them succeeding is to use object oriented programming, and to create a class model that closely resembles what most people intuitively understand as the concept space you are working in.
Humans did not evolve to process information regarding Ps and Qs. They evolved to process information about Johns and Sallys. They are much better at the latter than the former.
Well I fucking disagree with Felicia.
I didn't see any anthropomorphism in the example. It just looked like a comparison of procedural and OO coding styles.
> Anthropomorphism is degenerate no matter the situation.
a) Man is the measure of all things.
Anthropomorphism is something we cannot really ever abandon -- be it regarding our tools and even regarding what goes around us.
I always got upset with people who are Biology Nazis and go like "you cannot say that organism wanted to lose its teeth". Well, this is obvious! And yet (IMHO) it's a perfect valid way to state a fact -- either for youngsters who cannot grasp the way evolution really works and for adults, as a figure of speech.
b) The discourse at the end of The Great Dictator, by Chaplin, would also be useful. If you abstract enough, a good part of morality is lost. You are not machines...
c) OOP was never about anthropomorphism. One model entities, which might be humans or not. The article author didn't like an anthropomorphic example. Fine, do it with bacteria. Analogies now and then break. This has nothing to do with OOP as a method for problem specification and treatment.
d) Sometimes we get fed up with things and the current trend of flat designs is an example. We got tired of anthropomorphic controls. Very nice. And it shall pass, too. And we'll be back to more human-adapted designs, futurely, and will be touted as a novelty. Hah!
e) I've read both articles: the author has a much narrower aim at how one analogy broke; EWD says anthropomorphism fails (with what I agree) in a text written by hand (I had the pleasure to read another some months ago, he even let some text he stroke through remain. It's obvious he's not against anthropomorphism de per se, but he cautions us about the dangers of using it (like in the expression "restless waves").
f) OOP has its place, and in some niches it may not be as useful, so procedural might be better. But then this can be said about the car and the bicycle. Where I disagree with the author is about OOP being syntactic sugar, since OOP happens at an earlier stage -- before syntax takes place. The implementation of OOP might be seen as that, but then again an implementation is not the idea itself.
g) The author is way above my knowledge level; but then, this might be the source of his problems. I'd humbly suggest he backs away of his expertise and try a more conventional big picture view. There's a reason why OOP was invented and it will be debunked by a better knowledge model -- not by a previous one.
As you said, use the best tool for the job. As an example, if you're coding a combobox control, that control has a visual representation, some behaviors (methods), some properties, and some things that can happen in it (events). There are likely to be several comboboxes should should have approximately the same behavior. Combobox is naturally an object.
On the other hand, the small inner loop of lookup service which needs to be fast takes one parameter, a single value, and returns one value. There's no need for any object. This:
return x + 3;
Is much better than:
Number three = new Number;
three.value = 3;
return three.plus(x);
I love simple examples, they're so easy to manipulate to one's desired outcome.
If one takes his example to the next step (the step after his statement that "everything runs on one CPU anyways") and starts thinking about multple cores, multiple CPUs, or distributed systems (like each human being can be thought of), his example just falls flat on its face and is a good argument as to why the entire industry is at a crossroads how to handle the slowing of CPU power density and the implied code complexity that it brings, needed to solve the ever-increasing data/analysis power needed. Solving with parallism can be one way, or Ungar's recent race-retry approach (personally I think this is the wrong way to go).
Human beings ARE sentient, eventually we'll solve the entire AI thing (either with a good ending or a bad ending) and once we do, we, as software architects, developers, programmers, etc. should be ready. NOT following his advice would be a good start.
Sorry dude, but you're barking up the wrong tree.. (IMHO, of course).
Felicia disagrees with you.
This female is a furry.
At the very least she needs a 'tail-ectomy' and she could do with a new hair stylist, her mop reminds me of Farscape's Jool (SFW) but in blue. And those ears!
Most of the males here evolved to appreciate HUMAN females and that's how we likes em', thanks all the same.
..Mullah or Pope, Preacher or Poet, who was it wrote: "Give any one species too much rope and they'll fuck it up"?
The analogy expressed in the article isn't procedural versus OOP - which the author completely misses the point over. The analogy is serial versus parallel computing. In the first case each student is dealt with individually in order, in the second case the principal is a despatcher and each student is an independent process. So the analogy does hold. It has nothing to do with objects or not.
We're on 2015, which means the trend now is to chase down the bronies.
Java is pretty much the only language with forced OOP.
Any sane language is multiparadigm these days.
Btw, in reality procedural and object oriented are just two different views and controls on the exact same datastructures and process-flows.
'Object oriented' just means that you can extend the type system of the language which is completely orthogonal to procedural programming. It doesn't matter if you use only base types in your sub-routines, or add some custom types made with oop. So those approaches aren't even mutually exclusive. Just some common language constructs, which some languages implement and some don't.
There's absolutely nothing stopping you writing procedural code in Java, just put everything in one class and mark all your methods as static. Of course if you're going to start interacting with the class library you'll have to bend to it's way of thinking but that's not a _language_ thing. Of course I don't recommend doing that, but it can be done.
This is why an experienced developer has multiple tools at her disposal - Java is great (IMHO) for a lot of things, but I'll pull out Ruby or Perl for some stuff, C# for others (e.g. when I want a native windows UI), Scala for yet more. There is no one size fits all, and just because one tool doesn't do everything doesn't make it useless.
---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"
You've all seen good and bad 'personal details' websites so it's hardly necessary to continue.
We all know about stupid questions asked by an insensitive drone.
IMHO the difference is between 'demanding' and 'asking nicely for a reason'.
Don't forget C# too. Just try to write a self-contained program in it that doesn't involve at least 1 class :P
...I wonder why anyone would want to read it.
"One model entities"
Entity modeling predates OOP.
An analogy that breaks down if you push it too far?
Ridiculous! You cannot push analogies. They are not tangible things.
OOP doesn't want to be anthropomorphized
To qualify for GNAA membership, it has to be a first post, and you have to do it logged in. Sheesh. Don't they teach kids anything nowadays?
The original analogy involved a principal (a fairly complex process) who instructs a group of students (a collection of complex processes) to go to various classrooms (a fairly expensive / time consuming task). The pseudo-code he has breaks most of these assumptions and results in a simple single threaded task calling move-to-classroom routine that is so trivial that the implementation is not even shown. His straw man analogy is thus not correct.
It could easily be the case where the analogy is correct. e.g.
In this case, implementing this system (especially with a technology such as actors) would very closely parallel the analogy and the anthropomorphism would aid in communicating the design. The straw man argument that the author dredges up is a very simple example not worthy of most tasks a software developer faces in the 21st century.
Any analogy can be incorrect. Don't use them if they're incorrect.
I beg to differ. I'm primarily a C++ programmer (came from C) and have done an aweful lot of the "C with classes" style programming you're describing, and it is a very different thing than object-oriented programming. The language constructs may be the same, but the design philosophy is extremely different.
Today I mix and match as approppriate - there are situations where an OOP-oriented design has decided advantages, just as there are places where a more straightforward procedural problem decomposition makes things much more straightforward, but can still benefit from custom data types tailored to the problem space.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
Object orientation is a tool, unfortunately most programming languages treat it as if was a religion.
Anthropomorphism is always trying to get into trouble and ruin other people's lives.
Wha? Anthropomorphism just wants to be free!
Godel called and wants to know if "isAnthropomorphizable" has been inherited in anyone's classes.
This has to do with Dijkstra's rejection of trying to learn new concepts with analogies to existing concepts we already know. I'd read an essay of his on the same subject some years ago. From the linked Dijkstra essay:
"The above tried to capture the most common way in which we seem to cope with novelty: when faced with something new and unfamiliar we try to relate it to what we are familiar with. In the course of the process we invent the analogies that enable us to do so.
It is clear that the above way of trying to understand does not work too well when we are faced with something so radically new, so without precedent, that all analogies we can come up with are too weak and too shallow to be of great help. A radically new technology can create such circumstances and the wide-spread misunderstanding about programming strongly suggests this has happened with the advent of the automatic computer.
There is another way of approaching novelty but it is practised more more rarily. Apparently it does not come "naturally" since its application seems to require a lot of training. In the other way one does not try to relate something new to one's past experience - aware of the fact that that experience, largely collected by accident could well be inadequate. [...] To ease that process of liberation it might be illuminating to identify the most common metaphors and analogies and to see why they are so misleading.
I think anthropomorphism is the worst of all. [...]
I skip the numerous confusions created by calling programming formalisms "languages", except a few examples. [...]
And now we have the fad of making all sorts of systems and their components "intelligent" or "smart". It often boils down to designing a wooly man-machine interface that makes the machine as unlike a computer as possible: the computer's greatest strength - the efficient embodiment of a formal system - has to be disguised at great cost."
Unnecessary, since the IsBakeable interface provides a default implementation of the toast() method that throws an exception if you attempt to toast something that is not toastable.
Unfortunately for you the entry-level coder actually building out the objects copied the Bagel implementation to make Cake, so now Cake does have a .toast() that does not throw an exception.. and of course there's no unit test to find that because it's stupid to toast a Cake.
The first thing all four thousand clients did when getting the software was try to toast a Cake, and discovered Smoke.detect() worked great (well, for all the living ones anyway which is all that matters since they are the only ones you can bill).
"There is more worth loving than we have strength to love." - Brian Jay Stanley
What gets me is this:
If you don't draw analogies (like anthropomorphism), or abstractions, how the hell do you choose your names in a way that lends itself to understandable code? The author should take his own argument one step further and realize that calling a string of bits a "student" is likewise anthropomorphising the data, and calling another memloc a "Classroom" is applying an anology to what is really going on. Then he could reduce is argument ad-absurdium to requiring that all identifiers be randomly chosenstring to avoid installing unintentional meaning into data structures and procedures/functions.
Someone had to do it.
I always got upset with people...go like "you cannot say that organism wanted to lose its teeth". Well, this is obvious! And yet (IMHO) it's a perfect valid way to state a fact...
It's what Daniel Dennett calls the "intentional stance." I agree with Dijkstra, that anthropomorphizing code is frequently problematic, but the intentional stance can be quite useful in general. Most of the systems we build and encounter in our daily lives are "intentional systems", designed to achieve specific purposes in an external physical reality, and the intentional stance is really parsimonious for these cases.
.: Semper Absurda
If you don't draw analogies (like anthropomorphism), or abstractions, how the hell do you choose your names in a way that lends itself to understandable code?
That's a good point. Our programs are "intentional" (in the sense used in philosophy of mind), because we design them as means to specific ends. They are inherently about those ends, and self-documenting code conventions reflect that.
I think it's possible (and quite natural) to use the "intentional stance" without anthropomorphizing as such, for example when naming a variable "speed," or saying a program "tries" to do something (again, reflected in self-documenting conventions like a "try" construct). Purpose and intentionality are everywhere in the the world, and are not properties of the human mind only.
Dijkstra and Vaillant are probably not very familiar with intentionality (or philosophy of mind in general), or they probably would be making this distinction instead of blanket proscriptions against discussing code in certain ways.
.: Semper Absurda
But you do know that the static main method my call other 'procedural static methods?
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
you mean use anthropomorphism to make computers seem like politicians / journalists / managers ...
It seemed easier for me to organize things into classes for a poker program because anthropomorphizing the methods made sense in that case.
In what way did you impute human characteristics to the poker code? My guess is you didn't truly anthropomorphize, but rather used some form of intentional stance or design stance.
IMHO, Vaillant (not having studied philosophy of mind) is a bit confused about intentionality, which is actually totally inescapable in programming.
.: Semper Absurda
I wouldn't even call Java object oriented, rather class oriented. It forces you to put everything in a class. Most of the time when I see Java code, there's a whole bunch of classes with nothing but static functions in them.
Python is in a sense much more object oriented than Java: everything is an object. Modules are objects, functions are objects, classes are objects.
This sig under construction. Please check back later.
Well, I disagree to fucking with Felicia.
Disagree with me to fucking Felicia well?
Old and busted: anthropormphism.
The new hotness: gynomorphism.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
Nobody buys a 'Toast Decorator'. They buy a 'Toast Decorator Factory'. If you don't pick the right framework, you're never going to be more than an HTML coder.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
There's no such thing as 'OOP-oriented design'. Just some common design (anti-)patterns that people associate with object-oriented language features. Object-orientation is nothing more and nothing less than the capability to extend the type system. Looking for deeper philosophy in it is a waste of time.
Btw, TFA is promoting Functional programming over Procedural/ObjectOriented programming, and does consider OO as a Procedural style.
Well, I agree to fuck Felicia.
>There's absolutely nothing stopping you writing procedural code in Java, just put everything in one class and mark all your methods as static. Of course if you're going to start interacting with the class library you'll have to bend to it's way of thinking but that's not a _language_ thing.
That in general cannot be done and the reason is a language thing. Try something like (I can't even write it without pseudo code in Java, much less do it):
class X {
static auto f(int x) {
int g(int y) {
return x + y;
}
return g;
}
}
That would be perfectly normal procedural code.
There's no such thing as structured programming design - structured programming is nothing more and nothing less than convenient wrappers around "if" and "goto" statements.
Do you see how ridiculous such a claim is? Or perhaps you are too young to remember the wonderful world of "spaghetti code" programming before "goto" was demonized and nicely encapsulated functions became a common language feature.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
Comment removed based on user account deletion
Not all OOP languages have types. For example, Self is generally considered object oriented but does not have a type system. Furthermore, classes are not the same as types (Google type theory if you don't believe me).
OOP is hard to define!
The example cited in TFS breaks down. It claims that underlying the procedural and OO methods of moving students to classroms, the work done is the same. And then it conveniently shows the functions/methods move() and move_student() as "implementation not shown".
But in real life (and OOP), moving a student might differ for each instance. Some students might have to stop by their lockers to drop off some books. Or sneak out into the parking lot to blow a butt between classes. Likewise, in OOP, the move_student() methods might differ between students. If heuristics are applicable, some students might choose a more efficient path, while the dumb ones wander through the senior lounge and get the snot beat out of them.
Have gnu, will travel.
We can work around that tail.
Design patterns themselves transcend language features. That was my only point here. Mixing those two is a mistake. Using a language feature doesn't automatically make you proficient in using design pattern it's associated with. It's merely a syntactic sugar. And many language features serve different design patterns. And those patterns are implemented with different features in different languages.
(As for all the CompSci101 ad hominem one-upmanship of which definition is best to apply to each programming language, methodology, or style, I say: go do your bran muffin time *rueful laugh*
"A shoe!" -- Monty Python, Life of Brian
https://www.youtube.com/watch?... )
Uh, Linux geek since 1999.
Yes, and an extensible type system is a language feature that simplifies object oriented design - but it is neither necessary nor sufficient to the purpose.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
"This female is a furry." BZZT! Wrong answer, but thanks for playing! It's a cartoon/drawing of an anthropomorphic female from a comic/game/fantasy setting. A 'furry' is an actual person that sympathizes with, relates to, or even wishes they were an animal in some form or fashion, often by wearing fursuits and/or engaging in some form of animal behavior, sexual or otherwise. And for the record, we haven't 'evolved' to fuck human females, that's just how it's happened more often than not due to species dominance or relationships or that it was the 'only game in town'. Evolution hasn't stopped human males from fucking anything (like sheep or even other human males) that stands still long enough for him to try.
http://about.me/jimm.pratt
Anthropomorphizing is not this ridiculous caricature. It is a very effective process by which we relate new information to information we inherently have. Would you rather relate new information in a way you and others can readily understand or in a way you and others can't readily understand?
Sure, it's not perfect, but usually you're looking for good enough, not perfect. For example, consider this example from my neighbor, Yellowstone National Park. You are tourist and come across a bull (male) elk. It's a 600 pound member of the deer family with an antler spread around two meters wide. There are correct and incorrect ways to anthropomorphize the behavior of that bull elk. The following is the incorrect way which unfortunate, real world tourists use each year: "That's a pretty elk. I know he wants me to pet him, because I would like being petted if I were a pretty elk too!" Their world gets rocked as a result. Consider the alternate approach: "That's a big elk in the middle of rut season. I bet he'll be pissed if a crazy human tries to touch him. I would if I were running around hyped up on hormones." Look! No headbutt Ma! Obviously, neither approach captures what it means to be elk or those elk sensibilities. There is this certain lack of nuance of the elk point of view. But one approach, which I would go as far as to label an entirely correct approach to understanding in this scenario, keeps you from finding out what pointy antlers backed by 600 pounds of enraged elk can do to a person.
My view is that humanity and our behaviors are sufficiently complex that one can shoehorn any understandable phenomenon into an anthropomorphic basis. The real problem is not the process, but insufficient understanding of the problem needed to come up with a sufficiently correct anthropomorphic model.
The author uses a very simplistic example. In the real world a school has an admin dept to handle placing students in requested classes. Therefore at least one other Admin Class is needed. A Student should remember class assignment unless modified by Admin. This way the Principal can directly assign class if need be or contest an assignment.
The only thing I truly can't stand is when they call the program "he". I can honestly say I've never heard anyone I consider a good programmer do that.
it doesn't like it ;)
putting the 'B' in LGBTQ+
BZZT! Wrong answer, but thanks for playing! It's a cartoon/drawing of an anthropomorphic female from a comic/game/fantasy setting.
I beg your pardon, you are quite correct.
And for the record, we haven't 'evolved' to fuck human females, that's just how it's happened more often than not due to species dominance or relationships or that it was the 'only game in town'. Evolution hasn't stopped human males from fucking anything (like sheep or even other human males) that stands still long enough for him to try.
I didn't say that; appreciating is rather far removed from the act of fucking females.
However, whilst we're on the topic of fucking, males have most certainly evolved physically and psychologically to fuck females*. Are you really saying that they have not? Unless I misunderstand you, this may be difficult to argue given the preponderance of evidence to be found throughout the natural world.
* No offence intended to LGBTt people, I'm just simplifying and generalising in this case
..Mullah or Pope, Preacher or Poet, who was it wrote: "Give any one species too much rope and they'll fuck it up"?
Yeah well, don't push it too far then. Are there a lot of people who are pushing it too far?
You have it backwards, OO is primarily a design methodology, not a language feature. If you look carefully, most of the examples in K&R are actually implementations of good OOD written long before the term was coined. The "OOP features" found in today's languages actually evolved from the use of OOD, not the other way around.
How do I know this? - I'm degree qualified and have been using it professionally for almost 25yrs. Do yourself a favour, admit to yourself you might not understand OO properly and crack open an OOD textbook.
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
You could claim that subroutines are just syntactic sugar built on GOTO, but then again, even 6502 assembler supported three types of flow control -- JMP (unconditional jump); conditional branches (only a small memory offset, so only useful for IF-type constructs) and JSR: Jump to SubRoutine. But your typical C subroutine isn't syntactic sugar for a JSR, as you have more context to stack than just the accumalator, X and Y registers and the program counter.
Sytactic sugar has to refer to features within the same language, and while I'm sure I could get close to reimplementing Python's OO in Python using dictionaries, it's going to be very messy to get method calls and multiple inheritance working. But implementing Python's magic methods in non-OO Python... well, that's a whole other braintwist.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
When Dijkstra suggested that "It [anthropomorphizing] invites the programmer to identify himself with the execution of the program" he was a bit confused about the notion of anthropomorphization. To attribute human behaviors to objects, i.e., to anthropomorphize, is very different from projecting oneself into an object. Papert called this projection, e.g. to program a virtual or physical turtle, body syntonicity. There certainly is evidence that this can be a useful thing to do to write or debug programs.
I fail to see the relevance of the example provided by the recent article for or against OO. The code in both cases is essentially the same. Just because there is no explicit class teacher does not mean that example #1 is not OO. There are really cases in which OO does lead towards certain implementation approaches that are inefficient or overly complex for no good reason. Search for "Antiobjects" to find some examples where OO would suggest to put certain behavior into a certain classes in ways that may result in very complex code. The Antiobject approach, in contrast, can lead to a very simple solution. The two approach are not only different in terms of perspective and where the code really goes but in terms of actual code. An example would be to compare a concurrent search, e.g., multiple ghost tracking down a pac-man. In the traditional OO approach one would be tempted to put the complex, e.g., A*-based "AI" into the ghosts. In the antiobject approach one would put the tracking code into the background, e.g., the tiles and walls of a maze to implement, say, a Collaborative Diffusion approach. The collaborative diffusion approach is not only trivial to implement but also results in sophisticated collaboration patterns that would be much more difficult to match with approaches flavored by traditional OO design.
Design patterns themselves transcend language features. That was my only point here.
Yep, that's why it's called a design "methodology", it ignores the implementation details. OOD is an older design methodology you are apparently completely unaware of even though many languages have gone out of their way adding features to make it easier to implement OO designs. "Functional decomposition" is the oldest methodology commonly used by developers and is also well supported by specific language features. "Design patterns" is the only popular methodology that is not well supported by language features, perhaps that's why you noticed it "transcends language features"?
Agree that mixing two methodologies will end in tears but that doesn't mean you can't use OO language features to implement a design pattern.
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
The concept of Object-Oriented Programming is to encapsulate not only data but also functions, almost like wrapping them up together. Packaging them if you will. This means, if you're given an Object and its API, you know that the given Object has properties A, B, and C, and the functions that come with it are intuitive, straight forward, and compatible with the data. You can call function x and by way of the API know it will do something predictable, intuitive, and hopefully usefl to A.
Think about writing OOP code in C. You basically have a struct, which is the closest thing to an object, with some properties (variables), but you can't package functions in with it, so you end up with functions that need prefixes to allow you to differentiate between the "object functions" and the rest of your functions.
Like, if you have the struct Triangle with sides a,b,c and angles a,b,c, you can't just call triangle.Area() to get it's area, you have to do triangle_area(triangle); since you might also have square_area() and rectangle_area() or even circle_area;
The problem is the same for procedural, functional, and imperative. If you can't wrap your functions and data together, you can't guarantee compatability and you'll encounter far more trouble when you try to update, extend, or maintain code written to operate on said data. Granted, this isn't an issue for a program that only operates on one set or type of data at a time, such as researchers, but even having objects that can calculate a t-test based on its own data makes processing research data as easy as thisObject.t_test();
Learning something new without analogies is probably going to be very slow.
Dijkstra appeared to be a fan of the slow. See his essay "On the cruelty of really teaching computing science".
Article seems to be a load of crap, and the examples given are horseshit. None of that code would pass code review, and the OO example is not remotely OO. Kids.
No offence intended to LGBTt people
I don't see why you should have to say this. If humans had not evolved to be heterosexual, the species would not exist. How could anyone be offended by this truth?
I don't see why you should have to say this. If humans had not evolved to be heterosexual, the species would not exist. How could anyone be offended by this truth?
A fair comment and I'd wager that my friends who fit within the LGBTt umbrella probably wouldn't bat an eyelid.
However, in this enlightened age of political correctness and sensitivity (oh, and punitive moderation) I thought it wise to clarify.
..Mullah or Pope, Preacher or Poet, who was it wrote: "Give any one species too much rope and they'll fuck it up"?
You may like programming in Nim then (http://nim-lang.org), it gets away completely without objects because they are in most cases an artifact of the syntax. In fact, one of the first things you learn in OOP is how to *extend* or *add* methods to existing classes. Check the examples on the website header, no trace of class keywords, yet OOP like anything else.
One of my favorite quotes from the Jargon Files, on this exact subject, as relevant now as when it was written:
"At first glance, to anyone who understands how these programs actually work, this seems like an absurdity. As hackers are among the people who know best how these phenomena work, it seems odd that they would use language that seems to ascribe conciousness to them. The mind-set behind this tendency thus demands examination.
The key to understanding this kind of usage is that it isn't done in a naive way; hackers don't personalize their stuff in the sense of feeling empathy with it, nor do they mystically believe that the things they work on every day are `alive'. To the contrary: hackers who anthropomorphize are expressing not a vitalistic view of program behavior but a mechanistic view of human behavior."
Full text here: http://www.well.com/~lonewolf/...
Am I understanding that correctly that you basically define how an object should respond to data, thereby giving it a human-like response?
Pretty much, although part of the point I wanted to make is that "human-like" is not necessarily as broad as it's made out to be. For example, IMHO the "try" construct is intentional without being anthropomorphic - I think "try" is an accurate moniker for what the program does.
.: Semper Absurda
Comment removed based on user account deletion
That is a very difficult one to explain to someone with no coding experience.
I disagree. The try-catch block just performs an action while listening for special return values indicative of failure. Take establishing a connection, which may succeed or fail. If the failure code (or exception) is found, the program reacts differently than if it is not. I think most people would catch on quickly, especially if with some pseudocode to point to.
How can you ask a computer to "try" something, really?
I think "try" is a lot like "do," with uncertainty. Take a look at the definitions of "try". Def. 1 seems circular, but Defs. 2 - 4 and 7 seem to apply pretty well to the program. Of course, if we use Def. 8 instead, then few of us ever "try."
Ahh, semantics (being the study of meaning, I actually think semantics is pretty important).
.: Semper Absurda