Anthropomorphism and Object Oriented Programming 303
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.
Strawman (Score:5, Insightful)
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"
Re: (Score:2)
Summarizing (Score:5, Funny)
Re:Summarizing (Score:5, Funny)
Re: (Score:3)
Some of them do. Not all of them fit your template.
Re: (Score:3)
Nah, OOP is fine in the right places, the crystal healing therapy is agile programming.
Re: (Score:3)
Procedural vs OO (Score:5, Funny)
Toaster DRM (Score:5, Funny)
Re:Toaster DRM (Score:5, Funny)
Re:Toaster DRM (Score:5, Funny)
Re:Procedural vs OO (Score:5, Funny)
Hardware analogies are fraught with peril but ...
the object-oriented toaster never burns bread, because the slices/bagels etc set their own cook time. You don't need to upgrade the toaster every time you get a new kind of bakery product to toast.
And best of all, you never need to empty the crumb tray, because of the built-in garbage collection.
Re: (Score:3)
Re:Procedural vs OO (Score:5, Insightful)
By the same token, now you have to implement pie.toast() and cake.toast() and lots of other useless and irrelevant methods, even though you're never ever going to use them, simply because they extend the isBakeable() interface.
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.
The real issue is why the IsBakeable interface has a toast() method in the first place...
Re: (Score:2)
Re: (Score:2)
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.
Man does that bring back some memories..... Borland used to make some truly awesome toasters, what ever happened to them?
Re: (Score:3)
nonsense, procedural code cooks until the toasted flag is true.
Re: (Score:2)
An OpenCL-accelerated toaster toasts the same bagel a million times with slightly different heat profiles and picks the best result.
Ya, Sure. (Score:5, Insightful)
Re: (Score:3)
Re: Ya, Sure. (Score:2, Insightful)
Atheism suffers from this too... There are so many standard phrases for swearing/exclamations that invoke some deity construct that atheists are forced to continue using them as they are too entrenched in our cultures to replace. "Damn you!" Is too perfect to replace with "my anger is so vivid that I want the universe to arrange something very bad to happen to you. Err, except I don't believe the universe is sentient of course, ummm, errrr, I think I'll shut up now"
Re: (Score:2)
Unless you want to take a week to describe a single program, it really helps to anthropomorphise it.
Especially when it's that cute little Clippy!
Re:Ya, Sure. (Score:4, Informative)
Re: Ya, Sure. (Score:2)
"The program doesn't know to check for the start date of a new lease when the old one expires, it just thinks it should activate it regardless."
What's wrong with "The program wasn't designed to check for the start date of a new lease when the old one expires, it just activates it regardless."
More accurate, less words, and no shifting responsibility for the situation to a "naughty program" in a manipulative subconscious effort to evade responsibility for what you built.
Less accurate statement (Score:5, Insightful)
"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.
Re: (Score:3)
Or even simpler (and closer to the truth) "We screwed up. We didn't code a check for the start date."
No passing the blame off to some imaginary "bug".
Re: Less accurate statement (Score:3)
It's either a feature or a bug.
I understand what you are saying, but language that makes the computer sound like an out of control actor makes me sound like I'm not in control of my job and my dog ate my homework, so I make an effort not to use it. I think it makes me look less professional. Language that involves me saying things like "I designed it that way for these justified reasons, but we can discuss changing it", or "I'm not sure why it's responding this way, but it's my screw up and these are the
Re: Less accurate statement (Score:4, Interesting)
language that makes the computer sound like an out of control actor... describes most accurately what is really going on. You sent the slinky down the stairs but it veered sideways and hit a wall.
A program is basically a state machine, a very complex one - we start it and watch what happens, but with a complex enough state machine it is basically indistinguishable from watching a video feed of a person robbing a convenience store. You can describe later on what went wrong quite well, but at the time the result is unexpected.
To be the description of something as a "bug" is leaning more towards papering over flaws; just admit we build systems and almost never have a 100% understanding of what they will do in operation. That is far more truthful than saying there is *A* bug rather than the program is a series of statements that may do what we intend, but may not.
Re: Less accurate statement (Score:2)
No, its a system I built to fix a problem, and if it's not working precisely like it does in my minds eye, then it's wrong because I made a mistake, and I'm ok admitting that.
Re: (Score:2)
No, its a system I built to fix a problem, and if it's not working precisely like it does in my minds eye, then it's wrong because I made a mistake, and I'm ok admitting that.
"The program has a bug" indicates the program is flawed, not you.
I'm more than OK admitting I made a mistake, I prefer it.
Re: (Score:2)
You can shorten something so far for clarity, but if you go to far you end up with less clarity.
I see what you did there!!
... I only wish it had been intentional.
how sometimes you make a program a little more verbose so that a different programmer coming across the code later can understand it.
Oh, like comments? You can write insanely complicated code and as long as it produces the results you had intended, it's correct. But it helps the programmer behind you if you then also write "War and Peace" describing how it works. "It's Magic" is too short.
Re: (Score:2)
The last time I anthropomorphized a program it got quite angry at me.
Mrs Compiler wouldn't let me sleep in C: for a week, and even then she wouldn't let me declare unsigned variable types for the rest of the month!
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
Neither of those means quite the same thing as "the program knows your name." The first could be a reference to attribution, the second could be a reference to the program's name.
Re: (Score:2)
the second could be a reference to the program's name.
You mean "the program has your name"? There is no way that could be a reference to the program's name.
Re: (Score:2)
This program is named "phantomfive". The program has your name.
Re: (Score:2)
I programmed a litte executable and called it phantomfive.
The program has your name.
Re: (Score:2)
"The program stores your name." Simple and precise.
I agree thought, FTA is dumb. It is accurate to say that a program tries to do something when it makes some call that may fail, or when it uses a try...catch to attempt something that may fail. "Want" may be a bit of a stretch, but it's a shorthand way of describing behaviour like needing a file to be in a certain location or trying a particular operation first before taking some alternate action.
Re: (Score:2)
He doesn't like assignments [loup-vaillant.fr] either. As he says, the variable "x itself doesn't change. Ever. The value it holds is just replaced by another." So he would probably want you to say "the program contains a variable whose value stores your name"
Every analogy fails. (Score:2)
My code (Score:2)
Re: (Score:3)
Encapsulation (Score:5, Insightful)
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.
Re: (Score:3)
It sounds like you might be somebody who learned to program someplace other than a CS degree, or who got a CS degree and forgot some academic stuff that you haven't used in your day-to-day work.
You've run afoul of the "functional" doesn't mean "uses function calls a lot" problem and some chest-pounders here are slamming you for that. As an EE who only had a few undergrad CS courses, I've had similar problems. Somewhere out there is a USENET thread in which I'm assuming that "side effects" are "bad side ef
Re: (Score:2)
Re: (Score:2)
Most OO language really fall under that category, too.
That's because most OO languages are also procedural programming languages (for historical reasons). OO is principally about how to organise data and the operations on it, which is orthogonal to whether the operations are sequences of commands or composite functions to be applied.
Re: (Score:3)
Nor does encapsulation mean what he thinks it mans. The idea that you can't do encapsulation unless you have OOP is completely flawed.
Re:Encapsulation (Score:4, Insightful)
What the oop languages did, was to add explicit language support for all the features and idioms which software developers did anyway.
This make development and maintenance much more easy.
Crap article (Score:2)
Agree (Score:2)
Don't anthropomorphize your programs... (Score:5, Funny)
...they hate that.
Missing the point (Score:5, Insightful)
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.
Re:Missing the point (Score:5, Insightful)
OO isn't about anthropomorphism, it's about isolation and providing a clear API.
Believe it or not, isolation and 'providing a clear API' existed before OOP, so you can't say that's it. In general, object oriented programming means that the functions go with the data.
Re: (Score:2)
Far too many programmers these days seems to believe that object orientation is equivalent to the limited form available in languages like Java and C++. They would be helped by learning a language that has multiple dispatch [wikipedia.org] before commenting on that object orientation is.
Re: (Score:3)
Re: (Score:3)
There's a big difference between allowing something and requiring it. I think OO was the natural evolution of concepts like interfaces and namespacing, but what sets it apart is that it insists (so far as it can) the developer encapsulate information, while procedural languages at best suggest it.
Of course it's possible to write clear code in any paradigm, and some of the most beautiful code I've ever seen has been purely procedural, but that is unfortunately the exception. Most code I read is pretty poor,
Re: (Score:2)
I think OO was the natural evolution of concepts like interfaces and namespacing, but what sets it apart is that it insists (so far as it can) the developer encapsulate information,
No, that's not what sets it apart. See above for the meaning of OOP: it means that the objects and functions are bundled together.
Re: (Score:2)
OO isn't about anthropomorphism
Originally, it was actually about cellulomorphism. Programs were supposed to look like systems of communicating biological units, i.e. cells.
Re: (Score:2)
it's about isolation and providing a clear API.
Which did not exist before the invention of OOP... oh, wait...
I don't want them implementing fifty different versions of move_student
If only someone had thought of a way to define shared functions. He could call it a collection, or an archive, or a library, no that's crazy...
but it's still a useful way of keeping a complex program from getting out of control.
Being organized and professional is a useful way of keeping a complex program under control. With the right approach, it almost doesn't matter which language or paradigm you use. And with the wrong approach - ditto.
another article by the same guy (Score:2)
Re: (Score:2)
Re: (Score:2)
I think he understands it very well if he's familiar with how Kay defined it.
Do you know how Alan Kay defined it? [slashdot.org] (hint: he didn't give a clear definition)
Re: (Score:2)
Analogy (Score:2)
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.
Calling poor code organization OOP is flawed (Score:4, Interesting)
Re:Calling poor code organization OOP is flawed (Score:5, Insightful)
Re: (Score:2)
Linus. :)
Object Oriented sex (Score:2)
self.fuck
The limits of Dijkstra (Score:4, Insightful)
stupid (Score:5, Insightful)
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.
What about AI? (Score:2)
The insensitive clod who wrote this is clearly not working in AI.
This is why I like Python so I can use OOP or not (Score:5, Interesting)
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.
Re: (Score:2)
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
Re: (Score:2)
Balance (Score:4, Insightful)
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.)
Anthropomorphism very useful, when used correctly (Score:3)
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.
Do anthromorphise! (Score:4, Insightful)
Don’t anthropomorphize computers, they hate that [dwheeler.com] 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.
Stupidly bad example. (Score:2)
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.
Re: (Score:2)
A teacher in one classroom may be a student in another, for example (especially in college).
Then make Teacher a subclass of student. When the class list, no pun intended, is made the grad student who is taking the course would be instantiated as a Student rather than a Teacher. Problem solved. This would also allow a Principal to take a course. This shows another aspect of OO in that a Person can do completely different things depending on how they are instantiated.
you hard-wire privileged parking to managers,
Hard wiring anything make things less flexible.
The software may be more flexible if privileged parking is an attribute of "person" rather than part of a "manager" subclass.
"Parking" is an attribute of Person. No mater what class there needs to be a method to
Why not use it, if it works? (Score:2)
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 pro
Longstanding Precedent (Score:5, Funny)
Car Analogy (Score:4, Funny)
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.
Spoken like someone who forgets how humans work (Score:3)
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.
Re: (Score:3)
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
It's not very well written.
although both expressions communicate the same relationships and information.
I don't think they actually do. You don't define what P means, and actually you have two assertions in your English sentence, but only one apparently in your symbolic logic.
What? (Score:5, Funny)
An analogy that breaks down if you push it too far?
Ridiculous! You cannot push analogies. They are not tangible things.
Anthropomorphism / analogies can be useful (Score:2)
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.
Bears repeating... (Score:2)
Object orientation is a tool, unfortunately most programming languages treat it as if was a religion.
not seeing the problem (Score:3)
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 [wikipedia.org]. 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 [wikipedia.org]. 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.
Re: (Score:3)
Anthropomorphism is degenerate no matter the situation.
True. Anthropomorphism is always trying to get into trouble and ruin other people's lives.
Re: (Score:2)
Anthropomorphism is always trying to get into trouble and ruin other people's lives.
Wha? Anthropomorphism just wants to be free!
Re: (Score:3, Insightful)
> 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
Re: (Score:3, Interesting)
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 [wikipedia.org]." 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.
Re: (Score:2, Funny)
Re: (Score:3, Funny)
OOP doesn't want to be anthropomorphized
Yep. OOP for gui controls, procedures small & (Score:2)
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 ne
Re: (Score:3)
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.
Re: (Score:2)
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 m
Re:Programming languages are not really "language" (Score:5, Interesting)
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.
Re: (Score:2)