Newest at the top
| 2026-06-16 19:52:56 +0000 | <mauke> | what's confusing about RAII? |
| 2026-06-16 19:52:33 +0000 | <mauke> | compromise: repure |
| 2026-06-16 19:51:32 +0000 | <monochrom> | In Haskell, we have our share in choosing the name "return". (We are now trying to change it to "pure".) |
| 2026-06-16 19:50:58 +0000 | <yin> | guidelines are for suckers. parse, don't validate |
| 2026-06-16 19:50:03 +0000 | <vms14> | https://wiki.haskell.org/Programming_guidelines |
| 2026-06-16 19:49:35 +0000 | <monochrom> | to the point I'm now cynical and just say that meaningful names are lies. |
| 2026-06-16 19:49:33 +0000 | <vms14> | i should read it |
| 2026-06-16 19:49:23 +0000 | <vms14> | there is a post aobut conventions to follow? |
| 2026-06-16 19:48:32 +0000 | <monochrom> | Historically, programmers have had a long history of meaningful names that confuse, mislead, or downright gaslight. Examples: RAII, bus factor, test pollution. |
| 2026-06-16 19:47:13 +0000 | <vms14> | it will also train me to read formulas |
| 2026-06-16 19:46:43 +0000 | <monochrom> | or "object". |
| 2026-06-16 19:46:27 +0000 | <monochrom> | reasoning being: more general things deserve broader names, so broad that you may as well just call it "x", it's as good as "thingy" or "foo". |
| 2026-06-16 19:46:08 +0000 | wickedjargon | (~user@207.194.126.21) wickedjargon |
| 2026-06-16 19:46:01 +0000 | <vms14> | i was thinking that it would be harder to name a type variable than a value variable |
| 2026-06-16 19:45:35 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds) |
| 2026-06-16 19:45:07 +0000 | <monochrom> | Practically, more general things are worth less of your time thinking up names. Extreme example: "id :: a -> a" there is really no point "improving" the "a" to something longer. (You can still argue about "id"; I would respect that.) |
| 2026-06-16 19:42:41 +0000 | petrichor | (~jez@user/petrichor) petrichor |
| 2026-06-16 19:41:16 +0000 | <monochrom> | Naively, it is good to use descriptive names. Cynically, it is extremely difficult to make them accurate and honest. |
| 2026-06-16 19:40:21 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-16 19:38:00 +0000 | petrichor | (~jez@user/petrichor) (Quit: ZNC 1.10.1 - https://znc.in) |
| 2026-06-16 19:30:48 +0000 | <jaror> | Like `List<A>` |
| 2026-06-16 19:30:42 +0000 | <jaror> | I think Java uses `A` a bunch for its generics |
| 2026-06-16 19:30:17 +0000 | <vms14> | often* |
| 2026-06-16 19:30:00 +0000 | <vms14> | ofthen in other languages this would be discouraged, but in haskell seems to be the contrary |
| 2026-06-16 19:29:49 +0000 | <jaror> | Something like `(res -> el -> res) -> res -> [el] -> res` seems acceptable to me |
| 2026-06-16 19:29:28 +0000 | <vms14> | it defeats the problem of not knowing how to name your vars also |
| 2026-06-16 19:28:56 +0000 | <jaror> | I guess there is a point that `result` is more informative than `b` |
| 2026-06-16 19:28:42 +0000 | <vms14> | still i'll just try to get used to letters instead |
| 2026-06-16 19:28:22 +0000 | <vms14> | yeah the name is not the best i guess |
| 2026-06-16 19:28:08 +0000 | <jaror> | All these are types so ending them with `Type` says nothing |
| 2026-06-16 19:27:50 +0000 | <vms14> | and that myFold signature is ugly for any haskeller |
| 2026-06-16 19:27:36 +0000 | <vms14> | but it feels like i should get used to those a and b |
| 2026-06-16 19:27:18 +0000 | <vms14> | instead of (b -> a -> b) -> b -> [a] -> b |
| 2026-06-16 19:26:57 +0000 | <vms14> | myFold :: (resultType -> inputType -> resultType) -> resultType -> [inputType] -> resultType |
| 2026-06-16 19:26:53 +0000 | <vms14> | for example this makes it very clear for me |
| 2026-06-16 19:26:51 +0000 | <jaror> | I prefer `a` over `theFirstArgument` for very generic functions |
| 2026-06-16 19:26:44 +0000 | <vms14> | so i should get used to use them instead of names? |
| 2026-06-16 19:26:16 +0000 | <vms14> | seems the convention is to use letters |
| 2026-06-16 19:26:06 +0000 | <vms14> | it is wrong to use descriptive names instead of a b c for type vars and x z xs for values? |
| 2026-06-16 19:25:16 +0000 | vms14 | (~vms14@user/vms14) vms14 |
| 2026-06-16 19:23:42 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2026-06-16 19:17:05 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-16 18:34:50 +0000 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2026-06-16 18:34:23 +0000 | <monochrom> | Unfortunately the author passed away years ago, and now their website ertes.eu has disappeared, so I can only point you to the wayback machine archive. They actually used to be here! |
| 2026-06-16 18:33:16 +0000 | <monochrom> | This was what inspired me to focus on teaching the recursion pattern. It uses the spirit of indcution. https://web.archive.org/web/20250615160509/http://ertes.eu/tutorial/foldr.html |
| 2026-06-16 18:30:48 +0000 | vms14 | (~vms14@user/vms14) (Quit: WeeChat 4.6.3) |
| 2026-06-16 18:27:08 +0000 | <monochrom> | And when I use induction, I care about the recursive code pattern only. |
| 2026-06-16 18:25:38 +0000 | <monochrom> | (Sure I will use "..." for communicating ideas.) |
| 2026-06-16 18:24:37 +0000 | <monochrom> | not even a formula that contains "...". |
| 2026-06-16 18:23:59 +0000 | <monochrom> | Here is another angle. When I care about correctness, I use induction, not a picture that contains "...". |