Only after realising what 'problem' a pattern solves, perhaps by experiencing the problem over and over. I think this is why design patterns in OO are commonly abused (overused) - people learn about them without understanding the problem.

Sure, I agree. Novice programmers are not going to instantly understand what a category is, or how to utilize compositional programming without a bunch of experience and examples. However, I think for programming to progress we need to develop theory.

The proof is in the pudding.

You know why we have JavaScript? Because someone went and built it. Once it was built, it existed and people used it. All the theories about what a scripting language for the web should look like fell out the window the moment someone went and put one in their browser.

De facto standards beat de jure standards. Every time.

Theory is great. It makes for amazing and stimulating conversation. But in the real world the only thing that counts is building shit.

PS: this is also why English is the global language of trade and not Esperanto. Even though English is both harder to learn, has a terrible "API", and inconsistent semantics and grammar and syntax. Esperanto is clean and well designed and and learnable in 150 hours and not used by anyone.

> De facto standards beat de jure standards. Every time.

Only for a very base definition of "beat". People are falling over themselves to write X-to-Javascript compilers because Javascript simply isn't good enough.

Well, presumably an advance will eventually provide a competitive advantage.

For example, before the Copernican revolution, we had a model for the cosmos that made decent predictions. The heliocentric model actually made worse predictions for a long time until it was evolutionary improved. However, to the early scientists who adopted it, the heliocentric model "felt right."

Maybe right now programming in a shitty language like javascript with no regard to program structure is better at "getting shit done" than programming in a functional language using universal abstractions like composition. To people who study and think about it, though, it "feels right." Perhaps if they stick with it and perfect the art, it will eventually provide such a competitive advantage that it will be universally adopted.

There are already JS libraries for things like functional composition. If current trends persist, it will eventually get language-level support for that.

JavaScript is a tricky language like that. It lurks in dark alleys, beats up other languages and rifles through their pockets for spare syntax and semantics. Much like English.

Yeah, but the GoF book mostly is gobbledygook when designing program composition - it mainly shows how to patch java and C++ to be more like scheme. It does not actually help that much in program composition.

To quote Feynman incorrectly, Design patterns ala GoF are about as usable to programmers as ornithology is to birds.

> Philosophy of science is about as useful to scientists as ornithology is to birds

> Design patterns ala GoF are about as usable to programmers as ornithology is to birds.

So here design patterns is compared to philosophy of science. I think of design patterns more as a toolbox than an inapplicable study of the art. Much like how math is essential for science, I feel that solid programming abstractions and patterns are essential for software development.

"I feel that solid programming abstractions and patterns are essential for software development. "

Yeah, I feel exactly the same. To me object oriented programming as served by C++/Java/C# is good and fine for building abstractions over existing systems.

System design however, is served much better by thinking the system in terms of fundamental data structures, graphs and relational models rather than as an obtuse object hierarchy of some sort. This is my main gripe with GoF - it's used as a some sort of toolbox for software design when actually it just explains how to convert familiar and non-seremonial idioms from other languages to C++'s verbosity. If the student is not exposed to software construction in these other languages and just to GoF he/she is missing on so much (I know I did, at least).

But this is just my personal preference, maybe someone else writes much better software when thinking in objects but for me my initial years as a programmer were basically wasted in trying to build beautiful object hierarchies out of everything.

I write mostly C++ as my day job. Software modules which are built by embracing the C++ object model to it's full extent are the most horrible stuff I have to deal with :)

I think the complaint is basically that the majority of GoF patterns are better solved simply by having first class functions, and many students won't realize this because they only know languages without them, so they never develop an intuition for seeing such simple ways of solving problems, and instead build complicated machinery to do trivial things. And GoF tends to legitimize this approach in their minds.

It's a good book, but it's not a book for beginners.