3 ms·

Aeson parsing seems straightforward to me, not sure it could be easier in any language. Serialization from your endpoint is automatic, based on your data types.

by hopia 7y ago

Aeson parsing seems straightforward to me, not sure it could be easier in any language. Serialization from your endpoint is automatic, based on your data types. The real benefit of using a well typed language here is that you only need to parse the data once at this point, after that the type system makes sure the data is of correct format everywhere else in your codebase.

marcosdumay 7y ago
Aeson is not straightforward at all. Just try doing what the GP is saying he wants to do, you will discover you can't. It is a very good library if you control both sides of the communication, and have fit for purpose interfaces. Otherwise, you are better with any lower level library. Besides, what is it with the strictness of Haskell JSON libraries? There's nothing that will even accept Window's BOM.
- hopia 7y ago
  Fair enough, you're probably right, I have only used it in contexts where I build both sides of the application.
- platz 7y ago
  You don't have to define a type for Json data in Haskell if you don't want to. Defining a full type is only norm/preference. With Aeson, You always have the option work with a map directly and pull out properties by name. That is also especially useful when you can't predict what keys or shape the data will have
  - marcosdumay 7y ago
    I don't want to detract from Aeson. It's a great library. If you control both ends of your channel, it can be more convenient than the equivalent encoding and decoding on Javascript, and making a JSON library that is more convenient than JS is no small feat. But it's a very complex library. It may not show at your code interface, but that complexity is there at the documentation and type errors. It is also famous for generating bad runtime messages. There is even another library for fixing this, at the cost of even more complexity. If you fall outside of its optimum usage scenario, it won't afford you more functionality than a low level parser, so you are much better saving that complexity and going with the parser.
    - platz 7y ago
      Ok, so use a parser then? Not sure what this has to do with comparison to dynlang/js. OP was complaining that it's hard to type some kinds of payloads. Sure you could write a custom parser for it. With fromJSON in fact this is what you write. Maybe if you've only been driving Json instances generically, you never actually written a fromJSON instance in Aeson? I only use generic deriving in the simplest cases.. otherwise just write the fromJSON instance parser My point was that you can defer parsing up front and just return a map of you don't want deal with the shape. But sure you could write a custom parser as well, that falls more into the typed philosophy though than what js folks are used to

by hopia 7y ago

marcosdumay 7y ago

Aeson is not straightforward at all. Just try doing what the GP is saying he wants to do, you will discover you can't. It is a very good library if you control both sides of the communication, and have fit for purpose interfaces. Otherwise, you are better with any lower level library. Besides, what is it with the strictness of Haskell JSON libraries? There's nothing that will even accept Window's BOM.

hopia 7y ago
Fair enough, you're probably right, I have only used it in contexts where I build both sides of the application.
platz 7y ago
You don't have to define a type for Json data in Haskell if you don't want to. Defining a full type is only norm/preference. With Aeson, You always have the option work with a map directly and pull out properties by name. That is also especially useful when you can't predict what keys or shape the data will have
- marcosdumay 7y ago
  I don't want to detract from Aeson. It's a great library. If you control both ends of your channel, it can be more convenient than the equivalent encoding and decoding on Javascript, and making a JSON library that is more convenient than JS is no small feat. But it's a very complex library. It may not show at your code interface, but that complexity is there at the documentation and type errors. It is also famous for generating bad runtime messages. There is even another library for fixing this, at the cost of even more complexity. If you fall outside of its optimum usage scenario, it won't afford you more functionality than a low level parser, so you are much better saving that complexity and going with the parser.
  - platz 7y ago
    Ok, so use a parser then? Not sure what this has to do with comparison to dynlang/js. OP was complaining that it's hard to type some kinds of payloads. Sure you could write a custom parser for it. With fromJSON in fact this is what you write. Maybe if you've only been driving Json instances generically, you never actually written a fromJSON instance in Aeson? I only use generic deriving in the simplest cases.. otherwise just write the fromJSON instance parser My point was that you can defer parsing up front and just return a map of you don't want deal with the shape. But sure you could write a custom parser as well, that falls more into the typed philosophy though than what js folks are used to