
A hypothetical counterexample to "succinctness is power" - dfranke
Let's construct a hypothetical language called Arc'.  Arc' is identical to Arc except for one difference, as follows.  Arc' has two styles of parentheses: () and {}.  The two have no semantic difference, but, gratuitously, the programmer is required to alternate between using () and {} at each level of nesting depth.  Failure to do so is a syntax error.<p>So, trivially, for every Arc program there is an equivalent Arc' of the same length.  So Arc and Arc' are equally succinct.  However, without the assistance of an editor that would rewrite your parentheses for you, Arc' would be an absolute bear to work with for exploratory program.  A change as simple as adding a conditional around a large block of code would require toggling the form of every paren within that block.  I'd rather work in FORTRAN.<p>So, while Arc' is equally as concise as Arc, it seems to me that it is considerably less powerful.
======
andreyf
Oi, meddling with such definitions indeed puts us dangerously close to
philosophy. As PG says in one of his essays, "the concepts we use in everyday
life are fuzzy, and break down if pushed too hard". You're pushing too hard.
It's a rule of thumb, not logical truth.

If you insist on a logical truth, however, I think it's best to say that
_everything else being equal_ , a more succinct language is more powerful than
a less succinct one.

~~~
henning
Yes, don't challenge anything Paul Graham says, even if you have some way to
back it up.

~~~
yters
Right, that's the short road to negative karma, otherwise known as hell.
Unfortunately, this post may qualify, since pg isn't a fan of saying things
need to be kept under wraps. However, this is really a clever piece of reverse
psychology, when you take into account the non conformist and devil may care
attitude of us hackers.

------
etal
A program written in Arc' has the same number of characters and tokens, but
the specification of Arc' is slightly larger than that of Arc, so the
languages themselves aren't quite equivalent. But, point taken. Power involves
succinctness, simplicity, orthogonality and generality; Arc' certainly fails
simplicity and orthogonality.

And, surely it wouldn't be too hard to write an editor mode to automatically
toggle the braces and parens as needed, so with that enhancement writing Arc'
would feel only slightly more awkward than writing Arc. The size of the
language specification is what affects the ease of writing tools to manipulate
it.

------
mojuba
This is a nice thought experiment. We all know it proves nothing and at the
same time, formally, it does prove something.

Let's get back to PG's original essay. What he says essentially is, if the
goal of high-level languages is to make computer instructions (programs)
shorter, then making them even shorter might be the ultimate goal of any high-
level language. The shorter the better. Sounds like a very valid point.

However, there's something I think PG omits or disregards - the complexity of
the language in terms of the total number of abstractions introduced, which
intuitively should be low as well. In Lisp, which itself is a succinct
language, you may have a framework with some number of functions in one case,
and an equivalent framework with fewer functions in another case. Same applies
to built-in constructs and notions - you may have fewer notions that cover
same scenarios or vice versa, both producing (roughly) the same length in
terms of tokens. But clearly, there's a difference and we'd prefer the
framework that has fewer functions/abstractions/notions to remember.

So if we agree on this, Arc' is bad because it introduces more notions while
achieving no or very little effect, if not harm actually.

------
jdvolz
Wouldn't it be pretty easy to write an Arc (or even Arc') program to do this
for you automatically?

My first macro in Arc' would be "arcp" a macro which took Arc code and
translated it to Arc' code. Then you just wrap every file in:

(arcp ;;file contents )

So, based on that, Arc' has an extra macro compared to Arc and extra entries
in each file, and thus isn't as succinct as Arc and thus isn't as powerful as
Arc -- if we're going to be philosophical about it.

------
DanielBMarkham
I've been thinking about PG's assertion that more "powerful" languages express
things with less code for some time now.

I just can't say that I'm a believer. There are a lot of reasons (perhaps an
essay in there somewhere), but the main one is -- it seems to me a fallacy to
think that as languages evolve they work with smaller sets of code. Part of
the problem is that languages are so contextual: PG's challenge is a salient
example of context. If the context is "typical" web programming, the code set
is small. How do we define "typical" web programming? Why, the type of thing
PG trimmed up Arc to perform! The circle is complete.

I'm not happy with my disagreement, however. I think there's just something
intuitively wrong with PG's assertion. Wish I could express my concerns
better. His belief obviously fails at the extreme. One can imagine a program
that says "do stuff" which then proceeds to solve world hunger or download
pictures of Britney Spears. It would be difficult for an observer, however, to
determine what "do stuff' actually involved.

Programming is not a solitary sport.

~~~
nostrademons
I think that the actual basis for "less code = more powerful" is
psychological. You are less likely to want to write a feature if it requires
putting up lots of boilerplate code. People tend to do what they want to do
(discipline is highly overrated ;-)). So in a language that requires lots of
boilerplate, you end up writing fewer features, even beyond the cost of typing
(which is negligible for good typists).

Of course, there are other psychological factors at work. You are less likely
to work on a project where you have to keep lots of unknowns in your head at
once, and adjust them all simultaneously. (I suspect this is why Arc took 6
years to write.) You are not likely at all to work on a project where you
can't understand the required language features, or can't figure out the
existing code base. And it's no fun working on a project where every time you
fix something, something else breaks.

The "ideal language", for me, would be the one that minimizes the sum of all
these factors. IMHO, Java goes too far with the boilerplate, eliminating the
gains it makes in not having to keep much of anything in your head. Arc makes
for inscrutable code bases and requires that you keep the definitions of any
macros you're using in your head. Complex JavaScript tends to break when you
make small changes. Python hits the sweet spot for me, with liberal helpings
of doctest and docstrings.

~~~
DanielBMarkham
Oddly enough, there's something a little bit BS-like (EDIT: 1960s-ish) about
PG's definition of "powerful". (I know Paul, you hate having to explain
everything little thing you say, but bear with me here)

The word "powerful" is such a generic it doesn't work here. I guess the
simplest way to explain is to look at what I think Paul is saying: as our
languages evolve, it takes less "stuff" to tell the computer what we want it
to do.

The problem here is that the amount of "stuff" required is as much a user
interface problem as it is a syntactical one. Surely neural interfaces can
render most coding obsolete eventually. Perhaps well inside our 100-year
timeframe. So what, then, is meant by powerful? Is it our conversation with
the computer we are trying to maximize, or our conversations with each other?
In other words, am I trying to get to the quickest magic to get from my
thoughts to code, or am I trying to get to the quickest magic from my team to
a solution that we all understand? In the second scenario, the "power" of a
programming language is more about how well it can help the team discover,
implement, and maintain solutions that have value. Not about the directness of
my personal thought-to-code.

I think this second definition of "powerful" holds up better in the real
world. My opinion only, though. I don't have a bunch of essays or a cool
venture fund, so take it for what it's worth. I hate to be Mr. Definition Guy,
but it's tough to have conversations like this without understanding what the
heck we are talking about.

~~~
jimbokun
"Surely neural interfaces can render most coding obsolete eventually."

I am skeptical of that. I think that a good programming language can be a
great help for making ideas precise and exploring their ramifications. We may
have some vague notion of what seems a great idea, but when we go to express
it in a precise way find out that there are significant obstacles that were
not at first evident. So, the read-eval-print-loop of a good "exploratory"
language might still be very useful, even in a world with neural-computer
interfaces.

~~~
DanielBMarkham
Wouldn't a good neural interface create some abstraction of a read-eval-print
loop that would seem natural and not part of some other language?

I mean, don't we do the same thing when we have conversations with other
humans? Let's say we're going out and the other person wants some things from
the store. Surely we are both capable of discussing what's needed from the
store without having to formalize it so much, right?

So I take it that perhaps you feel that machines will always need a more
formal conversation than humans? I find that a little difficult to believe,
what with machine translation, OCR, voice commands and such. (None of which
are perfect, but all of which are getting closer to being very useful)

I guess I would be interested in what part of a neural interface would not be
able to provide the stimulus a programmer is already receiving from his
programming IDE? And if the neural interface can make it the same stimulus,
surely there would be room for improvement, no?

This conversation is continued in a new post --
<http://news.ycombinator.com/item?id=109286>

------
greendestiny
Stop trying to reduce the useful statement about succinctness being power into
some logical rule or definition. Clearly its not a complete definition of
language power, but contriving examples to break it doesn't prove an awful
lot. I'm sure there exist any number of languages that are succinct but
contain pathological clauses which make programming difficult.

I'm pretty surprised that this community is having such a problem with
language succinctness being an indicator of language power.

------
greatness
Interesting proof. I believe this does sufficiently prove BREVITY isn't the
only consideration one must take while creating a language design.
Fortunately, PG also considers other things as well, such as generality and
flexibility. I agree incidentally, Arc' sounds like a terrible language. :P

I believe the problem you may have with the "succinctness is power" philosophy
PG uses is merely a matter of communication; the sad part about the English
language (or any spoken language), is that it isn't perfect, and there is no
way to exactly specify the full description of what he means by "power". Why?
People learn most of their language in context, and depending on how that
individual learned it and that persons professional and unprofessional
background, there may be subtly different definitions of the way they use
words. For example, a mathematician has a significantly different definition
of the word "equal" than, say, the lady who works at the register of the local
McDonald's.

------
benl
This argument doesn't refute anything. All it demonstrates is that
succinctness is not the only thing that enables a language to be powerful. I'm
not sure anyone has ever made that claim.

The fact that there are other things, such as sensible syntax, that can affect
a language's power should come as a surprise to no-one.

------
hhm
It proves nothing. Imagine a language named Arc'', which drops you a little
amount of blood for every keyword that is present in your computer programs.
So, if you write a program that is large enough, you die.

So, trivially, for every Arc program there is an equivalent Arc' of the same
length. So Arc and Arc' are equally succinct. However, you would no doubt
rather work in Fortran.

It does not prove a thing, you see.

~~~
dfranke
The only absurdity in that line of reasoning is the one that you introduced.
Of course it's ridiculous that a language could cause you to spill blood when
you enter a keyword. Not because we can't imagine a machine that worked in
such a way, but rather because it's a non-sequitir. You've made a mockery of
the argument merely by bringing up something completely outside the frame of
the discussion. When we talk about languages we mean them in more-or-less if
not exactly the formal sense in which Turing discussed them. Turing machines
can't implement Arc'' because they don't have a spill-blood instruction.
They're perfectly capable of implementing Arc'.

~~~
hhm
This is not ridiculous. If you don't like Arc'', you might think about this:
we have two implementations of Arc, one in a normal computer, and another in a
computer environment that makes you spill blood on every keyword, that we call
Arc''. Nobody will want to use the Arc'' implementation right?

Languages, as considered for practical use, aren't only Turing machines. In
Turing machines it's unimportant to have libraries, and you have no way to
create sockets, access to disk, or anything like that. In real-life
programming languages, the language implementation and environment does make a
huge difference. My point is: you can think of many ridiculous environments
that will make any language terrible for daily use. You can also think of many
small language variations that would make that language use terrible as well.
Thinking about those variations isn't that great... the point of succinctness
is power is: everything else equal, the shorter program wins.

And both the original argument and mine, were wrong in the "everything else
equal" part of that point. That's why that's invalid in my pov.

~~~
dfranke
> This is not ridiculous.

You're correct, insofar as if we assume the hypothesis of the Sweeney Todd
Machine, then the above becomes a valid argument leading to a valid
conclusion. However, it's an uninteresting argument because it refutes
something that nobody believes; nobody would assert that succinctness = power
when equality is defined over a domain that includes bloodletting. My original
argument assumes stronger restrictions on the domain of what constitutes a
language. Under this set of hypotheses, some people, namely PG, would assert
that succinctness does indeed equal power, and therefore a refutation of that
assertion is interesting.

~~~
hhm
How could "everything else equal" include bloodletting? Of course the
experience of using C++ is different than using C++ with knives, that's
trivial, and I'm not saying that they are the same language or environment. My
point is: the original argument makes the same trick, by making a modification
to the language / environment that makes it very unusable... my extension of
the argument to blood and knives it's just a way to show that the original
argument is using exaggeration.

Everything else equal, the shorter program wins. Arc' breaks the "everything
else equal" part of the argument very obviously, the same with the imaginary
bloody machine.

~~~
hhm
Anyway, in his article, PG doesn't actually restrict his own argument on that
way. However I don't think he's being very strict in his presentation of the
hypothesis, and while he could present it in a much more formal and precise
(and theoretically correct way), I'm not sure that would make a very
interesting essay. I imagine PG knew there might be restrictions to his
argument, such as bloodletting and Arc' (or Arc' with bloodletting, imagine
that!)... bah, who knows...

------
bfioca
An interesting example, but I'm afraid it wasted much of the time I could've
used writing a succinct program in arc. :)

------
parenthesis
Are you a philosopher?

------
cestith
Do you mean less powerful, or less pleasant? The Arc' language would still
have all the same semantic power for the syntactic length. It'd just be a
royal pain in the behind to use.

------
byrneseyeview
If Arc' became more popular than Arc, I suspect that M-x arc'-mode would
handle the (/{ issue for you.

For any rule you can come up with, it should be possible to compile the rule
away (e.g. if Arc'' was Arc in ROT13, we'd all write in Arc and then apply
ROT13). Which should demonstrate that your example is weak. Can you imagine a
language as concise as Arc, and analogous to Arc, that can't be converted
directly into Arc through a simple process like the one above?

------
WilliamLP
It seems obvious to me that there are many cases where you're better off
writing longer code because it is either going to be easier to write or easier
to understand. This is especially sometimes true for programs that are quick
and dirty.

(It is absolutely true in mathematics. Sometimes a short elegant proof takes
much more time to find than simply a correct and adequate but much longer one.
I'm absolutely sure there are analogues in everyday programming.)

------
eugenejen
Not in defense of Arc, but so far your definition for "concise " is the length
of the program. But by mandatory alternating '{' and '(', you add a level of
complexity in grammar to Arc' . I guess that is the reason you feel it as less
powerful. So maybe 'concise' does not mean 'short' but means consistent and
easy grammar for expressing idea. I guess that's why people like Ruby better
than Python better than Perl.

~~~
jimbokun
Given your criteria of "consistent and easy grammar" I would put Python before
Ruby. There may be other measures that make Ruby more 'concise' than Python.

~~~
eugenejen
So I guess the original post is really a philosophical question. Because
unless "concise" can be quantified and describable, there is no way to judge a
choice of design of language is better than the other as science, because no
refutation of theory can be designed and verified. The original post only
discover that shortness doesn't mean powerful, it can be cumbersome given a
choice on a simple rules in grammar, then create a big mess for maintenance.

------
pg
There are any number of pathological exceptions. The question that matters is
whether it's true for every language that hasn't been deliberately broken.

~~~
dfranke
You originally left that as an open question:

 _What I meant was that in any language anyone would design, they would be
identical, but that if someone wanted to design a language explicitly to
disprove this hyphothesis, they could probably do it. I'm not even sure of
that, actually._

The weaker thesis is harder to contradict, though.

------
brlewis
You need a different counterexample. Arc' programs have more nodes than Arc
programs.

In Arc, parens only define the structure of the parse tree. They carry no
additional information. In Arc' the compiler's behavior must change based on
the type of paren. You need an additional node of information for each paren
pair to know its type. Thus Arc' programs are substantially longer when
measured by nodes.

~~~
dfranke
You don't need additional nodes. The syntax of Arc' is still context-free.
Paren types can be checked on-the-fly during parsing and never have to enter
the AST.

~~~
brlewis
Lucky for Arc' programmers. They don't need to worry about paren types for
expanded macros.

OK, so you added complexity by making the reader more complex. I still think
the evaluator has to be different for this to be a meaningful example.

~~~
dfranke
What? Why would I want to introduce more differences? That the languages are
so similar is the strength of the argument. Identical concision, different
power, QED.

~~~
brlewis
I don't want more differences, just difference in a different place.

You could have, for example, defined Arc'' as identical to Arc except gzip-
compressed. Once you have a parse tree, Arc, Arc' and Arc'' are identical, but
Arc'' is actually more concise. But that's useless, because nobody is saying
conciseness and power are identical. Arc' is no more likely to educate anybody
than Arc'' is.

------
rsheridan6
If you use paredit.el in Emacs, it would be absolutely trivial to write Arc'.
Some Schemes are already sort of like that, because they allow you to use
brackets as parentheses, and they require that closing brackets match opening
brackets, and closing parentheses match open parentheses. It's not a problem
at all.

~~~
dfranke
I'm sharing PG's premise that languages shouldn't require such tools in order
to write them effectively. Eclipse is not an excuse for Java.

~~~
byrneseyeview
Would Eclipse be an excuse for Java if it were a language rather than an IDE,
and if it compiled into Java?

~~~
dfranke
Sure, but then you're not working in Java any more. You're just using it as
object code.

------
nonrecursive
Your example isn't complete. If you're determining whether "succinctness is
power", you would need to compare Arc' to some Arc'-like language which is
less succinct but which has the parentheses requirement.

------
amichail
Maybe you could use Kolmogorov complexity as a measure of simplicity?

<http://en.wikipedia.org/wiki/Kolmogorov_complexity>

~~~
dfranke
Kolmogorov complexity is with respect to a given description language, so that
begs the question somewhat.

~~~
aston
Upmod just for correctly using "begs the question."

~~~
noonespecial
Agreed. That almost never happens anymore! Well done.

------
gibsonf1
Arc' fails the saved time test as the gratuitous syntax would take more time
to learn, debug, write editor extensions for, etc - making it less powerful.

------
dazzawazza
Interesting but surely Arc' is less succinct since succinctness is brevity and
clarity and the extraneous bracketing reduces clarity?

~~~
dfranke
> succinctness is brevity and clarity

Which is it? Those are two very different things.

> extraneous bracketing reduces clarity

I'd argue that clarity is increased. It makes it easier to tell what open
paren matches what closing paren.

~~~
derefr
> Which is it?

It is power, of a sort: brevity (voltage) multiplied by clarity (amperage).

The clarity, however, is not clarity of the syntax, but of the resulting AST.
Assuming that the AST is such that every construct in the code is encoded
somehow in the resulting transformation to the AST (otherwise the differences
would just be artifacts of implementation), it would require two kinds of
blocks: (parenthetical-form ...) and (brace-form ...). If these evaluate the
same, and are semantically equivalent, in all cases, this is definitely less
clear.

~~~
bayareaguy
Two problems with this electric analogy are

a) Voltage and current are related by I=V/R (which I guess you could also
express as (let ((I (/ V R))) I)) and

b) Brevity and clarity are closer to the ideas of resistance and/or impedance.
The shorter and more precise the language, the less it prevents the problem
from being solved.

------
mwerty
reference: <http://www.paulgraham.com/power.html>

------
febeling
Contrived.

------
kashif
gobleedeegook!!

