3 ms·

> then you realize that mathematicians figured all this stuff out in a really elegant way that composes and provides just a solid bedrock. Can you expand on wh

> then you realize that mathematicians figured all this stuff out in a really elegant way that composes and provides just a solid bedrock. Can you expand on what mathematicians discovered and how it can be applied to coding? Or does it require a certain programming language? I'm looking at the Hyperfiddle website and trying to understand how these concepts are connected. Thanks!

dustingetz 4y ago
He's basically paraphrasing Greenspun's Tenth Rule: "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." Photon has, by construction, proven that it is possible to define fullstack web UIs as pure functional expressions despite crossing the client/server boundary, and this is done without adding in all that extra "React.js-era web framework stuff" (the travesty being discussed in this larger thread), instead using only the composition semantics of lambda that were established many decades ago. The best explanation of that is this 10 minute talk: https://news.ycombinator.com/item?id=31217448 https://news.ycombinator.com/item?id=31217448
capn_duck 4y ago
In particular I was talking about parser/compiler formalizations made in the 50's/60's with the participation of the linguistic community. Kleene stars and their connection to regular languages, the Chomsky hierarchy, pushdown automata and table construction to make efficient bottom up parsers. And the benefits and confidence that these formalizations can provide to the programmers implementing these systems to the point that today, parser generators are an afterthought. No one would try to implement a parser today using a pile of if/then statements or well, those that do will probably find the road to enlightenment after some initial pain and then some googling. This isn't Math in the sense of numerical computing or solving partial differential equations. But its a better and more natural abstraction to work from. We've figured out the types of graphs we require to express our computations, and we've figured out the language representations that generate those graphs, as well as efficient methods to generate those graphs given an input language and a sequence of sentences. Add to that all the rich developments of type theory. The Photon/Hyperfiddle thing seems to me to be somewhat similar. It's declarative approach, let the compiler figure out all the cut points and join points, and just stop worrying about it. I'm sure if you looked at their source code, you'd find a lot of code concerned with walking the program tree and coloring different sections, then transforming those sections in a context-dependent way in to something that can run on a server versus a client with well defined interactions.

dustingetz 4y ago

He's basically paraphrasing Greenspun's Tenth Rule: "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." Photon has, by construction, proven that it is possible to define fullstack web UIs as pure functional expressions despite crossing the client/server boundary, and this is done without adding in all that extra "React.js-era web framework stuff" (the travesty being discussed in this larger thread), instead using only the composition semantics of lambda that were established many decades ago. The best explanation of that is this 10 minute talk: https://news.ycombinator.com/item?id=31217448 https://news.ycombinator.com/item?id=31217448

capn_duck 4y ago

In particular I was talking about parser/compiler formalizations made in the 50's/60's with the participation of the linguistic community. Kleene stars and their connection to regular languages, the Chomsky hierarchy, pushdown automata and table construction to make efficient bottom up parsers. And the benefits and confidence that these formalizations can provide to the programmers implementing these systems to the point that today, parser generators are an afterthought. No one would try to implement a parser today using a pile of if/then statements or well, those that do will probably find the road to enlightenment after some initial pain and then some googling. This isn't Math in the sense of numerical computing or solving partial differential equations. But its a better and more natural abstraction to work from. We've figured out the types of graphs we require to express our computations, and we've figured out the language representations that generate those graphs, as well as efficient methods to generate those graphs given an input language and a sequence of sentences. Add to that all the rich developments of type theory. The Photon/Hyperfiddle thing seems to me to be somewhat similar. It's declarative approach, let the compiler figure out all the cut points and join points, and just stop worrying about it. I'm sure if you looked at their source code, you'd find a lot of code concerned with walking the program tree and coloring different sections, then transforming those sections in a context-dependent way in to something that can run on a server versus a client with well defined interactions.