..."bit-rot" doesn't really happen if you don't change anything.
If we don't do anything to our part of software, it doesn't rot. Unfortunately, our part of the software is not the only part of the software. How could we prevent the rotting of other parts effecting our part? What an interesting question, isn't it?
Speak for yourself.
I do. So, could you please tell, what is a software. Is it only the code? The compiled or the source? Or does it include something else? Why?
Remember those "analysis" and "requirements gathering" steps?
Are you suggesting the dumbed-out-boehm-waterfall model? I didn't think so. Even the original Royce's waterfall model had at least two iterations: first to try out (with waterfall model) how to implement the software, then to use waterfall to implement the software.
Design is always trial and error, or at least based on it. I just would like it to be "trial and error by implementing" not "trial and error by stickmen and ellipses." In other words, "design with concrete facts, not with vague drawings." One of my former colleagues had this admirable habit of never to suggest any design proposals without first trying them out.
You said really strong and wise advices ("if you don't understand the problem domain" etc.), and I couldn't agree more. All I'm saying is: implement first to find the way to understand the problem domain. This implementation just has to be thrown away, otherwise it comes to be the product, a badly designed product.
Why reinvent the wheel?
Look around. Are we using just one web-browser? Just one word processor? Just one operating system? Playing just one FPS or racing game? Reinventing the wheel seems to profitable, money talks. I don't like it either.
Change the first part to "for well understood problem domains" and I'll agree.
Yes, I should've said so. Thanks for the correction.
I agree with you, except for: ...just the same way as a bridge designer...
Software is not a bridge. We have hundreds of years of experience in building bridges, but only few decades in building software. We actually do not know how to build a software, not even what a software is. That's why, on new software projects, the only way to find out a decent design is to implement it. How can something that is unknown be designed?
For software already implemented we can use all these fancy design methods to reimplement it, because then we have a slight idea of what we want. But software designers are not like bridge designers. Bridge designers know what they are doing.
Then there is this suggestion that maybe we shouldn't be modelling our art as another branch of engineering...
This can be considered as an advertisement, sorry for that. There are still people who do good, intense and imaginative games, specifically at Llamasoft
*blush* I went home and read my copy of Booch's (well, the beginning), and Budd's "Object-Oriented Programming".
I now remember the existence of object-based systems. Forgive me for saying you were wrong. You were not. Now I even understand (again) why you stated OOP != encapsulation! (Quick learner, aren't I? =)
Also, reading my comment again, I noticed that the part of polymorphism was also, if not utter crap, easily misinterpreted, again because I seem to have a bit different view of polymorphism than the rest of the world - well, I have my state, behaviour and identity:)
Polymorphism as in pure polymorphism is essential for object-orientation. I thought of polymorphism as it was only "ad hoc polymorphism" (overloading), and not pure polymorphism.
But now I'm corrected, thanks to you, igrek. Feel free to point out any other unbelievably crappy opinions in my previous (or this!) comment.
> 1) OOP != encapsulation, by definition.
> Hint: you missed inheritance and
> polymorphism:)
Sorry to say, but you are wrong here. First, the three most important aspects of an object are its state, behaviour and identity. To cut long proofing short, these three result to encapsulation, read for example Grady Booch's "Object-oriented analysis and design" for proof.
Ofcourse, as "strong typing is for weak minds only", is encapsulation for weak minds only when speaking of encapsulation as data "hiding". So private, protected and public attributes, both data and method attributes that is, are just to ease coding. If the attributes are split to different interfaces of an object, it results to capabilities. That's another story, but an interesting one...
If speaking of encapsulation as collection of the data and operations modifying the data, i.e. collection of behaviour and state under an identity, then it is essential to OO, imho.
Polymorfism has nothing to do with OO. Well, OO can use polymorfism, and it really is a nice tool in OO, but no, it is not essential for OO. Polymorfism can also be found on other than object languages, for example in LISP.
Inheritance is purely syntactic sugar.
When speaking of inheritance, we must define are we speaking of type inheritance or behaviour inheritance. Former is the nice thing, but not essential to OO (typeless languages, classless object languages, remember type!=class). Latter is way too easy to implement in other ways (and seems to be the only thing that people preferring C to C++ as an OO programme implementation language can see).
So, like the original author said:
"Things like inheritance, templates, polymorphism, etc, are all just fluff to make coding easier, that has been added on top of the OO ideal."
Slashdot Mirror
..."bit-rot" doesn't really happen if you don't change anything.
If we don't do anything to our part of software, it doesn't rot. Unfortunately, our part of the software is not the only part of the software. How could we prevent the rotting of other parts effecting our part? What an interesting question, isn't it?
Speak for yourself.
I do. So, could you please tell, what is a software. Is it only the code? The compiled or the source? Or does it include something else? Why?
Remember those "analysis" and "requirements gathering" steps?
Are you suggesting the dumbed-out-boehm-waterfall model? I didn't think so. Even the original Royce's waterfall model had at least two iterations: first to try out (with waterfall model) how to implement the software, then to use waterfall to implement the software.
Design is always trial and error, or at least based on it. I just would like it to be "trial and error by implementing" not "trial and error by stickmen and ellipses." In other words, "design with concrete facts, not with vague drawings." One of my former colleagues had this admirable habit of never to suggest any design proposals without first trying them out.
You said really strong and wise advices ("if you don't understand the problem domain" etc.), and I couldn't agree more. All I'm saying is: implement first to find the way to understand the problem domain. This implementation just has to be thrown away, otherwise it comes to be the product, a badly designed product.
Why reinvent the wheel?
Look around. Are we using just one web-browser? Just one word processor? Just one operating system? Playing just one FPS or racing game? Reinventing the wheel seems to profitable, money talks. I don't like it either.
Change the first part to "for well understood problem domains" and I'll agree.
Yes, I should've said so. Thanks for the correction.
And read some Petroski.
Thanks, I will. You might like trying Feyerabend.
I agree with you, except for:
...just the same way as a bridge designer...
Software is not a bridge. We have hundreds of years of experience in building bridges, but only few decades in building software. We actually do not know how to build a software, not even what a software is. That's why, on new software projects, the only way to find out a decent design is to implement it. How can something that is unknown be designed?
For software already implemented we can use all these fancy design methods to reimplement it, because then we have a slight idea of what we want. But software designers are not like bridge designers. Bridge designers know what they are doing.
Then there is this suggestion that maybe we shouldn't be modelling our art as another branch of engineering...
This can be considered as an advertisement, sorry for that. There are still people who do good, intense and imaginative games, specifically at Llamasoft
Good old Yak!
*blush* I went home and read my copy of Booch's (well, the beginning), and Budd's "Object-Oriented Programming".
:)
I now remember the existence of object-based systems. Forgive me for saying you were wrong. You were not. Now I even understand (again) why you stated OOP != encapsulation! (Quick learner, aren't I? =)
Also, reading my comment again, I noticed that the part of polymorphism was also, if not utter crap, easily misinterpreted, again because I seem to have a bit different view of polymorphism than the rest of the world - well, I have my state, behaviour and identity
Polymorphism as in pure polymorphism is essential for object-orientation. I thought of polymorphism as it was only "ad hoc polymorphism" (overloading), and not pure polymorphism.
But now I'm corrected, thanks to you, igrek. Feel free to point out any other unbelievably crappy opinions in my previous (or this!) comment.
I agree with you mostly, but...
:)
> 1) OOP != encapsulation, by definition.
> Hint: you missed inheritance and
> polymorphism
Sorry to say, but you are wrong here. First, the three most important aspects of an object are its state, behaviour and identity. To cut long proofing short, these three result to encapsulation, read for example Grady Booch's "Object-oriented analysis and design" for proof.
Ofcourse, as "strong typing is for weak minds only", is encapsulation for weak minds only when speaking of encapsulation as data "hiding". So private, protected and public attributes, both data and method attributes that is, are just to ease coding. If the attributes are split to different interfaces of an object, it results to capabilities. That's another story, but an interesting one...
If speaking of encapsulation as collection of the data and operations modifying the data, i.e. collection of behaviour and state under an identity, then it is essential to OO, imho.
Polymorfism has nothing to do with OO. Well, OO can use polymorfism, and it really is a nice tool in OO, but no, it is not essential for OO. Polymorfism can also be found on other than object languages, for example in LISP.
Inheritance is purely syntactic sugar.
When speaking of inheritance, we must define are we speaking of type inheritance or behaviour inheritance. Former is the nice thing, but not essential to OO (typeless languages, classless object languages, remember type!=class). Latter is way too easy to implement in other ways (and seems to be the only thing that people preferring C to C++ as an OO programme implementation language can see).
So, like the original author said:
"Things like inheritance, templates, polymorphism, etc, are all just fluff to make coding easier, that has been added on top of the OO ideal."
He couldn't have been more right.
Rabbit is taken by the fine Plan 9 folks. :)
I'd vote for exploded penguin