March 26, 2008 7:27 AM

Data-Intensive Computing and CS Education

An article in the March 2008 issue of Computing Research News describes a relatively new partnership among NSF, Google, and IBM to help the academic computing "explore innovative research and education ideas in data-intensive computing". They define data-intensive computing a new paradigm in which the size of the data dominates all other performance features. Google's database of the web is one example, but so are terabytes and petabytes of scientific data collected from satellites and earth-bound sensors. On the hardware side of the equation, we need to understand better how to assemble clusters of computers to operate on the data and how to network them effectively. Just as important is the need to develop programming abstractions, languages, and tools that are powerful enough so that we mortals can grasp and solve problems at this massive scale. Google's Map-Reduce algorithm (an idea adapted from the functional programming world) is just a start in this direction.

This notion of data-intensive computing came up in two of the plenary addresses at the recent SIGCSE conference. Not surprisingly, one was the talk by Google's Marissa Mayer, who encouraged CS educators to think about how we can help our students prepare to work within this paradigm. The second was the banquet address by Ed Lazowska, the chair of Washington's Computer Science department. Lazowska's focus was more on the need for research into the hardware and software issues that undergird computing on massive data sets. (My notes on Lazowska's talk are still in the works.)

This recurring theme is one of the reasons that our Hot Topic group at ChiliPLoP began its work on the assembly and preparation of large data sets for use in early programming courses. What counts as "large" for a freshman surely differs from what counts as "large" for Google, but we can certainly begin to develop a sense of scale in our students' minds as they write code and see the consequences of their algorithms and implementations. Students already experience large data in their lives, with 160 GB video iPods in their pockets. Having them compute on such large sets should be a natural step.

The Computing Research News also has an announcement of a meeting of the Big-Data Computing Study Group, which is holding a one-day Data-Intensive Computing Symposium today in Sunnyvale. I don't know how much of this symposium will report new research results and how much will share background among the players, in order to forge working relationships. I hope that someone writes up the results of the symposium for the rest of us...

Though our ChiliPLoP group ended up working on a different project this year, I expect that several of us will continue with the idea, and it may even be a theme for us at a future ChiliPLoP. The project that we worked on instead -- designing a radically different undergraduate computer science degree program -- has some currency, though, too. In this same issue of the CRN, CRA board chair Dan Reed talks about the importance of innovation in computing and computing education:

As we debate the possible effects of an economic downturn, it is even more important that we articulate -- clearly and forcefully -- the importance of computing innovation and education as economic engines.

[... T]he CRA has created a new computing education committee ... whose charge is to think broadly about the future of computing education. We cannot continue the infinite addition of layers to the computing curriculum onion that was defined in the 1970s. I believe we need to rethink some of our fundamental assumptions about computing education approaches and content.

Rethink fundamental assumptions and start from a fresh point of view is just what we proposed. We'll have to share our work with Reed and the CRA.

Posted by Eugene Wallingford | Permalink | Categories: Computing, Teaching and Learning

March 20, 2008 4:21 PM

SIGCSE Day 2 -- Plenary Address by Marissa Mayer

[A transcript of the SIGCSE 2008 conference: Table of Contents]

Marissa Mayer

The second day of the conference opened with the keynote address by Google's VP of Search Products and User Experience, Marissa Mayer. She was one of the early hires as the company expanded beyond the founders, and from her talk it's clear that she has been involved with a lot of different products in her time there. She is also something the discipline of computer science could use more of, a young woman in a highly-visible technical and leadership and roles. Mayer is a great ambassador for CS as it seeks to expand the number of female high-school and college students.

This talk was called Innovation, Design, and Simplicity at Google and illustrated some of the ways that Google encourages creativity in its employees and gets leverage from their ideas and energy. I'll drop some of her themes into this report, though I imagine that the stories I relate in between may not always sync up. Such is the price of a fast-moving talk and five days of receding memory.

Creativity loves constraint.

I have written on this topic a few times, notably in the context of patterns, and it is a mantra for Google, whose home page remains among the least adorned on the web. Mayer said that she likes to protect its minimalist feel even when others would like to jazz it up. The constraints of a simple page force the company to be more creative in how it presents results. I suspect it also played a role in Google developing its cute practice of customizing the company logo in honor of holidays and other special events. Mayer said that minimalism may be a guide now, but it was not necessarily a reason for simplicity in the beginning. Co-founder Sergey Brin created the first Google home page, and he famously said, "I don't do HTML."

Mayer has a strong background both in CS and in CS education, having worked with the undergrad education folks at Stanford as a TA while an undergrad. (She said that it was Eric Roberts who first recommended Google to her, though at the time he could not remember the company's name!) One of her first acts as an employee was to run a user study on doing search from the Google homepage. She said that when users first sat down and brought up the page, they just sat there. And sat there. They were "waiting for the rest of it"! Already, users of the web were already accustomed to fancy pages and lots of graphics and text. She said Google added its copyright tag line at the bottom of the page to serve as punctutation, to tell the user that that's all there was.

Search is a fixed focus at Google, not a fancy user interface. Having a simple UI helps to harness the company's creativity.

Work on big problems, things users do every day.

Work on things that are easy to explain and understand.

Mayer described in some detail the path that a user's query follows from her browser to Google and back again with search results. Much of that story was as expected, though I was surprised by the fact that there are load balancers to balance the load on the load balancers that hand off queries to processors! Though I might have thought that another level of indirection would slow the process it down, indeed it is necessary in order to ensure that the system doesn't slow down. Even with the web server and the ad server and the mixers, users generally see their results in about 0.2 seconds. How is that for a real-time constraint to encourage technical creativity?

Search is the #2 task performed on the web. E-mail is (still) #1. Though some talking heads have begun to say that search is a mature business in need of consolidation, Google believes that search is just getting started. We know so little about how to do it well, how to meet the user's needs, and how to uncover untapped needs. Mayer mentioned a problem familiar to this old AI guy: determining the meaning of the words used in a query so that they can serve pages that match the user's conceptual intent. She used a nice example that I'll probably borrow the next time I teach AI. When a user asks for an "overhead view", he almost always wants to see a picture!

This points in the direction of another open research area, universal search. The age in which users want to search for text pages, images, videos, etc., as separate entities has likely passed. That partitioning is a technical issue, not a user's issue. The search companies will have to find a way to mix in links to all kinds of media when they serve results. For Google, this also means figuring out how to maintain or boost ad revenue when doing so.

Ideas come from everywhere.

Mayer gave a few examples. One possible source is office hours, which are usually thought of as an academic concept but which she has found useful in the corporate world. She said that the idea for Froogle walked through her office door one day with the scientist who had it.

Another source is experiments. Mayer told a longer story about Gmail. The company was testing it in-house and began to discuss how they could make many from it. She suggested the industry-standard model of giving a small amount of storage for free and then charging for more. This might well have worked, because Google's cost structure would allow it to offer much larger amounts at both pricing levels. But a guy named Paul -- he may be famous, but I don't know his last name -- suggested advertising. Mayer pulled back much as she expected users to do; do people really want Google to read their e-mail and serve ads? Won't that creep them out?

She left the office late that night believing that the discussion was on hold. She came back to work the next morning to find that Paul had implemented an experimental version in a few hours. She was skeptical, but the idea won her over when the system began to serve ads that were perfectly on-spot. Some folks still prefer to read e-mail without ads, but the history of Gmail has shown just how successful the ad model can be.

The insight here goes beyond e-mail. The search ad data base can be used on any paged on the web. This is huge... Search pages account for about 5% of the pages served on the web. Now Google knew that they could reach the other 95%. How's that for a business model?

To me, the intellectual lesson is this:

If you have an idea, try it out.

This is a power that computer programmers have. It is one of the reasons that I want everyone to be able to program, if only a little bit. If you have an idea, you ought to be able to try it out.

Not every idea will lead to a Google, but you never know which ones will.

Google Books started as a simple idea, too. A person, a scanner, and a book. Oh, and a metronome -- Mayer said that when she was scanning pages she would get out of rhythm with the scanner and end up photocopying her thumbs. Adding a metronome to the system smoothed the process out.

... "You're smart. We're hiring." worked remarkably well attracting job candidates. We programmers have big egos! Google is one of the companies that has made it okay again to talk about hiring smart people, not just an army of competent folks armed with a software development process, and giving them the resources they need to do big things.

Innovation, not instant perfection.

Google is also famous for not buying into the hype of agile software development. But that doesn't mean that Google doesn't encourage a lot of agile practices. For example, at the product level, it has long practiced a "start simple, then grow" philosophy.

Mayer contrasted two kinds of programmers, castle builders and nightly builders. Companies are like that, too. Apple -- at least to outside appearances -- is a castle-building company. Every once in a while, Steve Jobs et al. go off for a few years, and then come back with an iPod or an iPhone. This is great if you can do it, but only a few companies can make it work. Google is more of a nightly builder. Mayer offered Google News as a prime example -- it went through 64 iterations before it reached its current state. Building nightly and learning from each iteration is often a safer approach, and even companies that are "only good" can make it work. Sometimes, great companies are the result.

Data is a-political.

Mayer didn't mean Republican versus Democrat here, rather that well-collected data provide a more objective basis for making decisions than the preferences of a manager or the guesses of a designer or programmer. Designing an experiment that will distinguish the characteristics you are in interested, running it, and analyzing the data dispassionately are a reliable way to make good decisions. Especially when a leader's intuition is wrong, such as Mayer's was on Gmail advertising.

She gave a small plug for using Google Trends as a way to observe patterns in search behavior when they might give an idea about a question of interest. Query volume may not not change much, but the content of the queries does.

Users, users, users.

What if some users want more than the minimalist white front page offered by Google? In response to requests from a relatively small minority of users -- and the insistent voices of a few Google designers -- iGoogle is an experiment in offering a more feature-filled portal experience. How well will it play? As is often the case, the data will tell the story.

Give license to dream.

Mayer spent some time talking about the fruits of Google's well-known policy of 20% Time, whereby every employee is expected to spend 1/5 of his or her time working on projects of personal interest. While Google is most famous for this policy these days, like most other ideas it isn't new. At ChiliPLoP this week, Richard Gabriel reported that Eric Schmidt took this idea to Google with him when he left Sun, and Pam Rostal reported that 3M had a similar policy many years ago.

But Google has rightly earned its reputation for the fruits of 20% Time. Google News. Google Scholar. Google Alerts. Orkut. Froogle Wireless. Much of Google Labs. Mayer said that 50% of Google's new products come from these projects, which sounds like a big gain in productivity, not the loss of productivity that skeptics expect.

I have to think that the success Google has had with this policy is tied pretty strongly with the quality of its employees, though. This is not meant to diss the rest of us regular guys, but you have to have good ideas and the talent to carry them out in order for this to work well. That said, these projects all resulted from the passions of individual developers, and we all have passions. We just need the confidence to believe in our passions, and a willingness to do the work necessary to implement them.

Most of the rest of Mayer's talk was a litany of these projects, which one wag in the audience called a long ad for the goodness of Google. I wasn't so cynical, but I did eventually tire of the list. One fact that stuck with me was the description of just how physical the bits of Google Earth are. She described how each image of the Earth's surface needs to be photographed at three or four different elevations, which requires three or four planes passing over every region. Then there are the cars driving around taking surface-level shots, and cameras mounted to take fixed-location shots. A lot of physical equipment is at work -- and a lot of money.

Share the data.

This was the last thematic slogan Mayer showed, though based on the rest of the talk I might rephrase it as the less pithy "Share everything you can, especially the data." Much of Google's success seems based in a pervasive corporate culture of sharing. This extends beyond data to ideas. It also extends beyond Google campus walls to include users.

The data-sharing talk led Mayer to an Easter Egg she could leave us. If you check Google's Language Tools page, you will see Bork, Bork, Bork, a language spoken (only?) by the Swedish chef on the Muppets. Nonetheless, the Bork, Bork, Bork page gets a million hits a year (or was it a day?). Google programmers aren't the only ones having fun, I guess.

Mayer closed with suggestions for computer science educators. How might we prepare students better to work in the current world of computing? Most of her recommendations are things we have heard before: build and use applications, work on large projects and in teams, work with legacy code, understand and test at a large scale, and finally pay more attention to reliability and robustness. Two of her suggestions, though, are ones we don't hear as often and link back to key points in her talk: work with and understand messy data, and understand how to use statistics to analyze the data you collect.

After the talk, folks in the audience asked a few questions. One asked how Google conducts user studies. Mayer described how they can analyze data of live users by modding the key in user cookies to select 1/10 or 1/1000 of the user population, give those users a different experience, and then look at characteristics such as click rate and time spent on page by these users compared to the control group.

The best question was in fact a suggestion for Google. Throughout her talk, Mayer referred repeatedly to "Google engineers", the folks who come up with neat ideas, implement them in code, test them, and then play a big role in selling them to the public. The questioner pointed out that most of those "engineers" are graduates of computer science programs, including herself, Sergey Brin, and Larry Page. He then offered that Google could do a lot to improve the public perception of our discipline if it referred to its employees as computer scientists.

I think this suggestion caught Mayer a little off-guard, which surprised me. But I hope that she and the rest of Google's leadership will take it to heart. In a time when it is true both that we need more computer science students and that public perception of CS as a discipline is down, we should be trumpeting the very cool stuff that computer scientists are doing at places like Google.

All in all, I enjoyed Mayer's talk quite a bit. We should try to create a similarly creativity-friendly environment for our students and ourselves. (And maybe work at a place like Google every so often!)

Posted by Eugene Wallingford | Permalink | Categories: Computing, Software Development, Teaching and Learning

March 19, 2008 12:40 AM

A Change in Direction at ChiliPLoP

As I mentioned in my last SIGCSE entry, I have moved from carefree Portland to Carefree, Arizona, for ChiliPLoP 2008. The elementary patterns group spent yesterday, its first, working on the idea of integrating large datasets into the CS curriculum. After a few years of working on specific examples, both stand-alone and running, we started this year thinking about how CS students can work on real problems from many different domains. In the sciences, that often means larger data sets, but more important it means authentic data sets, and data sets that inspire students to go deeper. On the pedagogical side of the ledger, much of the challenge lies in finding and configuring data sets so that they can used reliably and without unnecessary overhead placed on the adopting instructor.

This morning, we volunteered to listen to a presentation by the other hot topic group on its work from yesterday: a "green field" thought experiment designing an undergrad CS program outside of any constraints from the existing university structure. This group consists of Dave West and Pam Rostal, who presented an earlier version of this work at the OOPSLA 2005 Educators' Symposium, and Richard Gabriel, who brings to the discussion not only an academic background in CS and a career in computer science research and industry but also an MFA in poetry. Perhaps the key motivation for their hot topic is that most CS grads go on to be professional software developers or CS researchers, and that our current way of educating them doesn't do an ideal job of preparing grads for either career path.

Their proposal is much bigger than I can report here. They started by describing a three-dimensional characterization of different kinds of CS professionals, including provocative and non-traditional labels as "creative builder", "imaginative researcher", and "ordinologist". The core of the proposal is the sort of competency-based curriculum that West and Rostal talked about at OOPSLA, but I might also describe it as studio-based, apprenticeship-based, and project-based. One of their more novel ideas is that students would learn everything they need for a liberal arts, undergraduate computer science education through their software projects -- including history, English, writing, math, and social science. For example, students might study the mathematics underlying a theorem prover while building a inference engine, study a period of history in order to build a zoomable timeline on the web for an instructional web site, or build a Second Life for a whole world in ancient Rome.

In the course of our discussion, the devil's advocates in the room raised several challenging issues, most of which the presenters had anticipated. For example, how do the instructors (or mentors, as they called them) balance the busy work involved in, say, the students implementing some Second Life chunk with the content the students need to learn? Or how does the instructional environment ensure that students learn the intellectual process of, say, history, and not just impose a computer scientist's worldview on history? Anticipating these concerns does not mean that they have answers, only that they know the issues exist and will have to be addressed at some point. But this isn't the time for self-censorship... When trying to create something unlike anything we see around us, the bigger challenge is trying to let the mind imagine the new thing without prior restraint from the imperfect implementations we already know.

We all thought that this thought experiment was worth carrying forward, which is where the change of direction comes in. While our group will continue to work on the dataset idea from yesterday, we decided in the short term to throw our energies into the wild idea for reinventing CS education. The result will be two proposals to OOPSLA 2008: one an activity at the Educators' Symposium, and the other an Onward! paper. This will be my first time as part of a proposal to the Onward! track, which is both a cool feeling and an intimidating prospect. We'll see what happens.

Posted by Eugene Wallingford | Permalink | Categories: Computing, Software Development, Teaching and Learning

March 18, 2008 1:08 PM

SIGCSE Day 3 -- Expectation and Outcome

[A transcript of the SIGCSE 2008 conference: Table of Contents]

This was a tale of two sessions, two different expectations, and two results.

First came a session on Nifty Objects. After seeing this one, my sarcastic side envisioned a one-word report: Not. But then I cam to my senses and realized that I wasn't being fair. A couple of the presentations were okay. The problem was in using the word "nifty" in the title of the session. As I alluded in my post on this year's Nifty Assignments session, the word Nifty creates a brand expectation that even the originators of the panel have had a hard time living up to. I tried to recreate the nifty assignments magic at the OOPSLA'04 Educators' Symposium, but the assignments weren't quite nifty enough or the presentations quite dynamic enough to succeed wildly.

So to be fair, all I can really say about this panel is that expectations for its niftiness surpassed what it delivered. At this point, I'd say that using the word "nifty" in a session title is a recipe for overextended expectations.

Then came a session called "It Seemed Like a Good Idea at the Time". I commented positively on last year's panel of the same name, but I wasn't sure what to expect this year. First, I honestly don't remember many details from last year's, other than the guy whose intro students crashed the university network with a flood of Java-generated e-mail. Second, this year's panel didn't have a bunch of "big names" with a reputation for making a session a hit. So my expectations were not all that high. But, as I wrote last year, I like the idea of seeing an idea fail, so I gave it a chance. The session was a lot of fun, better than expected. Every presenter told a good story. After Dan Garcia went, I worried about the folks to follow, because he killed. The folks who followed more than held their own.

So this panel exceeded my expectations. Unfortunately, I can't tell you much about the content of the presentations. What made the session enjoyable was the storytelling, and I can't do the stories justice by retelling them here. I suppose that I should be able to give you a list of the lessons learned -- red flags to watch for in some big ideas, but I can't even do that. I haven't forgotten all the details yet (though ChiliPloP is starting to fill up my limited memory)! I recall Dan Garcia talking about a bad experience with giving an exam with no time limits and Caroline Eastman, I think, talking about just how hard it turned out to be to alphabetize a list of names in the face of international standards.

The individual stories were about very specific instances. The one general lesson I draw from the panel these two years is that any idea, however well thought out, can go awry in the most unexpected ways. Be prepared for that to happen, be prepared to adapt in real-time, and be prepared to take advantage of the experience to help students learn what they can. And loosen up -- if your assignment or exam goes unexpectedly wrong, you probably haven't scarred your students for life or harmed them irreparably. They may even have learned something valuable they wouldn't otherwise have learned.

Posted by Eugene Wallingford | Permalink | Categories: Teaching and Learning

March 17, 2008 4:18 PM

SIGCSE Day 1 -- Innovating our Image

[A transcript of the SIGCSE 2008 conference: Table of Contents]

Owen Astrachan and Peter Denning

I ended the first day by attending a two-man "panel" of NSF's inaugural CISE Distinguished Educational Fellows, Owen Astrachan and Peter Denning. The CDEF program gives these two an opportunity to work on wild ideas having the potential "to transform undergraduate computing education on a national scale, to meet the challenges and opportunities of a world where computing is essential to U.S. leadership and economic competitiveness across all sectors of society." A second-order effect of these fellowships is to have a soapbox (Denning) or bully pulpit (Astrachan) to push their ideas out into the world and, more important, to encourage the rest of the community to think about how to transform computing education, whether on the CDEF projects or on their own.

Owen went first. He opened by saying that the CDEF call for proposals had asked for "untested ideas", and if he couldn't propose one of those, well... I've mentioned his Problem Based Learning learning project here before, as part of an ongoing discussion of teaching that is built around real problems, projects, and meaningful context. Owen's talk described some of the motivation for his project and the perceived benefits. I'll try to report his talk faithfully, but I suspect that some of my own thoughts will creep in.

When we talk to the world as we talk among ourselves -- about choices of programming language, IDE, operating systems, ... -- we tell the world that tools are the coin of our realm. When an engineer comes to us and asks for a course using MATLAB, we may be 100% technically correct to respond "Python is better than MATLAB. Here's why..." -- but we send the wrong message, a damaging message, which makes it the wrong response.

We can engage those folks better if we talk to them about the problems they need help solving. In many ways, that is how computing got its start, and it is time for us again to look outside our discipline for problems to solve, ideas to explore, and motivation to advance the discipline. Increasingly, outside our discipline may well be the place for us to look for learners, as fewer folks express interest in computing for computing's sake and as more non-computing look for ways to integrate computing into their own work. (Like scientists and even artists.)

That is one motivation for the PBL project. Another was the school Owen's children attend, where all learning is project-based. Students work on "real" problems that interest them, accumulating knowledge, skill, and experience as they work on increasingly challenging and open-ended projects. Problems have also driven certain kinds of scientific professional education at the university level for many decades.

For the first time in any of his talks I've seen, Owen took some time to distinguish problem-based learning from project-based learning. I didn't catch most of the specific differences, but Owen pointed us all to the book Facilitating Problem-Based Learning by Maggi Savin-Baden for its discussion of the differences. This is, of course, of great interest to me, as I have been thinking a lot in the last year or more about the role project-based courses can play in undergraduate CS. Now I know where to look for more to think about.

As a part of eating his own dog food, Owen is trying to ratchet up the levelof dialogue in his own courses this year by developing assignments that are based on problems, not implementation techniques. One concrete manifestation of this change is shorter write-ups for assignments, which lay out only the problem to be solved and not so much of his own thinking about how students should think about the problem. He likened this to giving his students a life jacket, not a straitjacket. I struggle occasionally with a desire to tie my students' thinking up with my own, and so wish him well.

Where do we find problems for our CS majors to work on? Drawing explicitly from other disciplines is one fruitful way, and it helps CS students see how computing matters in the world. We can also draw from applications that young people see and use everyday, which has the potential to reach an even broader audience and requires less "backstory". This is something the elementary patterns folks have worked on at ChiliPLoP in recent years, for example 2005. (Ironically, I am typing this in my room at the Spirit in the Desert Retreat Center, as I prepare for ChiliPLoP 2008 to begin in the morning. Outside my window is no longer rainy Portland but a remarkably cold Arizona desert.)

Owen said we only need to be alert to the possibilities. Take a look at TinyURL -- there are several projects and days of lecture there. Google the phrase dodger ball; why do we get those results? You can talk about a lot of computer science just by trying to reach an answer.

After telling us more about his NSF-funded project, Owen closed with some uplifting words. He hopes to build a community around the ideas of problem-based learning that will benefit from the energy and efforts of us all. Optimism is essential. Revolutionizing how we teach computing, and how others see computing, is a daunting task, but we can only solve problems if we try.

Denning took the stage next. He has long been driven by an interest in the great principles of computing, both as a way to understand our discipline better and as a way to communicate our discipline to others more effectively. His CDEF project focuses on the different "voices" of computing, the different ways that the world hear people in our discipline speak. In many ways, they correspond to the different hats that computing people wear in their professional lives -- or perhaps our different personalities in a collective dissociative identity disorder.

Denning identifies seven voices of computing: the programmer, the computational thinker, the user, the mathematician, the engineer, the scientist, and the "catalog". That last one was a mystery to us all until he explained it, when it became our greatest fear... The catalog voice speaks to students and outsiders in terms of the typical university course descriptions. These descriptions partition our discipline into artificial little chunks of wholly uninteresting text.

What makes these voices authentic? Denning answered the question in terms of concepts and practices. To set up his answer, he discussed three levels in the development of a person's understanding of a technology, from mystical ("it works") to operational (concrete models) to formal (abstractions). Our courses often present formal abstractions of an idea before students have had a chance to develop solid concrete models yet. We often speak in terms of formal abstraction to our colleagues from other disciplines. We would be more effective if instead we worked on their problems with them and helped them create concrete results that they can see and appreciate.

One advantage of this is that the computing folks are speaking the language of the problem, rather than the abstract language of algorithms and theory. Another is that it grounds the conversation in practices, rather than concepts. Academics like concepts, because they are clean and orderly, more than practices, which are messy and often admit no clean description. Denning asserts that voices are more authentic when grounded in practices, and that computing hurts itself whenever it grounds its speech in concepts.

His project also aims to create a community of people around his ideas. He mentioned something like a "Rebooting Computing" summit that will bring together folks interested in his CDEF vision and, more broadly, in inspiring a return to the magic and beauty of computing. Let's see what happens.

I heard several common threads running through Astrachan's and Denning's presentations. One is that we need to be more careful about how we talk about our discipline. Early on, Denning's said that we should talk about what computing is and how we do it, and not how we think about things. We academics may care about that, but no one else does. Later, Owen said that we should talk about computational doing, not computational thinking. These both relate to the intersection of their projects, where solving real problems in practice is the focus.

Posted by Eugene Wallingford | Permalink | Categories: Computing, Teaching and Learning

March 15, 2008 1:26 PM

Not an Example of Problem-Based Learning

Professor: Students, your next assignment is to implement an operating system in Scheme.

Student: But professor, I don't know Scheme.

Professor: That's your problem.

(At least Owen laughed.)

Posted by Eugene Wallingford | Permalink | Categories: Teaching and Learning

March 15, 2008 1:06 PM

SIGCSE Day 1 -- Nifty Assignments

[A transcript of the SIGCSE 2008 conference: Table of Contents]

Last year's Nifty Assignments at SIGCSE merited only a retro-chic reference in my blog. I thought that was unusual until I looked back and noticed that I mentioned it not at all in 2006 or 2005. I guess that's not too surprising. The first few years of the now-annual panel were full of excitement, as many of the best-known folks in the SIGCSE shared some of their best assignments. These folks are also among the better teachers you'll find, and even when their assignments were only okay their presentations alone were worth seeing. As the years have passed, the excitement of the assignments and presentations alike have waned, even as the panel remains a must-see for many at the conference.

Still, each year I seem to find some nugget to take home with me. This year's panel actually offered a couple of neat little assignments, and one good idea.

The good idea came late in Cay Horstmann's presentation: have students build a small application using an open-source framework, and then critique the design of the framework. In courses where we want students to discuss design, too often we only read code and talk in the abstract. The best way to "get" a design is to live with it for a while. One small app may not be enough, but it's a start.

One of the niftier assignments was a twist on an old standard, Huffman coding, that made it accessible to first-semester students. Creating a Huffman code is usually reserved for a course in data structures and algorithms because the technique involves growing a tree of character sets, and the idea of trees -- let alone implementing them -- is considered by most people beyond CS1 students. McGuire and Murtagh take advantage of a nifty fact: If you are interested only in determining how many bits you need to encode a sequence, not in doing the encoding itself, then all you need to do is execute the loop that replaces the two smallest values in the collection with their sum. A simple linear structure suffices, and the code comes to resemble the selection part of a selection sort.

This assignment gives you a way to talk to students about data compression and how different techniques give different compression rates. The other twist in this assignment is that McGuire and Murtagh apply the coding to images, not text strings. This is something I tried in my media computation CS1 in the fall of 2006, with both sounds and images. I liked the result and will probably try something like it the next time I teach CS1.

Catching Plagiarists image

The other assignment that grabbed my attention was Baker Franke's Catching Plagiarists. This assignment isn't all that much different from many of the common text processing tasks folks use in CS1, but it is framed in a way that students find irresistible: detecting plagiarism. I used to tell my intro students, "Copy and paste is your life", which always drew a few laughs. They knew just how true it was. With universal web access and the growth of Wikipedia, I think my claim is more true now than it was then, to the point that students think nothing of liberal re-use of others' words. This assignment gets students to think about just how easy it is to detect certain kinds of copying.

So, putting the task in a context that is meaningful and way relevant ups the niftiness factor by a notch or two. The fact that it can use a data sets both small and large means that the students can run head-first into the idea that some algorithms use much more time or space than others, and that their program may not have enough of one or both of these resources to finish the job on an input that they consider tiny -- a MB or two. (Heck, that's not even enough space for a decent song.)

Another thing I liked about this assignment is that it is, by most standards, underspecified. You could tell students this little: "Write a program to find the common word sequences among a set of documents. Your input will be a set of plain-text documents and a number n, and your output will be a display showing the number of n-word sequences each document has in common with every other document in the set." Franke presented his assignment as requiring little prep, with a simple problem statement of this sort, so I was a little disappointed to see that his assignment write-up is four pages with a lot more verbiage. I think it would be neat to simply tell the students the motivating story and then give them the five-line assignment. After students have had a chance to think about their approach, I'd like to talk to them about possibilities and help them think through the design.

Then again, I have to cut Franke some slack. He is a high school instructor, so his students are even younger than mine. I'm encouraged to think that high school students anywhere are working on such a cool problem.

Posted by Eugene Wallingford | Permalink | Categories: Computing, Teaching and Learning

March 14, 2008 3:36 PM

SIGCSE Day 1 -- The Mystery Problem

[A transcript of the SIGCSE 2008 conference: Table of Contents]

During the second session of the day, I bounced among several sessions, but the highlight was Stuart Reges talking about an interesting little problem -- not a problem he had, but a problem that appeared on the advanced placement exam in CS taken by high-school students. This problem stood out in an analysis of the data drawn from student performance on the 1988. Yes, that is twenty years ago!

Donald Knuth is famous for saying that perhaps only 2% of people have the sort of mind needed to be a computer science. He actually wrote, "I conclude that roughly 2% of all people 'think algorithmically', in the sense that they can reason rapidly about algorithmic processes." But is it that those 2% have that the rest do not? In his talk, Stuart read another passage from Knuth that speculates about one possible separator:

The other missing concept that seems to separate mathematicians from computer scientists is related to the 'assignment operation' :=, which changes values of quantities. More precisely, I would say that the missing concept is the dynamic notion of the state of a process. 'How did I get here? What is true now? What should happen next if m going to get to the end?' Changing states of affairs, or snapshots of a computation, seem to be intimately related to algorithms and algorithmic thinking.

In studying student performance on the 1988 AP exam, Reges found that performance on a small set of "powerhouse questions" was inordinately predictive of success on the exam as a whole, and of those five one stood out as most predictive. This question offers evidence in support of Knuth's speculation about "getting" assignment. Here it is:

If b is a Boolean variable, then the statement b := (b = false) has what effect?
  1. It causes a compile-time error message.
  2. It causes a run-time error message.
  3. It causes b to have value false regardless of its value just before the statement was executed.
  4. It always changes the value of b.
  5. It changes the value of b if and only if b had value true just before the statement was executed.

What a fun little question -- so simple, but with layers. It involves assignment, but also sequencing of operations, because the temporary result of (b = false) must be computed before assigning to b. (Do you know the answer?)

You can read about the correlations and much more about the analysis in Stuart's paper and slides, which are available on this resource page The full analysis may be interesting only to a subset of us, perhaps as few as 2%... I really enjoyed seeing the data and reading about how Stuart thought through the data. But here I'd like to think more about what this implies for how students reason, and how we teach.

This notion of state, the ability to take and manipulate "snapshots of a computation", does seem to be one of the necessary capabilities of students who succeed in computer science. With his speculation, Knuth is suggesting that how people think about computation matters. Stuart also quoted one of my heroes, Robert Floyd, who upon hearing an earlier version of this talk commented:

These questions seem to test whether a student has a model of computation; whether they can play computer in their head.

This is something folks in CS education think a lot about, but unfortunately we in then trenches teaching intro CS often don't apply what we know consistently or consciously. Whether we think about it or not, or whether we act on it or not, students almost certainly bring a naive computational model with them when they enter our courses. In the world of math and CS, we might refer to this as a naive operational semantics. How do variables work? What happens when an if statement executes? Or a loop? Or an assignment statement? I have read a few papers that investigate novice thinking about these issues, but I must confess to not having a very firm sense of what CS education researchers have studied and what they have learned.

I do have a sense that the physics education community has a more complete understanding of their students' naive (mis)understanding of the physical world and how to engage students there. (Unfortunately, doing that doesn't always help.)

Someone in the crowd suggested that we teach a specific operational semantics to students in CS1, as some authors do. That's a good idea complicated by the kinds of languages and programming models that we often teach. I think that we can do better just by remembering that our students have naive computational model in their heads and trying to find out how they understand variables, selection, loops, and assignments statements.

Stuart gave a great example of how he does this. He now sometimes asks his students this question:

public static int mystery(int n) {
    int x = 0;
    while (n % 2 == 0) {
        // Point A
        n = n / 2;
        // Point B
    // Point C
    return x;

Is (n % 2 == 0) always true, never true, or sometimes true/sometimes false at points A, B and C?

Stuart reported that many of his students think (n % 2 == 0) is always true at Point B because it's inside the loop, and the while loop condition guarantees that the condition is always true inside the loop. One wonders what these students think about infinite loops.

If we understand what students think in such basic situations, we are much better positioned to help students debug their programs -- and to write programs in a more reliable way. One way to help students learn and enjoy more is to give them tools to succeed. And recognizing when and how what students already think incorrectly is a prerequisite to that.

Plus, these are multiple-choice questions, which will make some students and professors even happier!

Posted by Eugene Wallingford | Permalink | Categories: Computing, Teaching and Learning

March 14, 2008 10:55 AM

SIGCSE Day 1 -- Randy Pausch and Alice

[A transcript of the SIGCSE 2008 conference: Table of Contents]

Last September, the CS education community was abuzz with the sad news that Randy Pausch, creator of the Alice programming environment, had suffered a recurrence of his cancer and that his condition was terminal. Pausch approached his condition directly and with verve, delivering a last lecture that became an Internet phenomenon. Just google "lecture"; as of today, Pausch's is the second link returned.

Because Pausch, his team, and Alice have had such an effect on the CS education community, and not just the virtual reality community in which they started, the folks at SIGCSE gambled that his health would hold out long enough for him to accept the SIG's 2008 Award for Outstanding Contribution to Computer Science Education in person and deliver a plenary address. Alas, it did not. Pausch is relatively well but unable to travel cross country. In his stead, Dennis Cosgrove, lead project scientist on the Alice project, and Wanda Dann, one of the curriculum development leads on the project, gave a talk on the history of Pausch's work and on what's next with Alice 3.0. The theme of the talk was building bridges, from virtual reality research to cognitive psychology and then to the fine arts, and a parallel path to CS education.

I admire Cosgrove and Dann for taking on this task. It is impossible to top Pausch's now-famous last lecture, which nearly everyone has seen by now. (If you have not yet, you should. It's an inspiring 104 minutes.) I'll let the video speak for Pausch and only report some of the highlights from Cosgrove and Dann.

Pausch's work began like so many new assistant professors' work does: on the cheap. He wanted to start a virtual reality lab but didn't have the money to "do it right". So he launched a quest to do "VR on $5 a day". Alice itself began as a rapid prototyping language for VR systems and new interaction techniques. As his lab grew, Pausch realized that to do first-class VR, he needed to get into perceptual research, to learn how better to shape the user's experience.

This was the first bridge he built, to cognitive psychology. The unexpected big lesson that he learned was this: What you program is not what people see. I think the teacher in all of us recognizes this phenomenon.

Next came an internship at Disney Imagineering, a lifelong dream of his. There, he saw the power of getting artists and engineers to work together, not just in parallel on the same project. One of the big lessons he learned was that it's not easy to do. Someone has to work actively to keep artists and engineers working together, or they will separate into their own element. But the benefits of the collaboration are worth the work.

Upon his return to CMU, he designed a course called Building Virtual Worlds that became a campus phenomenon. Students came to view building their worlds as a performing art -- not from the perspective of the "user", but thinking about how an audience would respond. I think this shows that computer science students are more than just techies, and that placed in the right conditions will respond with a much broader set of interests and behaviors.

In the last phase of his work, Pausch has been working more in CS education than in VR. In his notes on this talk, he wrote, "Our quest (which we did not even realize in the beginning) was to revolutionize the way computer programming is taught." So often, we start with one goal in mind and make discoveries elsewhere. Sometimes we get lost, and sometimes we just wander in an unexpected direction. I think many folks in CS education first viewed Alice as a way to teach non-majors, but increasingly folks realize that it may have a profound effect on how we teach -- and recruit -- majors. I was glad to be pointed in the direction of Pausch's student Caitlin Kelleher, whose PhD dissertation, "Motivating Programming: Using Storytelling to Make Computer Programming Attractive to Middle School Girls" is of great interest to me. (And not just as father to two girls!)

Cosgrove wrapped up his talk with a cartoon that seems to express Pausch's Think Big outlook on life. I won't try to show you the image (who needs another pre-cease-and-desist message from the same artist?), but will describe it: Two spiders have built a web across the bottom of the playground slide. One turns to the other and says, "If we pull this off, we will eat like kings." Pausch and his team have been weaving a web of Alice, and we may well reap big benefits.

Pausch's career teaches us one more thing. To accomplish big things, you need both a strong research result, in order to convince folks your idea might work, and you need strong personal connections, in order that funders will be able to trust you with their money and resources.

Thanks, Randy.

Posted by Eugene Wallingford | Permalink | Categories: Computing, Teaching and Learning

March 13, 2008 8:06 PM

SIGCSE Day 1 -- This and That

[A transcript of the SIGCSE 2008 conference: Table of Contents]

This sort of entry usually comes after I write up the various conference sessions and have leftovers that didn't quite fit in an article. That may still happen, but I already have some sense of what will go where and have these items as miscellaneous observations.

First of all, I tried an experiment today. I did not blog in real-time. I used -- gasp! -- the antiquated technology of pen and paper to take notes during the sessions. On one or two occasions, I whipped open the laptop to do a quick Google search for a PhD dissertation or a book, but I steadfastly held back from the urge to type. I took notes on paper, but I couldn't fall into "writing" -- crafting sentences, then forming paragraphs, editing, ... All I could do was jot, and because I write slowly I had to be pickier about what I recorded. One result is that I paid more attention to the speakers, and less to a train of thought in my head. Another is that I'll have to write up the blog posts off-line, and that will take time!

As I looked through the conference program last night, I found myself putting on my department head hat, looking for sessions that would serve my department in the roles I now find myself in more often: CS1 for scientists, educational policy in CS, and the like. But when I got to the site and found myself having to choose between Door A and Door B... I found myself drifting into the room where Stuart Reges was talking about a cool question that seems to pick out good CS students, and the nifty assignments. Whatever my job title may be, I am a programmer and CS teacher. (More on both of those sessions in coming entries...)

Now, for a couple of non-CS, non-teaching observations.

  • I am amazed at how many healthy adults will walk out of their way, past a perfectly good set of stairs, to ride up an escalator. Sigh.
  • Staying at the discount motel over three miles away and without a car, I am relying on public buses. I have quickly learned that bus schedules are suggestions, not contracts. Deal with it. And in Portland, that often means: deal with it in the rain.
  • Schoolchildren here take standard mass transit buses to school. I never knew such a place existed.

There is so much for me to learn.

Posted by Eugene Wallingford | Permalink | Categories: General, Personal

March 13, 2008 7:22 PM

Notes on SIGCSE 2008: Table of Contents

This set of entries records my experiences at SIGCSE 2008, in Portland, Oregon, March 12-16. I'll update it as I post new pieces about the conference. One of those entries will explain why my posts on SIGCSE may come more slowly than they might.

Primary entries:

Ancillary entries:

Posted by Eugene Wallingford | Permalink | Categories: Computing, Running, Software Development, Teaching and Learning

March 13, 2008 11:49 AM

Re-Upping for Three Years

My three-year review as department head is over, and a couple of weeks ago the dean asked me to serve a second three-year term. I accepted. My first three years went quickly, and as time passed my ideas for the department have evolved and come into better focus. I welcome the opportunity to work with the faculty to achieve them for three more years. Even still, I told the dean that I miss having more time to do computer science. Opportunities to teach and program are more valuable to me than ever before.

When I became head, I thought that I would find myself writing patterns to document my experience, but that has not happened. I spent much of my first three years in a bit of a haze, without any clear grasp on patterns of success in management, leadership, promotion, and the like. In retrospect, that isn't surprising, giving my near-complete lack of experience in these areas before starting!

Since re-upping, I have been thinking about some of the things I have learned in my first three years. Here are three. Maybe they will become parts of patterns at some point.

You have to be comfortable knowing and not doing.    I am something of a control freak and have had to learn to let my secretary and other faculty do things. For example, in today's world, technology makes it almost as easy for me to do a lot of clerical work, but time spent doing it is time not spent doing something else. On the flip side, I can't let not doing something being a reason not to know how to do it, or how it works. I need to be able to fill in when the person responsible is gone, and I have to understand how things work so that I can manage budgets, re-engineer processes, and the like.

Talking is doing something.    I am a programmer, and I like to make measurable progress. Like many folks who tend more toward introvert than extrovert, I tend to prefer doing to talking about doing. This is so even when I know intellectually the great importance of communication. Three years as head have taught be in a more visceral way the value of talking -- to faculty, to administrators, to business leaders and legislators, and to potential students and their patterns. The stories we tell to outsiders matter so very much. And the bonds we on the faculty build among ourselves, and the bonds we nurture between the head and the faculty, are essential to the functioning of the team that is the department.

You can't not be that guy.    No matter how much or how well a department head tries to communicate with the faculty in his or her charge, there is likely always going to be someone for whom the head is "the boss". Those relationships takes extra care, because you need to work on being part of the team at the same time you also work on being a good boss.

I hope that those are not the only things I have learned in the last three years, but they are a start.

Posted by Eugene Wallingford | Permalink | Categories: Managing and Leading

March 12, 2008 4:32 PM

On the Roads Back in Portland

SIGCSE 2008 logo

With the exception of my annual visit to Carefree for ChiliPLoP, I don't often get a chance to return to a city for another conference. This year brings a pleasant return to Portland for SIGCSE 2008. OOPSLA'06 was in Portland, and I wrote up a little bit about running in Portland as part of my first visit to town. Because I was on the conference planning committee that year, I made three trips to the city, stayed in the same hotel three times, and ran several of the same routes three times. The convention center is right in town, which makes it hard to get to any nice parks to run, but Portland has a 3-mile loop alongside the Willamette River that provides a decent run.

This time, I am on my own dime and trying to save a little money by staying at a budget motel about 3.5 miles from the convention center. That meant figuring out bus routes and bus stops for the ride between the two -- no small feat for a guy who has never lived in a place where public transportation is common! It also meant planning some new runs, including a route back to the waterfront.

I arrived in town early enough yesterday to figure out the buses (I think) and still have time for an exploratory run. I ran toward the river, and then toward the convention center, until I knew the lay of the land well enough. The result was 4.5 miles of urban running in neighborhoods I'd never seen. This morning, used what I learned to get to the river, where I ran my first lap through the Governor Tom McCall Waterfront Park and the Eastbank Esplanade since October 2006. I ended up with about 8 miles under my belt, and a strong desire to return Saturday evening for three laps and what will be a 14-miler -- what would be my longest run since the Marine Corps Marathon. Let's see how I feel in a couple of days...

The rest of this week I am at SIGCSE, and I'm looking forward to seeing old friends and colleagues and to talking CS for a few days. Then on Sunday, four of us fly to Phoenix for ChiliPLoP and some intense work. This is a long time to be away from home and to miss my family, but the ideas should keep me busy.

Posted by Eugene Wallingford | Permalink | Categories: General, Running

March 06, 2008 8:07 PM

An Odd Dinner Conversation

Last night, at dinner with my family, I casually mentioned this YouTube video in which Barack Obama answers a question from a Google interviewer about how to sort a million 32-bit integers. Obama gets a good laugh when he says that "the bubble sort would be the wrong way to go". My family knows that I enjoy pointing out pop references to CS, so I figured they'd take this one in stride and move.

But they didn't. Instead, they asked questions. What is "bubble sort"? Why do they call it that? As I described the idea, they followed with more questions and ideas of their own. I told them that bubble sort was the first sorting algorithm I ever learned, programming in BASIC as a junior in high school. My wife mentioned something like the selection sort, so I told them a bit about selection sort and insertion sort, and how they are considered "better" than bubble sort.

Why? they asked. That led us to Big-Oh notation and O(n²) versus (nlogn), and why the latter is better. We talked about how we can characterize an algorithm by its running time as proportional to n² or nlogn for some factor k, and the role that k plays in complicating our comparisons. I mentioned that O(n²) and a big k are part of the reason that bubble sort is considered bad, and that's what made the answer in the video correct -- and also why I am pretty sure that Obama did not understand any of the reasoning behind his answer, which is what made his deadpan confidence worth a chuckle.

(If you would like to learn more about bubble sort and have a chuckle of your own, read Owen Astrachan's Bubble Sort: An Archaeological Algorithmic Analysis (PDF), available from his web site.)

As the conversation wound down, we talked about how we ourselves sort things, and I got to mention my favorite sorting algorithm for day-to-day tasks, mergesort.

I suspect that my younger daughter enjoyed this conversation mostly for hearing daddy the computer scientist answer questions, but my wife and freshman daughter seemed to have grokked some of what we talked about. Honest -- this wasn't just me prattling on unprovoked. It was fun, yet strange. Maybe conversations like this one can help my daughters have a sense of the many kinds of things that computer scientists think about. Even if it was just bubble sort.

Posted by Eugene Wallingford | Permalink | Categories: Computing, Personal

March 05, 2008 2:05 PM

And the Winner Is...

The Prometheus Awards are the Iowa tech industry equivalent of the Academy Awards. At last night's 2008 award ceremony, CS alumni from my school made a good showing.

T8Design won Software Company of the Year in the Small Company Division. Alumnus Wade Arnold is one of T8's co-founders, its former CTO, and its current CEO. Wade accepted the statuette and gave a fine acceptance speech. At least two other alumni were there in the T8 delegation, and it was good to be able to congratulate them all in person.

Alliance Technologies won the award for IT Service Provider of the Year. Alumnus and UNI CS advisory board member Mike Lang, CEO and President of Alliance, represented the company on the dais.

There were two other software connections to our program among the winners. Alumnus Tony Bibbs was part of the team that wrote one of the pieces of software nominated for Best Innovation in Government, which was won by ABC Virtual. And the most distant connection involved Express Auto, which won Top Growth Company of the Year in the Under $25M Division. One of the first programs that got Express Auto off the ground back in the mid-1990s was written by a UNI alumnus and CS advisory board member Fred Zelhart.

It was a good evening for UNI Computer Science alumni, and a good night for this CS prof. With the exception of Mike, who graduated the year before I came here, I had all of these entrepreneurs and developers as students in class, and now I work with Mike, Fred, and Wade on an ongoing basis. I feel a little paternal -- now fraternal -- pride!

Posted by Eugene Wallingford | Permalink | Categories: Software Development

March 02, 2008 2:03 PM

Them's Fighting Words

This provocative statement appears in the Roly Perera essay that I mentioned recently:

All I know is that if there is a place for post-modernist, lit-crit, social constructivist thinking in the modern world, it's nowhere near the field of computing.

Robert Biddle and James Noble may have a duel on their hands (PDF)! I think that we have the makings of an outstanding OOPSLA 2008 panel.

I'd certainly like to hear more from Perera if he has more ideas of this sort:

... emergent behaviours are in a sense dual to the requirements on a solution. Requirements are known and obligate the system in certain ways, whereas emergent behaviours ("emergents", one could call them) are those which are permitted by the system, but which were not known a priori.

This is an interesting analogy, one I'd like to think more about. For some reason, it reminds of Jon Postel's dictum about protocol design, "Be liberal in what you accept, and conservative in what you send" and Bertrand Meyer's ideas about design by contract.

Posted by Eugene Wallingford | Permalink | Categories: Computing, Software Development

March 01, 2008 3:39 PM

Toward Less Formal Software

This week I ran across Jonathan Edwards's review of Gregor Kiczales's OOPSLA 2007 keynote address, "Context, Perspective and Programs" (which is available from the conference podcast page). Having recently commented on Peter Turchi's keynote, I figured this was a good time to go back and listen to all of Gregor's again. I first listened to part of it back when I posted it to the page, but I have to admit that I didn't understand it all that well then. So a second listen was warranted. This time I had access to his slides, which made a huge difference.

In his talk, Kiczales tries to bring together ideas from philosophy, language, and our collective experience writing software to tackle a problem that he has been working around his whole career: programs are abstractions, and any abstraction represents a particular point of view. Over time, the point of view changes, which means that the program is out of sync. Software folks have been thinking about ways to make programs capable of responding naturally as their contexts evolve. Biological systems have offered some inspiration in the last decade or so. Kiczales suggests that computer science's focus on formality gets in the way of us finding a good answer to our problem.

Some folks took this suggestion as meaning that we would surrender all formalism and take up models of social negotiation as our foundation. Roly Perera wrote a detailed and pointed review of this sort. While I think Perera does a nice job of placing Kiczales's issues in their philosophical context, I do not think Kiczales was saying that we should go from being formal to being informal. He was suggesting that we shouldn't have to go from being completely formal to being completely informal; there should be a middle ground.

Our way of thinking about formality is binary -- is that any surprise? -- but perhaps we can define a continuum between the two. If so, we could write our program at an equilibrium point for the particular context it is in and then, as the context shifts, allow the program to move along the continuum in response.

Now that I understand a little better what Kiczales is saying, his message resonates well with me. It sounds a lot like the way a pattern balances the forces that affect a system. As the forces change, a new structure may need to emerge to keep the code in balance. We programmers refactor our code in response to such changes. What would it be like for the system to recognize changes in context and evolve? That's how natural systems work.

As usual, Kiczales is thinking thoughts worth thinking.

Posted by Eugene Wallingford | Permalink | Categories: Computing, Patterns, Software Development