[dharmaturtle]

> What you get here goes way beyond what a strict, static type systems gets you, such as arbitrary predicate validation,

Is this refinement types, which most static languages provide? https://en.wikipedia.org/wiki/Refinement_type

> freely composable schemas,

My understanding is that you can compose types (and objects) https://en.wikipedia.org/wiki/Object_composition

I'm assuming that types are isomorphic with schemas for the purposes of this discussion.

> automated instrumentation

I know that C# and F# support automated instrumentation/middleware.

> and property testing. You simply do not have that in a static world.

QuickCheck has entered the chat: https://en.wikipedia.org/wiki/QuickCheck

[CraigJPerry]

>> Is this refinement types

Well it does include that kind of behaviour but it's quite a bit more than just that. E.g. you could express something like "the parameter must be a date within the next 5 business days" - there's no static restriction. I'm not necesarily saying you should but just to give an illustrative example that there's less restrictions on your freedom to express what you need than in a static system.

>> types are isomorphic with schemas

I don't think that's a good way to think of this, you're imagining a rigid 1:1 tie of data and spec yet i could swap out your spec for my spec so that would be 1:n but those specs may make sense to compose in other data use cases so really it's m:n rather than 1:1

[dharmaturtle]

> E.g. you could express something like "the parameter must be a date within the next 5 business days" - there's no static restriction

Hm, I don't follow. If I were to write this in F#, there would be a type `Within5BusinessDays` with a private constructor that exposes one function/method `tryCreate` which returns a discriminated union: either an `Ok` of the `Within5BusinessDays` type, or an `Error` type with some error message. Once I have the type, I can then compose it with whatever and send it wherever and since F# records are immutable, I won't have to worry about invariants not holding. And since it's a type, I have the compiler/type system on my side to help with correctness.

(Side note, this is a bad example since the type can become invalid after literally 1 second... but since Clojure has the same problem I'm just running with it.)

I'm still learning Clojure (only a few months into it), but if I were to to write a spec, I'd have to specify what to do do if the spec failed to conform - same as returning the `Error` case in F#.

> i could swap out your spec for my spec so that would be 1:n but those specs may make sense to compose in other data use cases so really it's m:n rather than 1:1

Sorry, but I'm still not following - I believe you can do the same with types, especially if the type system support generics.

[CraigJPerry]

> If I were to write this in F#, there would be a type `Within5BusinessDays`

That’s not really the same thing - it’sa valid alternative approach but you’ve lost the benefits of a simple date - from (de)serialisation to the rich support for simple date types in libraries and other functions, the simple at-a-glance understanding that future readers could enjoy. Now the concept of date has been complected with some other niche concern.

> the type can become invalid after literally 1 second

Every system I’ve ever seen that has the concept of a business date strictly doesn’t derive it from wall clock date. E.g. it’s common that business date would be rolled at some convenient time (and most often not midnight) so you’d be free to ensure no impacts possible from the date roll.

>> I believe you can do the same with types, especially if the type system support generics

You can do something similar but you’ll need to change the system’s code.

It would be almost like gradual typing, except you could further choose to turn it off or to substitute your own types / schema without making changes to the system / code.

It’s quite a lot more flexible.

(Apols for slow reply - i 1up’d your reply earlier when i saw it but couldn’t reply then)

[dharmaturtle]

> but you’ve lost the benefits of a simple date

I see what you mean - thanks!

> you could further choose to turn it off or to substitute your own types / schema without making changes to the system / code

This is still unclear to me. How can you make changes (turning off gradual typing/substituting your own schema) without making changes to code?

[dgb23]

Right! I made the dumb, typical error to write: "You simply do not have that in a static world." When I should have written: "This type of expressiveness is not available in mainstream statically typed languages".

With "freely composable" I mean that you can program with these schemas as they are just data structures and you only specify the things you want to specify. Both advantage and the disadvantage is that this is dynamic.

[dharmaturtle]

Ah, well if you're going to shit on Go/Java/C#/C++ I won't stop you :)