The best way to learn design in any field is to study examples. These lessons therefore build scale models of tools that programmers use every day to show how experienced software designers think. Along the way, they introduce some fundamental concepts about pure functional languages that most programmers have never encountered. SDXRoc is a sequel to previous books in JavaScript and Python.
Fork this repository on GitHub so that you have a copy under your own account.
Clone your repository to your machine.
Make your changes in a branch in the repository on your machine
(or in main if you prefer).
Push that branch to your forked repository on GitHub.
Create a pull request from that branch of your repository on GitHub to the main repository.
We suggest that you add this repository as a remote to your desktop:
$ git remote add upstream git@github.com:roc-lang/book-of-examplesso that you can git pull upstream main periodically to stay up to date with changes.
| Name | GitHub ID | Topic | Slug |
|---|---|---|---|
| Shritesh Bhattarai | shritesh | SVG rendering | svg |
| Luke Boswell | lukewilliamboswell | text editor | editor |
| Sophie Collard | sophiecollard | property-based testing | proptest |
| Ashley Davis | ashleydavis | thumbnail gallery | gallery |
| Eli Dowling | faldor20 | autocompletion | completion |
| unclaimed | unclaimed | file backup | backup |
| Hristo Georgiev | hristog | file diffing | diff |
| Norbert Hajagos | HajagosNorbert | file transfer | ftp |
| Norbert Hajagos | HajagosNorbert | discrete event simulation | des |
| Stuart Hinson | stuarth | pattern matching | match |
| Stuart Hinson | stuarth | redis data store | redis |
| Nathaniel Knight | nathanielknight | random number generation | prng |
| Monica McGuigan | monmcguigan | JSON codec | json |
| Noel Rivas | noelrivasc | logging framework | logging |
| Abhinav Sarkar | abhin4v | pretty printing | pretty |
| Fabian Schmalzried | FabHof | binary data packing | binary |
| Isaac Van Doren | isaacvando | compression | compress |
| Isaac Van Doren | isaacvando | HTML templates | template |
| Jasper Woudenberg | jwoudenberg | continuous integration | ci |
| Agustin Zubiaga | agu-z | HTML parser | parser |
Ning (26) has a college degree in software engineering and has been working as a programmer for four years. They are comfortable using JavaScript, Python, the Unix shell, Git, and Docker to build web applications in a team with half a dozen others.
Ning is helping to convert a 20K line legacy front end from JavaScript to TypeScript. That experience sparked an interest in strongly-typed languages, which led them to experiment with Elm on some personal projects and to go through the Roc tutorial.
Ning would like to learn more about functional programming, and about the differences between working in interpreted and compiled languages. They are also interested in getting involved with an active open source community where they might still be able to make a noticeable contribution.
Ning has never done a course on compilers or programming language semantics, so they are worried that they don't know enough to start and will look foolish if they ask questions. In addition, their workload means they cannot commit to a regular learning schedule, so lessons must be usable in bursts of two or three hours at a time.
Why Roc rather than a more established language like Haskell, Clojure, or Elixir? One of the lessons from the previous books is that a large language can make design harder to see: core ideas might actually have been clearer if those books had used a smaller language like Lua. This book is also partly an experiment: can a project like this early in a language's development accelerate its evolution by drawing attention to oversights and sources of friction while the language is still malleable?
What license are we using? The code is covered by the MIT License, so it can be copied, remixed, extended, and incorporated into other projects (both open and closed source). The prose (i.e., the text of the lessons) is covered by the CC-BY-NC-ND License, which means it is free to read but people must cite us as the source if they quote or copy it, cannot republish it commercially without our permission, and cannot create derivative works (e.g., translations) without our permission. We may remove some of these restrictions once we have a contract with a publisher, but they are in place now because it's much easier to relax a license after the fact than to tighten one up.
How do I propose a topic? Create an issue with "topic proposal:" in its title and a brief description of what you'd like to cover. Greg will triage issues, start discussions, and identify overlaps.
How do I know what topics are taken? Look at the "Topics" section of this file or for issues marked assigned in our repository.
What if I don't have an idea but still want to contribute?
Issues labeled help wanted in our repo
are topic proposals in search of authors.
If you are interested in taking one of these on,
please add a comment to the issue and mention @gvwilson to start discussion.
Where should code and notes go?
For now,
each topic should go in a subdirectory of the root directory
whose name is a short hyphenated slug,
e.g., editor or http-server.
Each topic should be a standalone project;
please include an index.md Markdown file
with point-form notes about the design of the code.
We are currently building this site using Jekyll (the default static site generator for GitHub Pages); we will convert to something Roc-based soon.
./CODE_OF_CONDUCT.md: code of conduct./GOVERNANCE.md: how this project is run`./LICENSE.md: license./README.md: this file./index.md: home page./*_.md (trailing underscore): create website pages for project files*/index.md: chapters and appendices./*.css and ./favicon.svg: for generated website./_config.yml: configuration./_data/: data files (see below)./_includes/: inclusions./_layouts/default.html: our page template_data/contrib.yml: contributors (use GitHub ID as primary key)_data/order.yml: chapters and appendices in order (use slug as primary key)_data/topic.yml: chapter and appendix information (use slug as primary key)