3 ms·
Show HN: Haskell library for pricing and information on crypto-currencies
- deleted 9y ago[deleted]
- aviaviavi 9y agoFeedback is welcome! I wrote this library for my own use, but I'm happy to hear any suggestions, code improvements, etc
- wereHamster 9y agoSubmit it to https://www.reddit.com/r/haskell/ https://www.reddit.com/r/haskell/ if you want feedback to your code. I doubt most people on HN are fluent enough in Haskell to give you meaningful feedback.
- aviaviavi 9y agoAlready done, mentioned that here too just in case :)
- arthurcolle 9y agoTitle might confuse the audience since this doesn’t do any pricing per se, and only wraps a public API
- amrrs 9y agoSelf Plug: wrote a similar one for R as an R package https://github.com/amrrs/coinmarketcapr https://github.com/amrrs/coinmarketcapr
- endgame 9y ago* Consider using `Text` instead of `String`, as `String` is a linked-list of `Char` and quite inefficient * Consider refining some of your fields into more constrained types. Sort orders probably only have a couple of valid values, and might reduce to an enumeration instead of `String`. * In `instance ToQueryString PriceRequest`, I'd be surprised if those type annotations are necessary. The inferencer should be able to work out that `req` is a `PriceRequest`. * In `instance FromJSON AggregatedSnapshot`, I think the `read`s should go. I think you want to use the `Float` instance of `FromJSON` instead. (What the `read <$> ...` is doing is parsing to a string, and then using the partial (!) `read` function on the result. JSON responses that have a value that fails to read for that key will crash the program.) * In `instance FromJSON AggregatedSnapshot`, consider `withObject` here too, which encapsulates the pattern you're using.
- thinkpad20 9y agoI don't have it in front of me but I would assume the FromJSON instance for Float expects a JSON number, not a string. If the remote API makes the (puzzling) decision to put numeric values in strings, then parsing those will be necessary. Although, I agree that the 'read' function is the wrong one to use here, due to it making the function partial (consider 'readMaybe' instead?)
- aviaviavi 9y agoIt does indeed do that, there are numeric values returned as strings (i have _no_ idea why they do that), which is why I had `read` in there. I didnt know about readMaybe though, I'll definitely do that, thanks!
- aviaviavi 9y agoThank you for all of these suggestions, very appreciated! I'll work through implementing these. Also, please see my explanation of the `read` calls below, but I plan to change those to `readMaybe`s, since there is a need to parse numbers from strings ( for whatever reason :/ )
- endgame 9y agoWhat a bizarre API. You might get some mileage out of writing a helper function like `readParser :: Read a => String -> Parser a` which can call `readMaybe` and inspect the result.
- sfvisser 9y agoHaskell must be the only language for which I can skim a source file in under 60 seconds and almost fully grasp what's going on. Bunch of datatypes, some instances, some helper code, some top-level IO code tying everything upstream together. Done.
- kccqzy 9y agoThen you’ve never seen tricky/advanced Haskell code that takes hours to grasp. It’s not a language issue. In most sane languages you can write readable code. And most languages also give you enough freedom to write unreadable code. Here are some reasons why advanced Haskell code might not be readable if you aren’t already experienced with this style of coding: - uses the C preprocessor extensively (usually to workaround API changes in upstream libraries, but sometimes used for actual code generation, like in a particular streaming library) - uses long TH declarations that give no insight into what they do (you only know they have to return a `Q [Dec]` but it’s not obvious what, and dumping splices only goes so far; it can even download things from the Internet to generate code!) - uses advanced concepts like Church/Scott encodings of data types (though with some comments this really shouldn’t be hard) - excessive type level meta programming - uses concepts like Bazaar, Bizarre, Conjoined, Strong, Yoneda, etc By the way for some laughs you can read about how to write to write a factorial program in Haskell from simple straightforward styles to convoluted ones that use many advanced techniques: https://www.cs.utexas.edu/~cannata/cs345/Class%20Notes/10%20Haskell%20Programmer%20Evolution.html https://www.cs.utexas.edu/~cannata/cs345/Class%20Notes/10%20... I hope no one actually writes production code like this but it does show you how much of a steep learning curve could be needed before you understand certain kinds of Haskell code.
- SkyMarshal 9y agoTrue but Haskell's type declarations let you skip reading the actual implementations. You can skim through the type declarations only and know what it does, and that it won't compile if the implementations don't do exactly what the type declarations do. Saves a few brain cycles.
- 9y ago
- mrkgnao 9y agoClear, readable value-level Haskell is an underappreciated joy. What are you using this for, if anything?
- aviaviavi 9y agoGlad you liked it! I'm using this library to do my own analysis and visualization of the value of different coins to inform my own investing. My goal there is that some more tools will fall out of that endeavor, which I would also release publicly. We'll see how that goes!