[willtim]

> points he makes really don't translate to the software engineering world

His advice is in the context of functional programming languages. F#, Scala and even Haskell and OCaml are now very much part of the software engineering world (albeit a small part).

> How do you organise the interaction of libraries? You can do it yourself but you will have to follow some sort of pattern to organise the code

Because libraries compose, there's nothing to prevent a library on top of all these others libraries to accomplish this. If you have to repeat yourself with "patterns", your language of choice is failing you.

[chuck32]

> His advice is in the context of functional programming languages.

Thats not what he says. He says that these ideas "can be useful in any programming language". Which is the point that I disagree with.

> there's nothing to prevent a library on top of all these others libraries to accomplish this

So a library to organise the code which interacts with other libraries? Sounds an awful lot like a framework to me?

[willtim]

I agree that his advice will be difficult to follow in less expressive languages.

> So a library to organise the code which interacts with other libraries? Sounds an awful lot like a framework to me?

The domain/purpose does not alter the framework/library distinction according to his definition.