Logs: freenode/#haskell
| 2021-04-15 13:43:07 | <merijn> | L29Ah: User as in "compiler users" |
| 2021-04-15 13:43:30 | <merijn> | L29Ah: i.e. #ghc is strictly for "hacking on GHC questions" and not "programming Haskell questions" |
| 2021-04-15 13:45:09 | × | Mrbuck quits (~Mrbuck@gateway/tor-sasl/mrbuck) (Ping timeout: 240 seconds) |
| 2021-04-15 13:47:03 | → | waleee-cl joins (uid373333@gateway/web/irccloud.com/x-mduldyizmjdpywto) |
| 2021-04-15 13:47:44 | × | esp32_prog quits (~esp32_pro@37.120.201.122) (Ping timeout: 268 seconds) |
| 2021-04-15 13:48:13 | → | esp32_prog joins (~esp32_pro@37.120.201.122) |
| 2021-04-15 13:48:43 | × | lewky quits (~lewky@159.65.37.240) (Quit: Ping timeout (120 seconds)) |
| 2021-04-15 13:49:11 | → | lewky joins (~lewky@159.65.37.240) |
| 2021-04-15 13:51:03 | → | Pickchea joins (~private@unaffiliated/pickchea) |
| 2021-04-15 13:54:08 | → | Jd007 joins (~Jd007@162.156.11.151) |
| 2021-04-15 13:54:15 | × | esp32_prog quits (~esp32_pro@37.120.201.122) (Remote host closed the connection) |
| 2021-04-15 13:54:28 | → | esp32_prog joins (~esp32_pro@37.120.201.122) |
| 2021-04-15 13:57:14 | → | dmytrish joins (~mitra@2a02:8084:a82:d900:f811:9873:2623:c28b) |
| 2021-04-15 14:02:47 | → | lambdaman joins (~lambdaman@s66-183-152-156.bc.hsia.telus.net) |
| 2021-04-15 14:03:52 | × | frozenErebus quits (~frozenEre@37.231.244.249) (Ping timeout: 240 seconds) |
| 2021-04-15 14:04:17 | × | notzmv quits (~zmv@unaffiliated/zmv) (Ping timeout: 260 seconds) |
| 2021-04-15 14:04:30 | → | wonko7 joins (~wonko7@62.115.229.50) |
| 2021-04-15 14:07:37 | <kuribas> | Isn't allowing non-total computations more a question of culture rather than language? I find that haskell programmers are largely afraid of having non-total computations, even if it makes the code simpler, while a clojure programmer wouldn't care. |
| 2021-04-15 14:08:47 | <kuribas> | For example, having a combinator that outputs a runtime error instead of being proven correct in the type system, may be acceptable, as long as the error is done early. |
| 2021-04-15 14:09:09 | <kuribas> | As in, the code will always give an error if the combinator is applied wrongly. |
| 2021-04-15 14:09:28 | <nicholasbulka> | what exactly is a non total computation? |
| 2021-04-15 14:09:34 | → | Sgeo joins (~Sgeo@ool-18b98aa4.dyn.optonline.net) |
| 2021-04-15 14:09:56 | <kuribas> | nicholasbulka: a computation that in some cases results in a run-time error. |
| 2021-04-15 14:10:17 | <kuribas> | I am more thinking about using combinators to specify business logic. |
| 2021-04-15 14:10:27 | <nicholasbulka> | gotcha, how does Either fit into that? |
| 2021-04-15 14:10:28 | → | son0p joins (~ff@181.136.122.143) |
| 2021-04-15 14:10:36 | <nicholasbulka> | I apologize for my noob questions :-D |
| 2021-04-15 14:10:57 | <kuribas> | nicholasbulka: Either is fine, because it is total. |
| 2021-04-15 14:11:29 | <nicholasbulka> | so as opposed to finding an uncaught null value at runtime? |
| 2021-04-15 14:11:31 | → | notzmv joins (~zmv@unaffiliated/zmv) |
| 2021-04-15 14:11:46 | <kuribas> | yes |
| 2021-04-15 14:11:53 | <kuribas> | but IMO null values are not acceptable. |
| 2021-04-15 14:11:55 | <tdammers> | largely depends on what you consider a bottom |
| 2021-04-15 14:12:08 | <kuribas> | that's where clojure, java, etc, gets it wrong. |
| 2021-04-15 14:12:31 | <kuribas> | nicholasbulka: Either forces you to handle the error case. |
| 2021-04-15 14:12:47 | <tdammers> | but I would say that null is a perfectly fine value. it's just problematic to have it as a mandatory inhabitant of all user-defined types |
| 2021-04-15 14:13:14 | <hyperisco> | kuribas, but non-total can also mean it does not terminate |
| 2021-04-15 14:13:17 | <kuribas> | tdammers: true, but how would you do that without an option type? |
| 2021-04-15 14:14:08 | <kuribas> | hyperisco: yeah, the case I find acceptable is early crashing, with a meaningfull error message. |
| 2021-04-15 14:14:21 | × | nut quits (~user@roc37-h01-176-170-197-243.dsl.sta.abo.bbox.fr) (Ping timeout: 252 seconds) |
| 2021-04-15 14:14:28 | <tdammers> | I think you're being a tad bit pretentious here |
| 2021-04-15 14:14:29 | × | LKoen quits (~LKoen@65.250.88.92.rev.sfr.net) (Remote host closed the connection) |
| 2021-04-15 14:14:40 | <kuribas> | tdammers: how so? |
| 2021-04-15 14:15:13 | <ij> | Do graphs from fgl be converted back to data? |
| 2021-04-15 14:15:14 | <tdammers> | I mean, making everything nullable with no typesystem support for ruling out nulls is of course a lousy decision |
| 2021-04-15 14:15:16 | <merijn> | Well, see: nullPtr |
| 2021-04-15 14:15:38 | <tdammers> | but that has relatively little to do with "totality" as a property of the language as a whole |
| 2021-04-15 14:15:55 | × | dmytrish quits (~mitra@2a02:8084:a82:d900:f811:9873:2623:c28b) (Ping timeout: 260 seconds) |
| 2021-04-15 14:16:26 | <hyperisco> | kuribas, you have to hit the crash to know it exists then, which isn't guaranteed … I think the question is what sort of errors are most likely to reveal themselves when made, and how obviously do they identify themselves among other possible sources of error |
| 2021-04-15 14:16:31 | <dolio> | People are often 'scared' of partial functions because the errors and whatnot are not the sort of thing that are supposed to exit the program and be reported. They're supposed to be impossible cases that are sometimes very hard to track down when they end up not being impossible. |
| 2021-04-15 14:17:10 | <dolio> | And it's a classic scenario for someone to go, "you're too worried about it, just use partial functions," and then it comes back to ruin their day. |
| 2021-04-15 14:17:26 | <hyperisco> | running your program and getting a seg fault is typically not a good day |
| 2021-04-15 14:17:34 | <tdammers> | maybe worth mentioning that all practical general-purpose languages are partial |
| 2021-04-15 14:17:38 | <merijn> | It's a great day |
| 2021-04-15 14:17:49 | <merijn> | It's not getting a segfault that makes your life shit |
| 2021-04-15 14:18:08 | <hyperisco> | okay I guess I like shit |
| 2021-04-15 14:18:09 | <kuribas> | hyperisco: the problem with a segfault is that it is hard to track. |
| 2021-04-15 14:18:25 | <merijn> | What? segfaults are trivial to track |
| 2021-04-15 14:18:29 | <merijn> | You get a coredump |
| 2021-04-15 14:18:36 | <merijn> | It's silent memory corruption that's hell |
| 2021-04-15 14:18:38 | <kuribas> | merijn: then what? gdb? |
| 2021-04-15 14:18:43 | <merijn> | kuribas: Yes |
| 2021-04-15 14:18:47 | → | MrMobius joins (~MrMobius@208.58.206.154) |
| 2021-04-15 14:18:54 | → | LKoen joins (~LKoen@65.250.88.92.rev.sfr.net) |
| 2021-04-15 14:19:03 | <hyperisco> | we're talking about different leagues of difficulty here lol |
| 2021-04-15 14:19:05 | <kuribas> | merijn: how do I map that to a haskell function? |
| 2021-04-15 14:19:06 | <merijn> | kuribas: Much better than "some state got corrupted by write to a dangling pointer that didn't segfault and now memory is consistent" |
| 2021-04-15 14:19:17 | <tdammers> | segfaults aren't hard to track. the only problem with them is that they're in the "prove the presence of a bug" class, not the "prove the absence of a bug" class |
| 2021-04-15 14:19:19 | <merijn> | kuribas: GHC supports DWARF symbols now |
| 2021-04-15 14:19:31 | <hyperisco> | a simple error to me is you run the program, you get an error, and from that you immediately know where and what in the program is wrong |
| 2021-04-15 14:19:35 | <merijn> | (actually has since 8.0?) |
| 2021-04-15 14:19:43 | <hyperisco> | intuitively, not stepping through a debugger |
| 2021-04-15 14:19:57 | <merijn> | hyperisco: That's nice, but entirely unrelated to "total" or "not total" |
| 2021-04-15 14:19:59 | <hyperisco> | if you have to start stepping through a debugger you're in a bad place |
| 2021-04-15 14:20:32 | <merijn> | (or partiality for that matter) |
| 2021-04-15 14:21:00 | <hyperisco> | I don't understand how you can make that assertion |
| 2021-04-15 14:21:44 | <maerwald> | hm, we only have one dwarf bindist though |
| 2021-04-15 14:21:46 | <merijn> | You can have partial functions with great errors and total functions with shit errors |
| 2021-04-15 14:22:06 | <merijn> | "quality of error" and partiality are entirely orthogonal |
| 2021-04-15 14:22:21 | <hyperisco> | I didn't say otherwise |
| 2021-04-15 14:22:38 | <merijn> | hyperisco: I'm confused why we are even talking about quality of errors, though? |
| 2021-04-15 14:22:51 | <tdammers> | also, you don't usually step when debugging a segfault. or at least, I don't. |
| 2021-04-15 14:22:53 | <hyperisco> | because kuribas was talking about it |
| 2021-04-15 14:22:53 | <merijn> | The discussion started with "is partiality important or not" |
| 2021-04-15 14:22:54 | → | bitmapper joins (uid464869@gateway/web/irccloud.com/x-prwjffdraokbcpct) |
| 2021-04-15 14:23:11 | <ij> | re fgl: the interface isn't hidden, it's just type Gr = IntMap, so IntMap.toList should do :) |
| 2021-04-15 14:23:23 | <kuribas> | merijn: not important, but acceptable. |
| 2021-04-15 14:23:23 | <tdammers> | I use gdb to find the pointer that segfaults, and then I either stare the bug down with that information, or I pepper the code with tests to rule out all the error conditions I can think of. |
| 2021-04-15 14:23:24 | <ij> | view source button from hackage docs is amazing |
| 2021-04-15 14:23:27 | <tdammers> | that usually does the trick. |
| 2021-04-15 14:23:40 | <tdammers> | I think I haven't step-debugged anything in over a decade now |
| 2021-04-15 14:23:46 | <kuribas> | tdammers: that doesn't sound low-effort |
| 2021-04-15 14:23:56 | <tdammers> | it is, though |
| 2021-04-15 14:24:11 | <maerwald> | writing tests to find a bug sounds too much like an engineer |
| 2021-04-15 14:24:14 | <maerwald> | :p |
| 2021-04-15 14:24:14 | <merijn> | tdammers: It's mostly the issue of debuggers being shit, though |
| 2021-04-15 14:24:21 | <tdammers> | the idea is to not waste any time |
| 2021-04-15 14:24:35 | <merijn> | tdammers: Allinea DDT was some amazing shit |
| 2021-04-15 14:24:47 | <tdammers> | step-debugging is frugal - the moment you step away from a line, the state in which your program was at that moment is lost, only preserved in your brain |
| 2021-04-15 14:24:47 | <merijn> | tdammers: Of course it costs, like 100k per year per engineer :p |
All times are in UTC.