The%20Past,%20Present%20and%20Future%20of%20Programming%20in%20HCI

1
The Past, Present and Future of Programming in
HCI
Brad Myers and Andy Ko CMU UW
2
why talk about programming?

• programming languages are human-computer
  interfaces
• The Psychology of Programming 1973
• Software Psychology Ben Shneidermans
  book1980
• Empirical Studies of Programming (ESP) 1986
  through 1999
• Psychology of Programming Interest Group (PPIG)
• since 1987

3
why talk about programming?

• programming languages and tools affect
  human-computer interfaces
• HCI researchers have contributed to the way most
  software is created today
• ubiquitous use of toolkits and IBs
• general computer use increasingly involves
  programming-like activity
• scripting, customization, mail rules, Web 2.0,
  etc.

4
talk outline

• computing becomes a field 70s, 80s
• everyone computes 80s, 90s
• everyone is connected 90s, 2000s
• everyone is programming the future

5
talk outline

• computing becomes a field 70s, 80s
• everyone computes 80s, 90s
• everyone is connected 90s, 2000s
• everyone is programming the future

6
drivers

• the software industry was new
• CS departments were new
• but learning syntax was difficult and typing code
  was cumbersome
• studies of novice programming errors
• new interaction techniques (visual programming,
  programming by example, syntax-directed editors)
• algorithm animation, code visualization

7
trying to make programming easier

• simpler languages
• visual programming
• visualization
• programming by example
• toolkits and interface builders
• syntax-directed editors
• interactive development environments

8
simpler languages

• maybe we can make programming accessible by
  making the language simpler, and including
  graphics?
• Basic (1963)
• Logo (1966)
• Pascal (1970)
• Hypertalk (1987)

Nope
9
why not?

• didnt understand what was fundamentally hard
  about programming
• inherent difficulties of computational thinking
  Lewis Olsons cognitive barriers, 1987
• we identified 5 classes of barriersKo Myers
  2004
• (have been hundreds of studies about why
  programming hard)
• people confused when syntax is flexible
• learning programming didnt transfer to better
  learning in math science

10
visual programming

• maybe we can make programming easier by using
  graphics instead of text?
• PICT
• Glinert 1984
• Flowchart
• Only 4 variables
• Animate execution

11
visual programming

• maybe we can make programming easier by using
  graphics instead of text?
• Agentsheets
• Repenning 91
• Agentsheets.com
• Before and afterpictures as rules

12
visual programming

• maybe we can make programming easier by using
  graphics instead of text?
• try using ideas from spreadsheets
• NoPumpGNicholas Wilde, Clayton Lewis. CHI90
• C32Myers 91

Nope
13
why not?

• visual programming doesnt scale to useful-size
  programs
• visual programs have higher viscosity
• Cognitive Dimensions analysis by T.R.G. Green
• spreadsheet ideas havent generalized
• didnt transfer to helping large numbers of
  people to be able to program

14
visualization

• maybe it will help to show pictures of the code
  and data
• Algorithm animation
• Code data visualization

Nope
15
why not?

• not a big part of the understanding problem
• some people dont understand the pictures either
• Stasko showed that constructing viz might help
  learning, but viewing, not so much CHI93

16
programming by example

• maybe it would work to let people provide
  concrete examples of what they want the computer
  to do?
• Pygmalion
• Smith 77
• Show the computerthe desired steps

17
programming by example

• maybe it would work to let people provide
  concrete examples of what they want the computer
  to do?
• Peridot
• Myers 86
• Show behavior ofcontrols (widgets)by example

18
programming by example

• maybe it would work to let people provide
  concrete examples of what they want the computer
  to do?
• Gamut
• McDaniel 96
• Tries to infer morecomplex behaviors
• Do Somethingand Stop That

Nope
19
why not?

• people are actually not very good at coming up
  with concrete examples
• examples tend to show the system the same thing
  over and over
• people cant think of the edge cases and negative
  examples
• people need to be able to edit the code, so need
  a representation they can understand

20
interface builders and toolkits

• can people draw their user interfaces?can
  providing libraries help developers?
• Menulay
• Buxton 83
• Draw graphical parts of UI

21
interface builders and toolkits

• can people draw their user interfaces?can
  providing libraries help developers?
• Andrew Toolkit
• CMU 82
• first component architecture
• Macintosh toolkit
• Apple 84
• provide a library of widgets
• object-oriented frameworks
• MacApp - 1986

YES!
22
why?

• (See HCIC99 talk)
• Address the useful important aspects of UIs
• Threshold / Ceiling
• Right balance
• Path of Least Resistance
• Helps create good UIs
• Predictability
• Programmers can tell what will happen

23
syntax-directed editors

• maybe we can solve the problems with syntax by
  letting the editor help with it?
• Cornell Program Synthesizer, 1981
• MacGnome, 1988

Maybe?
24
why not?

• quickly gets tedious for any reasonable size
  program
• syntax stops being the big issue fairly quickly
• viscosity is a problem
• hard to edit programs

BUT.
25
Alice

• Alice Pausch (1995 - today)
• drag-and-drop program parts
• pop-up menus for parameters
• dramatic impact onlearning andattitudes
• wide uptake for firstfew weeks ofintro to CS

26
interactive development environments

• maybe tools can help with the programming tasks?
• creating, maintaining, debugging code
• somewhat independent of the particular language
• code completion, syntax coloring, indenting,
  integrated with debugger
• early examples Smalltalk (1972), Interlisp
  (1979), Mesa (1980)

YES!
27
why?

• tools from the early 80s had most of what is
  found in modern tools like Visual Studio and
  Eclipse
• appropriate level of support for professional
  programmers
• code completion is the most common means of
  exploring
• obviates need for short names and helps with slow
  typing

28
but why did it take so long?

• resistance from real programmers to using IDEs
• against adopting new tools
• universities were biased towards Unix and away
  from MacPC, and no decent IDEs for Unix, so IDEs
  were not taught
• bias against teaching with tools
• IDEs wouldnt scale to real applications
• Visual Studio not widely used internally at
  Microsoft
• not until universities switched to Java that had
  good IDEs for students to use
• now, programmers are used to using IDEs
• Eclipse also re-invigorated IDE research
• plug-in architecture

29
summary of becomes a field

• learning to program is still hard
• building small things is easier
• tools and toolkits and IDEs have a big impact on
  all all levels

30
talk outline

• computing becomes a field 70s, 80s
• everyone computes 80s, 90s
• everyone is connected 90s, 2000s
• everyone is programming the future

31
drivers

• computers went from niche to ubiquitous
• what people wanted software to do became
  incredibly complex
• software gets more complex
• more features because companies used
  feature-creep to sell new versions
• globalization created demand for
  internationalization
• viruses, spam, hackers ? code must be more secure
• long-lived software ? the people who understood
  it are gone
• too big risky to rewrite, so need support for
  learning old software
• need to use multiple languages and paradigms
• database, web, spreadsheets, regular languages
  together

32
increased requirements

• commercial software had to get more complex to
  meet these requirements
• 1960s  1980s, what we built was limited in
  scope
• we built large systems, but of relatively
  simplicity
• DOS 1.0 4,000 lines of 8086 assembly
• Linux Kernel 2.6 6 million of C
• Vista 50 million

33
Increased requirements

• even for research systems
• used to be possible in research to make small
  things
• Garnet and Amulet were popular with less than 10
  widgets
• now, any toolkit needs complex capabilities, like
  standards-compliant HTML rendering
• similarly, for IDEs tool expectations about
  what is needed

34
APIs manage complexity

• old
• write programs from scratch, or
• use Unix command lines, so used only use standard
  unix libraries
• new with Windows and Java, massive APIs
• Java very much designed without I/O built-in
• shift from writing from scratch to heavy reliance
  on APIs
• needing lots of documentation examples

35
standards

• software became more integrated and more
  standards based
• more different standards
• more complex standards
• plain text (Unix) -gt html -gt XML
• plain ASCII -gt many different flavors of Unicode
• standard protocols for IDEs
• expectations that IDE support CVS version control
  system
• standard for how to compile things

36
summary of everyone computes

• how cope with increased complexity?
• APIs to the rescue!
• but during this period, little research work on
  new languages or tools for helping with software

37
talk outline

• computing becomes a field 70s, 80s
• everyone computes 80s, 90s
• everyone is connected 90s, 2000s
• everyone is programming the future

38
drivers

• the Internet arrives, leading to
• open source software
• globalization and outsourcing
• streamlined information seeking
• team-oriented tools
• studies of software teams

38
38
39
open source software

• now possible to collaborate remotely on large
  software projects
• version control systems
• bug reporting systems
• blogs, IRC, mailing lists, Twitter, Google Docs,
  IM

39
39
40
globalization outsourcing

• teams no longer fit into a room
• separated by time zones
• distance increased collaboration requirements
• increased need for specifications, design
  rationale

40
40
41
intercontinental design rationale
Amazon hires firefighters to carry design
rationale across the Pacific Ocean in their heads
41
42
streamlined information seeking

• previously had to find expert (in person or on
  usenet) or a book
• millions of examples on the web, blogs, usenet,
  discussion boards, etc.
• search simplified finding
• example code
• troubleshooting information
• documentation

42
42
43
team-oriented tools

• Eclipse framework enabled a generation of
  integrated, collaborative tools
• Jazz and Mylyn, two successful research projects
  in broad use

43
43
44
new software development methods
Agile/eXtreme Programming ideas small
groups collocation rapid iteration constant team
awareness software industry realizing that
collaboration is a crucial part of software
quality and productivity
44
44
45
studies of software teams
resurgence of studies of cooperative and human
aspects of software development coordination,
awareness, expertise, ownership, decision-making,
information seeking, trust, training, API
usability
45
45
46
software industry, research is paying attention

• Microsoft has growing group of HCI experts in
  Visual Studio division
• Microsoft Research recently formed Human
  Interactions in Programming
• software engineering research has increasing use
  HCI methods to understand problems, evaluate tools

46
46
47
summary of everyones connected
the Internet changed programming enabling new
kinds of software teams renewing interest in
programmer productivity blurring line between
software engineering, CSCW, HCI
47
47
48
talk outline

• computing becomes a field 70s, 80s
• everyone computes 80s, 90s
• everyone is connected 90s, 2000s
• everyone is programming the future

49
end-user programming

• more people are programming computers to support
  their work and hobbies
• used to just be spreadsheets and HTML
• but now much more

49
49
50
long tail of applications
of needy
millions of apps 100s of users
e.g. Twittering a random synonym of the music
genre playing on my iPod
100s of apps millions of users
e.g. word processing online banking photo
management
need
50
51
programming customization
mail rules to filter, file, and flag
email CoScripter/Chickenfoot/d.mix scripts to
automate web tasks CSS/JavaScript/AJAX to
customize World of Warcraft clan site
51
52
last months NY Times
250,000 financial analysts, biologists,
statisticians, teachers, engineers, clinical
medicine using R no training in CS, all kinds of
bugs, but good enough most science today is
fueled by custom software, often written by
scientists
52
53
gt 50 million end-user programmers

• most people who write programs at work are not
  professional programmers(based on data from US
  Bureau of Labor Statistics)

53
53
54
end-user programming is enabling wonderful things
but it has its problems
54
54
55
opportunism vs. discipline

• opportunism is sufficient if
• code isnt reused
• requirements dont drift
• and precision/accuracy of output isnt critical
• otherwise
• in 2003, TransAlta bought 24 mil in worthless
  hedging contracts because of a cut and paste error

55
55
56
programming is an educational barrier
programming is now so pervasive, its becoming
part of engineering, science, art, design
training people are abandoning these disciplines
because they involve programming
56
57
a study of 60 computing biographies
Ko 2009 (?) almost all (non-CS) students
learned to code with TI graphing calculators,
BASIC, or view source command positive, social
experiences pre-college negative, isolating in
college
57
58
languages and tools are terrible

• need to design languages and IDEs that are
  expressive enough for unique domain requirements
• how do we choose the right primitives
• can we attain the benefits of software
  engineering practices without having to teach
  them?

58
58
59
summary of everyone is programming
everything that mattered in the 70s, 80s, 90s
and 2000s to computer science and
engineering is soon going to matter to everyone
59
60
whats the role of HCI in this future?
61
open HCI issues

• simplify creation of multi-language,
  multi-paradigm mashed up software
• understand, predict API usability
• understand software design as CSCW
• create new languages/tools to support specific
  domains of work and hobbies

61
61
62
13 papers at CHI 2009
Team Analytics Understanding Teams in the Global
Workplace ESPranto SDK an Adaptive Programming
Environment for Tangible Applications Support for
Context-Aware Intelligibility and
Control Comparing the Use of Tangible and
Graphical Programming Languages for Informal
Science Education Designers Wanted Participation
and the User Experience in Open Source Software
Development Understanding How and Why Open Source
Contributors Use Diagrams in the Development of
Ubuntu Development of Decision Rationale in
Complex Group Decision Making Finding Causes of
Program Output with the Java Whyline Fisheyes in
the Field Using Method Triangulation to Study
the Adoption and Use of a Source Code
Visualization Two Studies of Opportunistic
Programming Interleaving Web Foraging, Learning,
and Writing Code Amplifying Community Content
Creation with Mixed Initiative Information
Extraction Attaching UI Enhancements to Websites
with End Users User-created Forms as an Effective
Method of Human-agent Communication
62