ok what are the rules
-
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
-
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 number one rule is: Sometimes you need to break the rules, including this one.
Matt Gerrans
-
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
-
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."
At a time when all the roads led to Rome, you'd just ride on the fastest, largest and most straight road. But nowadays, there are a lot of good places to ride to. So I'd rather just take the road that leads me to the right place. :)
-
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.
The Grand Negus wrote:
Plain English, of course.
What is this? I mean are you kidding, or could you show a link describing it?
-
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.
Me neither :)
-
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
Here's the short answer, and we can go from there: we've developed a wide variety of major applications - including super-fast native-code compilers and super-smooth wysiwyg page layout programs - conveniently and efficiently without those things. So we haven't found them helpful or necessary. And we're more than willing to share our code and our ideas so others can see another way of doing things. Further comment on objects can be found here in this thread: [^] And further information about why we think our product is important can be found here: [^] Our two-page manifesto is on our website (www.osmosian.com).
-
Here's the short answer, and we can go from there: we've developed a wide variety of major applications - including super-fast native-code compilers and super-smooth wysiwyg page layout programs - conveniently and efficiently without those things. So we haven't found them helpful or necessary. And we're more than willing to share our code and our ideas so others can see another way of doing things. Further comment on objects can be found here in this thread: [^] And further information about why we think our product is important can be found here: [^] Our two-page manifesto is on our website (www.osmosian.com).
-
And that syntax seems better to you?
"oven = new oven(cookie)"
instead of this Plain English code:
Put the cookies in the oven.
which you nearly typed in anyway (as a comment)! C'mon, folks. We're trying to get into the 21st century here...
but saying you cannot avoid the usability of OOP and in a fair bigger scenario like nature (concepts of oop are basically from there if you read them in a bit detail ) supporting one technology is good thing like saying India is great but opposing other is like saying Xyz is not a good country why it is not and how can i say that without any experience of living in Xyz instead saying this shows that Xyz is a great country cause i targeted it and it has some thing great that i am jealous of :)
it is good to be important but it is more important to be good
-
The Grand Negus wrote:
Plain English, of course.
What is this? I mean are you kidding, or could you show a link describing it?
Pierre Leclercq wrote:
The Grand Negus wrote: Plain English, of course. What is this? I mean are you kidding, or could you show a link describing it?
No, all the programs we write now we write in Plain English. The current Plain English development system - including unique interface, simplified file manager, hexadecimal dumper, efficient text editor, native-code-generating compiler/linker, and wysiwyg page-layout facility (for documentation) is written entirely in (the previous version of) Plain English. The entire program is less than a megabyte in size, recompiles itself in less than 3 seconds on a bottom-of-the-line Dell, and requires no installation program or special runtime libraries. Why we think it's an important product is summarized here: [^] Our goals and what you can do to help can be found in the two-page Manifesto on our website: www.osmosian.com.
-
The number one rule is: Sometimes you need to break the rules, including this one.
Matt Gerrans
:laugh: :laugh: :laugh: :laugh: :laugh:
it is good to be important but it is more important to be good
-
:laugh: :laugh: :laugh: :laugh: :laugh:
it is good to be important but it is more important to be good
Good point - never write something that doesn't make sense, because it conforms to some external rule.
Christian Graus - C++ MVP
-
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:
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...
As you note, i don't give my oven a list of instructions. The processor for cookies is a human, but this can be implied, and the recipe i write out might well have a bigger focus on nouns (ingredients) than verbs (actions performed on them). In fact, recipes traditionally are written with a very few key verbs, interpreted by context:
Mix: 1/2 cup milk, 3 egg yolks (beaten) 1/4 cup brown sugar Fold in: 3 egg whites (whipped to soft peaks)
Behind this procedural list of instructions, the mechanics of separating eggs, beating the yolks, whipping the whites, the distinction between mixing and folding... is hidden. The differences between measuring milk and brown sugar are assumed to be known by the processor. "measure 1/4 cup brown sugar using brown sugar measuring method" is unnecessary, as the processor knows to use the method appropriate for each ingredient. Polymorphism in action. Correct me if i'm wrong, but it seems that a big part of your argument against OO has to do with the syntax. While i'd agree that there is room for improvement in the syntax used for OO in C-derived languages, i don't find the English sentence structure a particularly appealing substitute. Perhaps this is just my personal taste, but it generally takes me twice as long to write an English description of an algorithm than it does to codify the algorithm in my language of choice (of course, my notes are nominally in English, but as a series of diagrams and brief annotations intended to jog my memory, wholly unsuitable for communicating my ideas with anyone).
---- I just want you to be happy; That's my only little wish...
-
Kevin McFarlane wrote:
Quite harsh but I agree we should avoid deep nesting (McConnell suggess no deeper than 3). But in my experience almost no-one does.
Agreed; almost no-one does. But we do, and we've found it a good idea to do so. And we've written significant programs with no nesting at all to prove the point. We believe it (1) streamlines the design, (2) increases readability, and (3) improves reliability.
When I said almost no-one does this should not be taken to imply that I approve of the practice! :) Most programmers (probably not CPers) are very poor in this regard. But the type of people who post to CP are more likely to be the type of people who care about programming.
Kevin
-
Consider reading this http://www.netobjectives.com/download/Code%20Qualities%20and%20Practices.pdf[^]
Hey, Richard, this looks quite good from a casual glance. I'll print it out and read it tomorrow. I've already read their Design Patterns book.
Kevin
-
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:
On a more philosophical note
Come on. Have you heard of a guy named Descartes? (I think therefore I am). He did an excellent work thinking about how to think. He developed what is called today the top-down approach. This way of thinking is particularly useful, and has been applied successfully in many disciplines, and led to fruitful solutions. For software it was very useful too. That's the underlying concept for procedural computing. But software remains a discipline with its own particularities. And as projects became larger and larger, it appeared this approach had some drawbacks (especially for evolving the systems). (See Meyer on this). So OOP brings in a very nice concept, I mean bottom-up approach. Top-down remains a must for designing a system, but bottom-up provides extremely valuable features for implementing software systems. (procedural remains useful for small and low level code, but the days of 64k central memory are over)
-
Hey, Richard, this looks quite good from a casual glance. I'll print it out and read it tomorrow. I've already read their Design Patterns book.
Kevin
If you require details of related matters then post your needs. Also, note that some time ago I posted details of Microsoft's Architecture Journal. Well, Journal 9 has just been issued. For you and others who might want a hard copy delivered to your home/work address or wishing to download PDF's of all issues of this journal, point your browser at www.architecturejournal.net[^]
-
Consider reading this http://www.netobjectives.com/download/Code%20Qualities%20and%20Practices.pdf[^]
Interesting article - but I have real issues with the first two points.
Developers, Developers, Developers, Developers, Developers, Developers, Velopers, Develprs, Developers!
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
Linkify!|Fold With Us!