Pavel Panchekha

> The thing that I can't understand is, why did it take SO LONG to get useable, proper, and intuitive CSS-based layout on web-pages?

Many reasons:

- HTML and CSS are not designed for anything complex.

HTML and CSS at their core are only meant to display a static page of text and some images in a single rendering pass on a computer from 1990s.

- Many decisions in CSS (especially early CSS) are one-off solutions that might not even have correct specifications compared to how people usually use it

Float is really a one-off solution for a very specific subset of layout. The standard box model famously has a default that no one in real world uses, and that IE actually got right. There are more: https://pavpanchekha.com/blog/css-problems.html and https://www.impressivewebs.com/css-the-bad-parts/

- Any solution has to be aware of any previous solution and mistake

Let's say, you introduce flex. How will it work with floats? What about display:inline or display:inline-block? Tables? Inside tables?

Let's say you introduce grid. All the question above plus all the questions on how it will behave with flex.

Let's say you introduce...

- Standards are mostly driven by browser implementors, who are not known for any/much of web work. Additionally, solutions have to be "fully complete including edge cases that maybe one person in the world cares about".

Cant' find the link for that, sorry, you'd have to take me at my word :)

- All that still has to work reasonably fast for some…

I posted this and it picked up steam over night, so I thought I'd add how I'm using it:

I work on 3D/4D math in F#. As part of the testing strategy for algorithms, I've set up a custom agent with an F# script that instruments Roslyn to find FP and FP-in-loop hotspots across the codebase.

The agent then reasons through the implementation and writes core expressions into an FPCore file next to the existing tests, running several passes, refining the pres based on realistic caller input. This logs Herbie's proposed improvements as output FPCore transformations. The agent then reasons through solutions (which is required, Herbie doesn't know algorithm design intent, see e.g. this for a good case study: https://pavpanchekha.com/blog/herbie-rust.html), and once convinced of a gap, creates additional unit tests and property tests (FsCheck/QuickCheck) to prove impact. Then every once in a while I review a batch to see what's next.

Generally there are multiple types of issues that can be flagged:

a) Expression-level imprecision over realistic input ranges: this is Herbie's core strength. Usually this catches "just copied the textbook formula" instance of naive math. Cancellation, Inf/NaN propagation, etc. The fixes are consistently using fma for accumulation, biggest-factor scaling to prevent Inf, hypot use, etc.

b) Ill-conditioned algorithms. Sometimes the text books lie to you, and the algorithms themselves are unfit for purpose, especially in boundary regions. If there are…

You can take this idea further by trying to find computational analogues of more complex algebra structures and operations. For example, the derivative of a type function gives the type of ‘one-hole contexts’ of that type[0], which gives rise to the work on zippers for context-preserving transformation in functional data structures, things like Rust's `Entry` API for maps.

Amr Sabry has been doing work on extending this kind of ‘type algebra’ to negatives and fractions, with applications to reversible programming à la Kanren and quantum programming languages where breaking reversibility is an important effect, and I'm always kind of captivated by it when I see it. His original paper on it[1] is from 2012; he's produced a new paper[2] more recently that is more sophisticated but perhaps a bit harder to follow without a category-theory background.

[0]: https://pavpanchekha.com/blog/zippers/derivative.html [1]: https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=389fd378c9fe9b17af2756eb484bb562fa7d638a [2]: https://dl.acm.org/doi/abs/10.1145/3434290

The payoff is in part 3, here, where crntaylor explains how to take the derivative(!) of a type:

http://chris-taylor.github.io/blog/2013/02/13/the-algebra-of-algebraic-data-types-part-iii/

You can find a somewhat more mathematical explanation here, with explanations of why this is useful:

http://pavpanchekha.com/blog/zippers/derivative.html

The most obvious use for derivative types is the automated creation of "zipper" types for functional data structures. Among other uses, zipper types make certain purely functional data structures much more efficient. This is important both for Haskell and ML programmers, and also in situations where you need to leave older versions of a data structure intact, such as when implementing rollback or creating append-only file formats.

I do something similar for http://pavpanchekha.com/ (I describe the approach here: http://pavpanchekha.com/blog/org-mode-publish.html). I've found it a pretty good blogging platform so far. A huge plus is the diversity of markup (definition lists, tables, footnotes, info boxes, and so on) that are directly supported, plus the ease of directly embedding raw HTML (for things like diagrams and charts).

But one challenge I've struggled with is how to generate full-content RSS quickly. I like that my blog's RSS includes the full blog post (since that's how I like reading posts) but Emacs wants to recompile every post every time I update the site—that takes minutes.

This is an interesting post. An expert in numerical analysis compares the output of a tool which optimizes floating point expressions for speed and accuracy with the output generated by chatgpt on the same benchmarks:

https://pavpanchekha.com/blog/chatgpt-herbie.html

> I wouldn't use it—sanity-checking its algebra is a lot of work, but even if you fixed that up, the high-level ideas typically aren't that good either.

This has been exactly my experience with chatgpt as well.