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.
1 Like
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.
2 Likes
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.
2 Likes
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
3 Likes
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.
7 Likes
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/
1 Like
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.
2 Likes
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.
2 Likes
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.
6 Likes
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.
11 Likes
So it seems the debate is turning towards FP vs. OOP, or FP vs. imperative programming, or similar. I find that a curious divide. John De Goes seemed to me, at least on the surface, not to have anything against specific persons or communities, but found Scala great and feared for its survival and future and sought desperate solutions - though I do not know whether he was sincere or if he had ulterior motives and plans and/or other.
My 2 cents on that topic is that I hope that Java, Kotlin and possibly Haskell will serve me well in the future. The Java and Kotlin language developers, organizations and communities has learned a lot and been greatly inspired by Scala on a considerable number of aspects, including in newer and planned versions, though Scala is still, arguably, much (, much) further “ahead” in some regards (similar abstractions and features to case classes as well as pattern matching have been discussed and investigated by Brian Goetz and others reg. future versions of Java). I would imagine that the same kind of inspiration from Scala goes, albeit likely to a smaller degree, for Haskell, for better or worse for Haskell.
Well said @RichType, seconded. If there is any reason for me (privately) to be careful and take time responding on the continuation of the thread that brought me to this forum; its my appreciation of what Martin and his Scala community have given me. All of what you stated 6 days ago.
1 Like
the new Scala Center advisory board minutes include a summary of a discussion about community and moderation; see https://scala.epfl.ch/minutes/2019/06/19/june-19-2019.html
3 Likes
We are in the process of deciding whether we are taking Scala for our next family of projects. I’ve come here from a discussion on Reddit, John’s original post, and eventually the original Discord discussion linked at the top of this thread. To say the least, as outsiders, we are quite disturbed by the situation your community has experienced. On the other hand, there is nothing special. As end users of the contributors’ work, we are, however, mostly interested in stability, predictability, and performance, under the going concern, as we are heavily investing in the platform of our choice and make our merits depend thereupon, whence we strive for a clear picture of the state of the tools that we choose.
I’m aware that every community undergoes changes. We have almost settled for ScalaZ as part of our toolchain — until we’ve learned about this situation. This is very unfortunate, as we’ve been very satisfied with Scala overall and had invested in training.
To us, the perception of an attempt of a forcible deprecation, as called for by some and outlined by another community members, of a showcase piece of advanced software, based solely on personal issues certainly raises red flags. It has become apparent to us, maybe a bit too late in the game, that this is a significant risk factor.
We have thus adjusted our methods of evaluation of the merits of a platform to closer evaluate its social component, as a community’s behavior may become detrimental to our merits. We are ultimately interested in predictability of our choices regarding the pieces of our infrastructure.
As it stands, we need to re-evaluate our choices.
I hope this is the right place to ask. We are asking only because we already have made our basic initial investment into the Scala infrastructure and now have arrived at the crossroads where we need to decide whether we step in or out.
We certainly understand that a community having reached a certain scale cannot escape personal conflicts, which we believe should be attempted to be made beneficial, eventually. At face value, the issue seems to revolve around developers’ personal attitudes. This is beyond our scope of involvement, and, as it stands, will remain so.
Some participants advise that end-users simply choose cats over scalaz. We do not believe that this is an appropriate resolution, as this incurs immediate costs and unknown risks to users of scalaz.
As users, we deeply appreciate the marvelous efforts made by all contributing parties. The results of their work have convinced us to go with Scala. And we greatly enjoy the amalgamation of OOP with FP that has been achieved in Scala, to a great extent due to the ScalaZ and Cats libraries.
Requirements that we must satisfy, however, demand going-concern clarity, i.e., that neither component that we depend upon liquidates.
We are trying to estimate the risks of, say, cats undergoing the same procedure. For us, ScalaZ and Cats complement Scala’s native FP facilities, and we need them to meet our domain model requirements.
So now, seven months after the discussion seems to have concluded, would someone please attempt to objectively clarify
- what the state of affairs about ScalaZ is,
- and whether your community believes that such attitude toward other established libraries could resurface?
I hope our concerns are admissible within your CoC.
1 Like
It’s just the nature of life that controversial things happen. Oracle took over Sun, people thought that Java will die and evil Oracle will exploit Java programmers to the maximum. In reality Java lives to this day, it’s still free, Oracle delivered lambdas, modularity, GraalVM and other major improvements to Java platform. Python lost Guido over PEP 572: https://lwn.net/Articles/759654/ Python didn’t die. Instead it quickly gains popularity and it’s possible that within few years there will be more people knowing how to program Python than people knowing how to program Java {if that’s not already the case}.
There’s a Polish saying “nie znam się to się wypowiem” meaning “I don’t understand thing well, but I’ll speak nonetheless”. I don’t use scalaz, but from what I know:
- two guys that were prominent in scalaz were attacked the most: Tony Morris and John de Goes
- Tony Morris had foul language and lot of hidden power over scalaz. He left Scala for Haskell as did some other scalaz contributors. Such thing happened even long before the drama. Martin Odersky said “Scala is a gateway drug to Haskell”.
- John de Goes invited some person/ people {I forgot how many} to conference that were doxxxed and found to be “too right wing”. To stop controversy John left scalaz and created separate project called zio. zio and its modules implement lots of thing that were planned for scalaz 8. scalaz 8 effort was effectively abandoned and now scalaz 7.x is maintained by Kenji Yoshida and contributors {it seems}.
- zio is compatible with both cats and scalaz {and also monix and many others}, so if you don’t have any problem with who John de Goes is then you can freely use zio and integrate it with your existing code.
- now the best person to ask about scalaz future is probably Mr @xuwei-k .
3 Likes
Thanks for your reply. We are familiar with the cases that you mention and the history of the issue subject of this thread. Your reply however does not answer either of our questions but rather recapitulates the story. This is nonetheless appreciated! And thank you for the reference to Kenji Yoshida. I hope he will find time to reply too, though this seems unlikely.
We have no concerns with any of the persons involved therein, as we are not familiar with them in person. The personal exchange that was referred in the threads and posts is insufficient for us to draw any conclusions. We also do not care about affiliations whatsoever, as this is a personal choice and we are not in any position to draw reliable inference on it.
What we, however, need to know and can so far not estimate satisfactorily is the effect of removing ScalaZ from community builds: would it reduce the reliability of our builds?
The issue seems to have hit the ScalaZ team quite hard. This is very unfortunate for us as users, too. In our opinion, this event has significantly reduced the merits of the FP side of Scala.
We ultimately strive for a clear-cut picture to evaluate the situation objectively.
We have been eyeing Scala 3 and have begun with our first experiments using Dotty. We do however enjoy modeling with existential types, and use dependent types. Some things would need to be adapted. But we have a reliable subset of code that does not require advanced type theoretic features.
Our domain model is functional, and is best expressed this way. Martin is a great person, and one of us is in fact from Lausanne, which is not supposed to imply anything.
We do use Haskell too. It does have certain weak spots too, unfortunately. If it didn’t, we wouldn’t have to look around.
I’ve noticed among several members of the Scala community a generally negative sentiment toward Haskell users. We do acknowledge and respect it as a personal opinion that must be rooted in negative experience that might have been left unabated. But I would regardless ask such users to not ignore our request for clarification solely on this basis and to reply nonetheless.
Thanks again for your reply, Piotr.
There’s no apparent reason to believe so. The community build is mainly intended as large-scale compiler regression test suite, nothing more (which seems to have been largely overlooked or ignored by many people in the brouhaha). Scalaz and Cats are similar enough that, as far as I know, they tend to hit most of the same functionality. So far, I haven’t seen any reason to believe that anything is actually lost here, aside from face and politics.
Hmm. While I can believe that’s true of “several”, it certainly doesn’t strike me as typical. Among the Scala hardcore, I’ve observed a great deal of respect for Haskell. (Indeed, Scala often pays Haskell the ultimate compliment, of stealing most of its best ideas. Which then get stolen by all of the other programming languages – the programming circle of life.)
While there are folks who get religious and factional about any programming language, and Scala is no exception, I would say that there is significant respect and cross-pollination between Haskell and Scala. (And for that matter, Rust.)
5 Likes
The cats / scalaz split was largely an internal matter inside the scalaz community, 6 ish years ago IIRC.
I dont think this is the right place to go into it in great detail. The scala community is vastly more broad than those two projects.
As a fly on the wall (not someone important here or there), I can only say I have witnessed some personal bridges burned, such that certain people no longer wish to interact with each other for understandable reasons.
In my not so important opinion, anything else related to the ‘status’ of some projects that are not under the control of anyone here seems off topic. There is no third party project entitled to special status.
2 Likes
Emphatically no.
It will not reduce the reliability of anyone’s build. Not ScalaZ’s build, not yours, not any other project that isn’t now or will not be later part of the so-called “community build”, which has in fact nothing to do with the community, and is instead an extended test suite for the compiler team. There are countless projects that were never part of the community build, and which are very very stable.
“Politically” speaking, perhaps. Technologically speaking, not in the slightest.
8 Likes
Ok, I’ll bite one more time after reading this again. I am not a member of scalaz, cats, typelevel etc. I have my biases, but do not represent any of the parties in this dispute in any way.
From a technical perspective, Scalaz was not “hit hard”. It was not even hit.
The scalaz community presented exactly 0 technical reasons for inclusion in the community build. The complaints regarding removal from the build were all emotional and political. There were insinuations that being part of this build was some sort of implicit approval of a project by the authors of Scala (its not; it is not a marketing tool), and removal was seen as some sort of slap in the face. There seem to have been many people who misunderstood what the community build is, and how it is maintained, and came to false conclusions about the technical impact of the change. One commit message hurt some feelings, and politics from 10 years ago resurfaced.
Read the whole discussion yourself, keeping in mind what the community build is and what it is not.
The community build is a regression suite maintained by the compiler team to test compiler changes against a sample of open source projects. Its very useful, but high maintenance. Naturally, to test project X you also have to compile its dependencies, so many lower level projects are included even if they are redundant. Merit for inclusion is a balance between cost of maintenance, and likelihood that inclusion tickles some corner of the language that other projects did not.
Separate out the emotional appeals and politics from the pure technical aspects of the change and judge for yourself.
Scalaz has some fantastically capable contributors. They could fairly easily replicate the community build on their side by setting up a CI environment that tested the most recent scala compiler commits against their code base. If this started turning up bugs that the community build did not, it could be used, in part, to build a case for inclusion.
On the other hand, the project can do like most leading edge projects do and test against the Scala milestones and RC releases, which is more than sufficient to ensure the sort of bugs the regression suite can catch are noticed before a final Scala release.
3 Likes