4 ms·
Canonical example would be marshelling one type to another, something that typically requires a fair amount of boilerplate in statically typed languages, wherea
by virtualwhys 13y ago
Canonical example would be marshelling one type to another, something that typically requires a fair amount of boilerplate in statically typed languages, whereas in Ruby, Grooy et al you just do something like:
complex_object.to_json
and you're done with it (assumes a valid object of course, which can be a rather large assumption on the dynamic side of the fence ;-)).
It's a total PITA in Scala to query your DBMS; marshall a tuple result to a collection of case class(es) and then have to go down boilerplate road again in order to create a a typesafe JSON result.
I basically render everything server-side and use JSON sparingly (e.g. AJAX responses). Until Scala pickling or other cutting edge lib allows me to convert an arbitrarily complex object graph from A to B without the boilerplate, I'll keep to the server-side and leave client-side templating...off to the side.
- lmm 13y ago> Canonical example would be marshelling one type to another, something that typically requires a fair amount of boilerplate in statically typed languages, whereas in Ruby, Grooy et al you just do something like: complex_object.to_json The popular scala libraries only require one line of boilerplate per class for that, e.g. in spray-json I do jsonFormat3(MyClass) and then I can do myObject.toJson. With scala 2.11's implicit macros this will go down to 0 lines and work exactly like in ruby/groovy/etc. (Whether the scala ecosystem will want it to be 0 lines or prefer to keep the 1 line as a "flag" for which objects should be convertible to json is an open question, but scala-the-language certainly supports doing it the 0-boilerplate way) > It's a total PITA in Scala to query your DBMS; marshall a tuple result to a collection of case class(es) and then have to go down boilerplate road again in order to create a a typesafe JSON result. Huh? Squeryl just gives me the results as my case classes (I have to define the schema somewhere, but I have to do that with e.g. Django as well). I don't even need to do the json conversion explicitly - as long as it's the only serializer for that type in scope, spray will pick it up implicitly.
- virtualwhys 13y agoYou're talking about simple 1-to-1 mappings where both db result and case class to json conversion are straightforward. The example I gave was for objects of arbitrary complexity; it's a trivial operation in dynamic languages because there are no types (or 1 type if you like). In Scala, this is not (yet) the case, beyond a certain point you have to roll up your sleeves and do the marshelling yourself.
- Peaker 13y agoIn Haskell, I can add a single line containing a macro to derive the JSON [de]serialization code. Even when there's no simple 1-to-1 mappings. I don't see why you think unityping makes this serialization easier?
- virtualwhys 13y agoI have no idea whether or not the implementation is easier is dynamic languages or not. I do know that for the language user it's a simple foo.to_json, end of story. If you can marshall objects of arbitrary complexity to JSON in Haskell with a single line of code that covers all possible cases (e.g. your entire database model), consider me beyond impressed.
- Peaker 13y agoIt's (toJson foo) on the entire data, however complex, as long as there is a sane way to jsonify it. For example, if the data contains functions, there's no default way to convert it into json. And also, deserialization is going to be more concise in Haskell because type inference decides which type to deserialize to.
- virtualwhys 13y agoThat's pretty awesome, sounds ideal for a RESTful API. In Scala I've noticed a tendency toward using NoSQL storage engines like MongoDB, which speaks a form of native JSON (i.e. it removes the BP required to marshall to/from JSON). A few months ago I took a stroll through available Haskell libraries for web dev., found Yesod, HaskellDB, and a couple of other glue items. What's the state of the art on the web framework front in Haskell? Snap looks interesting but incomplete, and HaskellDB is fairly ancient (LINQ-to-SQL lib would probably get me very interested in Haskell sooner rather than later). Assume email, PDF generation and other web must-haves exist in Haskell ecosystem.
- Peaker 13y ago
- asdasf 13y ago>whereas in Ruby, Grooy et al you just do something like: complex_object.to_json So, just like you would in a statically typed language like scala or haskell?