The Future of Teaching Programming is on Mobile Devices
Nikolai Tillmann, Michal Moskal,Jonathan de Halleux, Manuel Fahndrich,
Judith Bishop, Arjmand SamuelMicrosoft ResearchOne Microsoft WayRedmond WA, USA
Tao XieDepartment of Computer ScienceNorth Carolina State University
Raleigh NC, USAxie@csc.ncsu.edu
ABSTRACTFrom paper to computers, the way that we have been writingdown thoughts and performing symbolic computations hasbeen constantly evolving. Teaching methods closely followthis trend, leveraging existing technology to make teachingmore effective and preparing students for their later careerswith the available technology. Right now, in 2012, we are inthe middle of another technology shift: instead of using PCsand laptops, mobile devices are becoming more prevalentfor most everyday computing tasks. In fact, never before inhuman history were incredibly powerful and versatile com-puting devices such as smartphones available and adoptedso broadly. We propose that computer programming, andthus the teaching of programming, can and should be donedirectly on the mobile devices themselves, without the needfor a separate PC or laptop to write code. Programmingon smartphones that we carry around with us at all timesmeans instant gratification for students, as they can showtheir games and applications to their friends, and it meansthat students can do their homework or additional practic-ing at all times. We describe TouchDevelop, a novel mobileprogramming environment, and call out challenges that needto be overcome and opportunities that it creates.
Categories and Subject DescriptorsD.2.3 [Software Engineering]: Program editors; D.2.3[Software Engineering]: Structured programming; D.2.6[Programming Environments/Construction Tools]:Integrated environments; D.2.11 [Software Architectures]:Languages
General TermsHuman Factors, Design, Languages
Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.ITiCSE12, July 35, 2012, Haifa, Israel.Copyright 2012 ACM 978-1-4503-1246-2/12/07 ...$10.00.
KeywordsEvolution, Mobile Devices, Touchscreen, Cloud, Type infer-ence
1. INTRODUCTIONFrom scratching in sand, chiseling in stone, writing on pa-
per, using an abacus, mechanical computers, electric com-puters, mainframes, minicomputers, to eventually micro-computers/PC, the way that we have been writing downthoughts and performing symbolic computations has beenconstantly evolving. The instruments that are available forteaching follow the prevalent technologies. Ideally, the waythat a subject is taught should be closely related to how thestudents will apply the acquired knowledge later in theirprofessional careers.
Right now, in 2012, we are in the middle of another tech-nology shift: more touchscreen-based mobile devices likesmartphones and tablets will be sold than PCs, laptops, andnetbooks combined. In fact, in many cases, incredibly pow-erful and easy-to-use smartphones are going to be the firstand, in less developed countries, possibly the only comput-ing devices that virtually all people will own. Many tasksthat used to require a large computer are now feasible onsmaller devices. Even the tiniest smartphones are alwaysconnected to the cloud and have great email reading andinternet surfing capabilities. Improvements in touchscreentechnology and word prediction techniques made it possibleto perform basic typing tasks with ease. Mobile devices arenow often used to play games of a sophistication that wouldhave required the most advanced PC a decade ago.
While traditional servers, PCs and embedded systems willstay around and much critical software still needs to be writ-ten for them, a significant portion of all developed programswill target mobile devices.
What has not yet happened is the shift to use the newmobile devices themselves to write applications for those de-vices. This shift might not seem desirable for auent pro-fessional developers who spend the majority of their timewriting code and who can afford a traditional PC develop-ment environment set up in order to be more productivewith a big screen, full physical keyboard, and mouse. Butnote that in general non-essential input devices tend to die;witness for example the PDA stylus and tablet PC pen, andthe declining popularity of slide-out keyboards for phones. Ifit is possible and effective to use only a mobile device witha touchscreen to program certain applications, then other
more complicated approaches are likely to be eventually re-placed by the single-device approach, making obsolete thePC development environment tethered to a mobile devicefor testing mobile applications.
Teaching of programming should follow this trend.Students are soon more likely to personally own a smart-
phone than a traditional PC or laptop. Students will notonly own such devices, they will carry them with them atall times. They will use them not only for communication,fun, and utility, but also to store and access their most per-sonal digital data such as pictures, videos, and music.
This connection opens new opportunities for teaching pro-gramming. Instead of analyzing and manipulating abstractor teacher-provided data, students should write and executeprograms on their own mobile devices, working with theirown readily available content, making learning programmingthe engaging experience that it should be.
2. DISRUPTIONWhile some technology shifts happen gradually, they are
often accompanied by fundamental changes. We believe thatthe way we input programs and the way we handle programstate will change with the transition to mobile devices, andthere will be consequences for the programming languages aswell. It is important that teachers prepare students for theseimminent changes, which are syntactical and conceptual innature.
There are many precedents for the coupling of input de-vices and programming languages. Consider for exampleFORTRAN 77, to name one representative of the punch cardera. Each punch card had 72-column lines; in FORTRAN77, the first 5 columns were reserved for line numbers, the6th could indicate a continuation line, and the first columncould indicate a comment. All of these conventions becamecumbersome once programs were not entered directly onphysical punch cards anymore, but instead via a keyboardand editors with line buffers. We predict that moving awayfrom a keyboard, a device that allows very precise entry ofaround 100 different characters to a touchscreen typical formobile devices will again influence how the program syntaxis structured and entered. While forward-looking predic-tive text input works reasonably well on virtual touchscreenkeyboard, actions that require fine navigation, e.g., to makestructural corrections, are awkward on a touchscreen wherethe size of a finger limits precision.
The capabilities of how a computer may handle mem-ory also influences programming languages. Consider againFORTRAN 77. It did not allow dynamic memory alloca-tion and had no way to represent memory references andhad no safe external storage facilities, but only the unsafeCOMMON blocks. Modern programming languages havegreatly improved this situation, providing garbage collectedobject references, and routines for structured I/O. However,the modern languages were designed to handle local mem-ory and storage, and they did not yet make the transition tocloud-connected devices where the user often perceives stateas not being tied to a particular device, but instead to berooted in the cloud, being made available as needed to fillin for the current task at hand. Besides the general hypeto move storage to the cloud, mobile devices are especiallyaffected by this trend as they have short replacement cycles,and they are easily lost or broken. Instead of burdeningthe programmer with the implementation of abstractions to
string ::= Hello world!\n | ...number ::= 0 | 1 | 3.1415 | ...local ::= x | y | z | foo bar | ...action ::= frobnicate | go draw line | ...global ::= phone | math | maps | ok button | chat roster | ...property ::= vibrate | sin | add pushpin | disable | add | ...exprs ::= expr | exprs , exprparameters ::= | ( exprs )op ::= + | | / | | = | > | < | = | != | and | or | ||expr ::= local | string | number | true | false| expr | not expr | expr op expr| action parameters | expr > property parameters
block ::= stmt | block stmtlocals ::= local | local , localsstmt ::= expr | locals := expr | do nothing| if expr then block else block| while expr do block | foreach local in expr do block| for 0
tween different syntax elements can be easily achieved bytapping on a finger-sized user interface element on the screeninstead of relying on a full physical or on-screen keyboardthat enables editing of code at the level of individual charac-ters from which words and in turn sentences are formed. Todetermine which user interface elements are shown on thelimited screen space, the editor leverages inferred types andit mines previously written programs to provide highly pre-dictive auto-completion suggestions to the user. In effect,the user only has to choose from lists of statement kindsand expression tokens instead of entering statements andexpressions character by character.
In addition to the basic programming functionality (lan-guage, interpreter, editor), TouchDevelop provides a socialexperience, allowing users to publish and download pro-grams, discuss them by writing comments, publish screen-shots, and users can give hearts to a program or commentwhen they like it. A central program repository in the cloudmanages all programs and analyzes them for privacy con-cerns and code duplication.
Figure 2 shows the different views of the code editor inTouchDevelop, including a listing of a complete program.Each screenshot captures the entire screen of a smartphone.Note that all surface areas which act as buttons are largeenough to be tapped on quite precisely by a big finger. Theleft screenshot (a) shows a list of statements. The user canselect a statement by tapping somewhere in a statement line.The middle screenshot (b) shows how the user adds addi-tional statements by choosing from a list of possible state-ment kinds. It is not possible to make syntactical mistakes atthe statement level. Once the statement kind is chosen, theview transitions to the expression editor to edit the expres-sion associated with the statement. The right screenshot (c)shows the expression editor, which is implemented similarto a rich calculator. Individual built-in syntactic primitivessuch as numbers and operators can be accessed via nestedkeypads, opened by first tapping on the corresponding sum-mary button. Other semantic procedure and function callscan be inserted by eight quick buttons, which are populatedbased on the type of the current scope, and historical usageinformation.
TouchDevelop is available as an free application on theWindows Phone Marketplace.
4. EXPERIENCEAfter six months, more than 3000 games and applica-
tions have been written and published by users of TouchDe-velop, using the touchscreen as the only input device. TheTouchDevelop website1 shows all games and applications.
Many games written by users leverage the accelerometer ofthe phone as a controller, measuring how the phone is tilted,including a fully-featured Tetris-like game, a Breakout-likegame, warehouse games where boxes need to be moved toparticular locations, and many more. Other applications areuseful tools and utilities, including a program that queriesthe calendar on the phone and automatically connects to anycurrently scheduled online meeting, a program that queriesthe current state of parking meters in a city via a web serviceand projects the information on a map, a Siri-like applicationthat connects the microphone, a speech recognition engine,and a search engine via web service calls, and many more.
In the following, we report on our ongoing experienceworking with students at various levels2.
4.1 9 Weeks with High School StudentsThe first indication of the feasibility of the approach was
an experience with two high school students who spent 9weeks over the course of a summer developing games and ap-plications with an early version of TouchDevelop. The stu-dents had some previous experience with programming onPCs for PCs using Java, Python, and/or Scheme, but theyhad never written applications for mobile devices before. Weprovided them with smartphones that had TouchDeveloppre-installed, and we encouraged them to be investigativeand learn by themselves how to create games and applica-tions with the environment. The only instructional materialwe provided to the students was a set of sample games andapplications, and a few videos that walk through the processof creating a new application, tap by tap on the touchscreen.We would help them later when they had particular ques-tions about the language, built-in functions, the editor, orother aspects of the environment.
The students started as learners of the language and en-vironment, and quickly became relatively experienced pro-grammers who could write quite sophisticated games andapplications by themselves. One student wrote 19 differentgames and applications during this time. Some of the stu-dents games rival existing apps in software marketplaces forsmartphones.
4.2 90 Minutes with 30 High School Studentsin a Computer Science Class
We were invited to a high school to work with 30 studentsin grades 11-12 in a computer science class for 90 minutes.The students had recently started the class and were alreadyintroduced to some programming concepts but they had noexperience in developing mobile applications. We provided12 phones for students to work in groups of three. Aftera brief introduction to TouchDevelop, the students had 45minutes to explore the language and write their own mobileapplications. All groups were able to write applications ontheir own, including a program that changes the color of thescreen based on the direction in 3D space that the phoneis facing, a peek-a-boo game that utilized the direction thephone was facing to display a covered face or an open facewith the audio track to accompany it, and a role playinggame where the user has to answer questions to progress.The regular computer science teacher made the followingremarks: Even though most of the students havent learnedabout some to the [techniques] before, like using a loop or acollection of objects, the concepts made sense in the contextof a phone app. [It] was a fun way to learn about program-ming topics and obtain instant feedback on whether you didit correctly or not.
4.3 2 Hours wit...