in what mode does the bee code?

Bees are smart coders, developed through a painstaking evolutionary process. Bees have been around for 120 million years.

We humans study bees, can learn from them and model their behaviour. Humans (Homo sapiens) have been around for 200,000 - 300,000 years.

In this blog I'll just show the bees behaviour and my emulation of it. In the next blog I'll go into educational detail. I should acknowledge BirdBrain Technologies for their assistance.

Attenborough explains the bee's waggle dance. To watch in YouTube go here



Here's the simulation I did to partly imitate the clever bee:

the teaching of coding

The approach I advocate here emphasises developing of personal, meaningful digital artifacts through collaboration. I also discuss known problems in the teaching of coding and suggest remedies.

An article of this nature will never be finished. At this stage I feel it is good enough to publish. The writing and redrafting process has helped clarify my own thoughts and how to present them. It may help others. I’ll put a version up on Google Docs, here, for anyone who want to develop it further or critique it.

GOAL: THE COMPUTER AS A MEDIUM FOR SELF EXPRESSION

On day one tell the students that their main task will be to “Design and build a collaborative digital project with personal and / or social relevance”

A rich, holistic task like this will achieve many of the dry, technical points on the ACARA checklist. I’ve included the ACARA goals for Years 7-8 as an Appendix.

THE LEARNING ENVIRONMENT

The teachers role is to tap into already established existing interests of the students and guide that in a direction where digital things are progressively enjoyed and mastered. If technology is seen to relate directly to personal life then this provides a tremendous incentive to learn it.

A good general theme is Children as collaborative software designers (after Idit Harel). Keeping it simple begin with Scratch and the Collabrify suite. Add in tangibles such as micro:bit if and when the time and opportunity present themselves. It depends a lot on how your school organises its computing resources. eg. in my current school Year 7s only receive 2 lessons a week for one term. I can argue for whole school reform to integrate computing into the curriculum but it probably won’t happen.

TANGIBLES

CSER has a lending library of class sets of tangibles: Beebot, Sphero, Ozobot, Makey Makey, LilyPad, Little Bits ‘Rule Your Room’, Little Bits Arduino, Dash & Dot, Bluebot, Micro:bit. They give preference to those who have completed their MOOC courses.

Kids have mobile phones and MIT App Inventor can be used to develop apps for Android phones. But given the reality that kids exposure to computer coding in Primary school has probably been patchy I suggest for Year 7s start simple with Scratch and the Collabrify suite and use programs such as App Inventor or activities with micro:bit, or whatever is available, as extension activity for those who have a strong background and can work independently.

PERSONAL, SOCIAL, COLLABORATIVE PROJECTS

What do kids like? Drawing and modifying pictures, music / sounds, games, socialising, building things, achieving something. The project, “Design and build a collaborative digital project with personal and / or social relevance”, taps into these already established behaviours and aims to develop them in the computer medium.

On day two introduce a Designer’s Notebook and Critique groups.

Designer’s Notebook: Preferably this should be online and public so the teacher and other students can read and comment on it.
Start of lesson: Write your plans and draw a picture of what will happen
End of lesson: Write about Progress, Problems, Solutions, Who I helped, Who helped me.

If and when social and emotional comments appear in the notebooks then this should be encouraged, not discouraged. Building a fully sharing community is just as or more important and helps to build the technical mastery of coding.

Critique groups: Projects need an audience for both appreciation and suggestions for improvement.

The metaphors have further evolved since Seymour Papert’s time. He coined the phase “objects to think with”; this has evolved into “objects to think and share with”. He coined the phrase “low floor, high ceiling”; this has evolved into “low floor, wide walls, open windows, high ceiling” (Kafai and Burke, pp. 55, 59)

PROJECT IDEAS

If you put out a variety of project ideas then that will send the right message, that we want our students to choose something with personal meaning:

• Add on yourself projects – eg. the initiator posts a picture of a dozen eggs and has put a face on one of them. He/she invites remixers to continue adding faces to the eggs. Kafai and Burke point out that this type of project usually has a low skill level coding requirement but they help build community involvement. Other examples include colouring in projects (with a prize for the best entry), add your icon/avatar jumping on a trampoline etc.
• Games, including Games with a story (RPGs)
• More complex group projects, eg. I took a copy of a poster, Know Your A-Z: Prevent violence against women – challenge gender stereotypes and promote respect, a different message for each letter of the alphabet; different characters and animals in the rooms of a castle
• How to projects: Tutorials which explain how to achieve a certain feature in Scratch, eg. a scrolling screen of the type seen in Mario games
• Seed project – the teacher could provide a poor version and ask students to improve it, possibilities include a rocket taking off, photosynthesis, maths drill, how to drive a car at an intersection, a vacuum cleaner which make white marks where it goes but doesn’t clean the room properly (this last one from Kafai and Burke, p.83)
• Cross age tutoring projects – years ago I duplicated the Idit Harel cross age tutoring children designers fraction project. Here.

COLLABORATIVE SOFTWARE

Blogs, wikis and Google Docs are available on many school systems. But improving on this is the Collabrify software suite (intended for Years 1 to 7) developed by Elliot Soloway and Cathie Norris. This includes Writer (co­-create documents that include text, pictures, and video), KWL (Know, Want, Learn), Flipbook(drawings or “flipbook” style animations), Chart (collaboratively create a chart and graph its data) and Map (for concept maps).

REMIX

The Scratch site has a remix feature where you are encouraged to take the work of others and modify it. This is something I want to encourage since it mirrors real life collaborative software development. But it does make it difficult to assess kids on the basis of the quality of their finished software since they have built on the work of others. The answer here is develop other asssessment parameters.

Kafai and Burke have a discussion in their book (p. 86), is remix a crutch or a spur?

KNOWN PROBLEMS

Coding is a complex activity and initially can be overwhelming to newbies. There needs to be some clarity about known problems in teaching novices to code. These are:
Design – I don’t know what I want the computer to do
Selection – I think I know what I want the computer to do but I don’t know what to use
Co-ordination - I think I know what things to use but I don’t know how to make them work together
Use - I think I know what to use but I don’t know how to use it
Understanding - I thought I knew how to use this, but it didn’t do what I expected
Information - I think I know why it didn’t do what I expected, but I don’t know how to check

Some of these problems have been alleviated through the development of block code languages. Others need to be specifically addressed.

BLOCK CODE

Scratch is now widely used in schools. This alleviates some of the above problems, as follows:

Selection – Picking a block from a pallete is far easier than remembering a word (recognition over recall)
Co-ordination – Blocks make assembling code easier by providing constrained direct manipulation of structure, eg. two incompatible concepts do not have connecting parts
Use – Coding has a high cognitive load for new programmers. Blocks reduce the cognitive load by chunking code into a smaller number of meaningful elements

What about the other three known problems (Design, Understanding, Information)?

DESIGN

Task: “Design and build a collaborative digital project with personal and / or social relevance”

Initially Design is approach through teacher modelling, discussion and recorded in the Designer’s Notebook.

The Designer’s Notebook includes this information:
Start of lesson: Write your plans and draw a picture of what will happen
End of lesson: Write about Progress, Problems, Solutions, Who I helped, Who helped me.

This is a record of “low level” design and collaboration activity.

Teacher modelling (the principle here is eat your own dogfood): For example, I have designed three versions of a computer game – bad pong (only a few features, boring to play), ok pong (more features such as randomisation of ball movement and scoring) and wicked pong (select backgrounds, unpredictable ball movement, high score, bat shrinks as your score increases). This provides various options for discussion with students. What are your favourite games? What are their design features? Split into groups and do a KWL (Know, Want, Learned – the learned comes later). Depending on how the class is progressing at some stage introduce some design tools (start / end, process and decision) to aid the process.

Some thoughts about the place of high level design in the learning process.

Simple projects have simple design.
eg. draw a square:
to square
pen down
repeat 4 [fd 100 rt 90]

Novices have to be carefully taken through this (tell the robot what to do, etc.) and yes, write it down. But conceptually, it is not particularly complex. With each increase of complexity the difficulty of holding it in your head increases. The complexity versus "grasping it" curve starts simple but is not linear. When you get to a game of pong which keeps score and stores and displays high score then you need to keep track somehow outside of the code itself.

Simple code can be written without formal design criteria. The Scratch course works more along the guidelines of play first, do something of personal interest, and later, when you want to build something more complex then design becomes necessary.

In the Creative Computing Curriculum Guide (Scratch 3.0) project planning is stressed more towards the end of the course (section 6).

For the sake of further discussion we could divide our students into those who are inclined to be top down planners and those who are inclined to be bottom up tinkerers. The way things are normally done in schools may disadvantage the bricoleurs / tinkerers. See the Epistemological Pluralism article in reference for more detail about this. As teachers of computing our prejudice may be to prefer the top down planning approach because it is “the way things are done” by professionals and it makes it far easier for us to keep track of what our students are doing for helping and assessment purposes.

IMHO one way to kill interest in some students is to put too much emphasis on top down planning and top down planning tools.

I think a reasonable compromise here (and one which is consistent with the Agile Programming approach) is this development sequence, as suggested in the App Inventor book:

1. initial ideas through group work and dialogue with teacher for desired project. Who is your audience and what features do they want?
2. build a simple prototype
3. follow the incremental development principle – code a little, test and repeat
4. at this stage produce a formal design

UNDERSTANDING and INFORMATION

Understanding - I thought I knew how to use this, but it didn’t do what I expected
Information - I think I know why it didn’t do what I expected, but I don’t know how to check

The experts, such as Juha Sorva, are advising here that the ability to trace code at run time should be explicitly taught. They also advise that Parson’s problems help to teach coding. Parson’s problems are where the blocks are provided to achieve a given task and the student has to put them together correctly.

I couldn’t find any reference to anything called Parson’s problems in the Scratch forums but did find something similar: Debug’ems, Complete’ems and Explore’ems! See reference.

Finally, students should be required to add comments to their code.

WHAT THIS ARTICLE LEAVES OUT

I support whole school reform to integrate computing into the curriculum. This idea has been around for 30+ years but hasn’t happened yet.

Tangibles. I think the new tangibles on the market are important and it’s a great idea that CSER has setup a lending library. I’d like to see more work on the evaluation of these tangibles.

I haven’t used slogans like “computational thinking”, which have become very popular. Some authors (diSessa, Guzdial) have critiqued this and I agree with their critiques. I haven't talked directly about teaching abstraction, which is part of the same bag of worms.

ACARA guidelines. Remember the saying, “School is like going to the world’s finest restaurant and being fed the menu” (Murray Gell-Mann). ACARA is cardboard, like that. Our job, as teachers, is to bring the cardboard to life.

REFERENCE
David Bau, Jeff Gray, Caitlin Kelleher, Josh Sheldon, And Franklyn Turbak. Learnable Programming: Blocks and Beyond (2017)

Beck, Kent. Manifesto for Agile Software Development.

Karen Brennan, Laura Peters, and Alexa Kutler. Creative Computing Curriculum Guide (Scratch 3.0)
 
Kafai, Yasmin. From Computational Thinking to Computational Participation in K-12 Education
 
Kafai, Yasmin and Burke, Quinn. Connected Code: Why Children Need to Learn Programming (2016)

Kerr, Bill. Educational Software: Designed By Kids For Kids (1994)

Ko, Andrew; Myers, Brad; Aung, Htet Htet. Six Learning Barriers in end user programming systems (2004)

Cathie Norris, Elliot Soloway, Jennifer Auten, Ronda Duran, Kimberly Lee, Sr. Rebecca Mierendorf, Cheryl Zuzo. We Collabrify: FREE Collabrified Apps That Support Synchronous Collaboration (2015)

Papert and Turkle. Epistemological Pluralism (1992)

Scratch Debug’ems

Jean Griffin, Quinn Burke, Elliot Kaplan. Debug'ems and other Deconstruction Kits for STEM learning (2012)

Sorva, Juha. Notional Machines and Introductory Programming Education (2013)

Wolber, David; Abelson, Hal; Spertus, Ellen & Looney, Liz App Inventor 2: Create your own Android Apps free online

APPENDIX

ACARA
YEAR 7 AND 8 CONTENT DESCRIPTIONS
Digital Technologies Knowledge and Understanding


Investigate how data is transmitted and secured in wired, wireless and mobile networks, and how the specifications affect performance (ACTDIK023)

Investigate how digital systems represent text, image and audio data in binary (ACTDIK024)

Digital Technologies Processes and Production Skills

Acquire data from a range of sources and evaluate authenticity, accuracy and timeliness (ACTDIP025)

Analyse and visualise data using a range of software to create information, and use structured data to model objects or events (ACTDIP026)

Define and decompose real-world problems taking into account functional requirements and economic, environmental, social, technical and usability constraints (ACTDIP027)

Design the user experience of a digital system, generating, evaluating and communicating alternative designs (ACTDIP028)

Design algorithms represented diagrammatically and in English, and trace algorithms to predict output for a given input and to identify errors (ACTDIP029)

Implement and modify programs with user interfaces involving branching, iteration and functions in a general-purpose programming language (ACTDIP030)

Evaluate how student solutions and existing information systems meet needs, are innovative, and take account of future risks and sustainability (ACTDIP031)

Plan and manage projects that create and communicate ideas and information collaboratively online, taking safety and social contexts into account (ACTDIP032)

rationale for a computer literate society (Mark Guzdial)

Requirements for a Computing Literate Society slides by Mark Guzdial. Mark's blog is here. I particularly liked slides 6, 7, 8 (rationale for teaching of abstract processing), 9, 13, 14 (Lake Wobegon effect: we don't know as much as we think we do), 23, 25, 27 (media computation as a motivating path to learning computer science) and 45 (conclusion)

Alan Perlis argued that all students should learn to program because:

• Computer Science is the study of process. Automated execution of process changes everything including how we think about things we already know (slide 6)
• The purpose of a course in programming is to teach people how to construct and analyze processes ... A course in programming is concerned with abstraction: the abstraction of constructing, analysing and describing processes ... The point is to make students construct complex processes out of simpler ones ... A properly designed programming course will develop these abilities better than any other course. (slide 7)

The Power and Fear of Algorithms. The Economist (Sept., 2007) spoke to the algorithms that control us, yet we don’t understand: Credit Ratings, Adjustable Rate Mortgages, Search Rankings. C.P. Snow foresaw this in 1961. Those who don’t understand algorithms, can’t understand how the decisions are made:

“A handful of people, having no relation to the will of society, having no communication with the rest of society, will be taking decisions in secret which are going to affect our lives in the deepest sense.”

Build Your Own Blocks

Build Your Own Blocks (BYOB) is an extension to the visual drag and drop programming of Scratch. It adds custom blocks, recursion, first class lists and procedures to the original.

The developer is Jens Mönig with design input and documentation from logo legend Brian Harvey.

There is a make a block shape in the Variables section. When you click on it an easy to use block editor comes up. First up, I made a block that draws squares, then followed up with a hex block and a star block. Here they are:

I am following a sequence suggested by Jens and Brian in their paper, Bringing 'No Ceiling' to Scratch: Can one language serve kids and computer scientists?

The next step is to draw a V shape with a randomly chosen decoration at each end. In a text based logo language this would look like:

to v
left 45 forward 50
run pick [square hex star]
back 50 right 90 forward 50
run pick [square hex star]
back 50 left 45
end

The tricky bit here is how to implement the line: run pick [square hex star] visually. Initially, I couldn't figure that out but my friend Tony Forster helped me with it:

And here is the whole v procedure, in visual block form:

This procedure draw shapes like this, (running it 3 times with different starting positions):

The next step illustrates how to do recursion in BYOB! Recursion means that a procedure calls itself. Here it is:

There are a couple of places where vee might randomly call vee causing the procedure to loop back on itself. Since it is random (item any) then the result are varied and unpredictable. Here are a couple of the more complex results:

As well as the paper by Jens and Brian make sure you read the manual which comes with the download, too.

Jeff Elkner's python resources for school

Using Python in a High School Computer Science Program - Year 2 (2002 Python conference paper)
Part I: Reflections From the Classroom by Jeffrey Elkner

This paper is refreshingly frank and honest about the real difficulties (and also the real potential) involved in introducing python programming to a school environment

It's really very important that the kids have a smooth start in a consistent environment (and in practice this seems almost impossible to achieve)

You need good resources, such as a good textbook.

The students need to see that the skills they are developing are relevant to some close at hand real world situation

Even with a smooth start some of them are going to find it hard and so we need to be on the alert for new ways to retain them (such as the LiveWires materials)

It's hard to get girls involved

Great to see that Jeffrey Elkner understands and is systematically addressing these issues. As well as the above article see his Open Book Project, his GASP python course and his adaptation of the How to Think Like a Computer Scientist to python.

scratch interview

All this Scrathin' (podcast 42 minutes)

Chris Betcher (NSW educator) interviewed Peter Ruwoldt, Grant High IT co-ordinator (Mt Gambier) and myself about Scratch, yesterday afternoon . Peter does most of the talking including a description of his Scratch Day involvement this year. The purpose was to spread the word about Scratch and ways to promote it further.

python programming competition

The School of IT at the University of Sydney is running a python programming challenge for high school students over 5 weeks in term 3, 2009 - starting on Monday 10 August.

The NCSS (National Computer Science School) Challenge is designed to cater for both beginners and advanced students. Each week, a set of Python teaching resources for either in-class or self-directed learning will be distributed to participants via email and online. A set of challenge questions testing this material will also be distributed. Each week's challenge set will range from relatively easy to extremely challenging allowing beginners to progress at their own rate whilst extending gifted students. The challenges will increase in complexity as more and more programming concepts are covered over the 5 weeks.

Teachers can enter too. I have participated on the past two years and wrote a review two years ago. Note that the competition has changed since then; it didn't have the beginners and advanced sections back then.

taking guzdial seriously

My plans to transition kids from scratch to python have not been particularly successful so I'm thinking of giving the Mark Guzdial approach a trial - using python to tweak multimedia

Kids find the transition from the scratch visual drag and drop to python only text based daunting, or, more likely they just get bored without the multimedia. It's a huge daily problem for practicing teachers to walk the line between engagement and rigour. The Guzdial approach would keep some visuals, sounds, movies etc. involved (as outputs) for student text based programming inputs. It might work.

The Georgia Tech site is a mess but I eventually worked out that you can get enough materials to get started for no cost

There is a free draft copy of his book downloadable as a pdf from this page:
http://coweb.cc.gatech.edu/mediaComp-plan/26

It includes chapters about:

• Ch 2. Sounds
• Ch 3 Pictures
• Ch 5. Files
• Ch 6 Text
• Ch 7 Movies

This draft is fairly similar to the one you can buy: Introduction to Computing and Programming in Python: A Multimedia Approach
From the same link you can grab the version of python they use (jython) and also media samples to work with

The draft book explains:

"You’ll actually be programming using a tool called JES for “Jython Environment for Students.” JES is a simple editor (tool for entering program text) and interaction space so that you can try things out in JES and create new recipes within it. The media names (functions, variables, encodings) that we’ll be talking about in this book were developed to work from within JES (i.e., they’re not part of a normal Jython distribution, though the basic language we’ll be using is normal Python)."
- page 22

The direct link for media samples (pic, sound etc. files) which fit the exercises in the book) is http://coweb.cc.gatech.edu/cs1315/814

I have successfully setup the Jython environment and completed some introductory exercises (recipes) from the book.

Let us know if you are interested in experimenting with this approach and we can compare notes. Forward on to others if you think they might be interested too. I see it as worthwhile to pursue a variety of pathways aimed to switch students and teachers onto python programming.

from painting to programming, with Leonardo

Mark Guzdial quotes Leonardo da Vinci (1452-1519) about painting and then makes an imaginative leap to transfer this to an argument in support of programming, (with typos corrected):

"He who despises painting loves neither philosophy or nature. If you despise painting, which is the sole imitator of all the visible works of nature, you will be certainly despising a subtle invention which brings philosophy and subtle speculation to bear upon the nature of all forms- sea and land, plants and animals, grasses and flowers…"(the da Vinci quote)

If programming, especially object-oriented programming, is about creating a simulation of the world in silico, then what da Vinci says about is also true about programming. Programming really is about creating an imitation of nature. It really is a philosophical reflection on the nature of forms and behavior. To program is to paint a working model of the world, in silicon.(Guzdial's reflection)
- A DaVinci argument for programming

This is good philosophical sweep but could be even better. Programming is not just about imitating nature but also extending nature to new worlds.

I looked up the Leonardo quote and think a fuller version is better still:

HE WHO DESPISES PAINTING LOVES NEITHER PHILOSOPHY NOR NATURE.

If you condemn painting, which is the only imitator of all visible works of nature, you will certainly despise a subtle invention which brings philosophy and subtle speculation to the consideration of the nature of all forms—seas and plains, trees, animals, plants and flowers—which are surrounded by shade and light. And this is true knowledge and the legitimate issue of nature; for painting is born of nature—or, to speak more correctly, we will say it is the grandchild of nature; for all visible things are produced by nature, and these her children have given birth to painting. Hence we may justly call it the grandchild of nature and related to God.

Taken from The Notebooks of Leonardo da Vinci edited by Jean Paul Richter, 1880

So, as well as a simulation of nature, programming is a grandchild of nature itself. In our modern Darwinian view, Turing's brain and all the other brains that have dreamed up programming languages are a grandchild of nature along with the physical materials that make up a computer. And in this generation we have moved from visible things to invisible things as well (the bits or electrons which underlay modern day virtual tools). This medium is more powerful than painting.

Just a slight edit of Mark Guzdial's imaginative leap. He has done the hard work here.

Inform 7

I've been playing with inform 7. It is very interesting and I think I'll be using it in 2009. I'd also like to show it to some English teachers and get their reaction.
http://www.inform-fiction.org/I7/Inform%207.html

"Inform is a design system for interactive fiction ... In place of traditional computer programming, the design is built by writing natural English-language sentences"

To make sense of it I had to read Chapter 2 of the Help. My initial unguided effort of "The cat sat on the mat" produced an image of broken cogs and a problem analysis. The Help explains that you have to create a world first by teaching the program where and what everything is using assertion statements in the present tense:

The cat is an animal.
The bathroom is a room.
The mat is in the bathroom.

"The cat sat on the mat" still doesn't work but I'm getting there.

Some analysis at the psychology of planning interest group:
http://www.ppig.org/newsletters/2008-10.html#inform

Here is a quick start, from Brian Slesinsky:
http://slesinsky.org/brian/code/fun_with_inform7.html

patching turtle art

Walter Bender is attempting to bridge the gap between teachers and developers:

Sugar Digest 2008-09-22 (September archive IAEP):

Some teachers in Uruguay are teaching the Pythagorean Theorem and were stymied by the lack of a square root function in Turtle Art. They wanted to demonstrate that the length of the diagonal of a square is equal to the square root of the sum of the square of each side. In pseudocode, they wanted to build the following construct:

repeat 4 (forward 100 right 90)
right 45
forward sqrt ((100*100) + (100*100))

Lots of alternatives were discussed, including using Dr. Geo. My favorite comment was from Pato Acevedo, who said:
[Modo Irónico on]
Claro, no puedo entender como fue que Pitagoras "descubrió" su famoso Teorema si en su epoca no existian calculadoras
[Modo Irónico Off]

Google translate:
[Ironic mode on]
Sure, I cannot understand how that was Pythagoras discovered his famous Theorem in his time if there were no calculators
[Ironic Mode Off]

But eventually—albeit with some intervention on my part—the discussion turned towards how to modify the Turtle Art activity. I put together a tutorial with the hope that not only would I be satisfying the immediate needs of the teachers, but also, showing them that in fact they could, themselves, make the necessary changes to the program to meet their needs. I am hoping that I didn't make it too easy for them and that some of them will risk making changes—creating new instruments ... A dialog between teachers and developers has begun. The next step is for some of the teachers to become developers.

I left this comment on the IAEP (Its an education project) list:
The idea of building a bridge for that small percentage (I agree with rob's figures) who want to be developers is a good one

insert: Rob Costello's figures were: (<1%) of teachers who would have the technical confidence/background/interest to learn /apply this (and maybe 0.01 % would already possess the skills)

I've asked a friend over to talk me through Patching_Turtle_Art. I'm lucky to have such a friend, otherwise I would have to ask dumb questions in public, which is not good for teacher ego since teachers are meant to know things already :-) I would identify fear of looking dumb as a major obstacle to these bridging explorations.

Some educators have written about what it means to join a community - what does it actually mean to be a scientist, a basketball professional or a software developer? eg. James Gee wrote a book (What video games have to teach us about learning and literacy) about how computer games could be used in this way. He identifies these elements of joining what he calls a semiotic domain:

1. we learn to experience the world in a new way: see, feel and operate on
2. we gain the potential to join a new social group, a new club
3. we gain the resources that prepare us for future learning and problem solving in a new domain and perhaps related domains

He's trying to draw a distinction between simple knowledge and being part of a community of knowledge, the latter being the real deal

When I read through walter's account, already knowing a little bit (but not a great deal) about programming, python, logo, turtle art, visual programming I still have really basic questions to ask - things that are so transparent to developers that it may not occur to even think of them as questions or problems that have to be overcome before being engaged in this activity:

• Where do you find things (python files, source code)
• Which things do what? How does walter know which python files have to be tweaked?
• Who do you communicate with? (I didn't know that Brian Silverman was the maintainer and didn't know his email)
• How do you program more advanced stuff in python, eg. using lambda?
• What is FOSS etiquette, how do you go about learning to be a member of this community?

Due to the reality of being a teacher (lack of time, large classes, the need to keep kids busy on task, schools and communities dominated by propriety software) all of the above is problematic - but as rob says a small % of teachers and a bigger percentage of students are open to it.

scratch resources

This page (teaching children computer programming by using scratch) on kidslike.info contains a number of links to good Scratch resources, the best of which I'll summarise below

1) Programming concepts and skills supported in scratch (pdf) (doc)
What problem solving, project design skills, fundamental ideas about computers and programming, and specific programming concepts does Scratch support (and for the latter does not support)? This is an excellent summary, highly recommended, you need to download for the examples (code snippets) provided too, which are really good. Also note this discussion thread on the Scratch forum about this document, especially the comments by kevin karplus and responses by natalie, the document author, to his suggestions

Scratch supports these Specific Programming Concepts:
sequence, iteration (looping), conditional statements, variables, threads (parallel execution), synchronisation, real-time interaction, boolean logic, random numbers, event handling, user interface design

Scratch does not currently support data structures (arrays, etc.), procedures and functions, recursion, inheritance, defining classes of objects, exception handling, parameter passing and return values, text input, file input/output

2) Scratch Programming Projects
Ten excellent projects described in just the right amount of detail, with requirements and extras:

1. "Chasing/Eating" (Pac Man Type Game)
2. Red Light/Green Light
3. Pong
4. Target Game
5. Communication Project
6. Animation of a short story
7. Virtual Musical Instrument
8. Virtual Board Game
9. Basic Space Target Game
10. Shape Drawing Robot (Polygon Robot)

3) Shark eats fish
Introductory tutorial, clearly explained with screenshots

4) Comparison of different languages (thread in Scratch forum)
This comment by pkimelma presents a well thought out sequence for teaching Scratch using a games theme.

Other comments in this thread compare Scratch with Phrogram (which has 3D graphics), Alice, Starlogo and others.

5) Kevin and Abe Karplus Scratch page looks to have a nice collection of scratch exemplars

the importance of visual programming

the importance of visual programming by Detha Elza

Detha finds scratch the best place to start young kids, outlines some of its higher order limitations expertly, rejects game maker because its Windows only, finds eToys inpenetrable, mentions Bots and looks at how to make python programming more accessible. Also discusses Quartz Composer which I've never used. It's a great blog.

I like his succinct outline of scratch limitations:

It also has some pretty severe limitations: no user-defined blocks, no return values, no file interaction (so no high scores), no network interaction, no dynamic object creation, the program cannot draw on sprites (only on the background), no string variables or any real string handling. It is a great environment for learning to think creatively within its constraints, but my kids also bump up against its limits pretty quickly.

one problem with scratch

In scratch I can't see any way to name your scripts. Unless I am missing something it can't be done.

This makes the classic, beautiful and elegant Barry Newell's turtle confusion puzzle sheet - my favourite introduction to turtle graphics - far more difficult to implement

I love Barry's puzzles because they start simple and scale to complex in the most deliciously, elegant fashion. He does this by using the earlier shapes as building blocks for the later shapes

For instance once you can draw a square with the cat starting and finishing in the middle (a centre-gon) then variations are possible by drawing smaller squares or rotating the cat before drawing same size squares


The scratch code shows how to draw one centred square.

In other versions of logo (microworlds, mswlogo) once you have the code for the centred square as a named procedure which can accept variable inputs then you can re-use the code elegantly to draw more complex shapes.

to twosquare
csquare 100
csquare 60
end

to rotatesquare
csquare 100
right 45
csquare 100
end

This elegance is not possible in scratch.

However, I did manage to complete one of Barry's more advanced shapes in scratch (number 38) which is a centred square rotated 9 times

using this scratch code:

So, the epistemological issue here is using names to blackbox code in order to write more elegant (clean) solutions to more complex problems.

Also there's no turtle in the default animal shapes. Outrageous :-) I miss that turtle. Mitch, can't you put it back in.

reference: Turtle confusion: Logo Puzzle and Riddles (1988) by Barry Newell

smalltalk: philosophy, metaphor, semantics, syntax

Programming languages can be categorized in a number of ways: imperative, applicative, logic-based, problem-oriented, etc. But they all seem to be either an "agglutination of features" or a "crystallization of style." COBOL, PL/1, Ada, etc., belong to the first kind; LISP, APL-- and Smalltalk--are the second kind. It is probably not an accident that the agglutinative languages all seem to have been instigated by committees, and the crystallization languages by a single person.

Smalltalk's design--and existence--is due to the insight that everything we can describe can be represented by the recursive composition of a single kind of behavioral building block that hides its combination of state and process inside itself and can be dealt with only through the exchange of messages. Philosophically, Smalltalk's objects have much in common with the monads of Leibniz and the notions of 20th century physics and biology. Its way of making objects is quite Platonic in that some of them act as idealisations of concepts--Ideas--from which manifestations can be created. That the Ideas are themselves manifestations (of the Idea-Idea) and that the Idea-Idea is a-kind-of Manifestation-Idea--which is a-kind-of itself, so that the system is completely self-describing-- would have been appreciated by Plato as an extremely practical joke ...

I recalled the monads of Leibniz, the "dividing nature at its joints" discourse of Plato, and other attempts to parse complexity. Of course, philosophy is about opinion and engineering is about deeds, with science the happy medium somewhere in between. It is not too much of an exaggeration to say that most of my ideas from then on took their roots from Simula--but not as an attempt to improve it. It was the promise of an entirely new way to structure computations that took my fancy. As it turned out, it would take quite a few years to understand how to use the insights and to devise efficient mechanisms to execute them.
- alan kay, the early history of smalltalk

Most books on programming that I have seen don't include much in the way of philosophy or metaphor. They seem to be filled with detailed definitions and techniques.

But from the alan kay quote above it's clear that Smalltalk, the first OOPs language drew heavily from philosophical principles - the monads of Leibniz, "dividing nature at its joints" from Plato. And that this approach leads to a more elegant and internally consistent programming language ("crystallization of style"), rather than a mix of human memory intensive bits and pieces ("agglutination of features")

Maybe we would be better off today if philosophy and also the use of metaphor was taught side by side with programming?

<message receiver><message>
<receiver object><message>
<message receiver><message selector (optional message arguments>

Messages trigger methods in receiving objects

The above is the basic structure of smalltalk semantics. This initially appears easy to follow but for me it became confusing at the level of specific examples

100 + 200

In this case 100 is a message receiver, + is a message selector (binary type) and 200 is an argument for +

Both 100 and 200 are SmallInteger class instances

I found two things difficult to understand (counter intuitive) about this example:
1) Why was + being called a selector, ie. what was it selecting?
2) The 100 and 200 which are similar types of things are behaving in different ways in the example. The 100 is a message receiver and the 200 is an argument to the + message selector

This sort of thing frustrates me because in the end I'm reduced to rote learning through not really understanding the underlying meaning of the way in which smalltalk was designed. Now thanks to help from some experts I have an explanation.

The metaphors that work here are:
An object (which has various properties) receives a message which tweaks one of those properties

Or a language metaphor:
The subject (which comes first) is directed by the different parts of the rest of the sentence (verbs, etc.)

Message selectors (such as +) are called selectors because they select properties from the receiving object. As an object myself, I can visualise and personalise this quite easily. If someone comes to me and delivers a message then the particularity of the message switches on (selects) certain parts of my mind, ie. accesses particular properties of my mind

I don't really need to know the details of the SmallInteger class to appreciate this, just that the + message selector will trigger something inside that will enable it to complete the task of adding +200 to 100

Another thing that confused me was finding the right metaphor to explain this particular thing. Another smalltalk metaphor is the biological cell, that the contents of the cell are protected or encapsulated and that they respond to messages from outside.

This metaphor is great for helping to understand encapsulation and complexity - cells can diversify and combine to create complex organisms. But it didn't help me explain why + was called a message selector. However, the object and language metaphors did help here. So you need to know the right metaphors for the particular task at hand.

I'll round this out a bit more by using some other examples, mainly from Stephane Ducasse's book, Squeak: Learn Programming with Robots

There are 3 types of messages - unary, binary and keyword

Unary: pica east
"pica" (robot object) is the message receiver. "east" is the message selector. It's just like someone approach me and says, "turn east" That selects the part of my mind that thinks about directions.

Binary: 100 + 200
Already discussed

Keyword: pica go: 100
"pica" (robot object) is the message receiver. go: is a keyword message selectors, they accept arguments (100). So the message go: 100 is sent to the robot.

Keyword with multiple arguments:
pica polygon: numberOfSides size: sizeValue
"pica" (robot object) is the message receiver. The method or message selector is the double barreled polygon:size: (counter intuitive initially). The arguments are numberOfSides and sizeValue

Another Keyword with multiple arguments:
33 between: 30 and: 50
33 is the message receiver. The method or message selector is the double barreled between:and: The message arguments are 30 and 50

reference:
Ducasse, Stephane. Squeak: Learn Programming with Robots (2005) amazon, bots inc

The Monadology by Gottfried Wilhelm Liebniz

The Problem of Universals(philosophical essay)
"Plato was clearly a Realist about universals. His most famous metaphor for the reality of universals was to say that real universals "cut nature at its joints" (Phaedrus 265d-266a). He compares the task of definition to the job of being a butcher. The clumsy butcher just hacks things up in any old way, but the expert butcher deftly slices the animal at its natural joints, neatly separating naturally distinct segments of the animal."

when kids program visually in etoys / squeak what is happening programatically under the hood?

My goal here is to understand OOPs and how it is connected to visual programming from a practical perspective. This is putting some meta issues of the meaning, history, philosophy and importance of OOPs to one side, temporarily.

When you program in etoys you first draw something, then you convert it to an object, then you display a Viewer which enables you to observe the properties (heading, x position, y position etc.) and write scripts for the object. You can also produce a second object and then pass variables between objects. For example, you can pass the heading of a rocket's steering wheel from the steering wheel to a script which belongs to the rocket.



There is stuff happening here which I haven't seen in other programming systems. What other system enables you to visually pass a variable from one object to another and then lets you observe it running and change it while it is running? What is about Squeak / Smalltalk that makes this possible when it is apparently not possible in other programs like Game Maker or Flash?

Specifically, I want to understand what is happening behind the scenes. What classes are involved? And in connection to an earlier blog about OOPs: Is etoys programming an example of "class create" or "object use"?

This involves looking behind the etoys visual interface to the Smalltalk classes and code which is making it possible.

Understanding this might have important implications wrt how we first teach programming to our youth. Can OOPs be taught to youth before procedural programming?

I previously wrote a blog about OOPs in which I quoted from mark guzdial's blog extensively. Mark is saying that OOPs is harder than procedural, with specific reference to "class create" being harder but not so much wrt "object use":

- "Object-use" means instantiating objects, applying methods to objects, writing new methods.
- "Class-create" means creating new classes and solving problems by writing different methods in different classes (distributing responsibility).

Charles Stewart left a comment on my blog suggesting I look at prototype based programming, he left a link to a wikipedia article about it. When I looked that up it said that a prototype was cloning of instances and called it class-less and it made reference to the concept coming from Self and Squeak

Then when I read about the background to morphic I came across this (User-Scripting has since evolved into etoys):

"In the User-Scripting style, you construct surface graphics by directly assembling standard Morphic parts -- e.g. Rectangles, Images, Joysticks, etc., by dragging them from a Parts Bin and arranging them as desired, and then you add user-defined state and behavior by adding instance variables and writing methods for "Players" who represent the individual morphs you wish to script.

The user thus does not directly subclass any particular kind of Morph, but rather she assembles Morphs and gives them special state and behavior by associating them with "Players", which are the fundamental user-scriptable object types for User Scripting."
- IntroductionToMorphic/Morphic-Styles-Scripting

How to look behind the scenes?

If you click on the light gray debug halo, the one with a spanner icon, a menu appears which enables you to inspect the morph. Then by clicking on extension you can see the important classes involved in the programming side of things. Then you select (highlight) the class name you want more information about and followed by Alt+b to open the browser on that class. This contains all the information you want.



Smalltalk has the open-ness and tools to enable you to look under the hood which is a significant other advantage for learning. Any proprietary program which hides or blocks information is reducing the potential to learn important under the hood knowledge.



By poking around in this way I discovered that the important classes involved are MorphExtension and the Player class, which are described as follows:

Object subclass: #MorphExtension
instanceVariableNames: 'locked visible sticky balloonText balloonTextSelector externalName isPartsDonor actorState player eventHandler otherProperties'
classVariableNames: ''
poolDictionaries: ''
category: 'Morphic-Kernel'

MorphExtension provides access to extra instance state that is not required in most simple morphs. This allows simple morphs to remain relatively lightweight while still admitting more complex structures as necessary. The otherProperties field takes this policy to the extreme of allowing any number of additional named attributes, albeit at a certain cost in speed and space.

Model subclass: #Player
instanceVariableNames: 'costume costumes'
classVariableNames: 'BiggestSubclassNumber TimeOfError'
poolDictionaries: 'References'
category: 'Morphic-Scripting'

The fundamental user-scriptable entity. Always represented by a user-specific subclass of Player; instance vars and methods relate to user-defined structures.

costume is a Morph, the primary morph I am currently wearing for graphical display.

Scripts are defined in subclasses of Player. These are UniClasses.

Messages in scripts are sent to Players. A Player may delegate to its costume, or to an object the costume suggests. Or, a Player may designate some other object to receive the script messages it does not understand. (see doesNotUnderstand:)

The UnscriptedPlayer subclass of the Player class is also important:

Player subclass: #UnscriptedPlayer
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''
category: 'Morphic-Scripting'

My instances are Player objects that have not been scripted, and which hence do not require a unique scripts dictionary, etc. As soon as needed, I am transformed automatically into a unique subclass of Player.

I looked at the before and after situation of adding a script to a rocket object. The important changes are in bold.

Before:
a MorphExtension (3333) [externalName = rocket ] [player = an UnscriptedPlayer (1733) named rocket] [other: (rotationCenter -> 0.5@0.5) (forwardDirection -> 0.0) (baseGraphic -> Form(70x64x32))]

After:
a MorphExtension (3333) [player = a Player66 (1733) named rocket] [other: (rotationCenter -> 0.5@0.5) (trailDotSize -> 6) (forwardDirection -> 0.0) (baseGraphic -> Form(70x64x32))]

So, when I added the script the UnscriptedPlayer class changes into Player66 class

Then if I inspect Player66 class in the browser I can see that it has the script I wrote and that the Steer object has been passed into the Player class of the rocket object:

script1
self forward: 1.
self setPenSize: 1.
self turn: Steer getHeading / (self beNotZero: 3)

Conclusions:

Even though I've learnt a lot I'm still not certain about whether this is "class create" or "object use". I still have a lot to learn about OOPs before I can clearly answer this question or even judge whether it is an important question to ask.

However, I do have a much clearer picture of what is happening behind the scenes when I do etoys scripting

Probably the main thing I have gained from this exercise was the knowledge that Squeak has good tools for quickly inspecting objects and classes, that as a system it encourages learning in this sort of way.

thoughts on a python programming competition

NCSS Challenge: The National Computer Science School python programming competition run by the School of Information Technologies, at the University of Sydney

I'm on long service leave, so I had time to participate in this competition, since they encourage teacher participation. NB. I would not have had time for it - no way - if I had been teaching.

I was very rusty on my python programming. Having the intensity of a competition with strict deadlines (complete 5 challenges a week for 5 weeks) provided some clear structure and pressure to get on with it

My general view about programming is that it is hard to learn. I'm also quite keen to improve my skill because for me programming has a deep sense of epistemological importance wrt to future of the human race. Two links and one quote about this. Why program? What is programming?

(Abelson and Sussman)....writing a computer program is really about the intellectually difficult task of how to control a complex system. The programming language provides us with a means to express and explore ideas about this which would otherwise be too complex to manage.

Each participant is given a profile page where, inter alia, they can enter their code into a window. A server runs some tests on the code which then provides feedback and whether your code was successful or not. You have 5 tries before you lose any points, which is a necessary feature for a machine check. Although far from perfect this mechanism does mean that the organisers do not become snowed under with marking. The negative is that it also limits the creativity or individuality of the competition, unlike some Game Maker competitions I have recently been involved with.

Forums are also provided. One of the forums allows participants to put in a query for code they think should work but which doesn't. I used this a few times. Then a real person evaluates your code and gives you some feedback.

So, there is a combination of machine checking and human checking which minimises work load for the organisers but provides necessary human to human feedback for those who are puzzled with a hard problem. The testing process meant that you had to finish off your program completely to pass all the tests. If you didn't then you received zero points

In the main this feedback mechanism worked well for me. ie. normally the feedback (either machine or human) made sense and I could then proceed to improve my code. Sometimes I thought the tests were either mean (not explained in the challenge) or trivial (eg. "!" missing in a print statement) but the 5 point buffer made up for that.

It was a competition. There was scoring with points, a leader board was published etc. Overall, I found this provided focus and was motivating. However, when I couldn't solve the spreadsheet problem fully after 4 days it made me dispirited for a while. So it could be hard for those struggling with the basics more than me.

The challenges varied in difficulty from easy to hard (my opinion). Examples of hard problems included a spreadsheet simulation (I learnt about eval in doing this one, but still didn't manage to meet all the criteria in time) and programming a MUD.

The challenges focused pretty much on the maths and logic domain. My logical thinking mechanisms have been give a good workout! The sort of things covered required me to improve my skills in the use of strings, lists, dictionaries, conditionals and importing and reading files. For example, one of the problems involved reading in an English to German dictionary (provided) and programming some translations of nouns from English to German and back again. Other problems involved sequences, working out what the sequence was and then writing a program to provide the correct output for an input sequence number.

So, my criticism here is that this is reinforcing an already stereotyped pool of recruits into programming, those who are already good at maths and logic. I think more than this will be required to reverse the trend of declining IT enrollments to courses. Read Mark Guzdial's post, The Wonderful Opportunities of the Declining Enrollment Crisis

Briefly, here are some of the things I learnt or beliefs which were reinforced from the programming part of the competition:

• computer programming is not easy (I've already said that)
• you need to put in the hours
• it's necessary to have some large slabs of uninterrupted time, the very thing that nearly all teachers do not have
• sometimes logic errors totally confound me, initially, I just cannot see how the error message I am receiving, either from python traceback, or, from the competition automatic tests, could possibly be correct
• but then it's either terribly frustrating or wonderfully elating when some time later your next effort either succeeds or fails
• surely I'm not the only programmer who experiences despair and / or elation
• more than once I did not read the question thoroughly enough and this led to errors which could have been avoided - pretty funny since I'm a teacher who sometimes tell students to read the question carefully and then become frustrated sometimes when they don't seem to
• overall the testing process pushed me in the direction of becoming more rigorous and proactive, to think before submitting code - to question some of my "she'll be right, mate" attitudes
  
• you need a good reference manual, pp. 49-50 of Python in a Nutshell (list and dictionary methods) has become well worn.

Many thanks to the IT crew at University of Sydney for organising this.

OOPs?

I entered in the National Computer Science School python programming competition run by the School of Information Technologies, at the University of Sydney. It's been great for my learning. Some of the challenges have been hard, for me. eg. simulate a spreadsheet, make a MUD game (although there was a fair bit of guidance for the latter).

But one thing I noticed was no requirement for object oriented programming.

I do have a beginners book on python programming (Python Programming for the absolute beginner by Michael Dawson) which does teach OOPs. Don't be put off by the dumbed down title, it has very clear explanations which is unusual in my experience for programming books.

Also I've become aware of the origins of OOPs through reading Alan Kay's Early History of Smalltalk and also Dan Ingalls Design Principles Behind Smalltalk and this knowledge makes a difference (without going into those detail at this stage).

So, I've become aware of two things.

At best, Education is stuck at the level of procedural or structured programming. Or quite often for most students, just applications, no programming at all.

OOPs is important (vital) for programming more complex systems but is harder and therefore makes limited inroads into formal Education.

Despite finding it hard to get my head around OOPs myself I don't really want to believe the second statement. I'm hoping that etoys / squeak (visual programming) might provide the answer of making OOPs more accessible. I'm not sure.

Reading Mark Guzdial's blog (he has published books in both Smalltalk and Python) makes me think that part of OOPs (creating classes) might be too difficult

This:

"Objects, for example, are harder for people to understand than procedural programs. Distributing responsibility and process across multiple objects increases cognitive overhead. That's empirically demonstrated. While it may be provably better (e.g., improvements in cohesion, coupling, and encapsulation), it demands more from its practitioners -- and in so doing, makes it harder to take on that role. As more complex ideas flow into the task of programming (structured programming, strong type systems, iterators, abstract classes, interfaces, and so on), the cognitive demands increase."
- Plea to Language Designers: Bring Back GoTo!

And this:

Two of the graduate students working with me, Brian Dorn and Allison Tew, did a fascinating study over the winter break and submitted a paper on it (still awaiting word on acceptance). They reviewed all the programs (scripts) that graphics designers had written for Adobe Photoshop and then had shared with other graphics designers/programmers at a specific website. These were written in Adobe's form of JavaScript. Brian knew (from an earlier study reported in his ACM ICER 2006 paper) that these designers/programmers had virtually no formal computer science background. The questions that Brian and Allison were asking included "Without a curriculum directing coverage of everything, what programming constructs do these end-user programmers use -- either because it's so useful, or because it's easy enough to understand without a course, or both?" In a real sense, this is studying "natural" programming -- what programmers "in the wild," who program because it's useful to them, do without the influence of a teacher.

As one might imagine, every program used variables and assignments, and virtually every program used conditionals and relational operators. But then there are some subtle and fascinating differences. Over 60% of the projects they found used FOR loops, but only 37.5% used WHILE loops. Are FOR loops nearly twice as useful or twice as easy to understand as WHILE loops? They also found that the use of TRY-CATCH for dealing with exceptions appeared in over 60% of the projects they reviewed. Perhaps exceptions are much more useful or much easier to understand than WHILE loops, though virtually everyone teaches a WHILE loop but not everyone teaches exceptions. Programmer-created functions appear in over 70% of the programs they reviewed. Programmer-created objects appear in less than 20% of the programs. Perhaps "objects-first" isn't as natural as we might think.
Studying Programming in the Wild

And these extracts from a discussion he was having on another list:

- "Object-use" means instantiating objects, applying methods to objects, writing new methods.
- "Class-create" means creating new classes and solving problems by writing different methods in different classes (distributing responsibility).
- "Early" means in the first week of class, or in the students' first programming assignment

Using the term "impossible" seems to be setting up a strawman. Nothing in education is "impossible." How about if we use a new term: "works," where works means "students can be successful in completing tasks using what they perceive as a reasonable amount of effort." ...

Reconsidering the phrase "objects-early is impossible," let's first consider "object-use early doesn't work." I'd say that the evidence AGAINST that is pretty strong. Not only do we have evidence of broad student success in tools like Alice (which doesn't have classes and methods in the same sense as Java or Smalltalk, so it tends to be "object-use" rather than "class-create") but even in Logo -- whose turtle is clearly a "first object." Roy Pea and Midian Kurland found that few students that they studied really learned Logo well, but there's a good bit of evidence from studies like Sharon Carver's that students could learn Logo -- that Logo "works."

Now let's consider "class-create early doesn't work." The way I read the research, there's a lot of support for that statement: Creating classes and writing distributed methods is *hard*. Consider some of the research evidence:
- Anne Fleury's work showed that students far prefer in-line code, even going so far as to prefer constants to named values. The Psychology literature makes that obvious: having to look elsewhere to find the value for something increases cognitive load.
- T.R.G. Green's work showed that increasing cognitive load (by making people look elsewhere for code and values) makes it harder to program, e.g., people read more slowly and make more errors.
- John Carroll's and Mary Beth Rosson's work at IBM in the 1980's on Smalltalk found that programmers had a hard time understanding the distinction between classes and instances.
- Even Adele Goldberg's technical reports from Xerox PARC in the 1970's showed that most of their students weren't able to complete program modification tasks in the given time. It took too much time to find where a particular feature was buried in a particular class. It didn't "work."

Overall, it's hard to test this hypothesis convincingly. It's hard to control for all factors and get students to program the same things with and without making classes. But there is a macro-level way of testing this evidence. For the schools whom I've talked to, the failure rate in introductory classes jumped when they went to class-create early, either in C++ or Java. That evidence suggests that it's true that class-create early doesn't work....

For myself, I'm going to stick with an approach of object-use early and class-create later (week 10 or later). Here are my reasons:

- PROGRAMMING IS HARD. Even procedural programming. I see students struggling with where to put the RETURN even in week five. In our last midterm, I was dismayed with how many students were still struggling with how to manipulate two different indices when working with two different arrays (sounds). I'm happy with where our students get in 15 weeks.

- OBJECT ORIENTED PROGRAMMING IS HARDER. I have seen no evidence that class-create programming is EASIER than procedural programming when dealing with introductory-level concepts and CS1 level of programming. I've seen lots of evidence (referenced in my last message) that it's harder. This doesn't have to do with the teaching method -- this is entirely a matter of cognitive load. The raw task of O-O programming requires a greater cognitive load than procedural programming.

- I CAN'T AFFORD TO MAKE IT HARDER. With high failure rates, students' perception of CS as being too hard, and declining enrollments, I can't afford to include class-create early. The costs aren't worth the benefits of learning object-oriented programming in the first course. I believe we need more of a gradual slope in our intro course, not such a steep curve that looks to students like a wall.
- NSF CPATH, Jobs and Objects

Mark Guzdial makes a lot of sense. Reality check. However, I'm still very interested in pushing ahead and learning OOPs myself as well as further exploring the potential of etoys in that context.

Ramon Leon: On Smalltalk

Another great Smalltalk blog. Here are some of the things I found there:

Smalltalk in Action
This provides a link to a video which demonstrates the power of late binding:

... some of the features of the refactoring browser on a running instance of the classic Asteroids game. He extracts a method to a component, changes the color of the asteroids, then shows off undo and redo. He does so while the game is running without ever having to break his flow with something as silly as a compile, debug, run cycle that we’ve all grown so accustomed to in most other languages.

Building a blog using Seaside
This links to a screencast of Ramon building a blog in seaside in 15 minutes. Seaside is a web development program which is written in Smalltalk

My Journey to Linux
The transition from being a Windows guy to a Linux guy. Shit happens.

Why Smalltalk
"I’m still amazed by how many people think they can grok Smalltalk by seeing syntax examples. Smalltalk isn’t its syntax, it’s its environment. Smalltalk is a living world of running objects, there are no files, no applications, just what’s running. To understand Smalltalk, you have to either actually use it for a while, or have a seasoned Smalltalker demonstrate it to you. Reading sample code just won’t cut it."

Ramon's top posts are here

Squeak: Open Personal Computing and Multimedia

draft of Squeak: Open Personal Computing and Multimedia

by Mark Guzdial, Kimberly Rose. Paperback - 544 pages 1st edition (June 15, 2001) Prentice Hall; ISBN: 0130280917

This post is a summary of the pdfs available from the above site, essentially a free download of an important book:

noel.pdf (39 pp)
Squeak for Non-Native Speakers by Noel Rappin
The goal of this chapter is to provide you with enough information about Squeak to understand the code samples and design principles in the later chapters, and allow you to experiment with it on your own – experimentation is a major part of the Squeak world view

steinmetz.pdf (34 pp)
Computers and Squeak as Environments for Learning by John Steinmetz
To promote more thoughtful discussion about computers and learning, and to provide some background before considering Squeak projects, this chapter will begin with general thoughts about children and computers.

Part 1 presents some assumptions and persistent misconceptions about computers and learning.

Part 2 presents their most common current use, simulating older media—such as words on paper or musical sound—while offering extra leverage for working in those media.

Part 3 considers brand new possibilities offered by computers, with entirely new ways to perceive and understand. Squeakers are developing tools, ideas, and genres to help these new media evolve

morphic.final.pdf (38 pp)
An Introduction to Morphic: The Squeak User Interface Framework by John Maloney
Morphic is a user interface framework that makes it easy and fun to build lively interactive user interfaces. Morphic handles most of the drudgery of display updating, event dispatching, drag and drop, animation, and automatic layout, thus freeing the programmer to focus on design instead of mechanics

pierce-final.pdf (24 pp)
Alice in a Squeak Wonderland by Jeff Pierce
This chapter is an introduction to Squeak Alice, an authoring tool for building interactive 3D worlds in Squeak

mathmorphs.pdf (42 pp)
MathMorphs: An Environment for Learning and Doing Math
Luciano Notarfrancesco and Leandro Caniglia
What if mathematicians had a place to keep all their living objects? Not a planar place, but a multidimensional one, with an unlimited capacity to hold things inside. A space with colors and movement.

andres 2.pdf (40pp)
Extending MathMorphs with Function Plotting by Andrés Valloud
This chapter describes how to plot mathematical functions in Squeak. It covers and shows the objects involved and how to present the results in Morphic using the MorphicWrappers. It is aimed at Squeakers who desire to develop objects with rich graphic representations

formatted-btf-once-more.pdf (12 pp)
Back to the Future Once More by Dan Ingalls
The purpose of this chapter is to update the paper “Back to the Future – The Story of Squeak, a Practical Smalltalk Written in Itself” (hereinafter simply “BTF”).
1. Introduction 2. The Evolution of Squeak 3. The Interpreter 4. The Object Memory 5. Storage Management 6. BitBlt and WarpBlt 7. Smalltalk to C Translation 8. Sound 9. Code Size and Memory Footprint 10. Performance and Optimization 11. The Squeak Community 12. Future Work

greenberg.pdf (31 pp)
Extending the Squeak Virtual Machine by Andrew C Greenberg

• Why Extend Squeak?
• Speaking Slang (a subset of Smalltalk)
• The Shape of a Smalltalk Object
• The Anatomy of a Named Primitive
• The Mechanics of Building a Plugin

Rowledge-Final.pdf (26 pp)
A Tour of the Squeak Object Engine by Tim Rowledge
This chapter will explain the design and operation of the Squeak Object Engine. The term Object Engine is a useful phrase that encompasses both the Smalltalk low-level system code (such as the Context and Process classes) and the Virtual Machine. We will discuss what a Virtual Machine (VM) is, how it works, what it does for Squeak programmers and users, and how the Squeak VM might develop in the future.

parsia 2.pdf (13 pp)
Networking Squeak by Bijan Parsia, Bolot Kerimbaev, Lex Spoon
There is a apparent split in the Squeak worldview between the intensely individualistic and the thoroughly social. Squeak itself aspires to be a complete personal computing environment (with the single user in both computational and intellectual control from top to bottom) and a tool for collaborative development, exploration, and experimentation. This conception is akin to the notion of a networked personal computer—neither a thin client dependent on the network and server, nor an isolated workstation, but a node among peers, server, client, and self-sufficient in turn, separable but connected. A Squeaker is not merely autonomous, but autokoenomous

porting-subfinal 2.pdf (57 pp)
Porting Squeak
Squeak must be one of the most ubiquitous programming languages to date. In addition to the original version for Mac OS, Squeak has been ported to a wide variety of very dierent platforms: most major avors of Unix, MacOS-X, several variations of Windows and Win/CE, OS/2, several \bare hard-ware" systems, and so on

shafer-final.pdf (15 pp)
The Future of Squeak by Dan Shafer
Friedrich Nietzsche once said, “Our destiny exercises its influence over us even when, as yet, we have not learned its nature; it is our future that lays down the law of our today.”

If ever there was a topic to which Nietzsche’s thought could be applied, it is Squeak. We have not yet learned the nature of the destiny of Squeak because it continues to unfold before our very eyes and because we are about the business of creating that destiny. Yet, to an extent not attained by other programming languages and environments, Squeak has always been about the future. Its future has in fact determined many of the ways it works and thinks today.

stpope_siren7.pdf (37 pp)
Music and Sound Processing in Squeak Using Siren by Stephen Travis Pope
The Siren system is a general-purpose music composition and production framework integrated with Squeak Smalltalk (1); it is a Smalltalk class library of about 320 classes (about 5000 methods) for building various music-and sound-related applications

xp.pdf (22 pp)
Embracing Change with Squeak: Extreme Programming by J. Sarkela, P. McDonough, D. Caster
The XP practices embody a set of heuristics for recognizing and adapting to change, for change is the only constant in XP. The XP process values learning as a basic skill for individuals and the team, as the tensions inherent in development stimulate evolutionary growth. In the XP view, setbacks and failures provide essential feedback on which the software development process thrives, where risk is something to be understood and managed, not merely avoided.