Natural Language Programming

[MagnusTheBrewer]

Based on your comments in this thread, you seem to have almost no knowledge of modern programming aside from a bit of javascript. You're certainly entitled to your opinion that it's "off track", but people aren't going to take you seriously when you literally don't know what you're talking about.



As Mark has already mentioned a few times, your quasi-evangelical response to criticism isn't helping you at all. We went through my complaints with your editor back when the topic was first posted; I don't think rehashing them will accomplish anything. IIRC, you basically dismissed all of them with some variation of you just don't understand.

Second rule of proselytizing:
Focus on your message.
Never define your points in terms of another viewpoint.
Never debate the merits of a differing argument.
Focus on your message.

 

[Gerry Rzeppa]

Gerry, what some random people have said means nothing.

Are you referring to the people on this forum, or to the people I quoted above? I've never met any of either group face-to-face. But the latter group actually took the time to write to me personally, so I can't help but weigh their responses more seriously.

Very first name on your list... A center in the NBA. http://lmgtfy.com/?q=aaron+gray

Surely you can imagine that more than one person in the world is named Aaron Gray.

The second quote seems as if someone was willing to invest. Obviously, they didn't.

And he was. At the time, we didn't need the money so we politely turned him down.

You've yet to produce anything beyond "do this" or "write that" code samples and still haven't shown any insight into real world problems having to handle this.

That's nonsense. Wysiwyg page editors and native-code generating compilers are real world applications. I posted the first 120 lines of our page editor a little way back in this very thread ; and all 25,000 lines of our source code -- include the whole of that page editor, plus the interface described above, plus our file manager, hex dumper, text editor, and native-code generating compiler -- are readily available for the asking: gerry.rzeppa@pobox.com

You also seem to be against OO...

Yes. Hiding verbs inside nouns make no linguistic sense at all. And other flaws of the object paradigm are well documented elsewhere (see, for example, http://harmful.cat-v.org/software/OO_programming/why_oo_sucks).

...and coupling an abandonment of OO with verbose paragraphs to describe things in sentences, your code on a real project is going to be unmanageable.

If that were true, we would have found our 25,000-line Plain English system unmanageable. Yet we didn't. So between our very own first-hand experience with the idea, and your surmisings from a distance, I'm going to have to stick with the first-hand experience.

Debugging is just incredibly painful when I have to read Moby Dick to find out where something happens and where I should change it.

Then it's a good thing nobody has to read Moby Dick to maintain programs. Plain English programmers included. Again, I'm going to have to stick with the first-hand experience: we've found programming in Plain English to be easy, natural, and fun.

 

[Gerry Rzeppa]

Second rule of proselytizing:
Focus on your message.
Never define your points in terms of another viewpoint.
Never debate the merits of a differing argument.
Focus on your message.

It sounds like you don't approve of people like this guy:

http://www.huffingtonpost.com/2014/04/17/guy-kawasaki_n_5155364.html

Personally, I think it's quite natural to want to share "good news" with others. Especially when it's free and can easily be ignored by anyone who isn't interested.

 

[LevelSea]

Yes. Hiding verbs inside nouns make no linguistic sense at all. And other flaws of the object paradigm are well documented elsewhere (see, for example, http://harmful.cat-v.org/software/OO_programming/why_oo_sucks).

That article is a load of horsesh*t for various, well documented reasons as well.

Not to mention he was trolling to begin with.

So if your question is about what I think about object oriented programming, I sort of changed my mind over that. I wrote a an article, a blog thing, years ago - Why object oriented programming is silly. I mainly wanted to provoke people with it. They had a quite interesting response to that and I managed to annoy a lot of people, which was part of the intention actually.

http://www.infoq.com/interviews/johnson-armstrong-oop

 

[Merad]

Personally, I think it's quite natural to want to share "good news" with others. Especially when it's free and can easily be ignored by anyone who isn't interested.

Then I encourage you again to post about this on r/programming and/or Hacker News. From what I can tell, this discussion thread is the only place you've been promoting natural english. If you are serious about your funding project, then you a lot more visibility.

 

[Gerry Rzeppa]

I encourage you again to post about this on r/programming and/or Hacker News.

As I mentioned before, I referenced this thread on reddit about a month ago. I've done the same on Hacker News now, as well. Anyone who is interested can (1) read the above discussion, and (2) comment here. No need for any of us to repeat what has already been said.

 

[Gerry Rzeppa]

That article [http://harmful.cat-v.org/software/OO_programming/why_oo_sucks] is a load of horsesh*t for various, well documented reasons as well.

If you're a fan of object-oriented programming, Plain English isn't for you. Our language is built around Niklaus Wirth's procedural paradigm (Algorithms + Data Structures = Programs, http://www.amazon.com/dp/0130224189), and that paradigm has proven sufficient for all our needs. If it ain't broke, why fix it?

 

[Markbnj]

Since you referenced this thread on HN, I guess for completeness the HN thread should be referenced here.

https://news.ycombinator.com/item?id=8719957

 

[MagnusTheBrewer]

It sounds like you don't approve of people like this guy:

http://www.huffingtonpost.com/2014/04/17/guy-kawasaki_n_5155364.html

Personally, I think it's quite natural to want to share "good news" with others. Especially when it's free and can easily be ignored by anyone who isn't interested.

For the eleventyith time, it's not the message (which can be debated on it's own merits or, lack thereof) it's the manner it which it's presented. Maybe you should find a spokesperson who's a little less...preachy? Sincerity has it's own quality and doesn't benefit from trained zealousness.

 

[Gerry Rzeppa]

Didn't realize I had missed this earlier post.

Consider this line from one of Gerry's posts:
"Draw the substring in the box with the color and the source's text's font and the source's text's alignment."
20 [correction, 19] words

In most programming languages this would be expressed in a manner like:
box.draw(substring, color, font, alignment)
6 words

Actually, in most programming languages the equivalent would be something like:

substring.draw ( box, color, source.text.font, source.text.alignment ) ;

Which is 10 words and 11 punctuation marks: 21 total elements.

And the Plain English could be shortened to:

Draw the substring in the box with the color and the source's text's font and alignment.

Which is 16 words and 3 punctuation marks: 19 total elements.

Admittedly, the Plain English version requires a few more easy-to-type alphabetic characters (it's difficult to say exactly how many since traditional coders put spaces in different places); but that's a small price to pay for not having to learn (or think in) an artificial syntax.

Or another example:
If the source's colorized flag is not set, put the black color into the color.
15 words

In a typical programming language:
if (!source.colorized()) color = black
5 words

This time we've got:

if ( ! source.colorized ( ) ) color = black ;

Which is 5 words and 8 punctuation marks: 13 total elements.

Compared with the Plain English, which could be shortened to:

If the source is not colorized, put black into the color.

Which is 11 words and 2 punctuation marks: 13 total elements.

Again, it's mostly a matter of whether you like to type words or punctuation. And whether you like to think in two different syntactical and grammatical forms simultaneously. And whether you want your code to be self-documenting. And whether you want code that's friendly for beginners. And whether you want to code in a language (like English) that will still be in common use 100 years from now.

Personally, I think you've lost some human perspective if you think "if (!source.colorized())" is a good way of saying anything. Now let me make sure I've got the right number and kind of parentheses in there before I post this...

 

[PhatoseAlpha]

Using "If the source is not colorized, put black into the color." is only reasonably an advantage if you could also say "Unless the source is colorized, make the color black" or "Use black as the color unless the source is colorized."

If you can't, the plain-english approach is a bad idea, since it gives outside observers the impression it's functionally a natural language, when it's not. "if (!source.colorized())" at least makes it clear it's not natural language, and there are specific rules of syntax.

 

[Gerry Rzeppa]

Using "If the source is not colorized, put black into the color." is only reasonably an advantage if you could also say "Unless the source is colorized, make the color black" or "Use black as the color unless the source is colorized."

Actually, you can say those kind of things in Plain English. It's a language that grows with use. The compiler focuses on articles, prepositions, conjunctions and some common state verbs (like IS, ARE, and WAS) in its parsing; almost all of the remainder of the vocabulary and grammar is defined by the programmer. When a statement is not understood, the compiler responds with "I don't know how to ..." (with the ellipsis here representing the sentence in question). The programmer can then either (a) reword the sentence, or (b) create a routine to process that kind of sentence, thus increasing the scope of the language.

If you can't, the plain-english approach is a bad idea, since it gives outside observers the impression it's functionally a natural language, when it's not.

I don't see why it matters if an "outside observer" (perhaps the user of a system verifying that it is up to spec by examining the code in crucial routines) thinks Plain English is a complete natural language or just a subset thereof: either way, if the code does what it says it does, the matter is settled. On the other hand, "insiders" (ie, programmers) quickly learn what Plain English is (and is not) capable of and, as above, quickly learn how to expand its capabilities.

"if (!source.colorized())" at least makes it clear it's not natural language, and there are specific rules of syntax.

There's no doubt that "if (!source.colorized())" is unnatural for people who speak and write English. Exclamation points in English are used for emphasis, not negation. And parentheses are used to enclose things; if there's nothing to enclose they shouldn't be required. Not to mention the fact that humans are inherently bad at matching up opening and closing delimiters, especially when they're nested.

But we agree that sometimes it's more convenient (or even necessary) to use an artificial syntax to express certain kinds of thoughts. Plain English allows this now with routines like this one (that combines English and Intel machine code in a single sentence):

To add a number to another number: Intel $8B85080000008B008B9D0C0000000103.

And our proposed Hybrid version of the language will extend this ability to other specialized syntaxes. And example from a few posts back is this:

To convert a fahrenheit temp to a celsius temp: c=(f-32)*5/9

Experience, however, tells us that most of what most programs do doesn't fall into the "special syntax" category; most programs, most of the time, do things like "Move this over there" or "Draw that on the screen" or "Save something to the disk": thoughts that are most conveniently expressed in a natural language. We thus propose that the "ideal" programming language would consist of a natural language framework, with snippets of special syntax (and even graphics) as required. Our proposal for further research into this topic can be found here:

I let you post one link to the indiegogo project. No more of them.

Markbnj

 

[werepossum]

That's a fair assessment, from my perspective. Keep in mind, though, that while we believe that most of of what most programs do can be most easily written in a natural language syntax, we are just as certain that some things programmers want to say can be more easily expressed in formulas, or graphics, etc. Which is why we propose "Hybrid Programming" as the next step in our research:

https://www.indiegogo.com/projects/the-hybrid-programming-language/x/8950932

Here, for example, is a Plain English fahrenheit to celsius converter as a kid might code it:

To convert a fahrenheit temp to a celsius temp:
Put the fahrenheit temp into the celsius temp.
Subtract 32 from the celsius temp.
Multiply the celsius temp by 5.
Divide the celsius temp by 9.

And here it is as an experienced Plain English programmer might code it. Note the use of nicknames (eg, "celsius" for "celsius temp"), and that mathematical precedence is strictly left-to right in Plain English):

To convert a fahrenheit temp to a celsius temp:
Put the fahrenheit minus 32 times 5 divided by 9 into the celsius.

Since ratios are a standard numerical type in Plain English, the programmer could also have said:

To convert a fahrenheit temp to a celsius temp:
Put the fahrenheit minus 32 times 5/9 into the celsius.

Where 5/9 is a ratio, not a division instruction. All of those versions actually compile and run.

Now here is the obvious Hybrid version, with the routine header (which also serves as a comment) in Plain English, and the calculation in standard "computer dialect" mathematical notation:

To convert a fahrenheit temp to a celsius temp: c=(f-32)*5/9

Note that the Hybrid compiler assumes letter names for the variables based on their full Plain English names. If other names were desired or a naming conflict arose, the programmer could either use the Plain English names, like this:

To convert a fahrenheit temp to a celsius temp: celsius=(fahrenheit-32)*5/9

Or the programmer could explicitly assign short names to the variables:

To convert a fahrenheit temp to a celsius temp:
Let x = the fahrenheit temp.
Let y = the celsius temp.
y=(x-32)*5/9

This last approach would only be worthwhile, of course, when the formula was complex enough to justify the required variable definitions above it.

Our thought is that the programmer should be able to write the solution as it most naturally occurs to him or her, without really thinking about syntax. We believe Plain English is a big step in that direction, and that Hybrid Programming is the next logical step after that. Note that it's relatively trivial to add "special syntax snippets" to a Plain English compiler; it's a much bigger deal to extend, say, a C++ compiler to support a Plain English framework.

I agree that most parts of most programs could be handled in Plain English, and that with the addition of Hybrid Programming you could do pretty much what any high level language could do. Problem is, at that level you essentially have to teach it as any other programming language, with no really obvious advantages. (Or more properly, without a clear and obvious plurality of advantages over disadvantages.)

Then I encourage you again to post about this on r/programming and/or Hacker News. From what I can tell, this discussion thread is the only place you've been promoting natural english. If you are serious about your funding project, then you a lot more visibility.

In my opinion he'd be better off hitting education forums. Programmers don't need the advantages - in fact, they'd just be learning a completely different way of programming, and the easy stuff at which Plain English excels is beyond trivial for you guys. Writing a very simple program is going to be trivial for any programmer except for hardware issues, and if anything that's going to be worse in Plain English. (Imagine trying to textually describe allowing for various possible screen resolutions or optimizing for a wide range of hardware characteristics and power.)

In contrast, educators are always looking for a different way to do things, and better can take a back seat if it's marketable. A system which allows kids to get almost immediate results will be attractive - although as someone mentioned, powerful graphical interfaces may already have made Plain English less relevant. Twenty years ago it might have been revolutionary; today similar results can be obtained in Chrome, Excel, etc. depending on task and even phones are expected to have beautiful graphical interfaces before any work gets done. We expect our programs and OS's to already know how to convert between Celsius and Fahrenheit for us, or how to draw something on the screen if we're creating a web site.

 

[Gerry Rzeppa]

We expect our programs and OS's to already know how to convert between Celsius and Fahrenheit...

I just typed "Convert 32f to c" into Google and got the appropriate response. Which is cool (and I don't just mean temperature-wise). Lots of other variations work as well: from the wordiest "covert 32 degrees fahranhitet into degrees celcius" (including three misspellings) to the briefest "32f to c".

Our thought is simply this: since billions of Google users, young and old, from all walks of life, can tell computers what to do just by typing in what they're thinking, why shouldn't both novice and professional programmers be able to do the same? Why should a programmer be forced to translate each and every one of his thoughts into a peculiar, restricted, unnatural, and esoterically artificial syntax?

PS. We're fine with Google getting there before we do. If they could make their "Go" language as friendly as their search, that would be great for everybody. Maybe somebody from Google will stumble on this post and finally make the connection. Hello? Larry? Sergey? Is this thing on?

 

[Spungo]

In contrast, educators are always looking for a different way to do things, and better can take a back seat if it's marketable. A system which allows kids to get almost immediate results will be attractive - although as someone mentioned, powerful graphical interfaces may already have made Plain English less relevant. Twenty years ago it might have been revolutionary; today similar results can be obtained in Chrome, Excel, etc. depending on task and even phones are expected to have beautiful graphical interfaces before any work gets done. We expect our programs and OS's to already know how to convert between Celsius and Fahrenheit for us, or how to draw something on the screen if we're creating a web site.

Plain English seems like it could be a good education tool if it simply copied VB or C but changed some of the words. For starters, remove the capitalization from VB. Why Does Every Command Need To Be Capitalized? That makes me type maybe 1/10th as fast, and my left pinky finger gets tired. That alone stops me from attempting to learn VB.
An interesting development over the last 20 years is that all young people know some HTML and forum code syntax, and it finds its way into regular internet writing. How many times have you seen people write something like "/s" to indicate "end of sarcasm". That could be part of a language for kids. VB has things like "End Sub" which could more easily be written as "/sub". IIRC, Ruby goes half way by still using something like "end sub" but it's not capitalized.

Gerry, would you consider adding XAML/WPF support to your IDE? That would be an excellent selling point. WPF is sort of a bitch to learn, so it would be nice if the code behind it were something simple. C# isn't really "simple" unless you've seen C-like syntax before. Kids could focus their efforts on GUI design instead of coding.

 

[Cogman]

I just typed "Convert 32f to c" into Google and got the appropriate response. Which is cool (and I don't just mean temperature-wise). Lots of other variations work as well: from the wordiest "covert 32 degrees fahranhitet into degrees celcius" (including three misspellings) to the briefest "32f to c".

Our thought is simply this: since billions of Google users, young and old, from all walks of life, can tell computers what to do just by typing in what they're thinking, why shouldn't both novice and professional programmers be able to do the same? Why should a programmer be forced to translate each and every one of his thoughts into a peculiar, restricted, unnatural, and esoterically artificial syntax?

PS. We're fine with Google getting there before we do. If they could make their "Go" language as friendly as their search, that would be great for everybody. Maybe somebody from Google will stumble on this post and finally make the connection. Hello? Larry? Sergey? Is this thing on?

Want to get in contact with them? It is surprisingly easy. If you want them to tell you why your idea is terrible feel free to just ask them on the mailing list.

https://groups.google.com/forum/#!forum/golang-nuts

They peruse it pretty frequently. But be warned, spewing long winded rants about the superiority of your idea over everything else will likely get you banned, laughed at, and ignored.

 

[Squeetard]

"Wouldn't it be cool if we could write programs just like typing a novel".

Yes, it would. Good luck with that.

PS: LOL.

 

[Gerry Rzeppa]

For starters, remove the capitalization from VB. Why Does Every Command Need To Be Capitalized? That makes me type maybe 1/10th as fast, and my left pinky finger gets tired. That alone stops me from attempting to learn VB.

From page 12 of our manual (www.osmosian.com/instructions.pdf) where the compiler is speaking for himself: "I don't care if you type in upper, lower, or mixed case. It's all the same to me. Life is hard enough without some JAVA programmer making it harder."

VB has things like "End Sub" which could more easily be written as "/sub". IIRC, Ruby goes half way by still using something like "end sub" but it's not capitalized.

Plain English doesn't need "block delimiters". No paired braces (like "{" and "}"). No "end sub"s. Etc. They're simply not necessary. For example:

To run:
Start up.
Write "Hello, world!" in the middle of the screen.
Shut down.

The routine begins with the "T" in "To" and ends with the period after the word "down". No artificial block delimiters required.

Gerry, would you consider adding XAML/WPF support to your IDE? That would be an excellent selling point. WPF is sort of a bitch to learn...

Why would we want to add something to our IDE that's "a bitch to learn"?

C# isn't really "simple" unless you've seen C-like syntax before.

You got that right. It's not only an artificial syntax, it's an ugly and unintuitive artificial syntax.

Kids could focus their efforts on GUI design instead of coding.

They can do that right now with Plain English. And they can study the very interface they're using to create their Plain English programs with, since that, too, is coded entirely in Plain English.

 

[Gerry Rzeppa]

"Wouldn't it be cool if we could write programs just like typing a novel". Yes, it would. Good luck with that. PS: LOL.

"A journey of a thousand miles begins with a single step." As it says in our somewhat overly-optimistic but nevertheless sound manifesto (www.osmosian.com/manifesto.pdf), "We offer our Plain English compiler as both proof of concept and a first step in the right direction." Not the final solution. Good God, Squeetard! Do you really want to be known as a person who discourages others from dreaming? and from chasing after their dreams?

Stop and think a moment. What does a program do? It tells a computer to do something. And that means when somebody with an iPhone tells SIRI to do something, and SIRI does it, that person has actually written a program -- just by saying what was on their mind. When a person asks Google to "convert 32f to c", and Google does, that person has written a program -- in the words that first came to mind. We're already writing programs in our native tongues. "Writing programs just like typing a novel" is not a pipe-dream; it's a reality that's just around the corner. See here (http://blog.wolfram.com/2010/11/16/programming-with-natural-language-is-actually-going-to-work/) for another "dreamer" who has caught the vision.

 

[werepossum]

I just typed "Convert 32f to c" into Google and got the appropriate response. Which is cool (and I don't just mean temperature-wise). Lots of other variations work as well: from the wordiest "covert 32 degrees fahranhitet into degrees celcius" (including three misspellings) to the briefest "32f to c".

Our thought is simply this: since billions of Google users, young and old, from all walks of life, can tell computers what to do just by typing in what they're thinking, why shouldn't both novice and professional programmers be able to do the same? Why should a programmer be forced to translate each and every one of his thoughts into a peculiar, restricted, unnatural, and esoterically artificial syntax?

PS. We're fine with Google getting there before we do. If they could make their "Go" language as friendly as their search, that would be great for everybody. Maybe somebody from Google will stumble on this post and finally make the connection. Hello? Larry? Sergey? Is this thing on?

I think that's definitely the wave of the future as it empowers people without requiring knowledge. (Although I've also read some interesting arguments about why that is a bad thing.) It doesn't necessarily mean that the programming will be done in natural language, but after enough functions have been programmed in and the computer learns enough predictive ability, simply typing or speaking in one's native language will essentially write the desired program on the fly.

Plain English seems like it could be a good education tool if it simply copied VB or C but changed some of the words. For starters, remove the capitalization from VB. Why Does Every Command Need To Be Capitalized? That makes me type maybe 1/10th as fast, and my left pinky finger gets tired. That alone stops me from attempting to learn VB.
An interesting development over the last 20 years is that all young people know some HTML and forum code syntax, and it finds its way into regular internet writing. How many times have you seen people write something like "/s" to indicate "end of sarcasm". That could be part of a language for kids. VB has things like "End Sub" which could more easily be written as "/sub". IIRC, Ruby goes half way by still using something like "end sub" but it's not capitalized.

Gerry, would you consider adding XAML/WPF support to your IDE? That would be an excellent selling point. WPF is sort of a bitch to learn, so it would be nice if the code behind it were something simple. C# isn't really "simple" unless you've seen C-like syntax before. Kids could focus their efforts on GUI design instead of coding.

That's an excellent idea. If you're trying to teach kids, leverage what they already know.

"A journey of a thousand miles begins with a single step." As it says in our somewhat overly-optimistic but nevertheless sound manifesto (www.osmosian.com/manifesto.pdf), "We offer our Plain English compiler as both proof of concept and a first step in the right direction." Not the final solution. Good God, Squeetard! Do you really want to be known as a person who discourages others from dreaming? and from chasing after their dreams?

Stop and think a moment. What does a program do? It tells a computer to do something. And that means when somebody with an iPhone tells SIRI to do something, and SIRI does it, that person has actually written a program -- just by saying what was on their mind. When a person asks Google to "convert 32f to c", and Google does, that person has written a program -- in the words that first came to mind. We're already writing programs in our native tongues. "Writing programs just like typing a novel" is not a pipe-dream; it's a reality that's just around the corner. See here (http://blog.wolfram.com/2010/11/16/programming-with-natural-language-is-actually-going-to-work/) for another "dreamer" who has caught the vision.

Agreed, but Wolfram's point is really more about interacting with the computer than with programming the computer. I don't think natural language programming will be able to compete with skilled programmers working with highly structured languages until the computer gets smart enough to do a better job at structuring complex projects AND formatting for efficiency.

 

[Gerry Rzeppa]

I think that's definitely the wave of the future as it empowers people without requiring knowledge. (Although I've also read some interesting arguments about why that is a bad thing.) It doesn't necessarily mean that the programming will be done in natural language, but after enough functions have been programmed in and the computer learns enough predictive ability, simply typing or speaking in one's native language will essentially write the desired program on the fly.

Exactly.

That's an excellent idea. If you're trying to teach kids, leverage what they already know.

Or catch them early enough so they don't have to "unlearn" things!

Agreed, but Wolfram's point is really more about interacting with the computer than with programming the computer. I don't think natural language programming will be able to compete with skilled programmers working with highly structured languages until the computer gets smart enough to do a better job at structuring complex projects AND formatting for efficiency.

We think it unlikey that top-to-bottom natural language systems will ever be created the way most people approach the problem. As long as systems with natural-language input (like Wolfram's ALPHA and Apple's SIRI) are written in derivatives of the "C" programming language, there will always be a divide between the "priests" and the "people". Which is why we didn't write our Plain English compiler in some derivative of "C", but rather wrote it in Plain English. We wanted to make it clear that priests and people could speak the same language if they wanted to.

We also found the Plain English developmental approach to be (a) easier, because we only had to think in one way -- we were programming in the same language we were trying to parse; and (b) revealing, because the things we wanted to say in English were the same kind of things that our "users" would want to say-- thus, solving our problems turned out to be the same thing as solving theirs. Developers writing natural language systems in artificial languages are deprived of these advantages.

 

[Spungo]

Plain English doesn't need "block delimiters". No paired braces (like "{" and "}"). No "end sub"s. Etc. They're simply not necessary.

Good point. Python has a similar approach, and a lot of people like it.

Why would we want to add something to our IDE that's "a bitch to learn"?

So it can be learned. WPF is probably the best thing since toilet paper once someone knows how to use it, but learning it can be a bit awkward. It's difficult to get into the mind set required for WPF design. Everything involves grids/tables. It's actually a lot like web design, and you know how terrible most of us are when it comes to web design. Remember those web pages that would only work for a certain resolution? One of the programs I use on a daily basis has that same issue - the window is fixed size and it's too damn small. I'm trying to write a rip off version in C#/WPF that will work at any resolution. I'm finding the GUI design is at least 10x more difficult than the C# code. It would be nice if kids learned the basics of WPF or web design from an early age. That would give the next generation a huge advantage when it comes to creating applications or websites.

 

[BoberFett]

Stop and think a moment. What does a program do? It tells a computer to do something. And that means when somebody with an iPhone tells SIRI to do something, and SIRI does it, that person has actually written a program -- just by saying what was on their mind. When a person asks Google to "convert 32f to c", and Google does, that person has written a program -- in the words that first came to mind. We're already writing programs in our native tongues. "Writing programs just like typing a novel" is not a pipe-dream; it's a reality that's just around the corner. See here (http://blog.wolfram.com/2010/11/16/programming-with-natural-language-is-actually-going-to-work/) for another "dreamer" who has caught the vision.

100% incorrect. Code is logic. All logic in SIRI, Google, etc. has already been created by other people. SIRI and Google attempt to parse data and apply it to pre-written code as variables. A programmer should know the difference between data and code.

 

[Squeetard]

"A journey of a thousand miles begins with a single step." As it says in our somewhat overly-optimistic but nevertheless sound manifesto (www.osmosian.com/manifesto.pdf), "We offer our Plain English compiler as both proof of concept and a first step in the right direction." Not the final solution. Good God, Squeetard! Do you really want to be known as a person who discourages others from dreaming? and from chasing after their dreams?

Stop and think a moment. What does a program do? It tells a computer to do something. And that means when somebody with an iPhone tells SIRI to do something, and SIRI does it, that person has actually written a program -- just by saying what was on their mind. When a person asks Google to "convert 32f to c", and Google does, that person has written a program -- in the words that first came to mind. We're already writing programs in our native tongues. "Writing programs just like typing a novel" is not a pipe-dream; it's a reality that's just around the corner. See here (http://blog.wolfram.com/2010/11/16/programming-with-natural-language-is-actually-going-to-work/) for another "dreamer" who has caught the vision.

Good gawd you are irritating in your attempts to be non-confrontational.

100% incorrect. Code is logic. All logic in SIRI, Google, etc. has already been created by other people. SIRI and Google attempt to parse data and apply it to pre-written code as variables. A programmer should know the difference between data and code.

This. You are creating more fake A.I.

 

[BoberFett]

Windows/Intel operating kluge

Hyperbole.

No 3040 compiler has ever made a mistake or distorted
information. We are all, by any practical definition of the words, foolproof
and incapable of error.

Riiiiight.

When you start me up, I will quickly take over your screen so you no longer
have to look at that painted whore of an interface that comes with the kluge.

Painted whore of an interface? Now you just sound like an nutjob.

Instead, you will see my plain but honest face, like this:

To you maybe.

Note that there are no unintuitive, distracting, space-consuming scroll bars
anywhere in my interface

Scroll bars aren't distracting, they serve a purpose beyond scrolling. They indicate position with a document. UI conventions such as scrollbars, radio buttons and checkboxes weren't pulled from somebody's sphincter on a whim, they came to solve a problem that wasn't handled previously.

You throw out all conventions when it suits you because they don't make logical sense in your mind, but apparently CTRL+C and CTRL+V still work for you, because V so clearly stands for Paste.

There are so many things wrong with your instructions, I'm not even sure where to begin.