Showing posts with label python. Show all posts
Showing posts with label python. Show all posts

Tuesday, July 21, 2009

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.

Sunday, July 12, 2009

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.

Saturday, July 11, 2009

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.

Sunday, February 24, 2008

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.

Thursday, October 25, 2007

kusasa ("tomorrow"): a solution to the maths/science education crisis

I've recovered from my initial excitement and have read every word carefully on the kusasa site(Capetown, South Africa) and pretty much agree with their whole approach to using computers for maths and science education

It seems similar to what is being done in Extremadura, a poor rural region of Spain (video link)

The philosophy is pure Papert: maths-land, hard play, tap into personal interests, build models of objects to think with, using computers to explore, discover and learn

Maths and Science ought to be learnt in the way it has developed historically. Humans wanted to build things and predict things. In doing this they gradually learnt maths and science. The abstraction came later.

The software is squeak etoys for years 4-9 and python for years 10-12

There are some great quotes about the importance of play on the How > Interests page sidebar:
"Play is the highest form of research."
Albert Einstein

"Do not keep children to their studies by compulsion but by play."
Plato

"In play a child always behaves beyond his average age, above his daily behavior. In play it is as though he were a head taller than himself."
Lev Vygotsky

"The very existence of youth is due in part to the necessity for play; the animal does not play because he is young, he has a period of youth because he must play."
Karl Groos

"Almost all creativity involves purposeful play."
Abraham Maslow

"Play is our brain's favorite way of learning."
Diane Ackerman

I like the Why? section the best, it goes into Challenges, Changes and Opportunities

Challenges: We are facing a crisis in maths/science education in many countries. Many students find it tedious and boring. In recent times education has become confused with entertainment, the demarcation is not clear.

Changes: A series of slides comparing 1907 with 2007 demonstrates how little School has changed compared with the car, the aeroplane, music and communications.

Opportunity: The plummeting cost of powerful computers opens up new opportunities to dynamically model concepts in a variety of learning areas.

Wednesday, October 24, 2007

Kusasa, a Zulu word for tomorrow

Kusasa
http://www.kusasa.org/index.html

This project from Mark Shuttleworth's foundation reflects my ideas of how computers should be used in schools and / or education. What a gem! Thanks Margaret!

Check out Mark Shuttleworth's amazing biography
  • successful IT entrepeneur / venture capitalist (digital certificates and internet privacy)
  • first African Cosmonaut
  • founder of The Shuttleworth Foundation, a non-profit organisation dedicated to social innovation in Africa with a particular focus on education
  • founder of the Ubuntu project ("Linux for human beings")
  • founder of HBD Venture Capital, "Here Be Dragons", which legend has it was used to describe uncharted territory on early maps ...
  • promoter of the Hip2BSquare brand, which aim to make mathematics and science sexy to pupils who are choosing their subjects for high school
"My current project, aims to produce a free desktop OS for the world. Everything you need on a single CD"

Friday, August 24, 2007

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.

Thursday, August 23, 2007

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.

Sunday, April 01, 2007

from guido van rossum

A couple of interesting quotes from Guido van Rossum's (the creator of Python) blog reporting on the Python 2007 Conference.

About the OLPC (one laptop per child) software:
The software is far from finished. An early version of the GUI and window manager are available, and a few small demo applications: chat, video, two games, and a web browser, and that's about it! The plan is to write all applications in Python (except for the web browser), and a "view source" button should show the Python source for the currently running application. In the tradition of Smalltalk (Alan Kay is on the OLPC board, and has endorsed the project's use of Python) the user should be able to edit any part of a "live" aplication and see the effects of the change immediately in the application's behavior. (A versioned document store will make it possible to roll back disastrous changes.) This is where Krstic wants my help: he hopes I can work magic and implement this feature for Python ...
The fact that python has become the main language being used to develop OLPC software (and not alan kay's squeak / smalltalk) is an incredibly powerful reason to teach Python in the schools of developed countries

For more discussion on python in education see the Edu-sig archive, which is "the starting point for a community around the Computer Programming for Everybody (CP4E) project, and a general meeting place for educators interested in teaching Python. " (about and subscribe page). There are some great discussions on this list.

About educational political gridlock:
The keynotes had a strong educational theme: on Saturday morning Adele Goldberg gave a passionate plea for improvements to the USA's educational system. 40 years ago, US education was #1 in the world; today it is #19. The public school system is stuck in a complete political gridlock; changes are nearly impossible to make due to the many constraints imposed on schools by federal regulations, fearful and litigious parents, bullying, lack of funds, and many other depressing factors. It also seems that most uses of computers in the classroom have turned into disasters: the well-meaning geeks behind many school computer experiments don't understand the situation in the average classroom. For example, computers show up without sufficient power, are likely to be stolen, or locked up in a safe rather than being used! Schools are in total fear of the internet, which is seen as a source of pornography and influences of the devil
Pretty much the same situation has developed in the Australian public school system

My hope is that within a few years there will be millions of OLPC in the world used in a way which demonstates to the moribund education system in developed countries that there is a better way. That is clearly the educational philosophy supported by the developers of the OLPC as outlined previously in this blog, see "we are impatient..." and seymour papert interview

Sunday, January 28, 2007

why education technology has failed school

And School has failed technology. This is a wonderful essay by Paul D. Fernhout, January, 2007, which also ventures into the issues of work and history.

He argues cogently that modern technology makes schools obsolete. Some extracts:
Ultimately, educational technology's greatest value is in supporting "learning on demand" based on interest or need which is at the opposite end of the spectrum compared to "learning just in case" based on someone else's demand.

Compulsory schools don't usually traffic in "learning on demand", for the most part leaving that kind of activity to libraries or museums or the home or business or the "real world". In order for compulsory schools to make use of the best of educational technology and what is has to offer, schools themselves must change...

So, there is more to the story of technology than it failing in schools. Modern information and manufacturing technology itself is giving compulsory schools a failing grade. Compulsory schools do not pass in the information age. They are no longer needed. What remains is just to watch this all play out, and hopefully guide the collapse of compulsory schooling so that the fewest people get hurt in the process.
So, who is going to get hurt in the process?

I was also fascinated by Paul D. Fernhout's PataPata project which is/was an experiment focusing on taking ideas from Squeak and Self and moving them to Python, as well as trying to go beyond the ideas in a Pythonic and educational constructivist way. Paul has written a post mortem critique of this project which is again a fascinating read. I hope to get time to return to this and follow up on the issues raised. It is sections of the free software community that has the vision for the future.