Hacker News Reader

Comment by timtadh | Hacker News Reader

"intellectual laziness of dynamically typed languages"

What a claim! What an absurdity!

Dynamically type checked memory safe languages (eg. Python, Ruby, Javascript, etc...) enable styles of programming impossible in non-dynamically checked languages. So it certainly isn't the users who are being "intellectually lazy." Nor are the creators, who have focused on productivity and usability instead of waiting for proof systems (static type checkers) to catch up with their ideas. Laziness doesn't factor in on either side.

View on HN

Provide an example where such a style would be deemed useful or superior to doing it the statically checked way.

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.

> 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.

You'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.

In 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?

I 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.

It'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.

That'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.

I do a lot of Haskell development, but virtually nil web development.

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.

Thanks for the overview, midway through Learn You a Haskell and it's clear I need to sit down and write some code as reading about Haskell is entirely different than reading about Java, Scala, etc. ;-)

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.

>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?

I don't really feel I need to provide you with specific examples, they are already a google away. Try: "python vs java" or "why ruby" or similar. Experiment with programming in these languages and see what type of flexibility you can get, especially during prototyping and initial development phases. Their simplicity is to their benefit when comparing to Scala which brings a lot of overhead to enable static checking of certain constructs. Furthermore, I would bet that you can do things in Python or Ruby that are not possible in Scala (for instance see Armin Ronacher's Euro Python 2013 presentation for some interesting tricks https://ep2013.europython.eu/media/conference/slides/5-years...)

So, basically you have no clue what you are talking about.

>I can't back up my absurd claim with an actual argument, so go google some strawmen for me

Really? How does this kind of shit not get downvoted to oblivion?

1. I did provide a link to a slide deck of examples.

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.

1. The link you provided does not support your absurd claim in any way.

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.

Duck typing in dynamic languages can allow you to do some pretty cool things.

The request was for some examples of the claim. You just repeated the claim.

Compared to Java? No question. Compared to Scala with its implicits and associated patterns? I've yet to see a case I couldn't handle in Scala.

An in place and efficient quick sort? :)

???

https://github.com/non/spire/blob/master/core/src/main/scala...

Ha! Fair enough, though I was thinking something different in two ways. Namely, something that worked on the common collections used by people and more readable than this. Still, bad example.

That doesn't make sense. The whole point of quicksort's algorithm is to do things in place, which requires fast indexed access and mutability.

Common collections lack both of these things.

Reply on news.ycombinator.com