Don't Teach Coding - Lindsey D. Handley - E-Book

Don't Teach Coding E-Book

Lindsey D. Handley

0,0
19,99 €

-100%
Sammeln Sie Punkte in unserem Gutscheinprogramm und kaufen Sie E-Books und Hörbücher mit bis zu 100% Rabatt.

Mehr erfahren.
Beschreibung

The definitive resource for understanding what coding is, designed for educators and parents Even though the vast majority of teachers, parents, and students understand the importance of computer science in the 21st century, many struggle to find appropriate educational resources. Don't Teach Coding: Until You Read This Book fills a gap in current knowledge by explaining exactly what coding is and addressing why and how to teach the subject. Providing a historically grounded, philosophically sensitive description of computer coding, this book helps readers understand the best practices for teaching computer science to their students and their children. The authors, experts in teaching computer sciences to students of all ages, offer practical insights on whether coding is a field for everyone, as opposed to a field reserved for specialists. This innovative book provides an overview of recent scientific research on how the brain learns coding, and features practical exercises that strengthen coding skills. Clear, straightforward chapters discuss a broad range of questions using principles of computer science, such as why we should teach students to code and is coding a science, engineering, technology, mathematics, or language? Helping readers understand the principles and issues of coding education, this book: * Helps those with no previous background in computer science education understand the questions and debates within the field * Explores the history of computer science education and its influence on the present * Views teaching practices through a computational lens * Addresses why many schools fail to teach computer science adequately * Explains contemporary issues in computer science such as the language wars and trends that equate coding with essential life skills like reading and writing Don't Teach Coding: Until You Read This Book is a valuable resource for K-12 educators in computer science education and parents wishing to understand the field to help chart their children's education path.

Sie lesen das E-Book in den Legimi-Apps auf:

Android
iOS
von Legimi
zertifizierten E-Readern

Seitenzahl: 424

Veröffentlichungsjahr: 2020

Bewertungen
0,0
0
0
0
0
0
Mehr Informationen
Mehr Informationen
Legimi prüft nicht, ob Rezensionen von Nutzern stammen, die den betreffenden Titel tatsächlich gekauft oder gelesen/gehört haben. Wir entfernen aber gefälschte Rezensionen.



Table of Contents

Cover

About the Authors

Acknowledgments

Introduction

Who Is This Book For?

Let's Do It!

CHAPTER 1: Prologues

A WIZARD'S TALE

A LANGUAGE WITHOUT

A LANGUAGE WITHIN

LANGUAGES WITHOUT

LANGUAGES WITHIN

CHAPTER 2: Beginnings

A WIZARD'S TALE

A LANGUAGE WITHOUT

A LANGUAGE WITHIN

LANGUAGES WITHOUT

LANGUAGES WITHIN

CHAPTER 3: Middles

A WIZARD'S TALE

A LANGUAGE WITHOUT

A LANGUAGE WITHIN

LANGUAGES WITHOUT

LANGUAGES WITHIN

CHAPTER 4: Ends

A WIZARD'S TALE

A LANGUAGE WITHOUT

A LANGUAGE WITHIN

LANGUAGES WITHOUT

LANGUAGES WITHIN

Conclusion

NEXT STEPS: LEARNING SCIENCES

NEXT STEPS: LANGUAGES TO LEARN

NEXT STEPS: CODING

NEXT STEPS: SOFTWARE ENGINEERING

NEXT STEPS: HACKER CULTURE

NEXT STEPS: HISTORY

NAMING THINGS: COMPUTER SCIENCE

NAMING THINGS: PHILOSOPHY OF MIND

NAMING THINGS: LEARNING SCIENCE

THANK YOU

Bibliography

Index

End User License Agreement

Guide

Cover

Table of Contents

Begin Reading

Pages

iii

iv

v

xi

xiii

1

2

3

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

82

83

84

85

86

87

88

89

90

91

92

93

94

95

96

97

98

99

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

175

176

177

178

179

180

181

182

183

184

185

186

187

188

189

190

191

192

193

194

195

196

197

198

199

200

201

202

203

204

205

206

207

208

209

210

211

212

213

214

215

216

217

218

219

220

221

222

223

224

225

226

227

228

229

230

231

232

233

234

235

236

237

238

239

240

241

242

243

244

245

246

247

248

249

250

251

252

253

254

255

256

257

259

260

261

262

263

264

265

DON’T TEACH CODING

Until You Read This Book

 

 

STEPHEN R. FOSTER

LINDSEY D. HANDLEY

 

 

 

 

 

 

 

 

This edition first published 2020© 2020 by John Wiley & Sons, Inc. All rights reserved.

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, except as permitted by law. Advice on how to obtain permission to reuse material from this title is available at http://www.wiley.com/go/permissions.

The right of Lindsey Handley and Stephen Foster to be identified as the authors of this work has been asserted in accordance with law.

Registered Office(s)John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, USA

Editorial OfficeJohn Wiley & Sons, Inc., River Street, Hoboken, NJ 07030, USA

For details of our global editorial offices, customer services, and more information about Wiley products visit us at www.wiley.com.

Wiley also publishes its books in a variety of electronic formats and by print-on-demand. Some content that appears in standard print versions of this book may not be available in other formats.

Limit of Liability/Disclaimer of WarrantyWhile the publisher and authors have used their best efforts in preparing this work, they make no representations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives, written sales materials or promotional statements for this work. The fact that an organization, website, or product is referred to in this work as a citation and/or potential source of further information does not mean that the publisher and authors endorse the information or services the organization, website, or product may provide or recommendations it may make. This work is sold with the understanding that the publisher is not engaged in rendering professional services. The advice and strategies contained herein may not be suitable for your situation. You should consult with a specialist where appropriate. Further, readers should be aware that websites listed in this work may have changed or disappeared between when this work was written and when it is read. Neither the publisher nor authors shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages.

Library of Congress Cataloging-in-Publication Data

Names: Handley, Lindsey, author. | Foster, Stephen, 1985- author.Title: Don't teach coding : until you read this book / Lindsey D. Handley, Stephen R. Foster.Description: First edition. | Hoboken, NJ : Jossey-Bass/John Wiley & Sons, 2020. | Includes bibliographical references and index.Identifiers: LCCN 2019055396 (print) | LCCN 2019055397 (ebook) | ISBN 9781119602620 (paperback) | ISBN 9781119602644 (adobe pdf) | ISBN 9781119602637 (epub)Subjects: LCSH: Computer programming—Study and teaching.Classification: LCC QA76.27 .H364 2020 (print) | LCC QA76.27 (ebook) | DDC 005.13—dc23LC record available at https://lccn.loc.gov/2019055396LC ebook record available at https://lccn.loc.gov/2019055397

Cover Design: Wiley

To our students,            you taught us to teach.

To our teachers,            you taught us to learn.

About the Authors

Dr. Stephen R. Foster is a researcher, author, and co-founder of multiple social enterprises with a mission to teach teachers how to teach coding. A fierce advocate for the power of coding to bring about worldwide change, he has himself coded to generate peer-reviewed scientific results, coded to build educational technology solutions for teachers and students, and coded to bootstrap educational startups and non-profit organizations out of thin air. All in all, these countless lines of code have all been in service of a single vision: to establish coding education as a basic human right across the globe. In short, he codes to teach coding.

Dr. Lindsey D. Handley is a researcher, entrepreneur, teacher, and author. For the last 10 years, the National Science Foundation has funded the research, design work, and the social enterprises that she operates. As a skilled coder, data scientist, and biochemist, she envisions a world in which we no longer suffer from a worldwide shortage of scientific fluency. To this end, she fights for the unification of science and education on two fronts: the use of science to improve education; and the improved teaching of science worldwide. In short, she applies science to design better ways of teaching science.

Together, they are the co-founders and leaders of ThoughtSTEM and MetaCoders.org – two social enterprises that have touched the lives of hundreds of thousands of beginning coders worldwide.

Acknowledgments

Thank you to the following people for taking time to read and provide feedback on earlier drafts: Dr. Jody Kelly, Dr. Shriram Krishnamurthi, Dr. Janet Siegmund, Kelly Foster, Matthew Butterick, and Allan Schougaard. Your contributions helped make this book what it is.

Thank you to the creators of Racket for their trailblazing work in language-oriented programming, without which we wouldn't have been able to design the programming languages for this book about programming languages.

Introduction

If there's one thing this book seeks to address, it is: What are programming languages?

It sounds simple, but answering this question deeply will require us to ask other questions: Why do we call them “languages”? Why are there so many? Why do people fluent in them get paid so much? How are they related to those other things we call “languages” (like English, Spanish, or American Sign Language)? Where do they come from? Where are they going? How do we learn them? What happens in your brain when you do?

And, above all:

How do we teach them?

Japan, Italy, England, and Finland are just a few of the countries that have begun to mandate coding education throughout K-12 public education. Computer science educational standards now exist in 22 U.S. states – two of which have passed legislation that requires coding education statewide from elementary to high school.

As the world embarks on a global change to its collective education systems, it is worth asking some basic questions.

Technically, this book is about what you should know before you start teaching (or learning) a programming language. But the book will also teach you a few simple languages in order to make headway on some of the deeper questions.

There is a structure that frames the four chapters in this book, each of which have five parts – five arcs that recur from chapter to chapter.

The Wizard's Tale is the only fictional arc of the book. At the beginning of each chapter, this narrative introduces the main ideas in a lighthearted way. Sometimes the truest things can only be said in fiction.

The pair of arcs called A Language Without and A Language Within are where you'll learn about coding – one language at a time. In A Language Without, we'll examine how the design of a language gives its users certain cognitive powers, and cognitive pitfalls. In A Language Within, you'll be given exercises to help you actually learn those languages (if you wish) – meditating on the gaining of those powers for yourself, while learning to avoid the pitfalls. The languages will increase in power and complexity as the book progresses – ending with the most powerful kind of programming languages: what computer scientists call “the Turing-complete languages.”

The arcs called Languages Without and Languages Within will “zoom out” – beyond you, beyond us, beyond this book, beyond the present day. In Languages Without, we'll piece together the epic story of language – literally, the story of stories themselves. It began before this book, indeed before the invention of writing and is still unfolding today. In Languages Within, we'll examine recent neuroscience about how the human brain processes language, how it acquires fluencies – and ultimately, how it earns the right to participate in that epic story of language that is unfolding all around us.

Human beings are linguistic creatures; and programming languages are one of the weirdest linguistic things we've done in the last few thousand years. The bigger our historical lens, the easier it is to see just how weirdly magical they are.

Who Is This Book For?

Mainly, this book is for K-12 teachers of coding, or any educated adult with an interest in the teaching and learning of programming languages. We assume no prior coding knowledge on the part of the reader, however.

This is because, increasingly often in the coming years, teachers who once taught a different subject will find themselves suddenly teaching coding. So we wanted this book to be of use to teachers in those situations. As a rhetorical strategy, we'll often seem to be speaking to the reader as if they were a coding student. If you are a teacher who is also a student, feel free to assume we are speaking to you.

If you are a teacher who is not also a student – ask yourself, why aren't you a student? In this field, the learning never stops. There's always another language, another library, another framework, another tool-chain, another repository, another engine, another platform, another service, another environment, another paradigm, another sub-field, another beautiful idea.

The teaching and learning don't stop. The job titles just change.

Finally, because our goal is to teach coding teachers what all too many do not know before they begin teaching – even expert coders may find insights here that they were never taught (because their teachers did not know). Thus, your expertise in coding will not prevent you from enjoying this book. We expect the book to be readable by: industry veterans while their unit tests run, computer science grad students in between meetings with their advisors, and battle-tested hackers amidst contributions to open-source projects.

Many of us appreciate the power of K-12 education. The students of today will be our colleagues tomorrow.

Let's Do It!

We hope this book will empower teachers and students to write the future of education – one line of code at a time.

At any time, for any reason, join us.

dont-teach.com/coding

CHAPTER 1Prologues

“The programmers of tomorrow are the wizards of the future. You're going to look like you have magic powers compared to everyone else.”

Gabe Newell, founder, Valve

“Any sufficiently advanced technology is indistinguishable from magic.”

Arthur C. Clarke

“The programs we use to conjure processes are like a sorcerer's spells. They are carefully composed from symbolic expressions in arcane and esoteric programming languages.”

Harold Abelson and Gerald Jay Sussman, Structure and Interpretation of Computer Programs

A WIZARD'S TALE

The Sorting of Wizards

“A sorting shall now commence!” an ancient wizard announced. “We must assign all of you into your various Houses. Each House at this prestigious school champions a slightly different way of learning how to become a coding wizard. I will now explain precisely how that works…”

Henry, who could not pay attention to lectures for very long, leaned over and asked his new friends, “How does it work? How many Houses are there?”

His better-informed friend Harmony replied, “There are over a thousand, with more being added every day.”

“Over a thousand!” hissed Henry. There was no way he was going to end up in the same House as his new friends.

“But,” his goofy yet loyal friend Rob said, “I've heard that the sorting algorithm takes your preferences into account. So you can basically choose which House you start in.”

Henry sighed with relief. “Good, which one are you both picking?”

“Definitely Python,” said his friend Harmony, as if there were no doubt in the matter.

“Really?” says his friend Rob, doubtfully. “My dad said I should pick Scratch.”

This sparked a debate between Harmony, whose position was that none of the great wizards actually use Scratch in their day-to-day work, and Rob, whose position was that Scratch was a better House for beginners to start in, and that they could always switch Houses later.

“You can switch?” asked Henry.

But Rob and Harmony didn't hear him. They were busy debating.

Henry's heart was starting to pound. The ancient wizard had already begun directing the students standing at the front of the Great Hall to start queuing up for the sorting process. One by one, they went onto the stage and sat on a stool. One by one, the ancient wizard placed upon them a weird cap with blinking lights. Each time, after a few moments of making beeps and boops, the cap's lights flashed green. Each time, it announced with a mechanical voice the House into which the candidate had been sorted:

“Java,” it said for one. “C plus plus,” it said for another. “Javascript,” it said for another.

“Is Java part of the JavaScript House?” Henry tried to ask his friends. But they were too deep in conversation.

Henry noticed that he was being watched by a nearby group of “cool kids.” One boy said to his friends, “This kid doesn't even know what JavaScript is.”

Henry tried to ignore them, but their snickering hurt.

Meanwhile the hat continued to drone out the names of Houses. “C sharp,” it said for one. “Ruby,” it said for another. “C,” it said for another. After receiving the hat's proclamation, each student grinned and exited the Great Hall through a door in the rear of the stage, presumably to meet the other students in their Houses. The number of students left in the Great Hall was beginning to thin.

Henry began to make his way through the crowd of students, toward the back of the Great Hall. Other kids gave him strange looks as he squeezed between them.

Finally, at the rear of the hall, just as he was about to curl into a fetal position between a suit of armor and a damp stone corner, he discovered that Harmony and Rob had followed him.

“What's wrong?” said Rob. “Where are you going?”

“It's just…” said Henry.

“You don't know which House to pick, do you?” said Harmony. “Not to worry. I'll help. The top 10 Houses right now are JavaScript, Python, Java, C++, PHP, Swift, C#, Ruby, Objective-C, and SQL. But you obviously wouldn't want to go into the SQL House – because they don't do general purpose magic, just database magic. And you might want to be careful if you go into the Swift or Objective-C Houses – because their magic is proprietary. With C#, some people think that's proprietary magic too, but there's an open source –”

Henry covered his ears to stop the flood of words he didn't understand. “I wasn't born into a coding family. Maybe I'm just not cut out for –”

“Neither was Harmony,” his friend Rob interrupted. “She just spends a lot of time on Google. My parents, on the other hand, were both wizards.” He said this proudly. “My father sorted into Java, and my mother sorted into Ruby. But both of them always say that it doesn't really matter where you start.” He gave Harmony a pointed look. “It's where you end up that matters.”

“But,” said Henry, frantic, “they can't ALL be equally good places to start. If they were all equally good, why are there so many different ones?”

“Each House does magic,” said Harmony. “They just use a different language to express their magic. At the end of the day, though, magic is magic.”

Meanwhile, over half of the students had already been sorted. Still the cap droned on. “Objective-C,” it announced. “FORTRAN,” it said. “HTML,” it said.

Harmony and Rob both winced at the “HTML” announcement.

“See?” exclaimed Henry. “They aren't all equal. What is HTML? What was that face you both made?”

“Okay,” said Harmony, “maybe they aren't ALL created equally. HTML is a kind of magic, don't get me wrong. But it's a less powerful kind of magic. You wouldn't want to spend your whole time here just studying HTML. If you did, you might not be able to get a job as a wizard afterward.”

Henry sank to the ground and rested his head against the cold metal of the suit of armor.

“My mom and dad say you shouldn't worry about getting a job,” said Rob. “You should just learn to love magic.”

Henry said, “I just want to be in a House with you two. But even you two can't agree.”

Rob and Harmony exchanged a look. “Give us a moment,” said Rob, pulling Harmony aside. They conferred in hushed tones.

Henry couldn't hear them over the constant drone of the sorting hat: “Prolog. Scratch. Algol. Perl. XML. Scratch. Haskell. CSS. Racket. Bash. Ruby. Python. TypeScript. Scratch.” And so on.

When they came back, Rob said:

“Okay, we've decided. You'll go first, and whatever you get sorted into, we'll pick that too.”

Harmony didn't seem happy about it, but she nodded. “Wizards work in teams,” she said. “At the end of the day, what matters is that we stay together.”

Henry was dumbfounded. He didn't deserve friends like these. They helped him to his feet, where he did his best to hide that his knees were shaky and weak. Arm in arm, they joined the end of the queue – the last of the young wizards to be sorted.

By the time Henry stepped up on the stage, the Great Hall was empty, save his two friends behind him, and the ancient wizard in front of him. Henry sat upon the stool and closed his eyes as the hat settled upon his head.

He could hear it talking through a speaker near his ear. “Well, well, well…what have we here?” it said. “Henry doesn't know what House he wants to be in…Hmmm… I suppose we could put you in HTML, and –” Henry stiffened. “No? What about Scratch?” Henry didn't know what to say. “Why am I asking you, anyway? I could put you anywhere, and you wouldn't know the difference.” Henry shifted uncomfortably. “Still, I sense a great power within you – greater even than any of the cool kids who came onto the stage before you…” Henry wasn't sure whether he should feel complimented about his mysterious “great power” or worried that he was uncool. “Yes, the more information I gather, the more I'm certain of it. You're a very special young wizard. Much too special for the lesser Houses. Perhaps I could sort you into a venerable old House, such as C. Or perhaps an ancient House, such as Lisp. Or perhaps you'd excel in a hip, newer House, like Rust, or an obscure but powerful House like Prolog or Haskell. Or perhaps a solid, popular House, like Python or Java. Interesting… I've never had so much trouble sorting someone before,” Henry's heart was beating so hard that he could barely hear the hat anymore. Was he really destined for greatness? The suspense was so painful that he wanted to just shout the name of a House at random in hopes that the hat would put an end to it all. Somehow, he didn't. “Hmmm, well, if I can't tempt you by dropping the names of these Houses, I suppose I have no choice,” said the hat, “but to place you into a House that I've only assigned a handful of young wizards before…” Henry tensed.

To his surprise, the ancient wizard took the hat off of him. The look on his face was grave.

“Henry,” said the ancient wizard, “do you know what this means?”

Henry tensed. “I didn't hear it say anything.”

“You're right,” said the ancient wizard. “It has been many, many years since I've heard the hat say nothing at all. In fact, the last time this happened, I was the one sitting on that very stool.” He scratched his beard. “Perhaps the three of you,” he said, “have been chosen by fate.”

Voice trembling, Henry asked, “What House did you get sorted into?”

The ancient wizard said, “This House has no name.”

“The House of No Name!” gasped Rob. “My parents said it was just a myth.”

The ancient wizard turned his attention to Rob and Harmony, still standing in the queue line, waiting to be sorted.

“No,” said the ancient wizard. “If we called it the House of No Name, that would be a name, and therefore contradictory. When we refer to it, we must resort to ‘This House has no name.’ It's a sacrifice we must make to avoid the contradiction.”

“I've never heard of a House with no name,” said Harmony, skeptically. “There's no wizard language without a name.”

“This House,” said the ancient wizard, “is the only House that isn't named after a wizard language. That's because we don't subscribe to any particular wizard language.”

Harmony scoffed. “One can't do magic unless one has a wizard language,” she said, as if she were the authority on the matter.

“You're right,” said the ancient wizard. “Focusing on a single language is not our main approach to learning magic. Rather, we study language itself.”

As if to underscore that the ancient wizard had made his main point, the phrase “language itself” echoed throughout the now empty Great Hall.

“It definitely sounds way cooler…” said Rob. He and Henry both looked at Harmony.

“No way,” she said. “I'm joining Python. I want to actually get a job.”

The ancient wizard shrugged. “The sorting hat will ultimately respect your wishes. However, if I may impart just a small moment of wisdom…” The ancient wizard cleared his throat. “If a job is what you seek, many roads will take you there. At the end of the day, though, when you're looking back on your life, don't you want to take comfort in the fact that you took the road that was way cooler?”

The words “way cooler” seemed to echo throughout the Great Hall.

Harmony waivered.

“Come on, Harmony,” said Henry. “Wasn't it you who said that wizards always work in teams?”

With a sigh, she said, “Fine. I'll do it. I'll join the House of No Name – or this House which has no name, or whatever it is. But for the record, I think it sounds weird, and I don't like it.”

The Call to Action

The ancient wizard motioned for them to follow him. “Come,” he said, “I will personally teach you three the ways of this House which has no name.”

He reached into his robe and pulled out three copies of a book, giving one to each of them. The title: Don't Teach Coding.

Henry glanced nervously at Harmony. She did not look pleased.

To be continued…

A LANGUAGE WITHOUT

Our Strange Protagonists

This book is about those languages that make computers do things.

Most people today call them “programming languages” – though they weren't always. These languages, oddly enough, are the protagonists of this book – and a mysterious set of heroes they are indeed. On the one hand, they are the tools with which programmers weave the software of the world. On the other hand, the act of learning these languages is what makes us into programmers. They are both tools and rites of passage.

As if that wasn't strange enough, once becoming programmers, we use programming languages to make other software – including, oddly enough, more programming languages. If this sounds like a loop, it is – one that affects everyone who has ever learned programming, and anyone who ever will.

Many of us can outline our personal histories as programmers by listing the languages we learned in different chapters of our lives. One of the authors first learned to program in a language called Applesoft BASIC, which came with his parents' first PC. Back then, people were still calling Apple computers PCs, up until IBM-compatible PCs re-wrote that definition. These new “real” PCs also shipped with a version of BASIC called QuickBASIC – itself an evolution over earlier versions of BASIC. He learned Java, Logo, Visual BASIC, Perl, and Pascal in high school. In college, it was more Java and Haskell, with an additional helping of C, C++, Ruby, Python, and Lisp. When he went into industry, it was Ruby, PHP, SQL, Bash, XML, HTML, CSS, and JavaScript. For his master's degree, it was C#, more Java, more Haskell, and Racket. For his Ph.D. and beyond, it was more Racket, and–

You get the point.

And that's just his story. Ask any programmer what languages they've mastered in their lifetime, and you'll get a different story. Sometimes it will be a long story, sometimes short. The details will change depending on when and where they were born, which languages were in vogue when they were going through grade school, which ones were taught in college, which ones were used by the companies that offered them jobs, which ones they selected for personal projects.

As working programmers, we have many cognitive tools, yet our languages are truly special. They are what we use to magically convert the vague linguistic utterances of non-coders – that is, “Solve problem X for client Y” or “Make an app that makes money” or “Get us more users” or “Make this data comprehensible” – into precise programs that, when run, actually do those things that non-coders could only talk about. Our languages are what make us look like wizards to others.

The story of how a programmer's mind develops feels like a personal experience – yet every programmer's origin story is woven into that larger story of programming languages. There are common threads. There are patterns. The larger story knits us together as a community. Linguistic history is our history; linguistic future is our future. Languages are the tools that shape us; we are shaped by the programmers who shaped those languages.

Ironically, few of us know the larger stories before beginning to wield a language. It is a rare student indeed who picks up one of these sacred tools for the first time with full knowledge of its true history, or its true power. Rather, most of us made our first steps as programmers by pulling one of the many magic swords from its stone and proceeding to chop vegetables with it – unable to see the tool for what it truly was. Languages, after all, are strange things: tools of the mind. As such, they cannot be correctly seen until after they have been learned.

These cognitive tools also deeply affect the teaching arts. Their sheer number poses an Eternal Conundrum: Teachers and students must reckon with their multitude year after year. The twin questions of the conundrum are: “Which one should I learn?” and “Which one should I teach?”

The Eternal Conundrum serves as the backdrop while our society embarks on a historic first: to install the first large-scale public infrastructures for teaching coding in a world that has finally seen that the light of the software dawn is only growing brighter. It took time, but the direction has become quite clear. K-12 computer science educational standards have been drawn up in 22 states (Lambert 2018). Iowa and Wyoming have passed legislation mandating coding in all elementary, middle, and high schools statewide (Iowa 2019) (Goldstein 2019). Non-profit advocacy groups like Code.org and CS For All continue to successfully drive the teaching of computing classes from Pre-K to 12th grade (Code.org 2019) (CSforALL 2019). The National Science Foundation has invested several million in the CS 10K initiative (Brown and Briggs 2015) – its mission: to produce 10,000 new high school computer science teachers across America. Even big tech companies like Google and Microsoft are spending money and labor on the effort – developing free or low-cost out-of-the-box curriculum and software to facilitate coding education.

England has already mandated computer science classes for all children between 5 and 16 years of age (United Kingdom 2013). Italy has launched an endeavor to introduce computing logic to over 40% of its primary schools (Passey 2017). Japan will mandate computing education starting in primary school by the year 2020 (Japan 2016). Finland introduces coding and computational thinking starting in 1st grade (Kwon and Schroderus 2017). One by one, the countries of the world join in this unified initiative.

When a society changes its public school systems, it is changing its very definition of “basic literacy” and therefore of “educated person.” Let's take the current trend to its extreme and imagine, for a moment, a world in which coding fluency is acquired by all students throughout all grade levels and beyond. In other words, the average person walking down the street will have had 12 years of computer science education. It's safe to say, that if school systems do an even moderately good job, the average citizen will be fluent in one or more programming languages. For many, this fluency will start so early in life that they will have no recollection of not knowing how to code.

Because of the growing importance of these enigmatic things called programming languages, which we are eagerly welcoming into the minds of our children, this book examines a loop of linguistic ideas – each so interconnected with the others that they are best pondered together, in a single book.

Programmers design new programming languages. Teachers teach programming languages to non-programmers. Learning programming languages makes non-programmers into programmers. This means, some of the programmers we teach today will design languages that the teachers of tomorrow will use. These languages will help shape the minds of students the day after tomorrow. So the wheel turns.

This means that some of the programmers of today will directly affect the teaching and learning of programming tomorrow. And by corollary: All of the teaching and learning of programming today has already been affected by programmers who created the languages of yesterday. As schools across the world engage in their individual experiments to teach coding, let us not lose sight of what connects us all.

Our programming languages can be learned, wielded, taught, and created. They are many-faced and multifaceted. In this book, we will sometimes speak of them all as a unified thing – a single entity named “the programming languages of the world.” Sometimes we will speak of them as individual things: like “Java,” “BASIC,” or “Racket.”

We said these languages are “the protagonists.” And that is true: Sometimes we will study them as protagonists. But languages are tricky things.

Sometimes they may seem to shrink down and become objects of interest in some other protagonist's story. That is how we as students first encounter a language: They pop into the story of our lives, perhaps helping us, perhaps frustrating us, perhaps intriguing us, perhaps boring us. There is no shame in any of these.

Even for a single student, the metaphors may shift over time: A language is the road beneath your feet, the magic sword you are wielding, the mentor you meet along the way, the mountain you are climbing, or even (at times) your arch-nemesis.

Languages will go by many metaphors throughout this book too: sometimes a fabric that connects us, sometimes a sword, sometimes a tool, sometimes an object of study, sometimes a mountain, sometimes a wave, sometimes magic. It is inevitable. Languages are complex characters.

They were not created by simple creatures.

(cons'Apple 'Soft)

The word “Applesoft” in “Applesoft BASIC” is a combination of two company names: “Apple” and “Microsoft.” Originally licensed by Apple from Microsoft in 1977, the Applesoft license only cost Apple $31,000 (McCracken 2012), but allowed them to ship their Apple II computers when Apple was unable to finalize their own version of BASIC (Isaacson 2011). Eight years later, when the Applesoft license needed renewing, Microsoft renewed on the condition that Apple would kill MacBASIC (Manes and Andrews 1994) (Hertzfeld 1985), Apple's up-and-coming BASIC programming language, which everyone expected to be more efficient. (Allen 1984)

Indeed, MacBASIC had better benchmarks and more features than Microsoft's BASIC – yet it scarcely saw the light of day and vanished from the world when Apple dropped it. Programmers went on using and learning the old BASIC, oblivious to the fact that language designers they had never met had made a decision they never knew about, quashing language features they had never learned.

These language wars (whose version of BASIC would ship on whose computers) were largely overshadowed by what was seen as the dominating historical force at the time: the hardware wars (whose machines would sit on the desktops of the world). The fact that improving BASIC might improve the lives of the programmers of the time wasn't enough to drive the evolution of the language.

Famous computer scientist Edsger Dijkstra claimed in 1975 that BASIC caused brain damage (Dijkstra 1982):

It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.

It does seem odd not to improve something that might cause brain damage. But economic pressures are often stronger than educational ones. For better or worse, this was the first program one author remembers typing into Applesoft BASIC, a few years after MacBASIC's secret death:

He was too young to know how to spell "Hello", and too inexperienced of a typist to type out the full traditional "HELLO, WORLD". Nor did he know, at the time, how to turn off the caps lock.

These were his struggles. Far from his mind were the warnings that this very language might cause brain damage. Far from his mind was the story of how Applesoft BASIC had come to be installed on that computer. So it is with most of us. We cannot see languages for what they are until after we have learned them; and we often cannot see the bigger historical picture until long after that.

At some point, brain damage or not, it is too late to unlearn a language. If Dijkstra is right and some languages can cause setbacks in one's ability to become a programmer, the only recourse is to hope he is wrong about being “beyond hope of regeneration.” Our only choice at that point is to learn morelanguages in hopes of correcting damage caused by previous ones. Let it be stated for the record: This treatment appears to have been successful for the author in question.

For better or worse, the evolution of BASIC was once a strategic part of the early skirmishes between what would become two of the biggest software mega-giants on the planet, Microsoft and Apple. Its existence sparked the origin stories of all programmers who completed their rite of passage on those machines. Yet today, the remnants of those original versions of BASIC remain alive only in the form of online JavaScript-based emulators that allow certain programmers to engage in nostalgic reconstructions of the programs we wrote as children. They are preserved: Software enshrined in software. As tools of the mind, though, they are not wielded as they once were.

Today, Microsoft champions many languages. Microsoft's TypeScript, a superset of JavaScript, is listed as the 41st most popular language in the world on the TIOBE index. Microsoft's C#, partially inspired by Java, is the 6th most popular language. Apple meanwhile champions languages like Objective-C and Swift, the 10th and 13th most popular languages. The linguistic ecosystem changes so quickly that these numbers will probably be out of date by the time you read them, which underscores the point. Languages are ever changing; what seem like mountains turn out to be tall waves in a shifting sea.

Whether brain damaging or enlightening, we learn these languages, and they make us who we are. Then we learn more, and continue to change.

For some, our first language may have been BASIC. For others, perhaps it was Logo. For others, Scratch. Regardless of our first language, the younger we are when we learn, the less likely it is that we are making an informed, rational decision about which language to learn.

It is not uncommon for everyone in a classroom (perhaps even the teacher) to be using a language without knowing where it came from and why. In that ahistorical context, students sit down to write their traditional first line, bidding their computer to say hello to a multilingual world they do not yet understand.

Tower of Babel

Our digital Tower of Babel is on the one hand quite beautiful, and on the other hand not. It's beautiful because unlike the biblical story of Babel, the legion of languages was not a curse cast upon humanity; it is an act of creation to which we have been willing participants. These languages didn't just happen. We created them – not by accident.

Programs written in these languages run our world – our planes, our cars, our governments, our militaries, our businesses, our charities, everything. An optimist might see it as the opposite of the Tower of Babel story: We gave ourselves the gift of tongues to write our edifices into existence.

On the other hand, there are less beautiful aspects of the polyglottic world – not the least of which is that newcomers face a bewildering array of choices the instant they enter the gate. Some of those choices are popular languages like Python and Java. Some are languages designed to make programming easier to learn – like Scratch, Hopscotch, and Snap. The Wikipedia page on “Educational Programming Languages” lists more than 50 languages that were either created for educational use or are used as such. Even the language BASIC (created in 1964) stands for Beginner All-purpose Symbolic Instruction Code – marking it as a language tailored for beginners, which is why it shipped in the 70s on “microcomputers,” and then again in the 80s on “personal computers.”

Being a beginner coder is a bit like being a hero embarking upon a quest, but then immediately being faced with a fork in the road that goes in more than 50 different directions (or 850 directions, if we look beyond specialized educational languages). It's like the quest to become a coder begins with a meta-quest: which quest to go on; which language to learn.

Confessions

This section is a disclaimer.

The authors of this book are not innocent when it comes to increasing the number of beginner languages in the world. As the architects of a coding education start-up (ThoughtSTEM), they've created a variety of languages with the purpose of making programming more accessible for beginners: LearnToMod is an environment and language for creating Minecraft mods; CodeSpells is a game where you program your own magic spells using an in-game version of JavaScript; #lang vr-lang is a Lisp-like language for constructing virtual reality scenes; #lang game-engine is for creating 2D RPG-style games. And that's not even all of them.

Once you've designed one new language, it becomes easier to design more.

While we designers mean well in creating these languages, it's a bit awkward to explain: “Hi, welcome to the land of programming. Sorry there are so many roads here at the entrance. But don't worry! We're making this part more user-friendly by paving these additional roads for you.”

Um… Wait…

Alan Kay, the creator of object-oriented programming and the language Smalltalk, is often quoted:

Every problem in computer science can be solved by another layer of indirection – except the problem of too many layers of indirection.

Similarly, problems in coding education can be solved with another language – except the problem of too many languages.

This book uses a different method.

Penances

Rather than paving yet another road, we decided to write a book about the roads – a book to be read before embarking on any of them.

One of the motivations was to show that the “problem of too many languages” is not a problem at all. It's what makes computer science the powerful and elegant field that it is.

Throughout this book, we'll examine a sequence of increasingly interesting languages, starting from basic ones and ending with ones as powerful as those in professional use today – as powerful as the ones that top the charts, as powerful as those mountains of our day.

There will be plenty of coding exercises – but never in any one language. We'll take the way cooler road.

To be continued…

A LANGUAGE WITHIN

Installing Languages

Because of the polyglottic nature of this book, we'll be using a special tool called Racket – a language for creating languages. If you want to run the programs in this book, all you have to do is 1) download Racket, and 2) download our languages. You only need to do these steps once.

If you're ready to do that now, here are the directions. If you're just reading the book cover-to-cover, you don't have to download Racket yet.

Even if you don't download, though, don't skip this section! That goes for any part of the book too: Don't skip. You won't get lost. Above all, we've written this book to be read. Following along on the computer is for bonus points. Whenever the output of a program isn't obvious, we'll print it. This is so you can follow the main ideas whether or not you're following along on a computer.

Exercise

Step 0:

Don't be scared to ask for help

. If you get stuck installing, please feel free to ask for help at

dont-teach.com/coding/forum

Step 1:

Download and Install Racket

. Go to

download.racket-lang.org

. Download the appropriate installer. Launch it and follow directions.

Step 2:

Install the “Don't Teach Coding” Package

. With Racket installed, you can now launch a program called DrRacket. Do so.

Next, click

File > Install Package...

In the prompt, type dtc and press enter. Installing this package will take a few minutes.

Lastly, in the lower left-hand corner, DrRacket may say No Language Selected. Click that, and select Determine language from source. Racket is in polyglottic mode now, which we'll explain in a moment.

Step 3:

Write some

"Hello, World"

programs

. The point of such programs is less about printing

"Hello, World"

than it is about checking to see if everything got set up correctly. So feel free to print whatever you want.

Your DrRacket may look slightly different from the following figure. For example, the version number may be different (in ours it is 7.3). Do not be alarmed; the programs in this book will still work. To write your "Hello, World" program, you simply need to write it your Editor Window (the one that doesn't have the version number). In the following figure, we've labeled the two windows after running the program. Can you guess which window has the program and which has the output?

When you've written your program, you need to run it – which we think you will be able to figure out on your own (Hint: Look for the “Run” button). If something meaningful prints out, everything is set up correctly. If something went wrong, feel free to post on the forums.

dont-teach.com/coding/forum

Writing in Tongues

From now on, when there's a code example, we're not going to insert the entire screenshot as in the figure above. Instead, we'll show code examples like this:

Notice the first line. This will always be there – the so-called “ #lang line.” It tells human readers and the computer the language under which to interpret what follows.

This is how we'll accomplish writing in tongues. Any time you see a #lang line at the top of a snippet of code, you know three things:

That's a piece of code you could type into DrRacket yourself.

The computer will use that language when it interprets what follows.

You

should use that language to interpret what follows.

All code we write will be written for you to read – only incidentally for the machines you type it into. This is not a book about machines. It is about language.

Often, after a snippet of code, we'll show the output. Though it may look like code, it will never have a #lang line.

Here's the output of the code above.

The reason for abandoning screenshots is obvious – they take up a lot of room. If we used screenshots for every example in this book, it would either become twice as long or have half as many examples.

Efficient use of space is key.

Kiss, Gift, Poison

Let's try another language.

Here's its output:

If you run it again, you might get:

This is a language with some trickiness to it. Whereas in #lang dtc/hello/normal, the print word simply printed the thing that came after it, the print word in #lang dtc/hello/colors places the thing that came after it onto a randomly colored shape.

Language designers would say:

The syntax is the same; but the semantics are different.

Most books about coding deal with one language, and have just one “Hello, World” example. But this book is about language itself, so we'll see a few “Hello, World” programs in different languages. The point is to give you an intuition for syntax and semantics. We'll define these more formally in the next chapter. When we do, you'll already have absorbed their meanings via linguistic immersion.

Let's look at one more example that has the same syntax as the previous two – but different semantics again.

Now, when you run the code, something different happens again. The word "HELO" is displayed with an animation every time you run it. We can't print a dynamic picture in a static book, but the basic story is:

And so on.

The key thing to notice about the last three examples is that we didn't change the code, only the language. The first time we said "HELO" to the world, we used #lang dtc/hello/normal. The second time, we used the language, #lang dtc/hello/colors. The third time, we used #lang dtc/hello/animation. What's interesting though, is that if you look at just the code (ignoring the language), you wouldn't be able to tell what language each is written in.

Here are all three programs together:

They do different things because the word print means something different depending on the language.

This concept arises in human languages, not just programming languages. The English word “gift,” in German, means “poison.” The English word “kiss,” in Swedish, means “pee.” And flashing the peace sign on one's forehead, in American Sign Language, means “stupid.”

The same words or signs, under different interpretations, are not the same words or signs.

Nova: Va o no va?

A famous (but surprisingly false) example of misinterpretation is the cautionary tale about the Chevy Nova. As the story is told in hundreds of marketing books and business seminars (Aisner 2000), (Colapinto 2011), this car sold poorly in Spanish-speaking countries because the word “Nova” is similar to the Spanish phrase “no va,” which translates to “doesn't go.” Supposedly, Spanish speakers were concerned that if they bought a Nova, it wouldn't go.

But language isn't always so simple. The Chevy Nova actually sold well in Spanish-speaking countries, meeting or exceeding expected sales numbers in both of Chevrolet's primary Spanish-speaking markets: Mexico and Venezuela (Hammond 1993).