Skip to content

Curriculum

Jump to bottom
Dave Liepmann edited this page Mar 4, 2018 · 37 revisions

Curriculum and Pedagogy for Maria

Needless help is an actual hindrance to the development of natural forces. –Maria Montessori

Curriculum overview

  1. First we briefly introduce programming and the coding environment in Learn Clojure with Shapes. This introduction is essentially a blatant loving rewrite of Quick: An Introduction to Racket with Pictures. The goal is to walk the learner through the basics of working in Maria using an absolute minimum of syntax and programming concepts.

    We would like this introduction to be short. Our hope is that with coaching, someone familiar with computers but who has never programmed (or used a command shell, or learned advanced maths, etc.) could be expected to complete this introduction in an hour.

    The introduction uses shapes to introduce the learner to a bare-bones list of programming concepts, which for us means:

    • evaluating expressions and functions, including evaluating different parts of compound and nested expressions
    • asking the computer what stuff is and what it does with, e.g., doc and what-is
    • having the computer do rote work for us, for instance, map over stuff
    • writing our own functions (so, fn)
    • naming our creations with let, def, and defn
    • that's it, really; all the rest should come separately

  2. Second, present the learner with a choice of "modules" according to their interests. This includes Welcome to Cells, Shannon's Entropy, and other topics still being written. "Rules" for these follow-up modules are few, but in general they should focus on a problem to solve, an idea or dataset to explore, or a cool thing to build, not a language feature or function. That said, our goal with these "hook" tasks as follow-ups to Learn Clojure with Shapes is to lead naturally to basic programming tasks like working with data structures. Curriculum goals at this stage should follow naturally from the task and be implicit (that is, hidden from the user), but it would be reasonable to introduce things like first, rest, nth, rand-nth, sets, maps, threading, and so on. In some instances it would be appropriate to explore namespaces, for instance, when the need arises to use clojure.string. In other instances one might make the decision to hide namespacing, and refer those functions under the hood.

    Possibilities for these follow-up modules include:

    • drawing/playing with shapes, using Quil or native Maria shapes
    • introduction to basics of computer science (recursion, higher order functions)
    • webdev (this may be complicated by the fact that Maria is a self-enclosed tool, so building a web app may not be within scope. Instead, perhaps it would be possible to make a remote API call?)
    • an exploration of Clojure features, e.g. laziness, infinite sequences, data types (this is the closest analogue to the existing ClojureBridge curriculum) (see this Clojure introduction touching on these topics--could be useful starting point)
    • a wander through mathematics or statistics (Fibonnacci, Shannon's entropy, Markov chains)
    • word or programming puzzles (see, for example, ClojureBridge's Caesar cypher exercise)
    • "Brain tripping" (Matt's Markov impersonator)
    • REPL as an external brain pack for thinking during research (maybe dive into e.g. lead-crime hypothesis)
    • installing an environment for more standard project work, e.g. JVM/leiningen/editor of choice/git akin to the ClojureBridge installfest followed by an initially trivial first project touching on dependencies
    • your idea goes here - please contribute!

  3. Finally, and in a non-linear relationship to the two preceding items, provide examples for learners to see what is possible and to copy and modify. The motivating idea here is that we teach in two ways: by explicit communication of concepts and by example. This is the purpose of the Gallery: instead of explicitly teaching, just show them possibilities that they don't necessarily understand, it's also important to not explicitly teach. Teaching is where topics are introduced piecemeal, with minimal but complete explanations and walkthroughs of progressively complex examples. The gallery is for exploration that includes none of those things. We believe oscillating between these two poles of teaching approach is vital.

Primary inspiration

Quick: An Introduction to Racket with Pictures is highly recommended reading to understand where our approach comes from. Note its fast on-ramp and simple LEGO-like way of learning techniques like define or functions as first-class objects through pictures and simple tasks rather than theoretical explanations.

Secondary resources

See also the background reading.

Guiding principles

The best way to learn a tool’s usefulness is to do the task without the tool. Feel the pain and hassle that the tool cuts through. Only then introduce the tool as one’s savior. (There’s a specific article that described this really well; if you have the URL I’d be very happy to re-receive it.)

"The practice of programming is a powerful way to develop a deeper understanding of any subject. Indeed, by the act of debugging we learn about our misconceptions, and by reflecting on our bugs and their resolutions we learn ways to learn more effectively." – Functional Differential Geometry by Gerald Jay Sussman, Jack Wisdom, Will Farr, page xiii of the preface, concept attributed to Seymour Papert and Marvin Minsky

Language features should be disclosed progressively, as they arise through exploration or in the necessity of introduction of a task.

Syntactic sugar, optimal approaches, theoretical understanding, and shorthand are all to be avoided in favor of letting the student experience basic interaction with the computer. Use of syntactic sugar should be avoided as long as possible, since it is incidental complexity.

Our audience includes true beginners, meaning folks who haven't worked in other programming languages. This means they probably have a limited vocabulary of functions and tech jargon. Therefore we introduce new concepts and functions only if absolutely necessary for the specific teaching goal of the moment. We explicitly teach fewer things, with minimal (preferably zero) theory.

Curriculum Roadmap

  • introduce keyboard-based expand/contract selection in intro
  • introduce slurp/un-slurp in the intro
  • polish writing in existing follow-up modules, especially Data Flow
  • split Learn Clojure with Shapes in twain: one version continues mostly as-is for learners working through it on their own (such as those coming to the site remotely), and a separate fork intended to cover similar curriculum with the assumption of a Clojure-knowledgeable coach present (such as it is used for ClojureBridge Berlin)
  • incorporate what we learned using maria.cloud at ClojureBridge Berlin 2017
    • maybe reconsider the puppy emoji? one learner expected that to be the result of evaluating "puppy"
    • look for a way for Firefox not to mark 90% of words as misspelled
    • replace diagrams for fn and if with images or gifs; they are great but just didn't work
    • look for a way for our emojis not to look like black-and-white garbage on Windows
    • fix skipping-around in cells-based confetti example in Gallery
    • nix "parameter" in rectangle docstring
    • provide cheatsheet/inventory for drawing fns
    • mention square in rectangle docstring
    • revise "pyramid" section; it caused widespread confusion
    • revise rand-nth section; it's an unclear transition and poorly written; confusion arose from "use all the techniques"
    • fix scale docs; they say it rotates the shape?!
    • IMPORTANT implement and introduce an animation template akin to Quil sketches, so that learners can immediately make use of something akin to frame-count. Include an example using sine curves.
    • Structure editing is non-obvious, we need to tell them about balanced parentheses and they naturally need slurp very early. Explain highlights and scope for evaluation, and what the parens are doing in terms of containment of sub-expressions.
    • Not clear which part of (circle 50) is the “arguments”, maybe a diagram naming the parts of an expression they will evaluate?
    • We need to explain doc better, and repeat it more. They learn so many things that by the time they need to use doc they’ve forgotten seeing it earlier.
    • Maybe need to define code block vs text (“prose”) block? Two learners still didn’t know what those terms meant after doing half the intro.
    • Editor QuickStart seems to help. An editor game might be helpful? Also, maybe an evaluation game? (both would be freestanding).
    • “What’s the difference between which-key and the command palette?” <- maybe need to make this a little more clear, another good opportunity for a gif.
    • “The function explanation feels very theoretical, maybe an example after each paragraph?”
    • Remove all need for scrolling. One student copied all the examples to a sticky (electronic) so she wouldn’t have to scroll back.
    • Diagram for x/y coordinate system so they understand how position works.
    • More explicit about docstring section.
    • rumor mill says the jump to map was a bit sudden (perhaps just inherently challenging)
    • consider introducing functions before map

Differences from Orthodox Clojure

Some of these are only plans for the future.

  • side-by-side interface (normally Clojurists use a REPL or in-buffer evaluation, e.g. with CIDER)
  • nice error messages
  • the what-is function is specific to this environment
  • all drawings and shape manipulation (circle, line-up, colorize) are specific to this environment
  • we say "Clojure" which many people hear as "Clojure on the JVM" whereas we are using "Clojure in JavaScript" a.k.a. ClojureScript--but it's all just Clojure on different hosts
  • comments, sections, and headings may stray from plain Clojure to enhanced syntax for a Markdown-based literate-programming approach
Clone this wiki locally