[enugu]

Watching Hickey's talk, many of the complaints seemed to be valuable, but they didnt seem to be about static types. Rather, it was about some problems with existing data types locking one into a rigid data model when the domain is constantly expanding.

This post by DeGoes makes the same point. http://degoes.net/articles/kill-data

The default model of algebraic data types is too inflexible.

There are different extensions which work with this issue. Good record system, Extensible cases, using free monads etc. We can have concise syntax for automatically declaring an interface for a algebraic data type based on some field values (ie, customizable deriving statements). Namespace qualified keywords, so we have rdf like attribute based semantics.

The post doesnt respond to the issue but suggests that if you want to do the same thing in clojure with error handling etc, you will need to think about this stuff.

Also, Hickey's mention of Monads was again not about static types. Monad laws are not typechecked. Their motivation is purity. The only slight inconvenience in a dynamic context is that you dont have return type polymorphism, so you have to type IOreturn instead of return.

[tome]

> [Monad's] motivation is purity.

This is not true and it's important to clear up this misconception lest anyone thing "the only good reason to use monads in Haskell is because it's a pure language".

* The use of monads in functional programming arose purely technically as an innovation in denotational semantics

* Then someone noticed you could use it to wrap up IO purely in Haskell

* Then it was noticed you could use it for all sorts of other stuff besides dealing with IO in a pure language.

Monads are only a little bit related to purity.

[enugu]

Yes, sure, monads, applicatives etc. have plenty of applications beyond IO, which is part of why keeping that abstraction separate from any particular use is of value.

My point is that this doesnt have much to do with static typing vs dynamic typing per se, as we dont check them statically. They are just important examples of an interface with implementations for many data types, which can be useful even in a dynamic language like Clojure. People who write a parser in a dynamic language might benefit from learning about distinction between applicatives and monads.

[tome]

Yes I agree. I just wanted to clear up a potential misconception.

[dustingetz]

OMG thank you for that link DeGoes nailed it.

Data is just information, it doesn't care about it's implementation and is portable across platform and language.

You can attach your monads to an #error value when you parse it. Or not, if you happen to parse it in Python.

[agumonkey]

I wonder if there's an at-least type system so one could say it needs Person (n,a,c) and if it gets a Person (n,a,c,h) well that's consider a superset and thus accepted.

[enugu]

Sure, flow/typescript already do this by default.