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.