2D graphics/turtle lib suitable for kids?

My daughter found Land of Lisp on my shelf and wants to learn Common Lisp. I approve of course, but for a 10-year old child I think the examples in the book are a bit too abstract. I'd like to start simple interactive graphics (create stuff from the REPL - instant satisfaction), but I have no luck finding a simple 2D graphics lib for this, preferably with turtle graphics, and perhaps other simple 2D functions (lines, basic shapes, fill with colors etc.). Is there such a package which is small and easy enough to be useful for small children just starting out? Any advice appreciated.

yena wrote:My daughter found Land of Lisp on my shelf and wants to learn Common Lisp. I approve of course, but for a 10-year old child I think the examples in the book are a bit too abstract. I'd like to start simple interactive graphics (create stuff from the REPL - instant satisfaction), but I have no luck finding a simple 2D graphics lib for this, preferably with turtle graphics, and perhaps other simple 2D functions (lines, basic shapes, fill with colors etc.). Is there such a package which is small and easy enough to be useful for small children just starting out? Any advice appreciated.

If I were you, I'd just use lispbuilder-sdl and make whatever primitives I need on top of it. Lispbuilder handles window creation, framerate, and the event pump pretty cleanly. It includes draw-pixel, draw-line, as well as draw functions for filled and unfilled rectangles, polygons, and circles. You'd have to define your own sprite type and... google image search a turtle to use to that end, I guess.

Duke wrote: google image search a turtle to use to that end, I guess.

BAH! Just use a triangle!
It was good enough for when I was learning how to work Apple Logo on my //c with the tiny phosphorescent green-screen

I think Duke's idea is a good one (if you have the time). I discovered programming through Basic, because I could put it into mode 13h and draw pixels. I think pixel plotting is probably an easier starting point than rotation, recursion and line drawing.

Were it me, I'd probably use SDL to create a 800x600 window, and then create a 'pixel' routine to draw 4x4 square (in one of 5 colors: RED, BLUE GREEN, WHITE, BLACK) big and visible. I'd expect this to be about 100 loc, max.

With pixel drawing routines, she can probably figure out horz-line routines and vert-line routines. Then progress to using those to draw big boxes, hollow boxes, a trail of boxes, a moving box, etc. In time you might relax limitations --- draw 1 pixel rather than 4, use RGB colors, manually control double buffering, etc.

Just an idea, if you keep your beginner library short (less than 100 loc) than she is never far removed from the real language itself.

Teaching Common Lisp to a 10 years old kid? Man, you are my hero

Seriously, if you eventually manage to do it, I would love if you could explain how you did it. Of course, please don't feel obligated to it, just a relative small post telling your experience will be enough for me

Warren Wilkinson wrote:I think Duke's idea is a good one (if you have the time). I discovered programming through Basic, because I could put it into mode 13h and draw pixels. I think pixel plotting is probably an easier starting point than rotation, recursion and line drawing.

Were it me, I'd probably use SDL to create a 800x600 window, and then create a 'pixel' routine to draw 4x4 square (in one of 5 colors: RED, BLUE GREEN, WHITE, BLACK) big and visible. I'd expect this to be about 100 loc, max.

With pixel drawing routines, she can probably figure out horz-line routines and vert-line routines. Then progress to using those to draw big boxes, hollow boxes, a trail of boxes, a moving box, etc. In time you might relax limitations --- draw 1 pixel rather than 4, use RGB colors, manually control double buffering, etc.

Just an idea, if you keep your beginner library short (less than 100 loc) than she is never far removed from the real language itself.

Different strokes for different folks, but I would have found that tedious and painful.
LOGO is beautiful, because once you write a few routines you can use those to draw stick figures and other simple objects, and if you have something more complete at your disposal (like SDL gives) you can grow from there.
Advocating a programming style inspired by BASIC in a CL forum is also a bit o_O to me...

For an out-of-the-box solution, give Scratch a try.

Tk's canvas is not far from what you describe. Simple, cross-platform, but a bit dated in capabilities. Easily accessible through LTK.

The new HTML canvas is much better. I people are using it from CL; Kenny Tilton or Tim Daly might be able to point you towards CL bindings.

There's also the Qt canvas. A bit heavier API. Accessible via CommonQt, or on ECL via EQL.

Thanks all for the replies so far. I'm a bit short of time and was hoping to find something ready to use, but I suppose that putting together a simple turtle lib myself shouldn't be too hard. I'll have a look at the sdl and tk options. Re: Lisp for a child - I don't really think that is too far-fetched, strange, or harder than any other approach. Her mind is still open to non-C syntax We actually tried Ruby but it was more confusing to her - too many ways to get syntax errors.

TheGZeus wrote:Different strokes for different folks, but I would have found that tedious and painful.
LOGO is beautiful, because once you write a few routines you can use those to draw stick figures and other simple objects, and if you have something more complete at your disposal (like SDL gives) you can grow from there.
Advocating a programming style inspired by BASIC in a CL forum is also a bit o_O to me...

I've never used logo, so I can't judge. I just feel that teaching cartesian coordinates would be easier than trigonometry, and since all graphical displays are based on pixels, also more useful long term. I'm also guessing that a child might be more interested in gradients and colorful patterns than they would be in triangles and recursion, this is easier with pixel plotting.

Its simpler too -- there is no pen, if you do it right there is just a continuous block of memory. Line drawing calls pixel drawing. Box drawing calls line drawing. Its perfectly functional. =)

Warren Wilkinson wrote:

TheGZeus wrote:Different strokes for different folks, but I would have found that tedious and painful.
LOGO is beautiful, because once you write a few routines you can use those to draw stick figures and other simple objects, and if you have something more complete at your disposal (like SDL gives) you can grow from there.
Advocating a programming style inspired by BASIC in a CL forum is also a bit o_O to me...

I've never used logo, so I can't judge. I just feel that teaching cartesian coordinates would be easier than trigonometry, and since all graphical displays are based on pixels, also more useful long term. I'm also guessing that a child might be more interested in gradients and colorful patterns than they would be in triangles and recursion, this is easier with pixel plotting.

Its simpler too -- there is no pen, if you do it right there is just a continuous block of memory. Line drawing calls pixel drawing. Box drawing calls line drawing. Its perfectly functional. =)

You're not teaching trigonometry, but basic geometry. You're still working from coordinates, just abstract ones. fd 1 (forward one, in a hypothetical dialect) could be one pixel (it was in Apple Logo) but it could also be an arbitrary distance, with 1.235 as a possibility, as well.

Advocating direct pixel manipulation seems... archaic, and non-portable to higher/lower resolutions.
SVG is much more flexible than (insert bitmapped format).
NeWS was much more flexible than X.

Artists don't draw on graphing paper, yo.

I wrote a simple turtle graphics library based on lispbuilder-sdl. The code can be found here: https://github.com/johanberntsson/cl-tu ... urtle.lisp

You're not teaching trigonometry, but basic geometry. You're still working from coordinates, just abstract ones. fd 1 (forward one, in a hypothetical dialect) could be one pixel (it was in Apple Logo) but it could also be an arbitrary distance, with 1.235 as a possibility, as well.

Advocating direct pixel manipulation seems... archaic, and non-portable to higher/lower resolutions.
SVG is much more flexible than (insert bitmapped format).
NeWS was much more flexible than X.

Artists don't draw on graphing paper, yo.

I like this topic =). Grid drawing is called pixel art: http://www.pixeljoint.com/pixels/new_ic ... ?ob=rating, I did it all the time to make sprites. Flexibility of the output isn't important here, simplicity of ideas is (she'll ask "How can I make it red?" long before she'll ask "How can I make it 1024x768 triple buffered with 32 bits, an alpha channel and a Z buffer?" -- hyperbole I know)

Direct pixel manipulation is the simplist, most primitive and most portable way of doing graphics. All other interfaces are just predefined pixel plotting routines. Algebra is the arithmatic as vectors are to pixels. My suggestion is to start at the logical beginning (pixels) and grow upwards to turtles (or gradients, or boxes, or triangles, or sprites, or text or whatever your kid is interested in).

What good is turtles when you want gradients? I'd bet she'd prefer making gradient rainbows to manipulating a turtle. Pixel plotting can, with equal ease, do both.

I wanted to demonstrate the simplicity of raw pixel pushing. I wrote the library I was talking about, it took under an hour. It requires SDL, SBCL, and no other libraries.

Makefile

gfx.so : gfx.c
	gcc -c -fPIC `sdl-config --cflags`  `sdl-config --libs` gfx.c && ld -shared -o gfx.so gfx.o

gfx.c

#include "SDL/SDL.h"

SDL_Surface* screen = NULL;

int sdl_start (int x, int y, int d) {
  if (SDL_Init( SDL_INIT_VIDEO | SDL_INIT_EVENTTHREAD ) != 0) { return -1; }
  screen = SDL_SetVideoMode( x, y, d, SDL_SWSURFACE ); 
  if (screen  == NULL) { return -1; }
  return 0; 
}

void sdl_stop () {
  SDL_FreeSurface( screen );
  screen = NULL; 
  SDL_Quit();
}

char* gfx_error () { return SDL_GetError(); }
void gfx_show () { SDL_Flip(screen); }
void* gfx_raw () { return screen->pixels; }
void  gfx_lock () { SDL_LockSurface(screen); }
void gfx_unlock () { SDL_UnlockSurface(screen); }

gfx.lisp

(defpackage :gfx
  (:use :common-lisp :sb-alien)
  (:export ;; +width+ +height+ +depth+ 
           +wide+ +tall+ +white+ +black+ +red+ +green+ +blue+
	   gfx-start gfx-stop gfx-show put))

(in-package :gfx)

(load-shared-object "libSDL.so")
(load-shared-object (car (directory "gfx.so")))  ;; Get the abs path of gfx.so.
(define-alien-variable screen system-area-pointer)
(define-alien-routine sdl-start      int (width int) (height int) (depth int))
(define-alien-routine sdl-stop       void)
(define-alien-routine gfx-error      c-string)
(define-alien-routine gfx-show       void)
(define-alien-routine gfx-raw        system-area-pointer)
(define-alien-routine gfx-unlock     void)
(define-alien-routine gfx-lock     void)

(defconstant +width+ 800)
(defconstant +height+ 600)
(defconstant +depth+ 32)

(defconstant +white+ #xFFFFFF)
(defconstant +black+ #x000000)
(defconstant +red+   #xFF0000)
(defconstant +green+ #x00FF00)
(defconstant +blue+  #x0000FF)

(defun gfx-start ()
  (if (zerop (sb-sys:sap-int screen))
      (or (zerop (sdl-start +width+ +height+ +depth+))
	  (error (gfx-error)))
      (error "Graphics are already initialized")))

(defun gfx-stop () 
  (if (zerop (sb-sys:sap-int screen))
      (error "Graphics are not initialized.") 
      (sdl-stop)))

(defun dot (color x y)
  (setf x (min (max x 0) +width+) y (min (max y 0) +height+))
  (let ((offset (ash (+ (* y +width+) x) 2)))
    (setf (sb-sys:sap-ref-32 (gfx-raw) offset) color)))

(defconstant +wide+ (/ +width+ 8))
(defconstant +tall+ (/ +height+ 8))

(defun put (color x y)
  "Puts an 8x8 pixels on the screen."
  (setf x (* x 8) y (* y 8) color (truncate color))
  (gfx-lock)
  (dotimes (dx 8) (dotimes (dy 8) (dot color (+ x dx) (+ y dy))))
  (gfx-unlock)
  (gfx-show))


(gfx-start)
(push #'gfx-stop sb-ext:*exit-hooks*)

The basic idea is to keep the code simple enough so that the library is a part of the learners world -- nothing up our sleeves. Simple libraries can be changed, and in my book that beats configurability.

Sat Jan 22 -- I've written a blog post on this.

Warren Wilkinson wrote:

You're not teaching trigonometry, but basic geometry. You're still working from coordinates, just abstract ones. fd 1 (forward one, in a hypothetical dialect) could be one pixel (it was in Apple Logo) but it could also be an arbitrary distance, with 1.235 as a possibility, as well.

Advocating direct pixel manipulation seems... archaic, and non-portable to higher/lower resolutions.
SVG is much more flexible than (insert bitmapped format).
NeWS was much more flexible than X.

Artists don't draw on graphing paper, yo.

I like this topic =). Grid drawing is called pixel art: http://www.pixeljoint.com/pixels/new_ic ... ?ob=rating, I did it all the time to make sprites. Flexibility of the output isn't important here, simplicity of ideas is (she'll ask "How can I make it red?" long before she'll ask "How can I make it 1024x768 triple buffered with 32 bits, an alpha channel and a Z buffer?" -- hyperbole I know)

Direct pixel manipulation is the simplist, most primitive and most portable way of doing graphics. All other interfaces are just predefined pixel plotting routines. Algebra is the arithmatic as vectors are to pixels. My suggestion is to start at the logical beginning (pixels) and grow upwards to turtles (or gradients, or boxes, or triangles, or sprites, or text or whatever your kid is interested in).

What good is turtles when you want gradients? I'd bet she'd prefer making gradient rainbows to manipulating a turtle. Pixel plotting can, with equal ease, do both.

I'm recommending a more high-level programming technique.
I find it interesting that one would recommend low-level, direct bit manipulation in a language like Lisp, which is so high-level, and abstracts away things like memory management.

Then again, I'm the guy who's hoping to re-implement a NeWS-alike with native PostScript 3D graphics in the next few years.
While bitmaps will be available, and bitmapping of objects will obviously be a priority, resolution-independence across the board is of higher importance.

I'm all for simplicity, and I'll take it in whatever form it comes in, low level or high.

Resolution independence shouldn't be that hard: turn +width+ and +height+ to *width* and *height*, set them to your resolution and rerun the program. That is how postscript does it, it's just a variant of Forth.

A high level approach might incorrectly teach her that computers are the abstractions they implement. Instead, teach the real comp-sci stuff, because in this case its just as easy (or easier) than turtle graphics (which is a dead-end API) -- why not go with the facts?

Warren Wilkinson wrote:I'm all for simplicity, and I'll take it in whatever form it comes in, low level or high.

Resolution independence shouldn't be that hard: turn +width+ and +height+ to *width* and *height*, set them to your resolution and rerun the program. That is how postscript does it, it's just a variant of Forth.

A high level approach might incorrectly teach her that computers are the abstractions they implement. Instead, teach the real comp-sci stuff, because in this case its just as easy (or easier) than turtle graphics (which is a dead-end API) -- why not go with the facts?

Ah, I see.

When you mentioned BASIC in a positive light, I misunderstood your intentions.
I think having both direct pixel manipulation and higher-level geometric stuff available is a good idea. Options.

Heck, PS can display bitmap images, too.

Hello.

I know: this is the Common Lisp section -- but:
I tried a turtle interface via Clojure. And it worked very well, without large programming work.

Here is a small code example:


(import '(ch.aplu.turtle Turtle))

(def t1 (new Turtle))

(defn mt []
(dotimes [_ 50]
(.left t1 110)
(.forward t1 100)))


This produces a small star in the turtle window.

You can get the necessary Java Lib from:
http://www.aplu.ch/home/apluhomex.jsp

Kind Greetings

cl-cairo2(github) would be good for it especially if we also could easily have keyboard/mouse/etc input in conjunction with it, and it has much more drawing ability. Neat to be able to export to many things, svg, ps, pdf, png, X11 window. Maybe i'll see if i can add a function to give sdl an cairo surface. Note: if it becomes slow, you need to may need to lock it. cl-cairo2:sync-lock, and use sync-reset and then locking again to draw. (I don't understand why that continuously costs cpu if unlocked, afaiks no way to change what is already drawn looking at the api.)