Source of Guy Steele quote
w_a_x_man
[customized edition] (by Springer and Friedman).
Guy L. Steele, Jr., July 1989:
I think we may usefully compare the approximate number of pages
in the defining standard or draft standard for several
programming languages:
Common Lisp 1000 or more
COBOL 810
ATLAS 790
Fortran 77 430
PL/I 420
BASIC 360
ADA 340
Fortran 8x 300
C 220
Pascal 120
DIBOL 90
Scheme 50
Kenneth Tilton
> This is from Steele's foreward...
Steele? The guy who started at CL and ended up at Java (well, and now
Fortran) after creating Scheme so all the big implementors had to add
back in all the things Steele took out to get the small spec? That guy?
The guy who took a good idea like dataflow and came up with constraints
a fundamentally dead research program while it is hard to find a serious
new software package that does not in some form support dataflow? That guy?
Oh, yeah, let's see what he has to say.
Not.
kenny
Pillsy
> This is from Steele's foreward to _Scheme and the Art of Programming_
> [customized edition] (by Springer and Friedman).
> Guy L. Steele, Jr., July 1989:
> I think we may usefully compare the approximate number of pages
> in the defining standard or draft standard for several
> programming languages:
> Common Lisp 1000 or more
[...]
> Scheme 50
I don't know if this is quite fair. I mean, yeah, Common Lisp provides
a lot more useful stuff than Scheme did back then, but 20 times as
much?
Cheers,
Pillsy
Pascal Costanza
This quote is probably taken out of context, and thus not very useful as is.
Scheme is an excellent language when it comes to distilling the
essential fundamental concepts of programming. From that angle, it is
quite impressive how much you can do with how little.
But nowadays, the criticism is rather that Common Lisp is too small, not
too big. (In the sense of, it doesn't come with batteries included.)
Real-world Scheme implementations are typically also a lot larger - see
PLT Scheme as an extreme example.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza
If only you knew...
> Oh, yeah, let's see what he has to say.
I find it extremely interesting what he has to say: http://vimeo.com/6624203
At least he doesn't just reinvent wheels.
Pillsy
> Pillsy wrote:
> > On Nov 12, 7:21 am, w_a_x_man <w_a_x_...@yahoo.com> wrote:
> >> This is from Steele's foreward to _Scheme and the Art of Programming_
> >> [customized edition] (by Springer and Friedman).
> >> Guy L. Steele, Jr., July 1989:
> >> I think we may usefully compare the approximate number of pages
> >> in the defining standard or draft standard for several
> >> programming languages:
> >> Common Lisp 1000 or more
> > [...]
> >> Scheme 50
> > I don't know if this is quite fair. I mean, yeah, Common Lisp provides
> > a lot more useful stuff than Scheme did back then, but 20 times as
> > much?
> This quote is probably taken out of context, and thus not very useful as is.
Yes. I was trying (and clearly failing) to be subtly sarcastic.
(Seriously, I agree with everything you wrote.)
Cheers,
Pillsy
[...]
Kenneth Tilton
> Kenneth Tilton wrote:
>> w_a_x_man wrote:
>>> This is from Steele's foreward...
>>
>> Steele? The guy who started at CL and ended up at Java (well, and now
>> Fortran) after creating Scheme so all the big implementors had to add
>> back in all the things Steele took out to get the small spec? That
>> guy? The guy who took a good idea like dataflow and came up with
>> constraints a fundamentally dead research program while it is hard to
>> find a serious new software package that does not in some form support
>> dataflow? That guy?
>
> If only you knew...
>
>> Oh, yeah, let's see what he has to say.
>
> I find it extremely interesting what he has to say:
> http://vimeo.com/6624203
(a) he needs to lose weight;
(b) you missed the point: given his record to date... well, lessee:
"all sequential languages encourage bugs of forgetting to initialize an
accumulator to zero."
c++ does not allow unitialized variables. And lisp has (for his example):
(loop for i from 1 to 1000000 summing i)
He's right. No initialization. <sigh>
If we do not cheat:
(loop for i from 1 to 1000000
do (incf sum i))
...the compiler will warn sum is special. Hmmm.
I'm three minutes in... do I have to keep on listening?
--
http://thelaughingstockatpngs.com/
http://www.facebook.com/pages/The-Laughingstock/115923141782?ref=nf
Kaz Kylheku
> c++ does not allow unitialized variables.
In your dreams! C++ allows uninitialized local variables, uninitialized class
members, uninitialized memory from operator new, etc.
To parody Stroustrup's FAQ answer ``Is C a subset of C++?'': every C program
with uninitialized storage bugs can be written in essentially the same way in
C++ with the same run-time and space efficiency, and the same uninitialized
storage bugs.
Raffael Cavallaro
> I'm three minutes in... do I have to keep on listening?
Only if you want to learn an interesting programming paradigm
(functional-parallel) which may well be to the 21st c what
imperative-sequential programming was to the 20th.
--
Raffael Cavallaro
Kenneth Tilton
Really? That was one of the things I (thought I) liked as I started
reading the C++ book. I lost it tho when I got to the way one declared
pure abstract virtual something or others:
<identifier> = 0;
I mean, I can visualize the machine language behind it, I guess I just
was ready for something less abstruse.
kt
Kenneth Tilton
You and the bozo who has me killfiled so he won't see this are missing
the point: Steele utterly cocked up a paradigm (by pushing it two
bridges too far (multi-way and partial constraints) that is slowly
devouring all of programming (resistance is futile) and single-handedly
created a Dataflow Winter that lasted until I (and dozens of others, but
let's talk about me) came along.
I'll wait till a Real Lisper tackles the subject.
kenxo
Lars Rune Nøstdal
Raffael Cavallaro
> You and the bozo who has me killfiled so he won't see this are missing
> the point: Steele utterly cocked up a paradigm (by pushing it two
> bridges too far (multi-way and partial constraints) that is slowly
> devouring all of programming (resistance is futile) and single-handedly
> created a Dataflow Winter that lasted until I (and dozens of others,
> but let's talk about me) came along.
This is, of course, the classic ad hominem argument. Because you
disagree with something he previously did, what he's now saying must be
invalid? Really?
In all seriousness, you should not let your antipathy toward either
Pascal or Steele deter you - watch the talk, it's an eye opener. BTW,
thanks for the pointer Pascal.
>
> I'll wait till a Real Lisper tackles the subject.
If Guy Steele doesn't qualify as a real lisper then there's no hope for
the rest of us, you and me and Pascal included.
--
Raffael Cavallaro
Kenneth Tilton
> On 2009-11-12 20:49:19 -0500, Kenneth Tilton <kent...@gmail.com> said:
>
>> You and the bozo who has me killfiled so he won't see this are missing
>> the point: Steele utterly cocked up a paradigm (by pushing it two
>> bridges too far (multi-way and partial constraints) that is slowly
>> devouring all of programming (resistance is futile) and
>> single-handedly created a Dataflow Winter that lasted until I (and
>> dozens of others, but let's talk about me) came along.
>
> This is, of course, the classic ad hominem argument. Because you
> disagree with something he previously did, what he's now saying must be
> invalid? Really?
The mind reels...
Congrats, btw, on your contribution to making "Really?" the neologism
fastest to reach irritatingness thru massive overuse.
>
> In all seriousness,...
Oh, thank G*d, you were kidding...
>.. you should not let your antipathy toward either
> Pascal or Steele deter you - watch the talk, it's an eye opener.
You misunderestimate me. Cells is made for parallelism, just with bigger
chunks than Steele is worrying about. But I was interested until I
realized he was making substantive assertions and I got all ad homineum
-- the boy who cried wolf wasn't much listened to after a while, no
matter how fascinating the wolf story.
But he has an intimidating, stern style and looks like a sizable fellow.
Funny to think he /bullied/ the world into Constraints, Scheme, and Java.
kt
Pascal Costanza
Of course not. You will figure it out yourself in 20 years.
Nick Keighley
> >> c++ does not allow unitialized variables.
>
> > In your dreams! C++ allows uninitialized local variables, uninitialized class
> > members, uninitialized memory from operator new, etc.
>
> > To parody Stroustrup's FAQ answer ``Is C a subset of C++?'': every C program
> > with uninitialized storage bugs can be written in essentially the same way in
> > C++ with the same run-time and space efficiency, and the same uninitialized
> > storage bugs.
>
> Really? That was one of the things I (thought I) liked as I started
> reading the C++ book. I lost it tho when I got to the way one declared
> pure abstract virtual something or others:
>
> <identifier> = 0;
>
> I mean, I can visualize the machine language behind it, I guess I just
> was ready for something less abstruse.
struck me there should have been a language word. Could they have used
"static" again?
--
Nick Keighley
Rui Maciel
> Nice. CL has a useful language standard -- that's cool.
How do you arrive at that conclusion?
Rui Maciel
Captain Obvious
NK> "static" again?
#define PURE =0
voi foo() PURE;
Nicolas Neuss
Hi, Kenny,
although I'm rather sure that you write this tongue-in-cheek,
the saying is "standing on the shoulders of Giants" not
"pissing on their legs" :-)
Nicolas
Kenneth Tilton
I was only ten behind on fixing his dataflow cock-up. It would have been
twenty if I had been aware of his work. If he wants my help any sooner
he should ask for it.
I was really happy in your killfile. What does it take to get back in?
kt
Raffael Cavallaro
> Cells is made for parallelism, just with bigger chunks than Steele is
> worrying about.
Steel is also interested in balancing the amount of time spent on those
chunks automatically by treating all data as a tree and rebalancing the
tree in different ways at runtime depending on what sort of computation
needs to be done on it. This is something cells doesn't do, so the talk
would still be enlightening.
But don't let me twist your arm - you may very well want to prioritize
usenet barbs over new programming insights, your call...
...sorry, have I contributed to "your call" becoming irritating, my bad...
...oops!, have I contributed to "my bad" becoming irritating...
;)
--
Raffael Cavallaro
Raffael Cavallaro
> How do you arrive at that conclusion?
By means of actually programming in the language?
--
Raffael Cavallaro
Kenneth Tilton
> Kenneth Tilton <kent...@gmail.com> writes:
>
>> w_a_x_man wrote:
>>> This is from Steele's foreward...
>> Steele? The guy who started at CL and ended up at Java (well, and now
>> Fortran) after creating Scheme so all the big implementors had to add
>> back in all the things Steele took out to get the small spec? That
>> guy? The guy who took a good idea like dataflow and came up with
>> constraints a fundamentally dead research program while it is hard to
>> find a serious new software package that does not in some form support
>> dataflow? That guy?
>>
>> Oh, yeah, let's see what he has to say.
>>
>> Not.
>
> Hi, Kenny,
>
> although I'm rather sure that you write this tongue-in-cheek,
Me? Be silly on Usenet? When have I ever?!
> the saying is "standing on the shoulders of Giants" not
> "pissing on their legs" :-)
Giants? I see you know nothing about the constraints research program
and apparently are unaware of Java. Lucky you!
Meanwhile, back OT, let's hear one objection to the fundamental design
principle of Scheme (making a spec shorter than the CL index):
"Should a programming language be small or large? A small programming
language might take but a short time to learn. A large programming
language may take a long, long time to learn, but then it is less hard
to use, for we then have a lot of words at hand � or, I should say, at
the tips of our tongues � to use at the drop of a hat. If we start with
a small language, then in most cases we can not say much at the start.
We must first define more words; then we can speak of the main thing
that is on our mind. [�] If you want to get far at all with a small
language, you must first add to the small language to make a language
that is more large." -- Guy Steele, 1998
Think I'm kidding? From the same talk/paper:
"But users will not now with glad cries glom on to a language that gives
them no more than what Scheme or Pascal gave them. They need to paint
bits, lines, and boxes on the screen in hues bright and wild; they need
to talk to printers and servers through the net; they need to load code
on the fly; they need their programs to work with other code they don�t
trust; they need to run code in many threads and on many machines; they
need to deal with text and sayings in all the world�s languages. A small
programming language just won�t cut it."
What is his excuse for having done Scheme?:
"Five and twenty years ago, when users did not want that much from a
programming language, one could try. Scheme was my best shot at it."
Hunh? No one wanted much from programming languages in 1984? Oh, my.
Well, he had to make up something. Kinda like Java being half way to Lisp.
Where do you see a giant? Really. Where? The technical writing?
Tamas K Papp
> Hunh? No one wanted much from programming languages in 1984? Oh, my.
> Well, he had to make up something. Kinda like Java being half way to
> Lisp.
>
> Where do you see a giant? Really. Where? The technical writing?
Why do you assume that being a giant has to be something positive?
Cf. Jack and the Beanstalk, Polyphemus in the Odyssey, etc. So you could
still call Steele a giant without changing your opinion about him :-)
Tamas
Rainer Joswig
<7c400e44-ad48-4566...@h34g2000yqm.googlegroups.com>,
Lars Rune N�stdal <larsn...@gmail.com> wrote:
> Nice. CL has a useful language standard -- that's cool.
That's correct.
Let's update some numbers:
Common Lisp - the same
C++ 1281
Ada 765
Fortran 605
C 538
Haskell 98 256
ECMAScript/Javascript 241
Scheme 187
Eiffel 174
The Common Lisp standard is also much less space saving.
READ-LINE for example is presented on 1.3 pages. The Scheme standard
has two columns per page and sometimes lists the function purpose in a
short sentence, if at all: The Scheme standard does not even describe
a function to read a line! There is no READ-LINE in the Scheme standard.
Let's look at a function that both languages have: READ-CHAR
Scheme R6RS on READ-CHAR:
------------------------
(read-char) procedure
(read-char textual-input-port) procedure
Reads from textual-input-port, blocking as necessary un-
til a character is available from textual-input-port, or the
data that are available cannot be the prefix of any valid
encoding, or an end of file is reached.
If a complete character is available before the next end of
file, read-char returns that character, and updates the
input port to point past that character. If an end of file is
reached before any data are read, read-char returns the
end-of-file object.
If textual-input-port is omitted, it defaults to the value re-
turned by current-input-port.
------------------------
Common Lisp Hyper Spec on READ-CHAR
------------------------
Function READ-CHAR
Syntax:
read-char &optional input-stream eof-error-p eof-value recursive-p => char
Arguments and Values:
input-stream---an input stream designator. The default is standard input.
eof-error-p---a generalized boolean. The default is true.
eof-value---an object. The default is nil.
recursive-p---a generalized boolean. The default is false.
char---a character or the eof-value.
Description:
read-char returns the next character from input-stream.
When input-stream is an echo stream, the character is echoed on input-stream the
first time the character is seen. Characters that are not echoed by read-char are
those that were put there by unread-char and hence are assumed to have been
echoed already by a previous call to read-char.
If recursive-p is true, this call is expected to be embedded in a higher-level
call to read or a similar function used by the Lisp reader.
If an end of file[2] occurs and eof-error-p is false, eof-value is returned.
Examples:
(with-input-from-string (is "0123")
(do ((c (read-char is) (read-char is nil 'the-end)))
((not (characterp c)))
(format t "~S " c)))
>> #\0 #\1 #\2 #\3
=> NIL
Affected By:
*standard-input*, *terminal-io*.
Exceptional Situations:
If an end of file[2] occurs before a character can be read, and eof-error-p is
true, an error of type end-of-file is signaled.
See Also:
read-byte, read-sequence, write-char, read
Notes:
The corresponding output function is write-char.
The following X3J13 cleanup issues, not part of the specification, apply to
this section:
READ-AND-WRITE-BYTES:NEW-FUNCTIONS
PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR
ARGUMENTS-UNDERSPECIFIED:SPECIFY
------------------------
The Common Lisp description is five times longer. If you remove the useful information to what
the Scheme standard contains it looks like this:
----
(read-char &optional input-stream eof-error-p eof-value recursive-p) Function
read-char returns the next character from input-stream.
When input-stream is an echo stream, the character is echoed on input-stream the
first time the character is seen. Characters that are not echoed by read-char are
those that were put there by unread-char and hence are assumed to have been
echoed already by a previous call to read-char.
If recursive-p is true, this call is expected to be embedded in a higher-level
call to read or a similar function used by the Lisp reader.
If an end of file[2] occurs and eof-error-p is false, eof-value is returned.
----
Which looks about the same.
Now add to that that Common Lisp defines more functions - like READ-LINE, which Scheme does
not define - then you get the idea why the Common Lisp standard is larger: it has more functionality
- some of that is basic stuff that Scheme still lacks in R6RS, it has more information
about the functionality and it is formatted less dense.
Rui Maciel
> Steele? The guy who started at CL and ended up at Java (well, and now
> Fortran) after creating Scheme so all the big implementors had to add
> back in all the things Steele took out to get the small spec? That guy?
> The guy who took a good idea like dataflow and came up with constraints
> a fundamentally dead research program while it is hard to find a serious
> new software package that does not in some form support dataflow? That
> guy?
>
> Oh, yeah, let's see what he has to say.
>
> Not.
Boy, aren't we arrogant.
Rui Maciel
Giovanni Gigante
> They need to paint
> bits, lines, and boxes on the screen in hues bright and wild; they need
> to talk to printers and servers through the net
Shoud a facility for "painting a box on the screen" be counted in the
size of a language? It depends if you consider that it is essential to
the concept of that language. So, maybe yes in AutoLisp, since its whole
point is painting boxes on screen; not sure for a more "generic"
language such as Scheme or CL. And we are back to the issue of "core vs
libraries". Is a standard java library part (in the numeric sense) of
java? Probably yes. What about one of those "non standard" CL libraries
that make a certain kind of people cry "common lisp has no networking!"?
Maybe not, but it would be if there was some sort of standard agreement
about it. So in the end a language is as big as their designers claim it
to be. Wasn't the very *purpose* of scheme to be somehow "essential"?
Nicolas Neuss
Yep. I think his impact was easily large enogugh to call him a giant.
But indeed, I see the net effect of his work as quite positive (which is
difficult enough to achieve, especially if you look at other giants like
Bill Gates where I see the negative effects on software culture
dominating by far).
Nicolas
Kaz Kylheku
> Kenneth Tilton wrote:
>> They need to paint
>> bits, lines, and boxes on the screen in hues bright and wild; they need
>> to talk to printers and servers through the net
>
>
> Shoud a facility for "painting a box on the screen" be counted in the
> size of a language?
That's like asking, should a facility for manipulating strings or doing
stream I/O be counted?
Of course.
If you have a standard way in the language for painting a box on the
screen, it makes the language larger.
All conforming, complete implementations have to have that.
> It depends if you consider that it is essential to
> the concept of that language. So, maybe yes in AutoLisp, since its whole
> point is painting boxes on screen; not sure for a more "generic"
> language such as Scheme or CL. And we are back to the issue of "core vs
> libraries".
In this newsgroup, we are past the "core versus libraries".
The distinction between language and library is a poorly defined,
misleading concept.
Much of Common Lisp is library material. What are (cons x y),
and (+ 2 2), language or library?
Even read syntax is library material. Load the functions, stick them in the
read table.
Only special forms are not library material, and since libraris can define
macros, you don't necessarily know what those are.
> Is a standard java library part (in the numeric sense) of
> java? Probably yes.
Probably? How probably? P = 0.98?
Kenneth Tilton
> On 2009-11-13 00:44:49 -0500, Kenneth Tilton <kent...@gmail.com> said:
>
>> Cells is made for parallelism, just with bigger chunks than Steele is
>> worrying about.
>
> Steel is also interested in balancing the amount of time spent on those
> chunks automatically by treating all data as a tree and rebalancing the
> tree in different ways at runtime depending on what sort of computation
> needs to be done on it.
Yeah, I got that far.
> This is something cells doesn't do, so the talk
> would still be enlightening.
<sigh> Are you people listening? The problem is: consider the source.
How can it be enlightening to listen to the boy who cried technology!?
Here is someone who created an entire language because he says languages
should be small who says fifteen years later, well, they should have
been small then but not now.
>
> But don't let me twist your arm - you may very well want to prioritize
> usenet barbs over new programming insights, your call...
>
> ...sorry, have I contributed to "your call" becoming irritating, my bad...
>
> ...oops!, have I contributed to "my bad" becoming irritating...
>
> ;)
>
:)
Kenneth Tilton
> On Fri, 13 Nov 2009 10:04:26 -0500, Kenneth Tilton wrote:
>
>> Hunh? No one wanted much from programming languages in 1984? Oh, my.
>> Well, he had to make up something. Kinda like Java being half way to
>> Lisp.
>>
>> Where do you see a giant? Really. Where? The technical writing?
>
> Why do you assume that being a giant has to be something positive?
The context was standing on the shoulders.
> Cf. Jack and the Beanstalk, Polyphemus in the Odyssey, etc. So you could
> still call Steele a giant without changing your opinion about him :-)
So I am standing on his shoulders so I can slash his carotid with by
sword? Keep pluggin, Tamas!
Kenneth Tilton
Rui Maciel
>> How do you arrive at that conclusion?
>
> By means of actually programming in the language?
So your comment had nothing to do with the OP's post?
Rui Maciel
Pillsy
> The problem is: consider the source. How can it be enlightening to
> listen to the boy who cried technology!?
If getting predictions about computer technology wrong means that you
have nothing enlightening to say, I'm gonna guess that nobody who ever
makes *any* prediction about computer technology has anything
enlightening to say.
People screw things up.
> Here is someone who created an entire language because he says languages
> should be small who says fifteen years later, well, they should have
> been small then but not now.
Seems pretty reasonable seeing how memory and speed increased by 3
orders of magnitude in the intervening years, and based on the
languages people were using back in 1984[1], it just seems more
realistic. C and Fortran 77 aren't languages that exactly stagger
under the weight of their included batteries.
Cheers,
Pillsy
[1] Or so I've heard. At that point, the only language I'd used was
Logo on the Apple II. The omission of turtle graphics from Scheme is
unforgiveable, though[2].
[2] I don't even know if I'm joking.
Kenneth Tilton
> Tamas K Papp <tkp...@gmail.com> writes:
>
>> On Fri, 13 Nov 2009 10:04:26 -0500, Kenneth Tilton wrote:
>>
>>> Hunh? No one wanted much from programming languages in 1984? Oh, my.
>>> Well, he had to make up something. Kinda like Java being half way to
>>> Lisp.
>>>
>>> Where do you see a giant? Really. Where? The technical writing?
>> Why do you assume that being a giant has to be something positive?
>> Cf. Jack and the Beanstalk, Polyphemus in the Odyssey, etc. So you could
>> still call Steele a giant without changing your opinion about him :-)
>
> Yep. I think his impact was easily large enogugh to call him a giant.
I can understand why you left it unspecified.
The fact is they took a good idea like automatic change handling and
looked down their noses at simple linear dataflow so they could do the
big boy stuff, multi-way and partial constraints never noticing they had
created something simply too damn hard to program with prolly cause like
most academics he never wrote any application code, he just worked on
languages.
Scheme was nothing but a pointless (even he now admits) fracturing of
the Lisp world at a time when we (they) had just completed a difficult
unification thereof. Small ecosystems in danger of expiring are hurt not
helped by being split in two
Meanwhile there is no way any contribution to Java can be anything but a
negative.
I'll send you the bill for the cleaners, piss on someone else's leg next
time.
Giovanni Gigante
> In this newsgroup, we are past the "core versus libraries".
> The distinction between language and library is a poorly defined,
> misleading concept.
I know. I meant that it seems to me that the "size" of a language is
defined by what its designers want it to be (in terms of: "all
conforming implementations MUST provide this"), not by what the language
is able to do in practice (like painting boxes or adding integers).
g
Pillsy
> Nicolas Neuss wrote:
[...]
> Scheme was nothing but a pointless (even he now admits) fracturing of
> the Lisp world at a time when we (they) had just completed a difficult
> unification thereof. Small ecosystems in danger of expiring are hurt not
> helped by being split in two
What unification? Huh?
Cheers,
Pillsy
Pillsy
If you actually program in the language, you'll very likely discover
that the CL ANS is a very useful reference.
Cheers,
Pillsy
Kenneth Tilton
> On Nov 13, 12:37 pm, Kenneth Tilton <kentil...@gmail.com> wrote:
>> The problem is: consider the source. How can it be enlightening to
>> listen to the boy who cried technology!?
>
> If getting predictions about computer technology wrong means that you
> have nothing enlightening to say, I'm gonna guess that nobody who ever
> makes *any* prediction about computer technology has anything
> enlightening to say.
>
> People screw things up.
Prediction? You fell for that bit about "no one needed the things a big
language offers back then"? What in CL has to do with drawing lines and
sockets and whatever else he had in mind with that insanity defense? The
things he threw away were core programming library stuff. He makes like
everyone was working on ascii tic-tac-toe software back then.
Oh, well, he talks fast and brusquely and orders the listener to do what
he says and now he has these awards so golly he must be right. Right?
>
>> Here is someone who created an entire language because he says languages
>> should be small who says fifteen years later, well, they should have
>> been small then but not now.
>
> Seems pretty reasonable seeing how memory and speed increased by 3
> orders of magnitude in the intervening years, and based on the
> languages people were using back in 1984[1], it just seems more
> realistic. C and Fortran 77 aren't languages that exactly stagger
> under the weight of their included batteries.
You think RAM was the issue? Got a citation? Paul Graham just created
Arc with Schemish justification and we have the resources so... hang on,
how was Scheme fast? Nope, this one won't hunt.
kt
>
> Cheers,
> Pillsy
>
> [1] Or so I've heard. At that point, the only language I'd used was
> Logo on the Apple II. The omission of turtle graphics from Scheme is
> unforgiveable, though[2].
>
> [2] I don't even know if I'm joking.
Rui Maciel
>> Boy, aren't we arrogant.
>
> Try to keep up, it's "smug":
>
> http://smuglispweeny.blogspot.com/
No, it's arrogance. You could only refer to your comments regarding Guy Steele as being smug if you could
somehow compare your contributions to the CS world to his.
Rui Maciel
Pascal Costanza
>
> I was really happy in your killfile. What does it take to get back in?
>
Don't worry, you've been enough exposed.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Kenneth Tilton
Ah, want to get precise, eh? That tells me you just like that he's a
technical writer. Nothing wrong with that.
Lesssee, arrogance:
http://www.google.com/search?rlz=1C1GGLS_enUS308US308&sourceid=chrome&ie=UTF-8&q=define:+arrogance
"overbearing pride evidenced by a superior manner toward inferiors "
Are you saying Steele is my inferior? Even I would not say that.
"a rock band from Chapel Hill, North Carolina"
Get a grip.
"having or showing feelings of unwarranted importance out of overbearing
pride"
I haven't said anything about myself. I am just saying constraints,
scheme, and java suck and so Steele is not credible to me on technology.
"the second studio album by rapper 2 Pistols"
Yer losing it, dude.
Let's summarize. I have made an unanswered case that Steele has placed
nothing but bad bets on technology. You are calling me names and
offering nothing else.
ie, You are a fucking jerk. Greetings, comrade!
Kenneth Tilton
> Kenneth Tilton wrote:
>>
>> I was really happy in your killfile. What does it take to get back in?
>>
>
> Don't worry, you've been enough exposed.
>
PWUAHAHAHAHAHAHAHAHA!!!!! Yes, you sure kicked my ass! Whoo boy did I
learn a lesson!
Did you want to say one good word about constraints, Scheme*, or Java?
kt
* OK, OK, lexical scope is the bomb. k
Raffael Cavallaro
> If you actually program in the language, you'll very likely discover
> that the CL ANS is a very useful reference.
To be completely unambiguous:
1. As Pillsy points out, as a practical matter, when programming in CL,
the hyperspec is quite useful because...
2. ...CL has a useful sized reference including as it does a great
number of useful facilities.
3. Scheme, including as it does fewer useful facilities, has a small
sized spec. Doing real programming in scheme means:
a. reading the small but not overly useful language spec
b. reading the much larger documentation for your implementation's
version of the many missing bits and/or implementing them yourself
c. repeating b for every single version of scheme you ever port
any code to.
So CL has a standard that is useful for actual programming, while
scheme has a standard that is useful for the small core language, but
not very useful for writing actual programs. For writing actual
programs, you really need to read the documentation for your
implementation. For example, a medium sized one is the manual for
Gambit which is a pdf of some 240 pages. Don't get us started on PLT
Scheme which has many hundreds (thousands?) of pages of documentation.
--
Raffael Cavallaro
Pillsy
> Pillsy wrote:
> > On Nov 13, 12:37 pm, Kenneth Tilton <kentil...@gmail.com> wrote:
> > If getting predictions about computer technology wrong means that you
> > have nothing enlightening to say, I'm gonna guess that nobody who ever
> > makes *any* prediction about computer technology has anything
> > enlightening to say.
> > People screw things up.
> Prediction? You fell for that bit about "no one needed the things a big
> language offers back then"?
I don't know if I believe it's true, but I don't think it's obviously
cuckoo for Cocoa Puffs.
[...]
> > Seems pretty reasonable seeing how memory and speed increased by 3
> > orders of magnitude in the intervening years, and based on the
> > languages people were using back in 1984[1], it just seems more
> > realistic. C and Fortran 77 aren't languages that exactly stagger
> > under the weight of their included batteries.
> You think RAM was the issue?
Dunno. 48K was enough to run that Logo interpreter!
Not that I knew what "interpreter" meant. Nor, for that matter, what
"48K" meant.
> Got a citation?
Not even a little bit.
> Paul Graham just created Arc with Schemish justification and we
> have the resources so...
...after pulling off his Guy Steele mask and telling us all how he
would have gotten away with it if it weren't for those pesky Tiltons!
Scheme was a really worthwhile experiment. It worked out phenomenally
well in some respects and pretty poorly in others. It had a major
influence on other languages, not least our beloved CL. Most of the
time, I'd rather eat broken glass than actually write something in
Scheme.
And I miss the freaking turtle in Common Lisp, too.
Cheers,
Pillsy
[...]
Nicolas Neuss
>> Yep. I think his impact was easily large enogugh to call him a giant.
>> But indeed, I see the net effect of his work as quite positive ...
>
> I can understand why you left it unspecified.
>
> [...]
>
> Scheme was nothing but a pointless (even he now admits) fracturing of
> the Lisp world at a time when we (they) had just completed a difficult
> unification thereof. Small ecosystems in danger of expiring are hurt
> not helped by being split in two
He has done a lot of good work for the Lisp world (CLtL 1&2 and Scheme),
but as you say correctly, the schism may also have done some damage.
Since there is no possibility to run the world without Steele a second
time, let's simply agree to disagree about him.
> Meanwhile there is no way any contribution to Java can be anything but
> a negative.
For CL, probably. For the world as a whole, I doubt it.
> I'll send you the bill for the cleaners, piss on someone else's leg next
> time.
Sorry about that :-)
> kt
Nicolas
Kenneth Tilton
> And I miss the freaking turtle in Common Lisp, too.
>
I could give you a quote on a nice Cells-based turtle. An OpenGL 3-D
turtle, at that.
kt
Vend
> Pascal Costanza wrote:
> > Kenneth Tilton wrote:
> >>> This is from Steele's foreward...
>
> >> Fortran) after creating Scheme so all the big implementors had to add
> >> back in all the things Steele took out to get the small spec? That
> >> constraints a fundamentally dead research program while it is hard to
> >> find a serious new software package that does not in some form support
> >> dataflow? That guy?
>
>
> >> Oh, yeah, let's see what he has to say.
>
> >http://vimeo.com/6624203
>
> (a) he needs to lose weight;
> (b) you missed the point: given his record to date... well, lessee:
>
> "all sequential languages encourage bugs of forgetting to initialize an
> accumulator to zero."
>
> c++ does not allow unitialized variables. And lisp has (for his example):
Actually c++ and c are the only high level languages I know (I don't
know about Fortran) that allow this kind of bug.
Vend
> Scheme was nothing but a pointless (even he now admits) fracturing of
> the Lisp world at a time when we (they) had just completed a difficult
> unification thereof. Small ecosystems in danger of expiring are hurt not
> helped by being split in two
Isn't Scheme older than Common Lisp?
frankenstein
> I think we may usefully compare the approximate number of pages
> in the defining standard or draft standard for several
> programming languages:
>
> Common Lisp 1000 or more
> COBOL 810
> ATLAS 790
> Fortran 77 430
> PL/I 420
> BASIC 360
> ADA 340
> Fortran 8x 300
> C 220
> Pascal 120
> DIBOL 90
> Scheme 50
Lad I am not sure what you gonna were smoking in the afternoon but pot
does not do you any good. No genuine man will ever only program in
r5rs scheme. A modern Scheme typically has about 1000 functions and a
manual covering 300 pages (condensed which means it could be 500 pages
as well):
http://www-sop.inria.fr/mimosa/fp/Bigloo/doc/bigloo.pdf
Moreover, no Scheme programmer, but for some academics, has ever been
proud of a tiny standard.
I get really sick when people spread libels about Scheme.
Raffael Cavallaro
Shh! don't let those pesky facts get in the way of a good usenet rant!
;^)
--
Raffael Cavallaro
Kenneth Tilton
:) No, that's OK, the rant about Scheme being a bad idea did not rely on
it having followed CL, that was just going to be gravy. And it was
/still/ a further fragmentation of the Lisp community, one so extreme it
survived the ecumenicalization that was CL. Definitely not helpful
especially since all they did was turn around and add everything back in
to get Lisps as big as CL but each different. Brillianr.
Meanwhile, wow. Steele actually denied small languages three times
before the cock crowed? Wow. I guess I won't have much trouble winning
that argument in the future. Gotta go bookmark that.
Do I get points for not cross-posting to c.l.scheme? You have no idea of
the temptation.
kt
Raffael Cavallaro
> Do I get points for not cross-posting to c.l.scheme? You have no idea
> of the temptation.
Just the opposite - I was hoping for a whole week's entertainment from
Ken "The Cell" Tilton...
... "You bring your small-language, scheme, candy ass, and The Cell
will lay the Smack-Down!"
;^)
--
Raffael Cavallaro
Jurgen Defurne
+1 Insightful!
Jurgen
Andrew Reilly
> which has many hundreds (thousands?) of pages of documentation.
Pages are so last-millenium!
The real measure of the adequacy of a language spec is how much heavier
it makes your laptop, once it's been downloaded?
;-)
Cheers,
--
Andrew
Rui Maciel
> If you actually program in the language, you'll very likely discover
> that the CL ANS is a very useful reference.
If you read the thread you will notice that no one has claimed that the CL standard wasn't useful. What has
been suggested was that the number of pages of a language's standard is somehow a measure of it's usefulness.
Rui Maciel
John Thingstad
> w_a_x_man wrote:
>> This is from Steele's foreward...
>
> Steele? The guy who started at CL and ended up at Java (well, and now
> Fortran) after creating Scheme so all the big implementors had to add
> back in all the things Steele took out to get the small spec? That guy?
> The guy who took a good idea like dataflow and came up with constraints
> a fundamentally dead research program while it is hard to find a serious
> new software package that does not in some form support dataflow? That
> guy?
>
> Oh, yeah, let's see what he has to say.
>
> Not.
>
> kenny
You are being silly. Steele is the language man. He has done this all his
life. C, Common Lisp, Java and now Fortress. To quote Coders at work by
Peter Seibel "they are all my children, different but all with their
individual qualeties". Perhaps you should widen your horizons.
--
John Thingstad
Kenneth Tilton
>> kenny
>
> You are being silly. Steele is the language man. He has done this all his
> life. C, Common Lisp, Java and now Fortress. To quote Coders at work by
> Peter Seibel "they are all my children, different but all with their
> individual qualeties". Perhaps you should widen your horizons.
>
How was your vacation? Restful, I hope! Welcome back.
kzo
GP lisper
> On 2009-11-12 19:16:28 -0500, Kenneth Tilton <kent...@gmail.com> said:
>
>> I'm three minutes in... do I have to keep on listening?
>
> Only if you want to learn an interesting programming paradigm
> (functional-parallel) which may well be to the 21st c what
> imperative-sequential programming was to the 20th.
Only in someone's wild fantasies.
In short, heard that stuff before more than once.
Predictions of the future have a near zero success rate.
I'd settle for getting the weather over the next 24 hrs correct.
GP lisper
>
> Where do you see a giant? Really. Where? The technical writing?
The one that signed his paycheck.
Another one is doing that nowdays.
So clones must listen!
GP lisper
>
> Scheme was a really worthwhile experiment. It worked out phenomenally
> well in some respects and pretty poorly in others. It had a major
> influence on other languages, not least our beloved CL. Most of the
> time, I'd rather eat broken glass than actually write something in
> Scheme.
s/Scheme/Perl/g
Which is a pita, since locals want me to write in perl still.
> And I miss the freaking turtle in Common Lisp, too.
Actually, thinking about how much I've been making my own images with
toolsets such as cl-gd, gozer and gifsicle, and what little I remember
about turtle graphics, I would expect that some Turtle Toolkit would
exist.
GP lisper
> Funny to think he /bullied/ the world into Constraints, Scheme, and Java.
Wasn't that Sun Microsystems standing right behind him?
GP lisper
>
> You are being silly. Steele is the language man. He has done this all his
> life. C, Common Lisp, Java and now Fortress.
"Fortress is a draft specification for a programming language,
initially developed by Sun Microsystems..."
"The language is not designed to be similar to Fortran."
The last makes it worthless.
I speak as someone that cruised thru grad school since I could
fix Fortran code fast, i.e. I was employable and in demand
"the DARPA contract was not renewed in November 2006"
what a surprise
oh, his latest work is a 3 year old failure?
GP lisper
>
> Scheme is an excellent language when it comes to distilling the
> essential fundamental concepts of programming. From that angle, it is
> quite impressive how much you can do with how little.
I also built the Taj Mahal with toothpicks in Z80 assembler.
A nightmare to maintain.
Tamas K Papp
> On Sat, 14 Nov 2009 12:31:39 -0600, <jpt...@online.no> wrote:
>>
>> You are being silly. Steele is the language man. He has done this all
>> his life. C, Common Lisp, Java and now Fortress.
>
>
> "Fortress is a draft specification for a programming language, initially
> developed by Sun Microsystems..." "The language is not designed to be
> similar to Fortran."
>
> The last makes it worthless.
> I speak as someone that cruised thru grad school since I could fix
> Fortran code fast, i.e. I was employable and in demand
So not being similar to Fortran makes a language worthless? Damn. I
have to ditch CL now. Thanks for opening my eyes :-)
Tamas
Raffael Cavallaro
> Only in someone's wild fantasies.
At this point the wild fantasy is that Moore's law will keep pace with
its rate of the late 20th c. Using 64+ cores will become commonplace,
so having a compiler that knows how to do this effectively will
similarly become commonplace.
--
Raffael Cavallaro
Pascal Costanza
People who can read have a real advantage.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Kenneth Tilton
Just curious. I'm not smart like you guys. Has anyoned proved the
communication cost of parallelization is a tractable problem? Without
using Cells, I mean.
kt
GP lisper
Nope. What people want is something that will run EXISTING Fortran
better, i.e. source code compatibility. Which is what EVERY large
(and important) numerical program has been written in since the dawn
of time. No one is interested in validating some new approach, and
that's fricken obvious (since "The language is not designed to be
similar to Fortran." options have been around for decades).
DARPA figured that out, hint hint.
GP lisper
>
> On 2009-11-15 04:43:31 -0500, GP lisper <spam...@CloudDancer.com> said:
>
>> Only in someone's wild fantasies.
>
> At this point the wild fantasy is that Moore's law will keep pace with
> its rate of the late 20th c.
Well, it's not, going beyond 32 nanometer will be difficult.
What market force will drive the work anyway?
Kenneth Tilton
> On Sun, 15 Nov 2009 10:01:01 -0500, <raffaelc...@pas.espam.s.il.vous.plait.mac.com> wrote:
>> On 2009-11-15 04:43:31 -0500, GP lisper <spam...@CloudDancer.com> said:
>>
>>> Only in someone's wild fantasies.
>> At this point the wild fantasy is that Moore's law will keep pace with
>> its rate of the late 20th c.
>
> Well, it's not, going beyond 32 nanometer will be difficult.
We'll make it up when we get organic molecules harnessed and a Whopper
can outperform a Cray.
yhihf, kenzo
Rob Warnock
+---------------
| Raffael Cavallaro wrote:
| > GP lisper <spam...@CloudDancer.com> said:
| >> Only in someone's wild fantasies.
| >
| > At this point the wild fantasy is that Moore's law will keep pace with
| > its rate of the late 20th c. Using 64+ cores will become commonplace, so
| > having a compiler that knows how to do this effectively will similarly
| > become commonplace.
|
| Just curious. I'm not smart like you guys. Has anyoned proved
| the communication cost of parallelization is a tractable problem?
For random problems, it's actually known *not* to be! But for
some problems -- those halfway between "single-threaded" and
"embarrassingly parallel" -- the communications cost of running
the problem on high-core-count ccNUMA machines is quite reasonable.
After all, that's how SGI survived so long selling ccNUMA machines
with 1000+ CPUs!! [Albeit the bulk of sales were in the 32-256 CPU
range.]
Of course, and more & more "dusty deck" codes were rewritten to run
loosely-coupled, cheap Ethernet- or InfiniBand-connected clusters
ate their lunch [and in fact that's what SGI mostly sells these days,
though they do still offer the 1000+ CPU Altix systems].
+---------------
| Without using Cells, I mean.
+---------------
Uh... er... Kenny, I suspect Cells would ahve a have a *LOT* more
work done on it to scale to 1000+ CPUs!!
-Rob
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Tamas K Papp
> On 15 Nov 2009 11:32:35 GMT, <tkp...@gmail.com> wrote:
>> On Sun, 15 Nov 2009 02:16:50 -0800, GP lisper wrote:
>>
>>> On Sat, 14 Nov 2009 12:31:39 -0600, <jpt...@online.no> wrote:
>>>>
>>>> You are being silly. Steele is the language man. He has done this all
>>>> his life. C, Common Lisp, Java and now Fortress.
>>>
>>>
>>> "Fortress is a draft specification for a programming language,
>>> initially developed by Sun Microsystems..." "The language is not
>>> designed to be similar to Fortran."
>>>
>>> The last makes it worthless.
>>> I speak as someone that cruised thru grad school since I could fix
>>> Fortran code fast, i.e. I was employable and in demand
>>
>> So not being similar to Fortran makes a language worthless? Damn. I
>> have to ditch CL now. Thanks for opening my eyes :-)
>
> Nope. What people want is something that will run EXISTING Fortran
> better, i.e. source code compatibility. Which is what EVERY large (and
It could be that some people want that (for convenience), but are they
going to get it? It is not obvious that you can milk Fortran (as it
is) for orders of magnitude more performance. HPF didn't work
miracles either. So IMO it is worthwhile to experiment with new
approaches, and you can't just dismiss something because it is not
Fortran.
> important) numerical program has been written in since the dawn of time.
> No one is interested in validating some new approach, and that's
> fricken obvious (since "The language is not designed to be similar to
> Fortran." options have been around for decades).
>
> DARPA figured that out, hint hint.
Hint, hint: very few people program numerical code in Fortran
nowadays. There is always the die-hard astrophysics & similar crowd,
mostly people who have invested time in Fortran when it still made
sense, but most people find that the pain of programming in Fortran is
not worth the improvement in speed. Fortran will have a niche for a
long time, mostly for legacy reasons (eg who wants to rewrite &
reoptimize LAPACK?), but is no longer the mainstream language for
numerical programs.
Tamas
John Thingstad
No, you got it utterly wrong. FORTRAN has been updated, the latest I
checked it was FORTRAN 2008. The main problem is multiprocessing and this
is the problem they set up to solve. Steele found this required a more
functional approach. Steele designs new languages. If it was a extension
for fortran they would have choosen someone else. Fortress is still alive
but it is now a opensource project, so it is anyones guess where that
ends up.
--
John Thingstad
Petter Gustad
> Of course, and more & more "dusty deck" codes were rewritten to run
> loosely-coupled, cheap Ethernet- or InfiniBand-connected clusters
> ate their lunch [and in fact that's what SGI mostly sells these days,
> though they do still offer the 1000+ CPU Altix systems].
That is my experience as well. Around 1992 I worked on an ASIC design
and implementation of a ccNUMA architecture based upon SCI (IEEE-1596,
the Scalable Coherent Interface).
However, most customers wanted just to use it as a fast interconnect
running PVM or MPI on top of it. So the design was split to enable a
low cost fast non-coherent interconnect which was attached to SBUS,
PCI and PCIe.
A few customers still wanted ccNUMA (like Convex Exemplar, and Data
General which used the ASICs in their NumaLine servers) over time, but
is seems like the pendulum is swinging towards ccNUMA again as
multicore awareness is growing among many programmers.
Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Pascal Costanza
I asked Guy Steele at OOPSLA recently, and Fortress is actually still
financially backed by Sun Microsystems. They are actively working on a
compiler (after the first prototype, which is 'just' an interpreter).
There is also a blog about Fortress at
http://projectfortress.sun.com/Projects/Community/blog
Guy Steele was very active in designing a couple of languages for
parallel programming, and was involved directly or indirectly in
Connection Machine Lisp, StarLisp, and Paralation Lisp, which had strong
influences on other languages, like NESL, ZPL, and friends.
ZPL also had a direct influence on Chapel.
Currently, the most interesting languages wrt parallel programming are
Chapel, Fortress and X10. It's very impressive what they are trying to
achieve, and they will probably all be very influential.
It's a pity that the Lisp communities seem a bit disconnected from that
line of research. It's a good sign that now more and more Common Lisp
implementations are supporting, or are going to support, symmetric
multiprocessing, which is an important step towards more interesting
concepts. But we should be paying more attention to what is going on
elsewhere as well.
John Thingstad
> ZPL also had a direct influence on Chapel.
>
> Currently, the most interesting languages wrt parallel programming are
> Chapel, Fortress and X10. It's very impressive what they are trying to
> achieve, and they will probably all be very influential.
I would like to add the two languages I have studied Erlang and Oz.
They constitute more that 10 yeas reaseach in paralell programming.
Mostly regarding messeage processing between paralell processes.
Also 'Beautifil concurrency' by S.P Jones on "software transactonal
memory" (Haskell). More spesific to multiple cores on a shared memory.
There is no one approach that satisfies all. I will probably be a
combination.
--
John Thingstad
William D Clinger
because he stated its standard is 187 pages, wrote:
> The Scheme standard does not even describe
> a function to read a line! There is no READ-LINE in the Scheme standard.
It's called get-line:
http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-9.html#node_idx_706
Will
Rainer Joswig
<fbdf0c29-9cad-46fc...@k19g2000yqc.googlegroups.com>,
William D Clinger <cesu...@yahoo.com> wrote:
> Rainer Joswig, who must have been talking about R6RS Scheme
> because he stated its standard is 187 pages, wrote:
Yes, sorry about that. Maybe I 'should' have talked about R5RS. ;-)
> > The Scheme standard does not even describe
> > a function to read a line! There is no READ-LINE in the Scheme standard.
>
> It's called get-line:
>
> http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-9.html#node_idx_706
>
> Will
Thanks.
I managed to not find it when I was looking for it. :-(
Pages in the standard (the PDF version)
used for describing the function:
ANSI Common Lisp READ-LINE: 1.3 pages
R6RS get-line : 0.17 pages
Rainer Joswig
Kenneth Tilton
So in the end it turns out CL is a small language but Steele is a
big-mouth? We'll add that to the indictment.
kxo
John Thingstad
Deep ultraviolet is the last commercially viable technology available. So
there is really no reasons we will see a circuit density beyond 45 nm for
some time.. And each miniaturization becomes increasingly more difficult.
Already people have given up doubling the clock frequency. 3 GHz perhaps
4 is about the max. Parallel processing is limited by Amdahl's law of
diminishing return.
Moore s law has already broken down.
--
John Thingstad
Nick Keighley
<raffaelcavall...@pas.espam.s.il.vous.plait.mac.com> wrote:
> On 2009-11-15 04:43:31 -0500, GP lisper <spamb...@CloudDancer.com> said:
>
> > Only in someone's wild fantasies.
>
> At this point the wild fantasy is that Moore's law will keep pace with
> its rate of the late 20th c. Using 64+ cores will become commonplace,
> so having a compiler that knows how to do this effectively will
> similarly become commonplace.
why does Moore's law imply increased parallelism?
Pascal J. Bourguignon
Because it will soon fail. It won't be practical to increase
frequency or density. Since silicium companies will still want to
compete on something, they'll have to increase parallelism.
--
__Pascal Bourguignon__
John Thingstad
> Because it will soon fail. It won't be practical to increase frequency
> or density. Since silicium companies will still want to compete on
> something, they'll have to increase parallelism.
There are other alternatives. More specialized hardware and asyncronous
logic for example. These may yield greter return in performance than just
adding more general purpose cores.
I expect improvements in GPU performance will give the most noticable
speed boost. 3D graphics and HDTV is probaly one of the few places where
most people will notice an improvement.
--
John Thingstad
Raffael Cavallaro
> There are other alternatives. More specialized hardware and asyncronous
> logic for example. These may yield greter return in performance than just
> adding more general purpose cores.
And these alternatives would require the same amount of compiler
re-writing (or an even greater amount). The point is that once Moore's
Law starts to fail (and it has), the only way to get increasing
performance is to re-conceptualize how computers work (i.e., not
strictly sequential - we started down this path years ago with
speculative and out of order execution).
For hardware manufacturers, the easiest way forward is to put more and
more cores in a single machine with some way to have them communicate
(shared cache and/or very high speed network). Since the hardware
manufacturers ultimately decide what is "mainstream" technology
(because their economies of scale allow them to provide certain options
at very low cost), if they decide that multicore is the future (and
they appear to have decided just that), then compiler writers and OS
architects are going to have to adapt to a multicore future.
--
Raffael Cavallaro