I disagree with this: > One, types are a concretion. If you’re looking for higher level of abstractions to get flexible behaviour, you’re ultimately going to h

I disagree with this: > One, types are a concretion. If you’re looking for higher level of abstractions to get flexible behaviour, you’re ultimately going to have a world of pain I don't see why types should be in the way of flexible behaviour. Frameworks like Spring in Java use types to direct dependency injection and it works well. Also this: > Types wrap data and treat it like a black box whereas schema describes the shape and content of data. Types can be made abstract and blackboxy, and sometimes that's what you want. But doesn't a record type give info about its fields? Doesn't a sum type give info about possible alternatives in the values? > As such haskell ultimately suffers a lot when they have to interact with the real world. Suddenly they are left reeling as they find out that the real world is, in fact, dynamic. The trick is to know what we are really modelling. If we are deserializing domain objects from JSON, it makes sense to have types for the domain objects. If we are writing a tool like, say, jq, perhaps we should merely have a datatype for the JSON tree itself: http://hackage.haskell.org/package/aeson-1.5.5.1/docs/Data-Aeson.html#t:Value http://hackage.haskell.org/package/aeson-1.5.5.1/docs/Data-A... > Bottom up design is something we’ve learnt collectively as a good way to be much more flexible in responding to change. Even if you want to design bottom-up, the moment you want to add anything to your program, you need a little top-down thinking, if only at the micro-level. You want to create something new that isn't there, and then think how to accomplish that with the tools you have.