Things to read or do next
Votes from the meeting are marked with one or more •.
- • Functional data structures
- Soft typing
- ••• 10 papers every programmer should read at least twice
- Papers could be fun, but it might be annoying to have to vote again every 2 sessions on what to do next. A list like this means we don't have to. If this list doesn't seem good we could find another list, or come up with one ourselves based on all the other papers listed.
- Simply Easy! - An Implementation of a Dependently Typed Lambda Calculus
- Propositions as types
- Paxos
- RAFT
- Polymorphism in ML
- Kanren and μKanren
- In Quest of a Pangram
- • Functional programming pearls
- •••••••• The New Turing Omnibus
- ••• 10 Print Chr (205.5+Rnd(1)); : Goto 10
- Less computationally intense than other suggestions as it's more about culture than computation. Might lend itself to a much more traditional book-club format.
- Hacker's Delight
- •• How to Design Programs
- •• Physically based rendering
- Goes through concepts and theory behind photo-realistic rendering from the principles of how light fundamentally works.
- Presented in a literate style which focuses on human comprehension, the entire book is source code for a sophisticated renderer.
- Won the 2014 Academy Award for Scientific and Technical Achievement (due to industry adoption)
- Think Complexity
- The Art of Unix Programming
- The Haskell School of Music
- •• Types and Programming Languages
- Beej's guide to network programming
- Little Prover
- Reasoned Schemer
-
Architecture of open source applications
- "In these two books, the authors of four dozen open source applications explain how their software is structured, and why. What are each program's major components? How do they interact? And what did their builders learn during their development? In answering these questions, the contributors to these books provide unique insights into how they think."
- 24 chapters including e.g. Asterisk, bash, LLVM, sendmail, nginx, git.
- Whole book available for free online in HTML under a Creative Commons license
- Introduction to Algorithms
- Mazes for Programmers [not mentioned at meeting]
- Eudyptula - linux kernel challenges
- Cryptopals: the matasano crypto challenges
- •• Write software to make something move
- Make something out of physical NAND gates
- I was imagining building one of the main components from the first half of Nand2Tetris
- The Arithmetic Logic Unit seems like a good candidate.
- According to this article you could make one out of ~460 NAND gates
- I was imagining building it out of 7400 Quad 2-Input NAND gates in a DIP14 package on Stripboard
- However, it might also be fun to layout and manufacture the circuit on a PCB
- If we went for a PCB we could also contemplate smaller packages e.g. surface-mounted SOIC
- We could have push buttons and LEDs on the board and/or run test scripts (generating inputs and detecting outputs) using [GPIO] (https://en.wikipedia.org/wiki/General-purpose_input/output) pins on a Raspberry Pi or an Arduino
- ••• Declarative programming
- through self-enumerating programs (In Quest of a Pangram)
- actually build something
- I'd really like to understand more about declarative programming. It's radically different from anything I've done before and I genuinely think our discipline is going to head in this direction in years to come. The "paper" by Lee Sallows might be an interesting way to get into this. He talks about a word puzzle he worked on and how he built a machine to solve it. I've been working on this problem myself and have come to the conclusion that the best way to do this is through declarative programming technique. So far, all of the examples I've looked at in Prolog have been contrived and aren't the sort of thing I'd connect with. I'd rather take a problem of our own and see if we can solve it through declarative programming. Tom spoke about declarative programming at LRUG and now might be the time to answer his call to action. I think that one of the reasons declarative languages aren't popular is because they're not intuitive to use. This could be because the existing abstractions aren't very good. Can we do better?
- •••• Implement a protocol from its spec, e.g.
- FPGA's