1. 17
  1.  

  2. 8

    We used wreq in the book as an excuse to demonstrate Traversable. I didn’t know anybody still used that client. Most people I know use stuff in the http-client family (Bloodhound, wreq, http-conduit, etc. all use it).

    This is where the HTTP operations ground out in Bloodhound. The rest is JSON parsing.

    First user experience matters, but if I was asking for help with deploying a Rails 2 application with Vlad the Deployer, I’d get politely redirected to something better in #rails and asked why I hadn’t looked around first.

    I may try translating the code in this post.

    1. 4

      I’m actually just about to buy your book to start a reading group around it. Thanks for the work you’ve done, you’re a big reason I’m getting into Haskell.

      1. 7

        Thank you! Julie and I are very happy with the progress we’ve seen our reviewers and readers make. We’re looking forward to getting it done soon :)

        Makes you feel any better, I thrashed for about five years (not constantly) before I got comfortable in Haskell. Spent a year or two teaching before I started feeling comfortable there too.

        Part of the reason I wrote Bloodhound was to make the point that you could make something nice and typesafe and not difficult for beginners to use. I know people who’ve used Bloodhound to generate JSON for talking to ES when they didn’t even know or use Haskell.

        I’m reviewing your post to see how it translates to the sort of kit I usually use, partly as a UX sniff test.

        1. 1

          I dm’d you on Twitter about the follow-up post.

      2. 12

        Uh…so he picked the wrong library at first, and then was surprised he had to import the library to use it, then was thrown off when the library properly encoded the querystring. Is this how programming is done nowdays? And what does this have to do with Haskell?

        Now I’m really curious to see an example of a language that doesn’t seem like a cavern of horrors to him!

        1. 5

          A lot of this complexity isn’t in Haskell. It’s in HTTP and years of best practices that you have to contend with, in any language. The difference is that if you use a framework like Rails or Django, it gets the common cases out of the way. However, if you rely on a framework to do your heavy lifting and get out of the common cases… then you have to learn all of that stuff.

          There are couple things that I’m starting to think dynlangs do better. For one thing, when you’re trying to learn a new domain at a beginner or intermediate, I think the dynamic toolsets are better at getting you to the important stuff. If you’ve never built a website, you’re probably going to get further, faster, using Rails than using Servant or Yesod or non-framework Haskell. If you want the absolute best possible backend, then non-framework Haskell can probably beat Rails, but that’s a “Maserati Problem” if you’re just looking to set up a website. This is also why I don’t see Haskell beating Python in exploratory data science (but, if Python can knock out R, I will be ecstatic).

          At least as things are now, Haskell’s vision of static typing requires you to know what the hell you’re doing before anything even runs. That’s not necessarily a bad thing. It’s great for highly reliable production systems (under whose economy, 4 hours to make HTTP requests ain’t so bad). It’s not good if you’re trying to get to a slightly less trivial, HTTP-powered “Hello world”.

          1. 2

            All true, but in this case…you could substitute JavaScript for Haskell and npm for cabal in this article and nothing substantive would change. You’re going to have to pick a library, import it, and understand the most basic principles of HTTP. Heedless copy and paste programming is equally invalid in any language.