I think he was just trying to explain the difference which we intuitively see between the two kinds languages he lists, because it's not obvious what exactly the difference is.
One of these groups he calls the "puzzle languages" and the others are "not puzzle languages". Puzzle languages are usually clearly oriented toward one particular way of doing things; trying to use a different way sometimes works, but is usually fairly fragile and almost always out of place. This can be intentional or unintentional; Haskell's purity is an example of intentional limits, while the ugliness of using function pointers in C is an example of an unintentional (perhaps?) one. Converting from the original solution to a cleaner one is the "puzzle". The advantage of this is that, if you learn to use the constructs in the way the language "wants" you to, your code will be nicer and you will be able to be more productive.
On the other hand, the not-puzzle languages don't limit you as much. There is little stigma associated with doing things in any particular way, and often the methods considered "dirty" in puzzle languages are the easiest or accepted way. There is often a "cleaner" method of doing things, but the language and the language's culture don't try to push you towards it. This can make the non-puzzle languages somewhat easier to work with, because they don't push more complex abstractions on you, but as a result they lose some of the expressiveness which forcing abstractions can give.
I'd disagree with him for making such a strict distinction between the two. It's a bit of a spectrum, based on the degree to which the languages try to restrict you. For instance, one (debatable) ordering of some languages is Javascript, Perl, Python, Java, Assembly, Haskell. Note that these distinctions don't necessarily convey the existence of high-level abstractions within the languages; it only conveys the degree to which they attempt to force you into whatever abstractions they have. (In fact, it seems that the less puzzle-y languages tend to support a wider variety of abstractions.)
I don't think the idea of puzzle-yness captures the distinction quite like he wanted it to, but it nonetheless is an interesting idea.
I think it overlaps closely to what are usually called "bondage and discipline languages": they have some grand underlying design idea (everything-is-an-object, stack-based, etc.), and if you're working on a problem it fits poorly, tough. In other words, languages that strongly encourage you to program in a certain style.
"Authors of BondageAndDisciplineLanguages believe their concepts of the Higher Principles of Computer Science should apply to how you say 'Hello World'."
For example, test driven development and design patterns can be (and sometimes are) practiced dogmatically, and raise questions about how something "should" be done within the paradigm. Being forced to think differently isn't necessarily bad (or good).
One of these groups he calls the "puzzle languages" and the others are "not puzzle languages". Puzzle languages are usually clearly oriented toward one particular way of doing things; trying to use a different way sometimes works, but is usually fairly fragile and almost always out of place. This can be intentional or unintentional; Haskell's purity is an example of intentional limits, while the ugliness of using function pointers in C is an example of an unintentional (perhaps?) one. Converting from the original solution to a cleaner one is the "puzzle". The advantage of this is that, if you learn to use the constructs in the way the language "wants" you to, your code will be nicer and you will be able to be more productive.
On the other hand, the not-puzzle languages don't limit you as much. There is little stigma associated with doing things in any particular way, and often the methods considered "dirty" in puzzle languages are the easiest or accepted way. There is often a "cleaner" method of doing things, but the language and the language's culture don't try to push you towards it. This can make the non-puzzle languages somewhat easier to work with, because they don't push more complex abstractions on you, but as a result they lose some of the expressiveness which forcing abstractions can give.
I'd disagree with him for making such a strict distinction between the two. It's a bit of a spectrum, based on the degree to which the languages try to restrict you. For instance, one (debatable) ordering of some languages is Javascript, Perl, Python, Java, Assembly, Haskell. Note that these distinctions don't necessarily convey the existence of high-level abstractions within the languages; it only conveys the degree to which they attempt to force you into whatever abstractions they have. (In fact, it seems that the less puzzle-y languages tend to support a wider variety of abstractions.)
I don't think the idea of puzzle-yness captures the distinction quite like he wanted it to, but it nonetheless is an interesting idea.