Just do yourself a favor and read it the way it's intended: As a dictionary.

Design patterns give you a vocabulary to describe design choices you made. They don't give you a set of things that inform design.

I can't remember who, but someone's said that design patterns really would be more appropriately called something like "palliatives for static manifestly typed languages."

Knowing idioms that relate to certain expressive / organizational problems is a good thing (especially if you're primarily working in a static manifestly typed language), but there's a weird overcelebrated status to them, and I'm not sure I'd encourage a developer I was training to become familiar with a full catalogue of them.

It seems to me that you could regard something like the Y Combinator as a design pattern that is a palliative for dynamic implicitly typed languages.

All kinds of languages have patterns. Whatever kind of language you use, learn the patterns that are relevant/useful for it.

A design pattern is a well-known way to do something. It's important so you don't reinvent the wheel.

They're different than external libraries, because usually the details of your application are closely integrated with how you implement the design pattern.

What are some resources outside of gang of four?

Head First Design patterns

Patterns of Enterprise Application Architecture

Enterprise Integration Patterns

Just start reading some Martin Fowler books, you will be up to your ears in patterns in no time :)