Newest at the top
| 2024-05-14 07:58:11 +0200 | danza | (~francesco@151.57.195.82) (Ping timeout: 256 seconds) |
| 2024-05-14 07:54:06 +0200 | michalz | (~michalz@185.246.207.200) |
| 2024-05-14 07:52:41 +0200 | euleritian | (~euleritia@dynamic-176-006-192-246.176.6.pool.telefonica.de) |
| 2024-05-14 07:52:08 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 252 seconds) |
| 2024-05-14 07:51:38 +0200 | euphores | (~SASL_euph@user/euphores) (Quit: Leaving.) |
| 2024-05-14 07:51:08 +0200 | michalz | (~michalz@185.246.207.193) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-05-14 07:42:23 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2024-05-14 07:30:53 +0200 | danza | (~francesco@151.57.195.82) |
| 2024-05-14 07:30:37 +0200 | danza | (~francesco@151.57.214.17) (Read error: Connection reset by peer) |
| 2024-05-14 07:30:03 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2024-05-14 07:23:55 +0200 | mei | (~mei@user/mei) |
| 2024-05-14 07:22:07 +0200 | mei | (~mei@user/mei) (Remote host closed the connection) |
| 2024-05-14 07:22:03 +0200 | acidjnk_new | (~acidjnk@p200300d6e714dc51e96b24be77fae744.dip0.t-ipconnect.de) |
| 2024-05-14 07:21:18 +0200 | <danza> | "... for readability" that is also a good one |
| 2024-05-14 07:20:40 +0200 | <danza> | "haskell's syntax is a complete disaster" haha nice joke |
| 2024-05-14 07:16:28 +0200 | <glguy> | oh, no |
| 2024-05-14 07:15:37 +0200 | <cheater> | so you're basically the "haskell is unreadable" person |
| 2024-05-14 07:15:20 +0200 | <glguy> | I would avoid using such a language, but I don't think it exists |
| 2024-05-14 07:13:53 +0200 | <cheater> | have you used the language i'm describing? |
| 2024-05-14 07:13:34 +0200 | remmie | (ianremsen@tilde.team) |
| 2024-05-14 07:13:03 +0200 | mei | (~mei@user/mei) |
| 2024-05-14 07:12:55 +0200 | <glguy> | no, that's not a common take on people who've actually used it |
| 2024-05-14 07:12:51 +0200 | <cheater> | if you lose track of that then your code is too messy anyways |
| 2024-05-14 07:12:42 +0200 | <cheater> | yeah you know that one usually when reading code |
| 2024-05-14 07:12:30 +0200 | <cheater> | idk that it would be, people say haskell's syntax is a complete disaster for readability too |
| 2024-05-14 07:12:17 +0200 | <glguy> | now to know what: f x y means, you have to work out the types of f, x, and y before you can know which thing is which |
| 2024-05-14 07:11:59 +0200 | <glguy> | beyond it simply not working with the way types in Haskell work, it'd be a complete disaster for readability |
| 2024-05-14 07:11:31 +0200 | michalz | (~michalz@185.246.207.193) |
| 2024-05-14 07:10:38 +0200 | mei | (~mei@user/mei) (Remote host closed the connection) |
| 2024-05-14 07:10:34 +0200 | <cheater> | but i don't think that's an issue |
| 2024-05-14 07:10:29 +0200 | <glguy> | all functions have one argument; no functions have two |
| 2024-05-14 07:10:29 +0200 | <cheater> | i see where you're coming from |
| 2024-05-14 07:10:21 +0200 | <cheater> | ok ok |
| 2024-05-14 07:10:18 +0200 | <glguy> | but that doesn't mean you can't apply the result as a function |
| 2024-05-14 07:10:08 +0200 | <glguy> | function in haskell *only* have one argument |
| 2024-05-14 07:10:08 +0200 | <cheater> | id only has one argument |
| 2024-05-14 07:10:00 +0200 | <glguy> | You need to know the order of application to even attempt to type-check an expression |
| 2024-05-14 07:09:38 +0200 | <lambdabot> | a -> a |
| 2024-05-14 07:09:37 +0200 | <glguy> | :t id |
| 2024-05-14 07:09:35 +0200 | <lambdabot> | 11 |
| 2024-05-14 07:09:34 +0200 | <glguy> | > id succ 10 |
| 2024-05-14 07:09:31 +0200 | <cheater> | why |
| 2024-05-14 07:09:14 +0200 | <glguy> | cheater: that would only make sense in a vary narrow subset of Haskell |
| 2024-05-14 07:00:59 +0200 | <cheater> | like what languages are you thinking of |
| 2024-05-14 06:46:16 +0200 | <danza> | other languages that support out-of-order arguments end up with a syntax similar to { arg = val } like one would easily achieve with a product type |
| 2024-05-14 06:44:29 +0200 | <cheater> | whatever's useful |
| 2024-05-14 06:44:17 +0200 | <cheater> | so what if we had a type constructor that's like (->) but binds less tightly than (->) and doesn't care about order. say (&). You could write f :: X & A -> B -> C & Y & Z -> Out, and then you could go like f a b c x y z, or f a x b y c z, or f x y z a b c |
| 2024-05-14 06:42:23 +0200 | <cheater> | if you look at type sigs, f :: A -> B -> C is basically a tuple. the only reason it's not exactly the same thing as (A, B, C) is currying. |
| 2024-05-14 06:41:56 +0200 | <cheater> | idk what you're saying |
| 2024-05-14 06:40:39 +0200 | <danza> | make a product type for that? |