What can make scala more popular?

Community
26

No, it does not.
I do not know universal rule which do not lead to holywar.
We use principle:
If someone read code in text editor and do not understand what it is going on because of implicits it is a bad practice.

So, we use implicits

  • instead of thread variables(it is evil in any case)
    there are 2 such implicits in our framework
  • to make constants, for exampl 2.nn is equavalent to NNumber(2)
    Everybody know it by heart.
  • context bounds def f[A : B]
    implicit should be in object A

So there are no need for

IMHO If you need IDE help it is a bad practice :wink:

27

Thereā€™s no point in making everyone happy. You canā€™t satisfy everyone at the same time.

Some Java programmers were scared by var keyword. They say they do not understand code with vars if they are reading it in text editor, so they prefer explicit types.

1 Like
28

I have said very different thing. All implicits( except context bound) must be known by heart by everyone

it is not like library extension it is more like language extension.

It is very expensive

29

Either that, or it has to be something that if you need to examine, you use an IDE, and you can understand the code at least superficially, without an IDE.

An example of that is Ordering. You can read xs.sortBy(f) without having to know about implicits, unless you need to examine it more closely. So if you can assume that anyone that needs to examine it more closely has the requisite tooling (such as the latest IntelliJ Scala plugin), then you donā€™t have to assume memorization.

The other side of that coin is that when designing a library and deciding how implicit-heavy it will be, you are deciding what level of understanding it is possible to get without implicit-examining tools. For example, from just reading code that uses Slick, you donā€™t know much about the machinery thatā€™s deciding how to work with your types. That machinery plays a pretty significant role in the behavior of the code. At the same time, Iā€™d kind of rather not have that part written out. If it was explicit, it would be much harder to see the more important part of the code, such as the columns or queries Iā€™m defining. (But no question, now that IntelliJ can show the implicit parts as if they were written out, I would sometimes turn that on.)

1 Like
30

May be it is most undeniable implicit feature.

There is other very important thing, it is the amount of brain to understand it :slight_smile:
There are two important moment in that joke:

  • The less brain is needed by you to read and write, the more brain you can spend on solving business task
  • I think there are mostly very smart people in this forum. But there are many usual people which can not be so smart for scala, but they can be usually much better for business task.

It is very hard to prove, but take into account some practice, for example:

Or let us just look on kotlin :slight_smile:

We are not lazy to think, we just want to think more about business tasks and about people.

31

I think it is really killer feature.
You just do not need to learn by heart where you need to write import someUnknownWord._ :slight_smile:

see also:

1 Like
32

Show me code with lots of receiver functions. Will it be only about mutable DSLs?

33

I have discussed a lot that question in other topics, so I would prefer not to repeat it here.

I have not thought much about it. We need better

  • scope managment
  • builder pattern
34

So no publicly available code to discuss? Then it doesnā€™t seem receiver functions are popular.

35

There are a lot of examples in other topics.

It seems so for scala users :frowning:

But kotlink users sometimes troll me :))

1 Like
36

All I see is mutable HTML DSLs harassed over and over. HTML is easy. Show me how do you deal with CSS with receiver functions :slight_smile:

Immutable type-safe HTML DSLs should be doable using type unions (available in Dotty), e.g.:

object HtmlDsl {
  type HtmlChild = ElemHead | ElemBody

  type HeadChild = ElemMeta | ElemTitle

  type BodyChild = ElemTable | ElemP

  def html(items: HtmlChild*): ElemHtml = ???

  def head(items: HeadChild*): ElemHead = ???

  def body(items: BodyChild*): ElemBody = ???
}

IDE should be able to suggest matching methods in auto-complete, i.e. IntelliJ already sorts method in auto-complete putting methods with correct result type first.

Here you have your killer feature :slight_smile: In FP form (immutability oriented) instead of typical OOP form (mutability oriented).

37

I have never said that it is killer feature for FP. I have thought it is obvious.

I have not seen simple scope management here.

38

Show me an example where it is not sufficient.

39

http://www.scalafx.org/

Yes you can make it somehow without delayedinit.
Just show me the way you can do it such way which can fit our company standards of simplicityā€¦

40

Which classes in ScalaFX use DelayedInit?

41

Letā€™s not repeat half year of discussions on loop.

I completely agree with it.

42

So itā€™s just one class inside ScalaFX that inherits from DelayedInit. Without DelayedInit we need to change:

object ScalaFxApp extends JFXApp {
  // some lines of initialization code
}

to

object ScalaFxApp extends JFXApp {
  def delayedInit(): Unit = {
    // some lines of initialization code
  }
}

Not a very big deal. At least not big enough to be convinced by it that DelayedInit makes Scala noticeably superior. I wouldnā€™t expect dozens of JFXApps in a single project. With few ones the saving are also small.

43

No, it does not.
But take into account:

  • DelayedInit is a bad alternative of kotlin reciever function and Scope Functions
  • if main task is view and the view code may contain 70% of markup code then kotlin will be just better.

So we have two camps in our company. Ones write controllers in the first camp, and others write views in the second camp. The second camp people just dream about kotlin sometimes. It is very good kotlin advertising ;).

There are many good illustration in history that something can be very, very good,but being a little bit worse is absolutely enough to remain in history.

But absence of more better dsl for viewā€™s markup just do kotlin more desirableā€¦

44

I think that supporting Scala on Android would do a lot to make Scala more popular. Right now, Scala-on-android is stuck at version 2.11, but I was recently looking at the d8 project which allows people to use java 8 features and then compile their Java 8 bytecode to dex bytecode. I donā€™t see why this canā€™t work for Scala. In fact, it looks this person with tag @LolHens has already started working on a prototype sbt plugin to support d8 https://github.com/LolHens/sbt-android-d8, and also talks a little bit about it here.

That could be a pretty low hanging fruit, and allow Scala to compete better with Kotlin, but I have never developed for Android and so donā€™t know much about it.

1 Like
45

Agreed. However itā€™s been pointed out that it also needs to be made official. Unless Scala is officially supported and marketed for JVM, Android, JS, and Native, Kotlin has a big advantage over us.