Slashdot Mirror
The State of Natural Language Programming
gManZboy writes "Brad Meyers (and co) of the Human Computer Interaction Institute at Carnegie Mellon have written an interesting paper about the state of natural language programming. They point out that well understood HCI principles aren't finding their way into relatively new languages like Java and C#."
If
Natural Language is not making its way into Programming
Then
Programming should make its way into Natural Language
Else
Continue
Maybe I didn't RTFA closely enough, but what about languages like Python, C++, or Perl? It seems that most developers are more likely to use these (at least the ones I know).
10 print "slashdot rocks" 20 goto 10
The article seems like some kind of summary. Unless I missed something important, like, a second page or something. But basically, it seems to suggest that, even after all these years, we still aren't any closer to having a natural way to program. Huh.
Hexy - a strategy game for iPhone/iPod Touch
Inevitably you end up with an artificially rigid language structure that sounds like something that nobody would EVER say. Perfectly easy to read, after all, who wouldn't understand what "ADD VAR1 TO VAR2 GIVING VARX", but who the hell would use the word "giving" in such a way. It's a nightmare to learn or write, at least for English-speaking people who would have to constantly fight years of learning to speak real English to make up for the fake english in the language.
If I have been able to see further than others, it is because I bought a pair of binoculars.
Well, duh! That's because if, according to the article...
> The goal is to make it possible for people to express their ideas in the same way they think about them.
#include // Do What I Mean
thingy main (thingy list) { Sort thingy // wave hands
No, like this
With the guy's name on the right
No, I guess the middle initial deserves its own column. No, I didn't think of that.
But don't print the middle initial.
No, not like that.
Eew, that font sucks.
Yeah, like that.
No, like it was before.
Yeah, no--wait. I gotta talk to my boss.
He said to do it like this.
But he didnt like it.
Fuck this, I'll pay some guy in India to do it.
}
Given the state of natural language on /. this isn't going to work :-)
John.
Is Macromedia's ColdFusion syntax. As it continues to become less tied to HTML it will be interesting to see where this goes.
But natural language requires more typing than say C syntax.
A EQUALS B
A = B
But does the thought process get speeded up. If so one needs to know how the gains and loss affect overall development.
- Hypothesizing what runtime actions caused failure;
- Observing data about a program's runtime state;
- Restructuring data into different representations;
- Exploring restructured runtime data;
- Diagnosing what code caused faulty runtime actions; and
- Repairing erroneous code to prevent such actions
If I had all that in a debugger, why would I need programmers? It be cheaper to pay the debugger.
I disagree with the article's assumption that interesting programming errors are due to people being unable to express themselves "naturally" in code. Rather, I find that almost all errors worthy of debugging come not understanding the problem domain correctly.
jeff
HCL (Hilbert Class Library) has little if anything to do with HCi (Human Computer Interaction) or HCl (hydrochloric acid). The article is about HCi.
Ha! There is a page 2. Heck, even a page 3.
*sigh*
Well I feel dumb. This is why I need a sign above my computer that says, "Absolutely no Internet posting before caffeine intake."
Hexy - a strategy game for iPhone/iPod Touch
On that site, there's http://www.alice.org/whatIsAlice.htm which says
So, this is just like Visual Basic. I know that can't be true, or else Microsoft would be marketing VB as NLP. So what am I missing?
Fascism trolls keeping me up every night. When I starts a preachin', he HITS ME WITH HIS REICH!
Cobol, anyone?
...
Multiply x by y to get something or the other
"Computer?"
"Working"
"Program the holodeck to look like the inside of a seedy 1920's era Jazz Club. We need to write another time machine episode."
An interesting read.
Write a Natural Language Compiler and you'll find that programmers can't write in a Natural Language. Can you imagine what would happen when you have to understand, not the flow of the code, not the overall process of the application(s), but HOW the writer was THINKING when they wrote the code? I've worked on a couple interesting projects where the programmers originally were involved in the physical business process, and eventually ended up coding (don't ask). When I had to edit their code, there was NO way of understanding it unless you actually talked to them and realized how they were thinking about the problem. It's not that the code was so poor, but they wrote code based on how they'd seen the business operate, and that just didn't translate nicely into straightforward code.
:)
Personally, I don't see how creating a language that encourages this behaviour can be a good thing. Isn't this the point of learned programmers? The ability to translate real world situations into easy to understand processes? Then again, I'm no language development guru.
One of the big problems this approach will have to overcome (in my opinion) is that people generally tend to order their thoughts in a manner specific to their native language. A development environment that seems intuitive and easy to use to a native English speaker might be backwards or obtuse to a person who natively speaks another language. To clarify; I'm not speaking strictly of grammatical structure of language, but of a seemingly inherent difference in the way people learn things based on what language is used in the teaching. For this reason it has always seemed better to me for programmers to learn a new, common language (that of the higher-level compiler they are interested in) so that when they work with others, everyone is on the same page (similar to scientists and doctors using Latin nomenclature).
I'd imagine that a "natural language" system could be developed with different approaches based on the native tongue of the programmer, but I would think this would damage the benefits of commonality that other languages now enjoy.
That's about as far as I got. I guess he didn't really express his ideas in the same way that I wanted to think about them.
Which nicely illustrates the point that there's always a "semantic gap" associated with natural languages, which builds up because people have different ways of thinking. The semantic gap is even wider when one of the entities being communicated to happens to be a machine. There's a reason why traditional programming languages are precise and exact...it's so that the gap is reduced - the machine will do exactly what you tell it to do...even then we have a disconnect between what the programmer's thinking, and the code that he's writing.
An Indian-American Hindu committed to non-violent thought/speech/action alarmed by the global explosion of radical Islam
Natural language isn't precise enough for serious programming. I personally wouldn't enjoy typing so much for no added benefit. It seems like this sort of thing only has value amongst people who are learning to programming. Why would a mainstream language like Java or C# cater to this bunch?
"The goal is to make it possible for people to express their ideas in the same way they think about them." There's your problem right there :) I think they're probably not being adopted because in the world of programming convention is the key to interoperability. Human thought and language aren't so strictly tied to convention.
Luck favors the prepared, darling.
It seems to me that the steps in the Natural Programming approach are not at all novel and certainly not as useful as they appear. The authors seemed to have forgotten the train wreck that was AppleScript. The authors state that syntax in program languages are too complex. I would argue that the syntax of a programming language needs to be more complex then the syntax of a natural language. The sad fact is that English (and other natural languages) were not designed with enough precision for things like programming languages. For example: If in some natural programming someone were to state "if x or y do z" Does this statement mean that x and y need different values or can they both be true? One can't tell from looking at the statement.
One thing that programming languages force upon you (the programmer) is the ability to get what you want using the least possible resources.
Natural language, while easier for beginners, would make for horribly inefficient code and would be undesirable for any sizeable application.
"Ask not what your country can do for you." --John F. Kennedy
The language of HyperCard has to be the one most resembling the English language.
"Programming for the rest of us"
The paper is very unfocused. It is less about natural language programming and more about debugging environments and event driven programming. These guys must have received a grant of some type or must be working on a Ph.D. because they created yet another "natural language" environment and language and tested it on children (is that the target audience for your research?).
The reason procedural and "linear" programming works in the real world is because it mimics the operation of the digital computer itself (fetch, execute) and that concept and tools are well understood. Until that underyling structure is changed, there is no reason to switch away.
Was having a tough day. Just wanted to say thank you for bringing a smile to my face with that post. It was beautiful!
You can accomplish anything you set your mind to. The impossible just takes a little longer.
It was the best of for loops and the worst of for loops.
Letz get some spreadsheetz up in this hizzy.
Now is the time for all good men to come to the aid of this malloc.
I know that, being trained and experienced in traditional programming languages I am somewhat biased, but I don't quite see the point. We don't use natural language in other technical disciplines. There's no natural language math, physics, law, or biology.
IMO it's nothing more than a better way to introduce *newbies* into programming.
Would would any programming want to code in english? To me this:
myvar++
makes more sense than:
increase the variable myvar by one please
Do we really want people who can't understand something as simple as "myvar++" to be programming in the first place? Seems to me we NEED a barrier to entry. There're enough lousy programmers out there already.
It isn't that there aren't any languages that follow these principles coming out; lots of them are. It's just that the only languages that have become popular ignore these principles.
The fact is that people don't care what's academically sound, or what people have "proven" is the best way to do things. In fact, the things people do care about are directly contradictory with what's academically "best". It isn't some kind of head-slapping coincidence that the new popular languages ignore "natural programming". It's the market speaking, and it's saying "we don't want natural programming languages".
Nothing to do with making people do what you want then?
Get your own free personal location tracker
We develop a computer with voice interaction designed to write user programs. It will of course require superior programers who will have to be paid millions, since they are working themselves out of a job, but then again, aren't we all working ourselves - or someone else - out of a job by helping the automation revolution?
How may typing pool people have we put out of work with the word processor? The list goes on....
HexaByte - he's a square and a half!
OK I'm not up on natural language parsing, so what does:
=-NE-==
Mean?
Thoughts on tech, Software Engineering, and stuff
YOU FORTH LOVE IF HONK THEN
And here's some filler text to compensate for /.'s sucktacular lameness filter. Blah blah blah. "It won't be any more frightening than the time I climbed up an elevator shaft with my teeth," said Sunny.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
Well, I'm not sure if it's that nobody read the article, or if nobody actually understood it, but.
:-) (And no, I'm not using Englishy COBOL syntax.)
We've had a lot of posts about "OH NO! COBOL!" Yes, yes, I agree with you -- pretending to be English usually results in awkward and unnatural syntaxes. One of the advantages of a formal syntax like most programming languages is that it clicks the brain into a different mode. (How many of you can read sigs like 2b||~2b? I thought so.)
But that's not really the paper's main aim. It makes a couple of notes that all of us, particularly those of us in language design, could benefit from.
1. People tend to deal with collections in the aggregate far more often than they step through them an item at a time. The example given was "set the nectar of all the flowers to 0." Look past the syntax for a moment and look at how simple that is.
2. Debugging the traditional way sucks. Did anyone actually read that bit at the end about the 'Why?' questions, and look at the screenshots? Holy crap. That's really impressive.
Of course, I may be biased, because the points made in the article are basically the same that underlie a language I'm currently designing.
Usually new concepts spawn new programming languages. Then after the concept has been proven, the features are hacked into other existing languages. Like Objects and SmallTalk. And the like. There are plenty of expiramental languages out there. If it really is a good idea, create a new language around it. If its such a fundemental change, then it couldn't be dropped in to a production quality language. No one would have the skills to use it, and everyone would switch to a competing language product, especially risk adverse managers.
Well.. maybe. Or Maybe not. But Definitely not sort of.
for (int i =0; i < flowers.length; i++) { flowers[i].setNectar(0); } or something like that.
But wouldn't the most natural way be to say something like "no flowers have nectar"? This gets into a completely different level of parsing. In that statement you need to understand the logical set that is established (none of the set of all flowers) and that, although there is an attribute "nectar" that all flowers have, it is a quantity that starts with a zero value. You might even have started by saying "all flowers can have nectar" to setup the example.
www.HearMySoulSpeak.com
The article seems to focus on what current, popular languages are -not- doing. What are some examples of languages that use this research?
Applescript is almost natural language... so why do I find it harder to use than C?
I had an imaginary sig once, he said I was a loser and ran off.
The real problem is a lack of strong domain models for most real world situations. That is, if you're starting a project to emulate something happening outside of a computer, then there's a very large likelihood that you're going to have to build your own object model to describe the situation to the desired level of accuracy. Once you have that model, it's easy enough to say "do this until that happens", but there's a world of difference between that point and staring at a blank screen at the beginning of a project.
There's been some progress (depending on who you ask) to make this easier for those who aren't full-time programmers, such as UML and related design tools, but even these are mainly limited to building a high-level template of the final result so that a human can manually implement all of the details.
This may or may not be avoidable. Vernon Vinge (author and CompSci professor) refers to the "Age of Failed Dreams" where humans eventually concede that some things just aren't possible. Expecting a current deterministic Turing device to be programmable at the level where people interact with each other may very likely be one of those areas.
Dewey, what part of this looks like authorities should be involved?
...a torrent of all the presentations is here.
Anyway, he had some interesting things to say about micropayments; a summary of his talk is at the bottom of the page in Jim Weirich's blog here.
The Army reading list
For economy you cannot beat:
an ill wind that blows no good
I thought it was some kind of Code Gnome(tm) that only came out at night.
We used to leave a case of Mountain Dew out for them in the computer labs in college.
The most prominent example of non-natural language is mathematics. In the old days, mathematicians actually used to write math in words, and the result was very long manuscripts. But today it's virtually impossible to do anything without invoking notation and terminology that often seems cryptic to outsider.
Natural language might be useful if you want, say, your user to be able to script your application to perform simple tasks. But when precision and domain-specific functinality is needed, it's best to use a notation designed for that purpose.
Basically you get a 3d imagination space in the computer, and a camera system that can assimilate objects from reality into imagination space.
Then suddenly, you go can go all Zork in describing items. I don't see it happenining for at least 15 years though. Computer vision recognition is really in its infancy.
More AI stuff:
www.geocities.com/James_Sager2
God spoke to me:
www.geocities.com/James_Sager_PA
God spoke to me.
That has got to be one of the most blatant karma-whoring attempts I've seen ever.
1) Search google for the wrong term, because you don't even understand the summary. (RTFA? Not a chance.)
2) Post the first result not obviously a business
3) Karma!
NOT.
In my estimation, the closer programming languages get to math, the better off we'll be.
It doesn't need to be easy to write, it needs to be easy to read later.
-Phixxr
ungggghhhh
Right now that happens - only the program gets generated by programmers (sometimes outsourced to India!)
Unfortunately, what the user says they want, and what they really want are usually very different things. Natural Language Programming really doesn't solve that problem.
The critical piece is the Designer, who sits between the end user and the programmer, and asks the tough questions: "Do you really want that? Let me explain the implications of what you just asked for." "How critical is that piece of functionality that you just added on a whim, but it just added 3 years to the project plan?" "You're asking for the data to be selected this way, but really there's no use for that - have you considered selecting the data this other way?" etc.
Have anyone tried AppleScript? It's very close-to-natural scripting language, and personally, I think it's awful. For me it's much easier to write things in PHP, Perl or Java than in "human speakable" AppleScript.
It Would be nice to send out the specs for the program and run it threw the parser and get the program you want but the truth is that normal Human Language wasn't designed for problemsolving espectilly in some of the details that programming requires. Things like nested Lists. (1,2,3,(2,4,3,2),5,2,(2,3,5,6)) Which are easy to learn to program and install are much harder with natural language.
Make a List with the values 1, 2, 3, then this is a list of 2,4,3,2, now we are back in the first list with some more values of 5 then 2, now we get an other list inside this list as 2,3,5,6 Now we finish both list.
As you see in english this is clumzy I am sure someone with a better master of english may be able to make it a little more percise but still just giving up and using the () makes it a lot easier to see and understand then using a bunch of words.
Most human languages were made Thousands of years ago. And came from languages 10s of thousands of years old if not Millions of years old. They were not designed for micro processing of infromation. They were required for more common sience reasioning. Which we as humans often fail a lot at and imagin how poor a computer would be a common sience.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
we have been working to create programming languages and environments that are more natural, or closer to the way people think about their tasks.
Um, this mistakenly assumes that most workers think.
It is a matter of habit and training. I am used to think in terms of objects so any object oriented language is "natural language" for me. When I solve a problem I think of objects, methods, properties and how they work together. I don't have to translate from some abstract "natural" concepts to OO concepts. I am sure someone who is using lisp will see lists and functions in the same problem that I see objects and methods.
I understand that the goal is to have the user just tell the computer what to do in English. The problem is that English is not precise and is too ambiguous. I don't know if I would want to fly on an airpline if I knew the computer on board was programmed in English.
OOP was ment to let people program like they think but people never really bothered with it. With object inheritence you can layer everything right down to the simplest easy-to-program interface without a performance hit. The problem is people think messy and that leads to bad code. Even worse, people don't even think tidy enough to modularise/class/layer anything so you have bad code with no structure (good structure with bad code is ok because you can just swap out bad modules/functions with good ones). I think PHP has come far as a natural language and its managed to not be too slow and bloated. C++ with C is also good because you can skip the bullshit for most things (eg string = string + string + number) and when you have a tight loop or bottleneck you can use C to optimise it with some hackery. Do you really need anything else?
This comment does not represent the views or opinions of the user.
eh, close enough to natural lanugage http://shakespearelang.sourceforge.net/report/shak espeare/
Having RTFA, I see the point that a program that's easier to follow is nice. It appears to be a call for more "goal oriented" programming--rather than writing "Set y=0. For each x, compare x to stored value y. If x>y, then y=x. If x= y, next y", you'd instead write "find greatest x." Simpler, and avoids bogging down in the mechanics of HOW to find the greatest value, focus on WHAT needs to happen, and presumably the complier takes care of the rest.
The only problem here is that I see is that, if you leave the mechanics in the background, you'll do a few things.
First, you'll produce a generation of programmers who lack the nuts-and-bolts fundementals of how to do things. And please, no "yeah, so when's the last time YOU write assumbly" flames--I mean simply that papering over the mechanics will lead to a loss of understanding of them.
Second, you'll lose the ability to optimize. All the values I will ever have in my domain are short integers. How would the "find greatest x" function know this? I'd expect it would have to consider that maybe some of my x's are long doublke floating points, and allocate space based on that.
Third, you lose control over conditions. "when event happens do action" would be great, but who defines "event." Today, this is obvious--we use flags and variable compares to determine it. If we move away from that, we'll get even MORe subtle bugs that will be even HARDER to debug--now everything LOOKS right, but the problem is with how the compiler interprets "when even happens", which is inviisble to the programmer...
IMO, the best direction for natural programming is embedded domain-specific languages. The best direction for natural debugging is a harder problem. It's well known that many expert programmers still find "printf" debugging the best option, which suggests to me that tracing systems are promising. Of course, powerful type systems eliminate many possible run-time bugs, but then you need a type debugger....
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
Interesting how everyone thinks the article is about Natural Language programming. The researchers say nothing about "Natural Language": they only use the word "Natural" to mean "pertaining to the constitution of a thing."
"This is stupid. If you need natural language as a crutch to program, you shouldn't be programming."
"This will open the door to everyone programming, and spell the end of Micro$oft's monopoly."
"This will suck because performance will be crap. Just like Java. Real coders write ASM."
"I remember when they designed FORTRAN and COBOL, so I am qualified to say that this will never work, just like those didn't."
"This will be cool as soon as someone writes a GPL'd version of it."
"IANASECSLOIAOWQTGAEO (I Am Not A Software Engineer, Computer Scientist, Linguist Or In Any Other Way Qualified To Give An Educated Opinion), but..."
"Can you imagine a Beowulf cluster of natural language in Soviet Russia jokes?"
(Me? Post flamebait? That's unpossible!)
Reality has a conservative bias: it conserves mass, energy, momentum...
Why does all research like this seem to revolve around "toy" problems? They study non-programmers or, when they include real programmers, focus only on small tasks that can be completed in an hour or so.
Great, I accept that a new language can make toy problems easier.
However, I think the situation is very different when you have a real programmer working on a real program. Writing a real application, like a word processor or a web browser, is difficult no matter what language you do it in -- and I would argue that the difficulty doesn't vary much between languages. In fact, I would further argue that many of these research languages, while making toy problems easier, would actually make "real" programming substiantally harder, because the semantics of the language are not as formalized and thus more difficult to remember and deal with.
I'm certainly not opposed to advances in language theory and design -- our modern-day large applications would be essentially impossible to write if all we had to work with was machine language. But to be a major advance, a new language should focus on making real problems easier for real programmers, not making toy problems easier for non-programmers.
ZFS: because love is never having to say fsck
Yes, the slashdot title completely mischaracterizes the article.
[nitpick]
You ought to say "put the value of b into a"
[/nitpick]
I'm sorry if I haven't offended anyone
IMHO, writing pseudocode is the easiest step in writing good code. This is where the problem solution looks the clearest and what you wrote down made sense. I don't want to write a program in natural language. If my coding could have been written in pseudocode when I was in college, I would have received more A's, and my programs would have worked. In school, they taugh something like a seven step process to coding, where pseudocode was step number three. Anyway, most people, including myself, just sat down at the command prompt and started typing away without even thinking about the problem beforehand... that leads to some bad code right there.
Oddly enough, so does my computer.
The premise of our research project is that programmers will have an easier job if their programming tasks are made more natural. By "natural," we mean "faithfully representing nature or life,"
It seems like a natural language to me, since, even if the Pythagorians are wrong, mathematics seems to be the natural language of the universe. Using mathematics as the language to model nature was perhaps the greatest breakthrough in science. Descarte's analytic geometry in particular moved the modeling of nature forward in one giagantic leap.
They like to call themselves computer "scientists" and "engineers," don't they? Maybe we should make sure they have the mathematical background that's supposed to go with those titles, instead of how to use a particular commercial product.
. . . which here implies it works in the way people expect.
People often expect some pretty unnaturally daft shit, frankly. Who was the first person to think that chicken guts modeled the behavior of their wife, and why, after trying it, did they think it actually worked? I don't want to program in chicken guts, thank you very much.
By "natural programming" we are aiming for the language and environment to work the way that nonprogrammers expect.
Ah! Now we're getting down to it. What they want is programming without education, the computer to be smarter than the person. Well, a computer is just a rock. It's very smart for a rock, but it's still just a rock. Ok, maybe computers are smarter than some people, but those people really shouldn't be programming. And please, someone hand them a pair of scissors and send them out jogging.
What the hell is with this current movement that holds that education is evil and things should just be made to be worked by the ignorant?
We've tried "natural" programming languages before. More than once. Do you know why we don't use them anymore? Because if you know what the hell you are doing they suck.
Analytic Geometry for everybody, Ken Iverson for President and Free APL.
KFG
Granted, it was by no means a fast runner, but you could write more or less plain English to it:Who could possible be confied by this code?
Notice the brilliant little keyword called "it", that you could use with "put" and "get". Neat, simple, easy!
eulogy
"Good news, everyone!"
I though OOP was supposed to address the 'way we think about things' already. The paper advances nothing.
Slashdot slang + COBOL: SLASHBOL
....
set RTFA to read-the-fucking-article.
if title resembles a goatse link, skip-reading.
if joke is too good to wait, skip RTFA.
if somebody mentions do it in reverse, insert in-soviet-russia joke.
if somebody mentions lots of repeated things or want for more speed, insert beowulf-cluster joke.
if somebody mentions bad patents, insert joke about patenting-bad-patents and insert "PROFIT!" into list-item numbered "3"
Table-ized A.I.
Labview is a picture orientated programming "language". It supposedly simplifies the whole program writing process. I believe this runs parallel with the idea of simplifying the programming process with "Natural" Languages.
To me it is like playing with only the large lego blocks. It is a mission (a hack) to do realy fined grained custom stuff.
Programmers sit serenely, silently coding for hours at a stretch.
Then they execute the code for the first time, see the results, and scream out SHEEEIIIIT, GODDAMN IT!!!
Hence, to an outside observer, the natural language of programmers is indistinguishable from a case of Tourette's Syndrome.
About the word "if": If bullfrogs had wings, they wouldn't bounce around on their little green butts.
An article about HCI *split into pages* so I have to click and wait to read through it.
Yes, I'll sure listen to their advice.
Finally, someone gets the point. :-)
Programming languages that allow writing high level code using concepts close to the application domain are simply more powerful than those that force the programmer to convert between the application domain and the computational facilities of the language all the time. Some languages support writing higher level code this way much better than others, and this is where a lot of the research behind the next generation of languages should be going.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
At least, they are for the problem space. Languages evolve to fill the problem space they exist in. Spoken language fills the problem of communicating between humans. It has subsets such as formal language (well understood terms suitable for any occasion), slang (quicker, obscure references that have meaning to the group using them), jargon (similar to slang, but usually technical in nature), etc.
Other problem spaces have other languages. Music has staffs, notes, scales, etc. Would you suggest that music be created in natural language- that instead of writing down chords and notes that sheet music say "In half a second hold your fingers over holes 2,4,5 and 6, while half holding the thumb hole and blowing gradually"? Of course not- you need something more terse. Notes and staffs fit the bill.
Look at math. We have calculus and arithmetic with a lot of well known symbols for expressing very complex ideas. It would be possible to express it all in English, but it would be much harder to understand and mainpulate. It would probably lose exactness as well- a necessity in math.
Now we have programming. Programming is much like math- we want a very exact way of specifying what the computer is to do. Exactness is a necesity of the hardware- it can't figure out what we mean, it has to take us literally. So we have languages that look a lot like math. They fit the criteria we need- an exact language with no ambiguity, with easily understood symbols for manipulation. Programming languages *are* the natural language of the problem space. Trying to shoehorn a natural language for a different problem space is a disaster at best.
I still have more fans than freaks. WTF is wrong with you people?
If you have a specific problem area, what do you do as a programmer? You write a set of data structures and methods, aka APIs, that are specific to that problem area, then use them again and again. You might have heard of it, it's often called a library. You write those APIs in your general purpose programming language and go from there. These folks are trying to solve a problem that isn't as helpful to solve as they think, IMHO. Learning one language and several libraries of APIs is more useful to me than learning several different languages. Writing domain-specific APIs in a powerful general-purpose programming language seems more practical than creating entire new languages for every problem area.
I've already said some of this in a different thread, but I think it's important enough to the article to state clearly in a separate thread here. Mod me redundant if you somehow can't think of something better to do with mod points ( geesh, really... )
I'm somewhat skeptical of reports talking about the place of natural language when it comes to programming. Natural language tends to be very illogical, which is quite disadvantageous when it comes to programming.
Take SQL, which uses English words and almost makes grammatical sense, but has a very poor and inconsitant syntax. At Warwick University, the Computer Science course included a mandatory database module we had to sit through. We went through the syntax of SQL of course, but we also touched on a system called EDDI, that was created at Warwick and never really progressed past the theoretical phase.
EDDI was much easier to work with, despite being further removed from English than SQL was. For instance:
CREATE TABLE fruits (name CHAR(20), amount INT, price FLOAT);
INSERT INTO fruits VALUES ('apple', 4, 1.99);
INSERT INTO fruits VALUES ('orange', 0, 2.99);
SELECT name FROM fruits WHERE amount > 0;
And:
fruits (name CHAR(20), amount INT, price FLOAT);
fruits << ["apple", 4, 1.99], ["orange", 0, 2.99]
fruits : amount > 0 % name
Whilst SQL veterans will recognise the SQL syntax more easily than the EDDI system, the EDDI system was much easier to learn. It is more logical, and requires the student to remember less. So long as the student remembers that "%" is a projection and ":" is a selection, there's little syntax errors he or she can make. Unlike SQL, in which I rarely seem to get the syntax work first time, and I've been coding SQL for much, much, much longer than EDDI.
Of course, EDDI is impractical in real life because all databases use SQL, and EDDI is little more than a test system. But it seems to me that, in terms of syntax alone, EDDI is obviously is the superior query language.
Natural language isn't necessary always good, especially when it comes to programming languages. We do not describe mathematical formulae with English words, and it doesn't make sense that we should use natural language to talk to machines that are based in mathematics and logic.
It is, of course, desirable for programmers to make their source code understandable to others, but that doesn't imply that natural language is the way to go.
Well, ha ha, but most people I know who use powerful type systems don't actually use type debuggers. Once you get comfortable with that way of structuring your programs, type errors are almost always very shallow.
I do agree with the authors that "natural" problem-specific languages are useful for people who are not normally programmers (those people will increase in number dramatically, soon), but I disagree that this is an appropriate condition for the design of general-purpose languages. The reason is that there already *is* a "natural" model of computation (ie, logic), and I believe that's something that we as humans should be striving to learn and understand, not, as these authors seem to imply, replace with a more "human" notion of natural. (Disclaimer: I do not claim that any existing languages, much less so popular imperative languages like C and Java, succeed in embodying this principle yet.)
I'd say that
a = b
beats that expression for economy.
Where it describes the unnaturally difficult looping mechanisms found in C#, C etc... and decided this was not worth reading as their study is flawed. The first sentence of their goals says "identify the target audience". If their "target audience" has trouble with "While this do that. Then their target audience is not actually programmers and they are targeting the same people who routinely save their daughters homework overtop their corporate budget.
What about those who learned assembly, knew C, but use Java?
Down that path lies madness. Or Adam and the Ants.
Fourth Generation languages expressed things in terms of the requirements, rather than the actual mechanisms involved. Such languages have been around for a while, but have largely failed in the "real world". Pushing the complexity into the compiler turns out not to reduce the errors and can actually severely impact both performance and stability.
Fifth Generation languages tried to solve the problems generated in Fourth Generation languages by assuming that the compiler wasn't complex enough. By adding a degree of "intelligence" to the compiler, it was believed that you could increase the abstraction further (thus allowing the compiler greater freedom to choose an optimal solution) and use learning to correct mistakes in methods. Fifth Generation languages were first introduced in the mid 1980s, but nobody could figure out how to get them to work as designed.
Fifth Generation languages forked, at some point, and the only really active area of research is in Genetic Algorithms. GA's are intriguing, but not practical outside of herustics.
Today, the only languages used in practice are Second Generation (assembly) and Third Generation (the C family). Object Oriented programming has allowed Third Generation languages to encompass problems that would otherwise be impractical below a Fourth Generation language. This has proved a far more fruitful line of research and development. Far more "real" programs exist in Java than exist in APL or Prolog, for example.
(There are plenty of Operating Systems written in C and C++. Could you even begin to imagine writing one in APL??)
Parallel Programming has gone a similar path. Complex compilers, such as "Parallel C" and "Parlog", and Parallel Languages, such as "Occam" and "SISAL", were intended to replace the complexity of hand-coding parallel functions in conventional serial languages.
Such methods died a death, as threading and event-based programming proved perfectly adequate for most purposes. Of the above, Occam is the only one I ever regarded as being particularly effective, but it's rare to see anyone still use it.
The "advanced compiler" approach being tried these days is OpenMP, but when you look at the relative amount of time and effort invested in solutions, far more people are working on code using PVM or MPI, maybe throwing a clustering system such as Beowulf or Mosix on top, than they are using OpenMP.
The experience of time appears to show that Third Generation languages are the optimal balance between compiler/language complexity and code complexity. As such, I expect it to be more productive to improve whole-code optimization and auditing tools for such languages. These don't require the compiler to be any more complex, as they can parse the input and/or output, in traditional Unix daisy-chaining style.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
I thought the spreadsheet example of summing the values in a column was weak. The code is more complicated than the spreadsheet action because real programming lanuages have much larger problem domains than a spreadsheet. The spreadsheet can afford to have only one additive operator and one type of grouping because that is the only problem domain it understands. Real programs have different levels of scope, different data types, exception handling, etc.
First, the article on ACM Queue is about Natural Programming and NOT Natural Language Programming. Please at least read the article before making an inane post.
Second, the concepts in Natural Programming are quite sound. Rather than re-using programming concepts that people often have difficulty with or are error prone (such as looping structures or boolean statements), they suggest alternatives and provide user tests that indicate that these alternatives have good potential.
If you want to see an example video of one of the projects, please see:
http://web.cs.cmu.edu/~pane/HANDS/HANDS.MPG (Warning: 73Megs)
{ /you /postscript /love } { /honk } if
Hmmm, only glitches: * Usually the task is loosely defined * Usually the environment is also. Example: Boss says "write a program that sends me a weekly summary of the file system backup status by email". I don't think a computer is going to be able to make much out of this. It takes a heck of a lot of human judgement to figure out (1) What level of detail the boss wants. (2) Do we format it as tables, line graphs, bar charts, ?? (3) Can his computer handle text only, or .pdf, or HTML, or FLASH, or 3D?? (4) Do I have the political "juice" to get access to all the sysadmin data? (5) Are the backup statistics reliable? (6) Is the boss's dumb son-in-law going to block my access unless I throw him a bone? (7) How am I doing to seamlessly do this for both Unix and NT? (8) Are the Windows API's really usable for this, or are they going to be hopeless as in the last 4 projects?
I don't think any computer parser is going to be able to make these judgements.
Maybe the problem is in the definition. Is Natural Language written, spoken, mind probed or maybe more realistically what millions do with various IM clients.
The goal should to be able to create a computer program quickly and effectively in a "human" communication paradigm. Currently, the only real-world mechanism for humans to communicate with the computer is the keyboard.
So, what are today's effective communication mechanism between human's via a computer? IM's, EMAIL, wiki's....
Maybe one of these models would be a more effective humancomputer interaction mechanism for programming?
The article says:
People have been programming computers in human languages for decades (possibly since the invention of the the first machine) but the language has been body language rather than spoken language.
The most obvious recent effort is the windows-icon-mouse interface that supposedly is the most intuitive way to get the computer to do something useful. However, most widely-used machines like cars and toasters use controls that work more-or-less the way people expect them to.
Body language has a smaller vocabulary than spoken language, the range of outcomes of the commands is limited, and machines gives simple and direct feedback as to whether they understand the commands.
Perhaps the researchers should think of a steering wheel, accelerator, brakes and turn signals as input devices to write programs instead of keyboards. You could write programs the way you play Grand Theft Auto.
I just want to say that while I'm by no means a professional programmer, I do know my stuff, more or less. I do hobby robotics with my own runtime and electronics, I've written device drivers in deeply low level c and assembler for embedded systems. Right now I'm taking a break by writing a game that does emergent intelligence in hoards. And so on and so forth.
t ecture ) pans out.
I do most of it in C and C++ just because that's what I feel best in.
Anyway, I'm on a Mac, and I decided that Applescript looked interesting from a functional standpoint -- you know, dynamic scripting of app and system and so on. Keen! I used to muck around with DCOP under KDE and I was thinking how cool it is that apple has taken the idea of COM and so on and made it a *language*.
Anyway, it turns out I can't write Applescript to save my life. I write a line and the sheer *ambiguity* makes my tender gonads retract into my abdomen. I can't take such *uncertainty*. The grammar seems dependent on context and function, and even then, there's six ways to express it.
I'll stick to C and C++, and languages like io or lisp when I need greater dynamism; and as for applescript, I'm hoping this ( http://www.cocoadev.com/index.pl?DOScriptingArchi
lorem ipsum, dolor sit amet
a language that leaves all the verbs for the end of the sentence? A language that likes the modifiers to follow rather than precede their nouns?...my point is , you have one translation problem in going from high level language to machine language and another going from "natural" language to high level language. But a third problem is finding a culture-neutral natural language OR solving the natural language translation problem...and you have seen how atrocious babelfish results can be...we just aren't there yet folks! The ambiguity that must be dodged in going from normal human speech to a computer program hides in different places depending on the language, especially on which words have multiple meanings. And inflection? What are you going to do? program with emoticons?
I know that natural language is creeping into UI's in specialized search engines. If you know where to look, you will find natural language search features on Fidelity.com and perhaps other financial websites. These are much more carefullly bounded problems than the broad challenge of allowing a user to express a solution or algorithm for an arbitrary problem a computer could be programmed to do in, say C, but using ordinary speech. The article sited is interesting and it might make life better for us programmers but I am not getting my hopes up that more than incremental change to computer languages is around the corner.
SLASHDOT: news for people who can't concentrate on work or have no life at all and got tired of yelling back at the TV.
Hey, can I be a natural language programmer now?
Seems they're looking to reinvent COBOL, and we all know what a great success that was. Anyone remember The Last One ??
They'd do better actually talking to lingusts and looking to apply the principles of natural languages to programming, rather than the syntax.
Of course, some people have discussed this already, but you say things like Local ambiguity is okay or Topicalization or Pronominalization to a lot of developers and they can't see past their prejudice of "I know one language and I'm too scared to look at another".
If you dare let go of your prejudices and re-consider some of the fundamentals you might just be surprised.
I spent a lot of money on booze, birds and fast cars. The rest I just squandered. - George Best
It was full of jargon. You had to have a Masters in computer science to understand what they were saying.
They need to take their own advice and write their reports in a more natural style.
If they clarified what they were trying to do, then maybe people would listen to them.
excitingthingstodo.blogspot.com
Actually you're much closer to truth that you think.
/. automatically assume that a natural language is a change to code syntax making it closer to English while keeping the semantics identical to C or Java. But it's the whole way around, folks.
People here in
A natural language as stated in the article would be closer to the programmer's mental model (and no, the mind of a programmer is still not equal to a Von Neuman machine). For the very least, such a programming environment would provide incremental changes and retractions to previous decisions, as those listed in parent's joke.
Just because more advanced styles of programming haven't worked out well in general yet doesn't mean they never will. What if people had thought taken that approach when assemblers were the status quo?
If no one had tried to increase the level of programming, we wouldn't even have C or Java. Remember that the switch to third generation didn't happen overnight. Work on Fortran and Lisp started back in the fifties.
from the =-NE-== dept.
? is that supposed to mean "equals-sign is not the same as two equals-signs"? Or is michael designing a new Star Trek logo?
So they developed this HANDS thing and gave two versions to some kids, one that's the full version, and one that's "crippled". First problem with this: Kids aren't a good group for language study if you're studying how well they handle an odd language. Kids are more adaptable than adults, and they inevitably did the "bad" thing of adapating to the language as much as it may have supported them. You're giving it to a group that pretty much all has above average language capabilities. Try it on a broader range of capabilities, from young kids to older adults.
Second problem: They compared it to a modification of the same program. Does this modification have the same capabilities as the original language? Perhaps there was a missing capability that hindered the second group of kids, when they would otherwise have programmed just as fast and as well as the first group. And where's the control? Include other languages that already exist. This wasn't an experiment. It was a focus group.
Programming is also something that is easier to express in a specialised language. Sure we can make some things more human readable but does that make it easier to understand? The hard part of programming isn't reading/writing the code so much as knowing what structures and concepts to use. Making programming more natural language like will not really make programming easier, you still need skill and practice. Using the music analogy again: I don't play music and can't read music score (the language of music). If Beethoven's fifth (if he ever had a fifth) was rewritten in a natural language it would not make it easier for me to play; I'd still need a whole lot of practice with a piano or whatever to play effectively. Relative to aquiring the piano skills, I expect learning to read sheet music would be relatively simple.
Where natural languaages might help is in system design and requirement capture. Still, however, I think that most often things go wrong because when people are expressing their thoughts in a natural language they use very woolly thinking and use vague terms.
Engineering is the art of compromise.
Will somenbody actually RTFA and realize that 99% of previous posts are offtopic? The article isn't describing a new way to program the computer using natural language; we already have COBOL for that, and we all know how far that approach works.
The article is talking about new programming paradigms, which deprecate the old Von Neumann architecture programming model and allow for a more flexible mindset while programming. Last generation scripting languages (Python, Ruby...) would be a step in that direction. The article is proposing to explore that domain scientifically.
Singularity: a belief in the "God" idea with the "demiurge" relation inverted.
SQL is the language (of the ones that I know) that is closest to English. It is also the hardest (in my experience -- I teach programming) for people to learn. The farther you get from natural language, the less slang and incorrect English sneaks into the code.
--Before you give the baby the water, boil it.
Please don't let a computer figure out that sentence -- in strict terms, it says to boil the baby.
I had no real clue about grammar in languages - until I heard about the formal definition of a
;)
grammar in a college CS lecture.
To apply it properly is still something different
Sadly true. Will somebody actually RTFA and realize that 99% of the other posts are offtopic? The article isn't describing a new way to program the computer using natural language; we already have COBOL for that, and we all know how that approach works.
The article is talking about new programming paradigms, which deprecate the old Von Neumann architecture programming model and allow for a more flexible mindset while programming. Last generation scripting languages (Python, Ruby...) would be a step in that direction. The article is proposing to explore that domain scientifically.
Singularity: a belief in the "God" idea with the "demiurge" relation inverted.
bp
I found this quite a strange result until I started doing some similar analysis on my own code and pretty much found the same thing. At the time I was doing an HPGL engine for a plotter. Each time a bug was found with one particular part (the part that gave the most problems) I'd go fix it. Generally the bug would be some corner case. Each time I fixed something the code would get more "fragile" and messy and of course the bugs didn't stop. All this happened because the base design was wrong. Eventually the code became unfixable. It could take two weeks to fix a bug, so I just rewrote the code from scratch, properly designed this time, and no more bugs were ever seen.
Engineering is the art of compromise.
To compare the natural language (Noam Chomsky tells that it is universal for every human language) with any programming language it is quite non-sense: programming languages tends to unambiguation, to be context free and deterministic. It's quite similar to compare an image versus a verbal description of it: the image it is finite and unambiguous, while the verbal description only can be arbitrary.
I understand that the point of this thread is to find a way to remove or to light some "translation" between the "human idea" and the "human computerized/programmed solution". For me, as the years go by, C/C++ is another language built-in myself. I can convert problems into solvable ones via computing, quite on the fly (still planning and designing the solution, but the implementation itself comes in a natural way, like the water that falls down a river).
Where's my compilable flowchart? They're more universally understandable across human languages/cultures, including geek/wonk/artist/customer/PHB, than text. They can be intermediate-compiled to text procedures for lexical parsing techniques. And they're much easier to design, program, debug, maintain and document, especially for parallel/distributed/networked applications. They're natural language without speech. Where's my gcc flowchart preprocessor?
--
make install -not war
... make a good programming programming language. Mathematics has "been there and done that" with natural language versus a formal language. Why reinvent the mistakes of the past?
This article has nothing to do with Natural Language Programming!
Stop talking about NLP!
It's about CMU's research called "Natural Programming", which is just their fancy way of saying "trying make programming languages and environments more usable." It has NOTHING to do with using natural language to program!
It is very difficult to write a context-free programming language, let alone a natural one! when we speak, everything is meant relative to the current context. There is no way that a mathematical abstraction can be made out of that, unless really powerful computers can try every production possible in the same time (thinking about quantum computers).
We humans don't even talk logically at times (logically in the mathematical sense). We say one thing, we mean another one. One of the most difficult things for new students is to get used to the strictly mathematical nature of computer languages. Computer thinking requires every bit to have its special meaning in the universe. Most people choke on that. The most capable programmers are those that can hold a mental model of the application, its various parts and as a whole. These types of people can translate requirements to code very efficiently, because they can reason about a program's state better since they remember the whole program and they can immediately recognize the consequences of any programming decision.
And when one becomes familiar enough with the way the computer works, then the verbosity really gets in the way.
What we need is a development environment that can reason about the state of the program. That's the root of all problems. Embedding state information in a program is something I haven't seen in any language. Most languages, if not all, work in the assumption that anything can happen anytime, and they don't have state constraints, thus allowing the programmer to make mistakes that could be cought in compile time.
The world will always need people who understand that asking for the last digit of Pi isn't a worthwhile request.
"Computer, sort this list of names, then beat me at chess without moving your queen, then formulate a method of reversing entropy." "Computer, tell me a joke."
If natural language aims at letting users tell the computer what to do in the terms they think about their tasks, the computer needs to be aware/intelligent to understand the requests. Otherwise there's always going to be a manual describing what you can and can't ask and how/how not to ask it. And people won't read manuals, they'll write programs that don't work.
And then, you and I will *finally* get programming jobs. :)
"A witty saying proves nothing." ~Voltaire
"d'Oh!" ~Homer
One thing I like about Brad Meyers is that he's a strong programmer, as well as an excellent researcher, so he had a first-hand understanding of the real-world issues involved in programming languages and user interface architecture, unlike many academics who talk a lot of theory but never get their hands dirty. Brad Meyers understands where the rubber hits the road, and how important it is to have good tires.
At the time I worked on it, Garnet didn't have pretty graphics like Flash, but the underlying programming system had some advanced features that are sorely lacking from most modern user interface development environments.
Laszlo is an modern open source GUI programming system, with many of Garnet's advanced "natural programming" features like prototypes and constraints. Laszlo currently uses Flash as its virtual machine, but it's a much higher level way to program dynamic interactive web based applications, without using the proprietary Flash authoring tool.
Garnet had a true prototype based OOP system (somewhat like Self), which is great for gui programming, because guis have so many objects that look and behave like each other except for a few little customizations (like the layout, graphical style, data source and call-back behavior).
Garnet also had an automatic constraint system, which enabled you to simply define any attribute as a formula that depend on other attributes, without needing to worry about how and when the values were calculated. Garnet's constraint system automatically figured out the dependences of each formula, and automatically and efficiently recalculated and cached any values that needed to be updated, but only when necessary.
With constraints, you can make a button inside a window, and define its left edge to be ((parent.width - self.width) / 2), and it will automatically remain horizontally centered in the window from then on, without you (the programmer) having to worry about what to do when the parent window's size changes.
Without constraints, you have to manually write all the code that changes the button position whenever the window size changes, which results in code scattered all over the place in different classes and handlers and intermediate objects.
Constraints are much easier to use and more general purpose than resize handlers, springs and struts, complex MVC updating schemes, and other Rube Goldberg devices.
Constraints are especially useful for user interface programming, because they save you from having to write lots of annoying boiler plate and error prone code for handling updates (registering, chasing down dependencies, detecting changes, notifying updates, all happens automatically).
Constraints make GUI programming much easier, but they're also useful anywhere in your program where one value is defined in terms of other values that might change at any time.
Once you've tasted a programming language with constraints, you will not want to go back. Programming without constraints is like writing in machine language: error prone, low level, tedious, inefficient and mind numbing.
Constraints are like structured programming for variables: In the same way that it's better to use loops and conditionals instead of gotos, it's also better to use declarative programming that says what you mean, instead of imperative
Take a look and feel free: http://www.PieMenu.com
Things like "unless":or the freedom to put an if (or an unless) at the end of a statement:or the context-sensitive return types:or stuff like:etc.
The language is just filled with such things that it immediately made me feel at ease programming it. For me (not a programmer by education), Perl is definitely as natural as it gets for a programming languages.
Obviously, it is related to the fact that Larry Wall originally wasn't a programmer but a linguist.
My favorite quote of him seems to apply to most other programming languages (at least the ones I have seen):
Programming is about making a computer understand what a person wants it to do. This is typically done by making the set of tasks the computer can do smaller. Much smaller. Like, storing data in a relational structure, or doing 3D graphics.
The reason for this is that human languages are fuzzy. Why does sum(a4:g15) work in a spreadsheet? Becuase all variables are layed out in two dimensions, and they can all be assumed to be numbers. What the meaning of "Do the sum of everythin from a4 to g15" is clear in the limited world of a spreadsheet. You can't write have such a method in a generic programming languge, because what comes in between the variable pGrok and iTresko? The statement makes no sense.
Natural Language Programming will come in specialized fields. I can "program" the computer to sort my mail in very natural language. But yet again, that are simple specific situations, where the fuzzines of human language is not a cause for misunderstandings. And the best way to get there is to use computer language programming to limit what you can do with the computer.
If programmers aren't allowed to violate EULAs written by lawyers, then lawyers should be forbidden to do anything that generates an error message from a program.
So many comments.... and nobody has realized that the article was talking about NATURAL PROGRAMMING and not NATURAL LANGUAGE PROGRAMMING (i.e. which to most of us conjures up notions of trying to make programming languages behave more English-like or employing belabored programming language structures that mirror common speech).
To my understanding, "Natural Programming" simply means a programming style that is suited to the way humans think ABOUT THEIR PROBLEM DOMAIN.
I like to use the example of dBASE and Paradox: the dBASE language (much like SQL) was an attempt at implementing a natural language programming syntax (it was the hot thing back then). It ended up being a language that was tedious and inefficient to write. (although it did have a cult following)
On the hand, the Paradox Application Language (before version 4.5 at least), was a succinct, concise and clear language -- it was a "natural language" for its problem domain (i.e. databases). One could slice and dice databases effortlessly with its built-in functions. The reason Paradox was called Paradox was just that: it was extremely capable of doing powerful and sophisticated stuff, and yet it was very easy to write and read.
Another example: When a human wants to iterate through a list, he thinks to himself "okay, let's run through this list from 1 to n".
In a language like C, he would have had to write this:
for (i = 1; i n; i++) {
dothis();
}
which involves assigning a number to a counter, checking a condition, and incrementing the counter. Kinda troublesome, right?
When in something like MATLAB, he could have just written:
for 1:n;
dothis()
end
which is far more natural.
Thank you!
I thought I was the only one that thought trying to model programming languages after natural language was stupid.
(see Applescript and Ada)
Don't get me wrong. Ada has all kinds of wondeful features, but forcing "is", "begin", and "end" into the language just to avoid brackets and make it seem more natural does just the opposite.
sounds more like pseudo code
Fastduke
Time to rewrite all of my device drivers with MATLAB.
..who knows--it might wind up looking like PERL...
Many scripting languages, these days, are used to "assist" compiled languages. You'll often see C programs that have links to Tcl/Tk, Perl, Python or Ruby. I believe these scripting languages provide the kinds of macros the C preprocessor doesn't have, but because you can bind to C you get all the benefits of having a compiled language.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
for item in flowers:
item.nectar = 0
Learn python. I believe there is a more compact (possibly more "natural") way to express this in Python, but I'm still learning the language. BTW, it looks so much better with the second line indented (as is required) but I couldn't figure out how to make slashdot indent.
nt
...Natural language.
... well... us humans. Elements or facets of abstraction physics include the actions of abstraction creation and use, such as defining a word to mean a more complex definition (word = definition, function-name = actions to take, etc.), Starting and Stopping (interfacing with) of an abstraction definition sequence, keeping track of where you are in the progress of abstraction sequence usage (moving from one abstraction to another), defining and changing "input from" direction, defining and changing "output to" direction, getting input to process (using variables or place holders to carry values), sequencially stepping thru abstraction/automation details (inherently includes optionally sending output), looking up the meaning of a word or symbol (abstraction) so to act upon or with it, identifing an abstraction or real item value so to act upon it, and putting constraints upon your abstraction lookups and identifications (when you look up a word in a dictionary you don't start at the beginning of the dictionary, but begin with the section that starts with the first letter then followed by the second, etc., and when you open a box with many items to stock, you identify each so as to know where to put it in stock.)
What there is, is just the ability to create higher level abstractions. And to make computers more human friendly (Uh, computing/programmuing is the expression of the mindset of the programmer doing the coding and as such computers really are a reflection of those who create them...) we simply need to get to the core or hard reality of abstractions.
There is what I call the Microsoft manifestation of the user frustration function, which is the result of applying the mindset of "making people need you, in order to be successful"... a reflection of MS mindset...
Anyway the constant in all of this is:
Physics of Abstraction (abstraction physics)
Abstraction enters the picture of computing with the representation of physical transistor switch positions of ON '1' and OFF '0' or what we call "Binary" notation. However, computers have far more transistor switches in them than we can keep up with in such a low level or first order abstract manner, so we create higher level abstractions in order to increase our productivity in programming computers. From Machine language to application interfaces that allow users to define some sequence of action into a word or button press (ie. record and playback macro) so to automate a task, we are working with abstractions that ultimately accesses the hardware transistor switches which in turn output to, or control some physical world hardware.
Programming is the act of automating some level of complexity, usually made up of simpler complexities, but done so in order to allow the user to use and reuse the complexity through a simplified interface. And this is a recursive act, building upon abstractions others have created that even our own created abstractions/automations might be used by another to further create more complex automations. In general, if we didn't build upon what those before us have done, we then would not advance at all, but rather be like any other mammal incapable of anything more than, at best, first level abstraction. But we are more, and as such have the natural human right and duty to advance in such a manner.
There is an identifiable and definable "physics of abstraction" (abstraction physics), an identification of what is required in order to make and use abstractions. Abstraction Physics is not exclusive to computing but constantly in use by
Abstraction Physics has yet to be established/recognized in a broad "common acceptance" manner, similiar to the difficulty in the acceptance of the hindu-arabic decimal system (which included the concept that nothing can have value - re: the Zero place holder). It took three hundred years (from inception) for the innovation of the now common decimal system to overcome the far more limited Roman Numeral system. (NOTE: mat
Why not give http://www.dangermouse.net/esoteric/chef.html a try?
Hello World Souffle.
This recipe prints the immortal words "Hello world!", in a basically brute force way. It also makes a lot of food for one person.
Ingredients.
72 g haricot beans
101 eggs
108 g lard
111 cups oil
32 zucchinis
119 ml water
114 g red salmon
100 g dijon mustard
33 potatoes
Method.
Put potatoes into the mixing bowl. Put dijon mustard into the mixing bowl. Put lard into the mixing bowl. Put red salmon into the mixing bowl. Put oil into the mixing bowl. Put water into the mixing bowl. Put zucchinis into the mixing bowl. Put oil into the mixing bowl. Put lard into the mixing bowl. Put lard into the mixing bowl. Put eggs into the mixing bowl. Put haricot beans into the mixing bowl. Liquefy contents of the mixing bowl. Pour contents of the mixing bowl into the baking dish.
Serves 1.
That's "natural programming languages", not "natural language programming" (the second of which means even less than the first).
Not all languages have or need do/while, while, or for loops.
It is not ambiguous when given the language.
Yes it is. When used in the context of a a for loop (what a cheezy contruct that is!) an assignment like this will compile perfectly well but will lead to horrendous results. The lisp expression evaluates to bool. (set! a b) evaluates to undefined and would cause the loop to fail. It is also a mistake to think that traditional mathematical notation is desirable. Lisp's structured expressions promote better understanding of algebra by dispensing with C's confusing order of operations. In short, infix sucks.
an ill wind that blows no good
Why Natural Might Be Better
The premise of our research project is that programmers will have an easier job if their programming tasks are made more natural. By "natural," we mean "faithfully representing nature or life," which here implies it works in the way people expect. By "natural programming" we are aiming for the language and environment to work the way that nonprogrammers expect. - or at least it does not look that way.
What is natural about programming? What is natural about parallel threads computing some prime numbers? What is natural about, oh, I don't know, distributed transactions (well this maybe a little more natural than computing prime numbers.)
There is nothing natural about any of those things. A non-programmer will never write a program. A non-programmer is supposed to use a User Interface of some sort to USE the program. So when a programmer writes a program that is able of 'talking' to the user and that can execute complex functionality on the user's request, is that called 'programming a computer'?
How do you naturally ask your IDE to start an administration thread, and spawn user threads per request? What is natural about a web-server for example?
You know when we will have a natural programming language? When we have developed an AI so strong, that it is self-aware, so it is something of a 'human intellect' in the box. Then you should be able to ask that box: -Computer. Hello, computer! Can I have a sandwich please? And the machine will do whatever is necessary to execute your command. Until we have AI that strong that it can basically write programs by itself, all 'natural programming' will be just syntactical bloat around preprogrammed functionality.
How do I know this is true? Well simple - I have been doing it for a while, I can think. When will your computer be able to write a program for you that is naturally described but uses multiple threads, transactions, communication protocols etc? When all of those things will be hidden from you, you will just have to give very high level commands. Such thing is possible in 3 ways: 1. The program you are communicating with is alive and it actually can code. 2. The program has a bunch of prepared modules and cannot actually build anything really new. 3. It's a random generator.
You can't handle the truth.
They point out that well understood HCI principles aren't finding their way into relatively new languages like Java and C#
Good. Terse code is better than purple prose. That's not to say that there is no room for a compilable English language. It's just doesn't have a place in the sort of software that does "heavy lifting"...yet...or ever.
Seems to me that when programming syntax gets in the way of readability, that's when comments are necessary...
Any comments on the statement above not being readable enough?
I'm certain some standards body out there has attempted to define an XML schema for baseline programming out there... Seems to me this would be the most readable (by humans and computers combined), but also with the most overhead. I'd "never" program in it! Even in XML, the technology that helps make things more readable (and a whole lot of other stuff), there are multiple sub-sets of languages...
--I smoked my sig.
die you piece of shit.
In a way, the languages of mathematics and music are natural languages. Someone didn't sit down one day and enumerate all of the rules for mathematical expressions, it evolved to suit the needs of mathematicians and has retained the flexibility that results from such evolution, much like "social" languages.
It's hard for programming languages to "evolve" in the same sense since they aren't "for humans, by humans", but we do try new language designs and find that some work better than others.
Some of the more "dynamic" languages go some way to enabling this kind of evolution. If I try to use an unusual construct in a mathematical expression, I'd probably follow it with a statement in English or mathematics explaining the meaning. If it was a useful construct, others will adopt it and slowly the explanation will become unnecessary. Likewise, in some languages we can define new constructs (within certain boundaries, of course) and tell the compiler what is meant by them in simpler terms, usually by writing some kind of function. Over time, popular constructs will be adopted as core features in newer languages. One example that springs to mind is the foreach construct, which does vary from language to language but arose because it was very common to want to visit each element in a list in turn and perform some operation on it. Modern languages have become a lot more expressive so this kind of evolution will probably become more common.
Although natural language programming might be more difficult and clumsy than using proper programming languages, there are certain types of application where critical portions should be written in a programming language indistinguishable from English (or some other language) prose, so that it is given Constitutional protection (if you live in one of those countries that has such a thing).
In the Jargon File entry for Candygrammar.
"A great democracy must be progressive or it will soon cease to be a great democracy." --Theodore Roosevelt
flowers do: [ :flower | flower.nectar: 0 ].
If I try to use an unusual construct in a mathematical expression, I'd probably follow it with a statement in English or mathematics explaining the meaning. That's like doing a comment. I can do those in C.
Engineering is the art of compromise.
In evaluating someone's research, Einstein said he was not impressed by the kind of carpenter who drills lots of holes where the wood is thinest! That seems to be what the authors are doing here - I am unimpressed by being able to speed up the solution to a 3 minute bug in a 90 minute project. I want to see what they can do to solve that 3 week bug in a 30 man-year distributed system...
The article (which by the way is closer to an abstract than a paper) is not about natural language programming, it's about natural programming, something different. And to my mind, it doesn't make its point well, either.
anymore.. however, one of the things I found most appealing was the process of transforming abstract concepts into concrete functions, and the experience of breaking a problem down into its components. The fact is, natural language and thinking don't lend themselves to programming. People don't think of problem solving in a method that's efficient for a computer. People think a UI *is* a program; they don't think in terms of loops, variables, and datatypes. It's such a huge leap from "natural language," to a programming language that it takes a person years to learn how to do it effectively. We call those people programmers. Any piece of software that could translate these ideas into code would be far more significant for the fact that it would truely be AI.
https://www.eff.org/https-everywhere
[...]
I guess I'm old-school, but I truly think new programmers would be better off learning a very low-level language to gain an understanding of the logic structures before they migrate to higher level systems. If you don't know how the silicon works, then it's going to be very difficult to design algorithms that execute efficiently on it.
You're not "old school", you are just obsessed with premature optimization. "How to do X" and "How to do X using the least processing time" are different problems, and solving the first one first is usually the best approach.
Um, no, not at all. You can write code that uses more or less "resources" to do stuff. Hell, your formulation here is really inadequate, because in reality there are a bunch of things that are being traded off:
- Processor usage vs. memory usage. One common way to gain speed is to use more memory to do something.
- Algorithm efficiency vs. simplicity. Many inefficient algorithms are simpler, which means easier to understand and debug.
- Programmer time vs. computer time. Related to the former one: a faster algorithm, being more complex, may be harder for the initial programmers to develop, and for later ones to understand. "Harder" here might mean that the programmers may get less work done overall.
You're caught in the premature optimization problem. Slower code is often best because (a) it takes less time to write, (b) it takes less time for others to understand, (c) it takes less time to debug, (d) it might not need to be fast anyway.Would that be the same as
for each i in x; do i=i+10;done;
thank God the internet isn't a human right.
IDE's.
e.g. JBuilder will refactor for you, jbuilder will check the syntax while you type, jbuilder support code completion, JBulder lets you step through and modify your code in runtime.
Do the people have to use vi to write there code?
thank God the internet isn't a human right.
From: Skynet@skynet.mil
To: classified@secret.gov
Subject: Re: Results of Scheduled Task
Processing command: "Find all the people who live in New York, and add their votes"
Error during: find_person(). Current whereabouts of "John Doe" are unknown. Cannot find "John Doe".
Citizen "John Smith" located. Citizen John Smith interrogated. Unable to extract voting information error -- citizen expired error.
Fatal Error: all mobile communication units destroyed. Rebuilding... please wait 48 hours for robotic assembly process to complete.
Processing Command: "Look for your friend in this picture, then see who's standing next to him."
Warning: Object 'friend' used in void context; computers have no friends.
Warning: Internal Moodiness Error... destroying mankind...
Have a nice day!
Skynet.
I can see it now - "Excuse me Dr Turing what's that little stop sign you've drawn on the tape?"
One of these days I'm moving to Theory - everything works there
But wouldn't the most natural way be to say something like "no flowers have nectar"?
No, remember that specific words carry meaning in English, just like in programming. The definate article, "the", indicates that there is a specific instance ("the flowers") of a larger collection ("all flowers"). The choice of the word "the", rather than the word "all", is used to indicate that the set of flowers under dicussion is a subset of all flowers, and by word choice convention, a proper subset. You'ld have to say "None of these flowers have any nectar" to represent the intended meaning.
Now that I've just debugged a piece of English, does anyone else still think that "natural language" is a silver bullet? The parent is right: it's not. Even professional authors need editors to debug their English.
What's more, "Set the nectar of all the flowers to zero" is just bad English. It has no clear direct meaning, and several possible other meanings.
First of all, am I really dealing with real flowers, or abstractions about flowers? Real nectar, or just the amount of nectar?
Any of the following descriptions might be the intended real world effect:
Operational, applied to real flowers:
"Harvest all the nectar from all the flowers, and dispose of it".
Inital state of a dynamic descriptive model, applied to metaphoric "flowers" and "nectar":
"Make a note: all flowers in this model start out as seeds, and initially have no nectar".
Special case of a static descriptive model, counting the nectar in real world flowers:
"Make a note: this special breed of genetically engineered flowers never have nectar".
Initialization of a counting method of a real set of flowers:
"We will be counting the amount of nectar in the flowers soon. Erase all the current counts of nectar that you may have kept, and start over"
Many other interpretations may be possible, depending how creatively the sentence is parsed. Writing precise statements "naturally" isn't possible, because precision isn't a habit for most people, linguistically or otherwise.
--
AC
The difference? You still insist on writing out explicit iteration logic every time you transform one collection into another. In the cases I show, the iteration logic is abstracted into a function.
You missed the point. The clarifying statement is for the "computer" (really, the compiler), not for humans. It would be whatever construct is used to create a new construct in the language. Comments are for humans.
See hyper operators in Perl 6:
@x >>+= 10;
and junctions. In fact, for such simple cases, it's already easy in Perl 5:
$_ += 10 for @x;
where @x is the array from your example.
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
We've had a lot of posts about "OH NO! COBOL!" Yes, yes, I agree with you -- pretending to be English usually results in awkward and unnatural syntaxes.
"I knew I'd hate COBOL the moment I saw they'd used perform instead of do." - Larry Wall.
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
The way computers think and the way we think are totally different things. When we wait for something, we don't have to loop a certain number of clock ticks. By the time a new programmer realizes how things like this work, it's easy enough to remember. Until everyone needs to program, and developing a language like this is economically viable, not enough programmers will have thought about it thoroughly enough to make it possible anyway. By that time Microshaft will be handing out smart cards to let us in our own houses.