Discussion of Homotopy Type Theory and Univalent Foundations
 help / color / mirror / Atom feed
From: Michael Shulman <shulman@sandiego.edu>
To: Nicolas Alexander Schmidt <zero@fromzerotoinfinity.xyz>
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	[thread overview]
Message-ID: <CAOvivQxVHxFhGzoSvMU9iw5_z9kgjD7w3c_VEYX5ANH-mOS_0g@mail.gmail.com> (raw)
In-Reply-To: <e491d38b-b50a-6172-dca9-40d45fe1b6d2@fromzerotoinfinity.xyz>

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
<zero@fromzerotoinfinity.xyz> 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 HomotopyTypeTheory+unsubscribe@googlegroups.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 HomotopyTypeTheory+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/HomotopyTypeTheory/CAOvivQxVHxFhGzoSvMU9iw5_z9kgjD7w3c_VEYX5ANH-mOS_0g%40mail.gmail.com.

      parent reply	other threads:[~2019-11-03  7:29 UTC|newest]

Thread overview: 32+ 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-24 18:11               ` Kevin Buzzard
2019-11-26  0:25                 ` Michael Shulman
2019-11-26  8:08                   ` Ulrik Buchholtz
2019-11-26 19:14                   ` Martín Hötzel Escardó
2019-11-26 19:53                     ` Kevin Buzzard
2019-11-26 20:40                       ` Martín Hötzel Escardó
2019-11-26 22:18                       ` Michael Shulman
2019-11-27  0:16                         ` Joyal, André
2019-11-27  2:28                           ` Stefan Monnier
2019-11-27  1:41                         ` Daniel R. Grayson
2019-11-27  8:22                         ` N. Raghavendra
2019-11-27 10:12                     ` Thorsten Altenkirch
2019-11-27 16:37                       ` Michael Shulman
2019-11-27 20:21                 ` 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 publicly 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 \
    --to=shulman@sandiego.edu \
    --cc=HomotopyTypeTheory@googlegroups.com \
    --cc=zero@fromzerotoinfinity.xyz \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).