A little bit of computing goes a long way, and not everyone needs software engineering: The SIGCSE 50th Anniversary issue of ACM Inroads
January 7, 2019 at 7:00 am 34 comments
This year is the 50th SIGCSE Technical Symposium, and Jane Prey was guest editor for a special issue of ACM Inroads on 50 years of ACM SIGCSE. You can see the current issue here, but yes, it’s behind a paywall — ACM Inroads is meant to be a membership benefit.
I’m really fascinated by this issue. Sally Fincher does a nice job telling the story of ICER. I enjoyed Susan Rodgers’ and Valerie Barr’s reflections. I’m still trying to understand all of Zach Dodds’ references in his SIGCSE 2065 future-retrospective. I found some of the articles frustrating and disagreed with some of the claims (e.g., I don’t think it’s true that AP CS enrollments plummeted after introducing Java), but discussion can be good for the community.
I was asked to write a piece about What we care about now, and what we’ll care about in the future. My bottom line is a claim that John Maloney (of Squeak, Scratch, and GP fame) reminded me is a favorite phrase of the great Logo (and many other things) designer, Brian Silverman: A little bit of computing goes a long way.
The important part of Scratch is that computationalists find value in it, i.e., that they can make something that they care about in Scratch. What we see in Scratch is the same process we see among the computationalists in computational photography, journalism, and science. They don’t need all of computer science. They can find value and make something useful with just some parts of computing. Scratch projects smell wonderful to Scratch computationalists.
There’s been a thread on Twitter recently about the use of software engineering principles to critique Scratch projects (see the thread starting here). Researchers in software engineering claim that Scratch code “smells,” e.g., has bad practices associated with it. There’s even a website that will analyze your Scratch project in terms of these software engineering practices, DrScratch. The website claims that it is measuring computational thinking skills — I see no evidence of that at all.
These software engineering researchers are misunderstanding users and genres of programming. They ought to read Turkle and Papert’s Epistemological Pluralism and the Revaluation of the Concrete. People code for different purposes, with different ways of appropriating code. The standards of the software engineer are not appropriate to apply to children. Not everybody is going to be a professional software developer, and they don’t need to be.
Increasingly, people are only going to use parts of computer science, and they will achieve fluency in those. That’s a wonderful and powerful thing. A little bit of computing goes a long way.
Entry filed under: Uncategorized. Tags: computing education, Scratch, Seymour Papert, SIGCSE.
34 Comments Add your own
Leave a comment
Trackback this post | Subscribe to the comments via RSS Feed
Computing Ed Research - Guzdial's Take 
1.
alanone1 | January 7, 2019 at 7:48 am
“A little bit of writing goes a long way” (or does it?)
There’s a lot of evidence that this sentiment underlies a lot of the use of writing and exhibited skills of most people via the computer media these days.
On the other hand, most people will not become professional writers, so we have to ask if there is an absolutely needed level of writing that is below professional, yet enough above “transcriptions of oral language use” to require some real learning.
If so, then we need to ask about how to help children achieve this level of “above ‘oral hacks’ and below ‘literate engineering’ “.
Most teachers of writing would agree that the initial processes be started as early as possible, and to initially hook up with oral usage. One very successful early years writing process had children do little storyboards and thumbnails to help them with sequencing beyond what their genetics were supplying at the time. Another had the children act as reporters for a joint project of a newspaper (which also require more structuring).
Doing regular writing several times a week is also a very good practice.
And so forth. A big point that has to do with cognitive load is that early development of fluencies open up room for new chunks that can be used for more organized uses and longer uses of language.
If computing is to become part of one’s intellectual major tool box, then I think we need to heed this analogy (and by the way, let’s fix up what has gone wrong with reading and writing of natural language while we are at it)!
This means that Scratch — like its ancestor Etoys — might be good in the 5th and 6th grades — it is not very good in either the earliest grades, and it becomes a barrier around the end of middle school.
An attempt at an analogy to a good reading and writing (and math and science) program for elementary grades would also be extremely fruitful for the design and pedagogy of computing for this age group and later on as well.
2.
joek van montfort | January 7, 2019 at 2:21 pm
With computing media around for less than 80 years, ideas on learning _with_ computational media some 50 years and ideas on teaching _about_ computational media even less, one can say: we just started. Contrary to math and language we have hardly ideas on what to start with. The CS equivalent of number sense or shapes.
Actually we find it more easy to throw in a new term (or revive an old one) than to truly explore, and find some common ground, what education about computational media could be about.
Taking Codeweek 2013 as an (arbitrary) starting point we now “enjoy” 5 years of support from tech industry heavily interested in enlarging the pool of CS savvy students, not at all interested in education at large. Helping studies “What to do after Scratch?” (think text based programming as better than block based) instead of “What’s empowering to do before or beside Scratch”
It doesn’t help. On the contrary, they kind of focus on todays situation at tech companies. Worse, every year they plug a new technology to put center stage.
Much more valuable (“extremely fruitful” in last paragraph of Alan’s comment) would be to find the bits underpinning it all, and ideas to teach these bits. Actually I think decades old contributions by Alan still are among the better starting points to think this.
I take the opportunity to mention another quite different try by Tim Bell to get the 10 most important ideas of CS listed which is open for improvement: http://tinyurl.com/big-ideas-cs
3.
alanone1 | January 8, 2019 at 3:24 am
*”one can say: we just started. Contrary to math and language we have hardly ideas on what to start with. The CS equivalent of number sense or shapes.”*
Thanks for your kind words, but please let me disagree with your initial approach in your comment. If we take “we” above as some large percentage of the field — or of the people who now have some interest in teaching computing — I think I’d agree that “they” have “hardly ideas on what to start with” after “80 years”
But it is usually the case that talents and outlooks are distributed unevenly in most populations, so — for good and great ideas — we want to find those few thinkers with unusual insights and try to *learn* what they actually mean (the learning is critical because these are unusual people, and their views by definition will not be shared by most).
This eliminates almost all of “we”, and exhibits a few special thinkers to whom we should pay a lot of attention and put forth large efforts to understand. These include a number of special thinkers from the past — such as Maria Montessori, Alan Perlis, Jerome Bruner, Seymour Papert, etc. — and a smaller number from the present — such as Bret Victor. The combined ideas don’t all mesh perfectly, but they (a) set a good high bar for quality of thought that we need to heed, and (b) they provide both principles and examples from which good starts can be made.
Just to take those five in historical order:
(a) Maria Montessori understood that humans — especially children — are set up to learn their cultures from being embedded in them. So the best way to get them to learn advanced epistemologies is to embed the ideas in the learning environment itself *as culture*.
(b) Alan Perlis (the first Turing Award winner, great thinker, and one of the coiners of the term and idea of “computer science”), said that “the science of computers is the *science of processes* (all processes)”.
(c) Jerome Bruner’s insight and challenge: “Any idea can be taught to anyone in an intellectually honest fashion if we heed their level of development”.
(d) Seymour Papert saw computing for children as a special new form and material for representing ideas of all kinds that could drastically change the kinds of ideas they could learn at early ages.
(e) Bret Victor thinks of computing for all — and especially children — as “manipulable magic for all” embedded into the whole environment of one’s life, and that this gives rise to a new kind of design, new media, and new literacies (many of the ideas influenced by the above four thinkers plus a few more).
It’s important to note from these insights that what counts are *examples/projects* that (a) children can do, and (b) that *lift* their epistemological perspectives and fluencies to the best we know of in the modern world. These will very often require new versions of the adult subjects to be *invented* that are “intellectually honest versions” of the ideas (watering down the quality of the ideas is a sin, and trying to teach adult versions is almost always also an educational sin).
A really important design heuristic can be used here: before trying to write down “principles” and “big ideas”, it is much better to gather the best examples from what has already been done with children and computing, mathematics, science, art, etc. This provides a fruitful glimpse into the “levels of development” without having to come up with crisp definitions.
This also provides a way to ask “what seems to be missing?”. Some of these will be ideas that need further levels of development, and some of them will be great additions the ages of children being addressed, and will give rise to more examples to be tried.
These examples lead directly to ideas for fruitful new computer languages and mechanisms, and especially new ways to connect developmental levels with projects.
As with many other kinds of learning, it is a good idea to be very careful about “things that learners can do in the beginning” that will hold them back later on. For example, there are ways and examples to teach complete beginners about processes and systems from the very first rather than making these ideas almost invisible by teaching only simple programming with “data” or single objects.
In brief, when we talk about “education for children” we are discussing ideas and processes that will deeply affect children’s lives and outlooks. Don’t the children deserve “the first team” rather than the well meaning but disturbingly ignorant and unimaginative people who are trying to make something happen without any sense that what they are doing is not good?
The rejoinder “Well, it’s a start” has not panned out for any previous educational reform — there are qualitative barriers that require high quality people to surmount.
4.
orcmid | January 7, 2019 at 12:12 pm
Short response: The December 2018 ACM Inroads issue that you link to has its HTML articles free to view. I confirmed that with the John White, Peter Denning, and your articles.
Also, I think a little SE also goes a long way and it is possible to introduce it around trustworthiness and practices for accountability.
What comes to mind is learning to check ones work, and have it confirmed by others, in the learning of arithmetic. Learning to check ones own work is a valuable skill. For programs, whether with practical, educational, or recreational purposes, the demonstration that a program is suitable for the purpose of its creation is something to cultivate, along with ideas of trustworthiness (as opposed to perfectionism).
5.
Mark L. Miller, Ph.D. | January 7, 2019 at 3:01 pm
Mark,
Interesting perspective. Two quick reactions:
1. I think there there is a need for ALL children to have some exposure to computational thinking, to some level of literacy if not fluency. I have to agree that most do not need to learn all of computer science. (In fact, one might argue that CS itself is now such a large field, with impacts on so many neighboring fields, that even a Computer Scientist cannot realistically aspire to be fluent in all of it.) This first level falls into the realm where it is needed to have a good understanding as an educated citizen, just as all students need to learn reading, writing, and some level of mathematics. There also needs to be another level (available to all but not inflicted upon all) where topics such as good software engineering practices for programming-in-the-large, or (say) proof of the halting problem are only required for those going on to more advanced studies in the field. I don’t mind if not everyone learns the language du jour for the AP test, so long as everyone has the OPPORTUNITY to learn it.
2. Having said this, there are a few aspects of Scratch — as wonderful as it is — could have helped make a few big ideas more accessible. The most notable of those, in my mind, is the lack of ability to create a true function. (One can create a block, even a block with inputs, but those blocks cannot return a value. I haven’t had a chance to verify this with v3.0 yet, but my understanding was that there were no plans to add this capability. Hence, even to do something as simple as create a function that computes the double of a number, or turns a string into a palindrome, has been left out, and can be accomplished only by setting a global value (which is not only poor software engineering but also missing the beauty of some core mathematics). Another example (and I haven’t yet checked if this changed in v3.0) is the ability to reuse a student-created block within multiple sprites, short of dragging a COPY of it into each one. This undermines much of the practical benefit of creating a block, making it harder for students to see the power. These are two fundamental problem-solving ideas, very much akin to what one finds in Polya’s how-to-solve-it (but from a computational perspective) and I think it is unfortunate that these capabilities were not provided. While I remain in awe of what Scratch has accomplished, and look forward to learning all the cool new features of v3.0, these are concerns that need to be brought forward. It is fine to say that “Scratch was not intended for teaching Computer Science, but merely Creativity,” but in practice, most of the nation and much of the world believe that teaching Scratch is the key first step (or second, after Code.org) in teaching CS, and no one has disabused them of that notion.
It is easy to criticize and so I offer these remarks in a constructive way and with a hope to see the concerns addressed in some future version. Meanwhile, as many know, for those of us who worry about such things, there are options such as Snap!, inspired by Scratched but designed to address such things.
Regards, Mark
6.
Mark Guzdial | January 8, 2019 at 9:43 am
Hi Mark,
Could you say more about why you think Scratch has to support functions with inputs and reuse of student-created blocks? I completely agree that these are powerful CS ideas, and I also agree that Scratch is being used to teach CS concepts (well, in my opinion). Arguing that more of CS needs to be in Scratch feels like arguing that I should be able to ride on a Fisher-Price car, or be able to built a dog house out of an erector set. When you’re ready to do more serious development, move to a new medium. Isn’t that exactly why John Maloney built GP? Why make the existing tool harder so that it no longer serves its purpose?
I liked a recent piece by Marina Bers on what kids learn from ScratchJR (see http://www.pbs.org/parents/expert-tips-advice/2018/11/what-kids-can-learn-through-coding/?utm_source=twitter&utm_medium=pbsofficial&linkId=100000004521011). It reminded me of the trajectory work by Katie Rich and company (see https://cacm.acm.org/blogs/blog-cacm/220552-measuring-student-self-efficacy-and-learning-trajectories-for-k-5-cs-icer-2017-trip-report/fulltext). This is the starting place. It’s authentic. It’s a steppingstone to the next stages of CS. Why force more CS down into Scratch?
Mark
7.
Mark L. Miller, Ph.D. | January 13, 2019 at 2:59 am
Hi, Mark,
Sorry for the delayed response. Let’s focus on including support for blocks that return a value (functions) as the example. Three quick thoughts:
Supporting functions would not “raise the floor” for Scratch, it would only raise the ceiling; including this capability would not make Scratch any less accessible. Those not interested in teaching or using functions can simply ignore them.
Not including this capability lowers the ceiling, forcing students to move to a different platform sooner than otherwise necessary, as they grow toward a deeper understanding of computer science. A common language pathway is Scratch -> Python; but the lack of functions in Scratch makes the transition to Python more difficult, because functions are of the essence in beginning Python programming. (My current workaround is to insert Snap! in between, but that requires students to learn yet a third system.) Moreover, the lack of functions encourages the development of bad habits such as using global variables to return values.
The ability to define functions is not a minor side capability but a central concept in computing. Experience with Logo showed that even young children can understand functions (and procedures generally) as a way to organize programs, corresponding to the “powerful idea” of breaking problems into subproblems. Why leave that out, when other, more complex features such as “cloning” (less central to the key ideas of computational thinking) are included?
Thanks for listening!
Best, Mark
8.
alanone1 | January 13, 2019 at 5:01 am
I don’t think “a pathway to Python” should be a motivation for anything in a language for beginners, especially young children.
To return to Bruner and Papert, what we really want is an “intellectually honest form” for what the children are to learn — in this case “computing” — this could be rather different from most parts of most “adult versions”.
Sometimes there are special things in adult versions that are great to get children started on, even if most of the adult world doesn’t use them (a good example in “maths” is “vectors” and the use of “differential vectors” instead of the normal ways “numbers” and “numerals” are presented).
There are lots of things that need to be heeded in designs whose artifacts will require learning, but to just pick one of the central ones here — cognitive load — we can go some distance only worrying deeply about it.
If this were about “riding a bicycle” then two different paths to reduce cognitive load would be (a) training wheels, or (b) a “balance bike”. The former is still the most popular, but in fact the balance bike is by far the best simplification of “riding a bike” that retains the main thing you need to learn. The differences between the two are qualitative.
My choice of a balance bike within computing would pick “creation of systems” as the central idea to always “feel” and be in view.
An example is the very first project in Etoys: “draw a car and get it to run; then draw a steering wheel and get it to control the car; then copy the car and wheel to get more car-wheel running systems”. This worked very well, but it could have been designed much better (I will not take the space here to try to explain how).
The two main perspectives on systems are (a) as “whole processes” that are doing things, and (b) as being made of “parts” that usually coordinate to some extent.
It is very fruitful to consider the parts as systems themselves which are considered as “whole parts” by the system that uses them, and as themselves being made of parts — which are systems — when we look inside. How they “coordinate” is an interesting question I’ll leave until a later note.
Given our two top priorities — reducing cognitive load and creation of systems — we should ask how the former affects how we design the latter. A very important thing to notice is — especially for beginners — that naming is not nearly as top a priority as “incorporating”,
This is easy to see in TinkerToy building. Configurations that can act as parts — like an arch or a triangle — can be thought about and put together without any labels (they don’t exist in TinkerToys). The key ideas here are “useful configurations” and “instantiations” of them.
Similarly “functions” and “procedures” and “objects” etc that can act as parts for larger organizations, don’t need to be labeled as black boxes (and shouldn’t be for beginners). Instead, they can exist as their own descriptions as “a boundary containing stuff”.
For beginners, they will be small, and easier to see, and especially remember what it is that they do. This is a very different — and much more important and deeper abstraction mechanism that using names as abbreviations and new vocabulary (both of which impose a lot of cognitive load on human minds).
One way to think about this is that “names” are “more local” than descriptions, especially if we can present the description as visually as possible (this is a standard way to reduce cognitive load: by using what is special about our visual mind and memories).
If we want to make one of these that can e.g. calculate a relationship for us, then we need to ask questions about how the “part” receives the parameters and delivers the relationships.
Once thought about this way, and in the context of keeping everything visible, we can imagine something much more straightforward than the idea of “passing parameters” to be bound invisibly in an invisible thing and miraculously winding up with the result replacing the thing that is going to do the work for us.
The latter is partly an artifact of textual ways to write relationships — visually we can be much more straightforward and direct.
Instead, we can show the learner just how the values enter the “thing”, what happens to them, and how the result(s) are sent out to the rest of the parts.
As with the balance bike adding the pedals after the kid has learned to ride securely, the idea of naming the thing can be introduced, and most especially the most useful ways to think about names of things can be gradually grokked (most humans wind up with a variety of bad ways to not quite understand naming and what it gives and what it takes away).
But we will need to solve naming because our visual minds run out of steam after about 100 things in the field of view, and we need to find ways to use the narrative part of our mind (a very large part it is) to organize visual relationships that start to get complex. A really simple one is to just “replace the “parts view” of a system with the “whole view” of the system” (and to be able to switch back and forth as needed). Labels — especially iconic ones — start to become useful to help remember what is under the “whole view”.
And so forth.
This was thought about when we started working on Etoys at Disney (and afterwards). It is actually a major task to do really well because it requires some deep thinking about what “the primacy of systems building” could be about for beginners.
We didn’t do it. I was hoping that Scratch would wind up different and better than Etoys — but in many ways it turned out to be less and not as good.
In any case, each era of design should build on both the strengths and weaknesses of the previous era of design, and this didn’t happen at all in the rush to “Coding For All”. As usual, the enthusiasts decided to start with what was around, rather than asking the key question for any endeavor “What Is Actually Needed?”. By not taking the time to work through this, much of what happened is much more like the answers to “What Are Actually Retrograde Ideas?”
9.
Mark L. Miller, Ph.D. | January 13, 2019 at 4:33 pm
Alan,
Thanks for the insights!
I am guessing that one reason we aren’t all quite on the same page here has to do with the age of the target users. I tend to work with slightly older students (5th grade and up) but I think much of the conversation is envisioning younger students. The Logo tradition had things like the Button Box for the younger set, which is somewhat analogous to ScratchJr perhaps, only more hands-on. There is also BeeBot and so on.
Once students start seeing variables and functions in their core math classes (however confusingly explained), though, perhaps it is time for them to start hearing a computational version of those ideas, as well? I think they have a better chance of not “hating math” and “sucking at math” if we give them better ways to think about it.
I’m still surprised by the community’s fear of functions in block-based programming. It works very well in Snap! and relatively young students aren’t bothered a bit by that capability being present, whether or not they use it. When they are ready, it is there, with no impact on cognitive load before then.
All the best. Thanks to Mark for kicking off a lively debate!
Best, Mark
10.
Mark Guzdial | January 13, 2019 at 8:30 pm
Hi Mark,
I’m not convinced that adding functions is a small change to Scratch. Having blocks in the palette that a student doesn’t understand makes the whole environment less inviting.
If you’re working with 5th graders and up, then why not use Bootstrap (which has terrific support for connecting functions to their mathematics representations) or GP? Why do you want to use Scratch?
11.
alanone1 | January 14, 2019 at 2:25 am
Hi MarkG
The Scratch palette already is segregated into sections for each kind of role. Adding another one that is not used for awhile won’t increase the clutter in a negative way.
I think the bigger issue is to help the children gain an operational fluency regarding functions. In most languages, including LOGO — and in math — the opaqueness of passing parameters, the invisibility of the execution context/frames, and the trickiness of seeing how the result “comes back” all were great barriers for many children.
I think two things can really make a difference: (a) to relate the passing of parameters to the style of binding of values to names that they have already encountered, and (b) for the system to be able to animate in a very clear way enough of the underlying machinery to make clear what is going on.
Philip Guo had a nice Python visualizer that could do some of these things (but Python’s form is not very well set up for children and beginners).
12.
Mark Guzdial | January 14, 2019 at 10:45 am
Hi Alan,
I’m more skeptical. Students who are “planners” (in the Sherry Turkle and Seymour Papert “Epistemological Pluralisms” sense) will probably ignore blocks that they don’t care about. “Bricoleurs” will try every block to see what it does. Those who try function blocks and can’t figure out what they or why they’re there might be discouraged and give up.
I’m quite sure that visualizations don’t help with this. We use Philip’s Python Tutor in our ebooks (see http://tinyurl.com/StudentCSP-new). The visualizations help if the students have a start on a notional machine. If they have no clue how function passing works, then we see just as Juha Sorva did in his dissertation (see my summary here: https://computinged.wordpress.com/2012/05/24/defining-what-does-it-mean-to-understand-computing/ and see the actual dissertation here http://lib.tkk.fi/Diss/2012/isbn9789526046266/), that students mumble about “boxes” and random walks through the graphics. The visualizations help for advanced students, and only increase confusion and frustration for the lower-ability students. (John Stasko found similar results for his algorithm animations in the 1990’s.)
I like what John Maloney is trying to do with GP, to have a “developer mode” where more blocks are made visible when a student says that they’re ready. The confusion and frustration is postponed. From my work on Emile, I’m pretty sure that students are not the best judges of when they are “ready” for the next level — self-monitoring skills are something that experts have, not novices. But I don’t know a better way to do it.
Mark
13.
alanone1 | January 14, 2019 at 11:35 am
So hide the extra palette!
14.
Mark L. Miller, Ph.D. | January 14, 2019 at 4:40 pm
MarkG and Alan,
Just a few quick comments due to time constraints.
There has long been talk of a “microworlds” capability which would (minimally) allow teachers to hide palettes that were not relevant for what the students were working on, so that you could progress to more advanced versions of Scratch simply by turning them on when ready.
All that is needed to enable functions in Scratch is a single “return” block. There is already (though not in the early versions) the ability for students to create new blocks with input parameters. The only thing missing for this capability is the ability to return a value. One block which takes 1 input, the value to be returned from the function being defined. (There are many less useful and less important blocks in Scratch already which could be left out if we are worried about cognitive overload due to the number of blocks.) This is not to say that it would be easy for the MIT team to implement, given that it was not a planned feature — I get that.
Back in the Logo days, the sorts of visual animations that Alan mentioned were part of the pedagogical approach to learning about functions and so on: it was called the “Little Man Model.” (We would now want to call it the Little Person Model, of course.) We probably need to do a test of several variations on this in order to confidently say that it helps or does not help students understand, whether it helps some but not others along a certain dimension of “learning style” (if there is such a thing) etc.
The reason I care about it, given that I can of course personally choose to use Snap! or one of the other tools recommended here, is that Scratch is the elephant in the room. Almost all K-8 teachers involved with teaching “computational thinking” tend to equate that set of ideas with Scratch. Hence, an entire generation of students is not being exposed to the concept of function, even though many believe they are learning powerful ideas from computation. My personally swimming upstream with other tools won’t fix that. I know that the goal of Scratch was always about creativity and there was a never a claim from the MIT team that it was teaching computer science. The problem is that the rest of the world didn’t hear their careful qualifications.
All the best. Delightful conversation!
MarkM
15.
Mark Guzdial | January 15, 2019 at 9:14 am
Hi Alan,
You once critiqued Python as make meta-programming too easy. You said that a meta-programming level was critical for a successful programming system, but it shouldn’t be something that one can stumble into or that one should use regularly — it was powerful and should be used carefully.
You suggested to me Bobrow and Kiczales “Metaobject Protocol” book as an example of how to do it well.
I’m wondering what the “Metaobject Protocol” equivalent is for block-based programming. Sure, we can hide the extra palette. But when do we display it? How do we indicate the the functions are special and different? And if we actually built a block-based metaprogramming system, how would we delineate that level?
Mark
16.
alanone1 | January 15, 2019 at 11:43 am
Hi MarkG
Computing itself is meta. (We are making new machines out of machines.) This is really its “powerful idea”, and the root of what is profound epistemologically about it.
Even assignment is meta (we are actually changing the meaning of a word on the fly and hoping that the change will be more beneficial and not less).
When we make a system — even the simplest kind from existing materials — we are almost always doing it because what the new system will do is not already in our tool box. We want the combination to be more than a simple sum of the parts — that’s meta — and that is a definition of “non-linear”.
As Seymour pointed out, the nifty thing for kids about this kind of “math” is that they can “feel it” that it is nifty much more strongly than most of the regular math that is shoved at them.
A new epistemological perspective that kids can feel! (Sounds like a truly wonderful thing to me.)
As I mentioned in one of my other comments, a “system” can be viewed from the outside as “a thing” and from the inside as an communicating organization of things (themselves with interiors as systems).
Even better, we can tinker with making organizations and then see that we could simplify these by drawing boundaries around subcollections that will “carve nature at its joints”. If these boundaries are actual encapsulations, then we’ve also made little worlds in and of themselves, and these can help thinking, designing and making.
We can instantiate these little worlds and use them in many places. We can put names on them, we can refer to them using pronouns, or we can just plug them into a useful place in our system.
I’m now reaching the place in WordPress where I start getting angry at not being able to come back and re-edit my comment (as I can in Quora). Not being able to do this limits what I want to try to describe about something I’m thinking about actively — because I’ll have some better examples tomorrow, and I won’t be able to add them in any reasonable way.
I would try to look at the larger picture that I outlined above, and design a scheme for kids that does much better than Scratch or Etoys, over even Smalltalk-72, which was much more successfully meta (with ~ 12 year olds and up) than either.
For Scratch … I’d like to redesign it for the purposes it is now being used for.
But …
Scratch needs to allow “hoods to be popped” in both the commands and the UI. I would pick several of the operations that could have an understandable Scratch definition.
A procedural one would be “turn”. A “functional” one could be “abs” or “*”. As MarkM noted, all that’s needed is “return v” plus a way to portray what the inside of one of these commands or operations needs to look like to make really clear where the parameters go, etc.
I would bend over backwards to use existing Scratch conventions for binding (“set”) etc and not introduce anything new (this is what we did in Etoys).
This provides a number of “worked examples” of what operations and commands are as systems of operations and commands. As you’ve pointed out on numerous occasions, these are golden for learners.
17.
alanone1 | January 14, 2019 at 2:15 am
Hi MarkM
I’m not at all against having things like names, variables, functions, procedures, and objects in childen’s programming languages. There are some very good ways to teach some of these ideas — the “drive a car” project uses one for teaching “properties” (variables) that really works well — and I called for in my comment and gave examples of better ways to teach them as “visible system components” rather than as new features.
One of the many reasons why this is of key importance is that any decent pedagogical language (I think any decent language) should allow “the hood to be popped” on anything, and what is seen should be made understandable by the system.
Scratch pretty much ignores this, but Etoys had some ideas for how to deal with some of the “hood pops”. For example, the built in procedure “turn” can be made by a procedure called “turn” which adds its input to the property “heading”. A key part of this is how to show the parameter being received and used. In a language that has assignment, one should show an assignment as part of the procedure definition, etc.
My comment here was to point out that a better language design/approach and UI than either Etoys or Scratch have, could also handle the larger idea that we are always designing and making systems, not just using a few features, and that this could dip nicely into the earlier grades.
18.
Anders Schneiderman | January 10, 2019 at 12:39 pm
Agreed! If anything, I think we need more focus on making it easier to move from a little bit of coding to a little bigger bit of coding and picking up bits of more sophisticated software engineering along the way. A smoother learning curve seems to me to be a better solution than overstuffing Scratch — and it’s even more true for non-technical adult learners (eg, budding power users)
19.
alanone1 | January 14, 2019 at 3:46 am
From the opposite direction …
As with most people who learned to program in the early 60s and before, I learned machine architectures and machine level coding on a number of machines before doing a little “higher level programming” (FORTRAN, RPG, etc). (We can imagine any number of reasons why this might not be the best route for most beginners today.)
Years later at Parc I taught various people Smalltalk, and ran into one who in the past had done a fair amount of plug-board wiring for punched cards machines. He did not want to learn a “higher level language”, as he said “because you have to believe too many pieces of magic”. He wanted nuts and bolts. So I taught him NOVA assembly code (which was a kind of RISC code and close to microcode) and for which it was easy to go another level deeper to how most things were actually accomplished on the NOVA hardware. He got this right away, and eventually became a very good all around programmer, including in Smalltalk.
My thought in those days about going “bottom up” is that the tradeoff for really good understanding of everything didn’t pay for itself in coding and design and debugging power (even with a great macro assembler to help organize everything).
It is certainly likely that bottom-up is not a good way to go for the attempts today to attract a large percentage of the population to “Coding For All” because the initial payoff in bottom-up is the joy of understanding and making machines rather than effects.
In theory, starting with a very high level language should provide many more opportunities to brush up against higher level design principles, and result in better organized programs. (But it’s not clear that this is anything like an automatic side-effect — most programs done by novices are very poorly organized and designed, and don’t seem to get much better.)
So, to return to the analogies between programming and writing and reading, it seems that a lot of work needs to be done by most learners to put more shape and design to anything larger than a few utterances.
Still, one of the biggest exceptions to the analogies between programming and writing in natural language is that most of the latter is essentially metaphorical and not easy to understand analytically — negotiation of meaning is often required — whereas one of the main points of most programming languages today is to be able to make and combine meanings mechanically to make more meanings in a predictable way (in this, it is much more like the careful usage of language in math, but with more ways to debug what’s meant).
For the general public, I think it is likely that the directions Stephan Wolfram has been taking his language designs might win out (this would be a semi-AI that is like an “automated grad student” that listens to your wishes, negotiates with you to find out just what it is that you want, and then uses its expertise to create processes that will do it). Commercial programming always lags quite a bit, but for much of what they are trying to do, they would be much better off with the “automated programmers/designers” than with the current level of non-skills today.
This is completely in line with the commercial drives to create computer versions of “servants and slaves” for everything.
For elementary school, it would very likely free up computing to be a sibling with math and science to help children understand the world in a modern — not post-modern — fashion. Math and science require a bit more of a bottom-up approach for each of their epistemological realms. But probably not all the way to set theory right off the bat (as the 60s “New Math” tried to do).
My suggestion here is that instead of worrying about computing — and especially instead of worrying about computing for getting to Python or for any vocational future — that an excellent way to get the the next good phase of “computing for children” would be to center our visions and goals on how to help them really learn “real science”, and let this redo both mathematics and computing as needed.
All three of these — to be really understood by the learners — will be more bottom up than now, and thus will need to be better scaffolded than the practices today.
20.
Ellie K | January 5, 2024 at 4:18 am
Who ARE you, AlanOne1! You are so wise! I am very late. I also have great respect for Mark Guzdial, as I have read everything I could find that he wrote about females (i.e. children and adults) learning to program.
Your findings about the results of ‘bottom-up’ programming is not what the Coding for All movement wants. That’s okay! It might be helpful, especially to male students in high school (who are very important too). I am thinking of your example of the eventual Smalltalk programmer. It won’t be for ALL boys, but it will be for some, especially those who are more ‘mechanically-inclined’, an old euphemism for the vocational path.
Your suggestion about “freeing up computing to be a sibling with math and science” is much easier to implement and thus potentially useful to boys AND girls. I know that it can be effective! When I took my first college linear algebra class, the instructor integrated it with APL because of vectors, matrices etc. I was a math major but I learned more about APL programming than linear algebra! Six years later, I was using APL at my job at IBM. (Yet I can’t get the hang of SQL now; I don’t know why.)
I gather that Scratch and Logo are intended for children in grades 3 to 6. Your suggestions (in the continued comment) about defining a variable and passing a parameter to a function remind me of calculus and even algebra. Mark L. Miller sagely commented,
Yes, exactly! Why not start at grade 8 or 9, when most students take Algebra 1? Including BASIC or Pascal with Algebra 1 would be analogous to how I was taught linear algebra. Moving along, how about learning FORTRAN to help learn calculus? I know everyone hates it, but it was excellent for non-discrete mathematics. The cognitive load aspect is taken into account with the appropriate choice of programming language. I suggest what I know but these are merely examples; you could make the best choices.
As you said so nicely, these seem like modern (not postmodern!) approaches. Would it be so terrible to wait until eighth or ninth grade to learn programming rather than elementary school? There’s so much to learn then.
21.
alanone1 | January 6, 2024 at 12:14 pm
A basic premise of modern cognitive psychology is that we “learn facets of ideas” from birth, and that how we see things later on is a combination of biological development and prior experience. One of the founders and greats of this field was Jerome Bruner (who was also a friend and long time colleague).
His take on the above is that the task of teachers is to “find the facets” (he would say “intellectually honest versions of the ideas for their age”) that the children can handle (and that will help them greatly for learning larger versions of the “powerful ideas” of humanity).
Closely examined, elementary algebra is about two main ideas (a) arithmetic and (b) equality. Young children can easily do both in a suitable curriculum. However, the typical early grades math curriculum could hardly be worse for children (and it is really at its worst when it is trying to be good).
This is a complex topic that is intertwined with both non-math people and their politics manifested in what is supposed to be an education system.
One of several good alternatives is the way Mary Laycock (who was a mathematician$) approached children’s math over the years: it was (a) real math, and (b) completely fit how children generally think.
$ https://camc.memberclicks.net/mary-laycock
22.
alanone1 | January 16, 2019 at 2:38 am
Scratch and “Functions”
This comment actually hooks onto some of the other comments that — via WordPress’s “lack of goodness” — have become too narrow for reasonable reading.
It was interesting to poke around the current Scratch webpages and the “create” invitation, which makes a Scratch instance to play with. One good addition in the UI is the “indexed infinite scroll” of Scratch code blocks. This feels much less modey than their previous UIs for this.
It is still an overly feature-laden language for something that is now being used as a tool for teaching programming (to a certain extent) and computing (to a lesser extent). The features were originally put in for the completely different goals of allowing teen-agers to make restricted kinds of dynamic media in small formats in about an hour for the Intel after-school computer clubhouses.
But let’s resist the temptation to do a new design that would be more appropriate for helping children learn “real computing”, and instead see what can be done with minimal changes to what is currently there with as little criticism as possible.
One of the definitional facilities in Scratch is “define a variable”. This has a UI that allows the programmer to define an object that shows up with the name and value of the variable — and also shows some Scratch code blocks for dealing with them e.g. “set”, “change”, “show”, “hide” …
Another definitional feature is “define a block”. This allows side-effects but can’t make an “operator” — like “abs” — because there is no “return v” block offered. But there is no reason why “return v” couldn’t be offered in this section in the exact same way that “set” is offered in “make a variable”. And one could argue that this is a good place for it because it doesn’t confuse matters by being included in the “control” section.
Another decision they made that has interesting tradeoffs for and against was not to show “set”, “change” etc until you actually make a variable. This reduces clutter, but it also reduces motivation by hiding “set”. But let’s stay with their approach here.
This would suggest that “return v” doesn’t show up until you “make a block”, and I’d make it show up both close to the “make a block” section, but also put it into the “control” section.
The other critique here is that they could have done a lot more about hints about what it means to pass a parameter (whether or not one making a procedure or “function”. For example, the simplest thing they could have done is to use the same form employed for visible variables in the heading — this establishes that there is a named thing that can be used.
I would push the discussion much further to ask whether there should be a use of “set” to take the outside-value-into-the-input and bind it to a local variable. This use of “set” could be created automatically when the parameters are being defined.
In the current version there is a glaring pedagogical bug in the nice drag and drop of parameters into code (this is that there can be multiple parameters with the same name, etc.). A lesser bug is the use of a sample value as a parameter name (this is differentiated from a constant by having the surround be circular — this doesn’t seem to be enough of a visual flag).
So: the simplest thing that could be done — and should be done — is MarkM’s suggestion to just include a “return v” block.
I personally would feel really bad if you couldn’t easily define the format of blocks with infixes. This would make a big “meta-impact” on how the kids think about what a programming language is.
A bigger deal is “safe-meta” for exploration. Some children will want to do this early (there are many stories about children finding out how to dive under Scratch to the underlying Smalltalk code).
Though I’d argue that you don’t want to find a different language underneath — just fewer deeper primitives — children should absolutely be able to safely explore the depths of both the language and the UI (any decent language should build the UI in itself. etc.).
Much of safety here has to do with putting in “fences” — that ask if you really want to do X — and having an extensive “undo” — which allows you to say “that isn’t what I wanted”. (And there is more here to be said.) In any case, the lack of these in most pedagogical languages is a mortal sin.
This is especially the case given that “undo” should be a feature in any programming language today — not just for the programming but for programming itself (this is called “possible worlds reasoning” and is a very powerful technique that should not be omitted from “coding”).
So: quite doable (but I feel really bad that Scratch is what children will imprint on as “computing” and as “programming”). Besides the lack of “meta” almost everywhere, the thing that shocked me about Scratch was that they omitted to include the wonderful particle system ideas of StarLogo that were ironically Mitchel Resnick’s best set of inspired ideas. I don’t see these as in any way optional for a beginner’s language.
23.
Mark Guzdial | January 16, 2019 at 11:22 am
This is fascinating, Alan — thanks for writing it all down.
24.
Ellie K | January 6, 2024 at 4:54 am
I realize that I am violating blog comment etiquette, but Mark Guzdial is a very tolerant man, so I will presume on his hospitality with a second comment. I will be concise.
Alan, you made several good points. First, I commend you for recognizing this:
Yes! And teachers should not rebuke them for doing so. I often found myself in that situation, and still do. It is deflating to be rebuked for curiosity and exploration, or worse yet, told that you have “broken it”. I try to be thorough, and read Turkle and Papert’s “Epistemological Pluralism and the Revaluation of the Concrete before commenting, as Mark G had linked to it in his post. It resonated with what I wrote above.
Next, it would be a fabulous idea to incorporate an undo in every programming language, as you suggested. Many languages with GUIs, e.g. my beloved SAS, supports an undo. (I do probability and statistics. SAS is closed source. Please don’t hate me.) I dislike the GUI and prefer to get at the code, and that has an undo too!
Finally, thank you for explaining ‘lack of goodness’. I have seen the expression for years but never understood it until now. I’m still trying to keep track of the meanings of ‘gaslighting’, ‘dog whistle’, ‘HODL’, CoC (code of conduct), coq (some obscure Haskell precursor), and ‘this is why we can’t have nice things’!
25.
alanone1 | January 6, 2024 at 11:55 am
Hi Ellie
What is “blog comment etiquette”?
There is no intrinsic conflict between a GUI and working directly in code. For example,
<I just found out that WordPress won’t allow me to paste in a picture here>
… It would have been of the 70s Smalltalk interface, which was the origin of the GUI style we use today and it allowed one to write code directly in a number of different ways.
SAS could have given you both. I think pondering why not could be illuminating.
26.
Ellie K | January 6, 2024 at 12:16 pm
Blog comment etiquette is not leaving three comments in a short interval of time, without any comments by other users in between. I only left two, so I wasn’t being too overbearing… I hope.
27.
alanone1 | January 6, 2024 at 12:23 pm
I don’t think “blog etiquette” makes any sense at all — especially in a really bad app like WordPress which does not allow authors to add more to their own comments when they think of more to add.
28.
Mark Guzdial | January 8, 2024 at 6:26 pm
Hi Ellie! Please feel welcome to comment as you wish. I’ve never been busier than I am now with PCAS, so I don’t post here much. I appreciate your interest and your engagement!
Alan is Alan Kay. https://en.m.wikipedia.org/wiki/Alan_Kay. He has given me valuable advice for decades, and I’m grateful that he’s here, too. And yes, he’s very wise.
29.
Mark L. Miller, Ph.D. | January 16, 2019 at 11:15 am
Imagine a world in which Scratch and Snap! are the same system but with different selections on which palettes (and even which individual blocks) are made available. (One reason why Code.org is so widely used may be that only the blocks needed to solve the current problem are presented — which I think is taking things to an undesirable extreme, though I get the reasoning there.) Since Logo was originally “Lisp for Kids,” one might think of such as system as “Scheme for Kids.” What we’d need next is a SICP Coloring Book! Seriously, though, thanks, Alan, for supporting my proposal for the 1 simple change to Scratch that could make a big improvement when it is used to teach some of the underlying ideas in programming/computing! In parallel, perhaps it is time for the next iteration of Smalltalk, with a focus on younger users.
30.
alanone1 | January 16, 2019 at 11:25 am
I think this is the right direction. I think that just combining them is not a good idea for many reasons — but that starting over and doing a comprehensive design that can grow with the kids is the way to go.
(By the way, Etoys had a very complete set of “reveal controls” for teachers to use that would allow many kinds of subsets of pretty much everything to be chosen. It even had a set of stages that gradually reduced the vividness of block boundaries to make the large programs more readable, etc.)
31.
Mark L. Miller, Ph.D. | January 16, 2019 at 11:34 am
Wow! The reveal controls concept is what I was was (somewhat inaccurately) referring to as “microworlds” earlier. I had thought it might be included in this release of Scratch actually.
p.s. Is there are currently working eToys out there somewhere that we can play with? It seems to have many treasure chests we should try to unlock and promulgate
32.
alanone1 | January 16, 2019 at 12:08 pm
The full blown version of Etoys was not supported after about 2005 when a stripped down version was made that could run on the OLPC XO. It was played with a lot from about 1997 or 1998 through 2004-5, and used by a lot of children around the world, especially in Japan. The OLPC version had many of the customizable features, but not all of them, but was also used by the children around the world who used the OLPC XO.
However, Etoys — like its offspring Scratch — originally had a very narrow scope, and important parts of this were not widened when the scope of Etoys moved to schools.
One of the experiments we tried ca 1997 was to see what a minimal programming feature model with a maximal environment model could do with children and their parents around the ages of 8-10. We defined about 50-70 “neat” projects that could be “nicely done” with Etoys resources. This was quite successful.
For the widened scope part of this research, something like “a Smalltalk that could really reach down to kids with block programming” was needed. (In fact, Jens Monig did do a whole block programming Smalltalk, and we experimented also.)
But, again, this really required a full design all the way up, and we couldn’t get funding to do it. The other project we’d been thinking about doing was STEPS (which actually overlaps some of these concerns), and we did get funding to do that.
I helped the Scratch folks get their funding, and was really hoping that they would get to the next level after Etoys. Instead, they also did a limited vehicle with different design contraints.
I think what they did accomplish — and no mean feat! — was to make a programming environment and the packaging for it that allowed both learning and social media display on the Internet. I think this really worked extremely well (and a lot of the good quality control and design work was due to Natalie Rusk).
33.
Code Smells might suggest a different and better Notional Machine: Maybe students want more than one main() | Computing Education Research Blog | March 18, 2019 at 7:00 am
[…] There is a body of research that looks for “code smells” in Scratch projects. “Code smells” are characteristics of code that suggest a deeper problem (see Wikipedia description here). I have argued that these shouldn’t be applied to Scratch, that we’re confusing software engineering with what students are doing with computing (see post here). […]
34.
Programming in blocks lets far more people code — but not like software engineers: Response to the Ofsted Report | Computing Education Research Blog | June 20, 2022 at 7:01 am
[…] design and conditioned execution for that task? They’re not doing complicated coding, but the little bit of coding that they’re using is powerful and is engaging for students — and relatively few students are getting that. […]