I didn't mean that the language standard contain those libraries, but merely that there exist standard, widely available, portable implementations
I'm not convinced that there are actually standard, portable socket, GUI, even regexp, libraries for C. There are certainly some that are portable across Unices, or from Unix to Windows, but I wouldn't call those standard (nor working, in most cases).
While the ANSI CommonLisp standard is one of the larger standards around, it is amazingly deficient in nailing implementations down enough to let programmers write efficient, portable, robust code.
Of course, many people believe that vagueness is a strength, allowing vendors to innovate some in their implementations.
I want a simple language definition, low-cost implementations, interoperable multi-vendor implementations, reasonable performance, runtime safety, interactive development, and a large set of libraries.
CL gives you half the items on the list, and I would argue Java is missing interactive development and that mutli-vendor anything is still a big problem.
I think his main point was that functional languages are sorely lacking when it comes to the representation of concepts beyond those found the lamba-calculi. For example, the common objects-passing-messages idea is a far better suited, conceptually, to some problems than the lambda calculus; similarly, lambda is better for many things than OOP. Imperative languages are more natural in some cases than declarative, and vice versa. It's true that you could implement anything in anything, but it's easier to think about some things in certain ways (e.g., it's easier to think about the world as composed of objects than to use quantum mechanics when your trying to make breakfast). Lisp provides almost every paradigm you could imagine, and in this regard I think it's ahead of functional languages.
lack of evolution of the standard and language, lack of standardization
We have a standard, and implementations try as hard as they can to follow it. The standard doesn't need evolutions; it's already ahead of any other ANSI language standard I know of, and certainly better than following Sun's whims.
CMU CommonLisp finally gets released with multithreading
AFAIK, the x86 port has threading.
the language is brought into the 00's
Meaning...? You seem to have caught a serious case of Java-itis: symptoms include conflating languages, libraries, and implementations, and believing that everything in the universe should be included in one of the three.
include regular expressions
I don't see why this should be in the standard. In a language like Perl, where text manipulation is the norm, it makes sense. Everywhere else it's just bloat.
XML
Ditto. XML parsing is an application of a language, not a part of a language. If you really want to play with XML, use XSL; otherwise, write your own library and keep the language small.
sockets
I would really like to see sockets as well, but I would rather have generalized streams (across sockets, FIFO's, pigeons, whatever). You also face the problem of defining sockets; e.g., would you include local (Unix-domainish) datagram sockets, which may not be available on some systems?
HTML parsing
This is a non-issue. HTML parsing doesn't belong in any language not defined by W3C, and in any case HTML is supposed to be dead in a few years, when XHTML replaces it.
Internet protocols
...should be handled by the OS, or implementation. At most, you should just be able to open a stream to an address and read from it; there's no reason to expose the protocols to the user.
graphics
No, absolutely not.
binary I/O
Have it, or as much as I want.
other common features
Sorry? Since when are XML, regexps, sockets, and graphics "common" feature in language specs? My copy of the C standard must be missing some headers....
Then, perhaps, the fact that it runs about 10x faster than common scripting languages might start attracting users again.
I'd rather Lisp hang on the edge of oblivion than come back as a scripting language.
Common Lisp is a standard. "Open" is just an invitation to change the standard.
...also has free quality open source compilers and interpreters which adhere to the open standard.
CMUCL, SBCL, and CLISP and all reasonably close to ANSI. CMUCL is probably one of the highest quility compilers on Earth.
...uses lazy reduction, which means that a wider variety of functions normalize, as opposed to strict reduction.
This is more a matter of taste than most people care to admit. If you really want laziness, you can build it, as in Scheme.
...is purely functional, which leads to more elegant and easier to understand programs. Formal analysis is allot easier when the language is purely functional as opposed to polluted.
Sometimes that is the effect, but often it isn't; I don't consider IO monads easier to understand than s/foo/Foo/, for example. It doesn't really matter anyway, since you can write purely functional programs in Lisp.
...allows for imperative or procedural features through the use of monads. So you can have your cake (purity) and eat it too (imperative/procedural aspects).
I've never liked monads; frankly, they seem like a hack, and they spoil the conceptual simplicity. You can get the same effects through, e.g., uniqeness typing, without so much syntactic and sematnic baggage. Variable functions are even better, but you probably wouldn't like the "impurity".
...uses function currying to ease the use of higher order functions and to decrease the reliance of all those damn parenthesis!
Currying is spiffy, and imagine it will eventually make it into a major Lisp. I believe I've actually seen curried Scheme, somewhere (and, actually, I starting writing one, once). And I like parenthesis.
...is statically typed and uses type inference too, so you don't even have to explicitly tell the compiler what types you are using. It can do all the dirty work for you, yet still give you very high automatic assurance of program correctness.
Static vs dynamic typing is a matter of taste. Some people like the extra checking, some people don't, and some people don't need it (oddly enough, these tend to Lisp and Smalltalk hackers). The only type errors I can recall making in Lisp recently involve putting the wrong number of d's in cad*r. I'm not having trouble, so why should I throw extra code at a problem that doesn't exist?
...is simply better designed. Its syntax, semantics, and APIs are more simple, consistant, and pure than Lisp and its many incarnations.
Mixed prefix and infix notation is not simple, consistent, or pure.
So, I ask my question: Why fear new and better things? Why do people keep ranting about the virtues of an outdated programming language, when there are better alternative standard functional programming languages?
Faster for some problems. My understanding is that quantum computers are not Turing-equivalent, and that their stengths complement conventional computers well, but cannot replace them. Their destiny seems to be as co-processors for more general machines, with all the autonomy we've come to expect from an x87 FP unit.
How about because he probably understands that the Senate killed Kyoto before Bush got anywhere near it? Bush couldn't ratify the treaty if he wanted to.
And other course Cyberdyne orignally comes from the Terminator movies, which probably everyone has seen. IIRC, Cyberdyne's baby, Skynet, was a military computer that destroyed the world after humanity realized that its wasn't a terribly good idea to have a giant computer with a sense of self-preservation controlling all of our nukes. (This is an old plot, but a nifty name;-)
The portion of in_systm.h he's referring to is below. The only code if some network-order typedefs that aren't used by the kernel, but provided for BSD-compatibility. IMO, this is code for the purpose of the GPL. or would be were it used.
/*
* INET An implementation of the TCP/IP protocol suite for the LINUX
* operating system. INET is implemented using the BSD Socket
* interface as the means of communication with the user level.
*
* Miscellaneous internetwork definitions for kernel.
*
* Version: @(#)in_systm.h 1.0.0 12/17/93
*
* Authors: Original taken from Berkeley BSD UNIX 4.3-RENO.
* Fred N. van Kempen, <waltje@uwalt.nl.mugnet.org>
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version
* 2 of the License, or (at your option) any later version.
*/
Note that it states that the file is GPLed, with no mention of the BSD license or, in fact, of the BSD copyright ("original taken from" is not a copyright notice that I'm familiar with). I assume that they got permission to do this, or the the file was public-domain, especially since (I'm almost certain) 1993 pre-dates the removal of the advertising clause in the BSDL, which might have been sufficient reason to avoid using the file altogether. I can really see them stealing the header and leaving attribution, either.
As you can see, the Alpha has a slight lead in peak int, a very close base int, and, of course, is far ahead in fp. The Athlon is all over the place, managing to beat the P4 in peak integer speed. The really important lesson, though, is that benchmarks are crap. The P4 is no where near 20% faster (or whatever, math is the first thing to go when my brain shuts off for the night) than an Athlon on any other benchmarks I've seen, nor in the experience of anyone I've heard from. In the "real world" benchmarks -- that is, games for the most part -- the P4 has been closer to 20% slower (except in Quake III, for whatever reason). Those results are probably crap too.
My own uninformed belief is that the relationship is more like P4 > Athlon > Alpha in integer, and Alpha > P4 == Athlon in fp, and that somewhere out there are chips that beat all of them, from manufacturers that have better things to do than make up numbers about their products.
A lot of young coots too. Even in relatively urbanized Oregon (more than Montana, anyway), I knew several kids in high school without phone service. Most of them lived out of town in distant valleys and whatnot, but even some people in town -- in apartments even -- went without, usually because they couldn't afford it. (I gathered that this was mostly a lack of self-control when it came to long-distance, though.) And thanks to cheap, available cellphone service, none of those people will probably see POTS again.
If it was DR1 or 2, then it was just before Apple dropped x86 support. My hunch is that they stopped development at that time also, or moved it well underground. I'm not certain, but I believe that pre-dated Quartz and Aqua, as well.
They aren't spies. Spies usually try to discover secret stuff while not being noticed; in this case, they were flying regular routes for years listening to radio transmissions and looking for radar sites. I'd call it (usually) dull recon duty.
Arm the military with dubious human rights records
I don't know what this means, but it sound wrong;-)
I hope that hot head Bush sends in a rescue mission into China to rescue the US "hostages" and gets his ass kicked with a warhead on the WhiteHouse.
No, you don't. No matter how a rescue mission turned out, it's a good bet that the end result you be a large portion of the planet being transformed into a decorative glass bowl. (OTOH, then I might get my power armor and gauss gattling gun!;-)
RFCs 3091 (Pi Digit Generation Protocol) and 3092 (Etymology of "Foo") are also available. Looking over the comments here, they're probably funnier, too.
You're overestimating the potential impact of quantum computers. Unless something's changed since I stopped paying attention, QCs are Turing-equivalent -- no more, possibly less. At best, they're nondeterminstic (or do a good impression), but that's hardly a breakthough for theory. Everything we know about algorithms, formal languages, and computation still applies. On the other hand, they're hard to build, fragile, and almost useless as general purpose computers (I haven't yet heard developed proposal for I/O, which is vital to just about everything most computers do).
I'm running under 4.0.2 just fine, w/AA fonts in KDE/qt2.3. NVidia's readme actually says 4.0.1 and up are support; maybe this changed in last week's release.
"In benchmark testing using just a few spoken words"
And why did the benchmark only involve a few words? Because that's all it can
recognize. This thing isn't doesn't do speech recognition, it does sound recognition; IIRC, it can only handle single syllables words, and only four or five at that, and no sound-alikes. (I think "yes" and "no" were half its vocabulary.) It might be breakthrough for such a small ANN, but it's not that useful as a natlang system. I suppose something similar could make a good front-end to more complete system, though.
AI is not advancing by leaps and bounds. In fact, I
don't think there's been a really significant development
in AI in years -- everyone is just working on getting
their current systems doing what they want.
People have this impression that because chips are
getting faster, and more software is in circulation, the
practice must be advancing at a tremendous rate. It's
ain't. Advances in software are few and far between,
and take decades to become widely accepted
(think OO, or functional programming). The quality of
software hasn't improved much, and may even have dropped
some. Complexity is up, but it's mostly the result
of bloat on existing systems and not the gobs of new
functionality. Even hardware isn't moving that quickly
if look at architectures; how long have the basic IA32,
Sparc, MIPS, etc, designs been around?
AI is, if anything, worse off. It's both a software field
and a science with close ties to psychology. It's stuck
with both to sad state of engineering, and the slow,
evolutionary methods of science. The appearance that AI is quickly advancing is mostly the result of poor reporting
and confusion between the actual state and predicted state
of the art. Every time some looney writes a book about
nano-AI's taking over the world, that story gets run on/. and a billion other places and people come away with the
impression that we're on the verge of having little AI's. We aren't. We aren't even on the verge of big AI's. Assuming we can actually build one -- and that's still a huge if -- it'll be decades, maybe centuries, and it's will probably be far more alien than anyone gives AI credit for.
Well, at least this explains why the only Score:5 post in this discussion is a troll: because there are honest people like yourself who probably get moderator points regularly but who just don't know better.
Well, I do think the info about QNX was "informative" (though not worth +5). Small OSes tend to have small lists of compatible hardware, and I rather not spend a day trying to install something just to find out if it'll work on my machine. QNX is advertised as being better than most in this area, and I was glad to see some confirmation.
"How so? He's pointing out that an operating system these days should be able to detect new hardware as it is added to the system."
Yes, but he's doing so in a way that implies that hardware autodetection will just reach Linux for the first time in Debian 2.3/3.0!
Funny, when he said "Corel did a good job on my P75, but it's all stock hardware." I assumed he was talking Linux and not, say, Word Perfect. My mistake, I guess.
Just objects with plug-compatible connectors, kind of like ICs.
Er, you'd think than the hardware engineers would have stumbled across this idea, considering it's they're job to put little IC's together. Oh, wait, I bet they did....
The primitive objects should just be sensors and effectors which can be connected together into higher level objects.
How does this work, exactly? How do I set up some sensor so that it knows what to look for if you won't allow me any sort of programming language? You can't expect people to build a mountain of objects -- without being able to configure any of them -- just so they can tell when someone has finally given up on the system starting and hit ^C.
Just drop them in and they find the right connections, automatically and reliably.
Of course, this sort of automatic programming has never worked. And even if it did work you'd never be able to prove it, because all of the vast resources computer science has devoted to proving program correctness assume that you have some idea of what the program is actually doing, and that you can translate it into a logical (that is, linguistic) framework.
Programming for the masses!!
Oh, great. I hope that isn't supposed to win over any converts. The "masses" have never been terribly enthusiastic about programming, and most of those who are, can't.
Slashdot Mirror
I'm not convinced that there are actually standard, portable socket, GUI, even regexp, libraries for C. There are certainly some that are portable across Unices, or from Unix to Windows, but I wouldn't call those standard (nor working, in most cases).
While the ANSI CommonLisp standard is one of the larger standards around, it is amazingly deficient in nailing implementations down enough to let programmers write efficient, portable, robust code.
Of course, many people believe that vagueness is a strength, allowing vendors to innovate some in their implementations.
I want a simple language definition, low-cost implementations, interoperable multi-vendor implementations, reasonable performance, runtime safety, interactive development, and a large set of libraries.
CL gives you half the items on the list, and I would argue Java is missing interactive development and that mutli-vendor anything is still a big problem.
I think his main point was that functional languages are sorely lacking when it comes to the representation of concepts beyond those found the lamba-calculi. For example, the common objects-passing-messages idea is a far better suited, conceptually, to some problems than the lambda calculus; similarly, lambda is better for many things than OOP. Imperative languages are more natural in some cases than declarative, and vice versa. It's true that you could implement anything in anything, but it's easier to think about some things in certain ways (e.g., it's easier to think about the world as composed of objects than to use quantum mechanics when your trying to make breakfast). Lisp provides almost every paradigm you could imagine, and in this regard I think it's ahead of functional languages.
We have a standard, and implementations try as hard as they can to follow it. The standard doesn't need evolutions; it's already ahead of any other ANSI language standard I know of, and certainly better than following Sun's whims.
CMU CommonLisp finally gets released with multithreading
AFAIK, the x86 port has threading.
the language is brought into the 00's
Meaning...? You seem to have caught a serious case of Java-itis: symptoms include conflating languages, libraries, and implementations, and believing that everything in the universe should be included in one of the three.
include regular expressions
I don't see why this should be in the standard. In a language like Perl, where text manipulation is the norm, it makes sense. Everywhere else it's just bloat.
XML
Ditto. XML parsing is an application of a language, not a part of a language. If you really want to play with XML, use XSL; otherwise, write your own library and keep the language small.
sockets
I would really like to see sockets as well, but I would rather have generalized streams (across sockets, FIFO's, pigeons, whatever). You also face the problem of defining sockets; e.g., would you include local (Unix-domainish) datagram sockets, which may not be available on some systems?
HTML parsing
This is a non-issue. HTML parsing doesn't belong in any language not defined by W3C, and in any case HTML is supposed to be dead in a few years, when XHTML replaces it.
Internet protocols
graphics
No, absolutely not.
binary I/O
Have it, or as much as I want.
other common features
Sorry? Since when are XML, regexps, sockets, and graphics "common" feature in language specs? My copy of the C standard must be missing some headers....
Then, perhaps, the fact that it runs about 10x faster than common scripting languages might start attracting users again.
I'd rather Lisp hang on the edge of oblivion than come back as a scripting language.
Common Lisp is a standard. "Open" is just an invitation to change the standard.
CMUCL, SBCL, and CLISP and all reasonably close to ANSI. CMUCL is probably one of the highest quility compilers on Earth.
This is more a matter of taste than most people care to admit. If you really want laziness, you can build it, as in Scheme.
Sometimes that is the effect, but often it isn't; I don't consider IO monads easier to understand than s/foo/Foo/, for example. It doesn't really matter anyway, since you can write purely functional programs in Lisp.
I've never liked monads; frankly, they seem like a hack, and they spoil the conceptual simplicity. You can get the same effects through, e.g., uniqeness typing, without so much syntactic and sematnic baggage. Variable functions are even better, but you probably wouldn't like the "impurity".
Currying is spiffy, and imagine it will eventually make it into a major Lisp. I believe I've actually seen curried Scheme, somewhere (and, actually, I starting writing one, once). And I like parenthesis.
Static vs dynamic typing is a matter of taste. Some people like the extra checking, some people don't, and some people don't need it (oddly enough, these tend to Lisp and Smalltalk hackers). The only type errors I can recall making in Lisp recently involve putting the wrong number of d's in cad*r. I'm not having trouble, so why should I throw extra code at a problem that doesn't exist?
Mixed prefix and infix notation is not simple, consistent, or pure.
So, I ask my question: Why fear new and better things? Why do people keep ranting about the virtues of an outdated programming language, when there are better alternative standard functional programming languages?
Ah, I see, you're a troll. Well, bye then.
Faster for some problems. My understanding is that quantum computers are not Turing-equivalent, and that their stengths complement conventional computers well, but cannot replace them. Their destiny seems to be as co-processors for more general machines, with all the autonomy we've come to expect from an x87 FP unit.
How about because he probably understands that the Senate killed Kyoto before Bush got anywhere near it? Bush couldn't ratify the treaty if he wanted to.
Actually, its the NSA that's (supposedly ;-) involved in Echelon. I haven't heard any anything about the CIA participating.
And other course Cyberdyne orignally comes from the Terminator movies, which probably everyone has seen. IIRC, Cyberdyne's baby, Skynet, was a military computer that destroyed the world after humanity realized that its wasn't a terribly good idea to have a giant computer with a sense of self-preservation controlling all of our nukes. (This is an old plot, but a nifty name ;-)
Note that it states that the file is GPLed, with no mention of the BSD license or, in fact, of the BSD copyright ("original taken from" is not a copyright notice that I'm familiar with). I assume that they got permission to do this, or the the file was public-domain, especially since (I'm almost certain) 1993 pre-dates the removal of the advertising clause in the BSDL, which might have been sufficient reason to avoid using the file altogether. I can really see them stealing the header and leaving attribution, either.
*cough* TCP/IP *cough*
(I would say that was a joke, but the war will probably happen anyway....)
P4 1.5GHz
524 536 549 558
Athlon 1.33GHz
482 539 414 445
Alpha 833MHz (Compaq AlphaServer ES40)
518 544 590 658
As you can see, the Alpha has a slight lead in peak int, a very close base int, and, of course, is far ahead in fp. The Athlon is all over the place, managing to beat the P4 in peak integer speed. The really important lesson, though, is that benchmarks are crap. The P4 is no where near 20% faster (or whatever, math is the first thing to go when my brain shuts off for the night) than an Athlon on any other benchmarks I've seen, nor in the experience of anyone I've heard from. In the "real world" benchmarks -- that is, games for the most part -- the P4 has been closer to 20% slower (except in Quake III, for whatever reason). Those results are probably crap too.
My own uninformed belief is that the relationship is more like P4 > Athlon > Alpha in integer, and Alpha > P4 == Athlon in fp, and that somewhere out there are chips that beat all of them, from manufacturers that have better things to do than make up numbers about their products.
A lot of young coots too. Even in relatively urbanized Oregon (more than Montana, anyway), I knew several kids in high school without phone service. Most of them lived out of town in distant valleys and whatnot, but even some people in town -- in apartments even -- went without, usually because they couldn't afford it. (I gathered that this was mostly a lack of self-control when it came to long-distance, though.) And thanks to cheap, available cellphone service, none of those people will probably see POTS again.
If it was DR1 or 2, then it was just before Apple dropped x86 support. My hunch is that they stopped development at that time also, or moved it well underground. I'm not certain, but I believe that pre-dated Quartz and Aqua, as well.
tell Chinese they should return their spies
They aren't spies. Spies usually try to discover secret stuff while not being noticed; in this case, they were flying regular routes for years listening to radio transmissions and looking for radar sites. I'd call it (usually) dull recon duty.
Arm the military with dubious human rights records
I don't know what this means, but it sound wrong ;-)
I hope that hot head Bush sends in a rescue mission into China to rescue the US "hostages" and gets his ass kicked with a warhead on the WhiteHouse.
No, you don't. No matter how a rescue mission turned out, it's a good bet that the end result you be a large portion of the planet being transformed into a decorative glass bowl. (OTOH, then I might get my power armor and gauss gattling gun! ;-)
And even if it doesn't, ask an average American to explain the differences.
RFCs 3091 (Pi Digit Generation Protocol) and 3092 (Etymology of "Foo") are also available. Looking over the comments here, they're probably funnier, too.
You're overestimating the potential impact of quantum computers. Unless something's changed since I stopped paying attention, QCs are Turing-equivalent -- no more, possibly less. At best, they're nondeterminstic (or do a good impression), but that's hardly a breakthough for theory. Everything we know about algorithms, formal languages, and computation still applies. On the other hand, they're hard to build, fragile, and almost useless as general purpose computers (I haven't yet heard developed proposal for I/O, which is vital to just about everything most computers do).
I'm running under 4.0.2 just fine, w/AA fonts in KDE/qt2.3. NVidia's readme actually says 4.0.1 and up are support; maybe this changed in last week's release.
Well, the Army's new berets are going to be made in China.
Not to mention that some of those oil companies would like to be remain in business after we run out of oil.
And why did the benchmark only involve a few words? Because that's all it can recognize. This thing isn't doesn't do speech recognition, it does sound recognition; IIRC, it can only handle single syllables words, and only four or five at that, and no sound-alikes. (I think "yes" and "no" were half its vocabulary.) It might be breakthrough for such a small ANN, but it's not that useful as a natlang system. I suppose something similar could make a good front-end to more complete system, though.
People have this impression that because chips are getting faster, and more software is in circulation, the practice must be advancing at a tremendous rate. It's ain't. Advances in software are few and far between, and take decades to become widely accepted (think OO, or functional programming). The quality of software hasn't improved much, and may even have dropped some. Complexity is up, but it's mostly the result of bloat on existing systems and not the gobs of new functionality. Even hardware isn't moving that quickly if look at architectures; how long have the basic IA32, Sparc, MIPS, etc, designs been around?
AI is, if anything, worse off. It's both a software field and a science with close ties to psychology. It's stuck with both to sad state of engineering, and the slow, evolutionary methods of science. The appearance that AI is quickly advancing is mostly the result of poor reporting and confusion between the actual state and predicted state of the art. Every time some looney writes a book about nano-AI's taking over the world, that story gets run on /. and a billion other places and people come away with the
impression that we're on the verge of having little AI's. We aren't. We aren't even on the verge of big AI's. Assuming we can actually build one -- and that's still a huge if -- it'll be decades, maybe centuries, and it's will probably be far more alien than anyone gives AI credit for.
Administrative Contact:
Cinege, David dcinege@psychosis.com
100 PerCenta, Notsure Blvd.
Someplacen, FL 33300
US
954-661-7484
$ whois cinonic.com
Administrative Contact:
Cinege, David dcinege@psychosis.com
100 PerCenta, Notsure Blvd.
Someplacen, FL 33300
US
954-661-7484
Must have been hard registering the domain last April if he didn't hear about it until now. Interesting address, too.
Well, I do think the info about QNX was "informative" (though not worth +5). Small OSes tend to have small lists of compatible hardware, and I rather not spend a day trying to install something just to find out if it'll work on my machine. QNX is advertised as being better than most in this area, and I was glad to see some confirmation.
"How so? He's pointing out that an operating system these days should be able to detect new hardware as it is added to the system."
Yes, but he's doing so in a way that implies that hardware autodetection will just reach Linux for the first time in Debian 2.3/3.0!
Funny, when he said "Corel did a good job on my P75, but it's all stock hardware." I assumed he was talking Linux and not, say, Word Perfect. My mistake, I guess.
Er, you'd think than the hardware engineers would have stumbled across this idea, considering it's they're job to put little IC's together. Oh, wait, I bet they did....
The primitive objects should just be sensors and effectors which can be connected together into higher level objects.
How does this work, exactly? How do I set up some sensor so that it knows what to look for if you won't allow me any sort of programming language? You can't expect people to build a mountain of objects -- without being able to configure any of them -- just so they can tell when someone has finally given up on the system starting and hit ^C.
Just drop them in and they find the right connections, automatically and reliably.
Of course, this sort of automatic programming has never worked. And even if it did work you'd never be able to prove it, because all of the vast resources computer science has devoted to proving program correctness assume that you have some idea of what the program is actually doing, and that you can translate it into a logical (that is, linguistic) framework.
Programming for the masses!!
Oh, great. I hope that isn't supposed to win over any converts. The "masses" have never been terribly enthusiastic about programming, and most of those who are, can't.