ok what are the rules
-
PaulC1972 wrote:
You counter Jeremy with this argument, can't you accept his challenge?
Yeah you beat me to it. It's obvious he can't.
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
Jeremy Falcon wrote:
It's obvious he can't.
I am still waiting for my Traveling Salesman Problem code in Plain English...
If you try to write that in English, I might be able to understand more than a fraction of it. - Guffa
-
The Grand Negus wrote:
But where's the hypocrisy in that?
Who said anything about being a hypocrite? It's still exploiting the lounge however.
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
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!
-
The Grand Negus wrote:
How about this argument. We wrote an exceptionally efficient native-code-generating compiler/linker with interface, file manager, dumper, text editor, and wysiwyg page editor using exclusively procedural code and not once during the development did the project suffer from disorganization, unreliability, or unnatural expression and not once during the development were we ever even tempted to think in an object-oriented paradigm. If that doesn't do it for you, I don't think a handful of posts here will help.
Won't fly, for one it's abstract. For two, you can do the same thing with an OOP paradigm.
The Grand Negus wrote:
When I first started teaching database design many years ago, I wrote into my materials an appendix explaining why the hierarchical and network approaches to database management were less desirable. I soon found, however, that once students mastered the simple and obvious relational approach taught in the course, the appendix ceased to be of interest; so I delete it. I think the same thing applies here.
We're not talking DBs here. Not to mention, DBMSs use a relational flat scheme, so this is apples to oranges.
The Grand Negus wrote:
If you have a particular example where you think object-oriented thinking works better than a procedural approach, however, I'll be happy to dissect it.
I'd be happy to, but only after you stop avoiding my challenge. Don't pull the "you first" card. I challenged you, not the other way around. If you can't accept that then you obviously don't know enough to defend your stance or otherwise you would have. And for the second time, leave the abstractions out of it. I'm sure someone with your superior intellect can understand this.
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
Jeremy Falcon wrote:
And for the second time, leave the abstractions out of it. I'm sure someone with your superior intellect can understand this.
Unfortunately, I can't. Give me an example of what would convince you (and what I'm trying to convince you of - I've forgotten). Something like: If _____________ then I, Jeremy Falcon will be convinced that _____________. Thanks.
-
l a u r e n wrote:
...but you keep on plugging your product...
Well said, except that should be "...but you keep on whoring your product..." just to be consistent. ;)
Matt Gerrans
-
Jeremy Falcon wrote:
And for the second time, leave the abstractions out of it. I'm sure someone with your superior intellect can understand this.
Unfortunately, I can't. Give me an example of what would convince you (and what I'm trying to convince you of - I've forgotten). Something like: If _____________ then I, Jeremy Falcon will be convinced that _____________. Thanks.
The Grand Negus wrote:
Unfortunately, I can't. Give me an example of what would convince you (and what I'm trying to convince you of - I've forgotten).
As said already, I'd be delighted to, but only after you say yay or nay on my challenge. It's just that simple. And, should you refuse then how can we believe you really know what you're talking about on this ground? I mean, if you know OOP sucks then you surely must know enough about it to make that claim, or how else would you really know it sucks? Really, I wasn't trying to pin you in the past, but it's come to this. I'm trying to help you wake up and see the light. If you need me to give you points so you can refute them with even more abstractions then you just don't know enough about it. Once you admit that, I'll be happy to do as you ask.
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
-
The Grand Negus wrote:
Why don't people use, say, C# to program their dogs? Why do they always just go for the thing they know best?
Most people i know don't really bother programming their dogs at all. As a result, their dogs are not particularly well-behaved. The few i know whose dogs actually listen to them appear to know quite a lot about dogs in general, and their dogs in particular, and spoken commands make up only a small portion of how they communicate (posture, eye contact, etc. make up the rest. As an aside, i've been told that my hat is offensive to dogs... hides my eyes or something).
---- I just want you to be happy; That's my only little wish...
Shog9 wrote:
The few i know whose dogs actually listen to them appear to know quite a lot about dogs in general, and their dogs in particular, and spoken commands make up only a small portion of how they communicate (posture, eye contact, etc. make up the rest.
Of course. And I use mouse clicks, and arrow keys, and an occasional smack on the side of the monitor - in addition to English - to program my computer. Further, I'm not sure I ever met anyone who preferred to program his dog in silence. However small its role, language appears to be an important part of the process. And the language of choice, in this country, is English. Never C#.
-
I'll throw in my two cents. First, I don't like the book Code Complete, though I do suggest reading it once in case it has a good idea you haven't thought of. (Like all books on software methodology, it is excessively dogmatic. It's also a little outdated and, unfortunately, does contain some really bad advice; the problem is it's all so jumbled together it's not clear what the good and bad advice is.) Some of my rules: * Know your tools, especially your debugger and how to search MSDN. * Know your APIs. If you're doing C#.NET, spend an hour each day actually reading through the .NET documentation cover-to-cover. The time will come when you will remember that .NET does something that you now don't have to write and you can look it up. * Know your customer. Treat them as they are always right, even if they aren't. * Hire the best UI designers and do truly objective usability testing. (Rigged usability testing is worse than no testing at all.) * Be pragmatic and flexible. No matter how good your design, how well you have implemented your code, how efficient your process has been, you will never have enough time or resources. The day will come when you will spend seemingly endless days hacking your code just to get it to work. You may even find that your design is so fundamentally flawed you have to throw all your hard work away and start over. * Most "Software Engineers" aren't. Most also overestimate their own capabilities and just how hard software development is. * Commercial software takes significantly longer to develop than that destined for in-house use. * Hire a technical writer early and involve them in all engineering and planning meetings. Have them summarize the results and ensure everyone signs off on them. (Okay, I've had this happen precisely once, but the results were very positive.) * Testing should never answer to the same manager and/or technical leads as the developers. * If you have less than five years solid experience in something, you aren't an expert. Don't claim you are. * In conjunction with this, if someone who IS a recognized expert gives you advice in response to a direct question, listen to them. (Don't spend days or even weeks trying to write code for which a single API is already provided in Win32. Yup, had a developer, the same developer, do this to me three times and yes, he once really did spend two weeks before meekly asking me again what the API was.) * Have one person in charge who has a vision of what the product will be and hold them a
Joe Woodbury wrote:
it is excessively dogmatic
I do agree with you on that front. While I think it's a good book, I do think it should serve as a guide more so than a religion.
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
-
The Grand Negus wrote:
Unfortunately, I can't. Give me an example of what would convince you (and what I'm trying to convince you of - I've forgotten).
As said already, I'd be delighted to, but only after you say yay or nay on my challenge. It's just that simple. And, should you refuse then how can we believe you really know what you're talking about on this ground? I mean, if you know OOP sucks then you surely must know enough about it to make that claim, or how else would you really know it sucks? Really, I wasn't trying to pin you in the past, but it's come to this. I'm trying to help you wake up and see the light. If you need me to give you points so you can refute them with even more abstractions then you just don't know enough about it. Once you admit that, I'll be happy to do as you ask.
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
-
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!
The Grand Negus wrote:
The message all these are hanging under.
Yeah, but I didn't say it - which was what I was getting to with that.
The Grand Negus wrote:
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!
That exploiting the lounge can in fact help CP loose revenue when people don't buy ads to promote their products. The less money CP receives, the greater the risk it will be shut down. That's why the ads are there in the first place. And since you like to quote stuff, why not check out the paragraph at the top of the page for when you create a message: Rules: The Lounge is rated PG. If you're about to post something you wouldn't want your kid sister to read then don't post it. Do not post programming questions (use the programming forums for that) and please don't post ads.
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
-
The Grand Negus wrote:
Exactly what is it that you want to know?
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.
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
-
Amar Chaudhary wrote:
what are the rules which you follow and think i should also follow
Here are a few things that have worked for us, and that you probably won't hear from anyone else: The programmers should work as a team on a single computer with dual monitors, keyboards, and mice. They should take turns leading and following. The leader gets the mouse; the other types in the appropriate code. They should test as often as possible, typically every ten lines of code (or so). They should start each day with a review of the code, looking very hard for things to delete. Less is more. No new code until something old has been removed, consolidated, or otherwise improved. They should avoid nested IFs and nested LOOPs. They should avoid the wanton use of dialogs, and minimize the number of controls on any interface. But before they begin, they should get a copy of DarkBasic and play with it as an illustration of an alternate use of the DirectX libraries. Then they should read Wirth's Oberon book as an example of alternate interfaces and efficiency in design and implementation. Finally, they should get the Plain English development system and work their way through it to further broaden their thinking.
-
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! -
All the startup companies I've ever worked in seemed to be focused on spending money :)
"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! -
The Grand Negus wrote:
Exactly what is it that you want to know?
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.
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
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.
-
I believe you forgot "They should break the project into very, very small features that are to be implemented in 10 minutes per feature".
mbrezu2 wrote:
I believe you forgot "They should break the project into very, very small features that are to be implemented in 10 minutes per feature".
I presume you're being facetious. But actually, I am proposing something like that, though the detail "breakdown" would not be planned and charted and managed except by the programmers themselves. Your statement would then read, and reasonable so, "They should break the project into features, which the programmers - as they work together - will further divide into very, very small testable chunks that can be verified in 10 minutes or less".
-
I wish I had a door I could slam in your face.
-- Please rise for the Futurama theme song
-
Amar Chaudhary wrote:
what are the rules which you follow and think i should also follow
Here are a few things that have worked for us, and that you probably won't hear from anyone else: The programmers should work as a team on a single computer with dual monitors, keyboards, and mice. They should take turns leading and following. The leader gets the mouse; the other types in the appropriate code. They should test as often as possible, typically every ten lines of code (or so). They should start each day with a review of the code, looking very hard for things to delete. Less is more. No new code until something old has been removed, consolidated, or otherwise improved. They should avoid nested IFs and nested LOOPs. They should avoid the wanton use of dialogs, and minimize the number of controls on any interface. But before they begin, they should get a copy of DarkBasic and play with it as an illustration of an alternate use of the DirectX libraries. Then they should read Wirth's Oberon book as an example of alternate interfaces and efficiency in design and implementation. Finally, they should get the Plain English development system and work their way through it to further broaden their thinking.
-
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