As Kundera put it, Nobody will laugh.
It’s not about what’s possible, it’s about pragmatism. Given the more passionate factions of the Scala community, it’s much easier to get the community into two stable camps then one (maybe even three). Then once each respective group comes to a consensus of the right standard, the two (or three) standards can be combined into a single very-flexible one. Otherwise, consensus will never be reached (that’s the way it is now).
TBH, I thought that was a gentle dig at Martin Odersky, not at the OOP community
I’m far from being able to predict social dynamics. I think no one can. I do however have an innate (and naive) belief in integration rather than segregation
Firstly, Evan Czaplicki has some very good thoughts about this:
The chief lesson therin is that by itself, social-media dialogue will follow certain kinds of non-productive pathways unless it is intentionally shaped. The patterns are easily observeable here are a few:
- Anger/frustration propogates the fastest and most visibly.
- People will speak up much more often when they disagree then when they agree. Thus, a better way to get a picture of general opinion is to try multiple proposals and see where least disagreement emerges.
- Reaching affirmative consensus (i.e. “do this” vs “don’t do that”) is much easier with ultra-short surveys then a call for comments due to the low barriers to entry (i.e. one click).
It is also worth noting that how consensus is reached is frequently a function of wording nuances like the “agentive expression” of particular phrasing. For example saying “a caused b” versus “a happened after b” frequently can be the difference between massive disagreement and tacit compliance. This is known via studies of behavioral linguistics and it has quite frightening conclusions. Here’s a simple example:
The simple conclusion is that reaching any kind of consensus is frequently tricky, the mechanisms are non-trivial, and getting to the right place requires some experimentation with approach. Like many kinds of discovery processes, trial and error is required to get anywhere interesting.
Thanks for the links, which I have shared forward.
From now on, I will definitely only say, “The build broke.”
Thanks for sharing this! I found both talks very insightful.
This is an interesting talk, but I’m not quite sure how the ideas presented there contribute to the thought that we need two distinct idiomatic styles, or how do they relate to the popularity of Scala in general.
Also, as a side note, around 13:40 he speaks about how he doesn’t encounter these social conversation-related problems in “normal life”; I’m quite surprised with this, as I often encounter these type of conversions at work, and I have the presumption that a lot of people – and especially programmers – think about programmers as people who like to argue vigorously.
Unfortunately, I still haven’t found the time to watch the other talk.
The talk mentioned angry reaction as an arbitrary example of any emotional reaction which often leads to viral propagation of responses.
In the talk, it is said that creating environments where people disagree more will contribute to engagement growth, which is an incentive for our interactions to go very poorly (“mix extremes” at 36:50, and then “when i take a step back on all this” at 38:40).
I definitely agree with that, which is why I’m reluctant to create two distinct idiomatic “bibles” for Scala. In my opinion, they will further split the community – each group fanatically referring to their bible as the holy one and the other as the blasphemous one – and will degrade our communication with each other.
Instead, let’s have less “by the book” styles. Let’s declare that in fact Scala is a very agile and flexible language, and there are often no clear choices.
A good way to find more pleasant examples of emotional reactions leading to viral propagation of responses is to head on over to r/aww and dive into the comment section of pretty much anything.
It should be true only for the language’s authors.
The language’s users should have easy choice of instruments to solve tasks.
And separation of concepts and style is a good way to simplify the task.
I can see the following major idiomatic styles in data processing:
- FP +
- OOP +
- structural ±
- dsl +/-
- language injection +/-
± means, that it can be improoved.
I agree with you, there are at least five.
I think, It can help to understand each other better.
Apparently Go maintains an official “why go” page – just a collection of links to articles across the web, including a list of which companies use the language and success stories.
It could be beneficial to maintain such a list for Scala as well.
23 posts were split to a new topic: Meta-discussion on appropriate use of this forum
This thread is now very long-lived and has accumulated hundreds of posts, many of which are only nebulously related to each other. I think it’s time to retire it in favor of new, more-focused topics.
I want to quickly pick up on this as it seems to have been lost in the remaining discussion. After all, the title suggests we are talking about ways to make Scala more popular and I think eyalroth has a point there. When I talk to people about how amazing Scala is, they usually reply “uh yeah? who uses that language though / what has been built with it”. Before investing energy into learning a language it seems natural and reasonable to consider whether there will be any profits. And I think at this point, scala-lang.org does not do a good job at that. I think that this can be considered suboptimal marketing for any technology, really, as you should always sell the client using a product, not just the product.
I propose adding a section showing company’s success stories as eyalroth mentioned. Further, it should also give an overview of the most prominent scala libraries and the absolutely beautiful APIs that have been designed with it since this is an aspect where scala really shines. Even people who dislike Scala usually have to admit that, when it comes to DLSs, Scala absolutely rules due to its flexible and expressive syntax.