The explosive emergence of the Internet forces us to rethink the traditional roles for client, server, and objects. Component technology has emerged as the way objects and frameworks are packaged for flexible object integration. In particular, components allow users who are not programmers to do their own integration. Up until now, components have mainly focused on object integration on end-users desktops and on a client: compound documents, application assembly, etc.Existing component models like OpenDoc and Microsoft's OLE/OCX/COM provide function for compound documents, persistence, scripting, inking, and code management (registration). A series of Internet scenarios are emerging that demand new kinds of components. These scenarios are thin clients (Internet terminals), virtual reality/rich multimedia clients, collaboration, and business data access. Each panelist will explore one of these scenarios for it's requirements on an Internet component model.

We describe an object-oriented architecture for intelligent tutoring systems. The architecture is oriented around objects that represent the various knowledge elements that are to be taught by the tutor. Each of these knowledge elements, called bites, inherits both a knowledge organization describing the kind of knowledge represented and tutoring components that provide the functionality to accomplish standard tutoring tasks like diagnosis, student modeling, and task selection. We illustrate the approach with several tutors implemented in our lab.

article Free Access Share on Cognitive processes in programming (panel session) Authors: Jeff Bonar University of Pittsburgh University of PittsburghView Profile , Saj-Nicole Joni Yale University Yale UniversityView Profile , Barry Kurtz New Mexico State New Mexico StateView Profile , Dave Scanlan Illinois State Illinois StateView Profile , Chairman: Laurie Werth University of Nevada, Los Vegas University of Nevada, Los VegasView Profile Authors Info & Claims ACM SIGCSE BulletinVolume 17Issue 1Mar. 1985 pp 373–375https://doi.org/10.1145/323275.323408Online:01 March 1985Publication History 6citation198DownloadsMetricsTotal Citations6Total Downloads198Last 12 Months4Last 6 weeks2 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my AlertsNew Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteeReaderPDF

We present a process model to explain bugs produced by novices early in a programming course. The model was motivated by interviews with novice programmers solving simple programming problems. Our key idea is that many programming bugs can be explained by novices inappropriately using their knowledge of step-by-step procedural specifications in natural language. We view programming bugs as patches generated in response to an impasse reached by the novice while developing a program. We call such patching strategies bug generators. Several of our bug generators describe how natural language preprogramming knowledge is used by novices to create patches. Other kinds of bug generators are also discussed. We describe a representation both for novice natural language preprogramming knowledge and novice fragmentary programming knowledge. Using these representations and the bug generators, we evaluate the model by analyzing four interviews with novice programmers.

It is widely known that programming, even at a simple level, is a difficult activity to learn. Why is this so? Are novice difficulties really inherent in programming or are they related, to the nature of the programming tools currently given to novices? To answer this question we have used novice Pascal computer programs collected from their terminal sessions, controlled clinical studies focusing on specific aspects of novice programming techniques, and video-taped interviews of novice programming [Bonar, 1982]. In each we focused on bugs and buggy programs. Bugs and errors illuminate what a novice is actually thinking -- providing us a window on the difficulties as they are experienced by the novice.In previous reports we presented evidence that current programming languages do not accurately reflect the cognitive strategies used by novice programmers [Soloway et al, 1981]. Instead, we have found that novice programmers possess knowledge about and experience with step-by-step specifications in natural language. This knowledge and experience gives them powerful intuitions for using a programming language. Programming languages, however, are, not designed to appeal to these intuitions. On a semantic and pragmatic level, there are incompatibilities between the way, natural and programming languages are used. Many novice programming bugs can be directly traced to an inappropriate use of natural language specification style or strategy.As an example of these incompatibility bugs consider the "while demon" bug. Novices with this bug assume that the actions in the body of the while loop are continuously monitored for the exit condition to become true. This interpretation is consistent with the English language usage of the word while: e.g."while the highway is two lanes, continue, north". In an earlier written study [Soloway et al, 1981] found that 34% of the students in an introductory programming course thought the test in a Pascal while loop was performed, as a demon. Furthermore, a later interview study showed that novices could even describe the implementation mechanism for such a demon:"… everytime I [the variable tested in the while condition] is assigned a new value, the machine needs to check that value …"In this report we describe our use of video-taped interview studies for understanding how novices use a programming system. Interviews provide valuable information not available through statistical analysis of written studies. Written studies allow us to manipulate specific factors and guage the results to performance or style. Furthermore, we can have statistical confidence in those results. An interview study, on the other hand, allows us to examine the source of performance or style differences uncovered. Interviews give us an "execution trace" while written studies give us the final output. We use both kinds of studies, depending on the kind of information needed.We have interviewed seventeen novice programmers. Four were interviewed regularly for the first 8-10 weeks of their introductory programming course. For these regular subjects we have about 15 hours of interviews tracing their learning and maturation through the course.In this report we show an example natural language specification and discuss strategies used in that specification. We then discuss two examples of novice programming difficulties stemming from an inappropriate use of natural language specification strategies. These examples are illustrated with video tape transcripts. We conclude with a brief discussion of the implications of this work.

The Cognition and Programming Group at Yale University is engaged in two complementary efforts: