Subroutines
Kyle Jones
> Perl has subroutines, and most of the Enterprise code is probably
> written in perl (at least it should be).
No way. A computer with smooth and logical interfaces like the
Enterprise being written in a language that's nothing short of a
a semantic and syntactic mine field?
The E's software was probably written in a Lisp derived tongue.
Arlie Davis
>The E's software was probably written in a Lisp derived tongue.
Way off! I saw a banner screen on an E's screen that had the legend
"Gnu D+=4 v263.91".
--
Arlie Davis
aldavi01@{starbase,vulcan,romulus}.spd.louisvile.edu
"My other .sig is pretty sad, too."
|grep ooga-booga >>~/.signature # Yes, this is the One True .signature Virus!
Larry Wall
: sta...@skyking.OCE.ORST.EDU (John Stanley) writes:
: > Perl has subroutines, and most of the Enterprise code is probably
: > written in perl (at least it should be).
:
: No way. A computer with smooth and logical interfaces like the
: Enterprise being written in a language that's nothing short of a
: a semantic and syntactic mine field?
Oh, gimme a break. Perl semantics are a regularization of Unix semantics.
Perl was never intended to be an ivory tower language. It's more like
a tank than a mine field. It may be ugly, but it shoots straight and
gets you where you're going, if you don't mind a few squashed daisies.
: The E's software was probably written in a Lisp derived tongue.
Doubtless that's why the E's computers are so slow as to have to say
"Working..."
Lispers are among the best grads of the Sweep-It-Under-Someone-Else's-Carpet
School of Simulated Simplicity.
[Was that sufficiently incendiary? :-)]
Larry Wall
lw...@netlabs.com
Kyle Jones
> Perl has subroutines, and most of the Enterprise code is
> probably written in perl (at least it should be).
ky...@uunet.uu.net (Kyle Jones) writes:
> No way. A computer with smooth and logical interfaces like the
> Enterprise being written in a language that's nothing short of a
> a semantic and syntactic mine field?
lw...@netlabs.com (Larry Wall) writes:
> Oh, gimme a break. Perl semantics are a regularization of
> Unix semantics. Perl was never intended to be an ivory tower
> language. It's more like a tank than a mine field. It may be
> ugly, but it shoots straight and gets you where you're going,
> if you don't mind a few squashed daisies.
Laying our weapons aside momentarily for the sake of the Star
Trek innocents, can you honestly imagine our clean-limbed Next
Generation heroes (thank you Jon Drukman) using a language like
Perl? People who fly around in a ship that looks like a Miata on
the outside and a stretch limo on the inside? People who talk to
their computers and ALWAYS use icons? Doesn't it call forth the
horrible image of an infant tottering toward a porcupine?
> > The E's software was probably written in a Lisp derived tongue.
>
> Doubtless that's why the E's computers are so slow as to have to say
> "Working..."
Yah, that's what I was thinking when I suggested a Lisp
derivative. That and huge amounts of memory. If they can cram
800 quadrillion bits into Data's head, you can imagine how much
memory the whole ship has.
> Lispers are among the best grads of the Sweep-It-Under-Someone-Else's-Carpet
> School of Simulated Simplicity.
>
> [Was that sufficiently incendiary? :-)]
Quite. :-)
I think someone should write a Lisp to Perl translator.
Jeff Sicherman
Or maybe by the Algol method, the name of which escapes me for the moment.
Anyone old enough (and obscure) to remember it ?
--
Jeff Sicherman
up the net without a .sig
Mike Lake
> Or maybe by the Algol method, the name of which escapes me for the moment.
>Anyone old enough (and obscure) to remember it ?
No pun intended, I'm sure.
Algol used call-by-name.
Mike
--
J. Michael Lake Beckman Institute for Advanced Science and Technology
Dept. of Comp. Science jml...@uiuc.edu Urbana, IL 61801
Kyle Jones
derivative seems a more likely choice for a system language.
Roger M. Wilcox
>In <1992Jan10....@uunet.uu.net> ky...@uunet.uu.net (Kyle Jones) writes:
>
>>The E's software was probably written in a Lisp derived tongue.
>
>Way off! I saw a banner screen on an E's screen that had the legend
>"Gnu D+=4 v263.91".
Really? Are there some actual Unix Weenies on the TNG stage-prop crew?
Actually, I'm surprised that 24th century computer programs have to be
WRITTEN at all. We've already got visual programming "languages" that
allow users to construct complete full-powered programs without keying
in a line of source code. (And I'm not just talking about interface
builders here, either.)
But the "subroutine" stuff gave it away.
The Galaxy-class Enterprise computers, ever since season 4, were
upgraded to run the Federation Standard Approved FORTRAN 43487.3 compiler
(ISO FORTRAN standard 6783658647286.2BIS) which supports Blah-De-Blah-
oriented programming extensions.
--
Jeff Boeing / Roger M. Wilcox cbcs...@ma.secs.csun.edu
----------------------------------------------------------------
"Estas malpermesita entrudi sin en la evoluon de pli naivaj
kulturoj." -- La Unua Direktivo, pli aw malpli
Root Boy Jim
>In <1992Jan10....@uunet.uu.net> ky...@uunet.uu.net (Kyle Jones) writes:
>: sta...@skyking.OCE.ORST.EDU (John Stanley) writes:
>: > Perl has subroutines, and most of the Enterprise code is probably
>: > written in perl (at least it should be).
To pick a nit, the very fact that Larry calls them "subroutines"
rather than "functions" speaks volumes.
>: No way. A computer with smooth and logical interfaces like the
>: Enterprise being written in a language that's nothing short of a
>: a semantic and syntactic mine field?
>
>Oh, gimme a break. Perl semantics are a regularization of Unix semantics.
How about half a break? The semantics are not bad, but the syntax is awful.
There is no need for a language to have complicated syntax. What LISP
provides is quite sufficient.
As for the semantics, they're incomplete. Finish the job
and make perl do everything C can do.
>Perl was never intended to be an ivory tower language.
Neither was LISP. However, it does require a bit of thought to approach,
while FORTRASH (and other conventional) languages were easily understood
by scientists and engineers upon first reading. That plus the necessity
for compilation to achieve speed is probably kept LISP in the "ivory
towers" for so long.
> It's more like
>a tank than a mine field. It may be ugly, but it shoots straight and
>gets you where you're going, if you don't mind a few squashed daisies.
Unfortunately, the tank is going in several directions at once.
>: The E's software was probably written in a Lisp derived tongue.
>
>Doubtless that's why the E's computers are so slow as to have to say
>"Working..."
Any language not completely compiled is slow. So what?
The real resource bottleneck is programmer think time.
It is interesting that you therefore chose to make perl an interpreter
rather than a compiler. Another example of "Laziness"?
>Lispers are among the best grads of the Sweep-It-Under-Someone-Else's-Carpet
>School of Simulated Simplicity.
I am unsure of what you mean here. Isn't the whole purpose of programming
to build a system layer upon layer, blissfully unaware of what is above
or below? Isn't programming an excercise in recursive abstraction?
Interestingly enuf, some of perl's best features are present only in LISP.
>[Was that sufficiently incendiary? :-)]
Yes it was. It is sad that someone as smart as you can be so blind.
>Larry Wall
>lw...@netlabs.com
One more point. I write almost everything now in perl. I wouldn't
use anything else unless it had to be really fast, or needed proper
signal handling semantics. I just wish the language was saner.
--
Desolation Row Jimmy <r...@uunet.uu.net>
Drawing Crazy Patterns on Your Screen
benj...@ducvax.auburn.edu
[lot's of computer talk from the Tech Guide deleted]
>
> (This also brings to mind two side questions: 1) Is a "quad" four bytes?
> Four words? What? and 2) Whatever happened to good old powers of two?
I figured a "quad" was short for a quadrillion or 10 to the 15th, but my
question is--is this memory size or clock speed?
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Jeff Lee Free Dan Bredy! Disclaimer: I speak for Shipbrook
> jl...@smylex.uucp uhasun!smylex!jlee Software, all of its employees, and
> jlee%smyle...@uhasun.hartford.edu their families.
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> taH pagh taHbe' -- William Shakespeare
David Benjamin
Auburn University: home of the hidden tape recorder
Rahul Dhesi
>One more point. I write almost everything now in perl. I wouldn't
>use anything else unless it had to be really fast, or needed proper
>signal handling semantics. I just wish the language was saner.
Well, perhaps it is now time for perl+.
perl+ translator
human-readable perl+ source --------------------------> perl code
--
Rahul Dhesi <dh...@cirrus.COM>
UUCP: oliveb!cirrusl!dhesi
"You're even nuttier than we've come to expect of you." -- Doug Gwyn
Pat Berry
> But speaking of the E's computer, I picked up the TNG tech manual this
> weekend, and found a curious inconsistency in the section about the E's
> computer technology.
>
> On page 49, it states that each module of 144 isolinear optical chips has a
> storage capacity of about 630,000 "kiloquads". This divides out to 4375
> "kiloquads" per chip. Yet on page 53, it states that each chip has a total
> memory capacity of 2.15 "kiloquads" per chip. Talk about synergism!
>
> (This also brings to mind two side questions: 1) Is a "quad" four bytes?
> Four words? What? and 2) Whatever happened to good old powers of two?
The Enterprise's computer uses quadritronic logic. A "quad" is to
quadritronic logic what a bit is to binary logic. It's the smallest
unit of information.
Pat Berry p...@berry.Cary.NC.US
D. J. McCarthy ~
>> No way. A computer with smooth and logical interfaces like the
>> Enterprise....
> People who talk to their computers and ALWAYS use icons?
>> Doubtless that's why the E's computers are so slow as to have to say
>> "Working..."
Subroutines; smooth, logical interfaces; lots of icons; slowness.
Sounds like the perfect niche for an infix version of PostScript.
"Computer:"
[bleep]
"Gsave rlineto 210 mark 36 warp 8."
[Working... course plotted.]
"Stroke!"
[Whoosh!]
--
| D. J. McCarthy The moving walkway is now ending.
| dmc...@swtec1.intel.com Please look down.
| ...!intelhf!mipos3!modl01!dmccart
Larry Wall
: In <1992Jan10.2...@netlabs.com> lw...@netlabs.com (Larry Wall) writes:
: >In <1992Jan10....@uunet.uu.net> ky...@uunet.uu.net (Kyle Jones) writes:
: >: sta...@skyking.OCE.ORST.EDU (John Stanley) writes:
: >: > Perl has subroutines, and most of the Enterprise code is probably
: >: > written in perl (at least it should be).
:
: To pick a nit, the very fact that Larry calls them "subroutines"
: rather than "functions" speaks volumes.
Unfortunately, what you're thinking is probably false.
They're called subroutines because that's the more generic term. A subroutine
can be *used* as a function, or it can be *used* for its side effects. I'm
not here to pretend that a procedural language is some kind of math.
: >: No way. A computer with smooth and logical interfaces like the
: >: Enterprise being written in a language that's nothing short of a
: >: a semantic and syntactic mine field?
: >
: >Oh, gimme a break. Perl semantics are a regularization of Unix semantics.
:
: How about half a break? The semantics are not bad, but the syntax is awful.
: There is no need for a language to have complicated syntax. What LISP
: provides is quite sufficient.
Oh, gee, I think I'll stop speaking English and start speaking LISP.
I would urge you to remember that I'm a linguist, not a computer
scientist, and I don't run screaming from redundancy, irregularity, or
other manifestations of the perversity of the human psyche. I say,
"What is it about human languages that makes them useful despite, or
perhaps because of, their syntactic complexity?"
: As for the semantics, they're incomplete. Finish the job
: and make perl do everything C can do.
It already can. Got any Turing machines handy that I can demonstrate on?
Oh, you mean make it do the same things C does with the same ease?
Is there anything that's easy in C? If there is, I can probably add
those into Perl, but only at the risk of making some things that are
currently easy in Perl a lot less easy.
"Beware the Turing Tarpit, where everything is possible, and nothing is easy."
[Who said that? Hoare? Dijkstra? Durn names get all tangled...]
Perl is intended to make certain things easy. It's not intended to make
everything easy, which is a utopian dream.
: >Perl was never intended to be an ivory tower language.
:
: Neither was LISP. However, it does require a bit of thought to approach,
: while FORTRASH (and other conventional) languages were easily understood
: by scientists and engineers upon first reading. That plus the necessity
: for compilation to achieve speed is probably kept LISP in the "ivory
: towers" for so long.
"Takes a bit of thought to approach." I like that. I've done a lot more
programming in LISP than in FORTRAN, and I can identify with this.
: > [Perl]'s more like
: >a tank than a mine field. It may be ugly, but it shoots straight and
: >gets you where you're going, if you don't mind a few squashed daisies.
:
: Unfortunately, the tank is going in several directions at once.
No, it has the possibility of easily going the direction you choose,
for a good many of the directions you often choose. That's why you
use it yourself.
I plan on adding the capability of going several directions at once, but
I've been excruciatingly short of time lately.
: >: The E's software was probably written in a Lisp derived tongue.
: >
: >Doubtless that's why the E's computers are so slow as to have to say
: >"Working..."
:
: Any language not completely compiled is slow. So what?
: The real resource bottleneck is programmer think time.
I don't disagree with you at all, except when I'm waiting for the computer. :-)
Honestly, how can I disagree with you, from a linguistic point of view?
I'm spending a lot more time writing this article than you will
reading it, and you're interpreting it, for goodness' sake!
: It is interesting that you therefore chose to make perl an interpreter
: rather than a compiler. Another example of "Laziness"?
No, mere stupidity. I'm not smart enough to write a compiler.
And apart from that, I've been more concerned with portability than with
performance up till now. An interpreter is (almost) instantly portable
to any machine that can compile the interpreter. A compiler has to have
a new back-end on every architecture you port it to. Sure, we're starting
to see more portability in back-ends, but if, for example, Perl were able
to spit out stuff for a GNU backend, you'd realize very little performance
gain over an interpreter because of the mismatch between abstract machines.
: >Lispers are among the best grads of the Sweep-It-Under-Someone-Else's-Carpet
: >School of Simulated Simplicity.
:
: I am unsure of what you mean here. Isn't the whole purpose of programming
: to build a system layer upon layer, blissfully unaware of what is above
: or below? Isn't programming an excercise in recursive abstraction?
That's merely one way to look at programming. And the problem with it
is that, in fact, you CAN'T be blissfully unaware of what is above or
below. You have to become familiar with a goodly portion of the
environment before you can effectively use that environment. An
effective LISP programmer has to know much more than what (CDR A B C)
means, just as an effective Unix programmer has to know much more than
what `A <foo | B | C` means.
I prefer to view programming as an exercise in effective communication.
Teaching somebody CAR and CDR, or Unix pipelines, and then saying "You
now know LISP, or shell programming", is like handing your sweet
16-year-old the car keys, and telling her "All you need to know is that
the right pedal makes you go, and the left pedal makes you stop." You
haven't told her anything about the driving environment, nor about the
fact that there are *differing* driving environments. Unless she does
a lot more studying, your daughter will turn out to be Not Very Portable.
The fact is, to use LISP, Unix, C, C++, etc., you have to be continually
referring to things outside the language definition proper to get anything
done, and historically speaking, language definitions proper have not been
notably successful in enforcing discipline outside of their domain.
In contrast, natural languages don't require you to say #include <stdio.h>.
If it's standard I/O, everyone worth talking to already knows about it.
If you don't understand something, that's what the dictionaries and the
encyclopedias are for, and I shouldn't have to tell you which volume to
look in. This approach has both advantages and disadvantages, of
course, and the computer scientists will be quick to point out the
disadvantages. Perl is a (partially successful) experiment in exploring
the advantages of building a little more into the language. In some
sense, Perl has failed you the moment you're forced to say "require".
I think the E's computers are programmed primarily in English, or in whatever
language the crew is actually speaking, if the English is dubbed. :-)
: Interestingly enuf, some of perl's best features are present only in LISP.
That's not entirely accidental. :-)
: >[Was that sufficiently incendiary? :-)]
:
: Yes it was. It is sad that someone as smart as you can be so blind.
Yes. Fortunately, those of us who have such handicaps are compensated
by an increased awareness of some of our other senses and sensibilities.
: One more point. I write almost everything now in perl. I wouldn't
: use anything else unless it had to be really fast, or needed proper
: signal handling semantics. I just wish the language was saner.
Me too.
: Desolation Row Jimmy <r...@uunet.uu.net>
: Drawing Crazy Patterns on Your Screen
Thanks, you're a good straight man.
Larry Wall
lw...@netlabs.com
Dave Schaumann
>The Enterprise's computer uses quadritronic logic. A "quad" is to
>quadritronic logic what a bit is to binary logic. It's the smallest
>unit of information.
No kidding?
Too bad they didn't decide on base 3 (ie, ternary). Since it can be
shown that the optimal computer design would use base 3 arithmetic.
Oh, well.
--
_
_ //\miga! | The persons and events in this post are fictitious. Any
\X/~~\ | similarity to actual persons or events is unintentional.
Kyle Jones
> I would urge you to remember that I'm a linguist, not a computer
> scientist, and I don't run screaming from redundancy, irregularity, or
> other manifestations of the perversity of the human psyche. I say,
> "What is it about human languages that makes them useful despite, or
> perhaps because of, their syntactic complexity?"
"SUKATH, HIS EYES UNCOVERED!!!"
Looking at Perl in light of your above comments, I suddenly have
no further questions. I've clearly been trying to comprehend it
using the wrong paradigms. I sure wish someone would have told
me this sooner...
--
"...as long as there is a Legion of super-Heroes, all else can surely
be made right." -- Sensor Girl
Root Boy Jim
>In <1992Jan13....@uunet.uu.net> r...@uunet.uu.net (Root Boy Jim) writes:
>
>They're called subroutines because that's the more generic term. A subroutine
>can be *used* as a function, or it can be *used* for its side effects. I'm
>not here to pretend that a procedural language is some kind of math.
No. Function is the more generic term. Everything returns a value.
Functions may have side effects and the return value may be ignored.
There is no such thing as a subroutine.
Like, I despise the eggheads who advocate totally functional
programming with no side effects. Mostly because I don't
entirely understand it. On the other hand, I am unwilling to
side with the people who deem languages "procedural".
>: How about half a break? The semantics are not bad, but the syntax is awful.
>: There is no need for a language to have complicated syntax. What LISP
>: provides is quite sufficient.
>
>Oh, gee, I think I'll stop speaking English and start speaking LISP.
>
>I would urge you to remember that I'm a linguist, not a computer scientist,
Don't confuse human and machine languages. English syntax is
closer to LISP than anything else. There isn't much to either.
And there shouldn't be.
>and I don't run screaming from redundancy, irregularity, or
>other manifestations of the perversity of the human psyche. I say,
>"What is it about human languages that makes them useful despite, or
>perhaps because of, their syntactic complexity?"
The human brain is a billion times faster and stores a billion times
as much information as any computer. Don't make the machine work so hard.
And don't make me think so hard either. At least not when I program.
I want to think about my problem, not the language I'm writing in.
I don't care about the squashed daisies; I just don't want the
tank running over my toes.
You have a good set of functions and operators. However, it's
those special cases I object to (even tho I use them sometimes).
>: As for the semantics, they're incomplete. Finish the job
>: and make perl do everything C can do.
>
>It already can. Got any Turing machines handy that I can demonstrate on?
I suppose I am talking about the OS interface then.
Finish the signal interface. Make waitpid work if wait3 exists.
Fix the shared memory stuff (attach/detach on every read/write
is really stupid). Take a third argument to open (O_xxx bits).
>"Beware the Turing Tarpit, where everything is possible, and nothing is easy."
>[Who said that? Hoare? Dijkstra? Durn names get all tangled...]
>
>Perl is intended to make certain things easy. It's not intended to make
>everything easy, which is a utopian dream.
This sounds like the "toy language" argument.
Perl is no longer a toy.
>[LISP] "Takes a bit of thought to approach." I like that. I've done a lot more
>programming in LISP than in FORTRAN, and I can identify with this.
The way I describe it is "slippery". It takes a bit of time to know
when you've got a "thing" or a pointer to it, and when things get
evaluated.
>Honestly, how can I disagree with you, from a linguistic point of view?
>I'm spending a lot more time writing this article than you will
>reading it, and you're interpreting it, for goodness' sake!
Ditto.
>: It is interesting that you therefore chose to make perl an interpreter
>: rather than a compiler. Another example of "Laziness"?
>
>No, mere stupidity. I'm not smart enough to write a compiler.
You may have stumbled on the right thing for the wrong reason.
Interpreters are a superior environment to work in.
Compiled code's only advantage is speed, and perhaps size.
>: >Lispers are among the best grads of the Sweep-It-Under-Someone-Else's-Carpet
>: >School of Simulated Simplicity.
>
>I prefer to view programming as an exercise in effective communication.
>
>In contrast, natural languages don't require you to say #include <stdio.h>.
>If it's standard I/O, everyone worth talking to already knows about it.
Now we're back to sweeping things under the rug, aren't we?
Besides, effective communication is difficult in perl. Mostly
because of those special cases, and a few bad choices made
early on in perl's lifetime.
Prefixing variables with [$%@&] to indicate their "type" is bad.
Variables merely contain pointers to objects, which is where the
types should be stored. Besides, in the case of file handles,
labels, and possibly builtins, there is no prefix character.
Also, poor choices were made for some of the prefix chars.
The `&' is better suited to the function `*' serves. File
Handles are too fragile to stand without a prefix, and function
calls don't really need one if parentheses are required.
I see no reason to distinguish between builtin functions and user ones.
And why is it that some builtins need parens and some don't?
I suppose this is all rather historical.
>If you don't understand something, that's what the dictionaries ...
Oh and BTW, the Perl Book is hard to find things in.
But that's another discussion.
>I think the E's computers are programmed primarily in English, or in whatever
>language the crew is actually speaking, if the English is dubbed. :-)
>
>: Interestingly enuf, some of perl's best features are present only in LISP.
>
>That's not entirely accidental. :-)
I'll take that as a partial concession. I find it truly amazing
that a language designed so long ago has such totally modern
features. Almost everything you need is there, in simple form.
>: >[Was that sufficiently incendiary? :-)]
>:
>: Yes it was. It is sad that someone as smart as you can be so blind.
>
>Yes. Fortunately, those of us who have such handicaps are compensated
>by an increased awareness of some of our other senses and sensibilities.
Such as?
>I just wish the language was saner.
>
>Me too.
Perhaps it is time to start designing its successor.
But please ask for help when you do.
>: Desolation Row Jimmy <r...@uunet.uu.net>
>: Drawing Crazy Patterns on Your Screen
>
>Thanks, you're a good straight man.
I suppose one of those sensibilities you mention is a good sense of humor.
>Larry Wall
>lw...@netlabs.com
--
Takashi Toyooka
(Pat Berry) writes:
>jl...@smylex.UUCP (Jeff Lee) writes:
>>
>> . . .
>> (This also brings to mind two side questions: 1) Is a "quad" four bytes?
>> Four words? What? and 2) Whatever happened to good old powers of two?
>
>The Enterprise's computer uses quadritronic logic. A "quad" is to
>quadritronic logic what a bit is to binary logic. It's the smallest
>unit of information.
I believe that the "quad" is a unit of memory which is in use today (that
is, it's not specific to the Star Trek universe). I recall Data once
stating his memory capacity in terms of "quadrillion bits", and I suspect
that that is the definition of a quad.
Mail me and scream if I'm wrong; I'll post the correct definition.
...Takashi
Gerald (Jerry) KUCH
>In <1992Jan14.1...@netlabs.com> lw...@netlabs.com (Larry Wall) writes:
>>In <1992Jan13....@uunet.uu.net> r...@uunet.uu.net (Root Boy Jim) writes:
>>
>
>Don't confuse human and machine languages. English syntax is
>closer to LISP than anything else. There isn't much to either.
>And there shouldn't be.
>
((> (equal? (English-syntax LISP)) (anything-else)
(what? (talk-about you here))))
What are you talking about? How many people walk around forming all of the
logical relations in their sentences in prefix form? The minimal nature of
Lisp's syntax essentially removes the need for any sophisticated parsing.
"No parsing at all" is a long way from natural language parsing.
>
>The human brain is a billion times faster and stores a billion times
>as much information as any computer. Don't make the machine work so hard.
>
d'Oh! Where are these numbers coming from? Faster at what? Let's see how
quickly you can factor a nine hundred digit prime number? Probably somewhat
slower than a computer could generate fairly acceptable (if not "understood"
but that's a whole other philosophical snakepit) English sentences.
The brain does some things very well. Some things better than any current
machine. This is true. But please spare us these stupid blanket statements
like "the brain is [some big number] times faster than any computer".
>I'll take that as a partial concession. I find it truly amazing
>that a language designed so long ago has such totally modern
>features. Almost everything you need is there, in simple form.
>
--
Jerry Kuch (je...@cs.mcgill.ca) "Make the ganglia twitch!" -- B.B.
"I was wrong to play God. Life is precious, not a thing to be toyed with.
Now take out that brain and flush it down the toilet."
--- M. Burns "Treehouse of Horror II"
Root Boy Jim
?In<1992Jan15.0...@uunet.uu.net> r...@uunet.uu.net (Root Boy Jim) writes:
?>
?>Don't confuse human and machine languages. English syntax is
?>closer to LISP than anything else. There isn't much to either.
?>And there shouldn't be.
?>
?
?((> (equal? (English-syntax LISP)) (anything-else)
? (what? (talk-about you here))))
?
?What are you talking about? How many people walk around forming all of the
?logical relations in their sentences in prefix form? The minimal nature of
?Lisp's syntax essentially removes the need for any sophisticated parsing.
?"No parsing at all" is a long way from natural language parsing.
You seem to be stuck on infix vs prefix notation. I could
write "a = b + c" as "set(&a,plus(b,c));" in C given suitable
trivial functions. Not far away from (set 'a (plus b c)).
Easier to read than Forth or Postscript.
I'll give up the English analogy if everyone else will.
?>The human brain is a billion times faster and stores a billion times
?>as much information as any computer. Don't make the machine work so hard.
?
?d'Oh! Where are these numbers coming from?
My source for these numbers is probably some NOVA show, and I will
grant that the numbers are somewhat hokey. Until we figure out how
the brain works, we can only speculate on the factors.
?Faster at what? Let's see how
?quickly you can factor a nine hundred digit prime number? Probably somewhat
?slower than a computer could generate fairly acceptable (if not "understood"
?but that's a whole other philosophical snakepit) English sentences.
I can factor a prime number instantly! But seriously, at things that
require intelligence, or at least the appearance of it.
?The brain does some things very well. Some things better than any current
?machine. This is true.
I will turn your statement around and say rather that "computers do some
things very well". Mostly rather trivial things.
?But please spare us these stupid blanket statements
?like "the brain is [some big number] times faster than any computer".
Here's another one: I've heard it said that current computers
are about "as smart as a snail". Yeah, hokey.
?>I'll take that as a partial concession. I find it truly amazing
?>that a language designed so long ago has such totally modern
?>features. Almost everything you need is there, in simple form.
So how come you didn't respond to the most substantial thing I had to say?
?--
? Jerry Kuch (je...@cs.mcgill.ca) "Make the ganglia twitch!" -- B.B.
? "I was wrong to play God. Life is precious, not a thing to be toyed with.
? Now take out that brain and flush it down the toilet."
? --- M. Burns "Treehouse of Horror II"
Root Boy Jim
LARRY>>Me too.
RBJ>Perhaps it is time to start designing its successor.
RBJ>But please ask for help when you do.
I received a piece of mail from Tom Christiansen calling me rude.
First, let me issue a blanket apology for any sensibilitys I may
have offended. In this discussion I feel constantly in danger of
straying across the line where I become insulting or tiring.
Second, let me reiterate my statement that I would think long
and hard about using anything else other than perl for almost
everything I write.
Third, let me add that I think Larry has written some of the most
useful and indispensible programs around. Perl has done quite a job at
uniting C, awk, sed, and sh features. And his version of regular
expressions deserves more consideration than it will get by the
standards makers.
I therefore wish to expound on what I meant when I said "ask for help."
What I had in mind was sort of like the acknowledgement section of the
Common LISP book by Steele. On that page were listed the people who
contributed ideas. It contained everyone from McCarthy to Stallman.
Now I have my reservations about Common LISP, and I certainly don't
want ANSI, IEEE, ISO, CCITT, or X/OPEN to get their hands on perl.
But I do think that Larry should get together with some of the best
people, figure out what's wrong with Perl I, what's right with it, and
design Perl II. My list would include Stallman, Flee, Henry Spencer (a
hostile witness; the point is: why? perhaps when talking to him, the
discussion could be about AWK II), someone at Bell Labs (the AWK people
come to mind, as do the shell people, Tom Duff, Bourne and Korn, maybe
even Bjarne), Arnold Robbins (gawk and ash), Paul Falstad (zsh),
perhaps the Berkeley people. Chris Torek, Doug Gwyn, and Guy Harris are
always good for an insight or two, altho I don't know how they feel
about perl.
Perhaps he has done some of this already. Keep it up.
Randal L. Schwartz
| But I do think that Larry should get together with some of the best
| people, figure out what's wrong with Perl I, what's right with it, and
| design Perl II. My list would include Stallman, Flee, Henry Spencer (a
| hostile witness; the point is: why? perhaps when talking to him, the
| discussion could be about AWK II), someone at Bell Labs (the AWK people
| come to mind, as do the shell people, Tom Duff, Bourne and Korn, maybe
| even Bjarne), Arnold Robbins (gawk and ash), Paul Falstad (zsh),
| perhaps the Berkeley people. Chris Torek, Doug Gwyn, and Guy Harris are
| always good for an insight or two, altho I don't know how they feel
| about perl.
Aurgh! Another PL/1 or Ada (the PL/1 of the 80's) would result!
Hey, Perl Version 1 was small and clean, and then some of us came
along and said "Larry, it doesn't do mkdir() as a primitive! Why
not?". So Larry, being the good sport that he is, put it in. Perl
Version 4.19 *is* the result of Larry's aribitration among a design
committee of 45,000 usenet readers.
Perl, like GNU Emacs and X11, is an amalgamation of the requests and
contributions of thousands of people. As a result, it won't satisfy
everyone in its cleanliness, but it *will* mostly satisfy *nearly*
everyone in its versatility.
Perl, the Swiss Army Chain Saw.
$_ = join('','a'..'y'); tr/a-y/Just another Perl hacker,/; print
--
/=Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 ==========\
| on contract to Intel's iWarp project, Beaverton, Oregon, USA, Sol III |
| mer...@iwarp.intel.com ...!any-MX-mailer-like-uunet!iwarp.intel.com!merlyn |
\=Cute Quote: "Intel: putting the 'backward' in 'backward compatible'..."====/
Gordon Edwards
|> have to give the computer the design specs of each program, and the
|> computer will write them all in fully-optimized MACHINE language.
|>
After a spending a substantial portion of my graduate career in AI, I would
like to address this question.
1) Perl, no way. I wouldn't do it in perl today!
2) LISP. Not likely.
3) Give it specs and let it do the work. I agree this is likely, but this
is more human interface than what is going on underneath.
So to repeat the question, "What is the language of the future E?" To answer
this, lets characterize the E's computer system. ADAPTABLE. Are today's
languages adaptable? NO! There are programming paradigms that are, to
differing degrees, adaptable. Two come to mind.
1) Non-monotomic reasoning. Adaptive? Somewhat. This is where you make
general assumptions about something, but can override that information
with new facts as appropriate. There are a number of higher-order logics that
allow this behavior. (First-order logic, that is, predicate calculus, is not
one of them.)
2) Neural programming. Adaptive? Yes, and getting better. If I had
to bet on what the E was using and it had to be a derivative of current
technology, this would be the winner. Main limitation is today's hardware.
Neural programming coupled with adaptable neural computers, would give the
appearance of learning. When I say adaptable neural computers, I mean systems
where the neuron is the fundamental processing unit and arbitrary compositions
of these neurons may be formed to solve particular problems. Why neural nets?
They give relative answers as opposed to binary reponses, they can be taught
(indeed, this is how one programs the network), and they can tell when their
not doing so well (so you can teach them some more).
Some NLP, higher-order logic, distributed database subsystem might/would be
useful for basic storage and retrieval of information. The nueral networks
would act as problem solvers, utilizing the stored information, sensor input,
etc.
Let me know what you think.
Gordon Edwards
Mead Data Central