
Prog21: Puzzle Languages - Jebdm
http://prog21.dadgum.com/38.html
======
jbum
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.

~~~
Jebdm
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.

~~~
silentbicycle
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>

------
zitterbewegung
I wonder where lisp falls in puzzle languages?

~~~
rtra
Wherever you need it to fall. :-)

