Provide an example where such a style would be deemed useful or superior to doing it the statically checked way.
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.
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.
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.
Even when there's no simple 1-to-1 mappings. I don't see why you think unityping makes this serialization easier?
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.
And also, deserialization is going to be more concise in Haskell because type inference decides which type to deserialize to.
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.
I know the Yesod ecosystem is well-developed and should have good solutions for most problems. I think the downside of Yesod is that it is not as principled/based-on-sound-theory as most of the Haskell ecosystem is, so it gets a lot of negative sentiment. But it solves a real problem now -- at least until a principled approach is proven.
Yesod also has "persistent", which can persist over SQL and IIUC, nosql DB's as well.
Snap is more minimalist, and solves a smaller part of the problem for you -- but is much simpler (and perhaps more elegant) than Yesod.
Happstack is another web framework, like Yesod (all 3 are under active development). Its main problem (perhaps this was fixed already) was prevalent use of "lazy I/O" which is very controversial. I personally despise lazy I/O and think it violates the basic principles that make Haskell great. I heard something about Happstack immigrating to an alternative to lazy I/O though.
Email is a solved problem in the Haskell ecosystem, as far as I can tell.
PDF libraries exist: http://hackage.haskell.org/packages/#cat:PDF but I haven't used them, so I don't know how good they are.
I don't know about other must-haves. I know an automatic "admin webpage" didn't exist until recently even in the Yesod ecosystem. A friend who encountered this missing piece contributed one, but it was pretty barebones/preliminary. This was a couple years ago though.
In other words, a simple web project is in order. Snap looks like a good call, along with Yesod's Persistent. PDF, email, etc. can come later, just trying to explore the language.
Thanks again.
So, just like you would in a statically typed language like scala or haskell?
Really? How does this kind of shit not get downvoted to oblivion?
2. This is a well written about issue.
3. I do not consider my claim absurd if I did I would not have made it.
4. If you do not have experience writing significant amounts of code in a dynamic language I don't expect you to agree with me nor do I think that I could convince you with some half baked micro examples. It is the type of opinion which emerges out of years of writing code in both dynamic and statically checked languages.
2. It is not a well written about issue at all. If it was you would show some support for it rather than try to deflect.
3. Of course not. But your claim is still absurd, being ignorant of this fact does not change it.
4. I have likely been programming in untyped languages longer than you have been alive. Your claim was not an opinion, you stated a (completely incorrect) factual thing. "I like untyped languages" is an opinion. "Dynamically typed languages let you do things that are impossible in statically typed languages" is a factual claim, one which is complete nonsense, and you have totally failed to support.
You made a completely baseless claim, and then when asked to support it said "no, you support my argument for me". That is what I said deserves to be downvoted to oblivion, not your original bullshit claim, which is just typical ignorance.
Common collections lack both of these things.