Skip to content

Curriculum

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

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

The Maria introduction to programming through Clojure intentionally avoids getting into the benefits of Lisp syntax, language features like immutability or laziness, hosting and tooling concerns, and the full span of basic data types. It is therefore a consciously incomplete introduction. While all of those topics are valuable material, they are secondary for the programming beginner. Instead, since Clojure programmers typically spend the majority of their time working with expressions, names, and functions in an editor-integrated REPL, we offer with Maria a playground where the beginner is introduced to that workflow. Familiarization with the many technical terms and concepts our community uses is left as a future task to be accomplished gradually, as the need for specific topics arises.

We support both beginners and experienced developers by providing Hiccup-syntaxed interfaces, a picture language, a simple reactive data flow mechanism, and humane REPL ergonomics. These pave the way for quite complex and powerful interactive explorations.

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, technical jargon, 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. (Do not take that as an estimate to expect--it has not been thoroughly tested.)

    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, usually not a language feature or specific 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. 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

  • polish writing in existing follow-up modules, especially Data Flow
  • incorporate what we learned using maria.cloud at ClojureBridge Berlin 2017
    • look for a way for Firefox not to mark 90% of words as misspelled
    • look for a way for our emojis not to look like black-and-white garbage on Windows -- try wrapping with "Segoe UI Emoji" font per https://www.tjvantoll.com/2016/06/15/emoji-on-windows/
    • provide API docs over shapes library (and perhaps friendly libs as well?) -- need to brainstorm format that will take
    • 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. now handled (mostly) in editor quickstart - we should circle back on this after more testing
    • “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.
    • 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.

Differences from Orthodox Clojure

  • side-by-side interface (normally Clojurists use a REPL or editor-integrated in-buffer evaluation, e.g. CIDER)
  • Markdown-based literate-programming, but using comments so source files can be plain Clojure gists
  • nice error messages
  • convenience functions for the beginner, such as what-is
  • picture language provided
  • 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
Clone this wiki locally