ok what are the rules
-
PaulC1972 wrote:
The Grand Negus wrote: Abandon the "object oriented" way of thinking and write the thing, as much as possible (with the language you've chosen), as traditional procedural code. Nope, I don't think so.
Just trying to save these folks a bit of time and trouble. The suggestion saves time because (1) there won't be endless arguments about how to squeeze the problem into an object hierarchy, and (2) there won't be endless debates about how to "simulate" design requirements that C# doesn't support (like multiple inheritance). The suggestion saves trouble because the resulting code will be more orthogonal and thus easier to understand, maintain, and especially extend.
The Grand Negus wrote:
resulting code will be more orthogonal and thus easier to understand, maintain, and especially extend.
But code reuse isn't as good as in object oriented programming. Get with the times, traditional procedural programming is old school and part of the past. I haven't done procedural coding in about 15 years :->
I'd like to help but I don't feel like Googling it for you.
-
PaulC1972 wrote:
The Grand Negus wrote: Abandon the "object oriented" way of thinking and write the thing, as much as possible (with the language you've chosen), as traditional procedural code. Nope, I don't think so.
Just trying to save these folks a bit of time and trouble. The suggestion saves time because (1) there won't be endless arguments about how to squeeze the problem into an object hierarchy, and (2) there won't be endless debates about how to "simulate" design requirements that C# doesn't support (like multiple inheritance). The suggestion saves trouble because the resulting code will be more orthogonal and thus easier to understand, maintain, and especially extend.
i will say that i prefer the mix of both (because of my limited knowledge i am not familiar with all the concepts of oops ) i use objects for the ease of code implementation when it is possible to make an object i make it i cant completely avoid it cause it is almost not possible for me to write with out objects ( cause objects makes things simpler for me to implement and if i think it throughly there are less chances of any bugs ) :)
it is good to be important but it is more important to be good
-
there were few discussions about rules for programming few days ago i am working in a company which is newly started and only two programmers there and no one to guide except CP so what are the rules which you follow and think i should also follow :):)
You should develop good coding habits not follow rules :D
Todd Smith
-
The Grand Negus wrote:
resulting code will be more orthogonal and thus easier to understand, maintain, and especially extend.
But code reuse isn't as good as in object oriented programming. Get with the times, traditional procedural programming is old school and part of the past. I haven't done procedural coding in about 15 years :->
I'd like to help but I don't feel like Googling it for you.
PaulC1972 wrote:
But code reuse isn't as good as in object oriented programming. Get with the times, traditional procedural programming is old school and part of the past.
Or the whole object-oriented approach was a wrong turn and the sooner we get back on the right road, the better. The object approach to programming is very much like the hierarchical (and, with multiple inheritance, the network) approaches to database managent. Both the hierarchical and the network approaches gained significant popularity and support from major players (like IBM) at one time - and both were made more or less obsolete by the relational approach which was simpler and more orthogonal. We suspect the same thing will happen here. Storing data in tables isn't "old school" or "new school", it's just a good idea for many applications. Likewise, procedural programming isn't "old school" or "new school", it simply works. And as for procedural programs being worse for "code reuse" - which is overrated anyway - that simply isn't true.
-
You should develop good coding habits not follow rules :D
Todd Smith
yes i want that too cause i never have any training i don't have them structured but which i follow are 1) commenting 2) rigid nomenclature 3) spending time on CP :) 4) divide the things for ease 5) thinking before and after coding any other you want to share :):)
it is good to be important but it is more important to be good
-
PaulC1972 wrote:
The Grand Negus wrote: Abandon the "object oriented" way of thinking and write the thing, as much as possible (with the language you've chosen), as traditional procedural code. Nope, I don't think so.
Just trying to save these folks a bit of time and trouble. The suggestion saves time because (1) there won't be endless arguments about how to squeeze the problem into an object hierarchy, and (2) there won't be endless debates about how to "simulate" design requirements that C# doesn't support (like multiple inheritance). The suggestion saves trouble because the resulting code will be more orthogonal and thus easier to understand, maintain, and especially extend.
IMHO, if your team is determined to argue, they'll find something to argue about. Orthogonality should be a goal in and of itself - whether the code is orthogonal or procedural.
---- I just want you to be happy; That's my only little wish...
-
PaulC1972 wrote:
The Grand Negus wrote: Abandon the "object oriented" way of thinking and write the thing, as much as possible (with the language you've chosen), as traditional procedural code. Nope, I don't think so.
Just trying to save these folks a bit of time and trouble. The suggestion saves time because (1) there won't be endless arguments about how to squeeze the problem into an object hierarchy, and (2) there won't be endless debates about how to "simulate" design requirements that C# doesn't support (like multiple inheritance). The suggestion saves trouble because the resulting code will be more orthogonal and thus easier to understand, maintain, and especially extend.
I did not think I'd still read something like this today. Back to the 80s. :)
-
yes i want that too cause i never have any training i don't have them structured but which i follow are 1) commenting 2) rigid nomenclature 3) spending time on CP :) 4) divide the things for ease 5) thinking before and after coding any other you want to share :):)
it is good to be important but it is more important to be good
I would say a consistent coding style is a good one. I'm currently working on a project that uses both 3 and 4 space tabs and I want to commit a crime everytime I jump from style to style. An overall style guide is good if the code base will eventually be used by others. Think "Verbose" It would be interesting to come up with a list of coding practices and have them prioritized based on importance. I imagine the prioity will be different for different kinds of projects.
Todd Smith
-
PaulC1972 wrote:
But code reuse isn't as good as in object oriented programming. Get with the times, traditional procedural programming is old school and part of the past.
Or the whole object-oriented approach was a wrong turn and the sooner we get back on the right road, the better. The object approach to programming is very much like the hierarchical (and, with multiple inheritance, the network) approaches to database managent. Both the hierarchical and the network approaches gained significant popularity and support from major players (like IBM) at one time - and both were made more or less obsolete by the relational approach which was simpler and more orthogonal. We suspect the same thing will happen here. Storing data in tables isn't "old school" or "new school", it's just a good idea for many applications. Likewise, procedural programming isn't "old school" or "new school", it simply works. And as for procedural programs being worse for "code reuse" - which is overrated anyway - that simply isn't true.
Code reuse is not the sole advantage. Should we really get back to this kinds of discussions? (A vast and abundant litterature is available) Just out of curiosity, what is your favorite/working programming language? The debate about the databases is a different one. Using a relational database, has some advantages even though that requires a relational<->OO layer. But in no way this invalidates the advantages of using an OO language.
-
I did not think I'd still read something like this today. Back to the 80s. :)
Pierre Leclercq wrote:
I did not think I'd still read something like this today.
I didn't think I'd have to argue about OOP today :->
I'd like to help but I don't feel like Googling it for you.
-
PaulC1972 wrote:
But code reuse isn't as good as in object oriented programming. Get with the times, traditional procedural programming is old school and part of the past.
Or the whole object-oriented approach was a wrong turn and the sooner we get back on the right road, the better. The object approach to programming is very much like the hierarchical (and, with multiple inheritance, the network) approaches to database managent. Both the hierarchical and the network approaches gained significant popularity and support from major players (like IBM) at one time - and both were made more or less obsolete by the relational approach which was simpler and more orthogonal. We suspect the same thing will happen here. Storing data in tables isn't "old school" or "new school", it's just a good idea for many applications. Likewise, procedural programming isn't "old school" or "new school", it simply works. And as for procedural programs being worse for "code reuse" - which is overrated anyway - that simply isn't true.
ok i'll bite ... do you really consider data hiding, loose coupling, re-use through sane inheritance and function overloading to be bad things? i would have to ask what level of software systems you have worked on but these concepts have been shown to work in the real world for large mc systems ... yet you throw it all away based upon some notion that procedural code is the one true way? classes are procedural code in their member functions ... it's just that the whole entity is wrapped in a "safe" package for consumption really when you say such things as "oo programming is a mistake" you really dont give yourself any credibility here where your audience is largely made up from some of the best programmers in the world sheesh
-
Code reuse is not the sole advantage. Should we really get back to this kinds of discussions? (A vast and abundant litterature is available) Just out of curiosity, what is your favorite/working programming language? The debate about the databases is a different one. Using a relational database, has some advantages even though that requires a relational<->OO layer. But in no way this invalidates the advantages of using an OO language.
Pierre Leclercq wrote:
Should we really get back to this kinds of discussions?
No, because I don't want to :zzz: right now :laugh:
I'd like to help but I don't feel like Googling it for you.
-
ok i'll bite ... do you really consider data hiding, loose coupling, re-use through sane inheritance and function overloading to be bad things? i would have to ask what level of software systems you have worked on but these concepts have been shown to work in the real world for large mc systems ... yet you throw it all away based upon some notion that procedural code is the one true way? classes are procedural code in their member functions ... it's just that the whole entity is wrapped in a "safe" package for consumption really when you say such things as "oo programming is a mistake" you really dont give yourself any credibility here where your audience is largely made up from some of the best programmers in the world sheesh
l a u r e n wrote:
when you say such things as "oo programming is a mistake" you really dont give yourself any credibility here where your audience is largely made up from some of the best programmers in the world
Thank you, l a u r e n :)
l a u r e n wrote:
sheesh
:laugh:
I'd like to help but I don't feel like Googling it for you.
-
there were few discussions about rules for programming few days ago i am working in a company which is newly started and only two programmers there and no one to guide except CP so what are the rules which you follow and think i should also follow :):)
The book is called 'Code Complete'. You should buy this book, and work through it.
Christian Graus - C++ MVP
-
IMHO, if your team is determined to argue, they'll find something to argue about. Orthogonality should be a goal in and of itself - whether the code is orthogonal or procedural.
---- I just want you to be happy; That's my only little wish...
Shog9 wrote:
IMHO, if your team is determined to argue, they'll find something to argue about.
No doubt.
Shog9 wrote:
Orthogonality should be a goal in and of itself - whether the code is orthogonal or procedural.
I use the term in the sense of "keeping separate things separate". It does not seem reasonable to us to hang verbs underneath nouns - or nouns underneath verbs, for that matter. Procedural programming tends to keep the two separate. In one 25,000-line Pascal program we wrote some time ago, for example, we only had two source files, called "nouns" and "verbs". It was a remarkably convenient and effective organization. In case you haven't run across my standard dissertation regarding cookies and ovens and baking, I'll repeat it here: In the object approach, a cookie is an object, and an oven is an object. Fine so far. But should we say "cookie.bake(oven)" or "oven.bake(cookie)" or something else, like "abstract.bake(cookie,oven)". We think all these options are unnatural, and prefer this actual Plain English code:
A cookie is a...
An oven is a...
To bake some cookies in an oven...Where the nouns and the verbs are "related" to the verb in the routine header (the third line above), but do not "hang" underneath each other - or under some artificial abstract class - as they would in the object approach. And we find the syntax much easier to think about, type in, and read, to boot. On a more philosophical note, we all know that cookies don't bake themselves, nor do ovens bake cookies without assistance (as the object model would lead us to believe). Someone bakes cookies in an oven. But the object approach - in great part due to the philosophical orientation of its creator - tries to ignore the existence of the active agent who is necessarily "outside" the system. If you get my drift...
-
I did not think I'd still read something like this today. Back to the 80s. :)
Pierre Leclercq wrote:
I did not think I'd still read something like this today. Back to the 80s.
As C. S. Lewis once said, "We all want progress, but if you're on the wrong road, progress means doing an about-turn and walking back to the right road; in that case, the man who turns back soonest is the most progressive."
-
Rama Krishna Vavilala wrote:
BTW I like all of his points except the last one. For a moment I thought that he was reformed.
But what's wrong with the last one? Since the project involves DirectX, why not take a peek at DarkBasic and see what they've done with it? And no one can deny that Wirth doesn't know his stuff and is worth reading - especially when such a compact example of his mature work is readily available. And since the Plain English development system is the only program I know that illustrates not only the desirability but the feasibility of eliminating nested IFs, LOOPs, and spurious widgets, why not recommend it? It's an excellent example of thinking "outside the box" that can't be found elsewhere.
I think they may be refering to the hypocrisy that appears on many levels with the "rider" on the last one:
The Grand Negus wrote:
Finally, they should get the Plain English development system and work their way through it to further broaden their thinking.
You need to broaden your thinking beyond just whoring your products.
Matt Gerrans
-
Code reuse is not the sole advantage. Should we really get back to this kinds of discussions? (A vast and abundant litterature is available) Just out of curiosity, what is your favorite/working programming language? The debate about the databases is a different one. Using a relational database, has some advantages even though that requires a relational<->OO layer. But in no way this invalidates the advantages of using an OO language.
Pierre Leclercq wrote:
Just out of curiosity, what is your favorite/working programming language?
Plain English, of course.
Pierre Leclercq wrote:
even though that requires a relational<->OO layer.
Not really. The in-house system we've been using for the past eight years is a relational "pagebase" where virtually no unnecessary translations between the stored data and the presentation of that data for viewing and manipulation are made. This particular program is called PERSPECTIVE and was written in Pascal. I can email you a 100-page PDF describing the system if you're interested. Just ask: help@osmosian.com.
-
I think they may be refering to the hypocrisy that appears on many levels with the "rider" on the last one:
The Grand Negus wrote:
Finally, they should get the Plain English development system and work their way through it to further broaden their thinking.
You need to broaden your thinking beyond just whoring your products.
Matt Gerrans
-
Shog9 wrote:
IMHO, if your team is determined to argue, they'll find something to argue about.
No doubt.
Shog9 wrote:
Orthogonality should be a goal in and of itself - whether the code is orthogonal or procedural.
I use the term in the sense of "keeping separate things separate". It does not seem reasonable to us to hang verbs underneath nouns - or nouns underneath verbs, for that matter. Procedural programming tends to keep the two separate. In one 25,000-line Pascal program we wrote some time ago, for example, we only had two source files, called "nouns" and "verbs". It was a remarkably convenient and effective organization. In case you haven't run across my standard dissertation regarding cookies and ovens and baking, I'll repeat it here: In the object approach, a cookie is an object, and an oven is an object. Fine so far. But should we say "cookie.bake(oven)" or "oven.bake(cookie)" or something else, like "abstract.bake(cookie,oven)". We think all these options are unnatural, and prefer this actual Plain English code:
A cookie is a...
An oven is a...
To bake some cookies in an oven...Where the nouns and the verbs are "related" to the verb in the routine header (the third line above), but do not "hang" underneath each other - or under some artificial abstract class - as they would in the object approach. And we find the syntax much easier to think about, type in, and read, to boot. On a more philosophical note, we all know that cookies don't bake themselves, nor do ovens bake cookies without assistance (as the object model would lead us to believe). Someone bakes cookies in an oven. But the object approach - in great part due to the philosophical orientation of its creator - tries to ignore the existence of the active agent who is necessarily "outside" the system. If you get my drift...
The Grand Negus wrote:
A cookie is a... An oven is a... To bake some cookies in an oven...
i think thats what we do
public void bake ( int number of cookies)
Cookie[] cookie = new Cookie[number of cookies required]
Oven oven;prepare cookies
for (int i =0 ; i < number of cookies ; i++)
{
cookie[i] =new cookie(.. list of ingredients)
}oven = new oven(cookie); //we put cookies in the oven
oven.Baked+= new Eventhandler(bake complete) //initiate the timer}
// the ingredients are defined as properties
public void bakecomplete()
{
// code goes here
}in this scenario we will need one oven and if it goes faulty then repairing it is easier :)
it is good to be important but it is more important to be good