ok what are the rules
-
The original example was mathematical proofs which are – for the most part – symbolic. While your calculus book will have lots of English text the real guts (such as the chain rule, the product rule and the proofs) will be symbolic. Not to diminish English as it plays an important, but no mathematician wants to do his math in English. Take algebra for example: this is a set of rules which allows one to mechanically manipulate a symbolic equation to produce another. An example is the distributive law which stated symbolically looks something like this: a*(b+c) = a*b + a*c This means if I have: 6*107 I can use this rule as follows: 6*107 = 6*(100+7) = 6*100+6*7 = 600+42 = 642 Such rules can be stated in English but doing so is of little help.
Steve
Stephen Hewitt wrote:
Not to diminish English as it plays an important, but no mathematician wants to do his math in English.
I'm not saying - and never did say - that a mathematician would. I'm saying that when a mathematician wants to explain or expound upon his work, he almost always uses a natural language to do so. I'm saying that natural language came first and will not be replaced with artificial languages - augmented, to be sure, but not replaced. You seem to be under the impression that we don't want our PAL 3000 to be able to solve equations. Not so. But as I said in an earlier post, that problem has already been addressed. We just make sure he's got Wolfram's Mathematica on the disk and say, "Solve this problem, PAL," supplying the necessary equations and values. But note that the "interface", if you will, the "Solve this problem, PAL" part - like the text surrounding what you think of as the "important parts" of a math book - is just Plain English.
-
The original example was mathematical proofs which are – for the most part – symbolic. While your calculus book will have lots of English text the real guts (such as the chain rule, the product rule and the proofs) will be symbolic. Not to diminish English as it plays an important, but no mathematician wants to do his math in English. Take algebra for example: this is a set of rules which allows one to mechanically manipulate a symbolic equation to produce another. An example is the distributive law which stated symbolically looks something like this: a*(b+c) = a*b + a*c This means if I have: 6*107 I can use this rule as follows: 6*107 = 6*(100+7) = 6*100+6*7 = 600+42 = 642 Such rules can be stated in English but doing so is of little help.
Steve
Let me say one other thing that most "programmers" don't seem to be aware of. Most programs contain very little math, proportionately speaking. I doubt if 10% our program, for example, is mathematical in any sense of the word - and we display menus, add, delete, and rename files, edit pages, compile programs, etc. So it seems odd to us that programming languages should be based on mathematical notation. Include it, yes, but not be based on it.
-
Stephen Hewitt wrote:
Not to diminish English as it plays an important, but no mathematician wants to do his math in English.
I'm not saying - and never did say - that a mathematician would. I'm saying that when a mathematician wants to explain or expound upon his work, he almost always uses a natural language to do so. I'm saying that natural language came first and will not be replaced with artificial languages - augmented, to be sure, but not replaced. You seem to be under the impression that we don't want our PAL 3000 to be able to solve equations. Not so. But as I said in an earlier post, that problem has already been addressed. We just make sure he's got Wolfram's Mathematica on the disk and say, "Solve this problem, PAL," supplying the necessary equations and values. But note that the "interface", if you will, the "Solve this problem, PAL" part - like the text surrounding what you think of as the "important parts" of a math book - is just Plain English.
The Grand Negus wrote:
I'm saying that when a mathematician wants to explain or expound upon his work, he almost always uses a natural language to do so.
No, he doesn’t. He might explain what he’s trying to do and name some techniques he’ll be using and even give a broad description of how he’ll proceed. Them he’ll do the real work symbolically. Without the symbolic stuff you’ve got nothing. This is how 99% of mathematics is done.
Steve
-
Let me say one other thing that most "programmers" don't seem to be aware of. Most programs contain very little math, proportionately speaking. I doubt if 10% our program, for example, is mathematical in any sense of the word - and we display menus, add, delete, and rename files, edit pages, compile programs, etc. So it seems odd to us that programming languages should be based on mathematical notation. Include it, yes, but not be based on it.
This is true; most programs contain very little math. But we're straying a little here: math was just used as an example of one place where a formal symbolic notation is superior to English.
Steve
-
It is thoroughly described by wikipedia[^] and you can find plenty of implementations with Google, for example this Python library[^] contains an example. More to the point, why don't you add your Plain English implementations (and stats) to The Great Win32 Computer Language Shootout[^]? Or at least, if the travelling salesman problem seems like too much work, there are several easier choices at this site that you could use and whose solutions should be small enough to post in this forum.
Matt Gerrans
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?
-
This is true; most programs contain very little math. But we're straying a little here: math was just used as an example of one place where a formal symbolic notation is superior to English.
Steve
Stephen Hewitt wrote:
But we're straying a little here: math was just used as an example of one place where a formal symbolic notation is superior to English.
And we don't disagree with that. "A picture is worth a thousand words" - sometimes. Who can deny it? Let me sum up then, and perhaps we can agree. There are many ways to communicate thoughts between beings. Specialized languages, pictures, diagrams, etc. And - of course - natural languages. In any given case, there is typically an optimal choice. To let you know what my wife looks like, I'd probably use a picture; to enumerate the needed groceries, I'd probably use a list of words and phrases. Sometimes one, sometimes another. We're trying to build a machine that will, among other things, answer questions - any kind of questions. From "What does Paul Simon look like?" to "How many cubic yards of concrete in a 25 by 50 slab, 4 inches thick?" Now we all know how to program a computer to fetch a picture from the internet. And we all know how program a computer to do a bit of calculation. The part that is missing is the part that hears the question, parses it, and calls the appropriate lower-level routine (which might be written in C, or Plain English, or assembler). That's the part we're working on. The part that hears the question, parses it, and calls the appropriate routine.
-
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.