What are some examples of "wartiness" making a programming language more useful?

Question

From the accepted answer to "Why is Lisp useful?":

 5. Wartiness. The real world is messy. Pragmatic coding winds up having to either use or invent messy constructs. Common Lisp has sufficient wartiness that it can get stuff done.

This thought has occurred to me, too. I'm currently developing an application whose backend I chose to write in Haskell, and whose frontend is in PHP. My experience has been that dealing with messy code in PHP is much easier than dealing with messy code in Haskell. However, it's my own code, and my PHP code probably isn't all that bad.

A simple example of "wartiness" is PHP's == (equality) operator. You know, the type of equality where '' == 0 is true. Since I'm wary of ==, I often choose to use PHP's === (strict equality) operator instead:

$is_admin = ($gid === 24 || $gid === 25);

However, the above usage turned out to be wrong. The $gid value came from the database, and is still a string. This time, the strict equality operator bit me, and I would have saved myself a few minutes by simply saying:

$is_admin = ($gid == 24 || $gid == 25);

Consider another interesting identity:

php> var_dump('0012345' == '12345');
bool(true)

What the heck?! == on two strings isn't even string comparison! However, consider if the user is given an ID card that says 0012345, but the database ID is simply 12345. Users may have trouble logging in to your application if you chose to use ===. Sure, you'll get a bug report, and you'll be able to make your application correct rather than relying on this obscure feature. But it'll take more time. I'd rather spend that time outside. It's a really nice day.

By contrast, here's an example of wartiness that is not helpful in most cases:

js> parseInt(031);
25

What are some more concrete examples where "wartiness" helps you Get Things Done? Please explain why; don't just list features Haskell doesn't have.

Another way of putting it: what are some warty language features to be aware of, and how can we use them to save time?

Answer 1

I think the general principle here is that when the shape of the warts in the language happen to match the shape of the warts on your requirements then they cancel out and you can program as if neither were warty.

You asked for an example, so I'll say that in java-script you can "parse" JSON by just using eval().

I picked that example because it shows the dangers of the "wart alignment" style of programming - doing an eval() on JSON strings is a huge security risk unless you control the string you're evaluating completely. (Which is why I'm calling it warty - the definition is a little subjective).

In your examples, string to int conversions built into the language were great when that's how you wanted it to work, but when it worked differently (like parseInt(031) --> 25) it was not wartiness that helped, but actually wartiness you had to program around.

The problem with wartiness in a programming language is that you generally have limited control over it, so if your requirements drift a bit so that the warts no longer line up, all you're really left with is two sets of warts to program around, those of your requirements plus those of the language.

Answer 2

Quick example, not the best.

In CL, Truth is anything not nil. That is kind of sketchy, right? Typically, you want to see if something is True, not determine if it's not-nil. True is a subset of non-nil.

But if you squint a bit, you realize it doesn't actually matter most of time, and also it reduces the size of code, instead of asking (if (eq foo #t) this that), you can do (if foo this that). Scheme takes the first approach.

I'm reasonably sure a PL designer can give some great discussions here, but unfortunately, that's not me today.

To quote a quote of vague provenance...

• Schemer: "Buddha is small, clean, and serious."
• Lispnik: "Buddha is big, has hairy armpits, and laughs."

Also, I'm quoted. Woot!

Answer 3

An easy example is about half of C++. There are sections of C++ which frankly are just diseases that should be removed, and it's obvious- for example, array/pointer decay. But they're kept because it increases C compatibility- a useful thing.