ing for help, how much time you spend
with people. Are there some people
who never come for help, but whose
performance indicates they should?
You cannot exactly go up to people and
say, “what are we doing wrong, why
don’t you come for help?” but consider
using a quick survey partway through
the term to ask students for feedback
on the TAs/lab assistants/student helpers as a group.
6. Do not make a big deal about
how you are doing so much and working so hard to be inclusive. Bragging
about how sensitive you are will backfire and can make people feel singled
out. Do it quietly, and trust that people are likely to learn more and enjoy
the class more if they are feeling comfortable in the educational setting
you have helped create.
I am sure this is not a comprehensive list. What do you do in your classes? What can you add to my list? Post
your ideas to the comments. Thanks!
Mark Guzdial
“Programming
Languages Are
the Most Powerful,
and Least Usable
and Learnable
User Interfaces”
http://bit.ly/1g39mAX
March 27, 2014
Andy Ko wrote a recent blog post
( http://bit.ly/1iVxF3A) with an important claim: “Programming languages
are the least usable, but most powerful
human-computer interfaces ever invented.” Ko argues the “powerful” part
with points about expressiveness and
political power. He uses HCI design
heuristics to show how programming
languages have poor usability. Obviously, some people can use
programming languages, but too few people
and at great effort.
I see that his argument extends
to learnability. There are two ways in
which programming languages have
poor learnability today—( 1) in terms
of expectancy-value and ( 2) in terms of
social cost.
What is the benefit of a closure?
Eugene Wallingford tweeted a great
quote the other day:
Educational psychologists measure
the cognitive load ( http://bit.ly/1lSmG0f)
of instruction, which is the effort that a
student makes to learn from instruction.
Every computer scientist can list a bunch
of things which were really hard to learn,
and maybe could not even be imagined to
start, like closures, recursion in your first
course, list comprehensions in Python,
and the type systems in Haskell or Scala.
http://bit.ly/1BMu8QD
Expectancy-value theory (http://
bit.ly/1sctSGD) describes how individuals balance out the value they
expect to get from their actions. Educational psychologists talk about how
that expectation motivates learning
( http://edcate.co/1iefV80). Students
ask themselves, “Can I learn this?”
and “Do I want to learn this? Is it
worth it?” You do not pursue a degree
in music if you do not believe you have
musical ability. Even if you love art
history, you might not get a degree in
it if you do not think it will pay off in
a career. Most of us do not learn Dvorak keyboards ( http://bit.ly/1jvaFNC),
even though they are provably better
than Qwerty, because the perceived
costs just are not worth the perceived
benefit. The actual costs and benefits
do not really play a role here—
perception drives motivation to learn.
If you cannot imagine closures, why
would you want to learn them? If our
programming languages have inscrutable features (that is, high cognitive
load to learn them) with indeterminate
benefits, why go to the effort? That is
low learnability. If students are not
convinced they can learn it and they are
not convinced of the value, then they
do not learn it.
The social cost of going in a new di-
rection. I was at a workshop on CS Edu-
cation recently where a learning scien-
tist talked about a study of physicists
who did their programming in Fortran-
like languages and only used arrays for
all their data structures. Computer sci-
entists in the room saw this as a chal-
lenge. How do we get these physicists
to learn a better language with a bet-
ter design, maybe object-oriented or
functional? How do we get them to use
better data structures? Then one of the
other learning scientists asked, “How
do we know that our way is better Con-
sider the possibility that we’re wrong.”
We computer scientists are always
happy to argue about the value of one
programming paradigm over anoth-
er. But if we think about it from Andy
Ko’s usability perspective, we need to
think about it for specific users and
uses. How do we know that we can
make life better for these Fortran-
using physicists?
What if we convinced some group
of these Fortran-using physicists to
move to a new language with a new
paradigm? Languages do not get used
in a vacuum—they get used in a community. We have now cut our target
physicists off from the rest of their
community. They cannot share code.
They cannot use others’ libraries, tools,
and procedures. The costs of learning a
new language (with new libraries, pro-
cedures, and tools) would likely reduce
productivity enormously. Maybe pro-
ductivity would be greater later. Maybe.
The value is uncertain and in the future,
but the cost is high and immediate.
Maybe we should focus on students
entering the Fortran-using physics
community, and convince them to
learn the new languages. Learning sci-
entists talk about student motivation to
join a “community of practice” (http://
bit.ly/1kDIhFJ). Our hypothetical phys-
ics student wants to join that commu-
nity. They are learning to value what
the community values. Trying to teach
them a new language is saying: “Here,
use this—it’s way better than what the
people you admire use.” The student
response is obvious, “Why should I be-
lieve you How do you know it’s better, if
it’s not what my community uses?”
Solution: Focus on usability.
Communities change, and people learn. Even
Fortran-using physicists change how
they do what they do. The point is that we
cannot impose change from the outside,
especially when value is uncertain.
The answer to improving both usability and learnability of programming languages is in another HCI
dictum: “Know thy users, for they are
not you.” We improve the usability
and learnability of our programming
languages by working with our users,
figuring out what they want to do, and
help them to do it. Then the value is
clear, and the communities will adopt
what they see as valuable.
Valerie Barr is a professor at Union College, and chair
of ACM-W, ACM’s Committee on Women in Computing.
Mark Guzdial is a professor at the Georgia Institute of
Technology
© 2015 ACM 0001-0782/15/03 $15.00