|
> I've never had to make a context switch between clojure and clojurescript. If differences in semantics means I have to change how I think about solving the problem at hand, then that has been pretty much non existent in my experience. Of course with one you have browser APIs and the other is java, but when it comes to building up and transforming datastructures everything I've been doing works the same on both. In clj: > (+ 1 "1") java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Number In cljs: > (+ 1 "1") "11" Now I get it...not that big of a deal, right? That's what I would say given a trivial example of something like this. Sure, this problem might not come up very often. In fact, for a team that I worked with, it only ever came up once...it's just that that one time that it came up, it corrupted 3 months worth of data. Would tests have caught this? Of course...but if you are confident in your knowledge of the clojure language, and you assume clojurescript is semantically equivalent, you would expect an exception to pop up in your repl during development, so if it works fine in clojure, why write a test for it in clojurescript? I understand why the cljs designers would do such a thing...think of the performance implications of having to generate type checks code for every possible arithmetic operation! But it absolutely was a context switch for that team (full stack clj/cljs), and the consequences of the developers not correctly context switching was horrific. Nothing quite burns bridges with entire languages like silent errors do. I'm fine with people trying clojurescript. FWIW, my personal experience with it was never as bad as that one team's experience. Maybe they'll never come across such a dangerous situation, hopefully they don't. But on the rare occasion that some third party web service dependency decides to serialize BigDecimals as Strings instead of Doubles, they deserve to be warned. |