Prog21: Puzzle Languages

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.

Really, read his other blog posts :) He's probably more comfortable with "puzzle languages" than the C family tree...

I write Forth code every day. It is a joy to write a few simple words and solve a problem. As brain exercise it far surpasses cards, crosswords or Sudoku; and is useful.

On the other hand, Moore has also complained about modern user interfaces by saying that they "feature puzzle-solving".

So does Chuck Moore think that writing Forth is like solving puzzles or not? I'm not sure.