Logs: liberachat/#haskell
| 2021-07-10 16:39:38 | <Profpatsch> | No automatic binding of encoder or decoder functions to types |
| 2021-07-10 16:39:43 | → | lerzer joins (~lerzer@101.175.100.42) |
| 2021-07-10 16:40:01 | <s__> | I'd like to have just Aeson.Value in a separate package (aeson-types?), for cases when I don't need encoding/decoding or want to use an alternative encoder/decoder |
| 2021-07-10 16:40:16 | <s__> | the number of dependencies in aeson is out of hand |
| 2021-07-10 16:40:18 | <Profpatsch> | if you need to decode something, write a pof for it that returns an aeson Parser |
| 2021-07-10 16:40:56 | <dsal> | That's necessary sometimes, but elm, e.g. requires that for every type and it's quite tedious there. |
| 2021-07-10 16:40:56 | <Profpatsch> | s__: I feel like the best way forward is to split these things out into dependencies of aeson |
| 2021-07-10 16:41:09 | <ahdyt> | does that also make it unable to magically derive anything? |
| 2021-07-10 16:41:32 | <Profpatsch> | e.g. have an aeson-fromjson-tojson package that just has the class & instances |
| 2021-07-10 16:41:56 | <Profpatsch> | ahdyt: you don’t want any magic in your API boundary |
| 2021-07-10 16:41:58 | <lbseale> | So to summarize the answer, you should only use ToJSON and FromJSON if you know that the layout of your JSON will always match your Haskell record ... but it likely never will so don't use them |
| 2021-07-10 16:41:59 | <Profpatsch> | is all I’m saying |
| 2021-07-10 16:42:13 | ← | lerzer parts (~lerzer@101.175.100.42) () |
| 2021-07-10 16:42:42 | <ahdyt> | ah okay? |
| 2021-07-10 16:43:09 | <dsal> | I use FromJSON and ToJSON when they aren't aligned very well because the classes give me a common way to send and receive records when communicating withs ervices. |
| 2021-07-10 16:44:02 | <dsal> | You have to have a function somewhere, so having a default one attached to a class is as good as any. Then you don't have to worry about naming hundreds of things that are all reasonable defaults. |
| 2021-07-10 16:44:07 | <ahdyt> | I wonder if there's any FromJSON and ToJSON antipattern snippet or example? |
| 2021-07-10 16:44:19 | <dsal> | I think the argument here is "all of them" |
| 2021-07-10 16:45:10 | <Profpatsch> | I’d say the only sensible use of them is when you actually consume the same data on the other side, with the same Haskell types |
| 2021-07-10 16:45:18 | × | Gurkenglas quits (~Gurkengla@dslb-002-203-144-156.002.203.pools.vodafone-ip.de) (Read error: Connection reset by peer) |
| 2021-07-10 16:45:25 | <Profpatsch> | e.g. you have a foo-types package and a foo-server and a foo-client which both depend on foo-types |
| 2021-07-10 16:45:32 | <Profpatsch> | then you can use To/From all you want |
| 2021-07-10 16:45:47 | <dsal> | I've had incompatibilities come up when upstreams change and I just like, fix them. I still have to model what's correct for my own services and having common interfaces haven't hindered me. |
| 2021-07-10 16:45:50 | <Profpatsch> | (big disclaimer: iff you *always* deploy server and client together!) |
| 2021-07-10 16:45:51 | → | yauhsien joins (~yauhsien@118-167-64-241.dynamic-ip.hinet.net) |
| 2021-07-10 16:46:12 | → | Gurkenglas joins (~Gurkengla@dslb-002-203-144-156.002.203.pools.vodafone-ip.de) |
| 2021-07-10 16:46:34 | <Profpatsch> | we did that with a purescript frontend and it worked great |
| 2021-07-10 16:46:46 | × | falafel quits (~falafel@pool-96-255-70-50.washdc.fios.verizon.net) (Read error: Connection reset by peer) |
| 2021-07-10 16:47:01 | <Profpatsch> | Just generated the associated purescript code and deployed server & frontend in one go every time |
| 2021-07-10 16:47:03 | <dsal> | I have an implementation of a binary protocol that supports a couple major versions with marshaling and unmarshaling of a large number of types and deal with it by just passing the version around so they know which features make the wire and which don't. |
| 2021-07-10 16:47:21 | <bryan[m]> | In my opinion, there's nothing wrong with To/FromJSON , but it's unwise to think your api types are the same as your model types. |
| 2021-07-10 16:48:27 | <dsal> | Model types and API types can sometimes conveniently be the same. I don't go out of my way to separate them, but sometimes regret not going out of my way to separate them. Refactoring is fun, though. :) |
| 2021-07-10 16:48:30 | × | coeus_ quits (~coeus@b2b-92-50-96-34.unitymedia.biz) (Quit: Leaving) |
| 2021-07-10 16:48:50 | → | falafel joins (~falafel@pool-96-255-70-50.washdc.fios.verizon.net) |
| 2021-07-10 16:50:03 | <bryan[m]> | In effect, we're all saying the same thing: that data coming from json might not be exactly the right shape our programs need. I just think one shouldn't shoot the messenger. :) |
| 2021-07-10 16:50:18 | → | merijn joins (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-07-10 16:50:28 | × | yauhsien quits (~yauhsien@118-167-64-241.dynamic-ip.hinet.net) (Ping timeout: 252 seconds) |
| 2021-07-10 16:52:43 | <dsal> | I've had some kind of gross FromJSON impls to do that, but... that code has to live somewhere and naming is hard. |
| 2021-07-10 16:53:34 | → | Pickchea joins (~private@user/pickchea) |
| 2021-07-10 16:54:15 | <sshine> | it sounds like one would wanna newtype before ToJSON/FromJSON'ing and have those newtypes relate to e.g. an API. :) |
| 2021-07-10 16:54:53 | <sshine> | dsal, is that much more expensive? |
| 2021-07-10 16:55:42 | <dsal> | It's just a different thing to name / different way to structure the "plain old function" kind of concept, but with classes, so not totally plain. |
| 2021-07-10 16:57:08 | <dsal> | I don't think it's expensive in any meaningful way, but I have a type that represents a thing, and some upstream has a JSON object that represents that thing in one way or another. I might very well have to do some work to get from there to here. I'm not bothered by doing that inside the FromJSON instance. |
| 2021-07-10 16:57:39 | <ahdyt> | sshine hahaha is this related to my previous question & snippet that I've shared? |
| 2021-07-10 16:58:04 | × | qbt quits (~edun@user/edun) (Ping timeout: 272 seconds) |
| 2021-07-10 16:58:32 | <lbseale> | So speaking of writing FromJSON instances, I really like ITProTV's recommendation about writing them in do notation: https://engineering.itpro.tv/haskell-style-guide/#prefer-monads-for-building-records |
| 2021-07-10 16:59:24 | × | chexum quits (~chexum@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2021-07-10 17:02:47 | <dsal> | I don't understand this. Why is that better? |
| 2021-07-10 17:03:21 | <dsal> | Just because of field order? |
| 2021-07-10 17:04:08 | × | Atum_ quits (~IRC@user/atum/x-2392232) (Quit: Atum_) |
| 2021-07-10 17:04:38 | <dsal> | It also says to avoid list comprehensions immediately above that because... someone might not know what they do? |
| 2021-07-10 17:04:48 | → | Atum_ joins (IRC@user/atum/x-2392232) |
| 2021-07-10 17:05:32 | <lbseale> | yeah because it avoids the field order |
| 2021-07-10 17:06:31 | → | mc47 joins (~mc47@xmonad/TheMC47) |
| 2021-07-10 17:06:43 | <hpc> | even though list comprehensions and do notation are the same thing? |
| 2021-07-10 17:08:01 | <Las[m]> | How would I convert a ParsecT e s Identity a to a ParsecT e s IO a from Megaparsec? I assume there's some general trick applicable here to lift it, but I can't find any function that does what I want. |
| 2021-07-10 17:08:23 | <dsal> | @undo [ x * 2 | x <- xs, x > 0 ] |
| 2021-07-10 17:08:23 | <lambdabot> | concatMap (\ x -> if x > 0 then [x * 2] else []) xs |
| 2021-07-10 17:10:21 | <hpc> | a better translation is do {x <- xs; guard (x > 0); pure (x * 2)} |
| 2021-07-10 17:11:07 | <dsal> | Some of these recommendations are just bad. It's like, "Don't write `getLine >>= print`." It thinks it's always better to name the intermediate value and then pass it to the function. |
| 2021-07-10 17:11:13 | → | tzh joins (~tzh@c-24-21-73-154.hsd1.or.comcast.net) |
| 2021-07-10 17:11:34 | <dsal> | Also, don't use multiple function heads when you could just have a case statement. |
| 2021-07-10 17:12:17 | <dsal> | "Prefer let over where" -- is this list a joke? |
| 2021-07-10 17:13:01 | <dsal> | "Avoid language extensions" -- like... all of them. |
| 2021-07-10 17:14:28 | <hpc> | even avoid the ones that are on by default |
| 2021-07-10 17:14:35 | <hpc> | build with every -XNo* flag :D |
| 2021-07-10 17:16:07 | <c_wraith> | I wonder if avoiding language extensions means you aren't allowed to use ST |
| 2021-07-10 17:16:10 | <dsal> | There are a few things in this list that are good, but many of them seem like the opposite of what would be useful. They clearly use OverloadedStrings in this list after saying you should avoid all language extensions. |
| 2021-07-10 17:16:17 | <dsal> | Does ST require language extensions? |
| 2021-07-10 17:16:33 | <c_wraith> | defining it does. Using it... well, it requires something that required it. :) |
| 2021-07-10 17:17:05 | <c_wraith> | And ugh. OverloadedStrings is one of the worst extensions in GHC. |
| 2021-07-10 17:17:19 | <monochrom> | I always go to the meta level, as you know. At the meta level, inflexible do's-and-don't's lists are always bad. |
| 2021-07-10 17:17:34 | <dsal> | Some are badder than others. |
| 2021-07-10 17:18:11 | <c_wraith> | Some extensions really are just pure awesome. |
| 2021-07-10 17:18:58 | <c_wraith> | RankNTypes is just a wonderful expansion of the type system, for instance. |
| 2021-07-10 17:19:45 | <c_wraith> | Matched only by Rank2Types and PolymorphicComponents. (It is a bit silly that the same extension has 3 different names) |
| 2021-07-10 17:19:47 | <monochrom> | People already know list comprehension from python. |
| 2021-07-10 17:20:11 | <dsal> | Do not learn anything that will make your job easier. |
| 2021-07-10 17:20:33 | <monochrom> | It takes living under a rock in a corner of a cave to worry "some people may have never seen list comprehension". |
| 2021-07-10 17:21:21 | <monochrom> | In that case why not also advocate "some people may have never seen lambdas". |
| 2021-07-10 17:21:25 | <c_wraith> | I tend to avoid list comprehensions anyway. As a special syntactic form they just aren't as composable as the functions they desugar to. |
| 2021-07-10 17:22:26 | <monochrom> | The fundamental problem with mixfix syntax :) |
| 2021-07-10 17:22:36 | <c_wraith> | yep |
| 2021-07-10 17:22:51 | <dsal> | Their case, though.. bad: `[ x * 2 | x <- xs, x > 0 ]` good: `map (* 2) (filter (> 0) xs)` OK: `do x <- xs; guard (x > 0); pure (x * 2)` |
| 2021-07-10 17:23:44 | <dsal> | I guess I wouldn't be offended by "bad" or "good" there. I'd be offended by having to work with someone who couldn't read either. |
| 2021-07-10 17:24:10 | × | merijn quits (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 240 seconds) |
| 2021-07-10 17:24:11 | <monochrom> | Another meta argument is that with someone calling themselves "IT pro" you can safely bet this is an inflated melodramatic ego and must be completely distrusted. |
| 2021-07-10 17:24:39 | <monochrom> | Beware of people calling themselves ITPro or NextGenHacker |
| 2021-07-10 17:25:52 | <monochrom> | https://youtu.be/SXmv8quf_xM is what you get from someone calling themselves NextGenHacker. |
| 2021-07-10 17:26:01 | <monochrom> | You get the TracerT monad transformer! |
| 2021-07-10 17:28:40 | <Rembane> | :O |
| 2021-07-10 17:29:27 | <dsal> | They That video is amazing. |
| 2021-07-10 17:30:43 | × | azeem quits (~azeem@176.201.17.130) (Ping timeout: 265 seconds) |
| 2021-07-10 17:30:49 | <monochrom> | A classic. :) |
| 2021-07-10 17:30:58 | → | azeem joins (~azeem@176.201.17.130) |
| 2021-07-10 17:33:47 | × | mikoto-chan quits (~mikoto-ch@ip-213-49-189-31.dsl.scarlet.be) (Read error: Connection reset by peer) |
| 2021-07-10 17:33:48 | <hpc> | isp sysadmin prank: if the packet ttl isn't enough to make it all the way through your network, start routing it in random directions |
| 2021-07-10 17:35:07 | × | shredder quits (~user@user/shredder) (Quit: quitting) |
| 2021-07-10 17:35:26 | → | shredder joins (~user@user/shredder) |
| 2021-07-10 17:38:54 | → | mikoto-chan joins (~mikoto-ch@ip-213-49-189-31.dsl.scarlet.be) |
All times are in UTC.