Background
jLogo Programming
- Commanding a Turtle
- Pseudocode
- Adding New Commands
- Iteration and Animation
- Hierarchical Structure
- Procedure Inputs
- Operators & Expressions
- Defining Operators
- Words & Sentences
- User Interface Events
- What If? (Predicates)
- Recursion
- Local Variables
- Global Variables
- Word/Sentence Iteration
- Mastermind Project
- Turtles As Actors
- Arrays
- File Input/Output
- AI: Pitcher Problem Solver
Java
- A Java Program
- What's a Class?
- Extending Existing Classes
- Types
- Turtle Graphics
- Control Flow
- User Interface Events
Appendices
- Jargon
- What Is TG?
- TG Directives
- jLogo Primitives
- TG Editor
- Java Tables
- Example Programs
- *** New ***:
Installation Notes
Updates
- December 13, 2008
- March 7, 2009
- January 6, 2012
- March 15, 2013
- January 20, 2014
- February 13, 2014
- July 29, 2014
- January 18, 2016
- January 29, 2016
- August 19, 2016
Lastly
Preface
Now available here in Polish thanks to Valeria Aleksandrova.
These web-based notes are the result of classes that I have been involved with for over fifteen years. I started putting them together simply as notes for my students.
From 1999 through 2002, I taught an Introduction to Programming class using the Java programming language to 6th through 8th grade students at Berkeley's Longfellow Arts & Technology Middle School. I had no idea what I was getting myself into. It was an eye-opener, a challenge, but I enjoyed it.
Starting in the summer of 2000, I volunteered to work with Brian Harvey, participating in the BFOIT Introduction to Computer Science program. Brian had been researching and teaching introductory computer science and programming concepts for decades. He had written a series of texts on the subject; he owned UC Berkeley's CS3 and CS61a introductory computer science courses. I wanted to work with him to learn all I could about teaching introductory programming.
The Longfellow Java class was held on Saturday mornings, from 9:00am to 11:00am. The age of the students and the short amount of time (2 hours) and the spacing (weekly, at best) forced me to develop something unlike anything I could find to use. I'd managed to keep all of the students (and some parents) coming back Saturday after Saturday - by keeping the activities very hands-on in nature. Each week, I picked one new concept to illustrate with an exercise; I provided skeleton source code and the objective of each lesson was to learn the new concept used to complete the exercise. For example, in 2002, we worked on assembling a TicTacToe program, piece by piece.
The BFOIT class started out as a single week, with Introduction to Programming taught every morning from 9:00 to 12:00. The students were older and part of the criteria for selecting participants was their grades for Algebra and Geometry classes. The first year we pushed the students hard; the objective was to implement the game Mastermind in Logo using the LCSI Microworlds Logo development environment. We supplied pieces of the program and a few students completed the project. But, we got a lot of feedback that we covered too much in one week.
In the summer of 2001, BFOIT was extended to two weeks. Brian and I decided to slow the pace with a couple of days dedicated to generic programming, followed by a project: to write the game TicTacToe. Our success rate improved. We still had feedback that the pace was aggressive, but we also had feedback that we moved too slowly... Success!
For the summer of 2002, I combined the turtle graphics commands available in Logo with the Java programming language. The experience proved to me that some concepts of programming that are challenges to learn/teach are independent of the programming language. However, due to the limited time for the class, Java's syntax was too much to cover. So for the summer of 2003, I went back to Logo and it did prove to be better, the group progressed through more concepts in the two weeks.
For the 2004 BFOIT class I decided to cover all of the basic concepts of programming in Logo. Once the students were comfortable with this material, Java would be introduced along with object-oriented programming. The web notes were expanded to cover a wider variety of computer science topics. I extended the Java turtle graphics code, adding an interpreter and a subset of the Logo language. This new program (TG) ran as an applet which was embedded into the new web notes. Students could experiment with programming concepts as they were introduced. TG also ran as an application so that students could save and load large programs.
During the 2004-2005 school year, Albany High School (just north of Berkeley) used the web notes. I was in close contact with the instructor and adjusted the contents to meet feedback; slowly the notes became lessons.
The 2005 BFOIT summer camp went well. I got more feedback and continued to refine the lessons. Albany High School also used the curricula again; this year without any assistance from me. I played a bit with e-learning via an ICSI CoPE Internet site. This later became a Facebook group.
In 2006 I decided to move the BFOIT curricula more towards preparing students for the AP CS (Advanced Placement Computer Science) class. This has remained my overarching goal. Since the BFOIT flavor of Logo is written in Java and contains Java-like extensions (e.g., Events, null, println), I've renamed the language jLogo.
In 2007, a new friend (Florian Plank), told me he liked the material, but that it's presentation could use a lot of work. He put together an example page or two which were much, much better than my stuff. I spent time rewriting the material as I cut and pasted the existing content into Florian's styled pages.
Around this time, MIT released the Scratch programming environment. It quickly became the tool for introductory programming. It provides a drag-n-drop, building blocks interface (no chance for syntax errors) as a programming language. I decided to focus BFOIT's lessons and the TG programming environment in the gap between Scratch and the Java AP CS class. This meant TG needed a lot of work. Over the next few years full multimedia support was added, more nerdy stuff from Berkeley Logo was supported, the Editor was enhanced, help, error messages and debugging aids were improved. The prioritization of changes was based on feedback I got from teachers/mentors using TG and/or the lessons, as well as what I've learned in my research.
So much stuff has been added to TG that it is now time for another pass through the lessons, to improve them and to introduce the new functionality.
Curriculum Philosophy
The BFOIT website materials cover what I believe are the most import concepts for a student's initial exposure to computer programming and (to a little lesser degree) computer science. The programming lessons move in microsteps in an attempt to reduce cognitive load. Each lesson builds on the previous, adding one big programming language concept.
I believe that the purpose of a high school CS0 class should be to introduce how useful programming can be as an aid to learning and understanding and in problem solving; it can help explain complex processes (via modeling and simulation); it can be used to express oneself artistically. The lessons must make computer programming attractive, fun. We need more students (and a more diverse group of students) using programming to enhance their learning experience. It should prepare a student for further investigation (?the AP CS class?). Even if the students end their study of computer programming with these lessons, they have been exposed to a variety of problem-solving skills and a feeling for how they could use a computer as a tool.
For a couple of my favorite views in this area, see Computational Thinking and Changing Minds.
In her book In Code, Sarah Flannery talks about how she used programming to explore and then document her work in cryptography.
So, what do I think is important in a computer programming class?
- It must have a good set of projects/exercises that give the student a feeling for how he/she can get a computer to do something of interest to him/her. The last thing I want to do is to scare students away from the field. The instructor should know them inside-out. Since there is rarely a single way to do things, the instructor must be able to see/judge merits/deficiencies in alternative solutions. Students will do things their own way and there often is a lot learned from their approaches.
-
It should cover the basics of computer science and programming without
overwhelming the student with esoteric information. The instructor needs
a set of lessons that cover a subset of CS and must be comfortable introducing
the material. She needs to know where the hard/trouble spots are (where
many students have problems) and be prepared to give extra guidance/coaching
in these areas.
"20% of the people will learn whatever you do to them. It's the other 80% that you have to worry about." Elliot Soloway
I've had students in my classes that just get programming. I need to do very little other than point them in the right direction and they are off and running. These are not the students I hope to help with these lessons. Chances are these students will get bored unless the instructor can recruit them to help others in the class, or push their limits with programs they come up with on their own or extensions to the exercises here.
What are the most important basic concepts?
- the concept of process, and then,
- decomposition of problems into understandable/manageable pieces
- abstraction - procedures and data
- the proper use of variables
- debugging and verifying a program's correctness
- at least an introduction to the way a program and information is encoded in binary numbers (bits)
-
Simplicity. The programming language used must be one that the instructor knows well or can learn easily. Given this, the simpler the chosen language's syntax/semantics, the better. The language does not have to be the current hottest language in use; high school students are not going to get a job in the real world based on what they learn in a CS0 class. If you do not believe this, read Teach Yourself Programming in Ten Years by Peter Norvig. The language should not get in the way of what one really is trying to teach. Simplicity is also important in the chosen programming environment. The less time you spend talking about the constructs of the language and how to develop programs in the chosen environment, the more time you get to spend on the real problem of authoring a process in source code.
I strongly believe that Java is not a good first programming language. In his book Java: The Good Parts, Jim Waldo starts with a section What Is Java Good For? where he lists its strengths as
- First I find Java a useful tool when I'm working on a project that is either so large, so complex, or on such a short schedule that I need to be working with other programmers to get it done...
- I find the Java language and environment to be a useful tool when the code that I am writing needs to run on multiple platforms...
- Java is a useful tool when the code you are writing is going to be used for a long time...
- Finally, I would say that Java is a useful tool if the code you are writing needs to be reliable.
These strengths are not what's needed in an introductory programming language.
Go to the Table of Contents