Hmm. That’s an interesting assertion - it’s true that many languages are mutable, but I don’t know that there is much evidence that they are popular specifically because of mutability. I’d say that they are popular because they are easy. Which may be somewhat related (since most people learn mutable styles first, it’s easier for them to pick up), but isn’t the same thing …
2 Likes
Sorry, I have not said that popularity of any language depends on mutability, or simplicity. I think it is not the main point.
But I cannot imagine popular procedural language without mutability also 
To say the truth I think the joke was around the words:
I sure that immutability of scala is butifull thing. But I think it will not good if it is the only killer feature. And if a procedural language does not have comfortable mutability it is not very good. I really like calling card like if you need big data processing the scala is for you. You will get mutability, immutability, object, fast record,macros. All what you need to quickly make fast reliable business app of any scale. I think it is more business oriented approach. 
1 Like
Making a language that is a kitchen sink of syntax features is not business friendly, I think. Look at C++ - it has everything and even more things are coming in next editions! You can write low-level code, high-level code, OOP code, functional code and even dysfunctional code. Only the last aspect was implemented properly :] How does C++ fare? Its significance diminishes. Less and less people want to deal with the absurdity of language complexity. Therefore we need to constraint the choices somewhat.
Scala community is already divided between two high-level programmers groups - pure FP ones and mixed OOP+FP ones. Adding low-level imperative coding lovers as a third group would mean even more division inside of Scala community. Do we want that? I don’t.
Big data, AI. machine learning and a lot of latest hot stuff (no matter how much sense it makes) is implemented in Python, which is a really slow language if you go through the route of writing pure Python code. If you want acceptable performance you need to find C libraries and write glue code in Python instead of writing real algorithms in Python. Scala is already much better than Python, performance wise.
Scala has mutability and will keep it. It’s just that mutability is second-class concern. Most of the time you should stick to functional programming.
Scala was never meant to be “better Java” (whatever that means). It’s not hard to find what Scala goals are. Look at Scala’s front page https://www.scala-lang.org/ :
There’s nothing about crazy mutations and low-level code. In fact it’s totally the opposite. Scroll down for “Online Courses” - you’ll see introduction to functional programming in Scala (totally non-imperative programming). Look at Scala conferences agendas - they are full of functional solutions to programming problems. It’s not surprising that when people hear “Scala” they think “functional programming on JVM” and not “extra sugar for Javaisms”.
In fact, if you look for “better Java” then two languages come to mind (three if you consider future Java to be another language than today’s Java):
- C# which is touted as “Java done right” by C# programmers (that’s probably half-trolling, half-taking-pride) - C# wins the race of having the most keywords in a programming language
- Kotlin which is designed to have a smooth learning curve for Java programmers and low friction integration with Java libraries and frameworks
- Java itself is also developing, there are lambdas in Java 8, type inference (vars) in Java 10, future plans include pattern matching and data classes (counterpart of case classes)
So the competition is already tough. Scala is rather problematic if you compare it to the languages above. Scala breaks binary compatibility between versions (i.e. every two years or even more often), still has relatively slow compilation speed, has incompatible collections (so many frameworks and magical reflection-based libraries need special support for Scala). It would be hard to sell Scala as Java with extra syntactic sugar given these disadvantages.
Also, it seems to me it would be easier and more sensible to port the few Scala features you like to Kotlin than port the many Kotlin features you like to Scala. It’s really weird that you want to make Scala a Kotlin clone instead of just moving from Scala to Kotlin.
4 Likes
It is very doubtful analogy. It seems that its because of my words. But I can not see any connection. I like holy wars about c VS c++ but here is forum about scala… And I can repeat it for most other statement. I can make symmetric answer at least
Let me answer in same manner. I’ll be brief.
- I feel tendency to isolation in last message.
It seems there is nothing good in the sacrifice some language feature because of beautiful words.
If C++ is not an acceptable example then maybe Perl? Anyway, Scala should learn from mistakes of other languages. As the famous saying goes: “Those who cannot remember the past are condemned to repeat it.”
If something is added then removing it is problematic. That’s why most programming languages evolve rather slowly. Otherwise you end up with bloated language. Another example of such thing is C# - it has plenty of keywords and small language features. Even C# fanboys are complaining already that the language is too complex for too little gain.
In the end it seems that either there are people who complain loudly that there are too few features or there are people who complain that there are too many features in a programming language (so they choose simpler ones instead). There’s no silver bullet to that. You can never create a language that you can sell to everyone at the same time.
2 Likes
It is very beautiful words until sombody say it to you…
See also:
https://www.scala-lang.org/blog/2019/05/02/community.html
I like such philosophi. there is something kind there.
AFAIR this is a response to a drama which caused some threads here to be closed. Do you want this thread to be closed too?
No I do not. It seems we are in different camps. Where you see disadvantages I see opportunities.
Martin’s words.
I see this difference of approaches as a big opportunity. There are so many great ideas to debate and opportunities to learn from each other!
1 Like
The next line after your quote is key:
Lots of these ideas feed into the design of Scala 3, with the overall goal to make Scala’s integration of paradigms even tighter than it is now, as well as making it simpler and safer.
While discussing stuff like adding syntax to ease working with mutable data certainly shouldn’t be banned, not everything is going to be adopted.
The SIP process is the primary filter, as far as I understand it, but I’d be really surprised if the support for the kinds of additional features you’re advocating make it in, as rampant mutable state doesn’t really tend to go hand-in-hand with safety and simplicity.
1 Like
This is a very General statement. I think it would be better to use more constructive arguments, you can give a reference to the feature at least. I agree with all your words in general completely. But to tell the truth I disagree with micro aggression and provocation to holywar.
1 Like
Go to the front page of Scala, scroll down to Online Courses, you’ll see many courses about functional programming, some of them directly from Martin Odersky where he asserts that functional code is easier to reason about than mutability oriented one. No wonder why Scala usually makes it more convenient to write functional code than imperative one.
1 Like
I write many mutable code in scala. I had only one problem with immutability it is collection architecture which requires time to accustom.
I can understand your love to immutability. But Language is a tool for me. I have to use many languages. A love to some idea is very big luxury for me (
Is there anything stopping you from e.g. mixing Kotlin with Scala? Take Apache Spark for example: it has APIs for Java, Scala, Python and R. I bet you can use Kotlin with it without pain. Choose the right tool.
2 Likes
It is an interesting topic for me, how to make language X more popular—this case X=Scala. One problem is that beginners find certain things difficult. These beginners either abandon the language or start understanding the things, in which case they cease being difficult. In either case the difficulty of learning is forgotten.
Is a complaint by a novice that “thing Y is difficult to understand” an important comment? I suspect there is underestimated value is such statements.
I keep saying that I want to create an article about things I think are difficult in Scala based on my personal learning curve. But doing this is really hard. And also, I don’t really know how to present or position such an article to maximize its benefit. E.g., I made a proposal for such a talk at a recent Scala conference, and it was sadly 
rejected without any comment.
1 Like
Of course it is. language injection is very interesting theme.
Thank you. I just believe your words.
@tarsa, I’ve often wondered whether it is valuable to mix Scala and Clojure. As they are both functional, my guess is that parts of your implementation which are easier to write without worrying about types, you could do in Clojure, and parts where you want code to be statically typed, or where you need tail recursion, you could use Scala. My experience, however, is that programmers who have used both languages usually love one using one and hate using the other. Which one is loved and which one is hated depends on the person.
Naively looking at it, it seems the Scala rigid dependence on the maven directory structure for projects makes interfacing with Clojure pretty difficult. Maybe I’m wrong.
The landscape changed quite a bit with Google officially(?) backing Kotlin and Kotlin’s popularity skyrocketing as a result. I think Kotlin is a great “better java”. I think Scala has the potential to be its own thing and a better language instead and that trying to be a better Java in the current landscape is a loosing fight anyway.
Now, I guess these real life concerns have to be contrasted with the fact that a “better Java” will always have an easier time to get Java devs converted. So long as there is a decently sized and preferably growing community of companies and devs using idiomatic Scala I think it’s fine to accept that Scala is never going to be the dominant alternative language on the JVM, given the obvious non-technical advantages of competitors.
If someone would like a “better Java” they’d very likely see a lot of Scala’s distinguishing features as unneeded complexity and would go With Kotlin.
2 Likes
I do not know the aim why you quoted my words. I just add not to abuse context. I disagree that scala should be more worse than java in processing big data or procedural approach.
I think it’s quite important – but also quite easy to misinterpret. Especially when working with novices, how something is taught matters at least as much as the subject itself.
FP is one of the best examples of that. On the one hand, I’ve seen a depressing number of people who tried to start with FPiS and ran screaming, because they tried it out too early. On the other hand, I have yet to encounter anybody who finds Creative Scala difficult. It’s still teaching FP, but is intentionally doing so in a beginner-friendly way.
That isn’t to say that there aren’t just-plain-hard concepts. But in my experience, the fault tends to lie more in the documentation and teaching. (Or lack thereof, when somebody just gets thrown into the deep end with no guidance at all…)
2 Likes