No other text to diagram tool also allows moving/editing diagram itself with mouse. I have shared this list[1] of all similar tools on web a few times before.
You've clearly put a lot of work into assembling this list. I'm guessing the page would be significantly more valuable to readers and much more likely to be found by people interested in the the information in it if you added a brief sentence or two description of each of the projects.
This list is not a good fit for your XOSH list. It does include PlantUML but does not include a feature-breakdown. Instead it's simply a declaration of existence.
I really wish Mermaid and PlantUML had compatible syntax, or at least more overlap for the basic structural stuff. On a day to day basis I'm writing either PlantUML in Confluence (via a plugin) or Mermaid in GitHub, and I almost always have to open up the reference or review an existing diagram to refresh myself on the different syntax.
FYI there’s also a Mermaid plugin for Confluence, we use it extensively. If you don’t mind losing some features from PlantUML for the sake of consistency.
I love the idea, but until UML is unbiquitous to generate like prettier is to code completion, it's relegated to a pedagogical device, and not a operable road map to learning a system that naturally grows and changes
Most of my UML is what I call whiteboard UML because we draw something that looks almost like UML on a whiteboard, then start implementing that. A couple weeks later we realize the implementation and the UML have diverged because didn't think of something so we erase the whiteboard. The initial drawing was very useful to get the implementation started.
20 years ago I worked at a place that keep the UML up to date. It was nice to have, every week I'd print out the latest and paste it on my wall, then as I developed I'd look over at the poster to answer questions. It only worked there because we generated out code from the UML and so up to date UML was always easy to find. If you don't have a dev process that keeps it up to date I don't think it is worth it.
> It only worked there because we generated out code from the UML
That sounds very interesting! Was that a proprietary tool/pipeline or is there something which I can use to leverage UML to generate some specific language... for example C++?
I did for a while code gen from UML, in IBM/Rational Software Architect. They would transform the model into an intermediate xml, which was fed to JSP’s for code gen.
We also used Sparx Enterprise Architect to model a large amount of business processes notated in BPMN, Use Cases in UML, business rules using a Sparx framework, etc. From these linked and traced models we generated comprehensive documentation using a nice framework that could walk the model and merge information into Word documents.
> Are UML diagrams used effectively in the dev industry?
Are they effective? I say they are when correctly used. For example last year I used plant UML to draw a sequence diagram to demonstrate some threading/mutex problems. [1]
I've also used draw.io to draw similar problems. [2]
I would say that tbqh using UML (or maybe just plant UML) is the "better" solution because it can be embedded in code and re-rendered as needed. But draw.io is _much_ easier to use!
I will also say that UML diagrams aren't well taught nor do most devs even know to reach for the tool.
I was going to say, I used a sequence diagram last week to wrap my head around a threading situation. I think they are a good way to visually model anything asynchronous or thread based, and sometimes also user interaction flows, and I think UML's bad rep (is that fair to say?) means a lot of developers either are not aware of them or think they must have no value – I consider using them a bit of a secret superpower ;)
I do occasionally use ER diagrams for drawing out data models too, but I'm super rough about following the "rules" with both of these. Really just a convenient way to sketch stuff out (usually using PlantUML or Mermaid, as I find it quicker to do in ASCII).
I prefer BPMN, it is more specific and easier on the eyes. The fact that there are many different types of UML diagram means noone knows them well enough to navivate and create them
Following them like a holy-grail, no, not that useful. I usually use them to help juniors build a foundational skill about drawing graphs of architecture before implementing them, as the ground-work for discussing the proposed architecture. Also explaining to them that it doesn't have to be using the right fill/hollow arrow or whatever, more that the graphs themselves accurately describes the architecture.
Sequence diagrams are extremely effective to document complex workflows. I’ve seen to many developers recreate sequence diagrams badly with boxes, arrows and numbers (to represent order) where proper sequence diagrams would have been a better fit.
I also use database diagrams a lot to specify complex data models. It helps to see the model and it’s relations.
I use them sometimes for component or sequence diagrams. I’m usually really happy with the result and get positive feedback for going to the effort. But stick to the 80:20 principle instead of diving down a UML pedantry rabbit hole.
Bullet points for requirements and one "box, swimlane, and cylinder" diagram (with no standard elements) for analysis and design if you're on a 'strict' project.
If we can't even decide on language A or B, CSV or JSON, ... (these are implementation artifacts that are essential to the solution), what hope do we have of even understanding- no even seeing that there is a problem in the other disciplines (requirements, analysis, etc) of technology delivery?
If we make it another 100 years, we'll look back at this time and view what we are coding now as wattle and daub huts whereas a century from now we'll be erecting the analogue of technological skyscrapers (but probably not good ones, if I'm being realistic).
I predict that the future development landscape won't be much different from today. In the same way that the development landscape today isn't much different to how it was 60 years ago. The only difference will be faster hardware, allowing people to use even slower languages to do just enough to get typical web applications to work. Developers will still be 95% focused on their own convenience instead of focusing on the business/end user. Developers will still "solve" problems by adding another layer of complexity and copy/pasting code they don't understand from somebody else. Developers will still be coding in languages that are around today (because legacy).
Very nice! I wish I had something like this when having to write papers for university. There are some nice tools but getting a consistent layout was always a problem. Are more diagram types planned?
[1]: https://xosh.org/text-to-diagram/