Slashdot has this same argument every time. In my book I still consider them "programming languages" even if they are not Turing Complete (TC), but there is no "official" definition either way.
My argument for it not mattering much is that non-TC languages can add TC support without really changing what they are used for.
For example, if they put TC in HTML, most would still use HTML for the same things they did before such that giving a completely different classification doesn't make sense. (Look Mom, I just reinvented Adobe ColdFusion!)
Keep in mind that Apple gets more press scrutiny than most other device makers, in large part because it's in the lead and a sought-after brand. Similar mistakes by other vendors are less likely to get the same attention.
The grossest error is that the author blatantly dismisses the ARPA invention of packet switching JUST because it was originally (allegedly) used for NON-computers. (For example, terminals.) Packet switching is THE primary feature of the Internet, regardless of the nature of the traffic (content). The fact that the content of the packets can be anything is part of what makes the Internet the Internet.
The cable design itself, which the article over-emphasizes, is fairly arbitrary and had decent alternatives at the time. Plus, the inventor of Ethernet gained a lot of his knowledge from prior gov't funded projects before working for Xerox.
I suspect it's the anti-government slant of the WSJ that creates such bad articles rather than mere incompetence. Look at the record of who it's owned by.
I did. By "unnatural", I mean it's not a hierarchy that exists in the "real world". Teachers are not a sub-set of student. They are generally independent traits.
Technically you may be able to get away with modeling a "car" as a big roller-skate with passengers instead of feet inside, but it would probably confuse the daylights out of your replacement.
Goto's are a hack to get around poorly designed code.
I don't know what you mean. Goto's (usually) make for poorly designed code.
Classification hierarchies are a variation on set theory...
A more limited variation. Outside of biology, the real world tends to change and vary in a set-oriented way, NOT a tree-oriented way; and thus sets are a better fit.
It creates smaller code files with fewer control structure to parse through to figure out what is going on.
No it doesn't. Perhaps in C-based languages it does because C has a crappy Switch statement, but that's a language flaw, not a paradigm flaw. The total number of dispatching-related "decision blocks" is nearly identical. I've done the counts before.
I've experimented with different ways to manage variations-on-a-theme, and sub-classing is usually not the best way, at least for how my brain processes code. Perhaps you found a way to simplify code testing using hierarchies, but there is more to code management than just testing. I don't want tangled subclasses JUST to simplify testing.
I find that silly and unnatural. I suppose if you always do it that way, then perhaps you get used to it, but the same can be said about Go To's.
This could be done even if Manager was a subclass of Employee.
True, but it doesn't get us anything. One could argue the determination of parking activity should be calculated in one place rather than scattered about different subclasses.
The real world often does not change in a hierarchical way
True, but it sometimes does.
But the non-fits can make a code mess. I've found variations on Set Theory more flexible than classification hierarchies. OOP tends to push one toward hierarchies.
Actually, OOP came about in physical modelling applications via the Simula programming language for companies that modeled things like trains and shipping ports in terms of distributing goods. In that sense, it was a form of anthropomorphism in that each physical object knew how to "handle itself". Whether that idea is always good outside of physical modelling apps is another matter.
But, everybody thinks differently. I've had vast arguments over code versus mind and have concluded that people vary widely. Whether there is a most-common or average thinking pattern, I don't know. Individual differences seem to swamp them if they exist.
"Types" of people is often ill-suited for the real world. Semi-independent attributes are often a better fit. A teacher in one classroom may be a student in another, for example (especially in college).
If managers get privileged parking, for instance, and you hard-wire privileged parking to managers, what happens if due to a decree, instead of bonuses, employees get privileged parking for a month or so? The software may be more flexible if privileged parking is an attribute of "person" rather than part of a "manager" subclass.
Excess use of hierarchical sub-classing can create maintenance headaches. Early OOP educators got "taxonomy happy" in my opinion. The real world often does not change in a hierarchical way (at least not the one I work in).
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.)
I meant Ubuntu LTS distro's directly (as an example), not Php in their distros.
And while I agree that security patches will probably always break some stuff, it's still the lessor evil compared to full upgrades (features & security).
Slashdot Mirror
Tech-support tells the astronauts to "re-boot" the legs, and they put a new set of boots on it.
"We can fix it, but it's gonna cost you an arm and a leg."
Slashdot has this same argument every time. In my book I still consider them "programming languages" even if they are not Turing Complete (TC), but there is no "official" definition either way.
My argument for it not mattering much is that non-TC languages can add TC support without really changing what they are used for.
For example, if they put TC in HTML, most would still use HTML for the same things they did before such that giving a completely different classification doesn't make sense. (Look Mom, I just reinvented Adobe ColdFusion!)
How about everybody just run the same direction for a few minutes to speed Earth back up?
I could tell you the answer, but then I'd have to kill you.
He's probably next to Jimmy Hoffa. Find Jimmy and you find Gengo boy.
Americans are reactionary. Until China embarrasses the USA by taking a tinkle on Neal Armstrong's flag, they will not care.
By now most expect MS to suck.
Keep in mind that Apple gets more press scrutiny than most other device makers, in large part because it's in the lead and a sought-after brand. Similar mistakes by other vendors are less likely to get the same attention.
WSJ is known for its "technical" incompetence. In the following article, they credit mostly Xerox with inventing the Internet.
http://www.wsj.com/articles/SB...
The grossest error is that the author blatantly dismisses the ARPA invention of packet switching JUST because it was originally (allegedly) used for NON-computers. (For example, terminals.) Packet switching is THE primary feature of the Internet, regardless of the nature of the traffic (content). The fact that the content of the packets can be anything is part of what makes the Internet the Internet.
The cable design itself, which the article over-emphasizes, is fairly arbitrary and had decent alternatives at the time. Plus, the inventor of Ethernet gained a lot of his knowledge from prior gov't funded projects before working for Xerox.
I suspect it's the anti-government slant of the WSJ that creates such bad articles rather than mere incompetence. Look at the record of who it's owned by.
Dilbertian Physics, the next frontier.
Maybe in UK you can't.
I did. By "unnatural", I mean it's not a hierarchy that exists in the "real world". Teachers are not a sub-set of student. They are generally independent traits.
Technically you may be able to get away with modeling a "car" as a big roller-skate with passengers instead of feet inside, but it would probably confuse the daylights out of your replacement.
I don't know what you mean. Goto's (usually) make for poorly designed code.
A more limited variation. Outside of biology, the real world tends to change and vary in a set-oriented way, NOT a tree-oriented way; and thus sets are a better fit.
No it doesn't. Perhaps in C-based languages it does because C has a crappy Switch statement, but that's a language flaw, not a paradigm flaw. The total number of dispatching-related "decision blocks" is nearly identical. I've done the counts before.
I've experimented with different ways to manage variations-on-a-theme, and sub-classing is usually not the best way, at least for how my brain processes code. Perhaps you found a way to simplify code testing using hierarchies, but there is more to code management than just testing. I don't want tangled subclasses JUST to simplify testing.
"Siri, answer the phone" -- Hands-free and to loud-speaker. In CA one is not permitted to touch-operate their phone while driving.
More fuel for the Gates quote debate:
http://imranontech.com/2007/02...
It's just like work: a bunch of pions popping in and out of a corporate vacuum.
I like your sense of scrutiny, Sir.
Only if cats occupy those galaxies
Okay, but we'll have to kill whales to do it.
I find that silly and unnatural. I suppose if you always do it that way, then perhaps you get used to it, but the same can be said about Go To's.
True, but it doesn't get us anything. One could argue the determination of parking activity should be calculated in one place rather than scattered about different subclasses.
But the non-fits can make a code mess. I've found variations on Set Theory more flexible than classification hierarchies. OOP tends to push one toward hierarchies.
Actually, OOP came about in physical modelling applications via the Simula programming language for companies that modeled things like trains and shipping ports in terms of distributing goods. In that sense, it was a form of anthropomorphism in that each physical object knew how to "handle itself". Whether that idea is always good outside of physical modelling apps is another matter.
But, everybody thinks differently. I've had vast arguments over code versus mind and have concluded that people vary widely. Whether there is a most-common or average thinking pattern, I don't know. Individual differences seem to swamp them if they exist.
"Types" of people is often ill-suited for the real world. Semi-independent attributes are often a better fit. A teacher in one classroom may be a student in another, for example (especially in college).
If managers get privileged parking, for instance, and you hard-wire privileged parking to managers, what happens if due to a decree, instead of bonuses, employees get privileged parking for a month or so? The software may be more flexible if privileged parking is an attribute of "person" rather than part of a "manager" subclass.
Excess use of hierarchical sub-classing can create maintenance headaches. Early OOP educators got "taxonomy happy" in my opinion. The real world often does not change in a hierarchical way (at least not the one I work in).
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.)
I meant Ubuntu LTS distro's directly (as an example), not Php in their distros.
And while I agree that security patches will probably always break some stuff, it's still the lessor evil compared to full upgrades (features & security).