[Edu-sig] CTL: Computer Thinking Language

Edward Cherlin echerlin at gmail.com
Tue Mar 3 17:26:04 CET 2009


Comments below. We can provide the authors with a great deal more
information on request.

On Sun, Mar 1, 2009 at 1:02 PM, David MacQuigg <macquigg at ece.arizona.edu> wrote:
> There is an interesting article in the latest ACM {Human Computing Skills: Rethinking the K-12 Experience, Fletcher & Lu, Communications of the ACM, Feb.09, p.23}.
>
> The authors make a strong case for re-vamping our curricula:
> despite our best efforts to articulate that CS is more than just programming ...
> computational thinking (CT) as a skill on a par with reading, writing and arithmetic ... places the core of CS, we believe correctly, in the category of basic knowledge.

CS, including incompleteness and undecidability results, is
fundamental to epistemology, which is fundamental to child
development, as Piaget showed in considerable detail. (What is true?
How do you know? When do you need to suspend judgment?) For example,
"proof" and "theorem" can be syntactically defined in either logic or
CS, but "truth" does not have a mathematical definition. The
definition of proof leads to the creation of sentences that can be
neither proved nor disproved. A definition of "truth" would, by
exactly the same mechanism, allow us to create sentences of arithmetic
that are neither true nor false.

> proficiency in computational thinking helps us systematically and efficiently process information and tasks.
> lay the foundations of CT long before students experience their first programming language.
> Programming is to CS what proof construction is to mathematics, and what literary analysis is to English.

I don't see it that way. Programming:CS::calculation:math, perhaps,
but the analogy is necessarily imperfect.

> Then they move to more more controversial statements:
> Knowledge of programming should not be necessary to proclaim literacy in basic computer science.

True if programming is defined by conventional languages written in a
text editor.

> Substantial preparation in computational

algorithmic and constraint-based

> thinking is required before students enroll in programming courses.

It hasn't been, but should be. We have accepted the ability to
calculate and solve equations as a substitute for the higher-level
concepts required.

> and a specific proposal:
> a computational thinking language (CTL) that captures core CT concepts must permeate the pedagogy.
> not a programming language, but rather vocabularies and symbols that can be used to annotate and describe computation, abstraction, and information and provide notation around which semantic understanding of computational processes can be hung.

I am doing precisely that with the Sugar version of TurtleArt, which
provides tiles that hook together to create programs. The schoolchild
learning TurtleArt is not bothered with syntax in any form. Tiles are
keyed to render type mismatches impossible. The resulting program is
in tree form, like the output of a compiler parser. Outputting various
languages brings in the various tree-walk orders and issues of
generative grammars. We are creating several sets of tiles to
illustrate different CS concepts, and planning a primary school CS
course with interactive digital textbooks.

I can do all of Euclidean plane geometry, plane analytic geometry, and
a toy Turing machine (finite tape, finite set of state symbols) in
Turtle Art. We can create tiles for almost any model of programming
and computer structure, including prefix (LISP, SCHEME, LOGO), infix
(most languages), and suffix (FORTH, RPN calculator) expressions;
procedural vs functional vs object-oriented message passing; a wide
range of control structures; and much more.

> They give as an example, a description of Euclid's algorithm for finding the greatest common divisor.  They suggest a syntax, which I transcribe here using <lamba> as the Greek lower-case lambda:
> <lambda> a,b. if a<b,(a, b-a); else (a-b, b)
> At this point, they really lost me.  Why would anyone go to this much effort to avoid programming language.  Python's equivalent statement is just as simple (although a bit odd in its ordering):

> lambda a,b: (a, b-a) if (a<b) else (a-b, b)

You left out the termination case in both forms. If one of the
arguments is zero, return the other. In any case, lambda notation is
completely inappropriate as a first CS language.

> Have these guys never heard of Python?

gcd =. if <.(a,b)>0 then gcd/(>./(a,b)-<./(a,b), <./(a,b)) else >./(a,b)

in J-like syntax, where <. is min, and >. is max, and / turns prefix
expressions into infix.

> I think the problem may be a need to avoid favoring one language over another.  Any time you make a proposal to use a specific language, you get immediate opposition from folks who favor another language.  In my department (Java & C++), and at our community college (Java, BASIC, Alice), I seem to have been labeled as the "Python guy", pushing "yet another language", or even worse, the guy who wants to get rid of type declarations.  Python is seen as a "scripting language", something equivalent to csh or bash.  To avoid being pigeonholed, I now just say "we need a more agile language".

TurtleArt is written in Python. That means that at some point we can
teach children to write their own tile definitions.

> I can see the need for a CTL, and I wouldn't object to it being something other than Python, and I'm all in favor of being "fair" to the other languages.  The one requirement I would insist on is that the language "compute", i.e. no ambiguity as to a result (no psuedocode).

This is yet another reason not to use text pseudocode, and not to
create Yet Another Text Programming Language.

> It would also be nice if CTL could be automatically translated to a real computer language, so there is a smooth transition when students are ready for the real thing.  Students could test their CTL by popping it into the translator, running it in a real interpreter, and getting immediate feedback.

TurtleArt currently outputs to its own format, which saves the page
geometry as well as the program

http://docs.python.org/library/json.html

and to Logo. Writing a Python method to output any other reasonable
form of code (NOT Intercal, Befunge, or Unlambda, or a Turing machine
state table) would be easy. There is also a different implementation
of Turtle Art, Kturtle, which has its own built-in editor.

> CTL should certainly include simple functions like min(), max(), sum(), and sqrt().  It could also include functions like range(a,b), introducing the idea that functions can return something besides numbers.  At this point there may be some controversy over how to treat the endpoints, but that could be worked out in compromise between the different languages.
>
> Moving on to week three of the lesson plan, we could introduce the idea of defining our own functions, adding new concepts one at a time.
>
> f(a,b): (a+b)/2           # a simple function
> f(a,b): (a+b)/(2*pi)           # with an "outside" variable
> f(a,b): if a<b,(a, b-a); else (a-b, b)   # adding some conditional logic
> f(a,b): a2 = a**2; b2 = b**2; return (a2 + b2)/2  # temporary variables and a statement sequence

All of this is supported in recent versions of TurtleArt, where the
code for a tile can call any Python function.

> #  control flow with multiple statements
> f(a,b): if a<(b-5), return a; if (b-5)<=a<=(b+5), return (a+b)/2; return b
>
> #  recursion
> f(a,b): if a<b, f(a, b-a); elif b<a, f(a-b, b); else (a,b)

We have some fractal graphics demos in the library that accompanies TurtleArt.

> This is a bit Pythonic, but only because I'm more familiar with Python than Ruby or Lua, or some other language that might like to contribute some gems.  We could even invite Java, if she will come down to this level.  :>)
>
> What else do we need in CTL?  Would anyone like to join me in defining this new "language"?  I'll write the translator to Python.

You're on.

http://sugarlabs.org/go/Activities/TurtleArt


> -- Dave
> ************************************************************     *
> * David MacQuigg, PhD    email: macquigg at ece.arizona.edu   *  *
> * Research Associate                phone: USA 520-721-4583   *  *  *
> * ECE Department, University of Arizona                       *  *  *
> *                                 9320 East Mikelyn Lane       * * *
> * http://purl.net/macquigg        Tucson, Arizona 85710          *
> ************************************************************     *
>
>
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>



-- 
Silent Thunder (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) is my name
And Children are my nation.
The Cosmos is my dwelling place, The Truth my destination.
http://earthtreasury.net/ (Ed Cherlin)


More information about the Edu-sig mailing list