From: Michael Shulman <email@example.com> To: Nicolas Alexander Schmidt <firstname.lastname@example.org> Cc: Homotopy Type Theory <HomotopyTypeTheory@googlegroups.com> Subject: Re: [HoTT] Why did Voevodsky find existing proof assistants to be 'impractical'? Date: Sun, 3 Nov 2019 00:29:23 -0700 Message-ID: <CAOvivQxVHxFhGzoSvMU9iw5_z9kgjD7w3c_VEYX5ANH-mOS_0g@mail.gmail.com> (raw) In-Reply-To: <email@example.com> I know hardly anything about Mizar, so I can't comment on it. And I don't know for sure exactly what Voevodsky meant (and perhaps no one now does). But I am pretty sure that he was not thinking about synthetic homotopy theory at the time, because the possibility of synthetic homotopy theory wasn't really even imagined until later on (specifically, with the advent of higher inductive types). Instead, I expect he was thinking about category theory and higher category theory. The advantage of univalence in such contexts is that it formalizes the isomorphism-invariant behavior of category theory, incorporating it directly into the logical structure of the foundations so that you don't have to worry about whether your theorems are invariant under isomorphism, or prove explicitly that they are. Is this a substantial advantage over a ZFC-based system? Maybe, maybe not. (One might argue that it's not much of an advantage at all until univalence becomes "computational", as with cubical type theories, so that transporting along it can be done automatically by the proof assistant.) But there are other points to consider. Firstly, before even getting to univalence, there is a difference between membership-based set theories and type theories, which is more closely analogous to the assembly language / high level programming language divide. Type-theoretic foundations for mathematics, like strongly/statically typed programming languages, provide automatic "error-checking" for the user, catching various kinds of mistakes at "compile time", and allow more intelligent compiler optimization and inference due to the more informative nature of types. Dependent type theories are even better at this. And just as the advantages of static typing are not belied by the fact that a lot of people happily write code in dynamically typed languages, so the advantages of typed mathematics for formalization are not belied by the fact that some mathematicians are happy to do without them. It's worth noting that many of the recent high-profile formalizations of *recent* mathematical results, such as the four-color theorem, the odd-order theorem, and the Kepler conjecture, use type-theoretic proof assistants like Coq and HOL rather than set-theoretic ones like Mizar. From this perspective, the advantage of HoTT/UF is that it "fixes" certain infelicities in previously existing type theories. Now we understand quotients better and have more tools for doing without setoids; now we know what the equality type of the universe is; now we are better at computing with function extensionality and propositional extensionality; etc. So HoTT/UF gives us the benefits of a type-theoretic foundation while ameliorating some of the traditional disadvantages of that approach. But in my own opinion (which is, I believe, rather different from Voevodsky's, at least in emphasis), all of this is kind of beside the point. It's like arguing about whether or not my laptop can play movies better than an 80s-era VCR; it overlooks the main point that my laptop does *so much more* than just play movies. The real advantage of type-theoretic, and homotopy-type-theoretic, foundations, is that they have a plethora of categorical and higher-categorical models. Proving a theorem once, in constructive homotopy type theory, automatically entails the "internal" truth of the corresponding theorem in all higher toposes. I think this is a much more important selling point than whether or not we get a more practical system for formalizing plain old set-based mathematics. Mike On Sun, Oct 27, 2019 at 7:41 AM Nicolas Alexander Schmidt <firstname.lastname@example.org> wrote: > > In [this](https://www.youtube.com/watch?v=zw6NcwME7yI&t=1680) 2014 talk > at IAS, Voevodsky talks about the history of his project of "univalent > mathematics" and his motivation for starting it. Namely, he mentions > that he found existing proof assistants at that time (in 2000) to be > impractical for the kinds of mathematics he was interested in. > > Unfortunately, he doesn't go into details of what mathematics he was > exactly interested in (I'm guessing something to do with homotopy > theory) or why exactly existing proof assistants weren't practical for > formalizing them. Judging by the things he mentions in his talk, it > seems that (roughly) his rejection of those proof assistants was based > on the view that predicate logic + ZFC is not expressive enough. In > other words, there is too much lossy encoding needed in order to > translate from the platonic world of mathematical ideas to this formal > language. > > Comparing the situation to computer programming languages, one might say > that predicate logic is like Assembly in that even though everything can > be encoded in that language, it is not expressive enough to directly > talk about higher level concepts, diminishing its practical value for > reasoning about mathematics. In particular, those systems are not > adequate for *interactive* development of *new* mathematics (as opposed > to formalization of existing theories). > > Perhaps I am just misinterpreting what Voevodsky said. In this case, I > hope someone can correct me. However even if this wasn't *his* view, to > me it seems to be a view held implicitly in the HoTT community. In any > case, it's a view that one might reasonably hold. > > However I wonder how reasonable that view actually is, i.e. whether e.g. > Mizar really is that much more impractical than HoTT-Coq or Agda, given > that people have been happily formalizing mathematics in it for 46 years > now. And, even though by browsing the contents of "Formalized > Mathematics" one can get the impression that the work consists mostly of > formalizing early 20th century mathematics, neither the UniMath nor the > HoTT library for example contain a proof of Fubini's theorem. > > So, to put this into one concrete question, how (if at all) is HoTT-Coq > more practical than Mizar for the purpose of formalizing mathematics, > outside the specific realm of synthetic homotopy theory? > > > -- > > Nicolas > > > -- > You received this message because you are subscribed to the Google Groups "Homotopy Type Theory" group. > To unsubscribe from this group and stop receiving emails from it, send an email to HomotopyTypeTheoryemail@example.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/HomotopyTypeTheory/e491d38b-b50a-6172-dca9-40d45fe1b6d2%40fromzerotoinfinity.xyz. -- You received this message because you are subscribed to the Google Groups "Homotopy Type Theory" group. To unsubscribe from this group and stop receiving emails from it, send an email to HomotopyTypeTheoryfirstname.lastname@example.org. To view this discussion on the web visit https://groups.google.com/d/msgid/HomotopyTypeTheory/CAOvivQxVHxFhGzoSvMU9iw5_z9kgjD7w3c_VEYX5ANH-mOS_0g%40mail.gmail.com.
prev parent reply index Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-10-27 14:41 Nicolas Alexander Schmidt 2019-10-27 17:22 ` Bas Spitters 2019-11-03 11:38 ` Bas Spitters 2019-11-03 11:52 ` David Roberts 2019-11-03 19:13 ` Michael Shulman 2019-11-03 19:45 ` Valery Isaev 2019-11-03 22:23 ` Martín Hötzel Escardó 2019-11-04 23:20 ` Nicolas Alexander Schmidt 2019-11-04 18:42 ` Kevin Buzzard 2019-11-04 21:10 ` Michael Shulman 2019-11-04 23:26 ` David Roberts 2019-11-05 15:43 ` Daniel R. Grayson 2019-11-05 20:29 ` Yuhao Huang 2019-11-06 23:59 ` Daniel R. Grayson 2019-11-05 23:14 ` Martín Hötzel Escardó 2019-11-06 0:06 ` Stefan Monnier 2019-11-11 18:26 ` Licata, Dan 2019-11-03 7:29 ` Michael Shulman [this message]
Reply instructions: You may reply publically to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAOvivQxVHxFhGzoSvMU9iw5_z9kgjD7w3c_VEYX5ANH-mOS_0g@mail.gmail.com \ --email@example.com \ --cc=HomotopyTypeTheory@googlegroups.com \ --firstname.lastname@example.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Discussion of Homotopy Type Theory and Univalent Foundations Archives are clonable: git clone --mirror http://inbox.vuxu.org/hott Example config snippet for mirrors Newsgroup available over NNTP: nntp://inbox.vuxu.org/vuxu.archive.hott AGPL code for this site: git clone https://public-inbox.org/public-inbox.git