www.projectpioneer.com
·
Implement
decentralized research method (work collaboratively)
·
Analyze the
efficiency and applicability of distance collaboration (different countries)
·
Create an
interdisciplinary project approach to curriculum development, creating a more
relevant and efficient curriculum.
·
Integrate
emerging (open source) and high-end technology in the educational arena.
·
Develop an
online learning environment.
·
Study the role
of technology in enhancing and promoting ongoing learning.
Below
is an excerpt of a dialogue between myself (asking the questions) and Jecel M.
Assumpção Jr. (answering them, sometimes seriously, sometimes playfully). This
dialogue reflects some very important aspects of the role technology is playing
in our project, and consequently in the learning activity. It shows the types
of research that can be done both collaboratively and long distance. It also
reflects how the medium allows for easy access to stored information, where I
could just use the emails directly and include the information in this
analysis. It also allows for easy access to metacognitive activities, where I
can organize my ideas and reflect on them, both individually and collectively,
allowing them to grow and develop.
Due
to the collaborative nature of this project (six team leaders, each one with
their own specialty), my initial ideas have been greatly enhanced and enriched.
Each project leader has contributed to the idea pool, as well as helped guide
students as they develop their work. We hope this project becomes a model for
technology integration in a more modern educational setting, where new pedagogies
will start having a larger role in our student’s educational process.
These
are some of the initial questions we asked ourselves, in starting this project:
·
(CMA) Can open
source become a new tool in designing interdisciplinary, situated based, real
life projects that can integrate into the curriculum?
·
(Jecel) To be
"interdisciplinary", the programming part must not be too intrusive
in order not to scare off those with less technical interests.
·
(CMA) (Study
the use of Self as a programming tool to encourage student's thinking at higher
levels).
·
(Jecel) Self
is meant to stimulate people with less abstract mindsets (you can *see* the
objects right there on the screen, and not just imagine them from looking at
the source text).
·
(CMA) Will it
promote higher level thinking skills, augment student learning?
·
(Jecel)
Programming is the most natural environment for learning certain "powerful
ideas". It provides a vocabulary for mental processes and helps people to
actively think about learning strategies.
·
(CMA) Model
collaborative learning using technology in what it best lends itself? Adequate
the activities to the medium?
·
(Jecel) The
computer can mimic any existing or imagined media (paper, LP records, TV,
etc..). With an infinitely malleable media, I see no reason to adapt the
activities to it except for the limits of our imaginations.
·
(Jecel) In the
past, this wasn't quite true - the technology was limited and couldn't do all
was wanted. That phase ended in the early 90s.
·
(CMA) Focus:
pedagogical aspect - integrating technology into the curriculum.
·
(CMA) Outcome:
Curriculum integrating new technology in a new way (not merely adjusting it to
the traditional uses). Online unit geared towards distance learning and online
collaboration. Open ended and not content based. A tool that students can use
to promote problem-solving skills, decision-making and research methodology.
·
(CMA)
Assessment: Measure student skills before and after.
·
(Jecel)
Objective measurement is *very* hard. List of facts = easy. Skills = nearly
impossible.
·
(CMA)
Qualitative analysis. Self-assessment through rubrics. If students reached a
functional model of a colony.
·
(Jecel)
Careful - mistakes are better learning experiences than successes! A
non-working colony might mean a failure or it might not.
·
(CMA)
Scalability of the unit - if it can be used in the classrooms, not just as an
after school activity.
·
(Jecel) Not
without major changes in the classrooms.
·
(CMA) How can
I measure success?
·
(Jecel) If the
students come back for more :-)
·
(CMA) In what
ways is this innovative?
·
(Jecel)
Students haven't had a chance to build their own tools since the early phase of
the PARC Smalltalk project in 1974... Time to try again!
·
(CMA) How can
this prepare students with better real world skills?
·
(Jecel) They
might very well be building a colony in Mars in 2030 ;-)
·
(CMA) To what
point does the medium influence and mold student thinking and learning?
·
(Jecel) Quite
a lot! "If all you have is a hammer, everything looks like a nail".
·
(CMA) How can
I encourage students to become independent learners?
·
(Jecel) Learn
to let go. Don't be frustrated if things go in unplanned directions.
·
(CMA) Seekers
and analyzers of information?
·
(Jecel) Don't
spoon feed them all the facts they need for the next task.
·
(CMA) Action
takers?
·
(Jecel) I
don't think that can be taught. It certainly can be discouraged by making kids
sit quietly in a desk for several hours every day.
·
(CMA) How can
I measure their capability to transfer knowledge to a new context?
·
(Jecel)
time_to_learn(new_context) < time_to_learn(old_context)
Once
we had established our initial research questions, we worked together to search
for research that would support our initial hypothesis and statements. In this
paper I will be referring to the results of that research, citing the authors
and their findings, all of which support Jecel’s answers. This also is a result
of distance collaboration (very much facilitated by the presence of the web)
and easy access to data (stored information, as many papers were readily
available on the web as well).
This
collaboration will improve even further once access to high bandwidth becomes
more widespread. It will allow for even deeper levels of collaboration, such as
allowing two users in different countries do browse the web together by sharing
the same computer screen, while talking to each other and seeing each other on
video. They will be easily able to collaborate on documents and other applications;
such as it is now possible with Microsoft Netmeeting. Even with the lower
bandwidth we have today, we have already been working using this tool.
One
of the main goals of the Pioneer Project is to integrate such collaborative and
research tools into everyday educational activities. Through the Mars
Millennium Project we hope to create a very friendly collaborative user
environment that will empower the students to become real researchers and
programmers. The research I have found supports us in this pursuit. One example
is the question below, by Harris. It is a question that should be always asked,
no matter what the medium being used:
·
Will this use
of the Internet enable students to do something that they COULDN"T before?
Will it allow students to do something that they COULD do before, but BETTER?
(Harris, 1998) These are questions we are constantly asking ourselves. We don’t
want to use technology for the sake of technology itself. We want technology to
be a tool to empower students, not to control them.
We
chose the WebQuest format, due to the fact that it lends itself to an
interdisciplinary approach, as well as authentic learning situation, where the
students become researchers. The students are challenged to work together to
solve a common problem, where each one contributes with a unique amount of
knowledge, being that one becomes dependent on the expertise of the other. This
is a strategy that makes perfect use of what the Internet has to offer today,
both as a communication and collaboration tool, as well as a research tool. Our
goal was perfectly summarized in yet another email I received from one of the
major specialists in the integration of the Internet in the classroom: “The
ultimate goal is, through the use of WebQuests and other tools, to develop students
capable of posing and solving their own essential questions, and proceeding
without the benefit of scaffolding. Going beyond WebQuests means that students
would recognize that any problem must be attacked from multiple perspectives.
They would have the skills to recognize the critical roles necessary to solve a
particular problem. They would define their own roles, locate their own
resources, and form the questions that would allow them to pursue their role.
Then they would develop individual expertise based on their roles, come back to
the group, and the process of problem-solving, share what they had learned, and
together construct a new body of knowledge that may not have existed before.”
(Wolinsky, 1999)
Thinking
skills that a longer term WebQuest activity might require include these (from
Marzano, 1992): comparing, classifying, inducing, deducing, analyzing errors,
constructing support, abstraction, analyzing perspectives (Dodge) This matches
perfectly with our goal to use the technology as an empowering tool, through an
environment that opens an opportunity for acquiring higher level thinking
skills.
The
model we chose is also in accordance to research by Johnson et.al (1993), in
integrating cooperative learning through emphasizing lesson coherence. The
prepared lesson has a beginning, middle, and an end. To begin the lesson the
teacher presents a practical, real world problem or provocative issue that
intellectually challenges students. Everything that follows is organized around
solving the problem. The problem is presented first. Then concepts and rules
are presented second. Teachers pose provocative questions and allow students to
adequate time for reflection. (Johnson et. al, 1993)
In
this particular activity, we also decided, based on previous experience and
supported by research (Johnson et. al, 1993) to assign specific roles, as a
scaffold in an initial phase, so that students wouldn’t get lost when starting
their vast research, and were confronted with the great amount of information available
to them. According to Johnson et. al, the teacher assigns students roles. After
each item, the roles are rotated so that each student fulfills each role once.
(Johnson et.al, 1993). By following this format, the students would be exposed
to different responsibilities and perspectives, acquiring a more global view of
what is required of them, as well as practice different uses of the online
environment, becoming more savvy with the technology.
Tools,
no matter how powerful their educational potential, don't directly help our
students to learn. What's important is how we use the tools to assist teaching
and learning (application rather than operation). Seymour Papert dubbed the
kind of thinking that successful technological integration was learning the
hardware and software as "technocentric thinking" (1987). Teachers
should plan an educentric application for the powerful tools. (Harris, 1998).
We decided to give our students access to two forms of online tools. The first
tool we offered them was the listserve (ppioneer@listbot.com).
The choice was made based on the fact that most of them already were used to using
email, and we wanted them to have a tool with which they would feel comfortable
with right away, so that they could concentrate on the content rather than the
medium. We were pleased to see we made a very successful choice. Students have
been exchanging an average of 80 emails a day, exchanging good resources,
ideas, and debating the different points of the challenge. This tool was also
fundamental for the successful implementation of the project, for all
participants are now far from each other (students are on vacation, teachers
are in different cities and even countries!). Without the technology, this
project could not have started at all until February of 2000. Also, this was a
tool that allowed students’ access to experts in the varied fields, including
the organizers of the official Mars Millenium Project. Technology here played a
role in compressing time, space, and content. In other words, students could
work together even when they were physically separated, and learned more than
they would have alone, in a shorter period of time, because they were exposed
constantly to guidance and to each other’s ideas.
The
one disadvantage of the listserve is that it doesn’t organize the information,
being that sometimes the questions will be asked more than once, filling
participant’s mailboxes and frustrating those who already have seen the
question before. That is one of the constraints of this type of collaboration
tool. In order to provide a more organized tool for the ideas to develop, the
project organizers created the forum found in our website. The questions there
are organized by threads, and the answers are stored under each question. That
not only has the advantage of making the information easier to find, but also
makes the information readily accessible for further analysis and metacognitive
processes, allowing students to learn through their own mistakes and accompany
their own development.
We
are at this moment in the process of studying an easier forum format to use.
The one we adopted requires going into too many screens (bad affordance), and
is not supporting student performance. Due to the difficulty in logging in and
navigating, students have not yet adhered to this new medium. They still are
preferably using the listserve, even though the facilitators have encouraged
them daily to move their discussions to the forum. This is a very good example
of how a great tool can be undesirable due to problems in affordance. We are
restudying the design to make it as user friendly as possible, so that the tool
doesn’t get in the way of learning.
Research
also shows that implementing the same activity in different classrooms can have
very different results. There are many biologically-, psychologically-,
socially-, historically-, and temporarily-rooted differences among student's
receptivity to educational activities. (Harris, 1998) The same can be said for
different medium, as we found out with the listserve and forum. This is
something we will have to be really careful with if we want to create an activity
that will be successful in any classroom. It has to be open and flexible enough
so that teachers can adapt to their own conditions, assuming ownership of what
they implement. The type of activity we want to design would serve as a
scaffold, to get other teachers started in using technology well. The idea is
for them to grow away from this and develop independence and new ideas of their
own, enriching even more the knowledge pool. The web is the perfect medium to
allow such flexibility, adaptability and sharing at all levels. In Harris
(1998) we find support for this:
We
know from both experience and research (e.g. Rogers, 1995) that tweaking
someone else's idea isn't nearly as satisfying, or as effective, as designing
an activity that fits the unique combination of factors that present themselves
in any particular classroom at any particular time. Reinvention; the process of
taking something like a new tool or idea and making it our own in its
application, is very important to both teachers and students. Feelings of
ownership are crucial if new tools are to continue to be employed in ways that
will benefit users. This is what is known as true adoption of the innovation
(Rogers, 1995).
This
is where our Biotechnology Project (http://www.colband.com.br/ativ/nete/biot)
went wrong last year (1999). The Biotechnology Project was yet another project
started in 1998, implementing the same model of learning and technology
integration. The success of the project was great with the first group of
students, yet totally unmotivating for the second group (1999). We found out
that this was due to the fact that the students didn’t feel as if the project
were theirs. They thought they were working on the last year’s students’ work.
Not assuming ownership discouraged them from putting any effort into
contributing to the knowledge building that had started, even though they were
offered and had access to the same tools and resources. This will be corrected
in 2000, when new students will be presented with unique challenges that will
motivate them to assume ownership and benefit from the activities offered.
We
also are making available to students, on the project website, access to
images, experiments, and progress reports based on their discussions. These
reports are being elaborated by a professional evaluator who is part of our
team, with the objective to help students analyze what they are learning, where
they came from, how far they’ve come, and call attention to points they need to
pay attention to, so that their research has scientific validity. Thanks to the
immediacy of the web, the students can all have access to this information as
soon as it is ready. It is published on the site on the same day as it is
finished, allowing for updated information. Once again technology allows the
use of information that is only useful if shared right away. And we don’t have
to depend on others to do that. The web has allowed us to become publishers and
authors, being able to help our students in a more efficient way.
Our
theory of learning is implicit in our design. According to Duffy and Jonassen,
instruction should provide contexts and assistance that will aid the individual
in making sense of the environment as it is encountered. (Duffy & Jonassen,
1992)
Constructivists
focus on the process of knowledge construction and the development of reflexive
awareness of that process. Evaluation in the constructivist perspective must
examine the thinking process. One possible type of student evaluation activity
would ask learners to address a problem in the field of content and then defend
their decisions.(Duffy & Jonassen, 1992) That is what we’ll be asking our
students to do as they prepare the presentations for other groups. The progress
reports provide the reflection on the process.
Smith
et. al (1994) were experimenting with creating a simulation environment that would
be easy for children to use, based on a graphical user interface. They raise
some fundamental questions, such as: How can people tell agents what to do?
More generally, how can ordinary people, who are not professional programmers,
program computers? This problem--the "end-user programming
problem"--is an unsolved one in computer science. In spite of many
previous attempts to develop languages for end users, today only a small
percentage of people are able to program. Why are most people unable do it, in
spite of all the attempts to empower them? Is programming inherently too
difficult? Or does the fault lie with computer scientists? Have we developed
languages and approaches best suited to the skilled practitioner, languages
that take months or years to master? The authors take the latter view: computer
scientists have not made programming easy enough. (Smith, Cypher, Spohrer,
1994) This is one of the challenges we propose to meet. That is why we chose to
use Self to program a virtual colony. We also feel that the problem is not in
the programming itself, but in how it is taught and designed. Even though these
authors take a position totally against teaching any programming language, we
feel that this is not totally necessary. As long as the programming language is
something students can identify with and understand, using analogies they are
familiar with, we feel they are ready to develop a world using a simple
programming language. Of course we are dealing with older students, high school
level, which are more mature cognitively and have successfully reached logical
reasoning skills. We also believe that teaching programming will enhance their
cognitive processes, further developing their logical reasoning, sequencing and
correlation of cause and effect skills. It will also give them the capability
and freedom to explore their potential and ideas, testing them out, because
they will be capable of working the variables and their relationships. This is
based on our previous observation of how many of our students taught themselves
basic programming languages such as HTML, Java and Perl. This tells us that
they are eager to be able to develop their own environments, with freedom to
choose what they would like to see there, not be confined to what some other programmer
has determined.
Again,
according to Smith et.al (1994), today, over 100 million people use computers
to write letters and reports, draw pictures, keep budgets, maintain address
lists, access data bases, experiment with financial models, play games, and so
forth. Children as young as two years old can use a mouse and paint with
programs like KidPix (a child's painting program, at one time the world's best
selling application) or explore worlds like The PlayRoom (a child's adventure
game). So computers are not inherently unusable. The key observation is that
most of these applications are editors: with them, users produce an artifact by
invoking a sequence of actions and examining their effects. When the artifact
is the way they want it, they stop. (Smith et. al. 1994) Smith et. al make it
clear that the problem is not in the technology itself, but in its constraints
and affordances. If we can circumvent these obstacles, we can provide a rich
learning environment. That was also Papert’s idea when he created Logo (http://papert.www.media.mit.edu/people/papert/
), which unfortunately was not taught the way it was meant to be. This is
another interesting thing we have observed happening. Even though the medium is
new, in the beginning, it is still used in the “traditional” manner, both by
students and teachers. So even though they have the right tools to really go
beyond drill and practice, we still have to help them make the pedagogical paradigm
shift, showing them how to use these new tools in an innovative way. After all,
we are dealing with people, and dealing with years of training in one
direction. We can’t expect the learning to change magically when the new tools
are presented. We have to be prepared to kill old habits and misconceptions, at
the same time that we are modeling the new pedagogies. We have to help teachers
and students rethink what education is about, and what the end product should
be. The tools are there only as support to this mentality change, because they
help organize and provide an adequate environment for such learning.
Smith
goes on to say that they have come to the conclusion that since all previous
languages have been unsuccessful by the criterion described here, language
itself is the problem. It does not matter what the syntax is. Learning another
language is difficult for most people. The solution is to get rid of the
programming language.(Smith et.al, 1994). They used a totally graphical user
interface (GUI). Since our students are older, we are going to use a GUI, but
also give them access to the source, giving them the choice and possibility of
going further in their learning experience. That will help make their learning
self-paced, with no limits as to how far they can go. We are dealing with
encouraging the acquisition of higher level thinking skills in an authentic
learning situation. We are not saying that this is the only way to teach. Other
pedagogies are better for other types of learning, as are other environments.
That’s why we have to be very clear on what we are trying to teach, so we know
how to best reach our goals and objectives. Different strategies are adequate
for different types of learning. Our focus is very specific for a very specific
audience. We want to provide a higher level environment for students who are
almost ready to face real world challenges in their professional lives,
believing that one of the goals of education is to prepare citizens who are
ready to contribute to the community they live in.
According
to the research, the following are the most important principles for solving
the end-user programming problem.
·
Visibility: Make everything relevant to people's
operation of a computer system visible on the display screen. This is the
single most important UI principle. People have an easier time understanding
what is going on and what to do next if things are visible than if things are
kept internal to the program and hidden from users. Without visibility it is
almost impossible to achieve an easy-to-use interface. Visibility has a couple
of related principles:
·
Interactive
vs. batch: Establish a
cause-effect relationship between user actions and system semantics. When users
do something, show the effects immediately. Systems that do not are confusing.
·
Modeless
vs. modal: A
"mode" is a state of a system in which user actions are interpreted
differently than they would be ordinarily. Systems get in trouble when either
(a) they have many modes or (b) their modes are invisible. Both confuse people,
leading to (usually unpleasant) surprises at the results of actions.
·
Copying and
modifying vs. creating from scratch:
Allow people to copy and modify existing items in a system as a way to create
new ones. It is often easier to start with something that works and figure out
how to modify it than to create the same thing from scratch. Revealingly, this
is the way most professional programmers work. (This is exactly what SELF is
best at).
·
Seeing and
pointing vs. remembering and typing:
Allow users to point to entities on the display screen with a pointing device,
instead of making them describe the entities by typing text. It is the
foundation for the popular concept of "direct manipulation."
·
Concrete
vs. abstract: Make the
entities presented to users concrete. People have an easier time with the
concrete than with abstractions. (SELF offers objects that can be seen, helping
visualization).
·
Familiar
user's conceptual model:
Cast the concepts in a system into terms the user can understand. When faced
with a new situation, people try to apply their existing knowledge to
understand it. This is the inspiration for the use of metaphor in computer
interfaces, especially the so-called desktop metaphor invented for the Xerox
Star by the first author.
·
Minimum
translation distance: One
principle of utmost importance for programming environments but not so much for
other applications was proposed by Sloman: minimize the conceptual distance
between people's mental representations of concepts and the representations
that the computer will accept. In our opinion, the failure to do so is the
single biggest reason that languages designed for children such as Logo and
Smalltalk have not attained wider use. Time and again we have watched children
try to accomplish simple programming tasks such as making a fish swim away from
a shark, only to be frustrated by the difficulty in having to deal with
coordinate systems and vectors. The most articulate representations are the
ones that minimize this translation distance. Of course this is also a
principle of good program design: create data structures and operations that
are close to those in the problem domain.
·
In summary,
the GUI eliminated command lines by introducing visual representations for
concepts and allowing people to directly manipulate those representations. It
has empowered millions of people to use computers. Today, all successful
editors on personal computers follow this approach. But most programming environments
do not. This is the reason most people have an easier time editing than
programming. (Smith et. al, 1994)
Why
simulations? Again,
according to Smith et.al (1994), they are a powerful tool for education.
Simulations encourage unstructured exploratory learning. They allow children to
construct things, supporting the constructivist approach to education. Alan Kay
contends "We build things not just to have them, but to learn about
them." He quotes the philosopher Cesare Pavese: "To know the world,
one must construct it." Scardamalia argues that children learn best when
constucting things. They enter Vygotsky's "zone of proximal
development." Simulations such as SimCity and SimEarth allow children (of
all ages) to construct unique microworlds, giving them a sense of ownership in
their creations. They can observe and modify and experiment with these
microworlds. Children are the "gods" of their worlds. This pride of
ownership and feeling of power are compelling qualities that motivate even professional
programmers (Smith et. al, 1994). That is EXACTLY what we believe, and that is
why we made the choice of using SELF and building a virtual colony.
However,
Smith et.al go on to say, most simulations today do not permit users to modify
their fundamental behaviors and assumptions. For example, one cannot alter the
fact that if one puts in a railroad in SimCity, the pollution problems go
away--not exactly a realistic consequence. This inflexibility is the reason
that most school teachers do not use SimCity as a teaching tool, even if they
are studying city building. It does not model what they want to communicate.
Simulations that do allow fundamental modifiability, such as numeric
simulations built with Stella, require extensive programming skills. Few
children or teachers can or want to do it. (Smith et. al, 1994). Students want
to feel they can have some control of their environment, so they can test
hypothesis and create something they feel they have an ownership of. We feel it
underestimates students’ capability to say they cannot learn programming.
That’s why we have chosen to include programming in the project, using a
language that will be very close to the GUI, but that will also allow them to
have access to the source code. In other words, we’re trying to include the
best of both worlds.
Smith
already said that what is needed is a way for children without programming
knowledge to have more control over the behavior of simulations. What is also
needed is a way for teachers to tailor simulations to support their curriculum
goals. (Smith et.al, 1994). Using Self will allow us to empower our students
without having to learn an excessively hard language. They will be using a GUI
(graphical user interface), at the same time that they will be empowered to go
to the source and troubleshoot and adapt the program to their specific needs,
giving them the ownership they need. Self is designed to support exploratory
programming. One of the strengths of object-oriented programming lies in the uniform access to different kinds of stored
and computed data, and the ideas in SELF result in even more uniformity, which
results in greater expressive power. An object in SELF would be created by
cloning a prototype. (Ungar and Smith, 1991). This is what makes it ideal for
our proposal.
When
we heard of the Mars Millennium Project (MMP), we knew right away it was
perfect to help us answer our questions. It provided an authentic
problem-solving situation, where students were encouraged to work
collaboratively, and use the web as one of the main media to obtain and develop
information. We just adapted it to our specific needs. This is yet one more activity
that has its success based on accessibility of information, only possible
through the web. It would never have reached the scale it has if it depended
solely on other traditional media. It is a project that makes use of updated
information (such as was the case of the Mars Polar Lander), video, audio,
contact with experts, stored information giving any data students need to learn
about Mars, and much more. No traditional media could have provided such a rich
research and collaboration environment.
This
is what you can find at the website:
“The
Planetary Society (TPS) welcomes you to a journey of inspiration and discovery
as we explore Mars through the visions of artists, scientists, engineers, and
astronauts who have turned their creative energies into wonderful paintings,
stories, music, architecture, intelligent machines, human space flight, and
much more. Even now, robotic spacecraft are engaged in brave missions to learn
more about the "red planet". We are happy that you are joining us as
we plan for the long–term adventure to Mars.
Initially,
intelligent machines will pave the way by measuring important properties of
this remote and alluring world. Later, humans will make the trip and establish
the first colonies. We want you to gather information from this website and
from your mentors, think about it carefully, creatively try your hand at
designing a small village on Mars for 100 humans, and then submit your ideas.”
(http://mmp.planetary.org/tour/welco2.htm
)
MAKING
A CASE FOR COLLABORATIVE ACTION RESEARCH
Visit any medical school
and what you feel is "electricity," says Richard Sagor, executive
director of the Institute for the Study of Inquiry in Education (Camas, Wash.).
"It's the electricity of a group of people exploring their passion. It's
the electricity of a learning organization," he exclaims.
That same passion could be
part of any school's culture, says Sagor, who shared his ideas with members of
ASCD's Signature Schools program earlier this fall. What's needed to inspire
such enthusiastic exploration of teaching practice is collaborative action
research, he says.
Through collaborative
action research, teachers identify a shared goal for improving student
learning, Sagor explains. Teachers then create an objective rating scale to
"show what it looks like" when students have reached the target.
The passion, Sagor suggests,
comes when teachers are given the authority to put their own theories to the
test--to use the instructional approaches they think will help students reach
the goal, even when others disagree. Holding differing opinions is healthy,
Sagor states, and educators shouldn't be afraid of conflicting viewpoints. When
there is division, "educators should say, 'Oh, good, we've got a
researchable situation.'"
In adopting such a
philosophy, educators feel professionally empowered-and students benefit, Sagor
states. Schools that encourage teachers to engage in collaborative action
research, he affirms, inspire teachers "to creatively pursue solutions to
improve student learning."
Richard Sagor is the
author of the ASCD book, *How to Conduct Collaborative Action Research.* For
information on this book and other action research resources, visit the ASCD
Online Store at http://www.ascd.org .
Sagor
expressed the importance of collaborative research, and we have already felt
the benefits of such efforts, as we teachers planned the project. We hope to
pass this on to our students to. That is why we have proposed the following:
Students,
using tools given to them through a special program created for that purpose,
will create a virtual world environment. Even though the program will have some
basic settings, it will be up to the students to build upon that. It will be
required that the students learn basic programming in object-oriented language,
in order to modify and adapt the tools offered them to make them more adequate
for the Mars environment. The tools offered will be appropriate for Earth. They
will also need programming skills when building the colony, in order to create
the buildings and whatever they see necessary for survival in the environment
they will research about.
The
students will have to research all about Mars, because in the program they will
have to input the data of the environmental conditions where their colony is
going to have to survive. They will have to find out the atmospheric gases,
temperature, humidity, etc.; as well as the soil conditions. They will input
their data into the program that will then recreate the environment for them,
simulating the world they will face.
The
students can work individually or in groups. There will be instructions
appointing the different roles existing in building the space colony, and
usually should require teamwork. But if a student is willing to take on the
whole challenge by himself, he can do so.
The
students will be able to save the program where they have stopped, as if it
were a game, picking up from where they left off the next time around.
The
work environment will offer several different challenge levels, so students of
all ages can participate in some way. After the teams have put in all their
data, the computer will simulate the results of their choices, giving them
feedback on their success. If the colony doesn't work out one way, they can
experiment with the variables to see if they can be successful another way.
There
will be a component where the students will have to justify their choices, to
avoid that they just keep "guessing" to try to get it right. They
will have to provide evidence as to their research in order to continue
(similar to the Science Sleuths software by Videodiscovery).
Once
the teams are satisfied with their colonies, they can showcase their virtual
world on the web. Others interested can visit this world. The visitors can
either just walk around, or collaborate and build their own structures. The
colony will be an ongoing process.
Students
will always have a choice of starting from scratch, inputting the variables, or
building upon someone else's work. After the initial success, new challenges will
be proposed, such as change in population, change in political system, change
in climate, and so on.
The
biggest asset of this program is that it will have an open source component,
giving the students the ability to modify the environment to their needs. That
will give them independence and room to grow. One team's world may turn out
very different from another team's world. They will not be constrained by
limits imposed by the initial programmers. This will be an option, for those
who like the challenge. If the student doesn't want to get involved at such a
complex level, the program will offer enough tools to get a basic colony going,
as long as the data is correct.
We
have adopted the constructivist approach to learning. Technology lends itself
really well to this pedagogy, according to research:
A
constructivist trainer doesn't strip away the natural complexity of a subject.
Instead, multiple perspectives are brought to bear. The goal of a
constructivist-learning environment is not the accurate transfer of content
from the instructor to the learner. Instead, the learner is given tasks and
opportunities, information resources and support, and is encouraged to
construct their own version of the content, subject to revision through
feedback. Many paths through the lesson are allowed and collaboration with
other learners is stressed over lonely individual learning. A constructivist
use of technology presents information to the learner in multiple forms from
multiple sources and invites the learner to make sense of it. (Dodge, 1996).
A
constructivist approach is more learner-focused, and less teacher-focused. The
instructor's role moves toward being a coach and orchestrator of resources, and
moves away from being the sole source of information. The emphasis is on case
studies, problem-solving, and the creation of meaning. The World Wide Web lends
itself beautifully to constructivist, active learning. (Dodge, 1996).
It
has been suggested by Ibrahim and Franklin (1995) that the pedagogical use of
the Web can evolve along two major axes: a closed corpus of material where the
technology is used mostly for its hypermedia and distance delivery
capabilities, or an open corpus approach which exploits the enormous amount of
information that is accessible via Internet, whether or not it has been put
there for educational purposes. An organized structure of links has then to be
superimposed on the domain to allow guided educational explorations. These two
axes can be alternatively or complementarily followed. (Eklund et.al, 1996)
·
Cross-globe
communication - Interpersonal Exchange (Harris, 1998)
·
Time
compression (facilitating the formation of correlations) (Rothkopf, 1998)
·
Multimedia as
a way to share information (Rothkopf, 1998)
·
Vast amount to
stored information (Rothkopf, 1998)
·
Access to
real-time data collection
·
Help systems
to increase efficiency (Rothkopf, 1998)
·
Allows for
active search for knowledge
·
Practical =
access to experts in the fields (Rothkopf, 1998)
·
Reactive,
allowing for individualized construction of knowledge, based on your background
and prior knowledge (Rothkopf, 1998)
·
Records the
learning process, allowing for metacognitive analysis
·
Convenience
(Rothkopf, 1998). It is easy to use.
·
Motivational:
students love to use technical innovations, feeling challenged to learn more.
·
Allows us to
elaborate educational activities that give students maximal return for the
amount of time and effort that all of us must expend to ensure success.
(Harris, 1998)
·
When we do use
these new tools, usually it will only be "worth it" for us to do so
if they can be applied in new ways to help new and worthwhile things to happen
in our classrooms. (Harris, 1998)
·
According to
Harris (1998), There are 18 telecollaborative activity structures that she's
identified to date. They group themselves into three genres of educational
online activity:
·
Interpersonal
Exchange
o
keypals
o
global
classrooms
o
electronic
appearances
o
telementoring
o
question-and-answer
activities
o
impersonations
o
Information
Collection and Analysis
o
information
exchanges
o
database
creation
o
electronic
publishing
o
telefieldtrips
o
pooled data
analysis
·
Problem
Solving
o
information
searches
o
peer feedback
activities
o
parallel
problem solving
o
sequential
problem solving
o
telepresent
problem solving
o
simulations
o
social action
projects
·
Constrains
contexts - someone decides for you what you can see and do (Rothkopf, 1998)
·
Requires
training to be used: Most teachers still don't use it do to lack of knowledge
of how to use such a system
·
More difficult
to measure competence for these abstract skills
·
Unclear help
systems (Rothkopf, 1998)
·
Problems with
authenticity of stored information (Rothkopf, 1998)
·
Access
problems: bandwidth limitations in other countries
·
Language to be
used when developing a global learning activity. This is illustrated by the
fact that even though discussions so far have been in Portuguese, the student’s
native language, the website and instructions are in English, so that
professors and students in the US can participate and follow what is happening.
Also, the students will be translating their presentations for the judges to be
able to evaluate what they have done. The two Appendixes in this paper are an
example of the type of information the students have access to in their native
language. These will be translated at a later date so that US users can also
use this information if they decide to join the project.
The
lessons explained by the authors of the Habitat will be taken into
consideration when we build our virtual world. This research will be made
available to students, so that they use technology in the best way possible,
allowing them to go through a rich learning experience.
These
lessons are:
·
Cyberspace is
defined more by the interactions among the actors within it than by the
technology with which it is implemented.
·
The core of
their vision is that cyberspace is necessarily a multiple-participant environment.
A multi-use environment is central to the idea of cyberspace.
·
At the heart
of the Habitat is an object-oriented model of the universe
o
The objects
implement the semantics of the world itself.
o
The goal is to
enable the communications between machines take place primarily at the
behavioral level rather than the presentation level (what people are doing
rather than how the scene is changing).
·
Cyberspace is
a computational medium to augment the communications channels between real
people.
·
The implementation
platform is relatively unimportant.
o
We can build
effective cyberspace systems today.
o
It is
conceivable that with a modicum of cleverness and foresight you could start
building a system with today's technology that could evolve smoothly as the
tomorrow's technology develops.
·
Data
communications standards are vital
·
Detailed
central planning is impossible.
o
Social
constructivism - community building of knowledge.
o
The bulk,
wherein the complexity lies, is the product of the users themselves, rather
than the system designers -- the operators of the system do not have to create
all the material.
o
Organizers
shifted from trying to control everything to letting the players themselves
drive the direction of design (going towards constructivism!). This proved far more
effective. Instead of trying to push the population in the direction they
wanted them to go, they tried to see what people wanted and aid them in it.
They became facilitators as much as designers and implementors. This allowed
them to have more influence on the system than when they had total control.
·
Work within
the system
o
Maintaining
the consistency of constraints makes the activity more pleasurable and
believable.
These
lessons are very important on a personal level as well. As seen in my initial questions,
I had difficulty letting go of the apparent control I wanted to have on the
evolution of the whole project. Project Pioneer already has taken on a life of
its own, and I learned that the best way I can help the students is by giving
them freedom. My role is that of a facilitator, providing the resources they
need, but letting them explore on their own. Using the open source approach has
an inherent constructivism to it that cannot and should not be ignored. It is
better to work with the flow in this case. That’s why we chose such a system in
the first place. It also allows us to benefit from the best aspects in using
simulation and virtual environment for learning.
According
to Assumpcao Jr. (1999), a very important aspect to remember is that almost
everything we have today was created by people with a “mathematical mentality”,
which normally had great familiarity with how computers worked at a very basic
level. This combination resulted in machines that only make sense to a very
small portion of the population, with only one learning style, leaving most of
the others out.
The
direction in which Smalltalk and Self went was to create something for people
who prefer to work with the concrete, instead of the abstract. These systems
don’t mind losing in performance to make the basic low-level details of the
machine irrelevant, when it is more convenient for the user.
A
little bit of this ended up passing on to the users through the Mac OS and
Windows. But adopting only some aspects of a more evolved system, and based on
a weak foundation is not the best solution. It’s best to adopt the more evolved
system once and for all. So that’s what we are proposing to try.
The
table below, made by Assumpcao Jr. (1999), will help visualize the requirements
for working with the different systems. By knowing what we are dealing with, we
will be able to better help our students get the most out of the environment. The idea of the table is to show that the learning
process in Self/R is of “progressive disclosure”, but more tortuous in other
systems.
Type of User |
Win98/NT/MacOS |
Linux |
Self/R |
Casual User |
File systems,
applications and how data in files is different from data on disk - open/save/save
as, scroll bars, menus and dialog boxes, cut/copy/paste, file formats,
browser for www and plug-ins, email software, user accounts and permissions
(in NT) |
File systems,
user accounts and permissions, processes and how to kill them, applications
and how data in files is different from data on disk, how to use their
particular X Window manager and various types of scroll bars, various user
interfaces for different applications - mostly menus and dialog boxes, file
formats, browser and email software |
Persistent
objects - prototypes and copies, user accounts, pop up menus and dialog
boxes, outliners, drag-n-drop, email |
|
Power User |
Scripting
systems and things like VisualBasic for Applications, shortcuts in the user interface,
managing files Linux: command line interface and Unix commands, shell
scripts, pipes |
|
Complex
selections, taking objects apart and putting them back together, typing
simple Self expressions in the shell, automating tasks with agents |
|
System Administration |
Hardware
information, network information, where things are configured, how to defeat
automatic (but sometimes wrong) configuration systems |
Lots of
hardware information, lots of network information, configuration file
formats, where configurations files are stored |
Not applicable
when running on top of another OS, where things are configured when running
on dedicated hardware |
|
Application Programming |
A language like
C++ or Java, the vast APIs (application programming interface) for the
system, using debuggers and related tools, how to think like a programmer |
A few languages
like C and Perl, one or more of the many APIs for X Windows, using debuggers
and related tools, how to think like a programmer |
Additional
things about Self, the large set of pre-defined objects and how they are
related, additional things about the debugger (used as an error dialog box up
to now), how to think like a programmer |
|
System Programming 1 (Drivers and Extensions) |
Hardware in
detail, a language like C or assembly, driver developers kit, lots of
additional APIs |
Hardware in
detail, kernel source and how drivers fit in, all about modules |
Hardware in detail,
reflection and meta-objects and how drivers fit in |
|
System Programming 2 (Kernel Hackers) |
Not applicable
unless you work at Microsoft or Apple, lots and lots of details and the
overall architecture of the source if you do |
Dive deeper
into the kernel source |
More
meta-objects including the compiler |
|
System Programming 3 (Languages and other Tools) |
Parsers,
semantic evaluation, code generation, much more about memory organization |
Parsers, semantic
evaluation, code generation, much more about memory organization |
Same as Kernel
Hackers plus things like parsers |
1. Assumpcao Jr., Jecel M. (1999) Computers
in Education. Email sent to the Project Pioneer list (ppioneer@listbot.com ) including
references to Papert, Kay, Jobs in making computer history.
2. Assumpcao Jr., Jecel M. (1999). History
of Programming. Email sent to the Project Pioneer list (ppioneer@listbot.com ) summarizing where
the Self language has come from, giving context to our choice.
3. Assumpcao, Jr., Jecel M. (1999). Self in
Education. Email sent to the author on December 11, 1999 4:31PM.
4. Dodge, B. (1997). Some Thoughts About
Webquests. San Diego State University. http://edweb.sdsu.edu/EdWeb_Folder/courses/EDTEC596/About_WebQuests.html
5. Dodge, B. (1996). Distance Learning on the
World Wide Web. Published in 1996 as Chapter 12 in Brandon, B. et al,
Computer Trainer's Personal Trainer's Guide, Que Education and Training,
Indianopolis, IN, ISBN 1-57576-253-6. http://edweb.sdsu.edu/people/bdodge/CTPTG/ctptg.html
6. Duffy, T. & Jonassen, D. (1992). Constructivism
and the Technology of Instruction: A Conversation. Published by Lawrence
Erlbaum Associates, Hillsdale, NJ.
7. Eklund, J. and Zeiliger, R. (1996). Navigating
the Web: Possibilities and Practicalities for Adaptive Navigational Support.
Paper on the web. http://www.scu.edu.au/sponsored/ausweb/ausweb96/tech/eklund1/paper.html
8. Harris, J. (1998). Wetware: Why Use
Activity Structures? December-January 1997-98 "Mining the
Internet" column in Learning and Leading with Technology, International
Society for Technology in Education, Eugene, Oregon. (http://ccwf.cc.utexas.edu/~jbharris/Virtual-Architecture/Foundation/index.html
9. Johnson, D., Johnson, R. and Holubec, E.
(1993). Circles of Learning: Cooperation in the Classroom. Interaction
Book Company, Edina, Minnesota.
10. Morningstar, C. and Farmer, F. Randall
(1990). The Lessons of Lucasfilm's Habitat. Published in Cyberspace:
First Steps, Michael Benedict (ed.), MIT Press, Cambridge, Mass. (http://www.communities.com/paper/lessons.html
)
11. Rothkopf, E.Z. (1998) Information,
Schooling, and National Performance. Columbia University, Teachers College.
Draft.
12. Smith, D.C., Cypher, A. & Spohrer, J.
(1994). KidSim: Programming Agents without a Programming Language. In
Communications of the ACM, 37(7), July 1994, pp. 54 - 67. (http://www.dnai.com/~cypher/Publications/CACM/KidSimCACM.html
13. Ungar, D. and Smith, Randall B. (1991). Self:
The Power of Simplicity. Published in Lisp and Symbolic Computation: An
International Journal. Kluwer Academic Publishers.
14. Wolinsky, A. (1999). Let's Play a game...
Beyond WebQuests (fwd). Email to WWWEdu list, on November 03, 1999 3:35PM.
Fortran,
Lisp, Visual Basic, C++, Smalltalk, Self (Assumpcao Jr., 1999)
Portuguese
A
programação nos primeiros computadores era feito modificando-os
físicamente
- tinha um painel cheio de furos e você ligava pares
de
furos com fios. A Cristiana mostrou uma máquina assim numa
feita
de ciências no colégio Mackenzie (ele é velha, não? :-)
Uma
grande melhoria foi guardar os programas na mesma memória
que
os dados. Isto ficou conhecido como "arquitetura de Von
Neumann"
pois o relatório em que a idéia foi descrita foi editado
por
John Von Neumann. Isto tornou possível a criação de programas
que
criavam programas: uns bits na memória podia ora serem encarados
como
dados de saída de uma programa e ora vistos como um programa
a
ser executado. O primeiro programa deste tipo criado foi o
montador
("Assembler") que permitia ao programador escrever algo
que
ele entendia:
load ($1234)
add bc
jmp LOOP32
ao
invés de algo que a máquina entendia:
1101 0000 0101 1001
1000 1000 1111 0101
0100 0010 0001 1100
Logo
foram percebidas tarefas que eram repetidas muitas vezes e
foram
inventas "linguagens de alto nível" para que o computador
passasse
a fazê-las (meados dos anos 50):
FORmula TRANslation para ciêntistas cheios
de equações
COmmon Business Oriented Language para
manter arquivos das empresas
LISt Processing para pesquisadores de
inteligência artificial
Depois
eu falo um pouco mais sobre esta última, o LISP.
Um
problema que foi logo percebido é que as pessoas tinha muita
dificuldade
de entender como funcionavam os programas das outras
pessoas
(e, muitas vezes, delas mesmas!). A maior razão disso é
que
o fluxo do programa pulava de lá para cá de maneira desordenada.
Foi
então criada a "programação estruturada". Nela, o programa
tinha
que ser dividido em blocos de maneira restrita - a execução
do
programa só podia começar no início do bloco e só sair no fim;
nada
de pular para o ou do meio do bloco. E só podiam haver três
tipos
de blocos: sequência de outros blocos, loops e blocos com
duas
ou mais alternativas. Note que a programação estruturada é
mais
*limitada* do que a programação livre. Os seres humanos são
limitados,
de forma que muitas vezes a única maneira de mantermos
o
controle é abrindo mão de opções.
Dado
o sucesso da programação estruturada, foi criada a ALGOrithmic
Language
em 1960 para que os blocos pudessem ser escritos diretamente
na
linguagem (demarcados por BEGIN e END). Chegamos aos anos 70
com
uma complexidade crescente nas linguagens, e Niklaus Wirth
mostrou
que o que realmente faltava ao ALGOL era a capacidade de
trabalhar
com complexas estruturas de dados - o seu famoso livro
"Data
+ Algorithm = Program" introduziu os conceitos da linguagem
Pascal.
Mas a simplicidade do Pascal provou ser bem problemática
na
prática, pois não havia meio de vários programadores trabalharem
em
trechos diferentes e depois integrarem seu trabalho. Isto levou
o
departamento de defesa americano a criar a linguagem Ada com
seus
"packages" para substituir a verdadeira Babel de linguagens
que
infesta o desenvolvimento de software militar. Wirth viu isso
como
mais um ataque da complexidade e criou a linguagem Modula-2
para
mostrar como se faz (depois ele viu que ainda era muito mais
complexo
do que precisava ser e criou o Oberon em 1985).
Na
outra mensagem eu falei um pouco sobre a programação orientada
a
objetos (Simula->Smalltalk->Self) de modo que aqui só vou mencionar
que
ela pode ser considerada um evolução natural da programação
modular
do paragráfo anterior. Tudo mencionado até aqui pode ser
chamado
de "programação imperativa", já que o programa representa
um
sequência de ordens a serem cumpridas pelo computador.
Enquanto
isso, o LISP deu origem a uma tradição de programção bem
diferente.
Um programa é descrito como uma sequência de aplicações
de
funções (no sentido matemático da palavra, e não de programação).
Para
fazer o LISP funcionar na prática, foram acrescentadas uma
série
de alterações que o transformaram numa linguagem imperativa.
Mas
a idéia da programação como um ideal matemático permaneceu, sendo
que
a APL (A Programming Language) a que melhor se aproximava disso.
Como
a criação da FP (Functional Programming) por John Backus (uns
dos
criadores do FORTRAN) nos anos 70, houve uma explosão de
interesse
por este assunto no meio academico, principalmente na
Europa.
A grande idéia é que você poderia provar matemáticamente
se
um programa está correto ou não, e usar ferramentas automáticas
para
transformar um programa em outro. A lista de novas linguagems
que
surgiram é muito grande, mas são Hope, Alice, ML e Haskell as
que
eu mais chamaram minha atenção.
Ao
mesmo tempo estava surgindo na Europa um terceiro tipo de
programação
com a linguagem PROgramming in LOGic - a programação
declarativa.
A idéia é que você apenas deve dizer (declarar) que
é
o problema da forma mais precisa possível, e o computador deve
usar
as regras da lógica para descobrir sozinho *como* resolver
o
seu problema. Exemplo clássico: dados estes fatos
mae(bruna,alex).
mae(bruna,sandra).
pai(chico,alex).
pai(chico,sandra).
mae(sandra,alfredo).
pai(felipe,alfredo).
mae(heloisa,felipe).
pai(geraldo,felipe).
e
estas regras
avo(X,Y) - pai(X,Z),pai(Z,Y).
avo(X,Y) - pai(X,Z),mae(Z,Y).
e
esta pergunta
avo(chico,N)?
teremos
a resposta
N=alfredo
mas
o PROLOG funciona nas "duas direções", de modo que a pergunta
avo(A,alfredo)
resulta
em
A=chico
A=geraldo
O
importante é notar que as regras foram aplicadas na ordem em
que
o PROLOG achou mais conveniente para resolver o problema, e
não
na ordem em que foram escritas pelo programador.
Dado
um avanço destes, o governo japonês anunciou que iria investir
massiçamente
no desenvolvimento de "computadores de quinta geração"
durante
uma década. Estes computadores seriam baseados na linguagem
PROLOG
e seriam capazes de criar seus próprios programas ao terem
os
problemas dos usuários descritos em linguagem natural.
Quando
aprendi sobre o Smalltalk e a programação orientada a objetos
ao
ler a revista Byte de agosto de 1981, eu já conhecia a programação
funcional
(eu tinha escrito um interpretador de FP em LISP) e a
programação
declarativa. A primeira coisa que me impressionou é
que
não entendi nada do que o pessoal da Xerox estava falando! E
olha
que eu não costumo levar mais que 5 minutos para aprender uma
nova
linguagem de programação (eu listo as principais em
http://www.lsi.usp.br/~jecel/jecel.html)
e eles afirmavam que usavam
o
Smalltalk para ensinar programação para crianças. Só mais tarde
eu
descobri que o Smalltalk-80 que eles descreviam na revista era
bem
diferente (mais complexo) do que o que eles tinham ensinado
para
as crianças.
O
que mais me chamou a atenção em relação ao Smalltalk eram os
resultados
práticos que eles tinham obtido (editores, programas
de
desenho, de música e tantos outros) em contraste com o mundo
das
idéias dos academicos da programção funcional e declarativa.
Outro
problema é que estes estilos dependem muito do programador
ter
uma mentalidade extremamente lógica/matemática, que não é o
caso
da maioria da população. Um problema muito prático do PROLOG
é
que como o programador abre mão de dizer ao computador *como*
resolver
o problema, fica quase impossível saber quanto tempo para
se
obter um resultado. Uma pequena alteração nos dados de entrada
pode
fazer um programa passar a levar meses no lugar de segundos
para
terminar.
Resolvi
insistir com a programação orientada a objetos e Smalltalk
até
que conseguisse entender o que eles tinham feito. Com o tempo,
vi
que realmente era símples mas eles não tinham explicado muito
bem.
Do jeito que eles escreveram, se você já sabia do que eles
estavam
falando ficava tudo muito claro, mas senão eram apenas um
monte
de palavras sem sentido.
Em
1983 um amigo da faculdade disse que uns banqueiros queriam
entrar
na área da informática e pediram para ele projetar um
computador
para crianças. Ele queria minha ajuda, mas logo eu
estava
fazendo tudo sozinho (os banqueiros sumiram e gastei meu
dinheiro
para montar o protótipo). Adotei a linguagem Logo (o
dialeto
do LISP para crianças), mas achei que as crianças dos
anos
80 não iam ficar muito contentes de ficar fazendo "desenhos
de
tartaruga" na tela. Resolvi que seria interessante que elas
pudessem
criar seus próprios jogos. Para isso, concluí que eu
teria
que incluir: programação paralela, eventos, objetos e rede.
---
Programação paralela ---
Num
jogo acontecem várias coisas ao mesmo tempo. É possível
simular
isso manualmente (exemplos no estilo da linguagem C):
while(true) {
leTeclas();
moveJogador1();
moveJogador2();
moveBola();
atualizaPlacar();
}
Só
que isso é difícil para a maioria das pessoas, e inserir novas
ações
(que tal um jogador3?) muda tudo. Não seria mais agradável
poder
programar cada coisa que acontece na tela separadamente?
while(true) {
leTeclas1();
moveJogador1();
}
while(true) {
leTeclas2();
moveJogador2();
}
while(true) moveBola();
while(true) atualizaPlacar();
É
claro que precisa uns comandos para iniciar a execução paralela
destes
quatro programas separados, mas é fácil ver que colocar
mais
jogadores, nuvens passando no céu, etc. não dá nenhum
trabalho.
---
Eventos ---
É
mais natural expressar o que acontece num jogo em termos de
regras,
o que favorece a programação declarativa. Só que não
precisamos
de toda a potência (e complicações) do PROLOG: se o
sistema
detectar a ocorrência de certas situações e executar
de
maneira imperativa mesmo trechos do nosso programa, as coisas
já
ficariam bem mais fáceis. O Papert propos o comando "when"
para
o Logo e o Alan Kay o implementou no Flex:
...
when (x<y) {x = y}
...
Isto
é bem diferente do "if". Nada acontece quando programa
passa
por este ponto, mas no instante em que o valor de X ficar
abaixo
do de Y ele é alterado para ficar igual ao Y. Para um
jogo,
não é bem melhor poder escrever:
when(colisao(jogador1,bola) {
desviaBola();
pontoPara(jogador1);
}
do
que ter que ficar enchendo o programa de teste em todos os
lugares
em que imaginamos que pode haver uma colisão?
Se
os tipos de condições nas quais estamos interessados é limitado,
uma
alternativa interessante é a do Macintosh (e seu clone, o Windows)
onde
o sistema coloca numa fila indicações de ocorrência dos eventos
e
nosso programa lê da fila:
while(true) {
e = getNextEvent();
switch (e) {
case colisao:
desviaBola();
pontoPara(e->jogador);
break;
case tecla:
...
}
}
Ei!!
Mas eu não falei que era melhor separar as coisas em pequenos
programas
independentes? Foi o que o HyperCard (e seu clone, o
VisualBasic)
fez:
onColisão (evento e) {
deviaBola();
pontoPara(e->jogador);
}
onTecla(evento e) { .... }
Note
que essa "programação por eventos" não é tão poderosa quanto
o
comando "when", mas quebra o galho. O grande problema deste estilo
é
que as regras do jogo costumam depender muito do contexto ("o
jogador
pode correr para a lateral, a não ser quando a bola foi
colocada
fora de jogo pelo juiz, ou se o cronometro for parado por
um
dos técnicos..."). Quem não entende os perigos de regras sem
contexto
deve assitir 10 vezes "O Aprendiz de Feiticeiro" no filme
"Fantasia"
do Disney :-)
---
Objetos ---
Todo
jogo é uma simulação (de algo real ou imaginário - não faz
diferença).
Não foi por acaso que a linguagem Simula-68 incluiu
a
idéia de objetos. Se existe uma "bola" no jogo, não é mais fácil
ter
um pedaço do programa que corresponde diretamente à bola do
que
ter uma dúzia de números e subrotinas espalhadas por todo
programa
que juntas representam a idéia de bola? Um exemplo
relevante:
se eu pudesse definir o objeto "data" num só lugar
no
meu programa (ou melhor: em todos os meus programas!) fica
trivial
mudar a representação de 2 digitos para 4. Senão, vou
ter
que olhar linha por linha para descobrir o que tem que
ser
alterado (famoso "bug do milênio").
---
Rede ---
Uma
unidade de disquetes custava US$500 em 1983 (160KB!), de
modo
que não tinha sentido cada aluno ter o seu. Resolvi ligar
todos
os micros em rede e colocar um winchester de 5 MB (US$3000)
na
máquina do professor. Também seria mais conveniente do ponto
de
vista de controle e administração. Mas além de partilhar o
disco
e impressora pela classe toda, me pareceu óbvio que os
alunos
iriam querer criar jogos em que vários jogadores participariam,
cada
um em sua própria máquina. Afinal, nada era mais popular
nas
redes de computadores Alto da Xerox PARC do que os jogos
multiusuários
de Star Trek e de labirinto 3D (o Doom dos anos 70 ;-).
Mas
eu não tinha experiência com isso na ocasião, e apenas
incluí
comandos para que um programa pudesse enviar eventos para
outra
máquina. Mais tarde (de 1987 para cá) eu pesquisei bastante
sobre
como realmente aproveitar a rede.
Quando
foi meados de 1984 eu descobri duas coisas: eu ia continuar
fazendo
tudo sozinho mesmo e que eu estava usando cada vez mais
a
parte de programação orientada a objetos que eu tinha colocado
no
Logo. De fato, eu estava usando tando que mudar para Smalltalk
iria
simplificar as coisas. Só que o Pegasus era muito fraco para
rodar
esta linguagem (que ainda era usada apenas na Xerox) e eu
propus
para meu amigo fazermos algo mais poderoso. Ia ficar meio
caro
para as escolas, mas poderíamos vender para empresas. Ele
não
gostou, mas eu achava que quem fazia o trabalho é quem devia
mandar
e me separei para iniciar o Merlin. Sem dinheiro, parei
o
projeto para trabalhar em 1985. Retomei o projeto em 1986 e
meu
ex-chefe quis ser meu sócio. Na feira de informática daquele
ano
apresentamos o primeiro "network computer" (apesar de que
o
Smalltalk não estava funcionando ainda). Nos desviamos do rumo
no
fim de 1987 e nossa sociadade acabou em 1988. O pessoal do
Laboratório
de Sistemas Integráveis (LSI) da USP se interessou
pelo
Merlin, mas quando eu trabalhei lá acabei mais ajudando nos
projetos
de "super computadores" deles do que fazendo o meu projeto.
Acabei
tendo que sair do LSI para poder realmente retormar o Merlin.
O
mundo continuava sem poder ver as fantastica e práticas coisas
que
tinham sido criadas em Smalltalk:
- Pygmalion [David Smith]
Introduziu a "programação por
exemplos", em que o usuário mostra
para o computador o que ele quer que seja
feito e o computador
passa a repetir a tarefa sozinho.
Introduziu os "icones" no
mundo dos computadores.
- Analyst [Xerox PARC para a CIA}
Uma planilha eletrônica de dar inveja ao
Excel. Qualquer tipo
de objeto podia ser usado como valor nas
células, de modo que
era
possível usar o Analyst para processar imagens ou sons.
- Humble [Xerox AI lab]
Um ambiente para a criação de
"sistemas especialistas", um
produto da pesquisa de inteligência
artificial em que o
computador podia ser usado em tarefas como
auxilio a diagnóstico
médico e à exploração petrolífera.
- ThingLab [Alan Borning]
Um sistema de programação por
"contraints", que é um caso
particular de programação declarativa.
Pense num "PROLOG
gráfico" :-)
- Alternate Reality Kit (ARK) [Randy Smith]
Permitia aos estudantes fazerem experiências
de física num
laboratório virtual. Só que as leis da
física poderiam ser
alteradas para ver o efeito na experiência!
A interface gráfica
dava uma impressão de solidez aos objetos
por efeitos de
sombra (copiado pelo NeXT que foi copiado
pelo Motif/Windows 3.1)
e representava as idéias do Smalltalk de
maneira concreta (mais
sobre isso logo abaixo).
- MoDE [Stephen Pope]
Um estúdio de composição musical com muitas
ferramentas
automáticas e de síntese.
É
claro que houveram muitos outros projetos interessantes, como
o
controle de fabrica de chips pela Tektronix, mas foram estes
que
mais me impressionaram. Por outro lado, depois de dez anos
e
alguns bilhões de dollars os Japoneses não tinham grande coisa
para
mostrar e os "computadores de quinta geração" cairam no
esquecimento
(o que não quer dizer que eles não possam ter o
seu
lugar no futuro).
A
experiência do Randy Smith com o seu ARK foi particularmente
interessante.
Ele queria que o usuário sentisse que realmente
estava
na realidade alternativa. O cursor era uma mão e quando
agarrava
um objeto este se erguia do mundo fazendo uma leve
sombra
nos que estavam em baixo. Ao largar um objeto, se a mão
estava
em movimento o objeto continuava andando devido à sua
inércia.
Se você precisava de um novo objeto (uma bola de metal,
por
exemplo), haviam no canto da tela uma "fabrica" (representando
a
idéia de classe do Smalltalk) onde você podia obter uma.
O
Randy ficou preocupado se os usuário achariam o subconjunto do
Smalltalk
que ele representou insuficiente, e se teriam que toda
hora
"olhar por baixo do pano" e voltar para as ferramentas
tradicionais
da linguagem para terminar o seu trabalho. Para a
sua
surpresa, não só as pessoas se viravam com apenas o que ele
tinha
incluído, mas até nunca usavam umas partes do ARK. No
lugar
de ir até a "fabrica" buscar uma nova bola, era muito mais
fácil
pegar uma bola já existente e dar o comando "copy" para
ela!
Quando
li o texto do Self no fim de 1988, o Randy tinha evoluido
estas
idéias com o David Ungar para chegar a um Smalltalk que
fazia
tudo o que o velho fazia, só que com menos idéias:
Para guardar informações:
Smalltalk - variáveis de instância +
herança
variáveis temporárias
variáveis de classe
variáveis partilhadas (pool
variables)
variáveis globais
Self -
"slots" de dados + herança
E
olhe que existem Smalltalks com vaiáveis de instância de classe
e
variáveis de pacotes.
Relações de objetos:
Smalltalk - inclusão como componente
instância de uma classe
subclasses de uma outra classe
Self -
inclusão como componente
inclusão como "pai"
Programa:
Smalltalk - métodos de instância + herança
métodos de classe + herança
Self -
"slots" de métodos + herança
Criação de novos objetos:
Smalltalk - envia "new" para uma
classe
envia "copy" para uma
instância
Self -
envia "copy" para um objeto
É
melhor parar por aqui antes que eu entre em detalhes obscuros
como
"contextos de execução" e "blocos" :-) A idéia é que se
eu
ia ter que ensinar a linguagem para um bando de gente, me
parecia
mais fácil com o Self do que com Smalltalk. Mas note que
Smalltalk
é considerada uma linguagem símples comparada com
Java
ou C++, só que se pode ser ainda mais símples... porque não?
Eu
já conhecia o trabalho do Randy com o ARK, de modo que quando
vi
o Self eu imaginei que poderia ser a base para algo extremamente
gráfico
e concreto. Isso só ocorreu em 1995 com o lançamento do
Self
4.0 (as versões anteriores até tinham uma demonstração de
interface
gráfica, mas toda a programação era feita na linha
de
comando e editores normais do Unix).
Papert,
Kay, Jobs, Schank (Assumpcao Jr., 1999)
Portuguese:
Isto
aqui vai ser um pouco comprido, pois achei melhor fazer uma
introdução
histórica para todos saberem de onde vieram as idéias
que
estou tentando implementar.
Bem
no fim dos anos 50, surgiu uma nova maneira de se usar os
computadores
chamada de "time sharing" ou "on line transaction
processing
(OLTP)". As pessoas se sentavam em frente a terminais
e
interagiam diretamente com o computador. Isto foi a inspiração
para
o CAI (Computer Aided Instruction), sendo o projeto Plato
da
Universidade de Illinois (1960-1980) o exemplo mais famoso. A
idéia
era substituir o professor: especialistas criavam lições
com
uma série de textos e perguntas de múltipla escolha. Dependendo
das
respostas de cada aluno, o computador apresentava um conjunto
de
textos diferentes (ou em ordem diferente). Seria o fim da
educação
massificada e o início do "self paced learning" onde
cada
aluno teria uma educação adaptada às suas próprias necessidades.
Este
modelo não agradou muito a Seymour Papert
(http://papert.www.media.mit.edu/people/papert/)
que tinha chegado
ao
MIT depois de ter trabalhado alguns anos com Jean Piaget em
Geneva.
Ele defendia duas idéias: quem ensina é quem mais aprende
e
o ambiente de aprendizado é muito importante (aprender Francês
era
considerado algo difícil nas escolas Americanas, mas é algo
que
qualquer bebê na França consegue fazer!). Em colaboração com
os
engenheiros da BBN Inc., ele criou uma versão simplificada
da
linguagem de programação LISP (usada em pesquisa de inteligência
artificial)
chamada Logo
(http://el.www.media.mit.edu/groups/logo-foundation/).
Um aspecto
interessante
é que eles incluiram um robô semi-esférico com rodas
e
uma caneta (parecia uma tartaruga - que virou o símbolo do Logo)
que
podia ser programada pelas crianças. Note que elas aprendem
tentando
ensinar coisas para a tartaruga (que é tão burrinha,
coitada!)
e a linguagem/ambiente onde fazem isso é algo no qual
idéias
matemáticas ocorrem naturalmente, e não como um assunto a
ser
estudado.
Observação:
o Logo é usado em muitas escolas, inclusive no Brasil,
mas
quase sempre é um espetáculo triste - professores que não
entenderam
as idéias obrigam os alunos a usarem o sistema como
o
programa de desenho mais desajeitado do mundo. Os alunos ficam
orgulhosos
se depois de um semestre conseguem criar uma casinha
símples
na tela do computador, o que eles teriam feito em dois
minutos
no Paintbrush!
Voltando
ao fim dos anos 60: o Alan Kay estava muito impressionado
com
as idéias mostradas no NLS de Doug Engelbart ("mouse", edição
dinâmica
na tela, janelas, processamento de "outlines", hypermedia e
groupware)
e com as interfaces gráficas da Universidade de Utah
(o
sistema Sketchpad de desenho e interfaces de realidade virtual
3D).
Em sua tese, ele trabalhou em cima da idéia de um "computador
pessoal"
(construiu um protótipo chamado "Flex"). Ele também
estava
interessado nas idéias da linguagem de programação Simula -
ele
deu a este estilo de programação o nome de "programação orientada
a
objetos". Ele pensava no computador como uma nova mídia, uma forma de
expressão
e não um ferramenta. Quando ele viu o trabalho do Papert no
MIT,
tudo se encaixou e ele criou o Learning Research Group dentro do
Xerox
Palo Alto Research Center para desenvolver um computador pessoal
para
crianças.
O
Alan imaginou que poderia aproveitar as idéias do Flex e do
Simula,
mas numa forma totalmente gráfica. Esta linguagem gráfica
se
chamaria Smalltalk (para que as pessoas não tivesse expectativas
muito
exageradas). Só que numa conversa de corredor ele descreveu
uma
idéia de linguagem muito símples mas muito poderosa e, sem que
ele
esperasse, o Dan Ingalls mostrou sua idéia funcionando num
mini-computador
menos de uma semana depois! Com o nascimento do
Smalltalk-72
a idéia da linguagem gráfica foi deixada de lado, e
logo
eles tinham uma máquina muito mais avançada para continuar
o
projeto: o Xerox Alto. Aqui nasceram as janelas sobrepostas,
os
"pop up menus", o copiar/cortar/colar (de Larry Tesler, hoje
na
Apple, e Charles Simoni, o criador do
Word da Microsoft), a
rede
Ethernet, a impressora Laser e os infames cursores em flexa
e
em ampulheta.
Como
a evolução da linguagem para o Smalltalk-74, o grupo teve
chance
de experimentar o sistema com alunos selecionados de
colégios
de Palo Alto. Começando com a famosa tartaruga do Logo,
eles
fácilmente reproduziram os resultados do Papert. Mas empacaram
nisso
até que a Adele Goldberg teve a idéia de uma nova abordagem:
primeiro
os alunos bricariam com objetos prontos, e só depois
desta
experiência eles tentariam adivinhar como seriam estes
objetos
por dentro. Deu certo - em pouco tempo os alunos tinham
criado
vários editores gráficos, simulação de helicóptero, sistema
de
animação e outros. Refletindo sobre a experiência anos mais
tarde,
Alan Kay concluiu que eles estavam fadados ao sucesso: dado
a
seleção de alunos e a quantidade de apoio que deram e a motivação
especial,
*qualquer* coisa que tentassem teria dado certo (quer
fosse
programação ou projetar submarinos). Isso é um pouco de
exagero
(como mostrou as dificuldades com a tartaruga), mas é uma
coisa
a se ter em mente quando se faz projetos pilotos na educação
e
se pretende generalizá-los depois.
Com
o Smalltalk-76, -78 e -80, o projeto tomou o rumo de antender
às
necessidades de programadores "sérios". O Smalltalk-78 foi
criado
para um computador portátil baseado no processador 8086
e
que os pesquisadores queriam que fosse comercializado. A Xerox
matou
o projeto criando bastante frustração. Em 1979 o Jef Raskin
(que
estava criando um computador de $200 chamado Macintosh na
Apple)
convenceu o Steve Jobs a ir até a Xerox PARC para ver uma
demonstração
do Smalltalk. Ele ficou muito impressionado e mudou
totalmente
o principal projeto da Apple, o Lisa, para ter a cara
daquilo
que ele tinha visto. Ao ser chutado para fora deste projeto
pela
direção da Apple, o Jobs se apoderou do Macintosh e o transformou
num
"mini-Lisa" de $2500. Em 1982 a Xerox finalmente comercializou
suas
idéias, mas o Star custava $25.000. O Lisa, de 1983, não foi
muito
mais popular custando $10.000. Foi só o Mac, em 1984, que
realmente
popularizou as janelas e o mouse. Mas o Jobs tinha
convencido
o Bill Gates a desenvolver programas para o Mac (Word
e
Excel), e este queria ter uma imitação de Mac para que os mesmos
programas
pudessem rodar nos PCs. O Windows 1.0, e 2.0 e Windows 386
não
tiveram muito impacto, mas o Windows 3.1 mudou a história em 1990.
O
grande problema é que estas cópias todas tinha a aparência do
que
tinha sido desenvolvido na Xerox, mas não a substância. Era
ainda
mais difícil programas para o Mac ou para o Windows do que
para
os sistemas anteriores! Em 1985 a Digitalk apresentou o
Smalltalk/V
para o PC. No fim de 1987 foi criada a ParcPlace com
o
pessoal da Xerox PARC que não tinha se debandado para a Apple e
outras.
Eles lançaram uma versão bem mais "pesada" do Smalltalk
para
estações Unix. Na mesma época foi criada uma mistura da
linguagem
C com as idéias do Simula e chamada de C++. Graças à
popularidade
do C, esta linguagem logo se tornou sinónima de
programação
orientada a objetos e o Smalltalk passou a ser usado
mais
por programadores que vinham do Cobol e outras linguagens
comerciais
e achavam o C++ muito complicado.
Ainda
em 1987, a Apple lançava o HyperCard. Combinando hipermídia
com
uma programação extremamente símples, qualquer um podia criar
"stacks"
interessantes e finalmente fazer o computador fazer o que
desejasse.
Houveram muitas cópias do HyperCard, mas nenhuma tão
bem
sucedida quanto o Visual Basic.
Também
em 1987, o David Ungar da Universidade de Stanford e o
Randy
Smith da Xerox PARC se juntaram para criar uma versão
simplificada
do Smalltalk, publicando o trabalho "Self: The
Power
of Simplicity". Em 1990, depois dos estudantes do David
terem
criado a primeira versão da linguagem (com um desempenho
muito
maior do que qualquer um poderia esperar - linguagens
orientadas
a objetos tem fama de serem lentas) o grupo se mudou
para
a Sun Microsystems (http://self.sunlabs.com) . Apesar do
impressionante
progresso obtido, a empresa cancelou o projeto em
1995
para se concentrar numa outra alternativa: o Java (uma espécie
de
Pascal com umas pitadas de Smalltalk, mas com cara de C++ para
atrair
os fans desta linguagem).
Enquanto
isso, o grupo original do Smalltalk se reuniu na Apple
e
criou o Smalltalk Squeak (http://www.squeak.org) para continuarem
de
onde tinham se desviado em 1976 - um sistema que pudesse ser
usado
para trabalhar com crianças. Com a crise na Apple, o grupo
se
mudou para a Disney. Ainda não posso recomendar o Squeak para
qualquer
um - está no mesmo pé em que estava o Linux quando
comecei
a usá-lo em 1994 (se você tinha muita experiência com
Unix,
ia gostar. Senão, não ia ser nada fácil). Por enquanto o
Squeak
é mais atraente para quem já conhece Smalltalk, mas está
evoluindo
rápido.
O
Self não morreu apesar da vontade da Sun (é o que eu uso nos
meus
projetos). Vou encurtar isso um pouco -
numa próxima eu
falou
um pouco de como o que eu fiz se encaixa nos que descrevi
acima.
