Clarification of terms
Ambiguity of “professional behavior”
Would this work as a rule of thumb for determining if something falls within the bounds of professional behavior: “Would this be behavior I’d expect from a lawyer in a the course of providing their services?”
Clarifying compatibility of safety-critical culture
Not a part of the safety-critical culture, but familiar with cultures similar to what’s been described.
While I don’t believe that responsible behavior is incompatible with respectful implementation of the same (e.g. it’s possible to fire someone for cause, while handling the firing itself in a respectful manner), and that in most cases being courteous actually takes less energy and gets quicker results than being abrasive, how the safety-critical culture handles internal interactions isn’t terribly relevant, provided their external interactions with the broader community are respectful.
With respect to the hypothetical hiring choice, I’d probably recommend passing on both.
The fully-qualified engineer may be good, but they aren’t a god, and will eventually make a mistake. Abrasive personalities tend to correlate with ego, and even in something that’s not safety-critical, I do not want to cultivate a culture where the loudest idea wins over better ideas. An abrasive engineer is an unacceptable risk, which grows the longer they are present as the impact of their inevitable mistake grows as they accumulate responsibility and influence.
The amiable but unqualified engineer is more nuanced. Everyone starts this way, so junior engineers are almost by definition unqualified for the work we’d like them to be eventually capable of performing. They are a risk, which is mitigated by code reviews and mentoring, so if something they wrote ends up breaking stuff, they are only partially responsible.
If the engineer is mature in their career and still unqualified, I’d pass. It’s less work to continue searching for someone that’s actually qualified, than it is to get rid of someone.
Intent
Clarification of the community’s goals, values and views reg. my earlier questions.
Context
My previous questions and the answers by morgen-peschke.
Question
Thank you very much morgen-peschke, I get the impression that you have made your goals, values and views very clear. I regret to inform you and I am sorry that I get a very strong impression that you are not sincere. My question is, both to you and others more generally: Are these goals, values and views that you describe here more or less shared by the general Scala community as well as the leadership of Scala?
I’m finding this intent/context/question format much harder to read. I think it’s good to include whichever of those components are relevant to what you’re posting but I would have a much easier time reading it if instead of making it into “form fields” people would write it as regular, flowing text. (I do find the heading formatting easier to read than the parenthesized paragraph prefix formatting, at least.)
First, thank you Darja for introducing this topic! I really like the tips for how to make the conversation a productive one.
I also really like the “big tent” conceptualization of Scala that Martin laid out. It very much agrees with how I view Scala and how I use it: I want to be able to go anywhere in that tent because different places have different strengths for solving problems. And, because of the broad applicability, it has a lot to offer people with many different types of problems. By default, since open-source communities consist of people who can use each others’ work, larger is better if all else is equal. (Tradeoffs exist, but the aspiration should be inclusiveness even from a purely selfish point of view; many of us are not selfish in that way and have other reasons to also value inclusiveness.)
Because of the rather expansive nature of the topic, I would like to enunciate some principles that guide my (and, I suggest, should help guide your) thoughts on the matter.
Note: by goal-directed I don’t mean that there is a particular endpoint that everyone is seeking, but merely that we’re trying to accomplish something, not just hang out with each other; and that this something has objectively clear succcesses and failure modes. This means that we can’t just decide whatever we like because we have a constraint: we’re doing stuff that should work, and we only partly get to decide what “work” means.
In order of importance:
I am happy to discuss either these principles or applications of them to specific cases, but for now I think this is enough.
Thank you @darja , and the Scala Center team, for being open to a discussion. I see this as progress.
As some background, I have been one of the top contributors to the Scalaz 7.x series (besides Yoshida-san, the maintainer) over the last two years, which was a side effect of writing a book on Functional Programming https://leanpub.com/fpmortals
Context
From our perspective in Scalaz, nobody I have spoken to has had any interaction with the Scala Community Build team except Yoshida-san. Indeed, I have personally had nothing but amicable exchanges with Seth for the last 5 years, barring a dispute last year that we later cleared up. So we are very confused why any action has been taken to remove our projects. Being included in the community build is, however, for the benefit of the Scala Compiler Team, and not us, so we will accept that decision. If it had been proposed as “we don’t have time to maintain this” then nobody would have paid it any mind (much as pcplod was recently removed for this reason).
Hurt
Many of us are very upset by the implication that we are damaging to the community by association.
https://twitter.com/adriaanm/status/1122779796575014912
Personally, I’ve put 18 months of my own time (2 hours every night, one day at weekends, some time off coinciding with paternity leave, two full weeks of unpaid holiday leave) into writing a book as a gift to the community.
The profits were donated to development of scalafix (a Scala Center project) to benefit the Functional Programming community. Sponsorship of Vladimir for Functional Programming features · Issue #451 · scalacenter/scalafix · GitHub
I could list many other things I’ve done for the benefit of the community, including my contributions to other projects, conferences, and guidance to the Advisory Board, but that would be a distraction from the topic at hand.
Many others volunteer their time and passion to the goal of furthering Functional Programming in Scala. So I hope you can understand why so many people have reacted emotionally, and hurt, at the implication that they are “toxic”. As a solution to this particular point, I feel an apology would be in order to clear the air. In particular, I think Adriaan’s words hurt the most people when he branded “Scalaz maintainers” and “core people”. The ambiguty regarding who he was referring to (we still don’t know), has meant that we’ve all had to live with the stigma.
Many of us are not working in Scala jobs and, frankly, Adriaan’s words make it very difficult for us to ever return: and that impacts our careers and families. This is not a risk that should exist for volunteer contributors who are working to make Scala better for everybody.
Code of Conduct
Scalaz does not have a written code of conduct, but it has an ethos. That ethos is “be better”, both as humans and as engineers. CoC or no CoC, Scalaz members do not like to see ad hominems or other “not being better” behaviour of that nature.
Where we differ from the “official” Scala community, is that there are no moderators: we believe it is best that social norms and rebutals are set by peers. There are no bans, except that one time Tony was banned by a rogue admin. So if you see something in a scalaz channel that you think crosses the line of civility, speak up!
If this is not something that you are prepared to accept, then we respect your right not to engage on Scalaz channels, or to link to Scalaz from your projects, or even to read or aid in promoting my book due to its use of Scalaz (as Lightbend, EPFL, Typelevel and Scala Center chose to do). But we then kindly ask that you do not tell us how to run our community, and to refrain from speaking negatively about us through association.
You may feel that the Scalaz approach to community management doesn’t work. And I will admit that it doesn’t always work. But I have plenty of examples of where codes of conduct don’t work either.
There is no point pressing this issue. Scalaz is not going to implement the Scala Code of Conduct for its channels. But everybody can each choose to engage on other channels using whatever code they prefer. I think the diversity of community styles is actually a good thing.
Solutions
As to additional solutions to the general problems, beyond the apology that I have already requested, I have some further ideas:
Recovery Centers
As a maintainer of multiple successful projects, I have received a lot of abusive comments directed at me personally, and I’ve burnt out because of the demands on my time. But that’s not something the Scala moderation team gets involved with, because it never happens in Scala channels, and although we have “police” we have no “recovery centers” or even the knowledge with how to deal with that, increasingly common, situation. It’s something I’d like the community to consider, instead of focusing on crime and punishment.
Sentiment
How should moderators measure “negativity toward Scala”, and how much should they enforce it? I believe measurement can only be achieved by having a representative group of diverse peers who can reach consensus on a case-by-case basis. If the moderators are a tightly knit group of friends with similar demographics then it is only inevitable that a kind of “old boy’s club” will be created with strong biases and cultural misinterpretation of intent. For example, interpreting the linked thread as a “troll” when it fact it was a very upset contributor.
Inappropriate bans and public shaming are hard for a community to forgive, and alienate contributors, so erring on the side of good faith should always be preferred in my opinion. However, I understand that Scala is looking to Rust for inspiration and Rust’s founder (https://twitter.com/graydon_pub/status/1121609262134779905) has taken the opposite approach, assuming bad faith when in doubt. If Scala wishes to do it this way, I think you should make it explicit. There is no solid evidence to say which approach increases inclusion, so it’s all still a big experiment.
Empathy
I believe that overstepping a room’s rules can be handled in a non-confrontational way: contacting people privately to ask how they are doing (i.e. de-escalation with empathy), or by peers responding with “that’s not the kind of thing that makes me want to continue this discussion” (i.e. a withdrawal of interest). This is why I prefer the Scalaz approach.
In contrast, the authoritarian approach (threatening punishment / exclusion) may be cathartic for the moderators, but it generates fear and bitterness. “Wrong thinkers” (who are likely to be passionate about Scala) find themselves excluded and unwelcome, leading to tribalism and an overall negative perception of Scala in industry. I would like you to reflect upon this.
This goes both ways and anybody who disagrees with the moderators must also strive to be empathic. As Adriaan describes his own feelings on the matter (regarding private conversations that none of us are privvy to):
Attempt not to Misrepresent
Something that is very frustrating is when somebody is portrayed as having an opinion that they do not hold. For example, that everybody in Scalaz wants to remove subtyping, because one person who uses Scalaz said it once. This is false and anybody who has followed John’s work in ZIO will see that it makes great use of subtyping (he’s made cakes bake again!). If Scala is going to moderate its channels, then perhaps misrepresentation of ideas should be something that is included in the list. It is far better for everybody to understand what everybody means rather than attack straw men.
Lead by Example
According to the Scala Code of Conduct, moderators are expected to uphold the standards higher than others and can expect less leeway if they break the rules. I think it would be fitting if this was extended to anybody who is involved with an offical entity, such as Lightbend, EPFL (including students outside of Martin’s team, the perception is important), Scala Center and the SIP. I think this is quite in line with corporate codes of conduct and is also the approach being taken in the Haskell community, where community leaders (e.g. for the advisory boards) have more responsibility to be a shining example to the community: Guidelines for respectful communication
We are not trying to impose these guidelines on members of the Haskell community generally. Rather, we are adopting them for ourselves, as a signal that we seek high standards of discourse in the Haskell community, and are willing to publicly hold ourselves to that standard, in the hope that others may choose to follow suit.
thanks, it is a vary good explanation why CoC is not a silver bullet.
Intent
I think moderation should be more transparent. The main aim should be education but it should not be punishment. Even ban it is not punishment it is our lose
Suggestion
Every bad practice should have clear indicators and descriptions why it is bad or does not work. A moderation action must have a reference to that practice. So that any reasonable person will be able to improve his messages and it shouldn’t matter whether he have too altruistic or egoistic emotions.
John De Goes:
"We need to sacrifice half of the community.
Say goodbye to it.
I’m not joking!"
Without any evidence this is not constructive
Could we get a link? There’s no context here, and without this it isn’t helpful.
I could be wrong, but this also seems off-topic.
It’s a quote from a talk he gave a couple of months ago. It’s called hyperbole. See https://corecursive.com/009-throw-away-the-irrelevant-with-john-a-de-goes/ for John’s explanation of his style.
Unfortunately John was speaking in a dynamic language called EnglishScript. Its become so popular recently that people are even starting to use it on the back-end.
God help us! Anyway I’ve decompiled it
We need to sacrifice half of the community;
Say goodbye to it;
I’m not joking! ;
back to the original source code.
val unwanted: Set[ScalaCommunityMember] =
allCommunityMembers.filter(_.isUseless)
val myPropostion: EitherJ[Set[IO[Unit]]] =
Serious(unwanted.map(memb => IO(Message(memb.email, "Dear " + memb.name + " goodbye!"))))
Notes. This has been left as a Set of IOs. Allowing maximum flexibility. So you could just flatten it and perform unsafeRun on it, or you could break it up into batches. Of course you can’t examine inside the IO, but that doesn’t matter as there is no useful data inside them anyway. I have added type ascriptions that weren’t in the original just for the purpose of education. The key point is the EitherJ bi-functor.
sealed trait EitherJ[A]
Serious[A](value: A) extends EitherJ[A]
Joke[A](value: A) extends EitherJ[A]
If John had intended this as hyperbole he would have returned it as a Joke, not a Serious[Set[IO[Unit]]]. Its unfortunate that in the untyped and unsafe language EnglishScript this meaning might be obscured to those not familiar with this style of coding. As I understand it John only considers it necessary to have one bi-functor for
as he thinks we only need one IO monad.
I didn’t link to the video in the earlier post because I was wary of including effectual links. Now maybe you might want to just ignore what I say because if you call John’s “useful” function you will see I’m one of the unwanted Scala Community members. But if not I would suggest that effects really are at the very heart of this debate.
What I’m suggesting is that while querying which community members carry their weight according to the ScalaZ sub-community algorithm may be a pure function, when you do that in a public talk that is uploaded to YouTube you are engaging in IO. And in this case this effectful IO may have had the unexpected side effect of leading to ZIOs exclusion from the community build. Although as John surely knows such a proposition is excruciatingly difficult to test.
It’s more than just EnglishScript, the tone of voice can’t really be written down. Also its grammar is whatever the opposite of context free is; context is everything.
I’m not saying that I’m not bothered at all by how he made his point, but I don’t think he did anything wrong.
Also his attitude towards Dotty has become more positive since that talk.
Would it be helpful if Scala had a short agreed definition of what the design goal of the language are?
Martin’s blog informally gives a vision for the Scala language, and whilst I believe that a significant number of Scala users support this vision, I’m not sure whether everyone in the Scala community is signed up to that same vision.
To give some further background, I have some experience with another engineering community (IETF) that has to deal with similar conflict resolution between competing solutions and individuals. In the IETF context, they have several mechanisms to help try and manage competing demands. Each of the IETF “working groups” have an agreed charter of what that working group is tasked to do (e.g. IETF NETCONF Working Group Charter). For particular problem domains, sometimes RFCs are written (but perhaps not taken all the way to publication) to reach agreement on what the precise requirements are of the problem that is being solved (e.g. rfc7923 is one example).
Hence the suggestion is that it might be beneficial to have a short specification that defines the design goals of the Scala language, with opportunity for members in the Scala community to review, comment, and contribute on that overall direction.
However, there are a couple of potential risks of doing this: (1) it may cause more short term conflict between different parties, (2) it may slow the process of getting the next version of the Scala language.
Regards,
Rob
Odersky has repeatedly stated that combining functional and object oriented programming is a design goal of the language. I don’t think that needs clarification.
The problem is that some people are fundamentally opposed to half of that design goal and cannot refrain from fighting about it, yet still want to take advantage of Scala.
It may be good goal. but it is a very bad goods.
I can’t convince my colleagues to use scala with such words.
question
is there more technical vision
https://contributors.scala-lang.org/t/what-can-make-scala-more-popular/
I remember a little while ago (a few months?), some one sent a link to
a video of a talk where the conclusion was pretty much that quote. So
I’m assuming that was then Jon De Goes’ talk, though I couldn’t be
completely sure.
The talk started off going over a series of challenges Scala faces,
including a list of competitors, and ended in the conclusion that
Scala is doomed unless Scala sheds its OO features and becomes purely
functional.
I watched the talk and it was not apparent to me that it was
hyperbole. I thought he really means exactly what he said.
It could be that I’m in the minority here, as I’m slightly autistic
and therefore less good in detecting things like hyperbole.
What he said was perfectly in line with some people who used to be
very vocal and never got tired of telling every one that real
idiomatic Scala is essentially functional (“avoid vars”, “mutability
is the new goto”, etc).
I disagree with these people, but they should have the right to voice
their opinions.
I think that’s not off-topic, because that’s exactly what Scala
community is or is not about.
Lurker here. I largely agree with this.
However, I think some of this could be mitigated if Scala’s standard library supplied more of the FP workhorses by default. Currently when contrasted with ScalaZ and Cats (and now ZIO), the Scala standard library “feels” moderately OOP biased, paying lip service to the FP side of Scala. Whether this is “true” or not is a fool’s errand
This perception of the OOP bias in the Scala standard is part of where the “oppositoonal FP ideology” attitudes emerge and manifest in both passive-aggressive undermining of Scala messaging as well as the outright religiously oriented “condemnation and excommunication” behaviors seen by the most billigerant (current and former) Scala FP community members.
Psychology has a rich library of ways to evaluate and mitigate ideologically damaging attitudes and behaviors. Trying to strictly control these psychology conundrums via various communication technology approaches will miss the root cause, and just add participation costs to those who don’t fall into the ideological extremes.
This is easier said than done, e.g. see this thread about adding Traverse to the standard library: Support traverse and sequence operations on more types · Issue #10934 · scala/bug · GitHub.
When Martin started creating Scala, Generics had not been delivered to Java or C#. I’m not sure if C# 1.0 even had foreach methods. Some people may snear at foreach, but it was the first thing that got me starting to think functionally, even if I had never heard of Functional Programming. At least as far I’m aware there was nothing with early Scala, that could be remotely interpreted as a promise to provide a platform for pure, inheritance-free, lazy programming on the Jvm.
Over time Martin and his collaborators, have added more and more to Scala to support Functional Programming and ever purer Functional Programming.
We’ve seen higher-kinded types, views, improved for comprehensions, generalised implicit look-up, succinct tuple syntax, lazy values, extended case class functionality, dependant method types, macros, Value types, singleton types and improved views added to the language.
We’re looking forward to intersection / union types, type lambdas, Dependant Function Types, Algebraic Data Types, Type class derivation, inferable by-Name parameters, Opaque Type aliases, Parameter Untupling, Kind Polymorphism and multiversal type equality.
We’ve seen the dropping of Any2StringAdd. All of this supports and will support the creation of of strongly typed, pure functional code and laziness. But from a certain section of the functional Scala community, do we see any gratitude towards Martin and the other lead Scala developers for all of this? No we see continual carping, complaining, bile and spitefulness.
If anyone has a right to complain about Scala its not the Haskellators but those that want to stay close to Java, use imperative code or write in a more loosly typed dynamic style. They’re the ones that have lost procedure syntax, and Any2StringAdd. They’re the ones whose Java code may be incompatible with Scala libraries using multiversal equality or other new features.