Agda VS lean

Learn how to use a formal proof assistant. Coq and Agda are the most popular. Both allow you to write a proof as a program instead of as a paper, and provide various tools for formally checking your proof.

Some programming languages are, https://github.com/agda/agda

If you're looking for stuff pushing the boundaries of PL research, Agda (especially Cubical Agda) might be cool to look at. It's got lots of cutting edge stuff in it, pushing the boundaries of what is currently possible with dependent type theory. It's not the only language out there with cubical features (see also: cooltt), but it's probably one of the more fleshed-out implementations in terms of being practically useful. The 1Lab makes heavy use of it. There's also Introduction to Univalent Foundations of Mathematics with Agda that might be interesting to look at too!

My best guess is that it has not really been maintained lately, there were only 12 commits in the last 7 years, some of which are just global modifications, which include this file as well: https://github.com/agda/agda/commits/136f85386ec43245745b76f03505bda4f5d1ed3f/src/full/Agda/Interaction/Highlighting/Vim.hs

Also I would suggest is that you import a paradox (e.g., https://github.com/agda/agda/blob/master/test/Succeed/Hurkens.agda) and see what it actually does when you construct values with it that you evaluate or proofs that you use.

Andrea had some code relaxing these restrictions at the last AIM (cf. "trying to make termination checker accept more definitions --without-K, fixing #4527" in the wrap-up section) but I don't know if it has been merged into master yet.

Significant nit: this isn't true. The whole domain of "high-assurance software" is about this, with examples such as CompCert and seL4. There are tools like Frama-C that support you in proving things about your C; [proof assistants]() that let you extract Haskell, OCaml, or Scheme from proofs so the code is correct by construction; and languages like CakeML, F*, Agda, Idris, ATS... that are both programming languages and proof assistants.

I have spent a good deal of time trying to formalize elementary mathematics and computer science textbooks in the Lean Theorem Prover, and in trying to extend and improve Lean to make the process easier. I have been able to translate entire chapters of several textbooks into Lean in a natural way, with every line of Lean seemingly isomorphic to the informal presentation. However, once in a while I will hit a statement or proof step that may seem simple to me but that requires a major refactor, or adding new features to Lean itself, or just seems like a brick wall. My brain is able to perform massive refactorings of mathematical knowledge and abstractions, synthesize the equivalent of tens of thousands of lines of tricky and performance-critical software, and maybe even expand the logic I am effectively operating in, all in the blink of an eye.

However, mathlib makes some weird design choices. For example, (semi)groups are defined using multiplicative notation -- and then immediately followed by an entire section giving the exact same definitions using additive notation! The claimed reason for this is that the more abstract approach is inconvenient for automation. I did it in Coq using the abstract approach, and indeed, noticed that doing so broke automation, which I then worked around in various ways. But it's just weird to me as a mathematician to have additive and multiplicative groups be different objects, so I wouldn't want to do it the Lean way come hell or high water. The Lean approach causes practical difficulties as well: you have to prove every theorem about groups twice. In some cases (e.g. product groups), you have to prove every theorem FOUR times. Ugh.