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.

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

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.

I think if you tack on that qualification, then the statement becomes vacuous or at least near-so. Considerations in language design are dreadfully non-orthogonal to each other. I don't think you could measurably alter a language's succinctness without completely blowing away ceteris paribus.

Border cases are where the interesting things lie.

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.

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.

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.

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.

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.

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.

"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.

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

Typing isn't the major cost of having lots of extra characters. The cost of having lots of extra characters is the separation of concepts from one another in the code. The closer the important parts are to one another, the easier it is to scan the code looking for defects or to make updates.

It isn't the mechanics of typing, it's the entire paradigm. Why would I need to use Arabic characters in some sort of pseudo-English to represent what I wanted the computer to do? Why not spoken words? Or emotional nuances?

Not trying to go way off the deep end, but I think people make a big mistake when they say that since we have a printed code situation now we'll always have one. I'm already seeing a lot of graphical programming environments. Sure -- they suck to some degree. But each year they suck less and less. It doesn't take a rocket scientist to believe that fairly soon a lot of programming could be done graphically. I would think a spoken conversation, with the computer rapidly prototyping, executing, and testing the concepts as we discussed them, could create some very complex solutions. It's not about typing or the mechanics -- it's the paradigm that's outdated.

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.

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.

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.

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.

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'.

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.

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

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.

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

> the experience of using C++ is different than using C++ with knives

Not by all that much.

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

Are you a philosopher?

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.

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?

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.)

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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.

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

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

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

Upmod just for correctly using "begs the question."

Agreed. That almost never happens anymore! Well done.

Arc and Arc' could be compared as long as they're both written in the same language. Arc is written in Mzscheme. Arc' is..?

Try zip.

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.

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

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

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

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.

reference: http://www.paulgraham.com/power.html

Contrived.