ok what are the rules
-
Jeremy Falcon wrote:
Ok, I'll repeat... without using abstractions and referring to PEP (let's talk design concepts) give me details why you think OOP sucks. I won't talk about C/C++, and you don't talk about PEP. That way nobody has an edge over one or the other. And, I'm talking about points here, not general ideas. Let's get down and dirty and talk just why OOP is so bad. Open up the hood and let's go to town on it.
I don't like OOP for two basic reasons. The first settles the issue for me; the second is more-or-less just an example of what happens when one starts with a bad premise and presses on anyway. (1) I disagree with the basic paradigm - I think programmed objects are operated on from the outside, and don't do things in, and of, and to themselves. Rectangles don't draw themselves and numbers don't add themselves to other numbers. (2) I disagree with the syntax that is the spawn of this flawed paradigm; the syntax of object-oriented languages is typically unnatural and unwieldy. "Rectangle.draw(device)" is an unhelpful and difficult way of expressing the thought that somebody or something outside of the rectangle is supposed to render it on the specified device; it is nowhere near as simple or natural as the procedural syntax "Draw(rectangle,device)". "Number.add(2,2)" is also not a clear expression of the thought being expressed; Add(2,2) is preferable.
The Grand Negus wrote:
I don't like OOP for two basic reasons. The first settles the issue for me; the second is more-or-less just an example of what happens when one starts with a bad premise and presses on anyway.
Ok, but you have to realize these are personal preferences and still abstractions, but hey I'll bite anyway. And speaking of preferences it's impossible to say yay or nay regarding OOP (or anything for that matter) because there's no fundamental point involved in this manner. Now, to dismiss all that OOP is because of your preference doesn't make OOP bad at what it was meant for... which I'll get to a bit of in a bit.
The Grand Negus wrote:
I disagree with the basic paradigm - I think programmed objects are operated on from the outside, and don't do things in, and of, and to themselves. Rectangles don't draw themselves and numbers don't add themselves to other numbers.
One of the fundamental philosophy’s behind OOP is encapsulation. This was created for a reason. In large projects (25k lines isn't that large, medium I'd say) with a lot of developers working on it, the less an average developer has to mess with the better. The merits of which may not manifest itself until you are in this situation. Now, can you achieve similarities in procedural code? Heck yeah, but OOAD demands it and breaking away from it is breaking away from established design patterns. Also, the outside-in paradigm is more in-line with how most people learn. You get a high level view and dig into it deeply. Pure OO enforces this. Yeah, a good procedural design helps in this regards too, but in my experience OOP does it better because more people adhere to it when it's enforced. And, like I said that fact doesn't make OOP bad.
The Grand Negus wrote:
"Rectangle.draw(device)" is an unhelpful and difficult way of expressing the thought that somebody or something outside of the rectangle is supposed to render it on the specified device; it is nowhere near as simple or natural as the procedural syntax "Draw(rectangle,device)".
Well, this is still abstraction on your preference, but to this I'll have to say; "says who?" The object.member syntax is just that - syntax. OOAD is not that. Syntax is one way it's implemented and taught, but the concepts aren't limited to it. With that being said, in your example the
Recatngleobject do -
You know, I read through all this stuff and I've got a couple comments. First of all, I am experienced enough to hang with you, and I still don't understand where you're coming from. A history of working with better and better things through the years does not make me want to go back to strictly procedural programs. OOP is the best thing to come along in my many years of doing this stuff. It doesn't apply to ALL problems, but it applies to 99% of them in a way that's easy for human programmers to understand. Second, everyone knows that speaking to your computer in plain English (or German or Arabic or Swahili) would be awesome, but like so many other things on Star Trek, we're not there yet. Furthermore, the development of Plain English doesn't negate the usefulness of OOP... I would be willing to bet that most Plain English parsing engines are written in some kind of OOP language. Someone with your experience should know that, at some point, you have to bridge the gap between the user and the chips in the machine. I don't want to go back to writing machine code by hand, and neither does anybody else. OOP languages that compile down to real code are the best option we have right now. I don't understand why you're so reluctant to admit that. Sounds like you're stuck in the past. I read your definition of how Plain English works, and you described it in an object-oriented manner... ears, brain, calculator... I hate to burst your bubble but those are objects.
"Quality Software since 1983!"
http://www.smoothjazzy.com/ - see the "Programming" section for (freeware) JazzySiteMaps, a simple application to generate .Net and Google-style sitemaps!Jasmine2501 wrote:
I would be willing to bet that most Plain English parsing engines are written in some kind of OOP language.
But ours isn't written that way. And we prefered not to write it that way - though we could have. And we believe that the ease with which we produced it, and the efficiency with which it runs, testifies to the fact that we made the right decision.
Jasmine2501 wrote:
Someone with your experience should know that, at some point, you have to bridge the gap between the user and the chips in the machine.
Of course. And we did bridge that gap - we wrote a Plain English compiler, in Plain English, that generates native Intel machine code.
Jasmine2501 wrote:
OOP languages that compile down to real code are the best option we have right now.
We don't think so. We prefer to program in Plain English. Without objects. And we do.
Jasmine2501 wrote:
I don't understand why you're so reluctant to admit that.
Because we've done it both ways and prefer Plain English without objects.
Jasmine2501 wrote:
Sounds like you're stuck in the past.
The past? We're not the ones using a derivative of a language and syntax from the 1960's! We're using our own native tongue - English - to write programs.
Jasmine2501 wrote:
I read your definition of how Plain English works, and you described it in an object-oriented manner... ears, brain, calculator... I hate to burst your bubble but those are objects.
Objects in the sense of "nouns", yes. But objects in the sense that they "do things" on their own, in the sense that they have their "methods" inside them, no. Our ears don't hear; they are used by us to hear with. Our brains don't think; they are used by us to think with. Our calculators don't calculate; they are used by us to calculate with. This is the fundamental issue we have with objects - they way they bind verbs underneath the nouns. This, we believe, is fundamentally wrong - a bad paradigm. All the other flaws of the object approach stem from this error.
-
The Grand Negus wrote:
I don't like OOP for two basic reasons. The first settles the issue for me; the second is more-or-less just an example of what happens when one starts with a bad premise and presses on anyway.
Ok, but you have to realize these are personal preferences and still abstractions, but hey I'll bite anyway. And speaking of preferences it's impossible to say yay or nay regarding OOP (or anything for that matter) because there's no fundamental point involved in this manner. Now, to dismiss all that OOP is because of your preference doesn't make OOP bad at what it was meant for... which I'll get to a bit of in a bit.
The Grand Negus wrote:
I disagree with the basic paradigm - I think programmed objects are operated on from the outside, and don't do things in, and of, and to themselves. Rectangles don't draw themselves and numbers don't add themselves to other numbers.
One of the fundamental philosophy’s behind OOP is encapsulation. This was created for a reason. In large projects (25k lines isn't that large, medium I'd say) with a lot of developers working on it, the less an average developer has to mess with the better. The merits of which may not manifest itself until you are in this situation. Now, can you achieve similarities in procedural code? Heck yeah, but OOAD demands it and breaking away from it is breaking away from established design patterns. Also, the outside-in paradigm is more in-line with how most people learn. You get a high level view and dig into it deeply. Pure OO enforces this. Yeah, a good procedural design helps in this regards too, but in my experience OOP does it better because more people adhere to it when it's enforced. And, like I said that fact doesn't make OOP bad.
The Grand Negus wrote:
"Rectangle.draw(device)" is an unhelpful and difficult way of expressing the thought that somebody or something outside of the rectangle is supposed to render it on the specified device; it is nowhere near as simple or natural as the procedural syntax "Draw(rectangle,device)".
Well, this is still abstraction on your preference, but to this I'll have to say; "says who?" The object.member syntax is just that - syntax. OOAD is not that. Syntax is one way it's implemented and taught, but the concepts aren't limited to it. With that being said, in your example the
Recatngleobject do -
:laugh::laugh::laugh: Joke Right?
We made the buttons on the screen look so good you'll want to lick them. Steve Jobs
-
It seems that you can turn almost anything into an "abstraction" and/or a "personal preference" and then discard it. So I don't think there's enough common ground beneath us to continue. But that's just my personal preference...
The Grand Negus wrote:
It seems that you can turn almost anything into an "abstraction" and/or a "personal preference" and then discard it. So I don't think there's enough common ground beneath us to continue.
That's because you don't know OOP well enough to get what I'm after. I'm looking for points that don't involve "this dot looks silly". If you can't understand this, then I guess you're right we're going to get nowhere. If you can't understand why I call "this dot looks silly" your preference, then I suggest you take a cold hard look into the fact your understanding and knowledge may not be as superior as you'd like to believe it is.
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
-
Jasmine2501 wrote:
I would be willing to bet that most Plain English parsing engines are written in some kind of OOP language.
But ours isn't written that way. And we prefered not to write it that way - though we could have. And we believe that the ease with which we produced it, and the efficiency with which it runs, testifies to the fact that we made the right decision.
Jasmine2501 wrote:
Someone with your experience should know that, at some point, you have to bridge the gap between the user and the chips in the machine.
Of course. And we did bridge that gap - we wrote a Plain English compiler, in Plain English, that generates native Intel machine code.
Jasmine2501 wrote:
OOP languages that compile down to real code are the best option we have right now.
We don't think so. We prefer to program in Plain English. Without objects. And we do.
Jasmine2501 wrote:
I don't understand why you're so reluctant to admit that.
Because we've done it both ways and prefer Plain English without objects.
Jasmine2501 wrote:
Sounds like you're stuck in the past.
The past? We're not the ones using a derivative of a language and syntax from the 1960's! We're using our own native tongue - English - to write programs.
Jasmine2501 wrote:
I read your definition of how Plain English works, and you described it in an object-oriented manner... ears, brain, calculator... I hate to burst your bubble but those are objects.
Objects in the sense of "nouns", yes. But objects in the sense that they "do things" on their own, in the sense that they have their "methods" inside them, no. Our ears don't hear; they are used by us to hear with. Our brains don't think; they are used by us to think with. Our calculators don't calculate; they are used by us to calculate with. This is the fundamental issue we have with objects - they way they bind verbs underneath the nouns. This, we believe, is fundamentally wrong - a bad paradigm. All the other flaws of the object approach stem from this error.
The Grand Negus wrote:
Because we've done it both ways and prefer Plain English without objects.
Take this line...
Print "Hello" to the console.
You do realize that console is in fact an object don't you? Whether or not you use procedural code or OOP methods to describe it doesn't make a difference.
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
-
Matt Gerrans wrote:
More to the point, why don't you add your Plain English implementations (and stats) to The Great Win32 Computer Language Shootout[^]?
Primarily because what we're offering is not in direct competition with existing languages. It's the "programming language of the future" and will eventually include most of the other languages for use where they are the appropriate. Think of Plain English like the "text" part of a calculus book; a framework within which other sub-languages are used. Example. I want my Plain English Household Computer, the PAL 3000, to work out a problem for me. I walk over to it and say, "I'm pouring a slab of concrete today, PAL. It's 25 feet by 50 feet and it's 4 inches think. How many cubic yards of concrete should I order?" And the PAL gives me the answer. How? First, by parsing the question. Then by calling a routine to handle the calculation, perhaps using Wolfram's Mathematica program that is stored somewhere on the disk. Note that this process is not unlike the way you and I might do the thing. I say, "Matt, I'm pouring a slab of concrete today..." and you parse the thing in your head, work out the figures on a nearby calculator, and give me the answer. So, which part is missing here? You've got ears, a calculator, and a brain, so we can interact like this. My computer's got a microphone and Mathematica but... See? The part that's missing the the very part we're working on. Who woulda thunk?
The Grand Negus wrote:
Primarily because what we're offering is not in direct competition with existing languages. It's the "programming language of the future" and will eventually include most of the other languages for use where they are the appropriate.
Um, so what are you saying? It isn't good for solving these kinds of problems? I don't have any confusion if what you are promoting is a human-computer interface of the future (a la Star Trek), but you seem to have promoted this thing as the Superior Solution to All Problems (TM) of the present in many other posts. Maybe you need to more clearly define exactly what it is you are advertising in The Lounge. By the way, you said in another post that you are a millionaire; if that is the case, I really don't understand why you don't go ahead and pay for your advertising. You would be buying yourself some good will in addition.
Matt Gerrans
-
The Grand Negus wrote:
Because we've done it both ways and prefer Plain English without objects.
Take this line...
Print "Hello" to the console.
You do realize that console is in fact an object don't you? Whether or not you use procedural code or OOP methods to describe it doesn't make a difference.
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
Jeremy Falcon wrote:
The Grand Negus wrote: Because we've done it both ways and prefer Plain English without objects. Take this line... Print "Hello" to the console. You do realize that console is in fact an object don't you? Whether or not you use procedural code or OOP methods to describe it doesn't make a difference.
What matters is whether or not the "print" function is inside and therefore an integral part of the console object, or outside and more or less independent of it. The object approach says, "inside"; we say, "outside".
-
Jeremy Falcon wrote:
The Grand Negus wrote: Because we've done it both ways and prefer Plain English without objects. Take this line... Print "Hello" to the console. You do realize that console is in fact an object don't you? Whether or not you use procedural code or OOP methods to describe it doesn't make a difference.
What matters is whether or not the "print" function is inside and therefore an integral part of the console object, or outside and more or less independent of it. The object approach says, "inside"; we say, "outside".
The Grand Negus wrote:
The object approach says, "inside"; we say, "outside".
As said already this works with either A: small teams or B: uber top-notch programmers (not people that think they are). And, as sure as the sun rises, the more programmers you throw into the mix the more retards you're going to get. Btw, two PEP programmers using the same computer is a very small team.
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
-
The Grand Negus wrote:
Primarily because what we're offering is not in direct competition with existing languages. It's the "programming language of the future" and will eventually include most of the other languages for use where they are the appropriate.
Um, so what are you saying? It isn't good for solving these kinds of problems? I don't have any confusion if what you are promoting is a human-computer interface of the future (a la Star Trek), but you seem to have promoted this thing as the Superior Solution to All Problems (TM) of the present in many other posts. Maybe you need to more clearly define exactly what it is you are advertising in The Lounge. By the way, you said in another post that you are a millionaire; if that is the case, I really don't understand why you don't go ahead and pay for your advertising. You would be buying yourself some good will in addition.
Matt Gerrans
Matt Gerrans wrote:
Um, so what are you saying? It isn't good for solving these kinds of problems?
We're saying it's good for solving all kinds of problems, from text editors to compilers, from file managers to page layout programs. But it is not the best choice for everything, obviously - nothing fits that bill.
Matt Gerrans wrote:
I don't have any confusion if what you are promoting is a human-computer interface of the future (a la Star Trek), but you seem to have promoted this thing as the Superior Solution to All Problems (TM) of the present in many other posts. Maybe you need to more clearly define exactly what it is you are advertising in The Lounge.
Well, try this for further information: [^]. I think it's in the Soapbox, but they're pretty much the same to me.
Matt Gerrans wrote:
By the way, you said in another post that you are a millionaire; if that is the case, I really don't understand why you don't go ahead and pay for your advertising. You would be buying yourself some good will in addition.
We did, at the start, buy ads here. Lots of 'em. But they didn't translate into sales, so we stopped buying. We also published several articles here, but the powers that be deleted them on grounds that we were never quite able to determine. Besides, I'm not a "millionaire" any more - if by that term you mean someone with at least a million dollars in assets. I've made millions over the years, to be sure - and spent most of it, primarily on research of various sorts. I've still got enough so I don't have to "work" in the conventional sense, but it's not enough to throw away on ads that aren't paying for themselves.
-
The Grand Negus wrote:
The object approach says, "inside"; we say, "outside".
As said already this works with either A: small teams or B: uber top-notch programmers (not people that think they are). And, as sure as the sun rises, the more programmers you throw into the mix the more retards you're going to get. Btw, two PEP programmers using the same computer is a very small team.
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
Jeremy Falcon wrote:
The Grand Negus wrote: The object approach says, "inside"; we say, "outside". As said already this works with either A: small teams or B: uber top-notch programmers (not people that think they are). And, as sure as the sun rises, the more programmers you throw into the mix the more retards you're going to get. Btw, two PEP programmers using the same computer is a very small team.
I'm saying that the "print" function doesn't belong inside the console object. Period. Why? Because consoles don't print strings - strings are printed on consoles. The size of the team has nothing to do with this.
-
You are not alone.
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -Brian Kernighan
-
Buy a copy of Steve McConnell's Code Complete for the office. Depending on what languages you're using look up the recommended style and/or practices guides on the web. E.g., for .NET this would be MS's Design Guidelines for Class Library Developers in the MSDN library. Though I don't think this has been updated for .NET 2.
Kevin
I am still waiting for my copy from Amazon :^)
-
BTW I like all of his points except the last one. For a moment I thought that he was reformed.
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -Brian Kernighan
Rama Krishna Vavilala wrote:
For a moment I thought that he was reformed
Well I only count one "Plain English", and it only constitutes one point amongst a dozen other points. Not sure how you define reformed but that's pretty close in my book.
"For fifty bucks I'd put my face in their soup and blow." - George Costanza
~ Web SQL Utility - asp.net app to query Access, SQL server, MySQL. Stores history, favourites.
-
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 :):)
Well the fact that you have started a thread with a massive number of replies, shows there is no simple answer. But there is only one Golden Rule you should follow when it comes to programming: DO NOT, under any circumstances, write ANYTHING in Visual Basic! (I just can't believe no one else has stated this already! :)) BTW, you might even have started the longest Lounge thread this year? Partly because you gave an opportunity for the words 'plain english' to appear :doh: :laugh:
"For fifty bucks I'd put my face in their soup and blow." - George Costanza
~ Web SQL Utility - asp.net app to query Access, SQL server, MySQL. Stores history, favourites.
-
Jeremy Falcon wrote:
Who said anything about being a hypocrite?
The message all these are hanging under.
Jeremy Falcon wrote:
It's still exploiting the lounge however.
I quote: "The Lounge is a place where you can discuss anything that takes your fancy. If you just want to laze about and discuss things that don't quite fit elsewhere, then this is the place." And this right is granted to all members, and the only thing required to join is a name and a string of characters that will pass for an email address. So here we are. Besides, what harm are we doing? In fact, I would argue that our posts engender more interesting and more meaningful discussions, on the whole, than many of the "non-exploiting" posters here. Chris should pay us to post just to liven up the place!
"Eppur si muove" - ? :)
-
Amar Chaudhary wrote:
so what are the rules which you follow and think i should also follow
Sorry, forgot one - a very important one: 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. Keep your nouns (data definitions) and your verbs (operations on those nouns) separate.
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. Keep your nouns (data definitions) and your verbs (operations on those nouns) separate.
Now I finally understand you. You are not a troll, you are totally incapable of understanding and "getting a clue" because you have lost complete touch with reality. This finally makes sense. The good news is, they do have medication for schizophrenia now. The bad news is, you probably will not, therefore HAL will keep talking you into visiting us and preaching your nonsense.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
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. Keep your nouns (data definitions) and your verbs (operations on those nouns) separate.
Now I finally understand you. You are not a troll, you are totally incapable of understanding and "getting a clue" because you have lost complete touch with reality. This finally makes sense. The good news is, they do have medication for schizophrenia now. The bad news is, you probably will not, therefore HAL will keep talking you into visiting us and preaching your nonsense.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
Jeffry J. Brickley wrote:
You are not a troll, you are totally incapable of understanding and "getting a clue" because you have lost complete touch with reality
:laugh: Good one :-D
Some people have a memory and an attention span, you should try them out one day. - Jeremy Falcon
-
Jasmine2501 wrote:
I would be willing to bet that most Plain English parsing engines are written in some kind of OOP language.
But ours isn't written that way. And we prefered not to write it that way - though we could have. And we believe that the ease with which we produced it, and the efficiency with which it runs, testifies to the fact that we made the right decision.
Jasmine2501 wrote:
Someone with your experience should know that, at some point, you have to bridge the gap between the user and the chips in the machine.
Of course. And we did bridge that gap - we wrote a Plain English compiler, in Plain English, that generates native Intel machine code.
Jasmine2501 wrote:
OOP languages that compile down to real code are the best option we have right now.
We don't think so. We prefer to program in Plain English. Without objects. And we do.
Jasmine2501 wrote:
I don't understand why you're so reluctant to admit that.
Because we've done it both ways and prefer Plain English without objects.
Jasmine2501 wrote:
Sounds like you're stuck in the past.
The past? We're not the ones using a derivative of a language and syntax from the 1960's! We're using our own native tongue - English - to write programs.
Jasmine2501 wrote:
I read your definition of how Plain English works, and you described it in an object-oriented manner... ears, brain, calculator... I hate to burst your bubble but those are objects.
Objects in the sense of "nouns", yes. But objects in the sense that they "do things" on their own, in the sense that they have their "methods" inside them, no. Our ears don't hear; they are used by us to hear with. Our brains don't think; they are used by us to think with. Our calculators don't calculate; they are used by us to calculate with. This is the fundamental issue we have with objects - they way they bind verbs underneath the nouns. This, we believe, is fundamentally wrong - a bad paradigm. All the other flaws of the object approach stem from this error.
The Grand Negus wrote:
The past? We're not the ones using a derivative of a language and syntax from the 1960's! We're using our own native tongue - English - to write programs.
So you are worried we're using a derivative of a 1960's language, continously improved using lessoned learned over the last 40 years, and you are using the random brain firings of a language from 5000 or more BC that doesn't even write well!??!! Wow, what a "bear" of a project to "bare" to us here. Pity you can't "pare" your ego down, or at least "pair" it up with a bit of logic instead of nonsense...
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
PaulC1972 wrote:
I thought that when the Osmosian guys posted those articles some months ago. Couldn't make any sense of the coding and it looked like something I would have gotten agitated over.
Yeah, they keep on saying PEP is more natural and you can type more code despite it being verbose because it flows so to speak. Personally, I don't think they spent enough time coding in another language that's not verbose to get that same flow. And having to use the shift key is not a show stopper for me. :rolleyes: Really though, if syntax was the only issue in debate (which it's not). I still wouldn't be crazy about it.
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
Jeremy Falcon wrote:
And having to use the shift key is not a show stopper for me.
Which just goes to show you that you have never drunk all your brain cells away. :)
Jeremy Falcon wrote:
Really though, if syntax was the only issue in debate (which it's not). I still wouldn't be crazy about it.
That has always been what I have said. We need something to gain from a language. At least C# has some benefits to the programmer beyond just a "new" (or in the case of PEP: incredibly ancient) syntax. In fact, there is so much you have to give up to program in PEP that half of the software written today wouldn't be possible to write in PEP. No games, no simulations, no scientific visualization, no concurrent massive parallel problem solving.... He may want "HAL 9000", but he is pushing a Hal 9000BC!
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)