Prog21: Puzzle Languages(prog21.dadgum.com)
prog21.dadgum.com
Prog21: Puzzle Languages
http://prog21.dadgum.com/38.html
2 comments
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.
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'."
http://c2.com/cgi/wiki?BondageAndDisciplineLanguage
"Authors of BondageAndDisciplineLanguages believe their concepts of the Higher Principles of Computer Science should apply to how you say 'Hello World'."
http://c2.com/cgi/wiki?BondageAndDisciplineLanguage
Perhaps it's simply dogmatism?
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).
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).
On reddit some people made comments similar to yours, to which some other people replied that the author knows FP languages, and Erlang, and all this stuff.
Really, read his other blog posts :) He's probably more comfortable with "puzzle languages" than the C family tree...
Really, read his other blog posts :) He's probably more comfortable with "puzzle languages" than the C family tree...
In an earlier post, he quotes Chuck Moore from
http://www.computerworld.com.au/article/250530/-z_programmin... ---
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.
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.
I wonder where lisp falls in puzzle languages?
Wherever you need it to fall. :-)
[deleted]
The languages he describes as "not" puzzle languages are all spiritual descendants of C and Algol, which is a very familiar idiom to many of us.
I imagine that Forth is far less of a puzzle language for Chuck Moore, it's inventor, and that he might find Ruby a bit of a puzzle.