Newest at the top
| 2025-11-11 03:24:24 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-11 03:15:46 +0100 | Googulator83 | (~Googulato@2a01-036d-0106-0180-8127-ba79-55a7-6f29.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-11-11 03:15:42 +0100 | Googulator53 | (~Googulato@2a01-036d-0106-0180-8127-ba79-55a7-6f29.pool6.digikabel.hu) |
| 2025-11-11 03:13:28 +0100 | <jreicher> | Thanks for the link! |
| 2025-11-11 03:12:55 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-11-11 03:12:04 +0100 | peterbecich | (~Thunderbi@172.222.148.214) peterbecich |
| 2025-11-11 03:10:04 +0100 | <monochrom> | Actually this! https://www.cs.utoronto.ca/~trebla/CSCC24-latest/ |
| 2025-11-11 03:09:40 +0100 | <monochrom> | I teach basic Haskell and basic Curry. And some PL topics, e.g., grammars, parsing, type inference, parametricity. |
| 2025-11-11 03:09:31 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2025-11-11 03:08:41 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-11 03:07:14 +0100 | <jreicher> | It cheers me even that those words might enter the classroom. |
| 2025-11-11 03:06:56 +0100 | <monochrom> | For students who are too used to pure math, especially the non-constructive one, I will have to bias them towards more explicit construction, even constructivism, yeah. |
| 2025-11-11 03:06:53 +0100 | <int-e> | And it's common that you use flawed analogies for new concepts when teaching. |
| 2025-11-11 03:06:30 +0100 | <jreicher> | monochrom: do you teach Haskell, or some of the other languages and/or lambda calculus/semantics? |
| 2025-11-11 03:06:01 +0100 | <int-e> | monochrom's teaching this stuff |
| 2025-11-11 03:05:57 +0100 | <monochrom> | No worries. I say "think math functions, algebra" to students who are too used to imperative thinking. They already can't escaping thinking of recipes for explicit construction. So telling them "like algebra" will get the right result. |
| 2025-11-11 03:05:43 +0100 | <int-e> | I didn't say that you're wrong (you aren't) |
| 2025-11-11 03:05:20 +0100 | <jreicher> | No argument with that, but there are still problems with the math model. You can define a non-computable function mathematically. |
| 2025-11-11 03:04:13 +0100 | <int-e> | (they do a decent job capturing purity) |
| 2025-11-11 03:03:41 +0100 | otto_s | (~user@p4ff27119.dip0.t-ipconnect.de) |
| 2025-11-11 03:03:37 +0100 | <int-e> | jreicher: I think the point is that math functions are a better model for what Haskell functions are than C functions. |
| 2025-11-11 03:01:46 +0100 | <monochrom> | About many ruby forms can't be combined. Yeah even the javascript community discovered long ago that if an object method returns the object itself, then you can write obj.method1().method2().method3(), it's pretty neat. |
| 2025-11-11 03:01:43 +0100 | otto_s | (~user@p4ff2712e.dip0.t-ipconnect.de) (Ping timeout: 240 seconds) |
| 2025-11-11 03:01:11 +0100 | <jreicher> | ...a little different... |
| 2025-11-11 03:01:00 +0100 | <jreicher> | monochrom: I think Haskell functions are a third kind of function. Math functions are often (infinite) sets. Haskell functions describe a construction of the set, which is a little. But they do it declarative, which is why they're not like C functions. |
| 2025-11-11 02:57:23 +0100 | <EvanR> | or old currencies, because the euro was abandoned |
| 2025-11-11 02:56:59 +0100 | <int-e> | (and possibly new currencies) |
| 2025-11-11 02:56:41 +0100 | <int-e> | (adjusted for inflation relative to 2025) |
| 2025-11-11 02:56:30 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2025-11-11 02:55:53 +0100 | <EvanR> | the 1 TRILLION dollar mistake *crowd laughs* |
| 2025-11-11 02:55:34 +0100 | <int-e> | EvanR: can't wait for the paper on the trillion-dollar mistake in about 50 years |
| 2025-11-11 02:55:09 +0100 | <EvanR> | so many forms in ruby return nothing useful and so can't be combined |
| 2025-11-11 02:55:07 +0100 | <monochrom> | If the null pointer was a billion-dollar mistake, I invoke Sapir-Worf and call that a priceless mistake. |
| 2025-11-11 02:54:56 +0100 | <EvanR> | returning a value was undervalued all the way even until ruby |
| 2025-11-11 02:54:00 +0100 | <monochrom> | The Algol people got it wrong in the first place. They said "side-effecting functions" [sic], just because there is a "return value". |
| 2025-11-11 02:53:18 +0100 | <int-e> | It's an overloaded concept, one of many. |
| 2025-11-11 02:53:07 +0100 | <int-e> | And sorry, I believe "function" is too ingrained in my brain by now. |
| 2025-11-11 02:52:54 +0100 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2025-11-11 02:52:52 +0100 | synchromesh | (~john@2406:5a00:2412:2c00:ed84:4ebe:de81:99a2) synchromesh |
| 2025-11-11 02:52:51 +0100 | <monochrom> | If foo :: IO Int, what do you call foo, i.e., what is the name of the kind of things like foo? Answer: procedure. |
| 2025-11-11 02:52:37 +0100 | gorignak | (~gorignak@user/gorignak) (Quit: quit) |
| 2025-11-11 02:52:27 +0100 | <int-e> | (A Pascal remnant, though Pascal's distinction based on whether a function returns a value or not is odd too.) |
| 2025-11-11 02:52:17 +0100 | <monochrom> | We should do that more! |
| 2025-11-11 02:51:56 +0100 | synchromesh | (~john@2406:5a00:2412:2c00:c5a6:321c:259:76f2) (Read error: Connection reset by peer) |
| 2025-11-11 02:51:56 +0100 | int-e | wonders when he last used the term "procedure" for an imperative "function". |
| 2025-11-11 02:51:12 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-11 02:50:45 +0100 | <EvanR> | though maybe subjecting them to enough haskell gives them a better appreciation for mathematical thinking |
| 2025-11-11 02:50:38 +0100 | <monochrom> | Oh if you hate math, there is nothing in Haskell for you. |
| 2025-11-11 02:50:05 +0100 | <EvanR> | ^ this very good advice has no effect on people who hate math |
| 2025-11-11 02:48:57 +0100 | <monochrom> | But I do tell my students: Think of Haskell functions as math functions, not C "functions". Think algebra. |