[hardmath123]

A lot of replies here are missing the key idea behind Penrose: that the "substance" and "style" of any mathematical diagram are separable. For example, the "substance" of a diagram might be a collection of sets with known subset relationships:

Set A, B, C

IsSubset(B, A)

IsSubset(C, A)

That same substance can then be rendered in many different styles, e.g. as a Venn diagram or as a tree diagram (substance vs. style is a lot like HTML vs. CSS). Importantly, Penrose's vision is that experts will author libraries of domains and styles, and end-users need only express the substance of their diagrams (i.e. the three lines of code above).

The second beautiful idea in Penrose is that diagram generation is expressed as a constrained optimization problem. This lets you easily experiment with layouts by writing constraints and sampling a variety of potential diagrams via stochastic search.

These two ideas set Penrose apart from most other diagram software out there. I really hope it gains wider adoption. Give it a try!

[xigoi]

> substance vs. style is a lot like HTML vs. CSS

Given the popularity of frameworks like TailwindCSS, it seems that people here don’t understand the advantage of separating HTML and CSS either, so I’m not sure if this analogy is helpful…

[coldtea]

Or that they understand it just fine, but don't think it has a particular advantage worth the extra complexity tradeoff.

[mewpmewp2]

I think graphs are quite different from HTML. The "substance" in html is far too chaotic compared to the structured data for the graphs.

[micheljansen]

The comparison to CSS for separating style vs (semantic) data was also the first thing that came to mind for me.

[dahart]

> Importantly, Penrose's vision is that experts will author libraries of domains and styles, and end-users need only express the substance of their diagrams (i.e. the three lines of code above).

In that case, would it be a good idea to start the tutorial with some predefined domains and styles? Part of the intimidation factor here is not just the programming language, but also the abstraction one is faced with using and trying to understand before seeing their first picture. If the goal is to have predefined libraries, then why not start with pre-defined domains and styles and first teach people only how to do the substance, and leave domain & style definitions for advanced tutorials?

What are the advantages of making everything a constrained optimization problem? I like the idea that I can experiment with layouts sometimes, but I don’t really want a random diagram all the time. I realize it doesn’t have to be random, I have the choice to explicitly pin things down, but that takes extra work with Penrose, I’m asking why random is the default. Having done a lot of technical diagramming in papers and books, I would expect to almost always pin things down, and maybe once in a while free up a few elements to move around. Letting the whole thing go random is rarely if ever something I’d choose, especially near the end of making a more complicated diagram. What I’m wondering is whether this design is good for experts, and why, or if it mostly helps beginners.

I recently discovered GeoGebra, and would love to hear some compare & contrast notes. It doesn’t use constrained optimization, and it does separate style from substance as needed, but in a different way than Penrose. The important feature seems to be that it lets you define the relationships between elements of the diagram, so if you move a point, the line attached follows, and then parallel and perpendicular lines attached follow, and so on, everything in the diagram becomes responsive to adapt to the change while letting you put something right where you want it. This way I still get to experiment with layouts, but nothing in the construction needs to be random. Most of the style definitions are point & click GUI actions. Are there reasons that workflow is inferior to Penrose?

[sestep]

Yeah, exactly! Also, possibly a third idea of Penrose is the way the selector matching blocks in the Style language can be used to construct the constrained optimization problem as you mention. This is inspired by CSS, but there are a lot of differences too.

With regard to the separation of substance and style, I think that idea can be profitably applied in other settings as well. For instance, Graphviz, tikz-cd, and Mermaid are all fairly declarative. But also, I feel like this idea could be even more profitably applied by building a diagramming library inside of a general-purpose programming language like Python.

For instance, take a look at the Substance code for our quaternion multiplication table example: https://penrose.cs.cmu.edu/try/?examples=group-theory/quater... It's about 83 lines of code. In contrast, by really taking the separation idea seriously, one can write a generic Python function for creating Cayley table diagrams, after which that particular example only takes about 5 lines of code: https://github.com/samestep/diagrams/blob/750f7a544635a6fd9f...

[davidthewatson]

This makes sense!

However, as I've commented on other software like this, why are none of the examples style-free Venn diagrams? That is, black on white 3 circle overlapping each other in pairs with a single shared triangle intersection at center? I apologize if one of these is already present. Style has little value there since it may obscure reality.

[spanswick]

I think upset diagram would be even better. https://upset.app/