Newest at the top
| 2025-03-03 23:29:49 +0100 | <haskellbridge> | <Liamzee> monochrom: partially because people are trained to talk to their audience and they're making the assumption that they're talking to amoeba simpletons, or that doing so provides the best tradeoff between their ability to communicate their ideas and the respect for their audience |
| 2025-03-03 23:29:45 +0100 | gmg | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2025-03-03 23:29:40 +0100 | <monochrom> | People have already seen C++ so "like C++ operator overloading but more organized" is the better story and gets there faster. |
| 2025-03-03 23:28:23 +0100 | <c_wraith> | the "like a java interface" thing breaks down basically as soon as you hit something as complex as Eq, but it at least gets people looking less in the wrong direction |
| 2025-03-03 23:28:06 +0100 | <monochrom> | Also why do people have to speak in simpleton amoeba terms of "is like, is not like"? |
| 2025-03-03 23:28:03 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 244 seconds) |
| 2025-03-03 23:27:52 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-03 23:27:30 +0100 | <int-e> | lie-to-children territory |
| 2025-03-03 23:27:19 +0100 | <int-e> | monochrom: The "it's more like a Java interface" is specifically for trying to build a bridge to people with an OO background. It's not meant to be super accurate. |
| 2025-03-03 23:26:48 +0100 | <dolio> | And sometimes give strange, unrealistic examples in support of certain OO designs. |
| 2025-03-03 23:26:21 +0100 | <monochrom> | Oh, about "like interface", am I the only one who recognize this? You have two solutions coming from two POVs to solve the same problem, that's why they feel "similar" but also "different". They solve the same problem. They are opposite approaches. It's very simple. Why is it confusing? |
| 2025-03-03 23:26:09 +0100 | <dolio> | And a vaguer problem is that mainstream programmer 'culture' has overpopularized the bad designs. Or did at one time. |
| 2025-03-03 23:25:32 +0100 | <Rembane> | int-e: The tagless final goodness? |
| 2025-03-03 23:25:22 +0100 | <dolio> | The 'problem' is some OO languages is that OO designs aren't good for certain things, but you can be forced to use the bad designs because better ones don't exist. |
| 2025-03-03 23:25:07 +0100 | <int-e> | My perception is that this phenomenon is *old* and was never embraced by Haskell programmers except for doing crazy things often attributed to Oleg ;-). |
| 2025-03-03 23:24:10 +0100 | <int-e> | "No, `class` is not an OO class. It's more like a Java interface." [...] "No, we do not do the Java EE thing where every single structure is first defined as an interface and then a type that implements it." [...] "I'm sorry to hear that your code is a mess but it's largely because you used the wrong ideas and abstractions for this language." |
| 2025-03-03 23:24:06 +0100 | <monochrom> | People don't have to abuse OOP. And there are tons of ways to abuse FP too. |
| 2025-03-03 23:23:41 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-03 23:23:31 +0100 | <monochrom> | Look, even when I teach parametricity vs ad hoc, I come clean and note that although OOP formally allows ad hoc (as in, the "same" method on different types may have arbitrary differences), I note that I am scaremongering, real programmers don't normally do really arbitrary differences, actually the "different" behaviours are closely related and the differences reasonable and necessary. It's a spectrum with grey areas not just boolean black and white. |
| 2025-03-03 23:23:28 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-03 23:22:57 +0100 | <c_wraith> | The only real abuse of type classes I've seen is when someone wants to share names for something that there is no way to use interchangeably. |
| 2025-03-03 23:22:34 +0100 | <haskellbridge> | <Liamzee> or a possibility if someone learns OOP after coming from Haskell |
| 2025-03-03 23:22:20 +0100 | <dolio> | Just assuming that type classes should be used like OOP. |
| 2025-03-03 23:22:18 +0100 | <jle`> | usually when you write typeclass-polymorphic code you'd like to be able to reason with it. so with lawless typeclasses this is kind of hard. typeclasses have a lot of weight, being global and not hideable, so this can make things a bit tricky in practice |
| 2025-03-03 23:22:17 +0100 | <c_wraith> | Orphan instances are actually supported better by tooling than they used to be. Haddock now lists orphan instances declared in a module |
| 2025-03-03 23:21:47 +0100 | <dolio> | It sounds like something that commonly happens when someone learns Haskell after coming from OOP. |
| 2025-03-03 23:21:24 +0100 | <dolio> | No. |
| 2025-03-03 23:20:51 +0100 | <haskellbridge> | <Liamzee> but afaik that was in vogue a long time ago, wasn't it? then haskellers found out it was horrible and warned against it? |
| 2025-03-03 23:20:31 +0100 | simplystuart | (~simplystu@c-75-75-152-164.hsd1.pa.comcast.net) |
| 2025-03-03 23:20:23 +0100 | <monochrom> | No programming language can ban all abuses. |
| 2025-03-03 23:20:00 +0100 | simplystuart | (~simplystu@c-75-75-152-164.hsd1.pa.comcast.net) (Ping timeout: 244 seconds) |
| 2025-03-03 23:19:54 +0100 | <haskellbridge> | <Liamzee> i mean the only obviously bad thing that springs to mind is orphan instances |
| 2025-03-03 23:19:45 +0100 | <monochrom> | All abuses are smelly. Well, much worse than smelly, it's criminal. |
| 2025-03-03 23:19:08 +0100 | <haskellbridge> | <Liamzee> well, a different, more concrete question, what happened with the typeclass abuse thing, and why was it considered smelly? i.e, ad-hoc, lawless typeclasses intended to create OOP-style methods and functionality? |
| 2025-03-03 23:17:58 +0100 | <jle`> | i guess you could formalize it by seeing it in terms of `forall a. NumDict a -> a`, (forall a. NumDict a -> [a] -> r) -> r, and `forall a. NumDict a` |
| 2025-03-03 23:17:16 +0100 | <jle`> | so it's kind of neat when you CPS transform it you can see the Num/Fractional visually pop from negative to positive |
| 2025-03-03 23:16:14 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds) |
| 2025-03-03 23:16:07 +0100 | <jle`> | yeah my two example types were the cps'd data N = forall a. Num a => N [a] and data F = forall a. Fractional a => F [a] |
| 2025-03-03 23:15:21 +0100 | <monochrom> | OTOH I'll admit it's flipped with "data N' = N' (forall a. Num a => a)" and the analogous F' |
| 2025-03-03 23:15:18 +0100 | <jle`> | yeah in the case i was talking about, F would be considered the subtype. only i use => F [a] instead of => F a |
| 2025-03-03 23:15:01 +0100 | <dolio> | Existentials like that sort of have the class in positive position. |
| 2025-03-03 23:14:45 +0100 | <dolio> | Yes. |
| 2025-03-03 23:14:39 +0100 | <monochrom> | If you give me an F value, I can repackage it as an N value. |
| 2025-03-03 23:14:19 +0100 | <monochrom> | Wait. So consider the existential types "data N = forall a. Num a => N a" and "data F = forall a. Fractional a => F a". Which one is a subtype of which? I think F is the subtype. |
| 2025-03-03 23:13:06 +0100 | myxos | (~myxos@syn-065-028-251-121.res.spectrum.com) myxokephale |
| 2025-03-03 23:12:31 +0100 | <jle`> | it's still a bit weird to think of `Num` alone as positive but i guess there is no need to formalize that |
| 2025-03-03 23:11:39 +0100 | <dolio> | Yeah. |
| 2025-03-03 23:11:22 +0100 | <jle`> | if Num is negative in forall a. Num a => [a] -> r then it'd be positive in (forall a. Num a => [a] -> r) -> r |
| 2025-03-03 23:11:18 +0100 | <monochrom> | s/You just/You know/ |
| 2025-03-03 23:11:13 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |