Logs: liberachat/#haskell
| 2021-06-19 11:08:59 | × | ubert quits (~Thunderbi@p200300ecdf259d37e6b318fffe838f33.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2021-06-19 11:13:21 | × | tromp quits (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2021-06-19 11:14:14 | <boxscape> | anyone got any experience with ImpredicativeTypes? I'm wondering how to make this work https://paste.tomsmeding.com/ig2UQ1O0 |
| 2021-06-19 11:16:27 | → | chrysanthematic joins (~chrysanth@user/chrysanthematic) |
| 2021-06-19 11:17:57 | → | adpRCCaLTxuh joins (~adpRCCaLT@88.155.39.126) |
| 2021-06-19 11:17:57 | <adpRCCaLTxuh> | Go bA(k tO FreEn0dE or n0rTH koReA nukeS YOu |
| 2021-06-19 11:17:57 | × | adpRCCaLTxuh quits (~adpRCCaLT@88.155.39.126) (Client Quit) |
| 2021-06-19 11:18:20 | × | nilof quits (~olofs@90-227-86-119-no542.tbcn.telia.com) (Ping timeout: 268 seconds) |
| 2021-06-19 11:19:04 | <boxscape> | (it's trivial with a newtype but if ImpredicativeTypes works it might be a bit nicer) |
| 2021-06-19 11:20:20 | <nitrix> | ) Just closing the paren adpRCCaLTxhh left opened. |
| 2021-06-19 11:20:40 | <boxscape> | appreciated |
| 2021-06-19 11:20:41 | <nitrix> | Okay I feel better now. |
| 2021-06-19 11:23:06 | → | ubert joins (~Thunderbi@p200300ecdf259d37e6b318fffe838f33.dip0.t-ipconnect.de) |
| 2021-06-19 11:27:24 | × | hmmmas quits (~chenqisu1@183.217.200.246) (Quit: Leaving.) |
| 2021-06-19 11:27:39 | → | betelgeuse joins (~john2gb@94-225-47-8.access.telenet.be) |
| 2021-06-19 11:28:24 | → | ddellacosta joins (~ddellacos@86.106.121.100) |
| 2021-06-19 11:28:52 | × | ubert quits (~Thunderbi@p200300ecdf259d37e6b318fffe838f33.dip0.t-ipconnect.de) (Ping timeout: 244 seconds) |
| 2021-06-19 11:30:09 | → | tromp joins (~textual@dhcp-077-249-230-040.chello.nl) |
| 2021-06-19 11:32:21 | → | hegstal joins (~hegstal@2a02:c7f:7604:8a00:1e4a:1cd5:4170:e3e0) |
| 2021-06-19 11:32:50 | × | ddellacosta quits (~ddellacos@86.106.121.100) (Ping timeout: 252 seconds) |
| 2021-06-19 11:33:56 | → | hmmmas joins (~chenqisu1@183.217.200.246) |
| 2021-06-19 11:34:17 | × | hmmmas quits (~chenqisu1@183.217.200.246) (Client Quit) |
| 2021-06-19 11:35:05 | × | merijn quits (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 268 seconds) |
| 2021-06-19 11:35:07 | <teaSlurper> | is there a function pattern for "match once first" |
| 2021-06-19 11:35:11 | <teaSlurper> | or do this first |
| 2021-06-19 11:36:29 | → | nilof joins (~olofs@90-227-86-119-no542.tbcn.telia.com) |
| 2021-06-19 11:36:42 | × | Pickchea quits (~private@user/pickchea) (Ping timeout: 240 seconds) |
| 2021-06-19 11:37:10 | <boxscape> | teaSlurper hmm, it's not really clear to me what you're asking |
| 2021-06-19 11:37:29 | <boxscape> | maybe an example would help |
| 2021-06-19 11:37:46 | <teaSlurper> | i'm generating a bunch of fractionals |
| 2021-06-19 11:37:51 | <teaSlurper> | going down from n |
| 2021-06-19 11:38:14 | → | trent joins (~trent@2001:8003:340d:d00:b2de:b98:7a93:b0ea) |
| 2021-06-19 11:38:17 | <teaSlurper> | so n = 4, [1/4, 1/3, 1/2, 1/1] |
| 2021-06-19 11:38:42 | × | favonia quits (~favonia@user/favonia) (Ping timeout: 264 seconds) |
| 2021-06-19 11:40:36 | <teaSlurper> | i solved the problem is cool, but in a different way |
| 2021-06-19 11:41:33 | → | eggplantade joins (~Eggplanta@2600:1700:bef1:5e10:1543:9aaf:78fa:158) |
| 2021-06-19 11:41:53 | → | lavaman joins (~lavaman@98.38.249.169) |
| 2021-06-19 11:41:54 | → | geekosaur joins (~geekosaur@xmonad/geekosaur) |
| 2021-06-19 11:43:38 | × | allbery_b quits (~geekosaur@xmonad/geekosaur) (Ping timeout: 252 seconds) |
| 2021-06-19 11:45:13 | × | Guest95 quits (~Guest95@202.36.179.107) (Ping timeout: 246 seconds) |
| 2021-06-19 11:45:54 | × | eggplantade quits (~Eggplanta@2600:1700:bef1:5e10:1543:9aaf:78fa:158) (Ping timeout: 240 seconds) |
| 2021-06-19 11:46:24 | × | lavaman quits (~lavaman@98.38.249.169) (Ping timeout: 252 seconds) |
| 2021-06-19 11:48:43 | <kuribas> | What's your opinion on testing on the REPL vs unit tests? |
| 2021-06-19 11:48:44 | × | azeem quits (~azeem@dynamic-adsl-78-13-238-239.clienti.tiscali.it) (Read error: Connection reset by peer) |
| 2021-06-19 11:48:56 | → | azeem joins (~azeem@dynamic-adsl-78-13-238-239.clienti.tiscali.it) |
| 2021-06-19 11:49:17 | <kuribas> | I can see an advantage for unit tests (and property tests) when you have complicated algorithms or business logic, that may still evolve. |
| 2021-06-19 11:49:36 | <kuribas> | However is there a point in unit testing simple functions which do one thing, and can easily be tested on the REPL? |
| 2021-06-19 11:50:10 | <teaSlurper> | i don't know anything about unit-testing with haskell, but the idea is all your tests are automated |
| 2021-06-19 11:50:18 | <teaSlurper> | in general |
| 2021-06-19 11:50:26 | <Morrow> | You can have your cake and eat it too |
| 2021-06-19 11:50:26 | <kuribas> | well, you need to write them first :) |
| 2021-06-19 11:50:43 | <Morrow> | You can load up your test file in the REPL |
| 2021-06-19 11:50:49 | <teaSlurper> | unit testing acts as a form of documentation in a way aswell |
| 2021-06-19 11:51:12 | <teaSlurper> | and keeps a history of edge cases you've tested |
| 2021-06-19 11:51:30 | <kuribas> | they also take up time in CICD if you have a lot of them. |
| 2021-06-19 11:51:31 | <teaSlurper> | and catches bugs in regressions |
| 2021-06-19 11:51:44 | <tomsmeding> | kuribas: sounds to me like a lack of ergonomics in specifying tests; if writing the unit test would be just as easy as opening a repl and entering it there, then you wouldn't ask the question |
| 2021-06-19 11:51:47 | <tomsmeding> | perhaps doctests? |
| 2021-06-19 11:51:47 | <Morrow> | Especially with frameworks that have test caching |
| 2021-06-19 11:52:03 | tomsmeding | isn't sure how ergonomic the tooling around doctests is, but it exists |
| 2021-06-19 11:52:09 | <kuribas> | tomsmeding: doctests are nice :) |
| 2021-06-19 11:52:31 | <kuribas> | tomsmeding: tests are also code, which needs to be maintained. |
| 2021-06-19 11:52:58 | <tomsmeding> | also true |
| 2021-06-19 11:53:06 | <teaSlurper> | with repl you can only test if your code works now, oppose to against future changes which is what unit tests are for more than anything perhaps |
| 2021-06-19 11:53:34 | → | hmmmas joins (~chenqisu1@183.217.200.246) |
| 2021-06-19 11:54:05 | <teaSlurper> | if 1 function stops working from a future change it could break 5 other unit tests |
| 2021-06-19 11:54:31 | <teaSlurper> | make em all green, then you know with more confidence your thing as a whole works |
| 2021-06-19 11:54:53 | <kuribas> | tomsmeding: I find unit tests in haskell quite ergonomic. |
| 2021-06-19 11:55:59 | <tomsmeding> | don't get me wrong, I'm quite bad at getting myself to write tests in the first place for anything but the most complicated code |
| 2021-06-19 11:56:40 | → | Pickchea joins (~private@user/pickchea) |
| 2021-06-19 11:57:17 | <kuribas> | I don't think code quality is a measure of number of unit tests. |
| 2021-06-19 11:57:34 | <kuribas> | We hardly have any unit tests in our code, but the quality is quite high. |
| 2021-06-19 11:57:58 | <kuribas> | In another company we had more tests than code :) The code was aweful. |
| 2021-06-19 11:58:32 | <kuribas> | Although in one project (our REST API) we now have a large amount of tests. |
| 2021-06-19 11:58:43 | <hpc> | sometimes how hard it is to write tests is the test itself |
| 2021-06-19 11:58:58 | <hpc> | as soon as it becomes hard to test something, you know it has modularity problems |
| 2021-06-19 11:59:00 | <kuribas> | I feel I could write the same code with 1/10 the tests, and more confidence by doing it in haskell (vs clojure). |
| 2021-06-19 11:59:38 | → | ddellacosta joins (~ddellacos@86.106.121.100) |
| 2021-06-19 11:59:41 | <kuribas> | hpc: certainly |
| 2021-06-19 11:59:48 | <kuribas> | but it can be easy and still tedious :) |
| 2021-06-19 11:59:51 | <kuribas> | to find all edge cases. |
| 2021-06-19 12:00:23 | → | fizbin joins (~fizbin@c-68-83-100-68.hsd1.nj.comcast.net) |
| 2021-06-19 12:00:46 | <kuribas> | maybe property tests are better in that case;.. |
| 2021-06-19 12:02:25 | <tomsmeding> | property tests take away one dimension of "finding edge cases", but sometimes there are more such dimensions |
| 2021-06-19 12:02:56 | <hpc> | they save you a lot of "basic" unit tests |
| 2021-06-19 12:03:06 | <tomsmeding> | which can sometimes also be covered with more generic generators, but not always |
| 2021-06-19 12:03:07 | <hpc> | you only have to write out the tricky cases by hand |
| 2021-06-19 12:04:00 | × | ddellacosta quits (~ddellacos@86.106.121.100) (Ping timeout: 252 seconds) |
| 2021-06-19 12:04:13 | <tomsmeding> | I recently wrote tests for a tricky program transformation; property testing allowed me to leave selecting _inputs_ for the transformed programs to the randomiser, but generating random _programs_ is hard enough that I resolved to writing those by hand |
| 2021-06-19 12:04:43 | × | fizbin quits (~fizbin@c-68-83-100-68.hsd1.nj.comcast.net) (Ping timeout: 265 seconds) |
| 2021-06-19 12:05:37 | → | merijn joins (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-06-19 12:09:13 | <tomsmeding> | (I did try generating programs for a bit, but then rediscovered how that's a hard problem :p) |
| 2021-06-19 12:10:53 | × | merijn quits (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 258 seconds) |
| 2021-06-19 12:13:13 | × | jneira_ quits (~jneira_@131.red-79-155-1.dynamicip.rima-tde.net) (Ping timeout: 268 seconds) |
| 2021-06-19 12:13:26 | → | slowButPresent joins (~slowButPr@user/slowbutpresent) |
| 2021-06-19 12:19:49 | → | jmcarthur joins (~jmcarthur@c-73-29-224-10.hsd1.nj.comcast.net) |
| 2021-06-19 12:23:43 | → | notzmv joins (~zmv@user/notzmv) |
| 2021-06-19 12:26:49 | × | hmmmas quits (~chenqisu1@183.217.200.246) (Quit: Leaving.) |
| 2021-06-19 12:27:27 | × | wei2912 quits (~wei2912@112.199.250.21) (Quit: Lost terminal) |
| 2021-06-19 12:29:22 | × | nilof quits (~olofs@90-227-86-119-no542.tbcn.telia.com) (Ping timeout: 265 seconds) |
All times are in UTC.