> -
https://codewords.hackerschool.com/issues/one/why-are-object....
> In all seriousness, this is one of the best articles I've ever read. I couldn't agree more with the author.
I'm not sure if you are being serious (you say you are, so Po's law), but this is a bad article written by someone who I guess must be a novice who thinks he knows something now but will look back on this 5 years later and cringe; examples...
> From the perspective of debugging, an instance variable is not in the scope of any of the methods on the stack.
He might as well be talking about heap allocated structs in C.
> This threatens to increase the search space, and suggests that avoiding instance variables in favor of passing arguments might be a better strategy where possible.
State should be stack allocated, except when it really is state (even if hidden in a monad).
> if you make the mistake of defining public “setter” methods, then the instance variables with setter methods become effectively global variables: if the value of the instance variable is incorrect at some point, that incorrect value might have been set anywhere in your code.
I'm trying really hard now to not be sarcastic.
> So, to avoid making your object-oriented code harder to debug than imperative code, you need to not use any public instance variables, and also avoid defining setter methods.
How does this guy define imperative code? Definitely not C where all members of a (heap allocated) struct are public?
He then describes the fragile base class problem without really understanding what that means.
> The technical term for a programming paradigm which uses neither inheritance nor instance variables is imperative (or functional) programming.
Ok, I can't stop myself from laughing at this point; I can't really go any further.
You know, we all go through this as programmers. We start knowing nothing, then we get a couple of years of experience and think we know everything....then we get 10 years of experience and realize we still don't know very much and what we thought we knew were just delusions of grandeur.
I won't say much about the rest of the publication. The nice thing about the internet is that anyone can produce something and make it available to read.
> In all seriousness, this is one of the best articles I've ever read. I couldn't agree more with the author.
I'm not sure if you are being serious (you say you are, so Po's law), but this is a bad article written by someone who I guess must be a novice who thinks he knows something now but will look back on this 5 years later and cringe; examples...
> From the perspective of debugging, an instance variable is not in the scope of any of the methods on the stack.
He might as well be talking about heap allocated structs in C.
> This threatens to increase the search space, and suggests that avoiding instance variables in favor of passing arguments might be a better strategy where possible.
State should be stack allocated, except when it really is state (even if hidden in a monad).
> if you make the mistake of defining public “setter” methods, then the instance variables with setter methods become effectively global variables: if the value of the instance variable is incorrect at some point, that incorrect value might have been set anywhere in your code.
I'm trying really hard now to not be sarcastic.
> So, to avoid making your object-oriented code harder to debug than imperative code, you need to not use any public instance variables, and also avoid defining setter methods.
How does this guy define imperative code? Definitely not C where all members of a (heap allocated) struct are public?
He then describes the fragile base class problem without really understanding what that means.
> The technical term for a programming paradigm which uses neither inheritance nor instance variables is imperative (or functional) programming.
Ok, I can't stop myself from laughing at this point; I can't really go any further.
You know, we all go through this as programmers. We start knowing nothing, then we get a couple of years of experience and think we know everything....then we get 10 years of experience and realize we still don't know very much and what we thought we knew were just delusions of grandeur.
I won't say much about the rest of the publication. The nice thing about the internet is that anyone can produce something and make it available to read.