You don’t even need to read past the product name. Like a lot of geeks they just don’t have a clue how to sell, nor how to hire talent that can. There is no part of their branding that is not a straight disaster. (And that shoulder massage…oy.)
Look, real ballerinas are totally hardcore badass atheletes who could easily kick all our flabby nerd asses while standing on one toe, and I take my hat off to them for what they do. But how many professional software developers will really want to self-identify as “ballerinas” when discussing between themselves, never mind pitching to board rooms?
(Outside of the programmers-who-already-happily-self-identify-as-bronies subset, of course.)
Doubly so when the actual product looks as agile and graceful as a household broom.
Triply so when they can’t even do simple web pages right. (Just try the inline links on the Community page.) Or try the learn-by-example page, which spends seconds looking completely blank until some pointless Web 2.0 crap eventually loads in a perfectly static TOC.
I mean, I was prepared to overlook the marketing catastrophe just to read about their much vaunted take on structural typing (which is highly relevant to my interests), but this simple lack of technical competence means I am not going to waste any more time.
Money says the whole thing immediately sinks without trace, and none involved will ever be any the wiser why. What a pointless waste of effort.
Catchy doesn't mean marketable or hospitable. You don't/won't go out saying you love Ballerina. :P
The problem is that you should not use a widely used word for the name of your product/software/tools. It's hard for everyone who tries to get involved.
A good name IMO is Typescript if you want to compare.
To be fair, even though I don't at all agree that it is necessarily an issue, what he saids could be an issue for the other insecure brogrammers out there since it obviously is for him already
> Look, real ballerinas are totally hardcore badass atheletes
Yes.
> who could easily kick all our flabby nerd asses while standing on one toe
For the most part, no, though if both parties have to try to stand one toe during the exercise, maybe.
> But how many professional software developers will really want to self-identify as “ballerinas” when discussing between themselves, never mind pitching to board rooms?
Uh, I don't usually identify, or want to identify, as name of tool when doing any of those things, whether the tool is Python, Ruby, C#, Docker, etc. Why would my lack of desire to do so when the tool is Ballerina be differentiating?
Identifying as user-of-toolname is different than identifying as toolname (and I actually prefer to minimize the former, too: when I'm dancing—contemporary or, less often these days, ballroom/swing, not classical ballet—I don't identify as a user of a particular brand of shoe, either.)
Regarding the identity thing: programmers like collective nouns.
What do you call a bunch of google employees? Googlers (and they self-identify with that label). The same thing goes for a bunch of companies.
What do you call the people at a go meetup? Gophers. Ruby meetup? Rubyists.
There's a bunch of collective nouns. In the software community, they particularly pop up around companies we belong to, and programming languages we use.
It's about 50/50 with programming languages really. A bunch of C programmers isn't a "Unit of Eunuchs", but a bunch of python programmers are a "Plethora of Pythonists".
Rust programmers are a "Corrosion of Rustaceans, but java programmers aren't an "Orientation of Objects".
Collective nouns are somewhat random, but I assure you that when the programming language name makes it easy to create them, they will be created. Ballerina makes it very easy any of a number of collective nouns to form, and they totally would if the language took off.
I read somewhere that the name originates from the graceful and seamless movements you see in a Ballet recital. The seamless integration and interactions of components in a distributed system is likened to that of a Ballet troupe.
People nitpicking the gender of the programmer in a cartoon here is a great example of what I despise about modern tech discourse. The gender of the cartoon programmer isn't even that clear, it's so highly stylized. But I wonder if it was a woman giving another woman a massage instead, they'd be lambasted for pandering to the male fantasy of lesbianism.
Well I see a Leanan sídhe sucking some mysterious lifeforce out of the programmer while "stimulating certain areas of his brain". I don't know what to make of that.
On the upside, if it /does/ load, it's one of the stronger layouts for examples, well-annotated to introduce the concepts being explored, and not just slapping you in the face with a bunch of novel code you would struggle to interpret.
It’s a visual metaphor, the ballerina represents the language and they are supporting / comforting the programmer. I’d say its pretty corny, especially when a bunch of literal engineers need it explained to them, but it’s not just a random picture of a back rub
Intention and interpretation are different. People who have already had rough gender experiences in software might read this image differently than you.
Always happy to see another language being born, especially one that's put together like this - assuming all of it works (have not yet downloaded or played with it, this is based on reading your website)
That said:
1. This is bikeshedding, but you cannot make a statement like "diagram is the code, code is the diagram" and not show how to actually do that. The home page even has a sequence diagram. If you meant that the written code looks like a sequence diagram if you squint, then say that.
2. What makes this a Perlis language? I knew every term in the by example summary [1]. Is it annotating functions as services with metadata, or in-language support for xml/json, websockets/http2, etc? How is that different from other batteries-included languages like wolfram, for example?
3. Related: the problem with a batteries included language is that it gets bigger and bigger over time; hence the idea of "small language, large library base". What will you do with the language when its usage pivots over time - add more batteries as standard?
4. Minor: Many links to GH on the community guide page [2] end in 404s.
Here's what the spec [1] says about the sequence diagram aspect of the language: "[Ballerina's] abstractions and syntax for concurrency and network interaction have been designed so that there is a close correspondence with sequence diagrams. This enables a bidirectional mapping for any Ballerina function between its textual representation in the syntax described in this specification and its graphical representation as a sequence diagram, such that the sequence diagram fully shows the aspects of the behavior of that function that relate to concurrency and network interaction."
The two biggest things that are different about Ballerina in my view are the language abstractions for providing and consuming network services, and the correspondence with sequence diagrams.
Can you share a sample of code, its equivalent sequence diagram, and how one is converted to the other please? I see that the samples have caller->method() style code, but how is this a sequence diagram? And where's the actual bidi mapping?
To be clear: I'm not critical; its good that ballerina attempts to bridge the visualization and the implementation. I'd like to see an actual sample, though.
Edit: Never mind, found the other poster who discovered your IDE plugin that shows the sequence diagram equivalent. Not sure how this is part of the language, though.
I've never heard of this language, but it looks like a cross between TypeScript and Java. The "Why Ballerina" points on the front page are intriguing, but none of the other materials seem to fill in the next level of detail. The diagram is the code... so this is a visual language? Where are the example diagrams? The language is built so that it's easy to access a service over a network? Tell me more. Show me something beautiful, dammit. The syntax isn't pretty. And why does every new programming language these days put "getting started" instructions above the fold, but not show you code or otherwise give you something concrete to latch onto?
I'm speechless at the sheer amount of documentation and tooling that already exists. Editor plugins, a code formatter, a style guide, a build tool, a doc tool, a package manager, a package repository, a language spec, a standard library, a framework for writing services, deployment guides, and maybe 200 example programs.
I am a major TypeScript fan and former major JVM fan, and I can see the appeal of mashing them up. I think my problem is that the front page is the only interesting page on the entire site, the only one that gives me some sense of why I might care about this obscure language, let alone use it.
It doesn't. The primary reason is that VSCode cannot be hosted.
We will soon publish a playground widget which will let you run the same code in the browser so you can see source and the diagram as you wish (or not!).
I've been programming in the Julia language for the past 4.5 years, and as somebody who has lived through the problems with Julia's name (getting incessantly teased by coworkers, friends, even my wife and kids, because of how much I like the Julia language and tend to gush about my enthusiasm for it), I think @StefanKarpinski really has hit the nail on the head here.
His suggestion of "Ballet" is very good, it still conveys all of the grace, elegance and beauty of ballet. Also, ballet dancers of all genders are pretty kickass athletes as well as incredible artists and performers.
Come to think about it, maybe I shouldn't recomend them changing from "Ballerina" to "Ballet", because if I came up with a new language, "Ballet" would definitely be pretty cool, and I'd want to use it myself!
As a co-creator of a language (Julia) with a name that is feminine in most of the world, let me give some friendly advice regarding the name "Ballerina", which means "a female ballet dancer". The way you talk about Ballerina comes off rather tone deaf to gender issues. In the post linked here and elsewhere on the language website, the female ballerina—and she is definitely a she—is talked about as an object of grace and beauty to be appreciated by the programmer, who is presumed to be male. In one cartoon on the site, the male programmer is getting a massage from the helpful, friendly, female Ballerina while he does his programming work. And then there is language like this (pointed out by @yoz):
> That obviously starts with the Enterprise Integrator team as that is where this baby was flirted with, dated and then conceived
This is really damaging: the Ballerina in question is referred to as "baby", she is flirted with and then conceived—weird because that's an unusual order of events, but I guess this means you knocked her up and then had a baby with her? I can't continue, even dissecting this sentence feels creepy. Just don't do this. It's weird and disturbing and it will put off most women and many men who might otherwise consider using or contributing to your language.
Consider renaming the language to "Ballet", which is distinctly non-gendered and doesn't have these issues but still suggests the grace and beauty you are inspired by and aspiring to. Seriously, consider this. Yes, it's late in the game (post 1.0) and you like the name you have, but it's close enough to the current name that you won't lose much branding and you can keep the same nice logo that you already have.
If you are going keep the name Ballerina, you cannot sexualize the name and you should have a rule that others in the community not do so either. Julia has a specific rule in the code of conduct saying "do not sexualize the name of the project"—we didn't originally think we'd need to say that, but it turns out people just cannot resist saying creepy, sexual shit about anything they perceive to be feminine.
Thank you for your comments. Both the cartoon and the sentence you highlighted have been fixed. We want to create an environment where everybody feels welcome. Your rule about not sexualizing the name seems like an excellent idea.
Glad that feedback was useful. I know it’s not a thing to consider casually, but please do start a real discussion about changing the name to Ballet—deciding not to is a viable outcome, of course, but do have the discussion. It could save you a lot of trouble over time. Even if it seems too late, I think it’s one of those things that will seem in hindsight that it was actually very changeable at this point in time.
Ada was named after Ada Lovelace too. Many may not know that it was a woman's name (and of course few program in Ada; we certainly hope for a better outcome than that!).
I'm sorry but I cannot accept the argument that because its a feminine word its not an appropriate name for the language. Gender balance has been a problem for this industry and making it so all names are male so people won't feel bad to say they like it is ridiculous. I worked hard in WSO2 to create an open workplace for women and 30% engineers are women - so it is possible to make it better if you try hard. Isolating tech to male-only names is not the solution.
As James noted, I updated the blog I wrote (even though the words were not meant the way you presented them) to remove that offending bit. And indeed your points about incorporating "do not sexualize the name" are great and we'll put them into our terms of conduct.
There’s nothing wrong with a feminine name, just be aware of the issues. The name Ballet would avoid many of those issues outright, lessen the need to have such a rule, and seems like it might be a better name anyway—it’s shorter and phrases like “I love Ballet” and “we used Ballet” work. It’s your project, of course, it just seems a conversation worth having.
It reads to me like someone whose had to deal with a lot of this:
> —we didn't originally think we'd need to say that, but it turns out people just cannot resist saying creepy, sexual shit about anything they perceive to be feminine.
Personally speaking, I knew exactly what 90% of the comments were going to be about just from the front page. Seeing that the dev team isn't from the US explained it, but yeah, it has to be hard out there for non-US teams to submit to HN.
I can tell you don't see it, but there are a multiple aspects of the ballerina site that will offend many of the people they presumably want to engage. I assume that's unintentional. The best thing for them to do is to understand the problems, fix them, and apologize to the offended people.
Dismissing the words of the person explaining the problems and providing good advice on dealing with them is a good way to remain frustrated and fail.
> In Ballerina, every program is a sequence diagram that illustrates distributed and concurrent interactions automatically. The diagram is the code. The code is the diagram.
I'm not sure it's a feature I'm missing in current languages, but I sure am curious about this. Maybe "ballerina by example" should implement a toggle between diagram and code views?
Given the end of your quote, what's to toggle between?
(I think it means that the code does clearly enough the interactions that you don't need a separate diagram, rather than that there's built in tooling to generate one, if that's the confusion.)
There actually is a built in tool to generate a sequence diagram. The language is designed with the idea that it should be possible to generate such a diagram for every program. The tool to generate diagram is currently part of the vscode extension for ballerina. It's documented here. https://v1-0.ballerina.io/learn/tools-ides/vscode-plugin/gra...
The way I read the docs though, it sounded like you could generate code from a sequence diagram - generating a diagram from code isn't that new or unique (albeit, still a handy feature!)
If you look at GP's link, you can see that the VSCode integration (perhaps others too) allows editing either the code or the diagram, and it's propagated to the other in real time.
I'm not certain it's unique, but it's pretty neat, and I can see how designing the whole language around servicing network requests would make it easier to implement / more reliably work.
Every time a new programming language is announced, I go look at some of the example programs. This time I didn't even make it through "hello world" as I can't read the grey on very slightly lighter grey code.
Please, if the makers are reading this, just make it look like it does in your editor, when you're reading and writing it.
And then please add quick sample syntax example on the front page as well as an example video of what you mean by the sequence diagram is the code which if I understand correctly is the languages main differentiator.
Also the comments. They are unnecessary in many places in the examples and distracting. It’s obvious that the piece of code is “return string to caller”. The comment is just noise.
I played with Ballerina about 6 months ago. I wasn't able to sell it to my team, but I was extremely impressed. Type safety, brilliant Kubernetes deployment, and a very rich API for integration tasks made it appealing for 'glue code'.
If you're considering spending 5 mins to write a comment on why we don't need this language, please consider spending that time with their examples page instead. Its pretty impressive in breadth and depth.
I do think that the whole diagram bit is noise, and I could never really get it to work as expected in VScode. Its just a solid language for service development.
Visual programming languages are great in concept until you actually start using them. Luna-lang, for example, promises so much but severely lacks in delivery. This claims to convert sequence diagrams to code, but is it really production quality? If not, is this purely for prototyping? Not that that's a bad thing. Honestly, these claims are all starting to sound very repetitive.
SCADE provides textual and graphical views that are synchronized and it's widely used in industrial critical embedded software such as airplane in airbus.
Disclaimer: Huge personal hunch, might be down-voted to hell for writing this...
I think that languages like this don't go mainstream because people like/want to write code, and anything that does not help to actually write code is seen as an hindrance. The main feedback I've heard about this kind of tool is "it's clunky, it's a pain to write code with". Guess what ? It's a good thing IMO.
For this to go mainstream, the whole software industry would have to go through a major revolution by shifting its focus from "writing code" to "deliver a working product". We should acknowledge that "writing code" is one tool among others, and may be not even the primary one (I personally think that specification engineering is the most important one).
In the field of critical embedded software, this has happened that's why it took off.
Another clue of that is for instance the Event-B/Atelier B that is intensively used in the railway/metro world (Paris line 14 was made with it, 2 bugs found in 15 years). While doing B, you get a broad specification you refine along the way into smaller problems. Writing code is actually the last step you do, when you are sure that all pieces fit together.
Learning how to write code isn't a significant barrier. It's just pressing buttons on a keyboard. Logical thinking and problem solving are far more important. Switching to a visual language doesn't actually help you with that. Worse, if clicking virtual buttons with a mouse is slower than pressing physical buttons you will waste mental capacity that could have been used for problem solving and logical thinking.
Logical thinking and problem solving can greatly benefit from visual representations and feedback. I write code but I often wish the representation was much more visual than lines of dense monospaced text with a little bit of colour. Diagrams are often easier to parse and reason about. When trying to understand difficult code or figuring out a difficult problem before writing code I generally draw diagrams with pen and paper. These diagrams are much closer to my mental model than code, and I wish that a lot more of this translation could be automated.
"Visual language" doesn't have to mean low-bandwidth interactions.
It seems to me that when creating a visual programming language for a particular class of programs, you probably find that making this translator is the same hard mental work that would let you make a text-based programming language instead. Once you have a good mapping from thoughts to code, the visual part doesn't add much. I was talking to a non-programmer recently who had tried Scratch and gotten tired of the visual layer very quickly. It's rare to see a visual -> code mapping that retains value after you've used it the first time, i.e. value beyond teaching.
I like the general idea of going the other direction, from code to diagram. I'm not interested in editing the diagram, but it's great for reading the code and sanity checking. But it doesn't have to be the actual code. A great many projects would benefit from having a GraphViz generator instead of hundreds of printlns. I was talking today about adding a GraphViz .dot visualisation to the salsa-rs incremental computation database, because I was reading the documentation on garbage collection and just wanted to see it in action. I know the rustc folks have been doing this for ages.
I think in addition to generating graphviz, it would be cool to have a log viewer that can render it.
$ my-program
normal logs
viz:"digraph {\n0 -> 1..."
more normal logs
^C
$ my-program | logviz
normal logs
more normal logs
... and a window pops up that animates changes between each graph that appears in the logs. Or even better, a tool that takes regular printlns of edges, nodes, etc, interprets them as an append-only variant (with deletion, etc) of graphviz, and assembles them into a graphical representation that changes on the fly. So you don't need to have a graph implementation in every language you want to do it with.
> Once you have a good mapping from thoughts to code, the visual part doesn't add much.
Having the visual representation readily available is indeed "great for reading the code and sanity checking". Writing code (here meaning text or visual) involves reading code, both the code you're currently writing and anything that is connected to it. Thus the visual representation is also good for writing code.
I'm not advocating a low bandwidth interaction model. I can certainly see why some people might quickly grow tired of Scratch, but I'd argue that's a problem with the specific language/editor, not something that is universally applicable to anything that tries to go beyond "text". Structured editors can beat text editors in interaction speed.
Then I'm struggling to understand the value proposition. If I did want to stick to implementing it visually through sequence diagrams, can I implement all the examples through a sequence diagram and have it run on Ballerina? Really curious. If yes, I'd really like to try it. There are no instructions/examples on doing that.
EDIT: I found a link to using the graphical editor in the comments here.
Like other WSO2 stuff, Ballerina suffers from too many almost complete features.
As I see it, they can hire dozens of coders in Sri Lanka, but don't have a good product management team that can turn a 95% complete feature into a market-ready one.
I'm the founder of WSO2. I'm from Sri Lanka. We have 100s of coders from Sri Lanka (not dozens). I'm the creator of Ballerina. I'm now its product manager.
Ballerina is in its first GA release. Please elaborate on what features you see as "almost complete"?
And regards to your comment about WSO2's inability to produce market-ready products, we have 500+ customers from all over the world for our products. What do we need to become "market-ready"?
Well, I just took a cursory glance at the documentation. Ballerina looks like it would be perfect for a data processing pipeline we run, I thought I could try it out for prototyping a new processing step, and see how I liked it.
This first use-case I could think of involves XML processing. You have "native" xml types. Neat.
After reading the language spec, all the xml examples, and the documentation for the 'xml' and 'xmlutils' module, I have no idea how to read in a xml file and get an 'xml' value from it. I also don't know how to extract a record type from some XML, except by writing a manual mapper from the DOM node to the record.
The actual methods available on the 'xml' type seems kind of unfamiliar, even after working with XML in a lot of different languages. 'getName' and 'getElementName' seems to do the same thing for elements. For some reason. To determine the type of a node, you call 'getItemType'. But 'getItemType' does not document what happens with CDATA sections, document elements or document type elements. Why re-invent the wheel? what's wrong with getNodeName and getNodeType?
The 'slice' method is really weird. It expects numeric child indexes. I mean, you sometimes know the document order of the stuff you're working with, but that's not really XML-ish.
It looks like there's a lot of amazing work put into Ballerina, but I don't think I'll use it for this prototype.
I've been to several dozen technology conferences the past two years and these folks show up with a fancy large booth and nice swag and I'm simply amazed at the presentation and effort they've put into this undertaking.
My understanding is that the primary motivation all of this is consultancy work in India.
I'm the founder of WSO2 which developed Ballerina. Also the person who started the project and lead it.
WSO2 is an enterprise software product company with 500+ customers in 70+ countries and 600 employees globally.
We promoted Ballerina like that because we are proud of the work we do and wanted to show it off to people. You may not like the work we produce but trying to say its to get "consultancy work in India" is rather racist.
> I'm the founder of WSO2 which developed Ballerina. Also the person who started the project and lead it.
Congrats and thank you!
> We promoted Ballerina like that because we are proud of the work we do and wanted to show it off to people.
And rightly proud!
> You may not like the work we produce but trying to say its to get "consultancy work in India" is rather racist.
Saying it's to get "consultancy work in India" might be wrong (you promote Ballerina because you're proud of your work), but I fail to see how it's racist. Even if it was true, it wouldn't be racist.
They do, this is why I would never bring a consultant on board who suggests a new language could solve the problems. Everybody loves it but after the easy 90% are done I am stuck with a niche language.
Thus, I am not sure that this marketing does not backfire.
That is often true that one of the consultant I had could focus on solving some gaps and the overhead is too high.
One of the primary reasons, we need a general purpose programming language focused on both "better developer experience" and "flexibility" that would cover almost all ecosystems.
I've had my eye on this for a while, it looks great! Co-designed by James Clarke (of SGML, DSSSL, and XML fame) and it uses XML as a built in native data type.
I don't do cloud stuff but I can't wait to give this a spin and see if there's any way I can use it to my benefit.
The absence of meaningful code samples on the front page, and the request that I install software on my computer to try a few lines of code, makes me highly doubt the future of this endeavour, outside of academia.
> Be conservative in what you send, be liberal in what you accept.
This is now widely considered a terrible idea because it encourages software that doesn't conform to specifications, e.g. HTML's "quirks mode". https://i.stack.imgur.com/teQdv.png
Liberal ≠ Malformed; an atrociously common misconception amongst atrociously common code.
The modern Web is the product of people who have so deeply and comprehensively misinterpreted and misunderstood every single facet that they are Not Even Wrong; then standardized, ratified, and protelyzed their own utter brokenness as The Right Way To Do It, and congratulated themselves on this marvellous job they have done.
I can’t say much about the language, but I think the image at the bottom is somewhat inappropriate. Why is there a woman massaging a man while he uses a computer? I understand that this is to illustrate comfort, but this is not an appropriate way to illustrate that
In an entirely neutral culture it'd be fine. In a culture that says that women aren't programmers, it perpetuates a common narrative that women are for display and support but not for real work. It's not helped by the picture above it where the ballerina is pictured with batteries.
Taken all together it seems to suggest that women are objects and that this is a product for men.
Yes, we're all being hyper sensitive about it, and it's likely that nothing negative was intended but it's something that we could do with having a bit of sensitivity about, given that it costs us so little and our current level of sensitivity has made the culture so hostile to women.
Jesus, that's my definition of oversensitivity. Literally everything, no matter how minor or insignificant gets turned into "this is driving women out of the industry".
It's surely not literally driving women from the industry, but it does make the product look outdated and the team behind it look insensitive.
It's like doing a presentation with a prominent stain on your shirt: ideally the audience should be able to separate appearances from content, but the reality is that they can't.
Agree. I mean come on, then we could say the same about the ballerina pictured being a woman is driving man out of the ballerina industry. Stop being oversensitive about such minor things.
I want to live in a society where there is no outcry over a chosen photo motive at all whether I want to picture a woman massaging a man or vice versa. Just let me choose the motive for a photo the way I think it fits.
> we could say the same about the ballerina pictured being a woman is driving man out of the ballerina industry
Maybe it is, I've got no problem if someone wants to make that argument. I don't know much about the Ballet world, so it's not something I'm going to raise myself.
On the other hand I've got personal experience of talking to a young girl who was trying to understand gender roles and if it was acceptable for a girl to be interested in space or computers because of things people had said to her at school. If she'd been looking at webpages with these kinds of pictures, I'm sure they would have had an effect.
> Stop being oversensitive about such minor things
At some point the regress of people getting annoyed about other people getting annoyed becomes ridiculous. I'm not spending time in a state of rage about this, and you don't need to be in a state of rage about my opinions about this either.
> I want to live in a society where there is no outcry over a chosen photo
And I want to live in a society where people understand that communication involves two sides, and that if your speech / picture selection makes a significant number of people think you're sexist and you aren't then maybe you should improve how you communicate.
Unlike rain and wet roads, it’s not a one-way cause and effect. Skewed representation makes sexist stereotypes more likely, and sexist stereotypes contribute to more skewed representation. To break a vicious cycle we need to be sensitive to the things that feed it.
You are simply asserting that "sexist stereotypes contribute to more skewed representation", which is no better than asserting that wet roads cause rain.
First, there is nowadays strong evidence that people generally do not hold explicitly sexist views. So the fact that people know that there are, for example, fewer female software engineers does not mean that they think women are incapable of being software engineers. Knowing that there are fewer female software engineers and therefore a software engineer you encounter is more likely to be male is not sexist, it is simple knowledge of the facts.
So what about "implicit bias"? Well, the poster child for implicit biases, the Implicit Association Test, is actually highly dubious, as results (a) are highly inconsistent [the same person will get wildly different scores on different instances of the test] (b) quite weak and a bit different than reported and (c) do not predict biased behaviour.
What do I mean with "a bit different than reported"? IIRC, it was reported that the IAT showed men being biased against women. Which was a bit of mischaracterisation: for male subjects, there was no difference in "bias" for/against women or men, but women had a positive bias towards other women. So there was a difference, but not quite what was reported. (This in-group bias was also discovered in a different study).
Finally, what about the backwards causality? Let's take Stereotype Threat. Results were always weak and somewhat questionable, and basically crumbled in the replication crisis, the effect disappearing when controlling for publication bias.
I'm sure hundreds of women won't go into STEM, now that this one new language has a picture of a ballerina with batteries giving a massage to some dude with a laptop.
Maybe they should illustrate her putting batteries in a vibrator, so she can go fuck herself, just like you should.
There is controversy about literally this exact thing in China's software culture[1].
> Jesus, have become so sensitive to everything?
What you call "being so sensitive" can also just mean that people are being considerate. The people suggesting the photo is inappropriate are not "triggered" or "offended" or whatever. They just seem to understand that the photo evokes real cultural problems and can easily be changed.
Why do you seem to be so offended on behalf of the picture?
I browse with JavaScript off, and I can't scroll on that site. Could you degrade it more gracefully, please? It's a documentation site, after all, not something that should be design heavy.
Examples are there to teach how stuff works, you can't be a programmer by copy-pasting everything. Read. learn and do it yourself. Maybe you can push it to Ballerina central as a library :)
> That obviously starts with the Enterprise Integrator team as that is where this baby was flirted with, dated and then conceived;
This is what happens when people think that coding is hard but writing is easy.
WSO2: Please, on behalf of innocent eyeball-owners everywhere, hire a dedicated content editor.