What can make scala more popular?

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

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

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.

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

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

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

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

There are a lot of examples in other topics.

It seems so for scala users :frowning:

But kotlink users sometimes troll me :))

1 Like

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).

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.

Show me an example where it is not sufficient.

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…

Which classes in ScalaFX use DelayedInit?

Let’s not repeat half year of discussions on loop.

I completely agree with it.

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.

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…

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

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.

I’m all for getting official support for Android and Native (assuming JS is already “official” isn’t it)! How it would be funded on the other hand I don’t know…

1 Like

I would prefer to complain about kotlin. Why they have made more better language for dsl. My life would be more pleasure if they had not made scope and reciever functions.

:))