Continuing the Journey

Shortly after our event at Foursquare, I was chatting with Kevin Friedman (Stuy '96). Kevin's startup is Cojourneo and since it has an educational bent, he thought I might be interested in hearing about it.

I certainly was.

Rather than visiting Kevin, I thought it would be fun to have him come down after school, present Cojourneo to any students that wanted to stay late and then field questions.

Cojourneo is an interesting product. There's been a lot of hype around on line education in the past year, but it seems to me that Cojourneo's a little different. We've got efforts like Coursera and Udacity that are trying to bring university style offerings to the masses while places like Codecademy seem to be more vocational in nature. All three efforts are "class" based. That is, you are taking a class over a period of time. Despite some resources to make these classes shared experiences -- specifically things like discussion groups, they mostly seem to have students watching videos or working through on line material on their own. 

Cojourneo's approach is to organize around "journeys" which aren't necessarily academic in nature, one of the journeys they have going now is Surviving the Startup Journey, but Kevin mentioned that they could have things like book clubs, travel journeys or any number of other types of journeys. They're also different in that they're really trying to create a shared experience -- you take the journey with a small circle of people, not solo - I love this aspect.

By no means am I an expert, but I like a lot of their ideas.

A bunch of students gathered and we were off. I had no idea how the talk would go but I figured that the kids hadn't had an opportunity to speak one on one with someone in the early stages of a startup so it would probably be valuable. 

Kevin presented the product, talked about some difficulties and decisions along the way and generally tried to give the kids the flavor of what it was like to start a product and a company. The kids tried to reciprocate by providing feedback on the product. 

Most of the questions focused on the business side rather than the technical. Kevin was asked about funding, monetization, building a user base, scaling, and any number of other ideas. 

All in all, I think it was a valuable experience and look forward to bringing more alums down to talk to the current crop.

Anyone can cook

Anyone can cook - Chef Gusteau

These days the rage seems anyone can code.

On line attempts to teach coding and computing abound.

We've got Udacity and Coursera trying to bring college level academic offerings to the masses on one extreme and more down to earth "learn to code" efforts with Codecademy getting the most press.

While I applaud any effort to make knowledge more accessible, there are a lot of unanswered questions as to the effectiveness of these latest attempts. Recent posts by Dan Meyer and Audrey Watters have started to raise questions and in my opinion some of the hype has worn off.

At some point, I plan to talk at length about the Udacity and Coursera offerings as well as attempts to increase on line course offerings at the high school levels. I'll talk about the difficulties and dangers that lie ahead.

Today, I'd like to talk about the more vocational offerings such as what Codecademy is doing.

The premise seems to be that anyone can code and that everyone should code. I've been thinking about this for a while and I keep coming back to the question, "what's the endgame?"

Teaching Javascript, HTML and the like narrowly focuses on creating web pages. Even if we forget about difficulties of on line learning that include lack of an interactive feedback loop, lack of follow up,  a narrow curriculum, and the fact that programming beyond the basics is not easy, what's the goal? While I find making an interactive web site cool, I don't know how much it benefits the masses.

One could argue that the mental exercise of programming is a benefit and having a better understanding of how a computer works is a good thing. I'd agree, but what we really could benefit from is a different paradigm in terms of how we approach using computers. A new approach would make even rudimentary scripting skills of greater value to all.

Most of us use computers as program loaders. That is, we sit down, load our word processor, edit something, and exit the word processor. Load our web browser, search the web, exit, load the next program, do something, etc. We might have multiple programs up at the same time, but we use them in isolation.

This is how most people's computing experience has evolved.

With this mindset, I'm not sure how useful coding will be for the masses. People might benefit from some rudimentary scripting a la Excel macros or Google App Scripts, but power users already do this. I don't think that the ability to program within the constraints of scripting individual applications will be a game changer.  To make rudimentary programming skills valuable we must use computers in a way that allows us to use simple techniques to tie together powerful applications.

A few years ago, right before our Christmas break, I stopped over in the Math Chairman's office to wish him a good holiday. Danny was hard at work. He was frantically trying to change the math web site before he left.

The math site was a mess. It consisted of a few dozen loosely arranged folders each with multiple sub folders. Danny was looking in each folder for old sample final exams, each saved as a Tiff file. He would load the file into Photoshop, convert it to another format and save it. He would then change the corresponding HTML file to reference the new file. He had been at it for hours with no end in sight. I said "Danny, I've got this, go home."

I went to my office, wrote a small shell script, maybe 10 lines, hit enter, got on my bike and rode home. When I got there, the job was done.

Now Danny's a really smart guy and he's technically savvy. The difference is that I was taught to try to tie programs together through the command line while he was taught to do things in the Windows/Mac way of loading one program and using it in isolation. I used a simple shell script to tie together a number of powerful Linux applications (find, imagemagick, sed) rather than pointing and clicking over and over again.

I've seen this "program loader" mind set time and time again and in surprising places. My good friend and colleague Gary Rubenstein has done a lot of work debunking the "educational reformers" that are currently in power. Gary had been using Excel to do all his analysis until I pointed out that he could download his data and use simple Python scripts to greater effect. Why was I surprised that Gary wasn't already doing this? Well, in addition to being an amazing math teacher, Gary holds a Masters degree in Computer Science and had worked as a professional programmer in a prior life.

Of course, our life isn't made any easier with closed file formats and vendors that try to isolate their data, but if we could re-educate people to use computers across applications, that would make rudimentary programming useful to all and then indeed there would be a reason for everyone to code.

Checking in with the family

"... the standardized courses don't shed much light on future opportunities and they make it hard for students to identify what they're most interested in. The CS department, on the other hand, is great at demonstrating all the things that are going on in the modern comp sci world." -- Asa, one of our current CS students.

Asa's comment was in response to an event we held last Tuesday. We brought 100 current students up to FourSquare along with 100 of our CS alums for a mixer. Other than the fact that we aren't a department, I'm hoping he was spot on. 

Stuy CS from 1976 to the present

A couple of months ago, I started to try to organize the graduates I've had the privilege of teaching over the years. I put out some feelers and the response has been great. So far we have about 400 members. I like to refer to us as the Stuy CS family since I'd like to think there's a stronger bond than that typical between a teacher and his students.  I'd also like to think there's a common thread across the years that ties the older and younger graduates together.

To kick things off, I thought it would be a great idea to get the alums together with the current students. We've got people all over the tech map, from giant companies to startups. I started putting a list together here. I thought it would be great to expose our current students to the range of possibilities that await them.

Immediately, the family came through. Noah and Dave volunteered FourSquare as host for the event. They provided the food and the site. The alternative would have been to have the event at Stuy. This would have cost us and would have been somewhat mundane. Just being at a place like FourSquare seemed to really excite the current crop of Stuy students.

The evening of the event, I was a little nervous -- about 100 alums signed up, but would they show. I've been told that general alumni events can typically have a very high no-show rate, particularly when the event has no cost and registering is as easy as an email.

The kids and I arrived early -- school lets out at 3:30 and the event didn't start until 6:00. As 6:00 approached, the alums started to dribble in. By the time we started, we had a packed house!!! It was great seeing everybody again.

We had alums from every year. From 1995, my first set of graduates, to last years senior class. We also had a few older alums, including me and  my classmate and friend Steve from '84 and Gerry ('76) , who I met when he volunteered to help Stuy CS back in the 90's. He's become a good friend to both me and the program in the years since.

For my part, I was extremely touched that everyone showed. As a teacher, you'd like to think you've had enough of an impact that your students would give back, but we rarely get any evidence as to the effects we've had. I've been fortunate enough to be in contact with a number of my alums through the years and a number of them have been kind enough express gratitude (often times more than I deserve) but to see everyone show up en masse really meant a lot to me. The only down side was there was so much going on, I really didn't get to spend time with anyone -- it was like hosting a wedding or bar mitzvah -- everyone's there, but you don't get to see anyone. I hope we can remedy this with more events and smaller events in the future.

If any of the "family" is reading this, you've also got to give me some props -- even though I haven't seen many of the alums in years, I recognized almost everyone and remembered far more names than I probably deserved to.

We spent the evening mixing students and alums and the FourSquare crew threw in tours of the facilities. Afterwards, many of the alums stayed back to discuss how to move Stuy CS forward. How the alumni community can help Stuy CS and it's current students and how it can become a resource for fellow alums. I think there are a lot of things we can do as a community, and I'm excited about what's to come in the near future for us as a group.

For the students, feedback has been terrific. I've gotten comments like:

I was wavering between whether or not I would continue CS in college and as a career, but now I'm fairly certain.

and

I really enjoyed the compsci event, it was very helpful to talk to alumni because they reminded me that there is life after college. I also liked the community within a community feel of the event.

The students pretty much universally loved the event and  I really think they got a lot out of it. 


We had parent conferences last Thursday and Friday and parent after parent confirmed this. Just about every visitor I had mentioned how much their son or daughter got out of meeting the "family". People  who were in their shoes a few short years ago and are now doing great things in the tech community. 


From what I can tell, this was a unique event, at least to Stuy, no one's ever done anything like this before in any subject area. It looks like it was a slam dunk, at least with respect to value to the students. 


Now the "family" just has to decide where we can go from here.

Field Trip!!!!!!!!

When kids are knee deep in nlog(n) algorithms and working on recursion, it's easy to lose track of the amazingly neat things that are right around the corner for them.

I've recently been working on organizing our Stuyvesant Computer Science alumni network and am putting together a page with some of the places our graduates work here.

It can be hard to see how one goes from sorting and searching in Java to working at places like Google, or FourSqurare or creating your own startup like DigitalOcean, Usable Health, TimeHop, or PropHop.

We try to show how close they are to doing really cool things, like the other day when we developed some solutions that lead to seam carving, but there's still a large enough gap between what they are learning and where they will be that it's hard for them to see how close they are.

With this in mind, yesterday, we took a field trip.

Being an NYU Alum myself  (BA '89, MS '95?), the CS people at Courant and I have periodically tried to form a partnership but there were internal problems at NYU that prevented us. Over the past few years, however, things have changed and we're well on our way.

Thanks to the efforts of the always amazing Evan Korth, Michael Overton, Rosemary D'Amico, Romeo Kumar, Shawn Abbot, and others, we were able to bring about 100 Stuyvesant juniors to NYU for a day of computer science.

We had four amazing presenters.

Ken Perlin batted leadoff talking to the kids about a variety of his interests. Basically a smorgasbord of places one can go to with CS. Ken touched on things ranging from expressing emotions from an animated  avatar composed of five polygons to paradigm shifts relating to ebooks.

Rob Fergus then gave a talk on image deblurring. Where Ken's talk provided a range of topics, Rob focussed in on one. The kids were really able to see how what they're doing now is just one step from solving some really neat problems.

JinYang Li was next. Her talk focused on systems touching on infrastructure issues and parallel processing. This provided an overview of one specific field in computer science.

Batting cleanup was Nathan Hull. Nathan talked about IOS developement. The most hands on topic of the day. Nathan really emphasized the fact that the kids could just download the tools to do either IOS or Android development and with online resources, they could teach it to themselves.

All this was followed by a great lunch.

It was a great range of talks and the kids left having a much better idea of what CS will be like in college and the range of things they'll be able to do.

Right now, I'm working on another event which will bring our students together with Stuy graduates working in the industry to give our kids more exposure to the step after college but more on that in a few weeks.

Pair Programming Tag Team Shootout

So today we changed things up a bit.

Instead of having a typical lab type periods, we tried the Pair Programming Tag Team Shootout.

We aren't annualized so while the kids that have been with me since September have been working in pairs for a while, the other half of the class is just getting used to how we do it. I also wanted to get the kids to mix a little more.

Hence the shootout.

Everyone got a sheet with a bunch of problems on it:

Shootout


I then paired them off randomly.

The idea is complete the first problem, find a new partner, repeat.

By the end of the period each student worked with between five and seven partners.

I'm having them send me their solutions and partners tonight.

The early response was good -- it's speeding up them getting to know each other and it was a nice change of pace. We had some problems coordinating switching problems, but we'll do better next time.

All in all a good day.

Let me Google that for you

Piloting a new course this semester - Intro to Computer Science part 2. Between the existing Intro part 1 and this, we should be able to do a pretty thorough job in preparing our kids for the future.

We decided that we wanted the kids to make deliverables in the form of web pages - plain old html written by hand. Part of the idea was to demystify things, part was to let the kids show off their work, part was to have something that they can generate programatically as the course progressed, and part was to give them a tool they might find valuable beyond their computer science classes.

We also wanted to help teach the kids how to find information and how to learn things on their own. Despite the fact that our students use computers all the time, they possess a widely varying skill set. With that in mind,  here's what we tried to do:

After a brief introduction to what a web page is (just a text file with markup) and showing them the bare
minimum of markup:




I recommended a simple editor - gedit - while resisting all my inner urges for all things emacs, and then showed them an image of a web page:

The end goal was to make a page that had all of the elements in the above image but I also asked:

• How did they go about finding out how to make the page?
• Where did they search?
• what turned up bad results (and what were they)?
• what turned up good results (and what were they)?

I was very pleased with the results. Just about all the kids are now able to make a web page with the components in the image above. More importantly, this is what came out of our discussion:

• Everyone used Google exclusively as a search engine.
• The range of queries ranged from things like "html tutorial," "making a web page," and just plain "html" to maybe not so good things like "gedit web page."
• No one used social search or used facebook.
• They mostly all found sites such as w3schools. 

I'm hoping this is a good first step in having the students find things on their own and not be afraid to try things. I think it's an encouraging start.

CS Stress

I've been mostly underwater for the last couple of weeks.

End of term issues combined with the Academy of Software Engineering announcement has pretty much eaten up all of my out of class time.

It's going to be a week or so before I can finish writing the posts I was planning on, but it looks like a storm is brewing around Stuyvesant and Computer Science so I thought I'd put up this short semi-related post.

Stuyvesant has a reputation of being something of a pressure cooker. The day can be as long as ten periods and it's not uncommon for a student to take three or more AP classes, even before the senior year. The question of student workload and stress has been a hot topic for a number of years.

There's frequently tension over how many courses and which courses a student should be allowed to take.  Usually, this revolves around the school placing a limit on the number of classes, or more specifically, the number of A.P. classes a student can take. Most recently, the conversation looks to be turning to the number of classes a student can take overall.

Given that most A.P. classes fall within a Stuyvesant student's required sequence of classes - that is, Calculus is just "the next math class" and A.P. U.S. History is slotted in place of a students regular U.S. History course, limiting the number of classes a student can take, A.P. or otherwise could have a major impact on Computer Science at Stuyvesant.

What's most disturbing is that limiting student options in terms of courses may not do anything to decrease stress and workload. No one has looked at what is actually going on in student's required classes.

I decided to collect some information from our students. I sent out a survey to five of our seven A.P. C.S. classes (three of mine, two of JonAlf's -- the other two classes don't have a mailing list). I asked them to rate the work load and stress factor for A.P. CS, their typical Stuy course and their typical Stuy A.P.course. So far, I've gotten 80 responses (out of about 150 students emailed). Here's what we got (ratings were on a 1-10 scale):

	A.P. C.S.	Reg. Class	A.P. Class
Workload avgs	4.97	6.65	7.13
Workload dev	1.94	1.41	1.52
Stress avgs	4.67	6.39	6.94
Stress dev	2.24	1.63	1.64

I know this isn't really hard data, but it seems that our A.P. C.S. classes are considered to be both easier and less stressful than other classes at Stuyvesant. Given that our kids do very well at C.S., we're probably doing something right and it will be a shame if student opportunities become limited. I'll certainly write more on this as the situation develops.

For you educators out there, is stress an issue at your schools and how do you deal with making room for students to take CS at your schools? 

Pretty sneaky, Sis

I've always lamented the fact that we don't have the time or structure to really teach our kids to program.

In their early classes, they learn syntax, algorithms, and  some ways of storing data and while they  will probably work on some larger projects as they study CS, kids seem to be mostly left on their own in terms of how to take a project from problem or idea to completion.

This frequently leads to poorly designed projects that are harder for the kids to write, debug, and modify. They end up with huge functions/methods no overall plan or design and everything's pretty much a mess

To try to address this, and having finished  most of the A.P. curriculum and not wanting to diverge from the other teachers, I figured we'd develop a class project before I gave the class time for their final projects.

I'm not a huge game person, but since they decompose well, we decided on writing connect 4 - a game that can be described as tic-tac-toe but with four in a row, on a larger board, and WITH GRAVITY!!!!!!

Actually, the choice of project didn't matter that much so long as it was the right size -- this was more about how we develop a program than about the actual program itself.

I started by giving my classes about ten or so minutes to talk among themselves to design the program -- no guidance was given. About seven minutes in, I asked them to reflect on whatever they were discussing - if they were discussing a data structure, why? If class design, why? What was so important about whatever they were discussing that made it their first order of business.

After a while, we started to share thoughts as a group. Most suggestions revolved around details -- how to you check for a winner, how do you make a move. This made sense - we've spent much of the term dealing with writing code fragments to do things and not too much time thinking about overall design.

This lead to a healthy discussion of looking at things from the top down as well as bottom up.

By the end of the class, we had identified the key classes we'd need (Board, Player, UI, Game Driver) and had some idea as to how they would relate to each other. By the next morning, we added a data structure for the board.

Over the next few days we filled in the missing pieces. We moved up and down levels of abstraction being careful to discuss why we designed things the way we did and adapting pieces as needed.

By the end of the project we were able to accomplish the following:

• Students saw how to have classes refer to each other - that is, the Player class had an instance variable to hold the board, while the Game class had instances for Players as well as the Board). 
• We were able to use different user interfaces for the program -- starting with simple console input and then moving to a GUI -- all we had to do was extend the UI class.
• Likewise, implementing a computer player (albeit a rather limited one) was trivial.
• I also tried to show frequent testing and the idea of developing one concept at a time.
• We discussed the idea that while design is important, there's a point where you can over design. Be aware of the scope of a project, what can generalize, and what shouldn't.
• With a good design, it was also trivialize to change things like game rules, how to move, board size. etc.

Based on preliminary feedback, I think the students have a much better ideas as to how to break down, design, and build up a project from design to implementation.

If any one's interested, the code is available here.

We'll see if it helps with the final projects, but I'm optimistic.  Spending time highlighting the design and development process while building a project can only help.

Anyone else have interesting mid-size projects they do with their classes?

Where's Waldo - Text style

Ok, it's a word search.

We're always looking for interesting applications to build lessons around. Over the years, I've tried different things when teaching 2 dimensional arrays. Simple game boards, representing a crossword puzzle, tables of various sorts, etc.

This year, JonAlf, one of my amazingly talented colleagues, decided to go with building a word search. I decided to steal the idea. It's a great one.

I thought I'd use this post to go through the project and why I like it.

Ultimately, the students end up with a program that will generate an n by m word search filled with random words from a dictionary. We gave the kids a skeleton of the base class. The only actual code we had to supply was the method that loaded a dictionary file into memory. You can check out the assignment here and the finished code here (we updated the repository as the project developed).


The first part of the project are pretty mundane. The kids write a couple of constructors and toString. Basically just practice traversing a 2D array. The project starts to get interesting at part 2, when they write the methods that add words into the grid. First horizontally:



After they write the method to add words vertically, we can start to refine things. We notice that the routines are essentially the same. The only difference between adding a word horizontally and vertically is  what we add  to the row and column each time. For one, there is a delta column of + 1, for the other it's a delta row. Further, they realize that adding diagonal words just needs both deltas. This leads us to factoring out the common aspects of the code and writing something like:



All of a sudden, they've written one piece of code that can add words in 8 orientations.

After filling the rest of the grid with random letters, we turn our attention to building a random puzzle.

This part of the project involves using an ArrayList of words. Our students frequently mix up array and ArrayList notation early on so by having a project that uses both but in clearly delineated areas, the students can be more comfortable with each.

For this piece, the code is again straight forward. Students run a loop that gets a random word from our dictionary and tries to place it in our grid at a random location choosing one of our possible orientations randomly. We get to see another nice little refinement again when we move from the typical first take at building a random puzzle which uses a three (or more) way if statement to select how to add words:



to using our more general addWords method described above:




When we're all done, we had some time to project the word search on the board and fun was had by all.

Peter, another one of our CS teachers had a great suggestion that I think I'll try. Start a competition to have the students modify the program so that it generates as densely packed  a wordsearch  as possible (giving higher scores first for longer words, then number of words).

Between the way the project broke down, the topics covered and the little refinements, I really enjoyed working with my classes on this project -- I'm hoping they enjoyed it as well.

Reboot

A couple of weeks ago, I attended the K-12 workshop at the Grace Hopper Celebration of Women in Computing Conference. It was great to reconnect with some old friends, make some new ones, and talk shop for the weekend.

One result was that I promised to start blogging again.

I've got a number of ideas for posts lined up. Some on pedagogy, some technical, and some cultural. Hope you enjoy them.

Earlier today Ben Chun tweeted about this post: http://worrydream.com/SomeThoughtsOnTeaching/.  To summarize -- teachers should practice what they preach. In the post, Bret Victor wonders if there are calculus teachers who spend their evenings doing calculus.

I know a number of math teachers who spend a considerable amount of their free time working on problems and refining their math skills, I also know many who don't.

I know wonderful, inspirational teachers in both camps. I've also known weak teachers that fall into both categories. Great teachers in both categories also spend large amounts of time working on how to best deliver instruction.

Before I started developing the computer science program at Stuyvesant, there were one or two sections of A.P. Computer Science. They were taught by a terrific teacher -- one of my mentors and role models, but he was a math guy and not passionate about CS. When I took over, the enrollment immediately shot up. Not because I was any great shakes, and Dave, the previous teacher was legendary. Rather, the students knew I loved CS. Part of that love was that I enjoy solving problems with computers, coding and what have you. The students can tell.

The fact that I code is a byproduct of my passion and part of the whole package that defines me as a teacher and a person. Whatever success I achieve is a result of this package. It's something I enjoy, and it also keeps me current with the field.

I've seen "naturals" who are just great teachers and get by without a passion for their subjects. More often than not, there's a ceiling in terms of what they can give their students either in terms of content, or more importantly, in terms of inspiration. Some times the ceiling is high enough that there isn't a problem.

Over the years, my "practice" has taken different shapes. Early on, while my students were working on USACO problems. I figured I had better be able to represent, so I started doing them. Later on, I would write systems to support my teaching.

More recently, I've been lucky enough to be surrounded by a number of like minded educators. We frequently share little projects we work on.

This semester, I've been taking the Stanford on line AI and ML classes -- both have been lots of fun.

This is just what I do and who I am and it is reflected in how I teach.

Of course, time and job constraints make coding difficult during the school year. With ~150 students, lesson planning, grading, and ancillary responsibilities take their tolls.

So, I guess I'm an example of what Bret Victor was talking about. I'm not sure I fully agree with his thesis, but it seems to work for me.

Sorting from the top and from the bottom

I've been meaning to write this post for a couple of weeks, but some times life just gets in the way.

I've always thought it important to arm students with as many different tools with which to attack problems as possible. As such, the courses I teach use a number of different languages, each highlighting a different paradigm and thought process. The hope is that by the end of the sequence, they can look at problems from many different angles.

In my advanced placement classes, we recently studied sorting algorithms. It think the quicksort is a good example of a problem that can be looked at from multiple points of view.

In my experiences talking to teachers and students who cut there teeth using languages like Java, C, or C++, much of the discussion deals with the actual partitioning of the array. Comparing elements, swapping them and arriving in the middle. One might end up with something like this as a first cut:

 1:  public void qsort(int[] a,int l, int h)
 2:  {
 3:  if (l>=h)
 4:    return;
 5:  
 6:  /* Just use lowest index as pivot for now */
 7:  int pivot = a[l];
 8:  int low=l;
 9:  int high=h;
10:  
11:  /* partition the data set around the pivot value */
12:  while (l<=h)
13:  {
14:    while (a[l]<pivot)
15:      l++;
16:    while (a[h]>pivot)
17:      h--;
18:    if (l<=h)
19:    {
20:      int tmp=a[l];
21:      a[l]=a[h];
22:      a[h]=tmp;
23:      l++;
24:      h--; 
25:    }
26:  }
27:  
28:  /* sort items below and above the pivot */
29:  qsort(a,low,l-1);
30:  qsort(a,l,high);
31:  
32:  }

A fair amount of time and detail is spent dealing with the low level movement of data within the array . This is important – good stuff, but it takes the emphasis away from the higher level elegance of the algorithm.

The quicksort can be described as:

1. If the size of the list is <= 1, return.
2. 1. Select a pivot element
   2. Generate the list L of items smaller than the pivot
   3. Generate the list H of items larger than the pivot
   4. the sorted list is qsort(L)+pivot+qsort(R)

Having seen some scheme in their intro class, our students have a tool with which we can describe the quicksort in terms much closer to the description (allowing for the fact that this doesn't deal with multiple values equal to the pivot correctly):

 1:  (define makefilter
 2:    (lambda (op x)
 3:      (lambda (n) (op x n))))
 4:  
 5:  (define qsort 
 6:    (lambda (l)
 7:      (cond ((null? l) '())
 8:            (else (append (qsort (filter (makefilter > (car l)) l))
 9:                          (list (car l))
10:                          (qsort (filter (makefilter < (car l)) l)))))))

This allows us to discuss the quicksort at a much higher level and focus on things like selecting a good pivot or the analysis of the run time. I believe this makes it much easier to really understand what's going on.

Having discussed it in this functional context, we can also look at the same thing in a scripting language such as python:

1:  def qsort(l):
2:      if len(l)<=1:
3:          return l
4:      else:
5:          return qsort([x for x in l[1:] if x <= l[0]]) + [l[0]]+\
6:              qsort([x for x in l[1:] if x > l[0]])
7:  

Again, the focus is on the algorithm, not the array or list manipulation.

Looking at the problem from both the more abstract side, which in this case functional languages allow, and the more concrete, as we did in Java gives our students more tools with which to attack problems.

Just some food for thought.

They teach programming, don't they?

One evening, many years ago, when I was in college, I had an epiphany. Maybe not as enlightening as the epiphany I had while watching "The Mummy Returns"  many years later, but that's a story for another day.

While working on some class project, I realized that soon, within a couple of  years, I'd be working for a real company and I'd actually have to write code that REALLY works. Not just something that gets past the grader, or answers all the test cases. Something well designed, well written, maintainable, and reliable.  Scary thought.

I've thought about this a lot since I started teaching computer science. We teach programming languages, algorithms, and assign projects. Maybe the students hear something like "comment your code," or "use good variable names," but we never really give them the tools to take a project from description to completion.

Too often young programmers rush to the keyboards and write copious amounts of code without any plan and with little discipline. In short they do everything they can to set themselves up for a difficult road ahead.

There are probably a number of reasons for this. When we teach introductory  programming, assignments are so short and simple that we can't easily model good programming techniques, and if we do, it's difficult to get students to "buy in" since it's hard for them to see the value. As complexity increases, we're faced with limited time to actually cover the prescribed course content, leaving little room for a protracted unit on "program development."

I'm certainly not going to be so bold as to say that I have the answer to the problem, but I've tried some things to help address it.

We'll take a few class days to take a project from beginning to end. Something that can be done incrementally but isn't particularly difficult.

This semester, I attempted this with my AP students. We wrote a series of text filters in Java. I lifted the topic from Kernighan and Plauger's "Software Tools." We wrote versions of character count, word count, detabbing a file, run length encoding and a simple version of tr. Nothing too heavy, but it allowed us to focus on the development piece rather than coming up with clever algorithms and data structures (which is what the rest of the class is for). The problem may be a little contrived, but I hope the benefits outweighed any issues with the choice of problem.

We start by talking about the importance of understanding the problem, which includes finding out what "the client" wants and not making our own assumptions. Some times, I try to leave a little ambiguity to give us a platform to discuss the "what the client wants" issue.

From there comes design, which might be mixed with writing some code to make sure we understand certain aspects of the problem and the environment we'll be working in.

Once we have a design and a plan we can start incremental development. This is what I think is most important for the youngsters. I try to model and emphasize the idea of coding one "concept" at a time. Frequently testing that concept and only moving on once it's completed.

I'll also talk about things that have worked for me along the way. I always like to put consistent comment blocks at the top of my functions, trying to keep functions a "screen length" or shorter, my preferences for naming, indentation, etc. Of course, I'm careful to emphasize that my way works for me, but it's just one approach. I try to present alternatives when possible.

Other ideas I try to emphasize is actually reading ones code and having others read it. Last semester I experimented with "pair programming" and while I have no idea how good it is as a professional development technique, I like it from a pedagogical point of view.

I think presenting these ideas while actually developing the project helps to drive in the concepts.

I'd like to think adding units like this helps to develop stronger programmers. Any teachers out there -- your thoughts?







In an unrelated note, yesterday was valentines day. We don't really do anything to celebrate it, but in anticipation of her new loom, Devorah had to clear off some room in the apartment. She stumbled upon love letters sent between my parents back in the fifties. If you'd like a small taste of the past, you can see here post on squidknits here.

Although we have gained all this immediacy with the electronics age, it sometimes feels that somethings been lost.

Subversion in the classroom

Ok, not subversion, rather subversion, the version control system.

I've used subversion as a way for students to hand in their projects for years. I haven't used it with my intro classes as I think the learning curve is a little steep and the benefits few, but for A.P. and beyond (juniors and seniors) it's worked very well as a method of collection and I think it's good to get the kids in the habit of using versioning systems.

A versioning, or revision control system let's an individual frequently save versions of their files, in our case, on a central server.  One can easily go back to earlier versions as well as manage changes made by multiple developers. Once one's in the habit of using a revision control system, it can greatly improve  productivity.

For my classes, I would create a repository for a project, give the kids a little version control primer, and they would create projects in the repository.

There are usually a few bumps in the road.

At first the kids go kicking and screaming. They create the repository, and neglect it until the last minutes. I'd wake up on a project due date, check out the repository and seem maybe 4 out of 60 projects only to see them mystically appear as the closing time approached.

As we move through the year and work on more projects, things get better.

Students start to update their projects more frequently. Not as frequently as I like, partly because SVN gets really slow on our system, but it's still an improvement.  Invariably, it saves a student or two when they accidentally delete all their files. Also, when things become  a real mess, being able to go back a few versions is a godsend. A much better alternative than what they had to do in the past, which was restarting the entire project.



What I find really interesting is how wonderful a tool svn is from my point of view as an educator.

By looking at the log files, I can see who made changes and when. By looking at the diffs, I can look at the projects progress much as an english teacher might look at drafts.

 Version control for projects turns out to be a win across the board.

Recently, I've been using SVN for homeworks as well. Homework collection has always been difficult for me as I'm disorganized and forgetful. SVN has made things much easier. At the start of the semester, I made a homework repository for each student. They then check it out at home.

Whenever a student does a homework, he or she just names it according to our conventions (HW1-name, HW2-name, etc.), put it in their checked out repository, add the file(s) and commits. With tortoiseSVN under windows it's trivial.

This lets me easily see all of the homeworks for a student as well as all submissions for a specific assignment. Again it's an overall win.

Next semester I'm going to be experimenting with GIT as a replacement for SVN.

If you're looking for a way to collect and track assignments, I'd highly recommend using a revision control system.

Talking Shop

During my first few years teaching computer science, I frequently felt isolated. As pretty much the only CS guy I really didn't have any one to "talk shop" with. It's hard to bounce pedagogical ideas off of your colleagues when they teach subjects that are tangentially related, at best.

I now consider myself extremely fortunate that I have four terrific friends and colleagues teaching CS with me. Now we have the same advantage that other teachers have enjoyed for years.

Today I started one of my favorite topics in my AP classes, recursion. Our students have already done recursion during the scheme unit of our intro class so today was at some levels, a review. Most of the students were fine with the basic concepts, but I wanted to make sure they had a solid foundation before we moved to more advanced problems.

I realized even though I "got" recursion back when I was starting out as a CS student those many years ago, no one ever really explained how the call stack worked. When you're calling functions and methods all over the place, how does the system know to return to the right place at the right time. It was alluded to when we expanded a recursion:

fact(4) –> 4*fact(3) –> 3*fact(2) –> 2*fact(1) –> 1*fact(0) –> 1

but never in the general sense of function calls. I thought it might make sense to try to "demystify" the computer and explain how things really worked.

I outlined a basic memory layout, stack, heap, data segment and roughly defined a stack frame (storing parameters, local variables, and a return address). We then looked at a code snippet such as:

a()
{
  b();
  c();
}

b()
{
  c();
}

c()
{
}

main()
{
  a();
  b();
}

and traced through the stack. We then did this with a couple of simple recursive examples. Only time will tell if this was helpful, but I think it was worth the time.

What I particularly enjoyed was later that day when I was talking shop with my fellow AP teacher. He wasn't planning on explaining the stack in this kind of detail but he liked the idea and planned to use that part of my lesson. I look forward to hearing how it went.

I have likewise borrowed ideas from his and our other colleagues classes.

Any CS teachers out there, I'm sure we'd all love to hear classroom techniques that have and haven't worked.