Logs: freenode/#haskell
| 2020-10-01 20:08:15 | <maerwald> | it's like cabal vs stack I think |
| 2020-10-01 20:08:29 | <koz_> | maerwald: So... same exact issue rofl? |
| 2020-10-01 20:08:30 | <Cale> | I'll often just use QuickCheck on its own |
| 2020-10-01 20:08:42 | <koz_> | But yeah, my experience with HSpec has been rather negative and I would not recommend its use. |
| 2020-10-01 20:09:06 | <maerwald> | It's all fine |
| 2020-10-01 20:09:14 | <maerwald> | the differences are minor |
| 2020-10-01 20:09:25 | <maerwald> | the smaller the differences, the stronger the opinions :p |
| 2020-10-01 20:09:27 | <koz_> | maerwald: Sure, and in my opinion they're not. YMMV. |
| 2020-10-01 20:11:40 | <nwoob> | was my question not good? |
| 2020-10-01 20:11:44 | → | coot joins (~coot@37.30.49.34.nat.umts.dynamic.t-mobile.pl) |
| 2020-10-01 20:11:58 | <Squarism> | I used HUnit quite a bit and it did what it was supposed to do. But there it hasnt been updated in 3 years. Would be fun to use something that has a bit of momentum to it |
| 2020-10-01 20:11:59 | <koz_> | nwoob: 'Expressive' is a vague term. |
| 2020-10-01 20:12:12 | <Squarism> | -it* |
| 2020-10-01 20:12:30 | <maerwald> | nwoob: typescript is more expressive in some senses, so not sure :p |
| 2020-10-01 20:12:53 | ← | wanaks[m] parts (wanaksmatr@gateway/shell/matrix.org/x-ypunfwqxglzxjffl) ("User left") |
| 2020-10-01 20:12:58 | <maerwald> | (actual structural typing is very expressive) |
| 2020-10-01 20:13:21 | <dolio> | Many HUnit doesn't need any more work. |
| 2020-10-01 20:13:28 | → | madjestic joins (~madjestic@86.88.72.244) |
| 2020-10-01 20:13:46 | × | dhil quits (~dhil@11.29.39.217.dyn.plus.net) (Ping timeout: 246 seconds) |
| 2020-10-01 20:14:11 | <nwoob> | maerwald: If I may ask, do you think typescript is beneficial over JS because of types |
| 2020-10-01 20:14:14 | <ski> | nwoob : dunno TypeScript's type system, in what ways it differs .. |
| 2020-10-01 20:14:18 | <maerwald> | nwoob: yes |
| 2020-10-01 20:14:37 | <Cale> | nwoob: "Expressive" means something like the ability to translate mathematical properties that your program may or may not satisfy into types that the compiler will check, with some element of having those types not be a pain to actually write or use mixed in as well. |
| 2020-10-01 20:14:40 | <maerwald> | it has a few holes though |
| 2020-10-01 20:15:24 | <maralorn> | nwoob: I think one definition of an expressive type system would be how many kinds of Bugs you can prevent by having specific enough types. |
| 2020-10-01 20:15:49 | <nwoob> | and how do you quantify that? |
| 2020-10-01 20:16:51 | <maralorn> | nwoob: You don‘t. I think it's subjective. But in practice examples are very clear. |
| 2020-10-01 20:16:58 | <maerwald> | hmm, haskell can't really prohibit concurrency bugs, there's that... I think you can only quantify it very generally |
| 2020-10-01 20:17:01 | <maerwald> | not deeply |
| 2020-10-01 20:17:24 | × | ericsagnes quits (~ericsagne@2405:6580:0:5100:4135:276:e32f:4d13) (Ping timeout: 244 seconds) |
| 2020-10-01 20:17:48 | <Cale> | Some of them it kind of can, sort of |
| 2020-10-01 20:18:00 | <maerwald> | Cale: you can in any language if you write a careful DSL |
| 2020-10-01 20:18:09 | <maerwald> | but the language itself doesn't take care of it at all |
| 2020-10-01 20:18:09 | <Cale> | Just the fact that everything is by default immutable is a great help |
| 2020-10-01 20:18:20 | <Cale> | and the fact that computations can have limited effects |
| 2020-10-01 20:18:26 | × | ClaudiusMaximus quits (~claude@unaffiliated/claudiusmaximus) (Quit: ...zzzZZZ) |
| 2020-10-01 20:18:34 | <maerwald> | you can mess up MVar locking, you can get races with IORef |
| 2020-10-01 20:18:37 | <maerwald> | and many other things |
| 2020-10-01 20:18:51 | <Cale> | e.g. we have things like STM, and the properties that allow an STM transaction to be rolled back can basically be enforced by the types |
| 2020-10-01 20:19:15 | × | Lycurgus quits (~niemand@98.4.96.130) (Quit: Exeunt) |
| 2020-10-01 20:19:52 | <Cale> | But yeah, while you can get into all the usual kinds of trouble with modifying IORefs from multiple threads, the fact that not everything is implicitly a pile of IORefs helps a bunch |
| 2020-10-01 20:20:03 | <maralorn> | You could also store all your variables in String and "fromJust . read" them whenever you want to do something with them. The point is not that Haskell programs are safe, but that it helps you to write safe programs … |
| 2020-10-01 20:20:16 | → | wroathe joins (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2020-10-01 20:20:21 | <maerwald> | maralorn: safe? |
| 2020-10-01 20:20:49 | <maerwald> | if you mean "doesn't crash", then haskell is actually not that good at it due to lack of checked exceptions |
| 2020-10-01 20:20:53 | <maralorn> | maerwald: safer? |
| 2020-10-01 20:21:07 | <maerwald> | if you mean "secure", then definitely no :p |
| 2020-10-01 20:21:51 | × | son0p quits (~son0p@181.136.122.143) (Ping timeout: 258 seconds) |
| 2020-10-01 20:21:57 | <maralorn> | Yeah, the lack of checked exceptions is a bit sad. |
| 2020-10-01 20:22:12 | <Cale> | I don't know what checked exceptions would actually look like |
| 2020-10-01 20:22:31 | <Cale> | How would they differ substantially from the usual ways that things can fail? |
| 2020-10-01 20:22:40 | <Cale> | e.g. by returning an Either result |
| 2020-10-01 20:22:41 | <maerwald> | Cale: Does that even work reasonably without a vm? |
| 2020-10-01 20:23:11 | <maerwald> | I'm wondering about cross platform too |
| 2020-10-01 20:23:40 | → | son0p joins (~son0p@181.136.122.143) |
| 2020-10-01 20:23:47 | <Cale> | If your IO action produces an Either Something, then the fact that it can fail is encoded in its type, along with the type of potential failures. |
| 2020-10-01 20:24:01 | <maralorn> | I think this kind of discussion is also a bit sad. |
| 2020-10-01 20:24:06 | <maerwald> | Cale: checked exceptions don't have to be in the type at all |
| 2020-10-01 20:24:24 | → | merijn joins (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2020-10-01 20:24:33 | <Cale> | Why shouldn't they be? |
| 2020-10-01 20:24:34 | <maralorn> | It feels like the overall point here is, that there is no such thing as safe programing (so let's not even try). |
| 2020-10-01 20:24:42 | <maerwald> | Cale: why should they be? |
| 2020-10-01 20:24:48 | <maerwald> | It clutters API |
| 2020-10-01 20:25:18 | <Cale> | Because types are the properties of programs which we expect the compiler to check statically (and which the program itself serves as a proof) |
| 2020-10-01 20:25:48 | <maerwald> | maralorn: well, there's "memory safe" and I don't know how good haskell performs here |
| 2020-10-01 20:26:10 | <maerwald> | Cale: exceptions in java are also statically checked |
| 2020-10-01 20:26:15 | <dolio> | What is 'checked' in the exceptions if they're not in something like the types? |
| 2020-10-01 20:26:20 | <maralorn> | maerwald: I have had more rust than haskell programs segfault in the last years … |
| 2020-10-01 20:26:29 | <maerwald> | not everything that's static needs to be a *type* |
| 2020-10-01 20:26:46 | <maerwald> | maralorn: segfault or panic? |
| 2020-10-01 20:26:47 | <Cale> | You could introduce what are effectively more overlapping type systems just for exceptions or just for other sorts of properties (cough LiquidHaskell), but it seems like it would be preferable to just have all that information in one coherent system. |
| 2020-10-01 20:26:49 | <maerwald> | huge difference |
| 2020-10-01 20:26:54 | <maerwald> | panic is memory safe |
| 2020-10-01 20:27:05 | <maralorn> | maerwald: Actual segfaults. |
| 2020-10-01 20:27:17 | <maralorn> | It had to do with ffi, so I am not being fair here … |
| 2020-10-01 20:27:31 | <maerwald> | Cale: I disagree on that. I think that's one of the reasons of the (unnecessary) complexity of haskell... |
| 2020-10-01 20:27:31 | → | alp joins (~alp@2a01:e0a:58b:4920:550:ea71:7853:65d0) |
| 2020-10-01 20:27:39 | <maerwald> | that we try to shoehorn everything into types |
| 2020-10-01 20:27:56 | <maerwald> | (because they're already expressive) |
| 2020-10-01 20:28:10 | <maerwald> | (so it's just that extra mile...) |
| 2020-10-01 20:28:17 | <maerwald> | (and then next year again) |
| 2020-10-01 20:28:54 | × | coot quits (~coot@37.30.49.34.nat.umts.dynamic.t-mobile.pl) (Quit: coot) |
| 2020-10-01 20:28:57 | <maerwald> | maralorn: ffi is unsafe :p |
| 2020-10-01 20:29:09 | <maerwald> | you literally put unsafe around it |
| 2020-10-01 20:29:17 | → | mav1 joins (~mav@83.135.139.36) |
| 2020-10-01 20:29:23 | × | merijn quits (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 240 seconds) |
| 2020-10-01 20:29:30 | <maerwald> | rust doesn't pretend to not crash |
| 2020-10-01 20:29:34 | <maerwald> | just crash gently |
| 2020-10-01 20:30:09 | <maralorn> | maerwald: No, I didn‘t. I wrote a pure rust program but the library I used was buggy. |
| 2020-10-01 20:30:12 | <ski> | Mercury has static modes, insts, determinisms (in addition to types) |
| 2020-10-01 20:30:30 | <ski> | (uniqueness is done with insts, not with types as is the case in Clean) |
| 2020-10-01 20:30:32 | <maerwald> | maralorn: ah yeah... you never know. But you have the same problem in haskell with ffi |
| 2020-10-01 20:30:50 | <maralorn> | Yes |
| 2020-10-01 20:30:54 | × | cr3 quits (~cr3@192-222-143-195.qc.cable.ebox.net) (Quit: leaving) |
| 2020-10-01 20:31:04 | <maralorn> | I think my biggest issue is that there is a class of concrete runtime errors in Haskell that the dev is not forced to acknowledge up front. |
| 2020-10-01 20:32:18 | <Cale> | Yeah, part of the problem is just particular libraries that overuse that system of IO exceptions for things that the user is more likely than not going to want to handle |
| 2020-10-01 20:32:42 | → | dhil joins (~dhil@11.29.39.217.dyn.plus.net) |
| 2020-10-01 20:32:59 | <Cale> | Exceptions are good for things which will rarely want to be handled in any way that's much more graceful than stopping the program or restarting some part of it. |
| 2020-10-01 20:33:04 | <maerwald> | it's fine for low-level libs (where it's hard to guess, what someone wants to handle), but yeah |
| 2020-10-01 20:33:47 | × | thir quits (~thir@p200300f27f0fc60004d129737887aa72.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
All times are in UTC.