roc-lang / book-of-examples

Software Design by Example in Roc

book website (WIP)

Software Design by Example in Roc

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.

Contributing

1. Fork this repository on GitHub so that you have a copy under your own account.

2. Clone your repository to your machine.

3. Make your changes in a branch in the repository on your machine (or in main if you prefer).

4. Push that branch to your forked repository on GitHub.

5. 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 [e-mail]:roc-lang/book-of-examples

so that you can git pull upstream main periodically to stay up to date with changes.

Topics

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

Learner Persona

1. 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.

2. 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.

3. 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.

4. 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.

FAQ

• 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.

Structure

We are currently building this site using Jekyll (the default static site generator for GitHub Pages); we will convert to something Roc-based soon.

• Project
  • ./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
• Jekyll
  • ./_config.yml: configuration
  • ./_data/: data files (see below)
  • ./_includes/: inclusions
  • ./_layouts/default.html: our page template
• Data files
  • _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)