The Hundred Year Language
Charles Pritchard
http://www.paulgraham.com/hundred.html
First Paragraph:
It's hard to predict what life will be like in a hundred years. There are
only a few things we can say with certainty. We know that everyone will
drive flying cars, that zoning laws will be relaxed to allow buildings
hundreds of stories tall, that it will be dark most of the time, and that
women will all be trained in the martial arts. Today I want to zoom in on
one detail of this picture. What kind of programming language will they use
to write the software controlling those flying cars?
Arthur T. Murray
A pure language of thought will obviate the need for
http://mind.sourceforge.net/lisp.html -- LISP -- and
all the other archaic programming languages.
Some ineradicably necessary embedded systems may still use
http://mind.sourceforge.net/forth.html -- Forth-- but other
programming languages will have been replaced with neurons.
Mentifex
--
http://mentifex.futureai.com/theory5.html -- AI4U Theory of Mind;
http://mentifex.futureai.com/jsaimind.html -- Tutorial "Mind-1.1"
http://mentifex.futureai.com/mind4th.html -- Mind.Forth Robot AI;
http://mentifex.futureai.com/ai4udex.html -- Index for book: AI4U
Peter Lawrence
There will be an emulator, or a nested set of them, all running some mix and
match untested combination of machine code from some obsolete systems that
have had their source code lost. Only the topmost emulators will have any
source code at all, and they will only have some sort of thin wrapper in a
scripting language wrapping a whole load of snippets of machine code - again,
passed down from time immemorial in the same way. (I once heard that the
classic game "Adventure" was migrated to new systems in much this way, with
no remaining original source code from the systems that first hosted it but
only their machine code.)
It's like something I heard about the Tasmanian aborigines: apparently they
had lost the secret of making fire from scratch and could only ever light
fires from ones they had kept burning. PML.
--
GST+NPT=JOBS
I.e., a Goods and Services Tax (or almost any other broad based production
tax), with a Negative Payroll Tax, promotes employment.
See http://users.netlink.com.au/~peterl/publicns.html#AFRLET2 and the other
items on that page for some reasons why.
Charles Pritchard
"but other programming languages will have been replaced with neurons."
In one way, the machine code is generated randomly, through the usual means
of breed and mutate -- in another it was created by an inteligent being and
later evolved through something akin to genetic manipulation. snip.
Personally, I think our own inteligence has firm foundations, and that
artificial inteligence will be based upon many of them. You can write
millions of lines of codes to handle the various situations an "inteligent"
car would face while driving down the road, or you can cheat, and simply
tell the car that you want to get to point A to point B without breaking
traffic laws nor killing anyone.
Maybe this is only tasteful to Arthur -- A human child needs the attention
and nurturing of a parent to survive past infancy. To become a functional
member of society it needs over a decade of this. Barring dogmatic
advantages, the blank slate takes a decade to program. Think of the hours
involved.
When I look at everything I do on the Internet now, I see that it was
possible in the earliest days of the internet, the features that have been
built since have only served as abstractions -- to make the solutions seem
more abstract than they are. We've scaled our languages to practical basics.
The primitives have been discovered through the scientific method. Thus I
think post question is really a syllogism, though the author does patronize
the languages that have settled on the natural primitives. I take it as a
misnomer. What this author meant to say is, what will computer interfaces be
like in one hundred years.
"Peter Lawrence" <pet...@netlink.com.au> wrote in message
news:3E9A28...@netlink.com.au...
> Charles Pritchard wrote:
> >
> > The article is a bit long, but I thought it was a good read:
> > http://www.paulgraham.com/hundred.html
> >
<snip>
Jerry Avins
I'm not sure about those flying cars. Ox carts seem to me as likely. Or
teleportation of a sort. Edward Bellamy predicted in 1887 that in 100
years, there would be mass distribution of live music for the masses by
telephone, one earpiece to a listener. Neither wireless nor loudspeakers
had occurred to him.
Jerry
--
Engineering is the art of making what you want from things you can get.
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ
Paul Boddie
>
[Charles Pritchard quoting Paul Graham's predictions of the future]
> > women will all be trained in the martial arts.
[...]
> Edward Bellamy predicted in 1887 that in 100 years, there would be mass
> distribution of live music for the masses by telephone, one earpiece to a
> listener. Neither wireless nor loudspeakers had occurred to him.
It seems to me that the chain of influence here is:
Edward Bellamy -> Flaming Lips -> Paul Graham
;-)
Paul
andr...@littlepinkcloud.invalid
> I'm not sure about those flying cars. Ox carts seem to me as
> likely.
Yeah. :-)
> Or teleportation of a sort. Edward Bellamy predicted in 1887
> that in 100 years, there would be mass distribution of live music
> for the masses by telephone, one earpiece to a listener. Neither
> wireless nor loudspeakers had occurred to him.
But that's pretty good, isn't it? Bellamy seems to have predicted the
entertainment industry, and that's what's important. Technical
details like radio propagation and loudspeakers are surely relatively
unimportant.
We have to allow for the possibility of huge breakthroughs. Marconi's
invention was in 1895...
Andrew.
andr...@littlepinkcloud.invalid
> The article is a bit long, but I thought it was a good read:
> http://www.paulgraham.com/hundred.html
It's surprising that Graham writes that "McCarthy's 1960 paper was
not, at the time, intended to be implemented at all. It was a
theoretical exercise, an attempt to create a more elegant alternative
to the Turing Machine." This seems to be contradicted by McCarthy's
own account in HOPL, where he wrote "I decided to write a paper
describing LISP both as a programming language and as a formalism for
doing recursive function theory." At that time, McCarthy already had
an implementation.
http://www-formal.stanford.edu/jmc/history/lisp/lisp.html
Andrew.
Astrobe
That's obvious. A language to program quantic computers.
What would be a quantic programming language?
Amicalement,
Astrobe
Lars Brinkhoff
> > http://www.paulgraham.com/hundred.html
> It's surprising that Graham writes that "McCarthy's 1960 paper was
> not, at the time, intended to be implemented at all. It was a
> theoretical exercise, an attempt to create a more elegant
> alternative to the Turing Machine." This seems to be contradicted
> by McCarthy's own account in HOPL, where he wrote "I decided to
> write a paper describing LISP both as a programming language and as
> a formalism for doing recursive function theory." At that time,
> McCarthy already had an implementation.
If there was an implementation of LISP at that time, it used the
M-expression syntax.
A few paragraphs below your quote from the McCarthy paper:
S.R. Russel noticed that eval could serve as an interpreter for
LISP, promptly hand coded it, and we now had a programming language
with an interpreter.
This was the first implementation of what we consider LISP today.
--
Lars Brinkhoff, Services for Unix, Linux, GCC, PDP-10, HTTP
Brinkhoff Consulting http://www.brinkhoff.se/
andr...@littlepinkcloud.invalid
> andr...@littlepinkcloud.invalid writes:
>> > http://www.paulgraham.com/hundred.html
>> It's surprising that Graham writes that "McCarthy's 1960 paper was
>> not, at the time, intended to be implemented at all. It was a
>> theoretical exercise, an attempt to create a more elegant
>> alternative to the Turing Machine." This seems to be contradicted
>> by McCarthy's own account in HOPL, where he wrote "I decided to
>> write a paper describing LISP both as a programming language and as
>> a formalism for doing recursive function theory." At that time,
>> McCarthy already had an implementation.
> If there was an implementation of LISP at that time, it used the
> M-expression syntax.
> A few paragraphs below your quote from the McCarthy paper:
> S.R. Russel noticed that eval could serve as an interpreter for
> LISP, promptly hand coded it, and we now had a programming language
> with an interpreter.
> This was the first implementation of what we consider LISP today.
Okay, but I can't see how anyone can square "McCarthy's 1960 paper was
not, at the time, intended to be implemented at all. It was a
theoretical exercise" and McCarthy's own "I decided to write a paper
describing LISP both as a programming language and as a formalism for
doing recursive function theory."
Andrew.
Lars Brinkhoff
> Okay, but I can't see how anyone can square "McCarthy's 1960 paper
> was not, at the time, intended to be implemented at all. It was a
> theoretical exercise" and McCarthy's own "I decided to write a paper
> describing LISP both as a programming language and as a formalism
> for doing recursive function theory."
No, you have to read other papers to find that information.
andr...@littlepinkcloud.invalid
> andr...@littlepinkcloud.invalid writes:
>> Okay, but I can't see how anyone can square "McCarthy's 1960 paper
>> was not, at the time, intended to be implemented at all. It was a
>> theoretical exercise" and McCarthy's own "I decided to write a paper
>> describing LISP both as a programming language and as a formalism
>> for doing recursive function theory."
> No, you have to read other papers to find that information.
Perhaps, but McCarthy's HOPL paper is intened to be authoritative, and
therefore if I see a contradiction between that paper and any other I
tend to discount the other paper. It's a basic dictum of history to
prefer primary sources.
Andrew.
Jerry Avins
I don't fault Bellamy -- at age 70, I do a little "Looking Backward"
myself -- but I'm sure that 100-year predictions hold too little promise
to be worth troubling with. I don't mind others having fun. I hope they
don't mind my laughing.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
jmdrake
> I'm not sure about those flying cars. Ox carts seem to me as likely. Or
> teleportation of a sort. Edward Bellamy predicted in 1887 that in 100
> years, there would be mass distribution of live music for the masses by
> telephone, one earpiece to a listener. Neither wireless nor loudspeakers
> had occurred to him.
>
> Jerry
Maybe he was predicting streaming MP3s going over the phone system. ;)
Regards,
John M. Drake
m-coughlin
> There will be an emulator, or a nested set of them, all running
> some mix and match untested combination of machine code
> from some obsolete systems that have had their source code
> lost. Only the topmost emulators will have any source code at
> all, and they will only have some sort of thin wrapper in a
> scripting language wrapping a whole load of snippets of
> machine code - again, passed down from time immemorial in
> the same way. (I once heard that the classic game
> "Adventure" was migrated to new systems in much this way,
> with no remaining original source code from the systems that
> first hosted it but only their machine code.)
A don't think a program propagated by writing emulators for
obsolete machine code is going to be used for very long.
Certainly not a hundred years. There is little problem in
finding an early original Fortran source for Adventure.
http://www.star.net/People/~rayshoop/advensrc.zip
A write-up for its history is also easily found
http://www.rickadams.org/adventure/a_history.html
The ultimate programming will always be done in a natural
language, like English. The problem will be how to translate
from an imprecise human understandable language to boringly
precise mechanical operations that a machine will follow.
I was frustrated when playing the old original adventure
game since I didn't have the source code so I didn't know how to
cheat. I think I'd rather play it by reading the source than
running it on a DEC PDP. Unfortunately life is too short for me
to translate the Fortran into Forth for current computers.
--
Michael Coughlin m-cou...@attbi.com Cambridge, MA USA
Jerry Avins
>
...
> The ultimate programming will always be done in a natural
> language, like English. The problem will be how to translate
> from an imprecise human understandable language to boringly
> precise mechanical operations that a machine will follow.
>
Aye, there's the rub. Programs will be built from natural language
specifications instead of code about the same time that bridges are
built from natural language specifications instead of drawings. Of
course, in 100 years, both may happen. We may even create art that way.
Jerry
--
Engineering is the art of making what you want from things you can get.
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ
andr...@littlepinkcloud.invalid
> m-coughlin wrote:
>>
> ...
>> The ultimate programming will always be done in a natural
>> language, like English. The problem will be how to translate
>> from an imprecise human understandable language to boringly
>> precise mechanical operations that a machine will follow.
>>
> ...
> Aye, there's the rub. Programs will be built from natural language
> specifications instead of code about the same time that bridges are
> built from natural language specifications instead of drawings.
Yup. Projects promoting programming in "natural language" are
intrinsically doomed to fail. [*] We don't use natural language to do
programming and we don't use natural language to do mathematics for
the same reason.
Andrew.
[*] A gold star to everyone who knows where that's from...
Brian Fox
This 'telephone' has too many shortcomings to be seriously considered as a
means of communication. The device is inherently of no value to us.
By: Western Union internal memo 1871
Brian Fox
London Ont. Canada
"Jerry Avins" <j...@ieee.org> wrote in message
news:3E99A17B...@ieee.org...
> ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Marcel Hendrix
> Predicting the future of technology is hard for some. See below.
> This 'telephone' has too many shortcomings to be seriously considered as a
> means of communication. The device is inherently of no value to us.
> By: Western Union internal memo 1871
- It is not difficult to spot great inventions with tremendous potential.
- It is very difficult to classify great ideas that will never work, or to
spot the parts that have great potential in a pile of rubbish.
Unfortunately, in practice there is no difference between the above two
statements.
E.g., crackpot idea #1: Future ICs will have on-chip high speed micro
gasturbines that directly convert biogas to electricity. Instead of
a powersupply (300Apeak at 0.3V), portable devices have a little
refillable gascilinder.
-marcel
Peter Lawrence
>
> Peter Lawrence wrote:
>
> > There will be an emulator, or a nested set of them, all running
> > some mix and match untested combination of machine code
> > from some obsolete systems that have had their source code
.
.
> A don't think a program propagated by writing emulators for
> obsolete machine code is going to be used for very long.
I don't think it should, I just think that it could and with a dash of
Murphy's Law, the proportion of code being handled in a cargo cult
fire-from-the-gods way will go up quite a lot. After all, there is something
of that in today's compilers - Ritchie, I think it was, showed how trojans
could be perpetuated through compilers that way, and someone told me that /n
has no original source code in C compilers right now. (For the purposes of
this argument, the factual accuracy of that last isn't as important as
whether it is realistic, consistent with coding possibilities as opposed to
physically existing.)
> Certainly not a hundred years.
On that one, I'd simply go for how often temporary botches turn permanent,
partly because people grow used to them. (I'll stop before I get into an OT
whinge.) So a century is certainly possible. But I don't think I'll be in a
position to tell. PML.
Dave Thompson
<pet...@netlink.com.au> wrote:
>m-coughlin wrote:
[snip]
>> A don't think a program propagated by writing emulators for
>> obsolete machine code is going to be used for very long.
>
>I don't think it should, I just think that it could and with a dash of
>Murphy's Law, the proportion of code being handled in a cargo cult
>fire-from-the-gods way will go up quite a lot. After all, there is something
>of that in today's compilers - Ritchie, I think it was, showed how trojans
>could be perpetuated through compilers that way,
Ken Thompson, recounted in his Turing Award lecture
http://www.acm.org/classics/sep95/
He credits the idea to the Air Force (RADC?) security analysis of
Multics somewhat earlier. According to folks on alt.os.multics,
(a version of?) that paper was resurrected for a recent conference,
IIRC ACSAC 02.
+ and someone told me that /n
>has no original source code in C compilers right now. (For the purposes of
>this argument, the factual accuracy of that last isn't as important as
>whether it is realistic, consistent with coding possibilities as opposed to
>physically existing.)
>
I'm not sure who /n is supposed to be, or if this is important.
- David.Thompson1 at worldnet.att.net
m-coughlin
>
> On Fri, 18 Apr 2003 10:09:49 GMT, Peter Lawrence
> <pet...@netlink.com.au> wrote:
>
> >m-coughlin wrote:
> [snip]
> >> A don't think a program propagated by writing emulators for
> >> obsolete machine code is going to be used for very long.
> >
> >I don't think it should, I just think that it could and with a dash
> >of Murphy's Law, the proportion of code being handled in a
> >cargo cult fire-from-the-gods way will go up quite a lot.
> >could be perpetuated through compilers that way,
>
> Ken Thompson, recounted in his Turing Award lecture
> http://www.acm.org/classics/sep95/
[snip]
Ken Thompson's above paper (Reflections on Trusting Trust)
is very interesting. I particularly like his statement "You
can't trust code that you did not totally create yourself.
(Especially code from companies that employ people like me.) ".
Now if we keep improving our methods for writing
do-it-yourself Forth systems, perhaps Forth will gain a
reputation for being good for security.
jonah thomas
> The article is a bit long, but I thought it was a good read:
> http://www.paulgraham.com/hundred.html
So, what does it take to write a very short program in Forth that
reproduces its source code?
My first thought is to put on block 1000
1000 LIST
And then when you do 1000 LOAD it prints its source to the screen.
Similarly you could have a string that goes SOURCE TYPE and if you
EVALUATE the string it prints itself.
What would it take to find a solution more like the one in the paper?
Charles Pritchard
seen it before on another website.
I honestly don't see the attraction. Either it can be solved via syntactical
sugar or by some silly string manipulation.
Apropos, neural networks, evolution of code, etc accomplish a similar feat
but with a more enticing promise.
The construction of an advanced system through random mutation of its
initial state.. Order from chaos, a miracle documented by science.
I'd like to see a virus that genuinely mutates predicting the survival of
offspring before expending energy (after all, you don't want to kill your
host).. Maybe these tricks were creative thirty years ago, but personally
I've been disillusioned by outlook express "virii". I think we all like to
see applications that are spiffy.
Do any of you have similar resources?
-Charles
"jonah thomas" <j2th...@cavtel.net> wrote in message
news:3EAF3F7D...@cavtel.net...
Marcel Hendrix
> Charles Pritchard wrote:
> 1000 LIST
Starting Forth, Chap. 10, p. 258:
------8<-------
TIB #TIB @ TYPE
------8<-------
-marcel
PS: It's online.
Samuel Tardieu
Marcel> TIB #TIB @ TYPE
Better (ANSI): SOURCE TYPE
Sam
--
Samuel Tardieu -- s...@rfc1149.net -- http://www.rfc1149.net/sam
Marcel Hendrix
>>>>>> "Marcel" == Marcel Hendrix <m...@iae.nl> writes:
> Marcel> TIB #TIB @ TYPE
> Better (ANSI): SOURCE TYPE
Minor point:
You mean: *also* ANSI, and more general.
I rejected the SOURCE line because it was not supporting
my second point.
-marcel
rickman
A friend of mine had this assignment as homework in a programming
class. I think the point was that you were not intended to simple imbed
the source in a file or other storage and print it back out. That is
not so hard in *any* language. The idea, as least in the class he was
taking, was to use recursion as a way to regenerate the program.
I was still learning 'C' at the time and could just barely find my way
past a pointer, so I have no idea what it took to make it work.
--
Rick "rickman" Collins
rick.c...@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.
Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX
Stephen Pelc
wrote:
>Charles Pritchard wrote:
>
>> The article is a bit long, but I thought it was a good read:
>> http://www.paulgraham.com/hundred.html
>
>So, what does it take to write a very short program in Forth that
>reproduces its source code?
: ENIUQ cr source type cr source type refill drop 0 word drop cr ;
ENIUQ
: ENIUQ cr source type cr source type refill drop 0 word drop cr ;
ENIUQ
Allowing for the vagaries of newsreaders, there are two lines
of the form:
: ENIUQ ... ; ENIUQ
For pre-ANS and BLOCK fans, here is the original code.
==========
((
From FORTH Dimensions II/5 page 140
Contributed by Lyall Morrill, San Francisco, CA
Self-reproducing source code in two lines of Forth
When loaded, types a copy of itself.
See "Godel, Escher, Bach: An Eternal Golden Braid", by
Douglas R. Hofstadter, Basic Books, Inc. 1979, p. 498
))
: ENIUQ CR 34 WORD COUNT 2DUP TYPE CR TYPE 34 EMIT ; ENIUQ
: ENIUQ CR 34 WORD COUNT 2DUP TYPE CR TYPE 34 EMIT ; ENIUQ"
==========
Stephen
--
Stephen Pelc, s...@mpeltd.demon.co.uk
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads
Stephen Pelc
wrote:
>So, what does it take to write a very short program in Forth that
>reproduces its source code?
And the one liner is:
: ENIUQ cr source type 0 word drop ; ENIUQ
Jerry Avins
only works as it's loaded. Later invocations of ENIUQ print only the
name. One might as well enter it interactively. The interactive version
is simply
source type
I guess it can't be done with one word alone.
Segher Boessenkool
> Charles Pritchard wrote:
>
>> The article is a bit long, but I thought it was a good read:
>> http://www.paulgraham.com/hundred.html
>
> So, what does it take to write a very short program in Forth that
> reproduces its source code?
It takes nothing (literally): an empty input program
will do just fine ;)
Segher
m-coughlin
A non silly challenge would be more interesting. How do you
write the source to a small Forth development system that
reproduces its object code (compiles itself)? Or reproduces its
object code but running at a different address? Or takes the
source of a whole Forth system plus an application and
reproduces the application's object code without whatever part
of the Forth development system is not needed?
Bernd Paysan
> : ENIUQ cr source type 0 word drop ; ENIUQ
> only works as it's loaded. Later invocations of ENIUQ print only the
> name.
If you want it to work later again, do that:
: eniuq cr [ source ] SLiteral type ; eniuq
The typical way to do it however is to prepare a word like (all one line):
: eniuq cr s" : eniuq cr s% 2dup bounds ?DO I c@ 37 = IF 34 emit space type
34 emit ELSE I c@ emit THEN ; eniuq" 2dup bounds ?DO I c@ 37 = IF 34 emit
space type 34 emit ELSE I c@ emit THEN ; eniuq
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Bruce Hoyt
"Bernd Paysan" <bernd....@gmx.de> wrote in message
news:be849b...@cohen.paysan.nom...