Mindstorms: Children, Computers, And Powerful Ideas

4.7
All Hacker News 18
This Year Hacker News 3
This Month Hacker News 1

Comments

by credit_guy   2020-07-02
A lot of people hold this belief that knowing how to do X with an "incorrect form" is worse than not knowing at all, if you want to progress at doing X.

In programming we have debugging. You have a program that does X, but with some bugs. You later improve the program by removing the bugs.

Why can't we do this in "real life" as well? You learn how to add multi-digit numbers from right to left. You then later relearn that by going from left to right. You learn to swim with your head above the water, then later learn to keep your head in the water, and turn it every two strokes to get a quick breath.

In fact, I read about this concept of "debugging" bad habits exactly in the context of juggling. Seymour Papert covers this in Mindstorms [1], p 111. He explains that the most common "bug" that prevents people from performing 3-ball juggling is following one ball with the eyes. Once you are aware of that, you the fix is quite easy: keep your eyes pointed at the apex of the ball's trajectory. In a later chapter he goes on to say that other things can be "debugged" as well; one example is relearning skiing to replace a v-type position to a parallel ski position.

[1] https://www.amazon.com/Mindstorms-Children-Computers-Powerfu...

by hhas01   2020-06-08
Nope. It’s not about “parsing”, it’s about representation.

Languages such as Python and C draw clear distinction between literal values on one hand and flow control statements and operators on the other. Numbers, strings, arrays, structs are first-class data. Commands, conditionals, math operators, etc are not; you cannot instantiate them, you cannot manipulate them.

What homoiconic languages do is get rid of that (artificial) distinction.

Lisp takes one approach, which is to describe commands using an existing data structure (list). This overloading means a Lisp program is context-sensitive: evaluate it one way, and you get a nested data structure; evaluate it another, you get behaviors expressed. The former representation, of course, is what Lisp macros manipulate, transforming one set of commands into another.

Programming in Algol-descended languages, we tend to think algorithmically: a sequence of instructions to be performed, one after the other, in order of appearance. Whereas Lisp-like languages tend to encourage more compositional thinking: composing existing behaviors to form new behaviors; in Lisp’s case, by literally composing lists.

Another (novel?) approach to homoiconicity is to make commands themselves a first-class datatype within the language. A programming language does not need swathes of Python/C-style operators and statements to be fully featured; only commands are actually required.

I did this in my kiwi language: a command is written natively as `foo (arg1, arg2)`, which is represented under the hood as a value of type Command, which is itself composed of a Name, a List of zero or more arguments, and a Scope (lexical binding). You can create a command, you can store it and pass it around, and you can evaluate it by retrieving it from storage within a command evaluation (“Run”) context:

    R> store value (foo, show value (“Hello, ”{$input}“!”))
    R> 
    R> input (“Bob”)
    #  “Bob”
    R> 
    R> {$foo}
    Hello, Bob!
Curly braces here indicate tags, which kiwi uses instead of variables to retrieve values from storage. (Tags are first-class values too, literally values describing a substitution to be performed when evaluated.)

..

When it comes to homoiconicity, Lisp actually “cheats” a bit. Because it eagerly (“dumbly”) evaluates argument lists, some commands such as conditionals and lambdas end up being implemented as special forms. They might look the same as every other command but their non-standard behaviors are custom-wired into the runtime. (TBH, Lisp is not that good a Lisp.)

Kiwi, like John Shutt’s Kernel, eliminates the need for special forms entirely by one additional change: decoupling command evaluation from argument evaluation. Commands capture their argument lists unevaluated, thunked with their original scope, leaving each argument to be evaluated by the receiving handler as/when/only if necessary. Thus `AND`/`OR`, `if…else…`, `repeat…`, and other “short-circuiting” operators and statements in Python and C are, in kiwi, just ordinary commands.

What’s striking is how much non-essential complexity these two fundamental design choices eliminate from the language’s semantics, as well as from the subsequent implementation. kiwi has just two built-in behaviors: tag substitution and command evaluation. The core language implementation is tiny; maybe 3000LOC for six standard data types, environment, and evaluator. All other behaviors are provided by external handler libraries: even “basics” like math, flow control, storing values, and defining handlers of your own. Had I’d tried to build a Python-like language, I’d still be writing it 10 years on.

There are other advantages too. K&R spends chapters discussing its various operators and flow control statements; and that’s even before it gets to its stdlibs. I once did a book on a Python-like language; hundreds of pages just to cover the built-in behaviors: murder for me, and probably not much better on readers.

In kiwi, the core documentation covering the built-in data types and how to use them, is less than three dozen pages. You can read it all in half an hour. Command handlers are documented separately, each as its own standardized “manpage” (currently auto-generated in CLI and HTML formats), complete with automated indexing and categorization, TOC and search engine. You can look up any language feature if/when/as you need it, either statically or in an interactive shell. Far quicker than spelunking the Python/C docs. A lot nicer than Bash.

Oh, and because all behaviors are library-defined, kiwi can be used as a data-only language a-la JSON just by running a kiwi interpreter without any libraries loaded. Contrast that with JavaScript’s notorious `eval(jsonString)`. It wasn’t created with this use-case in mind either; it just shook out of its design as a nice free bonus. We ended up using it as our preferred data interchange format for external data sources.

Honestly, I didn’t even plumb half the capabilities the language has. (Meta-programming, GUI form auto-generation, IPC-distributable job descriptions…)

..

Mind, kiwi’s a highly specialized DSL and its pure command syntax makes for some awkward reading code when it comes to tasks such as math. For instance, having to write `input (2), + (2)` rather than the much more familiar `2 + 2`, or even `(+ 2 2)`. Alas it’s also proprietary, which is why I can’t link it directly; I use it here because it’s the homoiconic language I’m most familiar with, and because it demonstrates that even a relative dumbass like me can easily implement a sophisticated working language just by eliminating all the syntactic and semantic complexity that other languages put in for no better reason than “that’s how other languages do it”.

More recently, I’ve been working on a general-purpose language that keeps the same underlying “everything is a command” homoiconicity while also allowing commands to be “skinned” with library-defined operator syntax to aid readability. (i.e. Algebraic syntax is the original DSL!) It’s very much a work in progress and may or may not achieve its design goals, but you can get some idea of how it looks here:

https://www.amazon.com/Mindstorms-Children-Computers-Powerfu...

by caenn   2019-07-05
Mindstorms: Children, Computers, And Powerful Ideas https://www.amazon.com/Mindstorms-Children-Computers-Powerfu...
by endlessvoid94   2018-11-10
Obligatory "Mindstorms" recommendation: https://www.amazon.com/Mindstorms-Children-Computers-Powerfu...
by ModernMech   2018-11-02
I'm sorry to say, but I don't believe a dismissive attitude can ever be described as professional.

I believe everyone can be taught to program, and the choice of language, semantics, and syntax has a profound effect on how far people can get, and what frustrations they face.

There are people out there with 0 formal training who run entire businesses on Excel, the most widely used programming language bar none (it's notable that in Excel, rows start at 1 and not 0. There is a reason for this). Ask a 7 year old to use C and they're not going to get very far. Give a 7 year old Logo, and they'll be writing programs with very little instruction, with results I've seen college freshmen struggle with.

I teach a summer robotics program to middle schoolers. We used to teach it in C++ because that's what the SDK came written in. In this mode, we spent most of the time getting them to think like the compiler, teaching them about memory layout, allocation, compiling, headers, preprocessors, etc. because they constantly ran into frustrations due to the design choices of C++. They never left the session with a firm understanding and confidence around programming because they spent all their time trying to build a model from scratch in their head without any relation to their own world.

Then we switched to Matlab. With one uniform data structure, a REPL, 1-based indexing, etc. they were much more comfortable, and they were able to make the robots do amazing things for their age. The most impressive thing I've seen is making a robot choir through writing a distributed protocol to synchronize the robots' notes. They were able to do this because the language, Matlab, got out of their way, which allowed them to focus on the task and relate it back to something they knew very well: music.

All I'm saying is this attitude of "Oh, you don't understand this thing we've built and these arbitrary limitations frustrate you, therefore you shouldn't even try it in the first place" is just toxic, given the evidence I've seen that people can learn and do amazing things if we give them a fighting chance.

Required reading on this subject: https://www.amazon.com/Mindstorms-Children-Computers-Powerfu...

by wallflower   2017-08-19
The beauty of Scratch and other similar tools is that instead of the teacher asking questions, the child learns to ask their own questions.

If you are interested in learning more about this mindset, you should read Mindstorms by Seymour Papert (RIP).

https://www.amazon.com/Mindstorms-Children-Computers-Powerfu...

Scratch can be a "gateway drug" to languages that professional programmers use. The extensions/abstractions of Scratch from Berkeley that deal with making it do complicated things seem like putting a fish on a bicycle. Sometimes, you just have to leap and try to not fall.

by dahjelle   2017-08-19
I don't have a direct answer for you (still researching), but if you haven't read Mindstorms by Seymour Papert [1], I highly recommend it. It's generally about how computing can help kids learn problem solving in a variety of contexts, including several bits about the LOGO programming language. It's from '88, so it is definitely dated, but many of the concepts are pretty timeless.

[1] http://www.amazon.com/Mindstorms-Children-Computers-Powerful...

by tel   2017-08-19
(Also at: http://www.ft.com/cms/s/2/118169b6-1d74-11e2-869b-00144feabd...)

I have a thesis that the kind of thinking required to survive med school is diametrically opposed to the kind of thinking required to do statistics well. It's the "rote pattern matching" versus "mathetic language fluency" issue that's at the heart of things like Papert's Constructivist learning theory[1] and it really causes me to have little surprise at an article like this. Doctors are (usually) viciously smart people who have to make a wide array of difficult decisions daily, but to operate at that level requires an intuition around a lot of cached knowledge, something I feel to be basically the opposite of statistical thought.

I don't think this is unique, either. It's the heart of Fisher's program to provide statistical tests as tools to decision-makers[2]. It's an undoubted success in providing general defense against coincidences to a wide audience, but it casts the deductive process needed in a pale light.

I think a principle component of the computer revolution is to provide more people with better insight into mathetic thought. Papert focuses on combinatorial examples in children in Mindstorms[3] but I think the next level is understand information theory, distributions, and correlation on an intuitive level. MCMC sampling went an incredible way to helping me to understand these ideas and probabilistic programming languages are a great step toward making these ideas more available to the common public, but we also need great visualization (something far removed from today's often lazy "data viz").

Ideally, things like means and variances will be concepts that are stronger than just parameters of the normal distribution---which I feel is about as far as a good student in a typical college curriculum statistics class in a science or engineering major can go---but instead be tightly connected to using distributions accurately when thinking of complex systems of many interacting parts and using concentration inequalities to guide intuition.

I think the biggest driver of the recent popularization of Bayesian statistics is that distributions as a mode of thought is something quite natural to the human brain, but also something rather unrefined. People can roughly understand uncertainty about an outcome, but have a harder time with conjunctions or risk. How can we build tools that will teach people greater refinement of these intuitions?

[1] http://en.wikipedia.org/wiki/Constructivism_(learning_theory... [2] http://en.wikipedia.org/wiki/Statistical_Methods_for_Researc... [3] http://www.amazon.com/dp/0465046746

by GHFigs   2017-08-19
Seymore Papert, in Mindstorms:

"By deliberately learning to imitate mechanical thinking, the learner becomes able to articulate what mechanical thinking is and what it is not. The exercise can lead to greater confidence about the ability to choose a cognitive style that suits the problem. Analysis of "mechanical thinking" and how it is different from other kinds and practice with problem analysis can result in a new degree of intellectual sophistication. By providing a very concrete down-to-earth model of a particular style of thinking, work with the computer can make it easier to understand that there is such a thing as a "style of thinking". And giving children the opportunity to choose one style or another provides an opportunity to develop the skill necessary to choose between styles. Thus instead of inducing mechanical thinking, contact with computers could turn out to be the best conceivable antidote to it. And for me what is the most important in this is that through these experiences these children would be serving their apprenticeships as epistemologists, that is to say learning to think articulately about thinking."

http://www.amazon.com/Mindstorms-Children-Computers-Powerful...