d_christiansen (u/d_christiansen)

d_christiansen commented on Functional Programming in Lean leanprover.github.io/func... · Posted by u/d_christiansen

ggm · 2 years ago

Minor thing. Purely as a side:

in C and C++, the conditional statement is written using if and else, while the conditional expression is written with a ternary operator ? and :.

ending a sentence with . is a must. Including a period directly after a syntactic construct about ? and : is .. jarring because it is possible to attempt to read this as :. as an atomic construct in the language. Or even worse, the three-dots pyramid in some mathematical proof notations.

d_christiansen · 2 years ago

I agree - this is inelegant. I'll make an issue in the repo to rephrase this sentence for the next time I do a round of typo fixes.

Thanks for the feedback!

d_christiansen commented on Functional Programming in Lean leanprover.github.io/func... · Posted by u/d_christiansen

xigoi · 2 years ago

In the book, the ":" is typeset in monospace and the "." in proportional font, making their meaning clear.

d_christiansen · 2 years ago

I'm the author - I think that it's good to signal this kind of thing redundantly, and not rely on the details of typesetting to avoid confusion. I'll create an issue in the repo to rephrase the sentence.

d_christiansen commented on Functional Programming in Lean leanprover.github.io/func... · Posted by u/d_christiansen

foderking · 2 years ago

this is actually a good read

d_christiansen · 2 years ago

Thank you! I hope you enjoy the rest of it.

d_christiansen commented on Functional Programming in Lean leanprover.github.io/func... · Posted by u/d_christiansen

theresistor · 2 years ago

I'm interested to know why I would want to learn Lean if I'm already familiar with Idris.

d_christiansen · 2 years ago

Lean occupies a different point in the design space. Its type theory is simpler and more conservative, its metaprogramming system is more reminiscent of Racket's (including hygienic procedural macros), and the focus on supporting professional mathematicians gives a different feel to the community and libraries. I think both are worth knowing, but either is great to learn. I hope the two projects learn more from each other in the future.

d_christiansen commented on Functional Programming in Lean leanprover.github.io/func... · Posted by u/d_christiansen

Reitet00 · 2 years ago

This looks very nice! Is epub version planned?

d_christiansen · 2 years ago

Unfortunately not. I wanted to produce PDF and epub versions in parallel with the HTML version, but getting those to be of sufficient quality would have blown the time budget for the project. There's some old code in the Git history for dumping the source to Pandoc's dialect of Markdown, from which I was going to generate those, but the differences in Markdown dialects are enough that it was a fair bit of work.

Dropping a print version and focusing on epub could very well be faster, as I suspect that an mdbook->epub pipeline is less challenging than creating a quality print-ready PDF. But no plans right now.

d_christiansen commented on Functional Programming in Lean leanprover.github.io/func... · Posted by u/d_christiansen

ykonstant · 2 years ago

Thank you very much for this book. It has been invaluable for my introduction to Lean and a joy to study from. I still have not read the last chapter, looking forward to it! Kudos for your effort, and I hope you will write some more stuff about Lean in the future.

d_christiansen · 2 years ago

Thank you for reading it, and I hope that the final chapter is also enjoyable for you. Right now, I plan to take a break - this book occupied every Saturday for about a year, and some time off is in order. But Lean is tons of fun, and I'd like to get back into it once I'm recovered a bit.

d_christiansen commented on Functional Programming in Lean leanprover.github.io/func... · Posted by u/d_christiansen

mdm12 · 2 years ago

Congratulations on the publication! As a dabbler in strictly typed functional programming languages like Scala and F#, I have always been curious about proof-oriented languages such as Coq or Agda, but found it difficult to justify the time investment. Lean seems to position itself as a theorem proving language that also supports general-purpose programs. Looking forward to digging into your book!

d_christiansen · 2 years ago

Thanks! I hope you find it valuable!

Those other languages are also definitely worth learning. Happily, there's lots of cross-transfer of ideas and skills between them, so learning one will make the others easier. I got my start in dependent types with Software Foundations and Coq, and that was very helpful when learning Agda and Idris later. Similarly, skills from them transferred quite readily to Lean.

d_christiansen commented on Functional Programming in Lean leanprover.github.io/func... · Posted by u/d_christiansen

d_christiansen · 2 years ago

Lean 4 is an interactive theorem prover. It's also a programming language with a self-hosting compiler. This is a free book on using Lean 4 as a programming language, written without assuming any background in functional programming. It's intended to be accessible to Python, C#, Rust, Kotlin, Java, TypeScript, and Scala developers. Today marks the final release, after more than a year of writing.

d_christiansen commented on New Hampshire set to pilot voting machines that use software everyone can see therecord.media/new-hamps... · Posted by u/isaacfrond

alexvoda · 3 years ago

While I agree with you that the ballot should be physical, electronic counting defeats the purpose of transparency. Counting should also be manual in the presence of representatives of each candidate. Marking of ballots and voter eligibility checking do not present any issues if done electronically.

Maybe one way to address the issues of electronic counting would be to have parallel counts by each candidate (and their reps) using their own hardware and software with a manual count in case the electronic counts of every candidate do not match. But this means each candidate has to bring their own counting infrastructure which is prohibitive.

d_christiansen · 3 years ago

Another nice method to reduce risk from electronic counting is called the "Benaloh Challenge" (after Josh Benaloh, the inventor). The idea is that there are two steps to putting the paper ballot into the machine: first, the machine precommits to an encryption of its count (e.g. by printing some paper with evidence on it), and then the voter decides whether to spoil the ballot or actually cast it. If the voter spoils the ballot, then they get a new paper ballot to vote on, but they can retain the commitment. Voters may spoil any number of ballots. Decryptions of spoiled ballots along with enough information to check the machine's work are provided to the voter, either immediately or at the end of the day. This means that a cheating machine cannot cheat very much, though the whole thing also really relies on a verifiable privacy-preserving audit trail for the actual count (e.g. with homomorphic encryption). It at least means that nobody need trust the actual computers.