Tcl/Tk Workshop `95 - Friday: Session 6
Panel: Tcl and Tk in the Classroom: Lessons Learned
Overview: The purpose of this discussion is to share perspectives
on teaching with Tcl/Tk both in academia and industry. Examining
case studies, what has succeeded and what has failed? Panel format
chosen becase we view this as an interactive, controversial issue
involving educators, researchers, and developers working within
industry.
Position by Charles Crowley
Has used Scheme/Tk in introductory programming classes, Tcl/Tk
in software engineering courses. Reasons: Tcl/Tk provides an
enjoyable introduction, allowing students to see and accomplish
results quickly. It can be used to accomplish diverse, useful
functions. Finally, it provides a framework for teaching good
CS and software engineering principles.
In addition to providing basic language introduction, data structures
and a graphical interface, it allows students to work alone and
discover satisfaction of accomplishment quickly on small-scale
but complete projects.
In the past, LISP offered these benefits plus easy extensibility.
What TclTk has been missing up to now is that it lacks a good
framework for extension management. Extension modularity and
megawidgets are also important because they facilitate teaching
good software engineering.
Examining the use of Scheme/Tk for beginning course (coupled with
a C++ course) --it offers closures, which have been traditionally
"dear to the hearts of CS professors"--but are these
really necessary? Tcl/Tk could be a very good teaching language
with the addition of objects and easier extensions/megawidgets.
Position by Joseph A. Konstan
Has offered a 10-week course specifically on Uis, for both undergraduate
and graduate students. Many already have backgrounds in CS (C,
C++, Scheme), non-majors' experience has varied. New in 1995:
offered a 3-day verson, where each day students saw the previous
day's discussion realized in Tcl/Tk.
Presentation of a video of applications developed by juniors/seniors,
developed to address specific engineering/visualization problems
but also games: goal to find applications that are meaningful
to the students.
Can teach Tcl/Tk in 75 minutes: overview, limitations, and illustrate
capabilities. Teaches about UI toolkits, other resources available
over the net for learning more. Finds that students continue
using Tk after the class, and that books have simplified the teaching
enormously. BUT--it cannot truly be learned quickly; issues such
as quoting, interface to C, and scope still cause confusion, and
there's a need for debugging and extensions.
Comparison to LISP--interpreters, list/string data structures,
memory management make it similar, but much of its popularity
results from differences--small size, no parentheses. However,
the areas which make it hardest to learn are those in which it
is not like LISP (for example, uplevel, quoting). What ultimately
sells it is the ability to see results quickly (as per the video).
Position by Michael McLennan
Has taught a 3-day course on 'Building Apps with Tcl/Tk"
at Bell Laboratories, as well as a 2-day course on "Object-Oriented
Programming with [incr Tcl]"; comments drawn from outside
courses as well.
Who takes these courses? Lots of the usual culprits (software
developers and sysadmins), but also people with varied backgrounds
including telecommunications, finance, aerospace, and physics.
Differences in learning: the amount of detail each wants, desire
for a comparison with other languages, richness of language, difficulties
with quoting and case staements being ordinary commnds. Observation
that the courses must be taught "with the students' hands
on wish", and emphasizes that examples should be developed
incrementally--and be visual, interactive, and fun--e.g. Star
Trek rescue mission program.
What confuses people: quoting, again--teaching people to internalize
how to do it takes a long time. Expand vs. Fill packer command
options. Reuse of keywords (e.g. bind) as commands, subcommands,
keywords--takes time and experience to have a feel for which is
correct. Switch in paradigms between pass-by-name and pass-by-value.
Command prefixing. To these issues, Tk 4.0 adds new complexity
to bind: bind tags, break/continue semantics, and sometimes unexpected
side-effects.
Panelist Questions:
- MM: Do you have any students who have added extensions, or
do you teach Tcl/Yk as an architectural paradigm?
- CC: The short answer is no. Real issue: software engineering
departments are good at teaching how to do things, but not as
good at teaching how to decide what to do. It's important to
emphasize design, thinking through what the student wants to see
done.
- JK: In software engineering, we emphasize structure, modularity
as well as implementation. Tcl does not provide many constructs
specifically for these areas. Should we switch focus to Perl,
Scheme.Tk?
- MM: No! Importanceof Tcl lies in the ease of picking it up,
and the fact that there is no wall you can't overcome with Tcl
and the growing extensions to it.
- MM: As GUI builders emerge, how are they going to affect the
teaching of what is essentially a scripting language?
- JK: Plan to offer courses on toolkit technology--how to add
extensiond. GUI builders will allow us to remove much of the
detailed discussion of how things work, but it's still important
to have a basic comprehension of the underlying principles.
- JK: How could we put you out of business [teaching Tcl courses]?
How could we automate a course--perhaps on the Web?
- MM: It's not impossible--to some extent that's what wish and
the man pages did originally. There's the widget tour as well,
which lets people make their own modifications and see them change
on the fly. This could become much larger--what if there were
2000 examples? But in reality, I think that this would INCREASE
the demand for training courses, not the reverse.
Open Questions:
- BASIC attracted many users because it was so easy to learn.
If people learn how to write Tcl code without underlying understanding
of how to design an application, what are the implications?
- JK: we don't teach courses purely on Tcl/Tk, but rather we
teach use of Tcl/Tk in the context, for example, of a UI design
course. One real advantage is that it's so much easier to make
changes when students make poor design decisions.
- Perhaps the fact that users have learned to implement things
more quickly means that they may have more time for really honing
their software development skills. Rapid prototyping is a plus
in this way.
- People forget that Tcl is extensible--they often assume they
have to write something before checking to see if it's already
out there or not. Perhaps another problem is that schools are
typically not exposing students to a variety of language concepts--as
a result, we may be producing students who cannot think outside,
for example, a C paradigm.
- CC: We need more of a culture of sharing, making sure people
know packages are available.
- JK: One obstacle in teaching UIs is that we have a lot of
students who are not familiar with event-driven programming.
We should be seeing more students with that kind of experience.
- If you look at the man pages for the canvas, they're extensive;
relatively light coverage in the book. This is the sort of topic--understanding
details of more complex widgets--that more course time should
be spent on; typically the sexy applications that draw people
use these anyhow.
- Closure model should be discussed more fully.
- How many of the people you teach are CS majors? How many
have even heard of Scheme?
- MM: 99% have never heard of Scheme. However, people who come
to us from a CS background have no problem picking up what it
does. But I wonder if we could make other issues, particularly
quoting, easier.
- We should probably focus more on how the parser interprets
different kinds of statements. Could the language be fixed to
make this less necessary, however?
- Is there ever a situation where you'd really want to use both
kinds of quotes in a single statement?
- MM: Curly braces for code fragments and conditionals, quotes
for strings--the important thing is to teach strategies and rules
of thumb, get these into people's minds, and let them actually
go on and get things accomplished.
- CC: There's a lot of self-indulgence in computer science teaching--closures,
complicated data structures. Need to focus on basics: no need
to focus on how to implement data structures if students don't
even know how to use them.
- I think CS schools are teaching things well--Tcl is not hard
to pick up. What's important--I have a lot of summer students
from different technical backgrounds--is that the code be, for
eample, modular and well-designed. My concern is not that this
isn't coming out of our CS departmentd--I wish we were teaching
these techniques with the non-engineering students.
- JK: In our school, 1/3 of our UI course students--probably
1/2, eventually--are not CS students; many aren't even engineers.
But another problem is that at a large state school, there are
very few free electives, and if something is not required, students
may simply not have the time to take it.
- How do we bring the message home that these techniques are
useful to a much broader audience than just CS students? The
emphasis is that our universities are not trade schools; students
are there to learn how to learn, not how to learn any one specific
language. What we may need to refine is the learnability of Tcl;
the rest may follow from there.
- MM: If you start off with quoting rules, though, you lose
people. The trick is to hook people with the capability, via
examples, then explain the underlying understanding needed to
implement the things people can relate to visually. Other issues--the
parser, sends, etc.--can come later, in this context.
- JK: How many of you were still having quoting problems 6 months
after you began using Tcl? (After a few moments--and after all
three panelists do--most of the room raises hands.) How many
of you who are not having quoting problems now feel that it's
because you understand how the parser works? How many of you
feel that it's because you have found and internalized "what
works". (The room is split about half and half.)
- But I have found that you tend to lose the sense of "what
works" if you don't use it for a while, without having a
sense of what the parser is really doing.
- Any experience teaching OpenGL? Any experience making a connection
to Tcl/Tk?
- Sometimes people don't understand ordering in transformations--that's
sort of a graphical equivalent to quoting. Tcl provides a good
medium for experimenting, trying to do things in a different order.
It's helpful to lay out specific quoting examples ahead of time,
then work through these.