A lot of people believe that it is well-defined. The problem, of course, is that none of them agree with one another! Let's take a look at your definition.
You have objects, either class based or prototype based, that hold data and the code that works on that data as methods or messages.
You start off by defining objects, though your definition is unusually restrictive. You exclude objects that aren't instances of of class or which have no prototype, or similar structures built in languages which don't feature classes or prototypes. This might have been unintentional on your part. You also exclude objects with only methods and objects which have no methods.
But we're not talking about objects, we're talking about Object-oriented programming. Moving on...
Such a system should support dynamic dispatched messages/methods and one or more forms of inheritance.
"Such a system" indicates that you believe that OOP classifies languages or systems within languages. You'll find that many people disagree with that, and will insist that OOP is an approach to programming not an approach to language design. There are plenty of people who believe they're doing object oriented programming in C.
To my point: OOP is so poorly defined, people can't even agree on what the term is intended to classify! Never mind the details, does it refer to programming languages or to programs? I've seen arguments for more than the two obvious responses to that question.
Now we have dynamic dispatch and inheritance. Inheritance is an easy one, as there is no general agreement here. Some go as far as to say that inheritance should never be used. There are also OO languages that do not support inheritance. Go is a nice example as it's fairly new and reasonably well-known.
I'm not exactly sure why you brought up dynamic dispatch. I don't know that I've seen anyone list it as an essential feature. I've seen people argue for and against polymorphism as an essential feature, though you don't necessarily need dynamic dispatch to achieve that either. (In Rust, for example, dynamic dispatch is the exception, most polymorphism is handled by static dispatch.) I agree that it's useful for implementing common types of object systems, I'm just not sure how it fits in to your definition of OOP.
Likely you just made a bad example: but examples like that simply instantly trigger the "you have not understood OO" reaction.
That's fair. My entire point is that no one understands OOP as the concept is too poorly defined. A lot of people think they understand it, naturally, though you'll find little to no agreement between them.
As for defenders and detractors: If you're a believer, you can guard against any criticism by simply saying that this or that "isn't really oop" or "they're doing it wrong". If you're a critic, there's nothing you can offer that can't immediately be disregarded. All they can hope to do is tear-down one fad or trend after another, hoping that they won't return with the next generation of OO believers.
Now with Scala and Groovy having Mixins and Java having interfaces with default implementations the question about MI is finally settled: developers want "some kind of MI".
That's a fine example. Multiple Inheritance was once thought to be essential. Later, as Java gained popularity, it was regarded as a terrible evil. Now, it's making a comeback. At each step, a lot of developers thought the question was settled. See, what is and is not popularly considered OOP changes from moment to moment.
What "mess" are you talking about?
I can't offer any answer that can't immediately be deflected with "That's not really OO" or "That's because they/you don't understand OO". It's too poorly defined a concept. Can you offer a criticism of OOP that can't be deflected in such a way? Can you even find some aspect of OOP that has remained relatively consistent over the past 20 years? Of course not. That's the point.
Sorry for the extra reply, but this is my earlier point entirely. You both think the other "doesn't understand OOP" or is "doing it wrong".
Tablizer has quite a reputation outside of Slashdot for his thoughtful criticisms of OOP. It's difficult to claim that he doesn't understand it, as far as anyone is capable of understanding such a poorly defined concept.
If you hate it, you have not grasped it, plain and simple.
Yeah, here's the problem. You and everyone else already things they understand OOP and that everyone else just has it wrong. The believers will insist that any OOP failure is a failure to truly understand OOP.
The truth, of course, is that no one understands OOP because no one can agree on what constitutes OOP. The Smalltalk folks will complain about how Java and C++ got it all wrong and ruined a good thing. The Java gurus will say that they've got the one true OO language. The Self guys will say that everyone else got it wrong from the start and that classes are unnecessary and add needless complexity. Converts still using C will argue that it's not the language, but how you use it that makes something OO.
You use a simple example to sell us on OOP. Others claim that simple examples are what lead to the masses misunderstanding the true power of OOP and that you don't really see the benefits until you're working on a very large application.
The design patterns zealots will tell you that it's the first step toward true software engineering. The rest will counter that design patterns are just complicated ways to work around the flaws in C++ and Java or that patterns are just missing language features. Others will claim that they can be helpful, but that their overuse has caused nothing but harm.
Favor inheritance or composition over the other? Always use accessor methods or are they unnecessary redundancy/overhead sometimes? Was multiple inheritance a mistake, and Java got it right with single inheritance? Is inheritance a mistake entirely as it can break encapsulation, or is that an unfounded criticism?
If you can not work with OOP and/functional concepts, your mind is stuck in simple thinking, you only get around that by actually using the stuff you hate.
A lot of people hate OOP because they've used it for decades, seen the OOD fads come and go, best practices turn in to dangerous pitfalls, and other ridiculous industry trends. Now, rather than selling us on the solution that will allow us to finally reap the benefits we were promised by OOP salesman, they're selling us solutions to help us clean up the mess OOP left on the rug.
Just one more example: You've not see spaghetti until you've seen a dependency diagram on any moderately large OO project. Enter dependency injection, the solution to the problem caused by various OO fads. If you're sold on DI, or one specific framework, you'll say that it's not only necessary, but we should have been doing this all along. If you're sold on OOP and skeptical of DI, you say that DI is only necessary for those that don't understand OOP.
I can't say that I blame the anti-OOP crew. I just might be one myself. I say "might" as it really depends on what variant of OOP you've got in mind. Not that that's easy, as I don't think any one developer has a single coherent vision in mind. I suspect that if I asked 10 developers, I'd get 12+ answers.
Exceptions can be expensive. Far more expensive than other approaches.
There are other problems and criticisms that apply to exceptions, but that's the easiest to understand. As for elegance, you'll find exceptions in Java are very often criticized for cluttering code. You'll find countless criticisms online with a bit of searching.
Like most things, there isn't a clear "best way". Exceptions are fine sometimes, a horrible nightmare other times. Sometimes, a goto is a really good thing.
Any idiot can build a cabinet. The second will bet better than the first, and so on.
Any idiot can paint a house. Again, you get better as you go along.
Any idiot can cook a steak. The first few might be a bit rough, but it won't be long before their preparation is near expert.
Any idiot can code, this is true. Programming is ridiculously simple. Children can, and often do, teach themselves. You probably taught yourself when you were a preteen, like millions of other kids. If you kept at it, you got better. Like all skills, you improve with practice.
Now, ask yourself, do you really want any asshole to code for you?
Well, I wouldn't hire you, for reasons completely unrelated to your skill as a developer.
Ummm... Nowhere in your link will you find anyone "defining ethernet as broadband".
Obviously at 100 Mbps, that includes ethernet.
LOL, Wut? You may want to do a bit of reading. What you've written is completely incoherent.
I'm still waiting on this: What "scientific truth" are they "redefining", exactly? Or have you finally figured out that that particular claim was absurd nonsense?
So it's the word "scientific" that's confused you...
A few other points: The term "broadband", in this context, means something other than what you want it to mean. If you have a complaint about how language works, you'll need to get over it. No one is "Defining ethernet as broadband". You came up with that one all on your own.
Again: What "scientific truth" are they "redefining", exactly?
For you kids out there, consider this insane, but completely possible, project: Write a JavaScript compiler in JavaScript, implementing a few API's you'll want for some low-level stuff next. Write an OS in JavaScript, compile it with your compiler. Implement JavaScript in JavaScript, compile it with your JavaScript compiler. Compile your JavaScript compiler, on the OS you wrote in JavaScript, by running your JavaScript compiler in your JavaScript implementation. Now you can compile your OS, from your OS, using a compiler you compiled on your OS. Everything from top to bottom being written in Javascript. Bootstrappy!
Yes, it's a terrible idea. JavaScript is obviously wasn't designed for those sorts of tasks. The point, of course, is that it's possible to do such a thing. I should probably point out that you could do the same thing in just about every other language you dislike. This is CS 101 stuff, kids.
So, if that's how you discriminate between "programming languages" and "scripting languages" you'll find that very few (likely none) of the languages you currently believe to be "scripting languages" qualify as such under your own criteria.
Capacitive touch (the metal ring around the iPhone's home button) only works if you are alive [...] Capacitive touch detects micro-electric currents that flow through your body
No.
The very first line from your own link:
In electrical engineering, capacitive sensing (sometimes capacitance) is a technology, based on capacitive coupling, that can detect and measure anything that is conductive or has a dielectric different from air.
Slashdot Mirror
My experience is dramatically different. I tried this out myself as well, and found it quite painful.
I recommend that you have others try as well. It's entirely possible that your experience is uncommon.
Give it a try. If possible, have a few other people try as well.
Have you run across entity component systems? There seems to be a good bit of similarity.
Actually I believe OOP is perfectly well defined:
A lot of people believe that it is well-defined. The problem, of course, is that none of them agree with one another! Let's take a look at your definition.
You have objects, either class based or prototype based, that hold data and the code that works on that data as methods or messages.
You start off by defining objects, though your definition is unusually restrictive. You exclude objects that aren't instances of of class or which have no prototype, or similar structures built in languages which don't feature classes or prototypes. This might have been unintentional on your part. You also exclude objects with only methods and objects which have no methods.
But we're not talking about objects, we're talking about Object-oriented programming. Moving on...
Such a system should support dynamic dispatched messages/methods and one or more forms of inheritance.
"Such a system" indicates that you believe that OOP classifies languages or systems within languages. You'll find that many people disagree with that, and will insist that OOP is an approach to programming not an approach to language design. There are plenty of people who believe they're doing object oriented programming in C.
To my point: OOP is so poorly defined, people can't even agree on what the term is intended to classify! Never mind the details, does it refer to programming languages or to programs? I've seen arguments for more than the two obvious responses to that question.
Now we have dynamic dispatch and inheritance. Inheritance is an easy one, as there is no general agreement here. Some go as far as to say that inheritance should never be used. There are also OO languages that do not support inheritance. Go is a nice example as it's fairly new and reasonably well-known.
I'm not exactly sure why you brought up dynamic dispatch. I don't know that I've seen anyone list it as an essential feature. I've seen people argue for and against polymorphism as an essential feature, though you don't necessarily need dynamic dispatch to achieve that either. (In Rust, for example, dynamic dispatch is the exception, most polymorphism is handled by static dispatch.) I agree that it's useful for implementing common types of object systems, I'm just not sure how it fits in to your definition of OOP.
Likely you just made a bad example: but examples like that simply instantly trigger the "you have not understood OO" reaction.
That's fair. My entire point is that no one understands OOP as the concept is too poorly defined. A lot of people think they understand it, naturally, though you'll find little to no agreement between them.
As for defenders and detractors: If you're a believer, you can guard against any criticism by simply saying that this or that "isn't really oop" or "they're doing it wrong". If you're a critic, there's nothing you can offer that can't immediately be disregarded. All they can hope to do is tear-down one fad or trend after another, hoping that they won't return with the next generation of OO believers.
Now with Scala and Groovy having Mixins and Java having interfaces with default implementations the question about MI is finally settled: developers want "some kind of MI".
That's a fine example. Multiple Inheritance was once thought to be essential. Later, as Java gained popularity, it was regarded as a terrible evil. Now, it's making a comeback. At each step, a lot of developers thought the question was settled. See, what is and is not popularly considered OOP changes from moment to moment.
What "mess" are you talking about?
I can't offer any answer that can't immediately be deflected with "That's not really OO" or "That's because they/you don't understand OO". It's too poorly defined a concept. Can you offer a criticism of OOP that can't be deflected in such a way? Can you even find some aspect of OOP that has remained relatively consistent over the past 20 years? Of course not. That's the point.
Sorry for the extra reply, but this is my earlier point entirely. You both think the other "doesn't understand OOP" or is "doing it wrong".
Tablizer has quite a reputation outside of Slashdot for his thoughtful criticisms of OOP. It's difficult to claim that he doesn't understand it, as far as anyone is capable of understanding such a poorly defined concept.
If you hate it, you have not grasped it, plain and simple.
Yeah, here's the problem. You and everyone else already things they understand OOP and that everyone else just has it wrong. The believers will insist that any OOP failure is a failure to truly understand OOP.
The truth, of course, is that no one understands OOP because no one can agree on what constitutes OOP. The Smalltalk folks will complain about how Java and C++ got it all wrong and ruined a good thing. The Java gurus will say that they've got the one true OO language. The Self guys will say that everyone else got it wrong from the start and that classes are unnecessary and add needless complexity. Converts still using C will argue that it's not the language, but how you use it that makes something OO.
You use a simple example to sell us on OOP. Others claim that simple examples are what lead to the masses misunderstanding the true power of OOP and that you don't really see the benefits until you're working on a very large application.
The design patterns zealots will tell you that it's the first step toward true software engineering. The rest will counter that design patterns are just complicated ways to work around the flaws in C++ and Java or that patterns are just missing language features. Others will claim that they can be helpful, but that their overuse has caused nothing but harm.
Favor inheritance or composition over the other? Always use accessor methods or are they unnecessary redundancy/overhead sometimes? Was multiple inheritance a mistake, and Java got it right with single inheritance? Is inheritance a mistake entirely as it can break encapsulation, or is that an unfounded criticism?
If you can not work with OOP and/functional concepts, your mind is stuck in simple thinking, you only get around that by actually using the stuff you hate.
A lot of people hate OOP because they've used it for decades, seen the OOD fads come and go, best practices turn in to dangerous pitfalls, and other ridiculous industry trends. Now, rather than selling us on the solution that will allow us to finally reap the benefits we were promised by OOP salesman, they're selling us solutions to help us clean up the mess OOP left on the rug.
Just one more example: You've not see spaghetti until you've seen a dependency diagram on any moderately large OO project. Enter dependency injection, the solution to the problem caused by various OO fads. If you're sold on DI, or one specific framework, you'll say that it's not only necessary, but we should have been doing this all along. If you're sold on OOP and skeptical of DI, you say that DI is only necessary for those that don't understand OOP.
I can't say that I blame the anti-OOP crew. I just might be one myself. I say "might" as it really depends on what variant of OOP you've got in mind. Not that that's easy, as I don't think any one developer has a single coherent vision in mind. I suspect that if I asked 10 developers, I'd get 12+ answers.
for ( int i = 0; i < y and !done; ++i)
for( int j = 0; j < x ; ++j)
if( bar(i,j) ){
done = true;
break;
}
It's not that hard. To produce a < just type <
I don't know. I've seen more than my share of working applications that were composed entirely out of bad programming ideas...
Exceptions can be expensive. Far more expensive than other approaches.
There are other problems and criticisms that apply to exceptions, but that's the easiest to understand. As for elegance, you'll find exceptions in Java are very often criticized for cluttering code. You'll find countless criticisms online with a bit of searching.
Like most things, there isn't a clear "best way". Exceptions are fine sometimes, a horrible nightmare other times. Sometimes, a goto is a really good thing.
Like all skills, you get better with practice.
Any idiot can build a cabinet. The second will bet better than the first, and so on.
Any idiot can paint a house. Again, you get better as you go along.
Any idiot can cook a steak. The first few might be a bit rough, but it won't be long before their preparation is near expert.
Any idiot can code, this is true. Programming is ridiculously simple. Children can, and often do, teach themselves. You probably taught yourself when you were a preteen, like millions of other kids. If you kept at it, you got better. Like all skills, you improve with practice.
Now, ask yourself, do you really want any asshole to code for you?
Well, I wouldn't hire you, for reasons completely unrelated to your skill as a developer.
Ummm... Nowhere in your link will you find anyone "defining ethernet as broadband".
Obviously at 100 Mbps, that includes ethernet.
LOL, Wut? You may want to do a bit of reading. What you've written is completely incoherent.
I'm still waiting on this: What "scientific truth" are they "redefining", exactly? Or have you finally figured out that that particular claim was absurd nonsense?
So it's the word "scientific" that's confused you...
A few other points: The term "broadband", in this context, means something other than what you want it to mean. If you have a complaint about how language works, you'll need to get over it. No one is "Defining ethernet as broadband". You came up with that one all on your own.
Again: What "scientific truth" are they "redefining", exactly?
broadband was redefined last year to require 25Mbps downloads.
Which is itself an example of government redefining scientific truth
Umm... What "scientific truth" would that be, exactly?
I think you're deeply confused.
Keep out ghosts? Foolishness.
A cage serves two purposes; only one of which is typically intended. It will keep ghosts out, surely, but it will also trap them in...
I figured it out. Languages he likes are programming languages. Languages he doesn't like are scripting languages.
Yes, obviously.
For you kids out there, consider this insane, but completely possible, project: Write a JavaScript compiler in JavaScript, implementing a few API's you'll want for some low-level stuff next. Write an OS in JavaScript, compile it with your compiler. Implement JavaScript in JavaScript, compile it with your JavaScript compiler. Compile your JavaScript compiler, on the OS you wrote in JavaScript, by running your JavaScript compiler in your JavaScript implementation. Now you can compile your OS, from your OS, using a compiler you compiled on your OS. Everything from top to bottom being written in Javascript. Bootstrappy!
Yes, it's a terrible idea. JavaScript is obviously wasn't designed for those sorts of tasks. The point, of course, is that it's possible to do such a thing. I should probably point out that you could do the same thing in just about every other language you dislike. This is CS 101 stuff, kids.
So, if that's how you discriminate between "programming languages" and "scripting languages" you'll find that very few (likely none) of the languages you currently believe to be "scripting languages" qualify as such under your own criteria.
Why do you think that's impossible?
What silly criteria did you use to make those distinctions?
There's no real, objective, distinction. Neither is there a need to make such a distinction. It's an impossible task that serves no purpose.
You're wasting an awful lot of outrage on completely meaningless nonsense. Let it go. You'll feel better.
You also have a different dielectric than the air whilst dead.
Capacitive touch (the metal ring around the iPhone's home button) only works if you are alive [...] Capacitive touch detects micro-electric currents that flow through your body
No.
The very first line from your own link:
In electrical engineering, capacitive sensing (sometimes capacitance) is a technology, based on capacitive coupling, that can detect and measure anything that is conductive or has a dielectric different from air.
If he's happy with them, what difference does it make?
I doubt it. Some people just hate everything.
Women are more likely to get worthless degrees.
Only if you're one of those oddballs that think "college" should be synonymous with "trade school".