Re: [IAEP] Turtles All The Way Down
On Fri, May 20, 2011 at 11:09 AM, Alan Kay alan.n...@yahoo.com wrote:
Smalltalk actually got started by thinking about a way to make a child's
Logo-like language with objects and pattern matching that could express its
own operating system and environment.
It is very tricky to retain/maintain readability (so the first Smalltalk was
also an extensible language not just semantically but syntactically).
With a tile language, this is really worth thinking about, since using tiles
suggests ways to extend both the form and the meaning of the tiles.
I've written a follow-up post, musing on the readability aspect Alan
mentioned above:
http://cananian.livejournal.com/64330.html
Is it worth trading a very simple and direct syntax like:
var Point = {};
Point.x = 0;
Point.y = 0;
var Point3D = Object.create(Point);
Point3D.z = 0;
for the more readable:
Class(Point, {
has: {
x: {is: ro},
y: {is: rw},
},
})
Class(Point.ThreeD, {
isa: Point,
has: {
z: {}
},
})
at the cost of introducing additional complexity into the object
creation process. The complexity is in a library, so the base
language is kept small -- but it's still more turtles thrown onto the
stack that you have to understand.
Returning to Alan's point about tiles -- the nice thing is that you
could define a custom tile for the Class() syntax above, with
pretty selectors to help you select parent class, slot attributes,
etc. But perhaps it's better just to keep the conceptual model small
-- then you don't need fancy GUI widgets to help you out.
For a more concrete example, you might want to read through:
https://github.com/cscott/TurtleScript/blob/beeba5c138d88af40297f93689ecbe7721724819/crender.js#L333
starting at line 333 or so. That's a widget library written in
Simplified JavaScript/TurtleScript which uses prototype inheritance
extensively. You can do clever things like swipe the implementation
of a function from a totally different class; see how we do multiple
inheritance around line 661. Is the Joose syntax an improvement?
--scott
--
( http://cscott.net )
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [IAEP] Turtles All The Way Down
No. OOP is overhyped anyway... It only helps for namespacing, and
primitive values where encapsulation works. Since children will not make
reusable libraries mostly I think there is no point making things more
complex as they already are. BTW I did not find the second version more
readable but it can be only me.
On 2011.05.24. 19:11, C. Scott Ananian wrote:
On Fri, May 20, 2011 at 11:09 AM, Alan Kayalan.n...@yahoo.com wrote:
Smalltalk actually got started by thinking about a way to make a child's
Logo-like language with objects and pattern matching that could express its
own operating system and environment.
It is very tricky to retain/maintain readability (so the first Smalltalk was
also an extensible language not just semantically but syntactically).
With a tile language, this is really worth thinking about, since using tiles
suggests ways to extend both the form and the meaning of the tiles.
I've written a follow-up post, musing on the readability aspect Alan
mentioned above:
http://cananian.livejournal.com/64330.html
Is it worth trading a very simple and direct syntax like:
var Point = {};
Point.x = 0;
Point.y = 0;
var Point3D = Object.create(Point);
Point3D.z = 0;
for the more readable:
Class(Point, {
has: {
x: {is: ro},
y: {is: rw},
},
})
Class(Point.ThreeD, {
isa: Point,
has: {
z: {}
},
})
at the cost of introducing additional complexity into the object
creation process. The complexity is in a library, so the base
language is kept small -- but it's still more turtles thrown onto the
stack that you have to understand.
Returning to Alan's point about tiles -- the nice thing is that you
could define a custom tile for the Class() syntax above, with
pretty selectors to help you select parent class, slot attributes,
etc. But perhaps it's better just to keep the conceptual model small
-- then you don't need fancy GUI widgets to help you out.
For a more concrete example, you might want to read through:
https://github.com/cscott/TurtleScript/blob/beeba5c138d88af40297f93689ecbe7721724819/crender.js#L333
starting at line 333 or so. That's a widget library written in
Simplified JavaScript/TurtleScript which uses prototype inheritance
extensively. You can do clever things like swipe the implementation
of a function from a totally different class; see how we do multiple
inheritance around line 661. Is the Joose syntax an improvement?
--scott
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [IAEP] Turtles All The Way Down
On Sun, May 22, 2011 11:09 am, Hilaire Fernandes wrote: Le 21/05/2011 03:17, moku...@earthtreasury.org a écrit : Seymour Papert also proposed creating an environment in which learning math would be as easy as learning ordinary language. Smalltalk has a number of kinds of number and shape objects, but I have not seen much else in the way of mathematical objects. I am trying to go through various subjects to extract the ideas that preschoolers can absorb, and create materials to encourage them to explore those ideas. We also need symmetries (group theory and algebra more generally), Venn diagrams (Boolean algebra and set theory), rubber-sheet geometry (topology), probability, knot theory (topology), infinities and infinitesimals, graphing (analytic geometry), and conic sections, among other topics easy to visualize and make tactile. (It is trivial to generate the conic sections using a flashlight in a darkened room.) DrGeo provides those extensions to Smalltalk for the Euclidean geometry field. This opens large use case in teaching programming related to history of math, largely based on Euclidean geometry. It works also for non-Euclidean and projective geometry using well-known models. History of math needs to be mined for its moments of adventure, discovery, and controversy. It is widely assumed that math is perfect and unchangeable in its nature. For example, that a theorem once proved stays proved forever. This turns out not to be the case. Lambert thinking he had disproved non-Euclidean geometry, and Peano thinking he had proved that all models of the natural numbers are isomorphic are historically the two most important instances that I know of. Gauss, Lobachevsky, Bolyai, and Riemann realized that Lambert was wrong, and Beltrami finished off the case by demonstrating a surface in Euclidean space with Lobachkevskian geometry. Abraham Robinson ran with non-standard arithmetic, creating non-standard analysis as an easier way to do calculus, and disposing of Bishop Berkeley's ghosts of departed quantities. http://www.reunion.iufm.fr/recherche/irem/spip.php?article493 http://fr.wikibooks.org/wiki/Programmation_objet_et_g%C3%A9om%C3%A9trie http://revue.sesamath.net/spip.php?article330 Sorry those references are only in French, a lot of teachers exploring programming for math seems to come from that place. Pas de difficulté pour moi. Merci. Hilaire -- Education 0.2 -- http://blog.ofset.org/hilaire ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep -- Edward Mokurai (#40664;#38647;/#2343;#2352;#2381;#2350;#2350;#2375;#2328;#2358;#2348;#2381;#2342;#2327;#2352;#2381;#2332;/#1583;#1726;#1585;#1605;#1605;#1740;#1711;#1726;#1588;#1576;#1583;#1711;#1585; #1580;) Cherlin Silent Thunder is my name, and Children are my nation. The Cosmos is my dwelling place, the Truth my destination. http://wiki.sugarlabs.org/go/Replacing_Textbooks ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Turtles All The Way Down
C. Scott Ananian wrote on Sat, 21 May 2011 19:22:01 -0400 I'm familiar with the processors designed for specific high-level languages. There was another generation of them built for Java (microblaze, picoblaze, etc) and some of those are even still commercially significant (they run Java subsets on smart cards). You were probably thinking of PicoJava, the very first processor for which Sun made the sources available (Microblaze and Picoblaze are 32 and 8 bit processors from Xilinx). I would recommend that anyone interested in this take a look at the Java Oriented Processor: http://www.jopdesign.com/ I keep a list of Smalltalk computers (some with commercial processors, others with language specific CPUs): http://www.merlintec.com:8080/hardware/26 I'm not terribly interested in those processors. Fair enough, but not only am I extremely interested in them, I also feel they can be a suitable learning object. I imagine many here are a bit tired of hearing about my SiliconSqueak project, but it is important to point out that it is organized as a sequence of layers: 1) Tiled entry level language: Etoys, Scratch but could also be Turtlescript 2) System language: Smalltalk, but could also be Python or Lua 3) Bytecodes 4) Microcode, but could also be assembly for ARM or Chuck Thacker's TinyComputer designs 5) Cache level (this is a unique SiliconSqueak thing) 6) logic circuits I think it is reasonable to introduce all children to 1, but for any given level I expect only a tiny fraction to move on to the next level. This is just natural so out of millions of people only two or three might be interested in level 5. Even so, I am willing make as much effort as I can to create a nice learning experience for those three. Level 6 breaks the pattern since it can used for many different interesting projects beyond SiliconSqueak, so many people might be interested in it. I would like to point out the workshops Etienne Delacroix created in Brazil and Uruguay in the past decade as a good example of what can be achieved in this regard. More in tune with the turles all the way down agenda is the work done on compiling high level languages to hardware. It's not that the hardware chipset runs turtlescript (that's not really giving you any additional insight into the operation of the hardware), but that the hardware is *described* in turtlescript. I've made some modest contributions to this in the distant past (http://flex.cscott.net/SiliconC/paper.pdf). Nice dream, and I say this as someone who is part of a group of research groups dedicated to making the dream of programming hardware in C come true. The paper doesn't have a data, but from the references I would guess 1996 or 1997. So it doesn't mention System C, Handel-C (killed off, unfortunately) or BlueSpec. Personally, I would select something like Matlab (Octave) as a source language for hardware instead of C. By a strange coincidence, a top researcher in this field was trying to get me intereted on working on the problem of compiling recursive functions to hardware. My own PhD project, Adaptive Compilation for a Reconfigurable, Parallel, Object-Oriented Architecture, is not entirely unrelated to this. That said, there is *zero* chance that this work will result in hardware suitable for the kids we care about. So let's stop talking about it. This is exactly what I hope will be the result. But I agree this is not the right place to talk about it. I once used a tile-based UI in a commercial database program. It was horrible once we got past the toy examples. [...] Of course. I would say that perhaps 40 or 50 blocks is a reasonable limit. After that, you should be writing subroutines to go in Python blocks, and not very long after transition to pure Python. Let's find out. I've written almost 4,000 lines of code in my tile based language so far. So far I've been typing it. I hope to leave the keyboard behind soon. And then we'll see whether I agree with you or not. One problem is that graphical representations are very rich, but not very dense. So factoring stuff better can help a lot (see any code by Chuck Moore). Another solution is to go beyond 2 dimensions - a program is really something that evolves in time and you could make its representation reflect that. I hope to use animation to unify: 1) using the computer with pop up menus and dialog boxes, 2) writing scripts, 3) debugging. Textual representations are really bad at references, unfortunately, beyond a small set of literals, the arguments and some globals. In Etoys I can use any object's halo to ask for a tile representing it and then use this tile in some expression. In Self I could set the value of a local variable by dragging an arrow to point to anything I wanted. My goal is to bring levels 1 and 2 (of my list above) together so the transition won't even be noticed. -- Jecel ___ Devel mailing list
Re: [IAEP] Turtles All The Way Down
On Fri, May 20, 2011 2:28 pm, C. Scott Ananian wrote:
On Fri, May 20, 2011 at 11:09 AM, Alan Kay alan.n...@yahoo.com wrote:
This is nice!
Smalltalk actually got started by thinking about a way to make a child's
Logo-like language with objects and pattern matching that could express
its own operating system and environment.
Seymour Papert also proposed creating an environment in which learning
math would be as easy as learning ordinary language. Smalltalk has a
number of kinds of number and shape objects, but I have not seen much else
in the way of mathematical objects. I am trying to go through various
subjects to extract the ideas that preschoolers can absorb, and create
materials to encourage them to explore those ideas.
Caleb Gattegno and Ken Iverson did a fair amount on algebra, using
Cuisenaire rods and APL respectively.
Don Cohen has done Calculus by and for Young People
I have made a start on symmetry groups, using variations on children's
block toys.
Elementary set theory using Venn diagrams was done long ago.
But there is so much more.
It is very tricky to retain/maintain readability (so the first Smalltalk
was
also an extensible language not just semantically but syntactically).
With a tile language, this is really worth thinking about, since using
tiles
suggests ways to extend both the form and the meaning of the tiles.
My current thinking is that macros are *graphical*, not *source*
transformations. You can create
your own tiles for the language which render into hygenic macros.
They are represented in source as simple message dispatch. For
example, choosing a particularly ugly bit of JavaScript syntax:
I would like to be able to create a set of blocks implementing the
symmetry group of a simple shape such as an equilateral triangle. This
case is generated by a 120 degree rotation and a reflection, giving six
elements in all.
Similarly I would like to be able to do modular addition, subtraction,
multiplication, and division in finite fields, and the and and or
functions or union and intersection on lattices.
Does your system accommodate this?
var ForBlockMacro = imports.macros.ForBlockMacro;
var foo = function() {
var i;
ForBlockMacro(function() { i=0; },
function() { return i 5; },
function() { i+=1; },
function() { /* body */ });
}
This is the underlying syntax for the macro. But the ForBlockMacro
function (which is a first class object in JavaScript) can have an
asTile() method which returns a more attractive visual representation
in the tile editor; in fact, the representation could elide all the
'function' and 'return' nastiness of the raw syntax and display
(traditionally) as:
for ( i=0 ; i 5 ; i+=1 ) {
/* body */
}
My current plan is to finess the multiple views issue (discussed in
3.4 of http://labs.oracle.com/self/papers/programming-as-experience.html)
by representing objects as 3d polyhedra. The front view might be
the nice cleaned up tile macro, but you should be able to rotate the
tile to see the low level source, and then rotate it again to see the
object corresponding to the actual widget displaying the source, etc.
So, one object, many views.
I've built the current system on a very flexible operator precedence
grammar, so there's no reason I *couldn't* allow the user to flexibly
extend the base grammar. But that increases the conceptual effort
necessary to understand the system -- I have to understand the
expanded language before I can understand the code I'm looking at.
The macro system I describe above has the nice property that you don't
*have* to understand the macro or the grammar of the new if statement.
It's enough to look at the desugared version:
ForBlockMacro(function() { i=0; },
function() { return i 5; },
function() { i+=1; },
function() { /* body */ });
and the implementation of ForBlockMacro:
ForBlockMacro = function(initBlock, condBlock, incrBlock, bodyBlock) {
initBlock();
while (condBlock()) {
bodyBlock();
incrBlock();
}
};
ForBlockMacro.asTile() = ;
This seems (to me) a preferable way of understanding what the new tile
does. But I'm open to other ideas on this front. (And yes,
JavaScript's syntax isn't lovely. But I'm interested in what I can do
with what I've got.)
--scott
--
   ( http://cscott.net )
___
IAEP -- It's An Education Project (not a laptop project!)
i...@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep
--
Edward Mokurai
(#40664;#38647;/#2343;#2352;#2381;#2350;#2350;#2375;#2328;#2358;#2348;#2381;#2342;#2327;#2352;#2381;#2332;/#1583;#1726;#1585;#1605;#1605;#1740;#1711;#1726;#1588;#1576;#1583;#1711;#1585;
#1580;) Cherlin
Silent Thunder is my name, and Children are my nation.
The Cosmos
Re: [IAEP] Turtles All The Way Down
On Fri, May 20, 2011 9:32 pm, Gonzalo Odiard wrote: The question is: does this really have educational value? Turtles all the way down is a great slogan, and a fine way to teach a graduate-level class on compiler technology, See * The Anatomy of LISP, by John Allen, and LISP machines, for LISP all the way down to the hardware. * http://domino.watson.ibm.com/tchjr/journalindex.nsf/600cc5649e2871db852568150060213c/641aa395fee3dd2c85256bfa006859fc!OpenDocument A Formal Description of System\360, by Adin Falkoff in the original pre-APL Iverson Notation, and Digital Systems: Hardware Organization and Design, by Frederick J. Hill Gerald R. Peterson for APL all the way down, also to the hardware. Specifically AHPL, A Hardware Programming Language. * SOAR (Smalltalk on a RISC) at UC Berkeley for Smalltalk all the way down to the hardware. * FORTH microprocessors such as Forth Multiprocessor Chip MuP21 http://www.ultratechnology.com/p21.html I would be interested to know of any other examples of hardware implementation of a programming language. (Not the Algol-optimized and COBOL-optimized Burroughs machines; real hardware implementations.) but I feel that the higher-level UI for tile-based program editing is the really useful thing for tablet computing. I'm a compiler geek and love the grungy underbelly of this stuff, but I keep reminding myself I should really be spending more time building a beautiful fluffy surface. I once used a tile-based UI in a commercial database program. It was horrible once we got past the toy examples. You are doing the right question I remember here No silver bullet [1] Different languages, different levels of abstraction, need different interfaces, and text is powerfull interface. May be is not the best interface to start to program, but surely graphic block are not the best interface to do programs of more than 400 of blocks. Of course. I would say that perhaps 40 or 50 blocks is a reasonable limit. After that, you should be writing subroutines to go in Python blocks, and not very long after transition to pure Python. Gonzalo [1] http://en.wikipedia.org/wiki/No_Silver_Bullet On Fri, May 20, 2011 at 10:30 AM, C. Scott Ananian csc...@laptop.orgwrote: I've done a little more work on Turtles All The Way Down, which I (very briefly) discussed at EduJam. I actually wrote a garbage collector in TurtleScript for TurtleScript on Sunday. Brief writeup here: http://cananian.livejournal.com/64140.html and exhaustive mind-numbing detail here: http://cscott.net/Projects/TurtleScript/ No actual turtles yet! I'm going to have to fix that soon. --scott -- ( http://cscott.net ) ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Edward Mokurai (#40664;#38647;/#2343;#2352;#2381;#2350;#2350;#2375;#2328;#2358;#2348;#2381;#2342;#2327;#2352;#2381;#2332;/#1583;#1726;#1585;#1605;#1605;#1740;#1711;#1726;#1588;#1576;#1583;#1711;#1585; #1580;) Cherlin Silent Thunder is my name, and Children are my nation. The Cosmos is my dwelling place, the Truth my destination. http://wiki.sugarlabs.org/go/Replacing_Textbooks ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Turtles All The Way Down
I'm familiar with the processors designed for specific high-level languages. There was another generation of them built for Java (microblaze, picoblaze, etc) and some of those are even still commercially significant (they run Java subsets on smart cards). I'm not terribly interested in those processors. More in tune with the turles all the way down agenda is the work done on compiling high level languages to hardware. It's not that the hardware chipset runs turtlescript (that's not really giving you any additional insight into the operation of the hardware), but that the hardware is *described* in turtlescript. I've made some modest contributions to this in the distant past (http://flex.cscott.net/SiliconC/paper.pdf). That said, there is *zero* chance that this work will result in hardware suitable for the kids we care about. So let's stop talking about it. I once used a tile-based UI in a commercial database program. It was horrible once we got past the toy examples. [...] Of course. I would say that perhaps 40 or 50 blocks is a reasonable limit. After that, you should be writing subroutines to go in Python blocks, and not very long after transition to pure Python. Let's find out. I've written almost 4,000 lines of code in my tile based language so far. So far I've been typing it. I hope to leave the keyboard behind soon. And then we'll see whether I agree with you or not. --scott -- ( http://cscott.net ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Turtles All The Way Down
This is quite interesting. Recently, I finished my dissertation on mobile development directly from mobile devices. Something like this might've been very useful, although I did target experienced developers, not beginners. Do you plan to make it self-hosted? I guess that wouldn't be possible without removing the interpreter. On 20 May 2011 14:30, C. Scott Ananian csc...@laptop.org wrote: I've done a little more work on Turtles All The Way Down, which I (very briefly) discussed at EduJam. I actually wrote a garbage collector in TurtleScript for TurtleScript on Sunday. Brief writeup here: http://cananian.livejournal.com/64140.html and exhaustive mind-numbing detail here: http://cscott.net/Projects/TurtleScript/ No actual turtles yet! I'm going to have to fix that soon. --scott -- ( http://cscott.net ) ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Turtles All The Way Down
This is nice! Smalltalk actually got started by thinking about a way to make a child's Logo-like language with objects and pattern matching that could express its own operating system and environment. It is very tricky to retain/maintain readability (so the first Smalltalk was also an extensible language not just semantically but syntactically). With a tile language, this is really worth thinking about, since using tiles suggests ways to extend both the form and the meaning of the tiles. Cheers, Alan From: C. Scott Ananian csc...@laptop.org To: IAEP SugarLabs i...@lists.sugarlabs.org; OLPC Devel devel@lists.laptop.org Sent: Fri, May 20, 2011 6:30:08 AM Subject: [IAEP] Turtles All The Way Down I've done a little more work on Turtles All The Way Down, which I (very briefly) discussed at EduJam. I actually wrote a garbage collector in TurtleScript for TurtleScript on Sunday. Brief writeup here: http://cananian.livejournal.com/64140.html and exhaustive mind-numbing detail here: http://cscott.net/Projects/TurtleScript/ No actual turtles yet! I'm going to have to fix that soon. --scott -- ( http://cscott.net ) ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Turtles All The Way Down
On Fri, May 20, 2011 at 11:09 AM, Alan Kay alan.n...@yahoo.com wrote:
This is nice!
Smalltalk actually got started by thinking about a way to make a child's
Logo-like language with objects and pattern matching that could express its
own operating system and environment.
It is very tricky to retain/maintain readability (so the first Smalltalk was
also an extensible language not just semantically but syntactically).
With a tile language, this is really worth thinking about, since using tiles
suggests ways to extend both the form and the meaning of the tiles.
My current thinking is that macros are *graphical*, not *source*
transformations. You can create
your own tiles for the language which render into hygenic macros.
They are represented in source as simple message dispatch. For
example, choosing a particularly ugly bit of JavaScript syntax:
var ForBlockMacro = imports.macros.ForBlockMacro;
var foo = function() {
var i;
ForBlockMacro(function() { i=0; },
function() { return i 5; },
function() { i+=1; },
function() { /* body */ });
}
This is the underlying syntax for the macro. But the ForBlockMacro
function (which is a first class object in JavaScript) can have an
asTile() method which returns a more attractive visual representation
in the tile editor; in fact, the representation could elide all the
'function' and 'return' nastiness of the raw syntax and display
(traditionally) as:
for ( i=0 ; i 5 ; i+=1 ) {
/* body */
}
My current plan is to finess the multiple views issue (discussed in
3.4 of http://labs.oracle.com/self/papers/programming-as-experience.html)
by representing objects as 3d polyhedra. The front view might be
the nice cleaned up tile macro, but you should be able to rotate the
tile to see the low level source, and then rotate it again to see the
object corresponding to the actual widget displaying the source, etc.
So, one object, many views.
I've built the current system on a very flexible operator precedence
grammar, so there's no reason I *couldn't* allow the user to flexibly
extend the base grammar. But that increases the conceptual effort
necessary to understand the system -- I have to understand the
expanded language before I can understand the code I'm looking at.
The macro system I describe above has the nice property that you don't
*have* to understand the macro or the grammar of the new if statement.
It's enough to look at the desugared version:
ForBlockMacro(function() { i=0; },
function() { return i 5; },
function() { i+=1; },
function() { /* body */ });
and the implementation of ForBlockMacro:
ForBlockMacro = function(initBlock, condBlock, incrBlock, bodyBlock) {
initBlock();
while (condBlock()) {
bodyBlock();
incrBlock();
}
};
ForBlockMacro.asTile() = ;
This seems (to me) a preferable way of understanding what the new tile
does. But I'm open to other ideas on this front. (And yes,
JavaScript's syntax isn't lovely. But I'm interested in what I can do
with what I've got.)
--scott
--
( http://cscott.net )
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [IAEP] Turtles All The Way Down
The question is: does this really have educational value? Turtles all the way down is a great slogan, and a fine way to teach a graduate-level class on compiler technology, but I feel that the higher-level UI for tile-based program editing is the really useful thing for tablet computing. I'm a compiler geek and love the grungy underbelly of this stuff, but I keep reminding myself I should really be spending more time building a beautiful fluffy surface. You are doing the right question I remember here No silver bullet [1] Different languages, different levels of abstraction, need different interfaces, and text is powerfull interface. May be is not the best interface to start to program, but surely graphic block are not the best interface to do programs of more than 400 of blocks. Gonzalo [1] http://en.wikipedia.org/wiki/No_Silver_Bullet On Fri, May 20, 2011 at 10:30 AM, C. Scott Ananian csc...@laptop.orgwrote: I've done a little more work on Turtles All The Way Down, which I (very briefly) discussed at EduJam. I actually wrote a garbage collector in TurtleScript for TurtleScript on Sunday. Brief writeup here: http://cananian.livejournal.com/64140.html and exhaustive mind-numbing detail here: http://cscott.net/Projects/TurtleScript/ No actual turtles yet! I'm going to have to fix that soon. --scott -- ( http://cscott.net ) ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
