From first principles: Why I bet on Scala.js
41–50 of 90 posts
Re: From first principles: Why I bet on Scala.js
#42Re: From first principles: Why I bet on Scala.js
#43What's a good way to learn how to use other languages in the browser asides from javascript?
Re: From first principles: Why I bet on Scala.js
#44Re: From first principles: Why I bet on Scala.js
#45Earlier quoted context omitted.
Thanks for the reply :) 1. Java platform is overengineered, everytime I had to set up stuff like Maven, I missed the easy JS days. 2. True story, I can infer what a '+' between two strings means, but what about all the non-intuitive operators? (List concats etc. pp.) 3. Not a big fan of IDEs. More of an editor dev, but good to know ICs are now discuraged. I got myself "Programming in Scala" back in the days and it se…
Not using an IDE for JVM-based languages is sort of like using pliers to drive screws. You can do it, but it's tiresome.
It would be nice to be able to run an integrated debugger (as opposed to a port connection from an SBT spawned JVM), integrate directly with SBT (as opposed to having to run it side by side), provide a full featured REPL (not the neutered version with no completion and poor editor integration), as well as functional import organization, dead code identification, refactoring suggestions, real linting, real code formatting, working extract refactorings, etc..
Re: From first principles: Why I bet on Scala.js
#46What's a good way to learn how to use other languages in the browser asides from javascript?
For Scala.js there are a lot of resources, e.g. http://www.lihaoyi.com/hands-on-scala-js/ is a good start.
I know you can use asm.js but it looks like they're not using asm.js
Re: From first principles: Why I bet on Scala.js
#47I wrote this; ask me anything
Re: From first principles: Why I bet on Scala.js
#48Earlier quoted context omitted.
Unfortunately, you also get Enumeratee.take(4) &>> Iteratee.fold[Byte, Int](0){ case (acc, b) => acc * 256 + (b & 0xFF) } It's a community thing, and much like Java suffered from excessive XML and patterns in the 200Xs, but is much better now, Scala has suffered from excessive operator noise, but it's getting better.
Scala Dotty will maybe have some kind of @infix("+") def add so that if it should be used via a + b it needs the infix else it's only possible todo a.+(b) p.s. I banned scalaz and shapeless on my company so there aren't too much operator noises.
Just wondering, do you have your own libraries that use some of the good stuff? I can't imagine living in a world where I'm banned from using...
* Traverse (do you write specialized versions for the cross product of [List, Vector, etc] x [Option, Either, etc] ?)
* Validation (how do you collect errors? mutable.Buffer?)
* NonEmptyList (I've written my own NonEmptyVector that wasn't that hard to write. Do you do that or just assume nonempty and it works out for you?)
* Unapply (maybe this doesn't apply to you because you never use HKT-generic typeclasses?)
I'm genuinely curious as all of these tools get used by me and my coworkers literally every day and without them we'd be writing boilerplate or making unchecked assumptions by the seat of our pants.
Re: From first principles: Why I bet on Scala.js
#49Earlier quoted context omitted.
For Scala.js there are a lot of resources, e.g. http://www.lihaoyi.com/hands-on-scala-js/ is a good start.
How does scala get embedded in the browser? I can't seem to find it on that document? I know you can use asm.js but it looks like they're not using asm.js
Re: From first principles: Why I bet on Scala.js
#50> If you look at other compile-to-JS languages like:
> - Google Web Toolkit which lets you compile Java to Javascript, > - The Opal Ruby Compiler for Ruby > - Brython, PyJS, Skulpt, Transcrypt or RapydScript for Python > - Various flavors of C#-to-Javascript (Salterelle, Bridge.Net, JSIL) > - Or Haskell-to-Javascript compilers (Haste, Faye) > You'll notice one thing in common: none of them have a standard way of writing code that runs on both their "original" runtime (JVM, MRI, CPython, CLI, ...) and on Javascript. And the reason why is straightforward: none of them are compatible enough, complete enough to really let you write "full" Java/Ruby/Python/C#/etc..
ClojureScript is mentioned in the article, but only for this specious comparison:
> Clunky Interop > Many other languages are not as fortunate. For example, here's how you create an element in ClojureScript, compared with Javascript
(let [paragraph (.createElement js/document "p")] (set! (. paragraph -innerHTML) "Bold!"))
var paragraph = document.createElement("p") paragraph.innerHTML = "It works!"
> Now, the conversion between these two snippets is mechanical, so it's not something you need a PhD to perform. Nevertheless, it is clear that using Javascript APIs in ClojureScript, while looking like ClojureScript, looks almost nothing like the Javascript it represents.
> This mapping is something that everyone who wishes to learn Clojurescript will have to internalize.
This seems misinformed at best - both Clojure and ClojureScript have interop as a first-class concern, and interop forms are exactly the same between them.
I appreciate the work that Li's done, but I'm disappointed by what seems like a rather disingenuous omission of the only other language which fulfills Li's criteria.
Interop, IDE support (IntelliJ), parent language compatibility, static optimization (judging by the payload size numbers, ClojureScript utilizes dead-code elimination more effectively than Scala.js), performance (ClojureScript immutable vectors are faster to build than JavaScript arrays, far from the 1-2x Scala.js slowdown cited in the article!) - there is (and has been - since 2011) a compile-to-JavaScript language that is in the same league as Scala.js, and arguably eclipses it on many dimensions.
A language-agnostic comparison can't reasonably leave out ClojureScript.