|
|
|
|
|
|
by jbum
6333 days ago
|
|
|
The author seems to be equating "puzzle languages" with "languages that are very different from the languages I am comfortable with." In other words, it's a classification which is very relative to the experience of the observer. 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. |
|
|
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.