Newest at the top
| 2025-03-03 23:43:47 +0100 | <constxd> | and then it's literally just pure |
| 2025-03-03 23:43:39 +0100 | <constxd> | in haskell it doesn't matter i guess because you just apply f immediately, there's no difference |
| 2025-03-03 23:43:12 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2025-03-03 23:43:08 +0100 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-03-03 23:42:49 +0100 | <jackdk> | Liamzee: any chance you can say more about the problem you're modelling? |
| 2025-03-03 23:42:34 +0100 | <jackdk> | Liamzee: I have never found OOP to be a scalable technique. As soon as you work on two types of data, you have to make hard choices about which OOclass "owns" the method, or invent dubious nouns to hold a single function of two arguments. |
| 2025-03-03 23:42:03 +0100 | <monochrom> | jackdk: This is how I teach Haskell type classes. At the end there is also a little discussion about C++ and Java. https://www.cs.utoronto.ca/~trebla/CSCC24-latest/04-haskell-types-2.html |
| 2025-03-03 23:41:57 +0100 | <constxd> | but in a language with colored async functions (python), i have this: def foo(f, *xs): async def g(): return f(*xs); return g |
| 2025-03-03 23:40:32 +0100 | <constxd> | i guess maybe this question doesn't really make sense in haskell |
| 2025-03-03 23:40:08 +0100 | <monochrom> | either that, or at call sites just "pure (f x)" without making a name for it. |
| 2025-03-03 23:39:45 +0100 | <monochrom> | I think I'll just use "pure . f" |
| 2025-03-03 23:39:32 +0100 | <constxd> | wait no |
| 2025-03-03 23:39:22 +0100 | <constxd> | foo f x = pure (f x) |
| 2025-03-03 23:38:58 +0100 | <constxd> | what might u name this function? |
| 2025-03-03 23:38:50 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-03 23:38:29 +0100 | <haskellbridge> | <Liamzee> so, ummm, if i were to do a more OOP-ish appproach, I guess what I'd be looking for would be to set up data modules and do import qualified as? |
| 2025-03-03 23:37:57 +0100 | <monochrom> | OK sorry. I didn't intend it. |
| 2025-03-03 23:37:21 +0100 | <int-e> | monochrom: your condescension has been noted and is totally uncalled for |
| 2025-03-03 23:37:14 +0100 | <jackdk> | It would be cool to see you teach someday |
| 2025-03-03 23:37:07 +0100 | <monochrom> | For example, as said, either I bridge with "like C++ operator overloading" or "both Java and Haskell try to solve this same problem but they came up with different approaches because the solution has to fit with the rest of the language". |
| 2025-03-03 23:36:07 +0100 | <monochrom> | int-e, jackdk: I am a good teacher, I do bridging all the time, and actually precisely because of that, my bridges are much clearer and have more predictive power than puny "is like". |
| 2025-03-03 23:34:40 +0100 | <jackdk> | monochrom: 'why do people have to speak in simpleton amoeba terms of "is like, is not like"?' I see it as "first you have to get a rope across the chasm': you get some idea across and then you refine the wrong idea into a less wrong idea. IME, not as many people can grok a concept from definitions up |
| 2025-03-03 23:34:34 +0100 | <monochrom> | Oh I have already long concluded that they are on drugs. |
| 2025-03-03 23:34:09 +0100 | <dolio> | When you're talking about "doses" and stuff. |
| 2025-03-03 23:33:57 +0100 | <dolio> | Careful. People will think you're on drugs or something. |
| 2025-03-03 23:33:50 +0100 | <haskellbridge> | <Liamzee> but afaik haskell doesn't favor using ad-hoc typeclasses does it, because the syntax is often much worse (need to write instances to multiple typeclasses is obnoxious) |
| 2025-03-03 23:32:57 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-03-03 23:32:41 +0100 | zungi | (~tory@user/andrewchawk) andrewchawk |
| 2025-03-03 23:32:13 +0100 | <jle`> | so that's nice |
| 2025-03-03 23:32:08 +0100 | <jle`> | there is a decent overlap between coffee snobs and programmers |
| 2025-03-03 23:31:54 +0100 | j1n37- | (~j1n37@user/j1n37) (Ping timeout: 252 seconds) |
| 2025-03-03 23:31:34 +0100 | <c_wraith> | talk to more coffee snobs |
| 2025-03-03 23:30:56 +0100 | <monochrom> | heh |
| 2025-03-03 23:30:44 +0100 | <jle`> | one thing i miss about writing enterprise java was saying the word Bean out loud |
| 2025-03-03 23:30:28 +0100 | gmg | (~user@user/gehmehgeh) gehmehgeh |
| 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 ;-). |