When we chose scala there were white box macros, and I really had thought that scala was the best toolbox for us.
But It was too complicated in practice.
So I understand it :
But now we have:
xml literals is deprecated
delayedinit is deprecated
symbol literals is depricated
I can only be happy that implicit is not deprecated
When we chose scala we had a vision ok, scala had disadvantages but scala had been solving our automation tasks and this language had been moving in the direction which would be able to help us.
I currently do not have such clear vision.
I think the key of a language popularity is the clear vision of for what tasks the language is.
And the real Simplifying the Scala getting started experience is the simple answer for the simple question.
when do I need scala.
To say the truth I cannot make simple answer now.
Somebody can say: “I love scala you can just enjoy it”.
I like the next answer:
I can see the race for language simplicity but I do not see simple vision.
Somebody can say
most others disagree with you
And what does it prove?
When java had been growing its popularity, its user friendly was much worse, but I think java had clear vision.
And even now I clearly know when I will use java.
There are first 3 article in my region which I seach in google by “scala vs kotlin”.
They do not recommend scala, they recommend kotlin, Smalltalk.
It is really sad. But after all. It is not very popular fact.
So may be it is wrong
Are macros part of Scala language specification? They are too experimental to rely on them.
Scala’s primary goal is to enable efficient blending of object oriented and functional paradigms. It does that pretty well. If someone disagrees that blending OOP and FP makes sense then he should choose another language. But anyway, FP is being introduced in some forms even into Java (hello Streams in Java 8), so mixing FP and OOP will stay with us for a long time.
Java’s vision is OOP and strong backwards compatibility guarantees. It took them ridiculous amount of time to deliver lambdas. They are evolving very slowly, because they don’t want to remove or incompatibly change any feature of language.
What makes Scala unpopular is IMO FUD around libraries like scalaz (and also cats, shapeless, etc). Their code is totally cryptic and scary for someone that doesn’t have any prior experience with FP. OTOH “scalaz-like” libraries are often presented on Scala conferences, giving impression that scalaz way of coding is very pervasive in everyday Scala code.
Probably there should be a document on scala-lang.org explaining that there are many coding styles in Scala community and specifically that grasping scalaz is absolutely NOT required for personal and commercial Scala usage. Too many times I’ve seen that pattern:
Person 1: Hey, look at Scala. Scala improves developer productivity a lot compared to Java or C#.
Person 2: I’ve looked at scalaz already. It’s so crazy I’ll pass. I’ll stay with my current language (Java, C#, etc)
To say the truth, It is a very academical definition. When I say it usual people do not understand me in my company.
We use java to make application server. We have problems with library integration, so can you explain why we do not use kotlin?
What…, we need implicit functions, may be receiver function type is better. It is damn holy war.
it can be a reason for dismissal in bloody ERP system. :)))
I think scala has very good potential in business, but it has very bad pr. Currently I have no undeniable argument for this language. For me it is problem much more big than good getting started (ironic smile).
What, we need implicit function, may be reciver function type is better.
It is damn hollywar.
Earlier I could say scala is the best in extensibility
Currently it is not sounds such undeniably
I agree with you, so I think clear “getting started” in that question can make scala more popular than a chase to be similar with python. I really want that scala has the best from python. But the best is not the same as similar
I suspect this is incorrect. I’m currently working at a largish, Scala-centric company that is bringing in and training up substantial numbers of folks who are new to Scala. I mostly see three things that they express trouble with:
Unfamiliarity with strong types
Unfamiliarity with mostly-immutable coding style
Implicits are terrifying and cryptic
The first two are mostly a matter of education. They’re not surprising – most engineers come from a background that is weakly-typed, highly-mutable, or both.
The last is being addressed in Dotty, replacing the gigantic and scary mystery of “implicits” with a bunch of more-focused and hopefully less-scary concepts. Whether this succeeds or not, we’ll see.
But I have yet to see a novice to Scala whose fear of the language seemed to be due to Scalaz or Cats – they may be out there, but I don’t think they’re common. Frankly, I’ve encountered precious few who have even seen any Scalaz-style code. In my experience, it tends to be intermediate Scala engineers who bump up against the FP libraries and get scared of them at first.
I really think implicits are a more common and pervasive hurdle for the beginners – that’s what I typically see the JS and Python programmers dissing, in practice…
For me it’s actually a very practical definition. Scala gives you the best of two worlds. You can mix and match features of OOP and FP that suit you best in each and every case.
Features of OOP that Scala gives you are e.g:
multiple inheritance that works (traits)
sugar for singletons (i.e. objects) instead of static methods that aren’t inheritable, overridable, etc
concise syntax for fields with accessors and for constructors that automatically define fields
for-comprehensions for convenient monadic style expressions - that’s also a BIG feature, as in for comprehension I can easily use multiple bound variables without explicitly passing them between unnested flatMaps - I’ll explain that later
implicit context bounds giving you ad-hoc polymorphism (i.e. typeclasses) that actually solves the Expression problem - Wikipedia - you can implement typeclasses for classes you don’t control (e.g coming from standard library or external libraries) while you can’t mixin an extra interface to them
Proper immutable collections (coupled with immutable case classes) give you majority of benefits from immutability (IMO). Java has Collections.unmodifiableCollection, but what it gives is just a read-only view - the collection contents can change (because someone can access the unwrapped collection) and you can’t simply add element to that collection (add method will throw exception); instead you have to clone the entire collection, add the element you want and then wrap the resulting collection using Collections.unmodifiableCollection. Even if you have helper methods for that, then it’s too time consuming (every modification has at least linear time complexity) for being useful for nontrivial collections. AFAIK Kotlin extends Java collections, but doesn’t fix fundamental mutability and shareability flaws in them. So in Kotlin you just have more sugar and that’s it.
For comprehensions in Scala allows you to operate on collections in functional way with ease. Compare e.g.:
for {
a <- as
b <- a.children
c <- b.children
d <- c.children
} yield {
(a, b, d)
}
to Java equivalents. I’m not skilled in Java 8, but it should look like this:
Notice that I had to tuple a, b and c between flatMap invocations. With more generators in a for comprehension (i.e. more <- steps) there could be potentially quadratically more tupling overhead in Java’s equivalent.
PS: The Java 8 equivalent could be made to look like desugared Scala syntax (i.e. having nested flatMaps, instead of consecutive ones), but I think Java programmers would shy away from nesting flatMaps.
Understand me correctly, I do not argue with you, I understand it perfectly I hope I know scala.
And most of you arguments work perfectly until there are kotlin.
Let me do not make cross comparison.
I’ll summarize
multiple inheritance that works (traits)
We have the only one place where it is important.
implicit context bounds
Yes, it is good for type injection. For example kotlin will lose in that area.
But I cannot say it is a killer feature currently…For example kotlin receiver function type can balance that disadvantage.
It seems that it is the only undeniable killer feature when we work with custom types.
But you example does not show it
The scala has very good libraries which can easy support custom data types.
But some extensibility is deprecated know. And it adds me troubles in scala pr :)( it is irony smile)
Ok, It is my troubles in my company, but it seems I am not the only one who have such troubles.
Dependency injection is certainly not done through context bounds. It’s sometimes done through straight implicit parameters, but I don’t recommend that.
Kotlin receiver functions aren’t about extensibility, but to allow easy creation of mutable DSLs. At least the official example is about that:
class HTML {
fun body() { ... }
}
fun html(init: HTML.() -> Unit): HTML {
val html = HTML() // create the receiver object
html.init() // pass the receiver object to the lambda
return html
}
html { // lambda with receiver begins here
body() // calling a method on the receiver object
}
I haven’t specified, but my example was about working with immutable collections. They are central thing in Scala. The default List, Map, Set, etc is the immutable one. Scala’s collection framework is incompatible with Java’s one and needs compatibility wrappers (e.g. JavaConverters), because Java’s collections design is insufficient for FP. Plenty of manpower of Scala authors goes into developing efficient immutable collections. If someone doesn’t see any value in that then selling Scala to him will be much harder. Essentially, if someone doesn’t care about any FP idioms (immutability, ad-hoc polymorphism, monadic notation, etc) then selling Scala to him will be hard.
At my job, rarely anyone makes an extension method of any form. What we do all the time is instead using immutable data structures (our immutable business classes or standard immutable collections) and other monadic types (future, try, either, etc) through for comprehensions and various combinators (map, flatMap, fold, foreach, filter, find, ++, sorted etc).
I think you just do not need our use case. It is not main point, so let us leave it.
I think I can use it in such way but it is not matter so.
Ok, I can completely agree with you. I feel that direction.
But I do not want that it should be the only main area. I think scala has more potential.
For example big data processing it is not always area around immutability. May be it is so historically.
But the market can be more broader. Scala can be more popular.
I think it has something sad in the vision which is
Whether you like it or not, Scala’s main vision is to enable efficient blending of OOP and FP to get the best out of two worlds. Scala’s original author Martin Ordersky said that many times.
Scala combines object-oriented and functional programming in one concise, high-level language. Scala’s static types help avoid bugs in complex applications, and its JVM and JavaScript runtimes let you build high-performance systems with easy access to huge ecosystems of libraries.
Scala is also pretty unique in the sense that it doesn’t keep backwards compatibility for very long. Some features come and then go from Scala when they don’t contribute much to main vision, don’t add much value to typical Scala user and at the same time add unnecessary complexity.
What is the vision of Kotlin? Basically a boilerplate free Java with more elegant and concise syntax with easy learning curve for Java developers. They do not bother with FP.
What should be the vision of Scala? A supercharged Kotlin, i.e. language like Kotlin, but with some extra features? If so, then Kotlin would backport the most successful features and render Scala basically useless. Kotlin already copied some of Scala’s syntax.
If we make yet another loop in discussion. Will something change?
I do not want to advertise kotlin. But I think thay have very good market coverage.
I do not think so.
Yes thay did. And it is the reason why the phrase like:
May not work.
Who am I to make scala vision? I only have said that I have troubles with scala promotion.
But I think the answer is in a good balance between simplicity and extensibility.
There are many discussions on such theme:
xml
macros
string literals
constants
external precompilers
and so on.
Kotlin have chosen simplicity and java Interoperability(they say we are just better java)
Scala has no such good Interoperability, without good extensibility, I will certainly have troubles in scala pr.
That’s a rather extreme claim, and I don’t think it’s justified. Lots of us do enormous amounts of interoperation with Java (and JavaScript) from Scala; indeed, it’s better than it is for most languages. No, it doesn’t do absolutely everything, but I think that’s unreasonable to expect…
Kotlin will probably never copy support for efficient FP from Scala, so it will always be valid to advertise Scala as having much better support for FP than Kotlin. OTOH many OOP features and other extras are easy to copy from Scala to Kotlin, so advertising them is weak in long run.
As for the HTML example, while Kotlin can use receiver functions to achieve mutable DSL like:
html {
meta {
title("hello kotlin")
}
body {
h1("hello from mutable DSL")
}
}
Scala libraries like scalajs-react use following immutability oriented idioms:
but that probably will cause identifier names collisions.
Overall not enough difference to copy Kotlin receiver functions to Scala, at least in this scenario (HTML building using DSL).
I do not see the superior extensibility that Kotlin supposedly offers. Kotlin has no support for ad-hoc polymorphism. Haskell, Scala, Rust, Swift do.
How I can extend custom type coming from external library to be comparable? In Scala I can define custom implicit Ordering instance for it, import it into scope and I’m done. In Java and Kotlin I would have to explicitly construct and pass Comparators to each method wanting to compare types.
I was using few Spring components (e.g. LDAP) without any integration problems. The only problem is that Spring APIs are ugly and oriented about mutability, so Scala programmers undestandably shun them.
we had problems with collection and traits. So we decided to use play for view engine. It is just example to demonstrate trend. I understand I cannot prove that.
Just a remark that implicits are the first thing that throw people off whenever they need to work on the scala codebase at our company. Creates a sense of “this happens automagically” in the language that is a bit of over-engineering in terms of practical programming language usage in a private sector company. And when the necessary implicit isn’t predefined in the context, then it can be pretty confusing for a java dev writing scala (e.g. implicit formats),
To make things clear, there are very big differences between Scala and Kotlin.
Kotlin is a better java, the language is being advertised as such. Its like a much better implementation of project Lombok and JavaFx.
Scala is a fusion of OO and FP, even the new core calculus used in Dotty (Dot calculus) is a mathematical formulation of this concept.
I disagree with this statement (and this is in context of me already teaching Scala to dozens of newcomers of different backgrounds). Lets make things clear here, these are the biggest problem with implicits are
Implicit conversions which were designated as an anti-pattern a long time ago and are being removed. Trying to justify removal/changing of implicits on this point is like removing/changing Scala’s type inference completely because there are some off examples
The current Scalac compiler is kind of terrible in reporting/diagnosing missing and conflicting implicit searches. This is probably the biggest issue I have seen from newcomers learning Scala. Its not that they don’t understand the concept of implicits (its actually quite an elegant and easy concept to understand), its that when a you compile Scala code and an implicit is missing (or there is a conflict), the compiler will give you a completely different error that is buried 3 times up the implicit chain
This is a problem that an IDE is designed to solve and ironically Intellij (which people historically complained about due to them implementing their own typechecker) is now much better than Scalac in diagnosing missing implicits and tracking them. Heck they just released a new feature where given an implicit definition, you can see everywhere where it is being used. The reason why people complain about implicits being “magic” is the same reason that people would complain about static types if the IDE wouldn’t be able to provide type information about values correctly.
