<story><title>One Way to Represent Things</title><url>https://macwright.com/2021/02/23/one-way-to-represent-things.html</url></story><parent_chain><item><author>lmm</author><text>Being able to build good representations of things is important. So many programming languages lack something as basic as sum types, which puts them behind the state of the art in the 1970s. Yes, Haskell has some fancier stuff in it as well, but a lot of the value comes from simply having a good way to represent &amp;quot;this or that&amp;quot; and applying it properly.&lt;p&gt;The other thing that we do all the time in everyday life is a quotient, and as far as I know no programming language has a good way to represent that: something as basic as a fraction (i.e. a pair of integers, but two pairs are equivalent when ...) can&amp;#x27;t be expressed except in an ad-hoc way.&lt;p&gt;I appreciate the author&amp;#x27;s enthusiasm for offering a large standard library of datatypes - I certainly think things like decimals and trees ought to be more available than they are - but I don&amp;#x27;t think we can even start on that until we actually have good tools for defining datatypes. And actually the best way to get there might be to have &lt;i&gt;fewer&lt;/i&gt; built-in datatypes, and force ourselves to go through the work of defining numbers and strings and so on &amp;quot;in userspace&amp;quot;, using the normal language facilities. That would quickly highlight a lot of quite basic things that a lot of languages are missing - e.g. literals for user-defined types are incredibly painful in a lot of algol-family languages.</text></item></parent_chain><comment><author>dragonwriter</author><text>&amp;gt; The other thing that we do all the time in everyday life is a quotient, and as far as I know no programming language has a good way to represent that: something as basic as a fraction&lt;p&gt;Er, fractions are a directly-supported (core or stdlib) type in many languages. Including:&lt;p&gt;Scheme family languages (numbers work this way by default, unless you introduce irrational numbers), Ruby (doesn&amp;#x27;t default to rational math by default generally for numbers, but has syntax for rational literals and rationals use rational math), Raku, Python, Clojure, Go, Haskell, and, well, lots of languages have core&amp;#x2F;stdlib support even if they don&amp;#x27;t have a literal syntax or Scheme-style default-to-exact-rational behavior.</text></comment>
<story><title>One Way to Represent Things</title><url>https://macwright.com/2021/02/23/one-way-to-represent-things.html</url></story><parent_chain><item><author>lmm</author><text>Being able to build good representations of things is important. So many programming languages lack something as basic as sum types, which puts them behind the state of the art in the 1970s. Yes, Haskell has some fancier stuff in it as well, but a lot of the value comes from simply having a good way to represent &amp;quot;this or that&amp;quot; and applying it properly.&lt;p&gt;The other thing that we do all the time in everyday life is a quotient, and as far as I know no programming language has a good way to represent that: something as basic as a fraction (i.e. a pair of integers, but two pairs are equivalent when ...) can&amp;#x27;t be expressed except in an ad-hoc way.&lt;p&gt;I appreciate the author&amp;#x27;s enthusiasm for offering a large standard library of datatypes - I certainly think things like decimals and trees ought to be more available than they are - but I don&amp;#x27;t think we can even start on that until we actually have good tools for defining datatypes. And actually the best way to get there might be to have &lt;i&gt;fewer&lt;/i&gt; built-in datatypes, and force ourselves to go through the work of defining numbers and strings and so on &amp;quot;in userspace&amp;quot;, using the normal language facilities. That would quickly highlight a lot of quite basic things that a lot of languages are missing - e.g. literals for user-defined types are incredibly painful in a lot of algol-family languages.</text></item></parent_chain><comment><author>Smaug123</author><text>Quotients are a bit of an unsolved problem even in Agda. Cubical Agda makes the definition easier but makes it &lt;i&gt;much&lt;/i&gt; harder to work with the resulting datatype, while if you don&amp;#x27;t use higher inductive types you end up in setoid hell where the language can&amp;#x27;t do any of the obvious things you should be able to do automatically.</text></comment>