Live data from Hacker News

From first principles: Why I bet on Scala.js

lihaoyi.com

1–10 of 90 posts

Re: From first principles: Why I bet on Scala.js

#5
post #4

3 things I don't like about Scala: 1. It's based on the Java platform. 2. It's excessive use of operator overloading. 3. Mad implicit conversions all over the place. (yes, I exaggrated a bit ;))

1. Java platform is excellent. Also, Scala.js is now Scala for JS platform, and scala-native is coming soon.

2. Have you seen languages like APL or J? Now that's operator overloading. '+' is just a symbol, meaning a lot of different things even in mathematics. All meaning is a product of convention.

3. In modern Scala, implicit _conversions_ are discouraged unless you know what are you doing. Besides, Scala IDEs are excellent in showing applied implicits anywhere in the code (you do use an IDE, right?)

Re: From first principles: Why I bet on Scala.js

#6
post #3

I wrote this; ask me anything

Scala.js is magic under magic sauce with magical cherry on top of it. Thank you and everyone else involved!

Compiling _entire Scala_ to JavaScript? Without runtime?! To the point of compatibility that Scalaz can be compiled, with all its horrors?!! Wow.

Re: From first principles: Why I bet on Scala.js

#8
I've backed the current iteration of my career on Scala and like the idea and some of the practicalities of Scalajs but it is destined to be limited to fun projects. The unavoidable problem is by committing to Scalajs you are accepting that you can no longer go out and get one of any number of JavaScript contractors or staffers to come on board and develop / maintain you client code and have to always have a Scala developer for that job as well which is a magnitude of time and expense different.

The underlying notion of Scala to X ie Scala Native has lots of potential but Scalajs is more of a segue.

Re: From first principles: Why I bet on Scala.js

#9
post #5
post #4

3 things I don't like about Scala: 1. It's based on the Java platform. 2. It's excessive use of operator overloading. 3. Mad implicit conversions all over the place. (yes, I exaggrated a bit ;))

1. Java platform is excellent. Also, Scala.js is now Scala for JS platform, and scala-native is coming soon. 2. Have you seen languages like APL or J? Now that's operator overloading. '+' is just a symbol, meaning a lot of different things even in mathematics. All meaning is a product of convention. 3. In modern Scala, implicit _conversions_ are discouraged unless you know what are you doing. Besides, Scala IDEs are…

'+' is just a symbol, meaning a lot of different things even in mathematics. All meaning is a product of convention.

As always: cost/benefit! There is a price for the "context switch" out of one set of conventions into another. Sometimes, the benefit far outweighs the cost. For example, there are certain environments where you can jump out of the programming language and simply write a method in SQL. Not embed SQL in code in a string, you can simply write prepared statements as a method. For certain applications, this can be beneficial.

The problem I have with operator overloading, is that it allows the average programmer to switch conventions using some of the the most commonly used conventions with barely a sign that something special is going on. It's too easy to use. It's too easy to miss. It's too easy to get a moment of confusion from it when debugging. (What, I'm in a method? Oh, operator overloading!) And it doesn't produce a great benefit all that often. Yet it has a "nifty" factor that encourages in experienced programmers to make use of it -- precisely the people who probably shouldn't be making that decision.

Post reply on HN