Newest at the top
| 2026-04-25 13:17:27 +0000 | <raincomplex> | it makes big changes a lot easier to keep track of |
| 2026-04-25 13:16:51 +0000 | <raincomplex> | i really like the pattern of following the compiler errors |
| 2026-04-25 13:16:37 +0000 | <raincomplex> | often i feel like tests i write in a dynamic language are implementing a little type system |
| 2026-04-25 13:15:44 +0000 | <[exa]> | (more ideally, from type information that you don't even write because it's inferred from the rest of the program) |
| 2026-04-25 13:14:44 +0000 | <[exa]> | in haskell it's quite normal to have whole large parts of programs auto-derived just from the type information |
| 2026-04-25 13:14:07 +0000 | <[exa]> | raincomplex: ask what the types can actually do for you, constructively |
| 2026-04-25 13:13:30 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-04-25 13:13:07 +0000 | <raincomplex> | i like both static and dynamic languages, and i think i'm just trying to get my head around what i like about each, and what the tradeoffs actually are |
| 2026-04-25 13:12:34 +0000 | gmg | (~user@user/gehmehgeh) (Ping timeout: 265 seconds) |
| 2026-04-25 13:08:49 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-04-25 13:08:31 +0000 | <jreicher> | Consider how unpleasant it would be figuring out how to call an API (in any language) without knowing the types of things. |
| 2026-04-25 13:07:46 +0000 | <jreicher> | I agree with [exa]. In addition to the cost saving of a faster feedback loop for a competent community the type annotations convey semantic information to humans. |
| 2026-04-25 13:06:45 +0000 | <[exa]> | raincomplex: re development patterns, there's an interesting dynamics -- with static types you usually get the error quicker and more reliably located. So I somehow like the type-errors more than test-errors just because the interaction loop is usually much faster |
| 2026-04-25 13:06:14 +0000 | <jreicher> | Put another way, there's no point verifying a program by the time it's running. The damage is already going to be done. |
| 2026-04-25 13:06:01 +0000 | <ski> | sometimes it's called "tag checking" |
| 2026-04-25 13:05:13 +0000 | <jreicher> | In my opinion there's no such thing as a dynamically typed language in this sense. The "program verification" aspect of types disappear as soon as you don't have static type checking. What is meant by "dynamic types" is more like "dynamic dispatch", which is something different |
| 2026-04-25 13:05:02 +0000 | <ski> | raincomplex : looking into property-based testing (like e.g. QuickCheck and similar), and also (preferably higher-order) contract checking (Racket has one), would probably be helpful, as well |
| 2026-04-25 13:04:13 +0000 | <raincomplex> | i'm thinking about the development pattern of making some changes, and then fixing the errors that arise when compiling/running. in a statically typed language, the type system covers more of this than in a dynamically typed language, where you need tests (manual or automated) to trigger the errors |
| 2026-04-25 13:01:25 +0000 | <jreicher> | raincomplex: My hunch is that the infinite/finite distinction is what you're after. If you want to show that a specific set of inputs result in the right behaviour, testing will give you that. But if you're in the realm of "all possible inputs", and that all is either infinite or unfeasibly large, testing won't, but type checking might. |
| 2026-04-25 13:01:21 +0000 | <[exa]> | raincomplex: article more like in "blog post" or "academic paper" |
| 2026-04-25 12:59:57 +0000 | <ski> | (or the caller of it, passing invald inputs) |
| 2026-04-25 12:59:44 +0000 | <ski> | higher-order contract checking systems can also correctly assign blame, when you're passing a callback to some library procedure, determining whether the callback was in breach, or the library operation itself |
| 2026-04-25 12:59:00 +0000 | <ski> | (then there's property testing, that's using randomly generated test cases, according to some coded distribution of inputs, which is quite useful, because it allows you to state testing *properties*, being more general than particular individual test cases) |
| 2026-04-25 12:58:02 +0000 | <jreicher> | Tests won't get you infinite coverage |
| 2026-04-25 12:57:54 +0000 | merijn | (~merijn@62.45.136.136) (Ping timeout: 248 seconds) |
| 2026-04-25 12:57:45 +0000 | <jreicher> | Emphasis on "every". That's what is special about a proof. That "every" is (probably) infinite. |
| 2026-04-25 12:57:42 +0000 | <ski> | tests, and contracts checking more generally, can assign blame for individual run-time issues, but generally can't prove the absence |
| 2026-04-25 12:55:56 +0000 | <ski> | a type system can ensure static properties about every possible future run of an operation |
| 2026-04-25 12:54:58 +0000 | puke | (~puke@user/puke) (Ping timeout: 250 seconds) |
| 2026-04-25 12:54:57 +0000 | <raincomplex> | i'm just looking for a discussion of the differences and overlaps |
| 2026-04-25 12:53:31 +0000 | <jreicher> | raincomplex: what kind of relationship are you expecting? A type check is a proof, but testing.... isn't |
| 2026-04-25 12:53:21 +0000 | <ski> | each can do things that the other can't |
| 2026-04-25 12:53:15 +0000 | merijn | (~merijn@62.45.136.136) merijn |
| 2026-04-25 12:50:00 +0000 | nattkyrro | (~serenity@user/nattkyrro) nattkyrro |
| 2026-04-25 12:49:10 +0000 | <raincomplex> | does anybody have a good article about the relationship (or lack thereof) between type systems and tests |
| 2026-04-25 12:42:19 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-04-25 12:37:18 +0000 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 256 seconds) |
| 2026-04-25 12:37:16 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-04-25 12:30:10 +0000 | tremon | (~tremon@83.80.159.219) tremon |
| 2026-04-25 12:26:34 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2026-04-25 12:25:22 +0000 | puke | (~puke@user/puke) puke |
| 2026-04-25 12:24:52 +0000 | puke | (~puke@user/puke) (Remote host closed the connection) |
| 2026-04-25 12:21:43 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-04-25 12:17:28 +0000 | puke | (~puke@user/puke) puke |
| 2026-04-25 12:16:49 +0000 | puke | (~puke@user/puke) (Remote host closed the connection) |
| 2026-04-25 12:11:40 +0000 | xff0x | (~xff0x@ah206235.dynamic.ppp.asahi-net.or.jp) |
| 2026-04-25 12:10:17 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2026-04-25 12:08:18 +0000 | misterfish | (~misterfis@31-161-39-137.biz.kpn.net) misterfish |
| 2026-04-25 12:05:14 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-04-25 11:57:06 +0000 | arandombit | (~arandombi@user/arandombit) arandombit |