Newest at the top
| 2026-04-25 13:31:39 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds) |
| 2026-04-25 13:30:05 +0000 | <raincomplex> | [exa], i don't know much about julia but that definitely sounds interesting |
| 2026-04-25 13:27:53 +0000 | <raincomplex> | jreicher, right exactly |
| 2026-04-25 13:27:43 +0000 | <jreicher> | raincomplex: I didn't say there was nothing. It's more about choosing the boundary |
| 2026-04-25 13:27:05 +0000 | <[exa]> | raincomplex: oh btw, before I forget -- Julia occupies a very veeeeery interesting overlap of both design "directions"; makes an interesting study material |
| 2026-04-25 13:26:38 +0000 | <raincomplex> | if there were nothing unavoidably runtime, we wouldn't need to run programs |
| 2026-04-25 13:25:58 +0000 | <jreicher> | So if you're prepared to accept that, the real question is, what do you think is unavoidably runtime? |
| 2026-04-25 13:24:29 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-04-25 13:23:02 +0000 | <jreicher> | Compile time is better. It's the ultimate "fail fast". |
| 2026-04-25 13:22:31 +0000 | <raincomplex> | will it complain before i even run the program, or does it only complain when the runtime tries to do something that isn't allowed |
| 2026-04-25 13:22:09 +0000 | <jreicher> | Even "type system" is ambiguous. Do you mean type check? |
| 2026-04-25 13:21:45 +0000 | <raincomplex> | i think the aspect i'm considering most at this moment is the "eagerness" of the type system |
| 2026-04-25 13:20:42 +0000 | <raincomplex> | i'm using it loosely |
| 2026-04-25 13:20:36 +0000 | <jreicher> | raincomplex: "dynamic language" is something different again. The terminology is quite confused |
| 2026-04-25 13:20:35 +0000 | <raincomplex> | this is one thing that jumps out "The key idea is that many dynamically typed languages idiomatically reuse simple data structures like hashmaps to represent what in statically-typed languages are often represented by bespoke datatypes (usually defined as classes or structs)." |
| 2026-04-25 13:20:08 +0000 | <raincomplex> | this article touches on what i'm thinking about, although it's not its main focus https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-type-systems-are-not-inherently-more-open/ |
| 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 |