5 ms·

The result looks nice but why not use existing tools like plantuml for common diagrams? It is already supported by some Markdown to HTML converters.

by emareg 3y ago

JonChesterfield 3y ago
I expected the answer to be that pikchr came first, but plantuml was 2009 according to Wikipedia and pikchr appears to be 2020 https://pikchr.org/home/info/d06dd0ebe7dae623 https://pikchr.org/home/info/d06dd0ebe7dae623 I'm personally excited to discover pikchr because I periodically need to produce box&arrow style diagrams and everything else from the author has been solid and easy to hack on.
- bachmeier 3y ago
  That's not quite the full story though. Pikchr is designed to be compatible with and extend PIC, which goes back to 1988. https://en.wikipedia.org/wiki/PIC_(markup_language) https://en.wikipedia.org/wiki/PIC_(markup_language) https://pikchr.org/home/doc/trunk/doc/differences.md https://pikchr.org/home/doc/trunk/doc/differences.md
LVB 3y ago
For common diagrams, you probably should. I've used Pikchr, and if you want/need to place a lot of things manually or otherwise have a larger degree of control, then it fills that niche OK, I guess. But for whipping up a flowchart or sequence diagram, I find Mermaid or other tools with higher-level abstractions much quicker and simpler. The big use case is if you need to use Fossil, which only supports Pikchr for inline diagrams. That's a shame IMO, and I would love Mermaid support.
- sgbeal 3y ago
  > The big use case is if you need to use Fossil, which only supports Pikchr for inline diagrams. That's a shame IMO, and I would love Mermaid support. Sidebar... (A fossil dev here.) That would require third-party code dependencies, something all projects created by Fossil's project lead (Richard Hipp) avoid except where absolutely necessary. In fossil, the only required 3rd-party dependency is zlib, with libssl highly recommended but not strictly required. Though fossil is heavily dependent on sqlite, they're both by the same main developer so it's not really a 3rd-party dependency. Same goes for JS code like Mermaid - if it's not written by a fossil project member, it doesn't go into the source tree.
  - troupo 3y ago
    There is a point at which you end up re-writing the entire universe yourself for smaller and smaller gains
    - jddj 3y ago
      Sure, but it depends how strongly you care about the security of the supply chain for a core piece of software for our industry, Vs having a more featureful way to make diagrams.
      - troupo 3y ago
        creating inline diagrams to display in documentation or comments in a VCS used to handle sqlite code isn't that much of a security issue IMO. It's bordering on paranoia :)
        sgbeal 3y ago
        > It's bordering on paranoia :) FWIW/FYI... as someone who has collaborated extensively in the "Hwaci ecosystem," for lack of a better term (projects stemming from Richard Hipp and his company (Hwaci)), i can elaborate a bit on that... It's not about security in the conventional computing sense, but more about _supply-chain security_. Any third-party components can become unmaintained or break in incompatible ways at any time. The Hwaci ecosystem has a strong culture of avoiding third-party-dependencies, stemming from/related to Richard's definition of freedom: "freedom is being able to take care of yourself," i.e. not depending on others to take care of you. It's important to Richard, and is therefore a part of his projects' cultures, that those who maintain the project are capable of continuing to do so. It's not always feasible to take over maintenance of upstream third-party code, or port away from it, if it suddenly becomes unmaintained. Similarly, it is not always feasible to adapt one's own code to incompatible changes made in upstream third-party code. Avoiding upstream dependencies, despite the obvious annoyance of having to re-invent the wheel at times, inherently gives a developer more freedom over the direction of their own projects. All projects within the Hwaci ecosystem share the trait that they eschew third-party dependencies unless they are (A) unavoidable, (B) non-trivial or non-sensible to reimplement in some minimal form, and (C) ubiquitous (zlib, libssl, and tcl being the counter-examples which most readily come to mind). That's the short and the long of it.
sgbeal 3y ago
> why not use existing tools like plantuml for common diagrams? Pikchr was created specifically to support the sqlite family of projects and was initially deployed in the markdown processor of the Fossil SCM (one of sqlite's siblings). That whole family of projects avoids third-party dependencies where at all possible for reasons too detailed to type out one-handed on a mobile device.
- sgbeal 3y ago
  > That whole family of projects avoids third-party dependencies where at all possible for reasons too detailed to type out one-handed on a mobile device. ... but which has since been elaborated on in <https://news.ycombinator.com/item?id=38890382 https://news.ycombinator.com/item?id=38890382>.

The result looks nice but why not use existing tools like plantuml for common diagrams? It is already supported by some Markdown to HTML converters.

by emareg 3y ago

The result looks nice but why not use existing tools like plantuml for common diagrams? It is already supported by some Markdown to HTML converters.

JonChesterfield 3y ago

I expected the answer to be that pikchr came first, but plantuml was 2009 according to Wikipedia and pikchr appears to be 2020 https://pikchr.org/home/info/d06dd0ebe7dae623 https://pikchr.org/home/info/d06dd0ebe7dae623 I'm personally excited to discover pikchr because I periodically need to produce box&arrow style diagrams and everything else from the author has been solid and easy to hack on.

bachmeier 3y ago
That's not quite the full story though. Pikchr is designed to be compatible with and extend PIC, which goes back to 1988. https://en.wikipedia.org/wiki/PIC_(markup_language) https://en.wikipedia.org/wiki/PIC_(markup_language) https://pikchr.org/home/doc/trunk/doc/differences.md https://pikchr.org/home/doc/trunk/doc/differences.md

LVB 3y ago

For common diagrams, you probably should. I've used Pikchr, and if you want/need to place a lot of things manually or otherwise have a larger degree of control, then it fills that niche OK, I guess. But for whipping up a flowchart or sequence diagram, I find Mermaid or other tools with higher-level abstractions much quicker and simpler. The big use case is if you need to use Fossil, which only supports Pikchr for inline diagrams. That's a shame IMO, and I would love Mermaid support.

sgbeal 3y ago
> The big use case is if you need to use Fossil, which only supports Pikchr for inline diagrams. That's a shame IMO, and I would love Mermaid support. Sidebar... (A fossil dev here.) That would require third-party code dependencies, something all projects created by Fossil's project lead (Richard Hipp) avoid except where absolutely necessary. In fossil, the only required 3rd-party dependency is zlib, with libssl highly recommended but not strictly required. Though fossil is heavily dependent on sqlite, they're both by the same main developer so it's not really a 3rd-party dependency. Same goes for JS code like Mermaid - if it's not written by a fossil project member, it doesn't go into the source tree.
- troupo 3y ago
  There is a point at which you end up re-writing the entire universe yourself for smaller and smaller gains
  - jddj 3y ago
    Sure, but it depends how strongly you care about the security of the supply chain for a core piece of software for our industry, Vs having a more featureful way to make diagrams.
    - troupo 3y ago
      creating inline diagrams to display in documentation or comments in a VCS used to handle sqlite code isn't that much of a security issue IMO. It's bordering on paranoia :)
      - sgbeal 3y ago
        > It's bordering on paranoia :) FWIW/FYI... as someone who has collaborated extensively in the "Hwaci ecosystem," for lack of a better term (projects stemming from Richard Hipp and his company (Hwaci)), i can elaborate a bit on that... It's not about security in the conventional computing sense, but more about _supply-chain security_. Any third-party components can become unmaintained or break in incompatible ways at any time. The Hwaci ecosystem has a strong culture of avoiding third-party-dependencies, stemming from/related to Richard's definition of freedom: "freedom is being able to take care of yourself," i.e. not depending on others to take care of you. It's important to Richard, and is therefore a part of his projects' cultures, that those who maintain the project are capable of continuing to do so. It's not always feasible to take over maintenance of upstream third-party code, or port away from it, if it suddenly becomes unmaintained. Similarly, it is not always feasible to adapt one's own code to incompatible changes made in upstream third-party code. Avoiding upstream dependencies, despite the obvious annoyance of having to re-invent the wheel at times, inherently gives a developer more freedom over the direction of their own projects. All projects within the Hwaci ecosystem share the trait that they eschew third-party dependencies unless they are (A) unavoidable, (B) non-trivial or non-sensible to reimplement in some minimal form, and (C) ubiquitous (zlib, libssl, and tcl being the counter-examples which most readily come to mind). That's the short and the long of it.

sgbeal 3y ago

> why not use existing tools like plantuml for common diagrams? Pikchr was created specifically to support the sqlite family of projects and was initially deployed in the markdown processor of the Fossil SCM (one of sqlite's siblings). That whole family of projects avoids third-party dependencies where at all possible for reasons too detailed to type out one-handed on a mobile device.

sgbeal 3y ago
> That whole family of projects avoids third-party dependencies where at all possible for reasons too detailed to type out one-handed on a mobile device. ... but which has since been elaborated on in <https://news.ycombinator.com/item?id=38890382 https://news.ycombinator.com/item?id=38890382>.