Learning to code in 2020
- 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!