HTDP as an introductory programming text for a child
faust
HTDP and Dr Scheme.
Any particular issues that I should beware of ?
BTW, I like the way HTDP does not start off with scary ( to a
beginner) stuff like recursion, higher order functions and lambda
calculus unlike so many of the other books that I have seen.
My son ( Ashish ) initially wanted to learn Java but I think that I
have managed to convince him that Scheme is better for his purposes.
Arguments about elegance and purity did not work, so I essentially
said, that Scheme has a better programming environment ( Dr Scheme )
--------------------------------------------------------
Come see,
real flowers
of this pain-filled world.
(from Basho)
Joe Marshall
> I plan to teach my 12 year old Scheme using the online version of
> HTDP and Dr Scheme.
>
> Any particular issues that I should beware of ?
One surprising hurdle that my daughter needed to overcome was how
intolerant the implementation was of `creative' spelling.
Feuer
faust wrote:
>
> I plan to teach my 12 year old Scheme using the online version of
> HTDP and Dr Scheme.
>
> Any particular issues that I should beware of ?
Kids want games & cool graphics. Try to get to interaction and
graphics quickly.
> My son ( Ashish ) initially wanted to learn Java
Ugh. Java is totally inappropriate for children. Logo, Scheme, and
even C make more sense. C++ is about the worst you could choose.
> but I think that I
> have managed to convince him that Scheme is better for his purposes.
What are his purposes?
faust
>One surprising hurdle that my daughter needed to overcome was how
>intolerant the implementation was of `creative' spelling.
Ah !
faust
>> but I think that I
>> have managed to convince him that Scheme is better for his purposes.
>
>What are his purposes?
To make cool games probably ! :-)
Actually, he wanted to learn something new these holidays.
I showed him how using one of the teachpacks in HTDP, I could make a
graphical Weight on Earth -> Weight on Moon convertor complete with
buttons, windows look and free and slider in two lines of code.
When I contrasted it with the few hundred lines of Java to achieve
that, I think I convinced him.
OK, I cheated by using the convert teachpack to provide the GUI. But I
told him that. And also mentioned that if it was Java, I would
actually have used JBuilder to spit out hundreds of lines of GUI code.
faust
>> have managed to convince him that Scheme is better for his purposes.
>
>What are his purposes?
Pointing out that Crash Bandicoot 1 , 2 and 3 had their game play done
in a Scheme variant ( actually a Lisp dialect ) helped as well.
Shriram Krishnamurthi
> Joe Marshall <j...@ccs.neu.edu> , emitted these fragments:
>
>
> >One surprising hurdle that my daughter needed to overcome was how
> >intolerant the implementation was of `creative' spelling.
>
> Ah !
To be fair, so are virtually *every* programming language and
environment, unless you're planning to seat your child in front of an
Interlisp system. (I believe there are penal codes about this in some
states of the Union.)
If your child tends to make a lot of mistakes, you may find the Check
Syntax tool useful in at least identifying them.
Shriram
faust
>> >One surprising hurdle that my daughter needed to overcome was how
>> >intolerant the implementation was of `creative' spelling.
>>
>> Ah !
>
>To be fair, so are virtually *every* programming language and
>environment,
The "Ah" was meant to be mock amazement :-)
>unless you're planning to seat your child in front of an
>Interlisp system. (I believe there are penal codes about this in some
>states of the Union.)
>If your child tends to make a lot of mistakes, you may find the Check
>Syntax tool useful in at least identifying them.
To be honest, I find the Check Syntax tool helpful for my mistakes as
well ( blush..)
But thanks for an excellent book, Shriram .
HTDP ( and the excelellent pedagogic features of DrScheme ) go well
together.
Joe Marshall
> Kids want games & cool graphics. Try to get to interaction and
> graphics quickly.
The `problem' with cool graphics is that they seem to be fundamentally
imperative (are there any good graphics paradigms that are fully
functional?).
> > My son ( Ashish ) initially wanted to learn Java
>
> Ugh. Java is totally inappropriate for children. Logo, Scheme, and
> even C make more sense. C++ is about the worst you could choose.
I agree that C++ is about the worst (although it may have strong
competition from Perl). I dislike Logo, though. Logo built around a
fundamental paradigm of mutating global state, and I can't teach that
with good conscience.
Joe Marshall
> faust <urf...@optushome.com.au> writes:
>
> > Joe Marshall <j...@ccs.neu.edu> , emitted these fragments:
> >
> >
> > >One surprising hurdle that my daughter needed to overcome was how
> > >intolerant the implementation was of `creative' spelling.
> >
> > Ah !
>
> To be fair, so are virtually *every* programming language and
> environment, unless you're planning to seat your child in front of an
> Interlisp system. (I believe there are penal codes about this in some
> states of the Union.)
If there aren't, there should be.
But I think that certain kinds of DWIM *are* useful. My feeling is
one shouldn't write programs that *rely* on dwimming. I think that if
the DWIM
a) only applies to interactive input, and
b) suggests, but not performs, the correction
is probably ok. (Although I tend to get really annoyed when the
computer says `oh, you should have done this: ....' If it is so
smart, why doesn't it do it itself? So I might relax part b)
Hrvoje Blazevic
> I dislike Logo, though. Logo built around a
> fundamental paradigm of mutating global state, and I can't teach that
> with good conscience.
>
I wonder where did you get that?
There are different Logos, granted -- but, before expressing a "global"
opinion like this, maybe, you should take a look at Berkeley Logo, and Brian
Harvey's CSLS books.
Joe Marshall
Unless Logo has change *quite* dramatically since I last checked,
there is a `turtle' (the global state) that you command to move
(mutate).
....google....google......
Ah, here it is. Berkely Logo does have a turtle that you move about
by commanding it.
To be fair, Brian Harvey's book puts the turtle code in chapter 10,
and focuses on the more functional aspects of Logo first, but without
the turtle, what advantage does Logo have over Lisp or Scheme?
Hrvoje Blazevic
>
> Ah, here it is. Berkely Logo does have a turtle that you move about
> by commanding it.
Hmm ... and how do you move the turtle in Scheme. I have looked at various
implementations of turtle graphics in Scheme, and (granted they do not use
global variables, because one can have many turtles) yet still -- they move
turtles around by altering the local state.
And whether you give it a "command", or pass it a "message" -- eventually you
do alter the state of some variable somewhere.
But -- OK, I was not talking about turtle graphics at all. I took your comment
to refer to the Logo as a language -- of which (at least in CSLS) the turtle
holds an extremely unimportant place.
>
> To be fair, Brian Harvey's book puts the turtle code in chapter 10,
> and focuses on the more functional aspects of Logo first, but without
> the turtle, what advantage does Logo have over Lisp or Scheme?
It has Word/Sentence abstraction -- which is the only point (when talking
about kids) where Logo really has an advantage over Lisp or Scheme.
This thread was about starting kids (12 years old), so maybe CSLS is the right
way to go. If you insist on Scheme, then SSICS is also a good prospect -- it
gives Scheme the very abstraction it is missing (when compared to Logo) words
and sentences (if you check the author, you will know why :-)
Not to be misunderstood, I do not favor SSICS over HtDP, but if I was 12, I
probably would. HtDP is a bit too systematic for that age.
Brian Harvey
>Unless Logo has change *quite* dramatically since I last checked,
>there is a `turtle' (the global state) that you command to move
>(mutate).
I don't see how you can do graphics of any sort without mutating the global
array of screen pixels! You can use functional ideas as part of the process
of generating the picture, as in SICP 2.2.4 for example, but ultimately to get
the picture on the screen you have to draw it.
But *turtle* graphics is based on using the idea of locality to make the work
easier, even though the locality isn't a matter of scope of variables. The
traditional approach to graphics is to impose a Cartesian coordinate system on
the screen and draw lines using the (global) coordinates of the endpoints. So
to draw a square you might say (never mind the syntax)
drawline [0 0] [0 100]
drawline [0 100] [100 100]
drawline [100 100] [100 0]
drawline [100 0] [0 0]
or perhaps
moveto [0 0]
drawto [0 100]
drawto [100 100]
drawto [100 0]
drawto [0 0]
But in turtle graphics, the turtle's motion is not with respect to a global
coordinate system, but with respect to its own (local) position and heading.
So you say
penup
home ; means moveto [0 0] and setheading north
pendown
forward 100
right 90
forward 100
right 90
forward 100
right 90
forward 100
right 90
or you can abbreviate this as
penup
home
pendown
repeat 4 [forward 100 right 90]
What's the difference? Suppose you'd like to draw a *tilted* square. In the
Cartesian approach, you have to use trigonometry to figure out where the
corners of the square should be. But with turtle-relative motion, you just
say
penup
home
right 27 ; tilt 27 degrees clockwise
pendown
repeat 4 [forward 100 right 90]
The same forward-right commands now draw a tilted square. (The HOME command
implicitly uses the global coordinate system, but that isn't an essential part
of the drawing; I just put it in so that the result would be exactly like the
Cartesian version. You typically write a procedure:
to square :size
repeat 4 [forward :size right 90]
end
and then you can draw the square at any position or heading.)
Now, this isn't the same as teaching composition of functions and local
scope. But it *does* introduce the broader idea of locality to young kids,
so that they might arguably be more ready for composition of functions
when they're a little older.
Here's some code from _Computer Science Logo Style_ that uses local
variables and a sort of imperative composition of functions to help make
interesting symmetric drawings:
to protect.heading :squig
localmake "oldheading heading
run :squig
setheading :oldheading
end
to spin :turns :command
repeat :turns [protect.heading :command right 360/:turns]
end
To use it you write a procedure that draws any old squiggle:
to squoggle
forward 50 right 70
forward 10 right 160
forward 35 right 58
end
spin 6 [squoggle]
>To be fair, Brian Harvey's book puts the turtle code in chapter 10,
>and focuses on the more functional aspects of Logo first, but without
>the turtle, what advantage does Logo have over Lisp or Scheme?
Besides the word/sentence abstraction that Hrvoje mentioned, another
difference that I consider advantageous *for young beginners* is that
Logo uses dynamic rather than lexical scope. Yes, this is wrong in
principle, and you don't get free persistent local state variables from
lambda-inside-let, but I think it's an easier model for beginners to
understand. For example, suppose you're in the common situation in
which procedure A (which has a bug in it) calls B, which calls C, which
calls some primitive that gives an error message. In Logo, you can arrange
to be left with an interactive prompt (it's a REL rather than a REPL since
Logo doesn't automatically print return values) in the scope of the call
to C. Because of dynamic scope, you can then examine and/or modify not
only C's local variables, but also those of A and B. (Yeah, if you used
the same names in all of them, some variables are shadowed, but that's
bad style in any language.) You don't have to think about scope at all;
if a variable exists, it's available.
I certainly wouldn't choose Logo over Scheme for production programming,
or even for teaching undergraduate computer science majors. But I'd
certainly choose it for 8-year-olds, and possibly even for 14-year-olds.
Except for the few born mathematicians, people mostly find functions to be
a difficult idea (especially first-class functions); they may learn better
if you ease them into it.
Brian Harvey
>> Interlisp system. (I believe there are penal codes about this in some
>> states of the Union.)
>
>If there aren't, there should be.
>I think that if the DWIM
> a) only applies to interactive input, and
> b) suggests, but not performs, the correction
>is probably ok.
And indeed that's how Interlisp DWIM worked. Except that instead of rule (a)
its rule is that dwimming is done only at the moment when you're about to see
an error message, and if the error is inside a procedure rather than in
interactive input, it offers to edit the procedure. Why is that bad? Are
typos less likely in procedure definitions? And rule (b) is generalized to
let the user specify a degree of confidence about each of the modifications
that DWIM knows how to make, so that you can let it do some of them
automatically but ask you about others.
Think of it as an early use of the principle that the medical expert system
people at SUMEX rediscovered much later: People will trust and use your
system only if the people are still in control, and the system explains why
it's making its suggestions.
faust
>> Kids want games & cool graphics. Try to get to interaction and
>> graphics quickly.
>The `problem' with cool graphics is that they seem to be fundamentally
>imperative (are there any good graphics paradigms that are fully
>functional?).
Yes.
Have a look at Fran and Pan.
http://www.conal.net/Fran/
http://conal.net/Pan/
However, I will not be trying to teach Ashish this since they are
implemented in Haskell.
>I agree that C++ is about the worst (although it may have strong
>competition from Perl). I dislike Logo, though. Logo built around a
>fundamental paradigm of mutating global state, and I can't teach that
>with good conscience.
Logo is midly disgusting.However, Star Logo is probably worth having a
look at. It is an easy way to introduce kids to artifical life and
emergent complexity.
"StarLogo is a specialized version of the Logo programming language.
With traditional versions of Logo, you can create drawings and
animations by giving commands to graphic "turtles" on the computer
screen. StarLogo extends this idea by allowing you to control
thousands of graphic turtles in parallel. In addition, StarLogo makes
the turtles' world computationally active: you can write programs for
thousands of "patches" that make up the turtles' environment. Turtles
and patches can interact with one another -- for example, you can
program the turtles to "sniff" around the world, and change their
behaviors based on what they sense in the patches below. StarLogo is
particularly well-suited for Artificial Life projects.
StarLogo is a programmable modeling environment for exploring the
workings of decentralized systems -- systems that are organized
without an organizer, coordinated without a coordinator. With
StarLogo, you can model (and gain insights into) many real-life
phenomena, such as bird flocks, traffic jams, ant colonies, and market
economies."
http://education.mit.edu/starlogo/starterpage.html
faust
>I do not favor SSICS over HtDP, but if I was 12, I
>probably would. HtDP is a bit too systematic for that age.
SSICS ?
Joe Marshall
> Joe Marshall <j...@ccs.neu.edu> writes:
> >> Interlisp system. (I believe there are penal codes about this in some
> >> states of the Union.)
> >
> >If there aren't, there should be.
> > [...]
> >I think that if the DWIM
> > a) only applies to interactive input, and
> > b) suggests, but not performs, the correction
> >is probably ok.
>
> And indeed that's how Interlisp DWIM worked. Except that instead of rule (a)
> its rule is that dwimming is done only at the moment when you're about to see
> an error message, and if the error is inside a procedure rather than in
> interactive input, it offers to edit the procedure. Why is that bad? Are
> typos less likely in procedure definitions? And rule (b) is generalized to
> let the user specify a degree of confidence about each of the modifications
> that DWIM knows how to make, so that you can let it do some of them
> automatically but ask you about others.
I seem to recall that the problem with the Interlisp DWIM is that
there were certain source code files that simply would not compile or
work without the DWIM being turned on and that people were
`programming in DWIM' rather than in lisp.
I was hoping that my two rules would tend to make this effect go away.
I think that typos at the command line are far more common (and
annoying) than typos in procedure definitions (at least they seem to
be for me). I don't want to fall into the trap of assuming that the
DWIM will fix my code using some heuristic mechanism, so making it
a command-line only feature alleviates the typo annoyance without
building in dependence at the source code level.
linergy
> Pointing out that Crash Bandicoot 1 , 2 and 3 had their game play done
> in a Scheme variant ( actually a Lisp dialect ) helped as well.
That is hilarious. I used the same line with my nephew. His ears
perked up right away.
He says he wants to go to MIT and be a game programmer. So, I told
him about scheme and its use at MIT.
In the end, he didn't start using scheme.
He was impatient for fabulous 3D results. So, I turned him on to
www.alice.org and he loved it.
Alice competes well against his PS2 and Gamecube games. Of course I
would prefer that he learn scheme. But, he is having fun and is thoroughly
engaged.
He does not really believe that he is programming though.
"Programming can't be this easy!"
I think that a decent 3D engine, a set of modeled objects, a few
configurable games, and a junior version of HTDP based on these would
be a marvelous thing for students of all ages.
A funny thing happened while I was showing my nephew how to use Alice.
My Dad was watching and he said to me later that "even I could click
and drag things around like that." I tried to explain that the
underlying process is the same whether he is clicking/dragging in
Alice or typing out his program and that it is normal to abstract the
underlying complexity of what is actually occurring. But he didn't
seem to be buying it. It's as if people associate the _typing_ of
programs with some sort of esoteric craft, while clicking and
dragging is something anybody should be able to do.
Hrvoje Blazevic
> Hrvoje Blazevic <hrv...@despammed.com> , emitted these fragments:
>
>
>>I do not favor SSICS over HtDP, but if I was 12, I
>>probably would. HtDP is a bit too systematic for that age.
>
>
> SSICS ?
>
Joe Marshall
> Joe Marshall <j...@ccs.neu.edu> writes:
> >Unless Logo has change *quite* dramatically since I last checked,
> >there is a `turtle' (the global state) that you command to move
> >(mutate).
>
> I don't see how you can do graphics of any sort without mutating the global
> array of screen pixels! You can use functional ideas as part of the process
> of generating the picture, as in SICP 2.2.4 for example, but ultimately to get
> the picture on the screen you have to draw it.
Of course! (Although.... maybe you could use a stream-oriented
technique or monads or something to model graphics in a functional
manner. I'm not sure this would work for kids. I can't imagine
trying to explain monads to a seven-year-old.)
In any case, I'm not suggesting that there is something about Logo
that makes it *worse* than any other language for graphics. As much
as I like graphics and see the appeal of using them as a way to entice
new programmers to bigger and better things, I still think that
imperative programming is a *very* wrong place to start and that the
nature of graphics causes imperative programming to be brought to the
foreground.
Of all the Logo books I've seen, yours is the *only* one that doesn't
start with the imperative statement `forward 10'. I think Logo
*encourages* this sort of thinking.
> But *turtle* graphics is based on using the idea of locality to make
> the work easier. Suppose you'd like to draw a *tilted* square. In
> the Cartesian approach, you have to use trigonometry to figure out
> where the corners of the square should be. But with turtle-relative
> motion, you just say
>
> penup
> home
> right 27 ; tilt 27 degrees clockwise
> pendown
> repeat 4 [forward 100 right 90]
>
> The same forward-right commands now draw a tilted square. (The HOME command
> implicitly uses the global coordinate system, but that isn't an essential part
> of the drawing; I just put it in so that the result would be exactly like the
> Cartesian version. You typically write a procedure:
>
> to square :size
> repeat 4 [forward :size right 90]
> end
>
> and then you can draw the square at any position or heading.)
Just to be argumentative, it is perfectly reasonable to cast this in a
Cartesian co-ordinate system: Rather than tilt the turtle prior to
drawing the square, *tilt the paper*.
[ignore the syntax here]
(call-with-paper-at-angle 27
(lambda () (draw-square)))
> to protect.heading :squig
> localmake "oldheading heading
> run :squig
> setheading :oldheading
> end
Yuck!
This is *terrible*! If a Scheme student in college wrote a piece of
code like that you'd flunk him!
> Now, this isn't the same as teaching composition of functions and local
> scope. But it *does* introduce the broader idea of locality to young kids,
> so that they might arguably be more ready for composition of functions
> when they're a little older.
In my opinion, it is better to teach the `right thing' from the
beginning than to teach something wrong and correct it later.
At least, that's the approach I like to take with my kids.
> >To be fair, Brian Harvey's book puts the turtle code in chapter 10,
> >and focuses on the more functional aspects of Logo first, but without
> >the turtle, what advantage does Logo have over Lisp or Scheme?
>
> Besides the word/sentence abstraction that Hrvoje mentioned, another
> difference that I consider advantageous *for young beginners* is that
> Logo uses dynamic rather than lexical scope. Yes, this is wrong in
> principle, and you don't get free persistent local state variables from
> lambda-inside-let, but I think it's an easier model for beginners to
> understand. For example, suppose you're in the common situation in
> which procedure A (which has a bug in it) calls B, which calls C, which
> calls some primitive that gives an error message. In Logo, you can arrange
> to be left with an interactive prompt (it's a REL rather than a REPL since
> Logo doesn't automatically print return values) in the scope of the call
> to C. Because of dynamic scope, you can then examine and/or modify not
> only C's local variables, but also those of A and B. (Yeah, if you used
> the same names in all of them, some variables are shadowed, but that's
> bad style in any language.) You don't have to think about scope at all;
> if a variable exists, it's available.
>
> I certainly wouldn't choose Logo over Scheme for production programming,
> or even for teaching undergraduate computer science majors. But I'd
> certainly choose it for 8-year-olds, and possibly even for 14-year-olds.
> Except for the few born mathematicians, people mostly find functions to be
> a difficult idea (especially first-class functions); they may learn better
> if you ease them into it.
It just really rubs me the wrong way to teach kids something easy but
wrong rather than the right thing from the get-go. It is true that
most people find functions to be a difficult idea, but rather than
teaching them in imperative style, perhaps we should try harder to
come up with a functional model that is easier to grasp. It *does*
put a larger burden on the instructor, but that's what we're supposed
to be here for.
faust
>
>In the end, he didn't start using scheme.
>He was impatient for fabulous 3D results. So, I turned him on to
>www.alice.org and he loved it.
Thanks !
I have shown him Alice and he is interested.
ol...@pobox.com
> > I don't see how you can do graphics of any sort without mutating the global
> > array of screen pixels! You can use functional ideas as part of
> > the process of generating the picture, as in SICP 2.2.4 for example, but
> > ultimately to get the picture on the screen you have to draw it.
> Of course! (Although.... maybe you could use a stream-oriented
> technique or monads or something to model graphics in a functional
> manner. I'm not sure this would work for kids. I can't imagine
> trying to explain monads to a seven-year-old.)
Applying the electric field to a liquid crystal certainly seems
imperative. Describing which crystals to mutate does not have to
be. You can describe a picture by simply _telling_ the color of
particular pixels or areas.
Many high-level rendering packages let the user add his own
textures. The packages however do not permit the user to access the
screen or the frame buffer, let alone write into them. The user
specifies the texture as a function f(i,j), which yields the color
value given two local coordinates. The function f(i,j) can be either
"static" (a static image, that is), or "dynamic" (a computational
process, a "shader"). In either case the function does not do any
drawing.
Jerzy Karczmarczuk has been using this approach to make fascinating
pictures, and to teach his students functional programming:
http://srfi.schemers.org/srfi-25/mail-archive/msg00069.html
(a summary of Jerzy Karczmarczuk's PADL02 talk)
http://users.info.unicaen.fr/~karczma/Work/Clastic_distr/clastic.html
(a web page with a few samples). It is interesting to note that
surprisingly many textures can be described not only functionally but
also in a coordinate-free manner.
> I can't imagine trying to explain monads to a seven-year-old.
Did you explain compilation, macro-expansion, or any kind of staging?
The compiler of a drawing program does not draw anything. It emits
instructions for drawing. Just like a movie script writer does not
yell, jump off the cliff or build sets. The writer merely tells others
what to do. A single instruction -- in a real or a virtual machine --
is a "monad". For example, an 'rm' command does some action and
returns a value (the success code). We can write a _parameterized_
action, which does one thing or the other based on the return code
(e.g., prints "OK" or "failure"). We can then chain the 'rm' action
and the parameterized action into a bigger action, the one that
removes something and prints something. If an action does not affect
the script (i.e., the compiled program does not try to modify or
remove itself) we can freely chain actions: we have associativity. If,
in addiction, we can generate success codes without doing anything
(like /bin/true and /bin/false in Unix) -- we have a monad.
Max Hailperin
...
> I don't see how you can do graphics of any sort without mutating the global
> array of screen pixels! You can use functional ideas as part of the process
> of generating the picture, as in SICP 2.2.4 for example, but
True enough, but equally well to get the numerical value 36 onto the
screen you have to decompose it into the digits 3 and 6, and then you
need to figure out which pixels to turn on to form the each of those
two characters. No one worries about that when they type in
(* 6 6)
or, after a suitable definition,
(square 6)
to their real-eval-print-loop (REPL). They just take it for granted
that when the result of the evaluation is a number, the REPL will
display it appropriately. There is no reason why the same can't be
true if the value is an image rather than a number. Some other
posters have pointed at some quite sophisticated functional graphics
systems that can cope with interaction, etc. However, for the basics
this isn't needed. You just need functional constructors that make
images, including combining images to make new images. So long as the
REPL will then display the image, you can easily do functional
graphics. This is the approach we take in Concrete Abstractions(*),
though it wasn't original to us. I'm not claiming that for all
purposes it is the best choice, or even for all introductory pedagogic
purposes. I happen to like local imperative turtle graphics, a la
Logo, for some introductory teaching. However, it does show how
graphics can be done in a purely functional setting without getting
into major complexity. It allows our students to type in things like
(overlay (line 0 0 1 1)
(line 0 0 1 -1))
or, after suitable definitions,
(pinwheel (pinwheel nova-bb))
and have an image show up in their REPL.
-Max Hailperin
Associate Professor of Computer Science
Gustavus Adolphus College
800 W. College Ave
St. Peter, MN 56082
USA
http://www.gustavus.edu/~max/
(*) Concrete Abstractions: An Introduction to Computer Science Using
Scheme, by Max Hailperin, Barbara Kaiser, and Karl Knight,
published by Brooks/Cole, 1999.
http://www.gustavus.edu/~max/concrete-abstractions.html
Dorai Sitaram
>Feuer <fe...@his.com> writes:
>
>> Kids want games & cool graphics. Try to get to interaction and
>> graphics quickly.
>
>The `problem' with cool graphics is that they seem to be fundamentally
>imperative (are there any good graphics paradigms that are fully
>functional?).
MetaPost. It does have a := statement but it is
rarely used or advised for anything other than setting
tracing levels.
Shriram Krishnamurthi
> I don't see how you can do graphics of any sort without mutating the
> global array of screen pixels! You can use functional ideas as part
> of the process of generating the picture, as in SICP 2.2.4 for
> example, but ultimately to get the picture on the screen you have to
> draw it.
That assumes you can have only one picture on a screen. The problems
of state arise primarily when you can see only one instant in the
object's history. If images are values, you can have as many as you
want around ... (cue to PLT Scheme.)
Shriram