One doesn't believe that mafia exist until one experiences how some things and projects are impossible, and it applies not only to the few Italian regions stereotypically associated with organized crime.
From a business perspective, did it work? Was the team more, less, or equally effective than one where you didn't expend the time and expense of hiring a more homogenous group? Was turnover better or worse?
I know you can't absolutely know the counter-factual, but I've always wondered this. Incidentally, when I was a young man and CS major, I changed majors and went into a different field because I wanted to be around more women, but I've never known if being outside that kind of monoculture actually is better for the business or not.
Is the business perspective the right one to go with?
Let's say it's legal to discriminate on race in hiring in the US. Then a Japanese restaurant hires only Japanese workers because they find customers prefer it. Do we want to have this?
The purpose of our state is to provide for its citizens. So we decided to use a market economy because it seems the most efficient way to do that. But we make up the rules that it runs by and we can change the rules as we see fit.
So it seems now we are saying DEI is not a good rule. Can we make a better rule or is the goal of that rule not good?
There are multiple axes upon which something like this can be evaluated. I'm not against us as a society collectively deciding we should enforce rules that may be counter to business logic (e.g., child labor laws to pick something uncontroversial).
When something is more controversial, it's common to look at the business case. It has commonly been argued that 'diversity' is good business even disregarding any desire one may have related to restorative justice.
Put simply, if it's good business and good morals we should do it, if it's bad business and good morals or good business and bad morals, we have to weigh the balance of it (bad business can lead to morally bad outcomes, like layoffs), and if it's bad business and bad morals we ought not do it at all. I was just focusing on the business case under the assumption that the poster believed it to be good morally.
> I think it's always conscious one way or the other. With or without DEI.
Isn't the central point of DEI that whites prefer whites due to an unconscious bias?
Then, on one hand you have a very conscious decision to hire a minority just because he or she is a minority. On the other hand, you have an unconscious bias that might or might not be there but you can't really measure it by definition because it's unconscious. It's not the same.
I think it's more unsaid than unconscious. But putting that aside, if DEI is purposeful and deliberate while the "natural state" of things is not (unconscious bias), is that how we should leave it?
Should businesses have the freedom to exclude if it's unconscious?
The problem with unconscious bias is that it's unobservable by definition: it might be there, it might not be there and if it's there it might be imperceptible or very strong; you don't know because it's unconscious. It might even be not existing, and the gaps in hiring explained by the fact that minorities have less access to higher education for economic reasons. Yet the response to this is always conscious.
But in hiring, I think it's mostly conscious. What I mean is that I think people will see a long Indian name they can't pronounce and skip that resume or put it off until later. That's conscious. They'll see someone who looks like themselves and feel more comfortable talking to them. That's conscious. Etc.
If it was so simple, we wouldn't need equality of outcome. We would just need to tell people to pay more attention. The whole point of dei is that, since bias is unconscious and impossible to eliminate, we should err on the other side.
It might not be simple. It could be very hard, very expensive. Is it worth doing? Does it have value?
Would it be so bad if most of the CEOs are white men? All the execs are white men?
But I don't want to pick on white men. Let's say would it be so bad to let the incumbents call the shots. Let the incumbents hire only who they want to hire.
Should business have freedoms that are good for business but bad for society?
Isn't the whole reason for businesses in the first place is that they improve society? They are an efficient way to allocate resources for the good of everyone involved. It runs by rules that we set. And we tweak those rules. And it seems DEI may be one of those rules that aren't good and we can change it.
But the end goal shouldn't be defined as anything that is good for business is good for society.
Introducing unfair bias to contrast perceived bias that might or not might be there and might have or not have the provided explanation is not good for society, no.
What if we don't assume any bias and just look at outcome?
We stipulate that bias should play no part in decision making. Only the outcome should matter. If the outcome doesn't match racial balance of the society we make it so.
Sadly, Adobe Acrobat Viewer cannot load it, but if go to Chrome and choose Open.. That should use chrome PDF to display it in the browser (depending on your settings maybe) which worked for me.
Works in Edge's PDF viewer, after exiting the initial mode via the <- in the upper left corner. (If you know how to avoid this being the default, let me know.)
We are doing some fundamental changes to how diagrams are rendered, which would enable us to support more renderers. This will enable us to do server side rendering without a browser.
The main reason why we need a browser currently is size calculations of the SVG boxes, which libraries like jsdom does not support.
Please don't take the, in my opinion, excessive criticism to heart. Mermaid is fantastic. It would be even better if it supported more renderers but as it stands to day its an invaluable tool.
That I can bring GraphViz into a browser but not Mermaid out of the browser forces GraphViz for some usecases. Unless browser-native was the intent (idk, it could be... maybe thats why it was named Mermaid), I do think it should be a high priority thing.
FWIW I gave up trying to render SVG for our project and switched to using fabric.js (and node-canvas for server side rendering). For us it was mostly because it had far better text support.
SVG is in a bit of an awkward place. It’s mostly used as a graphics file format. It actually is (when opened by a web browser) a full application environment, the nonreflowable counterpart to the reflowable HTML, or the open version of Flash with worse authoring tools: there’s support for full JavaScript, MathML, CSS, animations without CSS... You can probably stick RDFa somewhere in there too. And while XML is outwardly simple, I’ve heard an XML parser author say Adobe tools exporting SVGs like to define parsed entities in the internal DTD subset (did you know XML inherited a full textual macro system from SGML?).
There’s a reason why there’s SVG then there’s SVG Tiny then (recently, not approved by any standards process) there’s SVG Tiny PS. But as far as I can tell, there still isn’t any broad agreement on what subset of SVG is sane for dumb graphics consumed by (relatively) dumb rasterizers.
This is interesting, but we're not expecting Mermaid to parse and execute SVG content, we just need it to export its internal representation to SVG.
IIRC the issue is that they rely on DOM manipulation for rendering (and node doesn't have a DOM). I can't think of a reason why Playwright as a mechanism would result in inconsistent output though, as long as you give the CLI the same theme/size/etc parameters as the original.
May I suggest my favorite: blockdiag (including seqdiag, nwdiag, and actdiag, and rackdiag (rackdiag super slept on!))
I've evaluated every diagrams-as-code tool in existence just about, and revisit them every year or two, and I keep coming back to blockdiag. Mermaid looked nice but had many issues I ran into.
blockdiag doesn't look as pretty out of the box, but when done right it looks really good, especially as an SVG
When I have needed a static image I have just taken a screenshot. I would still put the mermaid code and style next to it in case future modifications were needed. Worked reasonably well.
Graphviz is hard. I only need a graph making tool three or four times a year and when I go back to mermaid, only 5 minutes of going through the documentation get's me up to speed. But graphviz is much more complex in a way I often don't need. It's also pretty verbose; You first need to define nodes then the connections while in mermaid both are done in a single line.
However mermaid's experience and output is definitely subpar. Under the saved graphs section you find randomly saved graphs and there is no way to organize multiple graphs in the web editor.
I've even thought of writing a simple script to translate mermaid charts into dot language.
A potentially much bigger difference in verbosity comes from graphviz being a general purpose graph drawing software, while mermaid is more of a software for drawing software development related diagrams (not just graphs and tables). This is well reflected by the fact that in graphviz the diagram types are categorized by layout engine (hierarchical drawing, spring model, force directed placement, circular layout,...), but in Mermaid they are categorized by what data the diagram represents (flowchart, sequence diagram, class diagram, state diagram, entity relationship diagram, gant diagram). You can draw many of those types of diagrams in Graphviz but you will have to potentially do a lot more of reinventing the wheel and low level manual formatting (arrow and node shapes, line style, etc.), while Mermaid documentation uses more of diagram specific terms like cardinality, visibility(public, private, ...) and many others.
That's like comparing Excel with purpose built accounting software or an inventory management system. Excel might be a lot more flexible, but if the usecase specific software matches your needs it can be a lot more streamlined and less error prone.
So the conclusions will very much depend on your use case. If you are trying to draw one of the standard software engineering diagrams as part of design documentation, Mermaid can be great. For less formal design diagrams or quickly visualizing the state of some algorithm it's much more even playing field.
The thing that's problematic is rendering Mermaid SVGs outside of a browser environment - i.e. what static site generators need in order to generate JS-free HTML docs from Markdown content.
If you're looking at a rendered Mermaid diagram on your screen, you probably already have the SVG in your browser's dom. You can just right click -> view source -> find element -> view as html -> save that to a file. I expect this is how the SVG export on the Mermaid live editor[0] works.
(the Mermaid live editor is great, it's where I tend to go if I want an SVG export)
I work on Scroll (https://scroll.pub), which currently compiles to HTML/TXT et cetera.
Compiling to JPG, SVG, PDF, MKV, MP4, et cetera, are high on my todo list, but I really haven't seen a standout way to do that, beyond that would run through Chromium.
I wonder if Ladybird (https://ladybird.org/) might be appropriate for that use case? Not sure if it's a new rendering engine or what.
>It is very difficult to save the images as bitmap (.jpeg, .mpng) or vector (.svg)
Huh? It's quite trivial, and even some tools for VS Code and other environments support it.
>You basically have to use a headless browser rendering toolkit, and guess what? The images aren't consistent (different rendering styles)
Is your problem saving Mermaid as images or lamenting cross browser rendering consistency?
If it's the former, why is the latter a problem? Use a single headless browser rendering toolkit and stick with it. Who said you need to use multiple and compare?
And there are other ways to do it, like exporting from an actual in-browser render, or even a VS Code extension - it can also be found in other tools based on Electron.
> A better answer: natural language is the programming language everyone knows.
And when you get into frustrating misunderstanding of details you end up using a programming language anyway. Natural languages are to ambiguous to be useful for specific things. We humans can resolve the ambiguities in our minds, or think we do, based on context. I think the anthropomorphization argument hits closer to home. I feel guilty too of projecting more meaning and intelligence to a generated text and I think I'm not the only one.
