TurtleJS is turtle graphics for learning coding in a humanities context, implemented in Javascript with p5.js, being developed (and very much in progress) by Scott Richmond at the University of Toronto.
What follows now is a part of a draft of a statement of purpose; speculative reasoning about the practical matters of TurtleJS and how it works pedagogically are in TODO. More practical documents are forthcoming.
Once upon a time, a few decades ago, LOGO and its famous "turtle graphics" was the way kids (old and young) learned how to program computers. Generations of kids learned to make a square by typing REPEAT 4 [ FORWARD 100 RIGHT 90 ]. (I did this myself once or twice, but already in the early 1990s, we were engaged in dumbing down learning with computers. What I really remember is Oregon Trail.) LOGO was and remains hugely influential in how we teach computer programming, from the use of Lisps in teaching coding (e.g. Scheme and Racket) to the make-pretty-pictures-fast ethic of Processing to the "easy" and "friendly" graphical interface of Scratch.
The idea behind TurtleJS is both that LOGO got a great many things right in the practice of teaching coding and that it has an interesting and important place in the history of ideas. Which is to say, the intuition behind TurtleJS is that humanities students will learn better both how to code and what coding might mean by engaging fully with turtle graphics. By this I mean: learning how to move a turtle around and reading the history of LOGO and its related pedagogical philosophies, both at the same time. The idea is that students will not only type FORWARD 100 RIGHT 90 (or, rather, forward(100).right(90)) but also will read (parts of) Seymour Papert's Mindstorms, bits from Piaget, and other primary source material, alongside contemporary thinking about digital media. The goal of TurtleJS is to facilitate both teaching coding as a practical skill, and also to be an important component in a humanities coding curriculum whose primary goal is a deep understanding of the important and interesting history of ideas around computing.
At the same time, TurtleJS isn't just LOGO, or, for that matter, just turtle graphics. You can find both actual LOGO interpreters and deeply robust turtle graphics elsewhere. What TurtleJS does is adapt (rather freely at times) the ethos and methods of LOGO and its turtle graphics to contemporary JS. It does this a few ways:
Javascript has a bad rap as a learning language. Academics these days love to teach with Python and its one-way-to-do-one-thing, or with the favored Lisps (Scheme or Racket). Or kids get friendly graphical interfaces (Scratch and its offshoot, Tickle). By contrast, there are always sixteen ways to do any one thing in JS. It is the unholy hybrid offspring of object-oriented and functional languages, doing neither well (or rather, doing neither the way we might expect). It's boring and textual for all that (despite Bret Victor's dreams and Scratch's brightly marketable colors). (Actually, I think it's an important bit of pedagogy to force students to write code, although I would also kill for Victor's dream IDE.) The story goes that the only reason a pedagogue could love JS is because it is a language of convenience, running on nearly literally every computing device everywhere. To be sure, this convenience is not to be underestimated.
TurtleJS is designed to get students writing correct (although highly scoffolded and idiolectic) JS in the browser console from the beginning. The idea here is to give students a direct connection to the actually-existing technologies that run much of what they see on screens. JS, for all its warts and weirdness, runs much of the web and a great deal of mobile apps. Learning JS in the browser (instead of in a dedicated IDE, e.g. Processing or DrRacket) connects students to the technologies that organize their lives and articulate their ordinary.
But also, JS's flexibility means you get to teach it how you want, in the order that you want, with a great many different options. More to the point, whatever Python ideologists may want you to believe, there is, of course, always more than one way to do a thing—and that's not a bad thing. I have found that teaching refactoring very early in the process of learning to code is actually really valuable, and understanding that there's always more than one right way to attack a problem is a very good thing. (As Papert shows, students often use idiolectic ways of approaching problems, and that's just fine. Javasript says: may 1,000 idiolects bloom.)
It does not mean: learning the DOM. TurtleJS assumes and teaches no knowledge whatsoever of HTML or CSS (or any of the modern web technologies that go with them). It also does not mean: learning common frontend frameworks (React, Angular, Vue, etc.). It does not mean learning anything about MVC or MVVM or other MV* frameworks. Following LOGO and Papert's original ethos, what TurtleJS hopefully leads to is programmatic (or computational, or, in a confusing turn of phrase to my contemporary ear, procedural) thinking. For Papert, programmatic thinking is an especially powerful way of thinking about thinking. This approach aims to get students to a relatively rich understanding of what computation is, how it works, what it means, and how to think with it without teaching formal computer science or practical software engineering.
p5.js is the Javascript adaptation of Processing (which was originally written in Java, with its truly irritating imperative OO programming style and its static typing—there is no relation other than a mid/late-1990s marketing decision). Processing, and thus p5, were developed under the influence of LOGO at the MIT Media Lab, but Processing sure ain't LOGO. There's a world of difference between ellipse(100, 100, 50, 50) and REPEAT 360 [ FORWARD 1 RIGHT 1 ]. In particular, Processing substitutes abstracted Cartesian geometry for "body syntonic" (Papert's term) polar, relative geometry of LOGO's "turtle." (The difference is roughly that between, "draw an ellipse of width 50 and height 50 with the center 100 from the top and 100 from the left" and "to make a circle, go forward a little bit and turn a little bit, and repeat that until you're back in the same place.") This abstraction is not necessarily a problem, since the college-age students who typically start with Processing in new media arts curricula have presumably worked through Cartesian geometry (whatever "worked through" might mean), and certainly do need to learn it to do any sophisticated animation.
That said, a humanities coding curriculum isn't necessarily bound to practical outcomes, and the crucial bit lies in understanding the relations between different kinds of computational abstraction. (This is cognate to Papert's wonderful presentation of the basic media-theoretical idea that our technologies organize our thinking: school math looks the way it does because it's what you can do with children and pens and paper.) The idea behind TurtleJS is that students can progressively encounter (some of) the complexity that makes it operate, learning encapsulation as they go. (They will eventually use p5.js to make their own programs, but they won't use the relatively sophisticated metaprogramming strategies that make the TurtleJS DSL possible.) The shift from TurtleJS to p5.js, however, will be substantially more structured than the usual p5.js procedural, imperative flailing (and will, with a helper function here and there, be thankfully devoid of loops). The issue is to go from "muck around with it and see what it does" to more structured exploration of what Papert calls "microworlds."
The intuition here—and I'm only building this out now to be used instructionally at some point in time in the relatively distant future, likely fall 2018—is that the goal of of exploratory, syntonic learning is best served by exploring within "microworlds." Therefore, the idea is to provide a number of different environments, each with their own restrictions.