Hacker News Reader

Comment by sklogic | Hacker News Reader

> it will be harder for a human to follow than if you use parenthesis

Not any harder than following Master Yoda speech.

OTOH, following something (say, an English text) (which is heavily parenthesised) may be (I'm sure there is a lot of references to back this notion) exceptionally hard (even if there is just one nested level (and more levels certainly add more confusion)). Choosing flat over structured often makes a lot sense.

View on HN

Valid Forth syntax:

    6 8 7 5 4 + * - + .
     -49 ok

Tell me that's easier to read than

    8+6-(4+5)*7

Parenthesis can make things harder to understand if poorly used. RPN can make things harder to understand if poorly used.

The reverse is also true for both. Forth does not prevent bad code.

Most people find uppercase text harder to read than lowercase. Research has shown this to be the case because people are more familiar with lowercase (people more exposed to more uppercase will eventually find it easier to read).

Because of this effect you cannot trust your own sense of what is inherently easier to read, it will be biased by experience.

>you cannot trust your own sense of what is inherently easier to read, it will be biased by experience.

Funny you should say that, when basically every person in the world going through a basic mathematics curriculum will be experienced with infix notation, and completely unfamiliar with RPN.

True, maybe you for some reason have more experience with RPN. So use Forth.

But there is a clearly superior notation when you're talking about "which one will most people understand." HP calculators notwithstanding.

I find it amusing that arithmetics is always invoked in any discussion about nested expressions syntax, despite being largely unimportant in most of the typical code scenarios.

I used an arithmetic example, but since everything in Forth is just "words", it all reads the same.

And it is much closer to plain English than all that too nested languages. And most of the code must be like English, not like arithmetic expressions.

Plain English is hardly succinct and precise either.

Repeat after me: "There is no silver bullet." There, that wasn't so hard.

> Plain English is hardly succinct and precise either.

But so far it's the best form of communication we've got.

Honestly, how often do you need any deeply nested arithmetic expressions in your code? I very rarely use anything beyond an increment by one. Any time you are invoking nested logic you are already summoning a complexity problem. Luckily, it can be avoided in most of the real world cases.

How often? Quite. "Take these two points and extrapolate." "Solve this quadratic equation."

Whether you need more complicated arithmetic expressions depends entirely on what field you are working in. I would not call `8+6-(4+5)*7` complicated by any means.

Is it really that often? More than 10% of lines of code containing nested arithmetic expressions? Sorry, I find it hard to believe.

If 10% is your threshold of "often", then no. Arithmetic expressions do show up often enough in code that I work on that they should be immediately readable.

Nobody is stopping you from keeping them as readable as you like. The question here is in readability of the remaining 90% of the code, and this is exactly where nested expressions are evil and must be flattened.

In literary English, parenthetical clauses are almost always delimited using commas, and the literate reader has no problems because she's spent years practicing reading that style. She'd have no problem reading your example if she'd spent years reading that style instead.

Nesting with commas is still nesting, increasing a number of contexts to deal with simultaneously.

Hmmm. This comment made me realize that I use parens and commas too much in my sentences, in emails, chats, etc. Now for how to fix that...

I think your, convoluted, example would be better if you hadn't merely added in parentheses randomly. Parenthetical and asides are sub-statements, and, typically, can be omitted without losing the overall meaning of the expression.

Take my above asides ", convoluted," and ", typically,". Neither are necessary for understanding the sentence, but neither make the sentence exceptionally difficult to understand for a literate reader.

The method in which parentheses (and other structuring notations) are used is more akin to grouping from algebra and mathematics.

EDIT:

Original: OTOH, following something (say, an English text) (which is heavily parenthesised) may be (I'm sure there is a lot of references to back this notion) exceptionally hard (even if there is just one nested level (and more levels certainly add more confusion)). Choosing flat over structured often makes a lot sense.

But it doesn't make sense when we remove the parenthetical statements:

  OTOH, following something may be exceptionally hard.
  Choosing flat over structured often makes a lot [of]
  sense.

(one edit for clarity). That first sentence has lost all meaning. Following what? Following a car on foot can, indeed, be exceptionally hard. But following a slug is often exceptionally easy.

A more reasonable version of your sentence:

  OTOH, following something--say, an English text--which
  is heavily parenthesised may be, I'm sure there is a
  lot of references to back this notion, exceptionally
  hard (even if there is just one nested level (and more
  levels certainly add more confusion)). Choosing flat
  over structured often makes a lot sense.

Now the remaining asides (demarcated using the various English notations of em-dash, comma or parenthesis) can be removed without losing the general sense of your sentence.

I admit my hastily written example is clumsy, but the general idea still holds in your rendering of it.

Nesting with commas is just as confusing as nesting with parenthesis. It forces your reader to operate with more than one contexts at a time, and this is exactly what pushes up the complexity level.

Even in Lisp, I realised that I always tend to build flat DSLs instead of the nested, using the non-parenthesised punctuation wherever possible. And I am not alone, take a look at the LOOP macro for example.

Reply on news.ycombinator.com