4 ms·

A hypothetical counterexample to "succinctness is power"

18 points by dfranke 19y ago

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. 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. So, while Arc' is equally as concise as Arc, it seems to me that it is considerably less powerful.

gibsonf1 19y ago
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.
- deleted 19y ago
  [deleted]
parenthesis 19y ago
Are you a philosopher?
dazzawazza 19y ago
Interesting but surely Arc' is less succinct since succinctness is brevity and clarity and the extraneous bracketing reduces clarity?
- dfranke 19y ago
  > 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 19y ago
    > 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 19y ago
      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.
etal 19y ago
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.
amichail 19y ago
Maybe you could use Kolmogorov complexity as a measure of simplicity? http://en.wikipedia.org/wiki/Kolmogorov_complexity http://en.wikipedia.org/wiki/Kolmogorov_complexity
- dfranke 19y ago
  Kolmogorov complexity is with respect to a given description language, so that begs the question somewhat.
  - amichail 19y ago
    Try zip.
  - aston 19y ago
    Upmod just for correctly using "begs the question."
    - noonespecial 19y ago
      Agreed. That almost never happens anymore! Well done.
  - byrneseyeview 19y ago
    Arc and Arc' could be compared as long as they're both written in the same language. Arc is written in Mzscheme. Arc' is..?
mwerty 19y ago
reference: http://www.paulgraham.com/power.html http://www.paulgraham.com/power.html
bfioca 19y ago
An interesting example, but I'm afraid it wasted much of the time I could've used writing a succinct program in arc. :)
greendestiny 19y ago
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.
andreyf 19y ago
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 19y ago
  Yes, don't challenge anything Paul Graham says, even if you have some way to back it up.
  - yters 19y ago
    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.
- dfranke 19y ago
  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.
- yters 19y ago
  Border cases are where the interesting things lie.
WilliamLP 19y ago
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.)
deleted 19y ago
[deleted]
greatness 19y ago
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.
jdvolz 19y ago
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.
benl 19y ago
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.
mojuba 19y ago
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.
brlewis 19y ago
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 19y ago
  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 19y ago
    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 19y ago
      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 19y ago
        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.
hhm 19y ago
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 19y ago
  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 19y ago
    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.
kashif 19y ago
gobleedeegook!!
DanielBMarkham 19y ago
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 19y ago
  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.
nonrecursive 19y ago
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.
rsheridan6 19y ago
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 19y ago
  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 19y ago
    Would Eclipse be an excuse for Java if it were a language rather than an IDE, and if it compiled into Java?
    - dfranke 19y ago
      Sure, but then you're not working in Java any more. You're just using it as object code.
febeling 19y ago
Contrived.
byrneseyeview 19y ago
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?
eugenejen 19y ago
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 19y ago
  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 19y ago
    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.
cestith 19y ago
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.
pg 19y ago
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 19y ago
  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.

18 points by dfranke 19y ago

gibsonf1 19y ago

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.

deleted 19y ago
[deleted]

parenthesis 19y ago

Are you a philosopher?

dazzawazza 19y ago

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

dfranke 19y ago
> 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 19y ago
  > 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 19y ago
    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.

etal 19y ago

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.

amichail 19y ago

Maybe you could use Kolmogorov complexity as a measure of simplicity? http://en.wikipedia.org/wiki/Kolmogorov_complexity http://en.wikipedia.org/wiki/Kolmogorov_complexity

dfranke 19y ago
Kolmogorov complexity is with respect to a given description language, so that begs the question somewhat.
- amichail 19y ago
  Try zip.
- aston 19y ago
  Upmod just for correctly using "begs the question."
  - noonespecial 19y ago
    Agreed. That almost never happens anymore! Well done.
- byrneseyeview 19y ago
  Arc and Arc' could be compared as long as they're both written in the same language. Arc is written in Mzscheme. Arc' is..?

mwerty 19y ago

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

bfioca 19y ago

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

greendestiny 19y ago

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.

andreyf 19y ago

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 19y ago
Yes, don't challenge anything Paul Graham says, even if you have some way to back it up.
- yters 19y ago
  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.
dfranke 19y ago
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.
yters 19y ago
Border cases are where the interesting things lie.

WilliamLP 19y ago

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

deleted 19y ago

[deleted]

greatness 19y ago

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.

jdvolz 19y ago

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.

benl 19y ago

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.

mojuba 19y ago

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.

brlewis 19y ago

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 19y ago
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 19y ago
  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 19y ago
    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 19y ago
      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.

hhm 19y ago

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 19y ago
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 19y ago
  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.

kashif 19y ago

gobleedeegook!!

DanielBMarkham 19y ago

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 19y ago
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.

nonrecursive 19y ago

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.

rsheridan6 19y ago

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 19y ago
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 19y ago
  Would Eclipse be an excuse for Java if it were a language rather than an IDE, and if it compiled into Java?
  - dfranke 19y ago
    Sure, but then you're not working in Java any more. You're just using it as object code.

febeling 19y ago

Contrived.

byrneseyeview 19y ago

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?

eugenejen 19y ago

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 19y ago
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 19y ago
  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.

cestith 19y ago

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.

pg 19y ago

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 19y ago
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.