This document provides guidance for high school and college students on learning to code. It discusses the benefits of coding skills, different types of coding careers, and what coding and software development entail. It then covers considerations for choosing a first programming language, including options for learning functional programming first or starting with Python. The document predicts that Rust will be in high demand in the coming years for developing embedded systems and web applications due to its safety and growing adoption. It recommends students learn foundational concepts in a beginner-friendly language before potentially specializing in Rust.

1. Learning to Code in 2020
Considerations for high school and college students
(Rust stuff begins on slide 15)

2. Intro
● why learn to code
● what coding, and software development, mean
● thoughts for high school and college students
about how to learn to code, and language choice

3. Why learn to code
Even if you don't choose a career in software development:
● ability to do things you couldn't otherwise
○ Mathematicians increasingly write software to prove theorems.
○ Simulations play an important role in science.
○ Sophisticated data analyses increasingly guide businesses.
● better collaboration with software teams
● better understanding of some research
● better insight into software you use
● improved ability to think logically / systematically

4. Software development as a career
● LOTS of high-paying jobs
● projected to continue well into the future
● entrepreneurial opportunities
● possibility of remote work
● creative work that can feel like art
● constant learning
● ability to have a big impact on society

5. What it means to code
a rendering of that in
some programming
language
some problem
out in the real
world
an algorithm
that solves it

6. What it means to code, continued
computer(s)
running
the program
the real
world
data output
sensors actuators (often just humans)

7. Learning to code is just the start
Computer Science:
● algorithms and data structures (fascinating!)
● paradigms (imperative / OOP / functional / logic programming)
● operating systems
● networking
● programming language design/implementation
● machine learning
● artificial intelligence
● computer architecture
● more

8. Learning to code is just the start, continued
Software Engineering:
● how to make software easy to use
● how to write software that is understandable to other coders
● how to structure software so that it is testable, adaptable, maintainable
● how to communicate software structure/operation in diagrams
● how to architect a system of interacting software components
● how to ensure that software works (quality assurance)
● how to automate the mechanics of software development (dev ops)
● more

9. Kinds of software
web sites
phone apps
("front end")
Infrastructure (operating systems, libraries, networking, cloud service providers, ...)
"back end"
software
browser
apps
desktop
apps
embedded
software
(in devices)
command-line
utilities
business data
processing
more ...
users

10. Programming languages
● There are many hundreds (!), but most are of little interest.
● Certain kinds of software have special language needs;
e.g. for embedded software you need the code to
○ run fast
○ use little battery power
○ take little memory
○ reliably respond without latency (no JIT, no GC)
○ sense and manipulate the real world
● Some popular languages are really not very good.
● Some languages have more cachet, e.g. Haskell. This matters to
○ recruiting companies
○ university admissions
● Some languages are easier to use than others.

11. Evidence
You could probably learn to code from a book + YouTube videos,
but it would be better on that university application to have evidence.
● A MOOC from Coursera or EdX with a certificate ($) would carry some weight.
● You could have a GitHub repo or two with some of your work, but
○ Did you really do the work, or is that someone else's code?
○ Is what you did any good?
○ Universities probably can't evaluate your work, but it still might count for a little.
○ Better if you blog about what is in the repo and have a good README.
● An interviewing company probably will have an engineer look at your repo
○ How substantial is the work?
○ Does the code look well written?
○ Questions about it in the interview, so don't fake it!
○ Don't put your early code out there if you code much better now.
● StackOverflow answers, blog, ....
● Vetted contributions to open source projects are probably the best evidence!

12. Option 1: "I mostly just want the credential and a handy tool"
Learn Python. Here is a Coursera MOOC (edX) that will earn you a certificate.
● It's immediately useful; many environments are written around it.
● It has a huge ecosystem (users, employers, libraries, tutorials, tools, etc.).
● It's easy to learn, at least the basics.
But
● It's relatively slow.
● It's ok, but not really a good language (though Pythonistas will complain!).
● It's not a language for writing complex software in a maintainable way.
Consider this route if you don't really care about software as a discipline, if learning
to code is more of a checklist item you want to tick off. Python can be a very useful
tool, but I wouldn't choose it to write really important software.

13. Option 2: "I want to learn to write good software"
Learn a good functional programming language first. My first choice would be
Clojure or Scheme, but (surprisingly) those MOOCs assume prior coding experience.
But here is a beginner MOOC in ML, a functional language, offered by a good school
(U of Washington), and there is a follow-on MOOC in Scheme if you're interested.
● ML and Scheme are simple and well-suited to teaching programming.
● Learning a FP language is a better start on writing good software.
● FP languages have cachet on that college application.
BUT -- you're probably not going to get a job in these languages (and that's OK!).
Consider this route if you do care about software as a discipline, and to show
people that you have taken a good first step on that path. It's the better start
unless you need to try to land a software job after a couple of courses.

14. Why learn to code using a functional language?
● Four types of languages, "programming paradigms":
○ Imperative, e.g. C, Fortran
○ Object-oriented (OOP), e.g. Smalltalk, Ruby (Java is not "pure" OOP)
○ Logical, e.g. Prolog
○ Functional, e.g. Haskell
● Imperative and OOP paradigms are dominant, but functional is on the rise.
● Functional programming is a bit like math, and has nice properties:
○ easier to reason about code
○ better for composing abstractions
○ easier to test
○ easier to parallelize for multi-core CPUs, allowing us to continue to improve performance now that
we can no longer increase clock rate much on silicon!
● Jobs using FP languages tend to pay well.
● Even non-FP languages are getting some FP features these days.
● Even with non-FP languages, coding in FP style is often useful.

15. OK, I learned ML or Scheme or something. Now what?
If Math is your thing, consider Haskell, or even Idris or Agda 2 if you don't need a MOOC.
The Haskell Road to Logic, Maths and Programming
Haskell MOOC with certification
If a job creating great software -- particularly infrastructure software -- appeals to you,
consider Rust.
Or hey, both. :)

16. Uh, why Rust? I see things like this on the web.
from stackoverflow.com

17. And this. Shouldn't I pick a widely used language (lots of jobs)?
from freecodecamp.org

18. But wait a minute ...
If # of available jobs
were really the key concern
in career direction,
then learn to wait tables
would be great career advice.
LOTS of jobs!

19. You already know what really matters...
SUPPLY
vs.
DEMAND
(btw, please take some Econ courses!)

20. utility(num_jobs) is a sigmoid function
# of jobs in that language
enough
value
to you
not enough
After a point, more jobs don't
help much.
You really only need
one good job
in your area
if there is nobody else to fill it.
Demand only needs to be high
relative to supply!
0 jobs a few many

21. What you want from the job market
In a software job, you probably want
● a good salary, a good work environment, etc.
● greenfield work (building new things rather than maintaining old things)
● meaningful work
... at the time you enter the job market!
Programming languages come and go;
what's true now may not be true in 5+ years.

22. Think supply vs. demand
We have to predict the future.
What will be important in 5+ years?
We want to know for which languages, at that time, demand (employers
wanting developers) will be high relative to supply (available developers).
That will determine salaries!
Ideally we would also like the demand to be for greenfield work.

23. On predicting the future
"Prediction is very difficult, especially if it's about the future."
-- Neils Bohr
But that doesn't mean you shouldn't try.
And we are in special circumstances at the moment; they give us clues.

24. Some key things happening now
● A huge wave of devices (IoT = Internet of Things, robots, etc.) will need code;
even more true in the future because of developments like these:
○ RISC-V: open-source instruction set architecture will make smart devices
■ cheaper
■ use less memory
■ use less power
■ generate less heat
○ Improvements in battery technology will make new device applications feasible.
○ Developments in robotics (walking, swimming, climbing, soft) = new application areas.
○ Longer-flying, more agile drones = new applications.
○ Developments in AI, and TPUs, will permit greater "intelligence" in devices.
● Web Assembly: browsers can finally run code other than Javascript
○ Javascript, a mediocre language, is huge primarily because it was the only language that
browsers directly supported. That is (finally!) no longer true.
○ Will be used to improve performance and maintainability of complex software.
○ Allow programs to run in the user's browser rather than on servers.

25. Language needs for embedded systems
● CPU efficiency (speed, long battery life, low heat)
● memory efficiency
● low latency (no pauses for "garbage collection" or on-the-fly compilation)
● no associated runtime (code that manages the language environment)
● precise control over the use of memory
There are only really three acceptable choices in this space!
C, C++, and Rust.
But C and C++ are inherently unsafe, requiring very careful coding and making later
maintenance tricky (especially when working with someone else's code).

26. Rust
● Rust 2018 Edition was released in December 2018
○ provided needed usability improvements
○ simplified use in embedded systems
● Novel features eliminate entire classes of nasty bugs that plague C/C++ code
○ memory deallocation problems: use after free, free twice, fail to free (memory leak)
○ "null pointer" problems, stale pointers
○ data races (nasty concurrency problems) and more!
○ buffer overruns (often the cause of security problems)
● Much more modern language, enabling higher-quality code, e.g.
○ very good type system
○ powerful+safe macro system
● Yet still as fast and suitable for embedded applications as C/C++
○ and better at concurrency -- easier and safer to make use of multiple cores
● Already a popular choice for Web Assembly applications
○ fast
○ no runtime to be downloaded

27. what C and C++ let you do
what most languages
let you do
what is safe
Program safety (roughly)
what Rust lets
you do
i.e. what Rust
considers safe
Bad bugs in embedded devices
risk substantial financial liability.
Consider medical devices, robots,
cars, ....
Rust code can still have bugs,
but major classes of really
hard-to-find bugs are simply
not possible in ordinary Rust code.

28. A Terrible Property of Memory Safety Errors
"Normal" bugs in software are generally easy to reproduce, their causes easy to find.
NOT SO with memory safety errors, like memory corruption -- they can be hard to find!
Memory corruption can cause your program to die anywhere, far from the cause.
WORSE: Larger code bases, larger datasets, more concurrent code -- all make it that
much harder to find the cause of such elusive problems.
If your simple 500-line C program corrupts memory, finding the cause can be a pain.
But it would generally be far harder to find the same problem in a highly concurrent,
50,000-line C program that consumes lots of data.
The software we are writing today is much more complex and concurrent
than the software we wrote in the '70s, '80s, and '90s.

29. "But there are many more C/C++ libraries!"
0 libraries thousands millions
enough
value to you
not enough
After a point, more libraries don't
help much (don't much change
the probability that you'll find
most of what you need).
Yes, there are many more C/C++
libraries than Rust "crates."
But there are already over 25,000
Rust crates. There are crates for
most things you might need, and
that number is growing.
You can always write the glue to
call out to a C library if needed
(and some C++ libs, depending on
the features they use).
# of libraries for that language

30. A unique situation
Consider the uniqueness of the current situation:
● We are starting to build a growing avalanche of smart devices.
● These devices will live in the real world, alongside people.
● Significant failures in many of these devices will be very bad news,
perhaps even ending product lines and startups.
● Only three languages are suitable for much of the code on those devices.
○ Two of those languages (C and C++) are the most unsafe languages in common use!
○ The third (Rust) is the safest language in common use!
● That third language also has many other improvements over the other two.
● Few people know the third language.
This is a very interesting, almost weird, confluence of circumstances.
It is extremely relevant to anyone planning to enter the job market in a few years.

31. A prediction (waves hands mysteriously)
Rust was already on the rise.
But Rust 2018 Edition, with key improvements addressing prior usability problems,
and competing only against wildly unsafe C and C++ in huge software segments
requiring lots of new code, will have accelerating uptake over the next few years.
In a few years, Rust will be a top choice for a significant portion of greenfield
development in embedded and Web Assembly apps, of which there will be a lot.
Companies will want Rust's advantages in safety and code quality.
so there will be a substantial increase in demand
But there are relatively few Rust coders, and Rust is relatively hard to learn.
And many still think that # of jobs, rather than supply/demand, is what matters.
so there will be relatively low supply

32. NOT predicting Rustworld
NOT predicting that Rust is going to take over the world.
It is not going to replace C/C++.
Lots of old C/C++ code exists and will need maintainers.
Will even continue to be used for much new development.
NOT predicting that Rust is going to displace Javascript in the browser.
NOT predicting that Rust is going to displace Java in server applications.
etc.
But if even 5% of new development, in application areas for which C / C++ / Rust
are the only reasonable language options, is done in Rust, that's a lot of Rust!
Rust uptake is likely to be throttled by the supply of coders.
So check on Rust's trajectory -- after learning to code using some other language.

33. Why not just start with Rust?
Rust is harder to learn, probably making it a poor choice for a first language.
And it is not a functional programming language (although it has some FP features).
Ideally, divide the journey into two parts:
1. Without any consideration at all for the job market, learn the concepts using a
really good functional language that has a minimum of syntax and "warts."
Ideally (IMHO) this would be a homoiconic language with no static type system
(to make it simple yet expressive) that strongly deemphasizes mutation
(to keep you from falling back to less good solutions). Clojure would be
a great choice, but unfortunately I couldn't find a good MOOC for it with
a certification option. The best beginner FP MOOC I could find uses ML.
2. Then, knowing the basics, learn a practical language with a good type system
that will get you the kind of job you want. No need to choose this language now,
but I suspect Rust will be a strong option.

34. A plea to high schools and colleges
If you (like my local high school) teach kids to program using C/C++, please stop!
You are unnecessarily frustrating students, and some will never come back.
Choose a first language that is easy and clean and encourages good habits.
Consider using a functional programming language, or at the very least a
functional subset of a language that supports FP well, and not allowing mutation.
Your goal should simply be to make it straightforward to learn the concepts.
Don't worry about whether there is a market for that first language;
that is a concern for their second (or maybe third or fourth) language.
BTW, here is a letter from Edsger Dijkstra, a great name in computer science,
making a similar plea (in his case for teaching introductory programming using
Haskell rather than Java at UT). Definitely worth a read!

35. Questions?
Any questions?