Lambda the Ultimate

To test the truthfulness of the "succinctness is power" hypothesis we simply need to consider the case of any maximally succinct language. That would be a language with maximum information content (i.e. no more compression is possible). Such a language would clearly be utterly unusable.

I suspect that the definition of "succinct" that Graham has in mind is along the lines of that given by the American Heritage Dictionary: "Characterized by clear, precise expression in few words". "Maximally succinct" is therefore not some sort of equivalent to "maximally compressed" or "cryptic", both of which are almost the opposite of "succinct", due to not being clear.

That's an interesting point. I had always assumed PG thought that less tokens = better. He basically says that in his essay, but now I realize that there's an invisible clause attached to his statements along the lines of "don't take this to the extreme."

Of course, that brings up the question: at what point does this clause kick in? Where do you draw the line?

but now I realize that there's an invisible clause attached to his statements along the lines of "don't take this to the extreme."

Your assumption that Paul is advocating less tokens, I think is a sound one. His essay is clearly emphasizing brevity as the most important quality of code.

Where do you draw the line you ask? For a general purpose programming language we could do the following thought experiment: imagine writing a million line program in a language. Now imagine giving it to someone else who is not an expert in your language and ask them to find and correct the bugs.

I think the line is precisely where compacting code any further would start to have a negative impact on debugging. Of course, this only applies to languages intended to be used on medium to large software projects.

Yes, that seems logical. But would it not be wise to simply invest time into learning the less verbose language? If shorter really is better, then presumably the small start-up cost would quickly be overshadowed by the benefits, would it not?

Th cst f smllr cd s tht t tks mr tm t prccss rgrdlss f yr lvl f prfcncy.

I don't understand. How does removing vowels from English words make it impossible to be fully proficient in reading them?

I think the suggestion's more that t's stll slwr hwvr prfcnt y r[1]. This isn't true in general though - increased proficiency can allow someone to quickly recognise and work with a conceptual framework that enables much faster communication overall.

[1] it's still slower however proficient you are

But how does his example show that? Why would removing vowels prevent somebody from ever being 100% proficient at understanding it?

It was never said that it does:

"The cost of smaller code is that it takes more time to proccess regardless of your level of proficiency."

That was my fault. By "100% proficient," I meant that it doesn't take any more time to process than the base case.

There are sometimes ambiguities that can only be resolved with context, which I think's likely to slow anyone down at least somewhat.

Ohhhh! Wow. I completely missed that. Good point. So once a language becomes concise to the point where ambiguities arise, comprehensibility goes down? That sounds true, although I can't think of any programming languages that are ambiguous in that manner. I suppose the definition of "ambiguous" could be fudged a bit to mean "not initially apparent," although even then I'm having a hard time coming up with examples.

Pretty much anything with sufficient overloading, especially where multiple (conceptual) types have the same representation but you're working in an untyped language. If you get the conceptual hints early and in convenient places you do less work inferring the relevant framework in which to understand what's going on.

changePalette or launchMissiles is far more informative than OUT portNumber!

Those seem specific to a set of circumstances, rather than universal to the language. After thinking about it for a while, I've come to the conclusion that program length should be minimized along with the amount of work your brain has to do. (ignoring the time it takes to actually learn the language, of course.)

Does that make sense, or am I delusional again?

I've come to the conclusion that program length should be minimized along with the amount of work your brain has to do.

This seems odd. The amount of work necessary to understand a program has a direct impact on maintenance costs, with a high constant multiplier and superlinear order of growth. The program length has comparatively small costs (disk space, build time). Why wouldn't any rational developer optimize cost of understanding at the expense of brevity?

Whoops, sorry, that's what I meant. I forgot to point out the relationship between the two. Actually, I suppose I could just drop off the "program length" clause completely: "power is inversely proportional to the amount of cognitive load."

How does that sound?

Paul said:

If smaller source code is the purpose of high-level languages ...

This is very clear: he is talking about compact code. As a result I was interpreting the definition of succinct as more along the lines of the Random House Unabridged Dictionary definition:

1. expressed in few words; concise; terse.
2. characterized by conciseness or verbal brevity.
3. compressed into a small area, scope, or compass

It was my impression that the article was focusing on brevity as opposed to clarity. I believe that both are important chracteristics in a programming language. However I think it is safe to say that clarity trumps brevity when we look at how effective a programming language is for the purposes of developing software.

I've just been reading about the K language which can only be described as 'terse'. It has a small number of heavily overloaded tokens. For example, the '!' symbol has three different, unrelated meanings. K programs are undoubtedly brief but I think the ability to read them must be hard won.

The prime examples of extremes are APL and COBOL. APL is close to maximally succinct, but sacrifices a huge amount of readability for that.

Thanks very much for the interesting-looking references.

Regarding APL, I certainly understand that many people find it hard to read. But it's possible to get comfortable with it, even good at it. I used it mainly 25-30 years ago, but was surprised how well I could read from the FinnAPL Idiom Book when I pulled it down from a (dusty) shelf the other day. Perhaps APL takes the single-character operator idea too far, but in smaller doses it works quite well, for example in traditional written mathematics or (I think) in Haskell.

Of course APL will look pretty foreign to those who are more used to Pascal/C/Java, etc., but then Mandarin will do so to those who know, say, English, Dutch and German. I assume that my history with APL would help me learn J or K, but then perhaps even my exposure to SML and Haskell would help, relative to someone with only an imperative language background. (How much of this is syntactic, how much semantic? Does Mandarin differ semantically from European languages as much as it does syntactically? I think Chung-chieh Shan would be the person to ask re the latter ... .)

I must admit I was surprised to see someone in a blog post elsewhere refer to Haskell as "looking like line noise": it looks very much like math notation to me anymore. It is more concise than ML, which seems a bit cluttered with keywords to me now (fun, orelse, andalso, etc.). But I must admit that I pronounce the of from ML's datatype declarations when reading data declarations in Haskell: the direct juxtaposition of capitalized value and type constructor names in Haskell's version can be a bit confusing, especially for beginners. Perhaps this is one place where Haskell went a bit too far in the "succinct" direction.

Anyway, I hope you will indulge me in coming to the defense of APL, as an old friend of mine (I received my first paycheck using it back in '76). And I hope that everyone here would admit admit that APL was a bold and inventive stroke by Iverson, especially considering the time.

I basically agree with your comments about learning APL (which I used just a little about 20 years ago). With effort, it is possible to get comfortable with it. But the effort is considerably larger than for more verbose languages.

About the value of the APL experiment: I emphatically agree. Iverson deserved that Turing award. What is sad, to me, is that other languages have yet to 'learn' enough from APL's successes. APL is way more polymorphic than Scheme for example [here I mean the language plus the standard library]. The only work that I know why has attempted to give types to that kind of polymorphism is Barry Jay's FISh. APL's polymorphism made sense (unlike the ad hoc polymorphism in Matlab); why can't it be expressed in Haskell?

If only physics was that universal. We can always dream :-)

What are the programming equivalents to mass and acceleration? ;D

Isn't work force * distance?

I meant.. Mass * Acceleration * Distance / Time