The article is a slow burn with a hilariously clickbait title but damn, those are some fascinating and significant consequences. > An interesting question come

The article is a slow burn with a hilariously clickbait title but damn, those are some fascinating and significant consequences. > An interesting question comes to mind: which programming features, apart from the ones we mentioned above, allow us to program [computably continuous integer streams]? In terms of Haskell, the same question is which monads allow us to program [these streams]? > Can we do it without any extra features and use just “pure” functional programming? > If by pure functional programming we understand a functional programming language with natural numbers, booleans and recusive definitions, also known as PCF, the answer is no. The proof of this uses denotational semantics and domain theory, and I will not go into it now. You may entertain yourself by trying and failing to define [computably continuous integer streams] in pure Haskell or ML, i.e., no side effects, no exceptions, no mutable store, no parallelism, no monads. > ... The lesson is for those “experts” who “know” that all reasonable models of computation are equivalent to Turing machines. This is true if one looks just at functions from N to N. However, at higher types, such as the type of our function m, questions of representation become important, and it does matter which model of computation is used. It takes a hit on the trend that was in vogue in early 2010s to do AI and metaphysics on top of Kolmogorov Complexity, Solmonoff Induction, information physics... people took the Turing Equivalence as a carte blanche to say whatever willy-nilly thing you want about the (potentially) computable nature of reality without being informed by more naturalistic methods. This is harshed even further given that these information-theoretic arguments often used non-computable notions.