ok what are the rules
-
The Grand Negus wrote:
I think it's the term "utility function" that gives the lie to the object approach.
At the end of the day, you still need something to get the work done. It's at the point where it stops being a useful organizing technique and starts to intrude upon my efforts to actually accomplish anything that i abandon OO.
---- I just want you to be happy; That's my only little wish...
-
Shog9 wrote:
but i've no interest in trying to make everything an object.
Good. But how about making everything Plain English? It's the language millions use every day to program their dogs!
But dogs have intelligence whereas computers don't. If you tell a computer to do something stupid it will go off and do the wrong thing at 3 GHz and possibly make a hell of a mess before you can stop it. A dog on the other hand will use his intelligence to read between the lines of your incomplete description (a dog probably wouldn’t understand a more rigid description anyway) and figure out what you actually want as opposed to what you said.
Steve
-
Amar Chaudhary wrote:
now dinosaurs do you believe few floods killed them all or it was there inability to change as you are more experienced than me have you heard of ice age humans survived from it any many more disasters
There's a lot of evidence that the dinosaurs were unable to recover after a watery cataclysm. But it's hard to get good data from so far back. The problem with cataclysms is that organisms perfectly adapted to one environment are often not at all suited to another - like the environment that emerges following a cataclysm. It's like training yourself to be a chess champion and then having to deal with a bully in the park who kicks the board over. As Solomon said, "I have seen under the sun that the race is not always to the swift, nor the battle to the strong, nor bread to the wise, nor riches to men of understanding... but time and chance happens to them all".
Amar Chaudhary wrote:
ok this time my point is the price difference between the two (supporting languages)
I'm not sure what you're asking here. But if you're asking if we can write a program better, faster and cheaper in Plain English than in any other language, the answer is a definite "yes".
The Grand Negus wrote:
we can write a program better, faster and cheaper in Plain English than in any other language, the answer is a definite "yes"
Uh huh, sure :rolleyes:
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 think a moment. English can be used to write anything from a love letter, to a post on CodeProject, to a native-code generating compiler. Why bother with anything else?
For the same reason mathematicians don't: for some purposes English is either too verbose, too vague (open to many interpretation), too hard to manipulate or all three. In a mathematical proof for example there’ll be both English and formal symbolic notation. It’s not a matter of one being better then the other: just that they both have their strengths and weaknesses and you have to know when to use which. It’s similar to the multi-padagram discussion we were having before; when all you've got is a hammer, everything looks like a nail.
Steve
Stephen Hewitt wrote:
In a mathematical proof for example there’ll be both English and formal symbolic notation. It’s not a matter of one being better then the other: just that they both have their strengths and weaknesses and you have to know when to use which.
Agreed. But note something important here. The framework of such a proof is almost always a natural language, like English. The formulae are written in a specialized sub-language of the natural language. In other words, English is "bigger" than mathematical notation. Not better, bigger. It's easy, for example, to think of American English including the way Americans typically write numbers or simple equations - it's hard to imagine the reverse. And that's what we're proposing regarding Plain English (and which we've spelled out in other places). Our Plain English Machine, the PAL 3000, will understand not only English, but various forms of formulae and other programming languages as well. But the machine's native tongue will be English. And we're emphasizing this part of the problem because, frankly, the other parts (how to parse equations and compile C#) have already been solved.
-
But dogs have intelligence whereas computers don't. If you tell a computer to do something stupid it will go off and do the wrong thing at 3 GHz and possibly make a hell of a mess before you can stop it. A dog on the other hand will use his intelligence to read between the lines of your incomplete description (a dog probably wouldn’t understand a more rigid description anyway) and figure out what you actually want as opposed to what you said.
Steve
Stephen Hewitt wrote:
If you tell a computer to do something stupid it will go off and do the wrong thing at 3 GHz and possibly make a hell of a mess before you can stop it. A dog on the other hand will use his intelligence to read between the lines of your incomplete description (a dog probably wouldn’t understand a more rigid description anyway) and figure out what you actually want as opposed to what you said.
Not always. When I was a kid, the drummer in our band liked to put a speaker at one end of a room, grab a microphone, and stand at the other end of the room: then call his dog. The poor beast would run in circles (at 3 Hz) in the middle of the room until one of the other band members would take pity and turn off the amplifier. What you say is a matter of degree, not kind. Our compiler, in many situations, can figure out what you actually want as opposed to what you said even in its current incarnation. For example, if you say "Draw a circle at the screen" instead of "on the screen", it will figure it out. If you tell it to draw a "frame", it will reduce "frame" to "rectangle" and call the appropriate routine. If you fail to specify a color, it will pick its favorite - not unlike a kid.
-
...and thinking about the inspiring prose you used to describe your proposed wall between the VB and C# forums: Were you home schooled? Or did you just play Zork a lot?
The Grand Negus wrote:
Were you home schooled? Or did you just play Zork a lot?
Can't it be both? ;) Yeah, i was homeschooled, and as a result of this spent a lot of time reading pretty much everything i could get my hands on, which gives me a fairly large amount of source material to draw on when i'm in the mood to goof off a bit. I don't consider myself a particularly good writer, of course - it takes me far, far too long to put my thoughts down, and a lot of editing before i'm ever happy with it. Still, i can put out some entertaining documentation on occasion...
---- I just want you to be happy; That's my only little wish...
-
Stephen Hewitt wrote:
In a mathematical proof for example there’ll be both English and formal symbolic notation. It’s not a matter of one being better then the other: just that they both have their strengths and weaknesses and you have to know when to use which.
Agreed. But note something important here. The framework of such a proof is almost always a natural language, like English. The formulae are written in a specialized sub-language of the natural language. In other words, English is "bigger" than mathematical notation. Not better, bigger. It's easy, for example, to think of American English including the way Americans typically write numbers or simple equations - it's hard to imagine the reverse. And that's what we're proposing regarding Plain English (and which we've spelled out in other places). Our Plain English Machine, the PAL 3000, will understand not only English, but various forms of formulae and other programming languages as well. But the machine's native tongue will be English. And we're emphasizing this part of the problem because, frankly, the other parts (how to parse equations and compile C#) have already been solved.
The Grand Negus wrote:
The framework of such a proof is almost always a natural language, like English.
In my experience (some maths at University before I switched to computers) this isn't the case: the English spells out a vague high level description of the problem and highlights points of interest, cites references and such. The actual body of the proof is in symbolic notation. In mathematics this is almost always the case.
Steve
-
The Grand Negus wrote:
we can write a program better, faster and cheaper in Plain English than in any other language, the answer is a definite "yes"
Uh huh, sure :rolleyes:
If you try to write that in English, I might be able to understand more than a fraction of it. - Guffa
PaulC1972 wrote:
The Grand Negus wrote: we can write a program better, faster and cheaper in Plain English than in any other language, the answer is a definite "yes" Uh huh, sure
Well, we should know since we've written major programs in various assembler languages, in Fortran, COBOL, Pascal, Prolog, LISP, C, C++, C#, a number of our own languages, and Plain English. And Plain English is our language of choice. Not because we invented it, but because of all the languages we've used, it works the best. Think a minute - if it didn't work the best, we wouldn't have released it, like we didn't release the other five languages we developed over the years. When those languages proved to be only marginally better (or sometimes even worse), we went back to the drawing board.
-
Shog9 wrote:
but i've no interest in trying to make everything an object.
Good. But how about making everything Plain English? It's the language millions use every day to program their dogs!
The Grand Negus wrote:
But how about making everything Plain English?
To be honest, I wouldn't mind taking a look. But then, there are at least two other languages on my "idle time todo list" already, and they've both taking a back seat to other things lately (i'm baking bread right now; somehow, that's more satisfying today ;) ).
---- I just want you to be happy; That's my only little wish...
-
PaulC1972 wrote:
The Grand Negus wrote: we can write a program better, faster and cheaper in Plain English than in any other language, the answer is a definite "yes" Uh huh, sure
Well, we should know since we've written major programs in various assembler languages, in Fortran, COBOL, Pascal, Prolog, LISP, C, C++, C#, a number of our own languages, and Plain English. And Plain English is our language of choice. Not because we invented it, but because of all the languages we've used, it works the best. Think a minute - if it didn't work the best, we wouldn't have released it, like we didn't release the other five languages we developed over the years. When those languages proved to be only marginally better (or sometimes even worse), we went back to the drawing board.
The Grand Negus wrote:
of all the languages we've used, it works the best
Can it solve a problem like the Traveling Salesman Problem in the worst case scenario, in linear time complexity?
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:
The framework of such a proof is almost always a natural language, like English.
In my experience (some maths at University before I switched to computers) this isn't the case: the English spells out a vague high level description of the problem and highlights points of interest, cites references and such. The actual body of the proof is in symbolic notation. In mathematics this is almost always the case.
Steve
Stephen Hewitt wrote:
In my experience (some maths at University before I switched to computers) this isn't the case: the English spells out a vague high level description of the problem and highlights points of interest, cites references and such. The actual body of the proof is in symbolic notation. In mathematics this is almost always the case.
You've got to be misunderstanding what I mean by framework. Let's try a different example. In what language are all the articles on this site written? C? C++? C#? VB? No! They're all written in English with examples written in these sub-languages. Back to the other example. My calculus book is written in English. It is not a German calculus book, it is an English calculus book, though it probably contains the same or similar formulae. The "framework" is English: the title, the preface, the chapter headings, the introductions, the explanations of the formulae, the problem statements, etc.
-
The Grand Negus wrote:
But how about making everything Plain English?
To be honest, I wouldn't mind taking a look. But then, there are at least two other languages on my "idle time todo list" already, and they've both taking a back seat to other things lately (i'm baking bread right now; somehow, that's more satisfying today ;) ).
---- I just want you to be happy; That's my only little wish...
Shog9 wrote:
i'm baking bread right now; somehow, that's more satisfying today ).
Well, at least the bread isn't baking itself! But how about that dog analogy? Why don't people use, say, C# to program their dogs? Why do they always just go for the thing they know best?
-
The Grand Negus wrote:
of all the languages we've used, it works the best
Can it solve a problem like the Traveling Salesman Problem in the worst case scenario, in linear time complexity?
If you try to write that in English, I might be able to understand more than a fraction of it. - Guffa
PaulC1972 wrote:
Can it solve a problem like the Traveling Salesman Problem in the worst case scenario, in linear time complexity?
As far as I know, that's an unsolved problem in any language. But a Plain English solution to the problem will be as good as any other - and definitely easier to read (even without comments!).
-
PaulC1972 wrote:
Can it solve a problem like the Traveling Salesman Problem in the worst case scenario, in linear time complexity?
As far as I know, that's an unsolved problem in any language. But a Plain English solution to the problem will be as good as any other - and definitely easier to read (even without comments!).
The Grand Negus wrote:
a Plain English solution to the problem will be as good as any other - and definitely easier to read
Let's see it then.
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:
a Plain English solution to the problem will be as good as any other - and definitely easier to read
Let's see it then.
If you try to write that in English, I might be able to understand more than a fraction of it. - Guffa
-
Shog9 wrote:
i'm baking bread right now; somehow, that's more satisfying today ).
Well, at least the bread isn't baking itself! But how about that dog analogy? Why don't people use, say, C# to program their dogs? Why do they always just go for the thing they know best?
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...
-
- Get a grip on the logic of what you are trying to accomplish before you start. ie. Understand exactly what it is you are trying to accomplish
- Use the right tool for the job. Ignore anyone who says you *must* use such-and-such a tool or technique.
- Learn the concepts of programming. Memory management, design patterns, organising your code into the correct peices (objects, procedures, files, namespaces)
- Understand the concepts of the technology you are using. Object oriented, web based, crazy anonymous functions. Learn the tools.
- Write pretty code. Forcing yourself to write good looking code will force you to take a look at the structure, the comments, the way it's broken up, and as a consequence it will be easier for someone else to read and check
- Write comments in code. Relevant comments. Lots of useful, relevant comments.
- Learn to test and debug
- Learn how to rip chunks out of your code and replace it as the specs change. And they will change. Never, ever believe that there is such a thing as a final spec sheet.
- Keep learning.
- Be good to your Mother.
cheers, Chris Maunder
CodeProject.com : C++ MVP
Chris Maunder wrote:
5. Write pretty code. Forcing yourself to write good looking code will force you to take a look at the structure, the comments, the way it's broken up, and as a consequence it will be easier for someone else to read and check
Right on! I am amazed by the seeming vast majority of so-called "software engineers" who don't understand the importance of this. :mad:
Matt Gerrans
-
Chris Maunder wrote:
5. Write pretty code. Forcing yourself to write good looking code will force you to take a look at the structure, the comments, the way it's broken up, and as a consequence it will be easier for someone else to read and check
Right on! I am amazed by the seeming vast majority of so-called "software engineers" who don't understand the importance of this. :mad:
Matt Gerrans
Matt Gerrans wrote:
I am amazed by the seeming vast majority of so-called "software engineers" who don't understand the importance of this.
Could it be that management or bosses pressure them away from writing pretty code?
If you try to write that in English, I might be able to understand more than a fraction of it. - Guffa
-
Stephen Hewitt wrote:
In my experience (some maths at University before I switched to computers) this isn't the case: the English spells out a vague high level description of the problem and highlights points of interest, cites references and such. The actual body of the proof is in symbolic notation. In mathematics this is almost always the case.
You've got to be misunderstanding what I mean by framework. Let's try a different example. In what language are all the articles on this site written? C? C++? C#? VB? No! They're all written in English with examples written in these sub-languages. Back to the other example. My calculus book is written in English. It is not a German calculus book, it is an English calculus book, though it probably contains the same or similar formulae. The "framework" is English: the title, the preface, the chapter headings, the introductions, the explanations of the formulae, the problem statements, etc.
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
-
Okay. Send me a version in some other language that you think is good - and hopefully short - and we'll get you the Plain English equivalent.
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