[sorincos]

"The lack of first-class functions is the major reason why there are so many “design patterns” in Java. Once you have first-class functions, you will need almost none of the design patterns."

Now this is a very bold statement. I'm dying to hear more on how you can get rid of design patterns with first-class functions. Does it mean getting rid as in: sharing knowledge is not needed anymore and programming becomes art as we all head to the rapture?

[icebraining]

See http://c2.com/cgi/wiki?AreDesignPatternsMissingLanguageFeatu... and in particular http://www.norvig.com/design-patterns/

[dragonwriter]

No, what it means is that instead of documenting pattern templates that you have to fill in with the bits that pertain to your use case, you can provide library functions (or, in some languages, library macros) that take well defined arguments and do what the pattern is intended for, rather than providing boilerplate fill-in-the-blanks code Mad Libs.

Instead of books of design patterns, you have code libraries with APIs, and you don't have to rewrite the code following the pattern for each new project.

The less expressive the language is, the more need there is for template-style design patterns. The more expressive the language is, the more patterns can be implemented in reusable code.

[tomp]

FactoryFactoryFactoryClass, most of dependency injection frameworks, anonymous classes, several different one-method interfaces, (such as event handlers/observers), and probably more become unnecessary when you have first-class functions.

[fzltrp]

Note that it also becomes easier when class types (generally speaking) are available.

Also, one interesting aspect of interfaces is that they act as tags, allowing for stricter formal contract checking (as in: am I registering a function to this Observable which is meant to deal with its events, or is it just a coincidence that the function signature matches?).

[huherto]

I am currently experimenting with Spring JavaBased config (As opposed to XML based) It seems to me that a lot of those factories are created to be able add complex behavior in the XML configuration. I almost want to say that it is XML injection what is causing such complexity.

[tomp]

No no no, I wasn't trying to say that Factory pattern in itself is useless, or dependency injection frameworks, or similar. These are all useful things, time-tested. However, in a language with first-class functions, all these cease to be "obscure patterns that you need a certificate to think of and design" and simply become "just another day of life". For example, you don't need to create a FactoryFactoryFactory class with appropriate functions and the whole framework around it, you simply write a function that takes the appropriate parameters and returns the appropriate object, and pass it around. Similarly, you don't need a complicated Dependency Injection framework, you just pass parameters to a functions and it gives you what you want. It's that simple. Still, occasionally some advanced IoC functionality can be useful, but much less frequently.

To see this in action, try googling "factory pattern in Python". You will find hardly any results.