<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Topics on My New Hugo Site</title>
    <link>https://drcicero.github.io/topics/</link>
    <description>Recent content in Topics on My New Hugo Site</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <atom:link href="https://drcicero.github.io/topics/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Choreographic Programming</title>
      <link>https://drcicero.github.io/topics/choreographic/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://drcicero.github.io/topics/choreographic/</guid>
      <description>← Back to Home&#xA;Write a whole distributed system as one script, and let the compiler split it up.&#xA;A distributed system is normally written as many separate programs, one per participant, which have to agree on a protocol that exists nowhere in the code. Choreographic programming inverts this: you write the interaction once, as a single program that names every participant, and a compiler projects it onto the individual endpoints.</description>
    </item>
    <item>
      <title>Incremental Programming</title>
      <link>https://drcicero.github.io/topics/incremental/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://drcicero.github.io/topics/incremental/</guid>
      <description>← Back to Home&#xA;Compilers that turn plain functional code into computations that redo only what changed.&#xA;Most programs throw away their own work. Change one cell of a matrix, one row of a table, one node of a tree, and the whole computation runs again from scratch. Incremental programming asks the compiler to do better: from an ordinary functional program, derive a second program that consumes a change to the input and produces the corresponding change to the output, reusing everything that was already computed.</description>
    </item>
    <item>
      <title>Type Systems &amp; Mechanized Proofs</title>
      <link>https://drcicero.github.io/topics/types-and-proofs/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://drcicero.github.io/topics/types-and-proofs/</guid>
      <description>← Back to Home&#xA;Types catch bugs before a program runs, and stop humans and bots alike from doing nonsense.&#xA;A type system is a negotiation. The programmer wants to write what they mean; the compiler wants a guarantee it can actually check. Push too hard on the guarantee and the notation turns rigid (effects marshalled one per line, motives spelled out by hand). Push too hard on convenience and the guarantee evaporates.</description>
    </item>
    <item>
      <title>Compilers for Machine Learning</title>
      <link>https://drcicero.github.io/topics/machine-learning/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://drcicero.github.io/topics/machine-learning/</guid>
      <description>← Back to Home&#xA;Derive and prove what ML frameworks hard-code, and search for the equations that generated the data.&#xA;Machine learning runs on a small set of operations (differentiate this, invert that, multiply these arrays) that a compiler ought to be able to derive rather than have a human write out by hand. That is one half of the work here: taking the transformations deep learning frameworks hard-code and giving them a proper functional foundation, so they can be optimized aggressively and proved correct rather than trusted.</description>
    </item>
  </channel>
</rss>
