├── learning-agda.md └── readme.md /learning-agda.md: -------------------------------------------------------------------------------- 1 | ## Learning Agda 2 | 3 | Some resources: 4 | 5 | * [*Programming and Proving in Agda*](https://www.youtube.com/watch?v=AVRsH_YH7XU): ZuriHac 2024 talk by Jesper Cockx. 6 | * [*Programming and Proving in Agda*](https://github.com/jespercockx/agda-lecture-notes/blob/master/agda.pdf): lecture notes by Jesper Cockx. 7 | * "Propositions as Types" by Philip Wadler. 8 | This [talk](https://www.youtube.com/watch?v=IOiZatlZtGU) and [paper](https://homepages.inf.ed.ac.uk/wadler/papers/propositions-as-types/propositions-as-types.pdf) present the deep connection (equivalence/isomorphism) between logic and dependently typed programming, often called "the [Curry–Howard correspondence](https://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspondence)", as discovered and developed during the 20th century. 9 | I consider the fundamental equivalence of computation and constructive logic to be the most powerful and beautiful insight in computer science. 10 | Agda is the prettiest and smoothest language I know of that embodies this insight. 11 | * Part one (Logical Foundations) of [Programming Language Foundations in Agda](https://plfa.github.io/). 12 | Parts two and three are about operational semantics of programming languages, leading to complex theorems and proofs rather than simply correct computation. 13 | * [The Agda Wiki](https://wiki.portal.chalmers.se/agda/pmwiki.php) has many papers and tutorials. 14 | * The Agda Zulip community is very helpful! 15 | See the [Agda community page](https://wiki.portal.chalmers.se/agda/Main/Community). 16 | 17 | You'll probably find that correct programming is more difficult than standard programming, but it's usually harder to do *anything* correctly than incorrectly. 18 | 19 | Some advice: remember to have fun! 20 | Enjoy the learning experience in itself rather than trying to get it out of the way to get to something else. 21 | If it doesn't feel like play, try to shift something about how you are relating to the journey. 22 | -------------------------------------------------------------------------------- /readme.md: -------------------------------------------------------------------------------- 1 | *Would you like to play/learn/work with me?* 2 | 3 | I am seeking research collaborators and mentees in the general area of correct and efficient engineering with *simple* and precise specifications. 4 | To keep us honest, we'd formalize our questions and answers in one or more proof assistants (my favorite being Agda), eliminating guesswork, subjectivity, and false assumptions. 5 | (As Richard Feynman put it, "The first principle is that you must not fool yourself, and you are the easiest person to fool." 6 | Bertrand Russell made the point even more specifically: "Everything is vague to a degree you do not realize till you have tried to make it precise.") 7 | 8 | With this commitment to (and support for) truth in place, we would then look for the simplest (and thus most valuable) possible specifications for problems of interest. 9 | (Simplicity of specifications is important not only for ease of use but also crucial to reliability, since the specification/question is the one aspect of the work that cannot be formally verified.) 10 | With such a specification, we would look for efficient implementations and tractable (and thus affordable) proofs (demonstrations of correctness). 11 | 12 | I personally believe these values are necessary for doing work of lasting scientific value (as opposed to merely short-term commercial value) and for moving our technological society off its rickety foundations onto solid ground. 13 | 14 | I discussed my values and why they matter to me in three interviews: 15 | 16 | * [The Lost Elegance of Computation](https://www.typetheoryforall.com/episodes/the-lost-elegance-of-computation) (3:32) 17 | * [Denotational Design](https://www.typetheoryforall.com/episodes/denotational-design) (3:07) 18 | * [Haskell Interlude](https://haskell.foundation/podcast/62/) (0:58) 19 | 20 | See also my ZuriHac 2023 talk, [A Galilean revolution for computing: 21 | Unboundedly scalable reliability and efficiency](https://github.com/conal/talk-2023-galilean-revolution) (1:27). 22 | 23 | It took some experience mentoring people to realize the importance of asking them to work with a proof assistant. 24 | Before that (working in Haskell), I found myself repeatedly reminding mentees of the success/correctness criteria, and I didn't enjoy the role. 25 | Eventually it dawned on me that dependent types could capture these criteria precisely and remind the mentees whenever they strayed. 26 | A modern dependently typed language seems the best foundation for proof assistants, thanks to embodying the profound Curry-Howard-Lambek correspondence. 27 | Agda is my favorite dependently typed language / proof assistant, so it's where I now do all of my work, including generation of efficient parallel computational hardware with formal correctness proofs (and simple specifications). 28 | To help you get started, I've collected some suggestions about [Learning Agda](learning-agda.md). 29 | I'm also open to using other proof assistants *in combination with* Agda for the sake of comparison. 30 | 31 | For mentoring, a typical getting started path looks something like the following: 32 | 33 | * Install Agda. 34 | * Read some of the Agda resources I recommended, and work through the exercises you find. 35 | You may ask me questions along the way. 36 | * Send me a progress update every two weeks (preferably in Markdown format without section headings), even if it's short, so I know that you're still in the game. 37 | Between progress updates, you're welcome to write to me as often as you like with questions etc. 38 | It helps my journal-centered workflow if we both write in [Markdown](https://en.wikipedia.org/wiki/Markdown) format with pretty links, without section headings, and with blank lines before lists and enumerations. 39 | Also, "agda" in the fenced code header, and single back-ticks around in-line code. 40 | * Assemble a list of topics that interest you, and start investigating, emphasizing simple and precise specifications. 41 | (A topic can even start with some code you've read or written.) 42 | I'll ask clarifying questions and make a few suggestions (hopefully not too intrusively), and we'll iterate from there. 43 | * If anything in the process isn't working for you, please say so, and we'll adapt to suit us both. 44 | If you want to quit, that's fine, but I prefer hearing so explicitly. 45 | 46 | You can find my email address near the bottom of my [home page](http://conal.net). 47 | --------------------------------------------------------------------------------