Aha, then I did not understand your initial statement correctly. I most certainly agree that this approach is preferable and that it’s quite the consensus.
I don’t know if I like Scala because it’s a “better Java”; I’m not even sure that I see it that way. I do, however, believe that it’s one of the major advantages that the language has - the ability to (almost) seamlessly use Java’s SDK, libraries and tools.
I’m not sure it’s an orthogonal issue. First, the richness of the language might not come without a cost, but that cost can be mitigated, as is being done with Dotty. Second, there is always the option to give up on expensive features that are not so popular.
Type-safety is hardly a unique feature for Scala. That’s one of the most common characteristics among programming languages. However, I do believe it has a unique combination of these characteristics:
I like your questions. Of course I have no answer for these in general.
But for me personally:
I can see one general area for scala. It is fast reliable data processing.
Because this area requires custom types for each sub domain areas and big performance.
IMHO:The ability to comfortably use custom types with standard libraries without performance overhead is the most powerful feature of scala which is absent in other languages which I have known.
create custom types
I do not like types from external sources because they lead to orphan tasks which have no good decision.
intergrate custom types with external scala libraries
decorate jvm libraries which you often need.
enjoy scala
May be there are different ways. But I do not know area where I will choose scala when I do not need custom types. It seems I will prefer java or kotlin where standard jvm types are enough.
Scala has beautiful string interpolation but I do not prefer plain jvm types in the areas where it is really a very important feature for me.
val guid = g"1322030"
for(v <-SQL"""select id from table t where t.guid= ${guid}
""".as(nStr("id").*).sortBy(_.desc) if v.isNotNull){
...
}
Try to get FP101 / Structure & Interpretation to be taught in Scala at US CS curricula.
Students almost universally despise Sceme, and Lisp with a passion (arguably also Haskell). It’s for a reason, these languages are very, very impractical. Students should be taught how FP gives value on top of OOP, not instead of it. Scala can do that beautifully!
Emphasize simple features with lots of value: For-comprehensions, Pattern-matching and Case Class ADTs.
One single idiomatic style wouldn’t work so make two. Make an FP-Idiomatic style and an OOP-Idiomatic style. (Or call it FP-Pure-Idiom and OOP-Friendly-Idiom). That should be possible.
Uhh, why wouldn’t it work? That’s one of the best things about Scala - its idiomatic style isn’t all that strict and allows for variations of new cross-paradigm designs. Not everything has to be considered “idiomatic”, some can still be just “good practice”.
Although I love the joke, I think that’s an example of one of the things that make Scala less popular - a somewhat snob and elitist approach towards anyone who’s not fully embracing FP.
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).
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.
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.
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.
