Thank you very much and thanks to everyone that helped me build this. You, carter, and the others in the Haskell/Haskell.au IRC channels were a big help. The thank-you list would be huge if I tried to list everybody that made a library I used or whose blog post helped me along.
To be fair, errors are implicitly encoded in the HTTP statuses and I'm not doing anything about Conduit's exceptions right now. This is something I'd like to fix later.
This is great advice, I read the follow-up links in that post and they're very informative! I'll jot down a task for figuring out how to flip the Seminearring over to bool.
The reason for the original design was that they mated to nested And/Or filters which I knew to be less than ideal but figured it work as a first pass.
It's spreading pretty rapidly in my circles. It's used by a lot of popular sites, such as Github, Soundcloud, Stumbleupon, Quora, Foursquare, Etsy, etc.
I run the Elasticsearch Berlin UG and we have a steady and fast influx of new people. I've rarely seen communities grow that fast. The community is great and active and Elasticsearch is caring a lot for that.
Why you never document your code? You didn't document your Clojure libs and now you're continuing the trend with Haskell. If you're going to make libs, please provide the adequate documentation with examples of usage in the code. I'm not gonna keep going back to the README. I'm going to use Hoogle and Hackage. All those comments in the README could be looking all pretty on Hackage right now.
meh, types give you enough documentation. once you play around with examples on README, reading type annotations (that are actually written manually as a form of documentation) of functions in https://github.com/bitemyapp/bloodhound/blob/master/Database... make sense.
examples could be moved over into modules.. but I much much prefer to have examples in one place that could be read like a gentle introduction and walkthrough of the library. Said that, additional module and function documentation could be useful, too. But not at all if the library maintainer just fills stuff in to generate fat haddock. Again, type annotation says much.
And, you're welcome to contribute documentation to the library.
that is frustrated me when entering functional language world. rarely good document compared to other language. In Perl, many modules will have their own tutorial
27 comments
[ 5.2 ms ] story [ 55.0 ms ] threadhttps://github.com/ocharles/Elasticsearch
it's not very principled, tbh. uses error etc rather than proper sum types for returning errors.
Seminearring and Monoid Filter could encourage usage of the bool filters, instead of and/or.
Thank you otherwise, I was longing for something similar when I was editing JSON queries. Going to try that the next time I have to do some ES work.
The reason for the original design was that they mated to nested And/Or filters which I knew to be less than ideal but figured it work as a first pass.
Thanks!
[1]: http://bitemyapp.com/projects.html
They have some case studies:
http://www.elasticsearch.org/case-study/
eg. http://www.elasticsearch.org/case-study/github/ http://www.elasticsearch.org/case-study/soundcloud/ http://www.elasticsearch.org/case-study/stumbleupon/
http://www.meetup.com/Elasticsearch-UG-Berlin/
http://www.google.com/trends/explore#q=elasticsearch%2C%20so...
TLDR; they are roughly equal in popularity according to gg-tends, ES growing very fast.
I'll transfer the README docs over to Haddock/lhs when I do the next non-trivial release.
examples could be moved over into modules.. but I much much prefer to have examples in one place that could be read like a gentle introduction and walkthrough of the library. Said that, additional module and function documentation could be useful, too. But not at all if the library maintainer just fills stuff in to generate fat haddock. Again, type annotation says much.
And, you're welcome to contribute documentation to the library.