From first principles: Why I bet on Scala.js
lihaoyi.com
From first principles: Why I bet on Scala.js
1–10 of 90 posts
Re: From first principles: Why I bet on Scala.js
#2Re: From first principles: Why I bet on Scala.js
#3Re: From first principles: Why I bet on Scala.js
#41. 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 ;))
Re: From first principles: Why I bet on Scala.js
#53 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 ;))
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
#6I wrote this; ask me anything
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
#7Re: From first principles: Why I bet on Scala.js
#8The 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
#93 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…
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.