4 ms·
Not to argue that code bloat is a problem, but the concept of writing things in any dialect of Forth makes me cringe. I played with Forth. Sure you can do comp
by SomeCallMeTim 11y ago
Not to argue that code bloat is a problem, but the concept of writing things in any dialect of Forth makes me cringe.
I played with Forth. Sure you can do complex things without parenthesis, but if you squeeze something complicated into a single line equation, it will be harder for a human to follow than if you use parenthesis.
The original article also says "It's never clear how efficiently source will be translated into machine language," which is complete garbage: Most modern processors were designed precisely to optimize for the kinds of control and data structures that C creates, and C (though NOT C++) has close to a one-to-one mapping from code you write to assembly language output.
A key exception is those infix equations, which C can reorder in ways that are more optimal than a naive developer writing Forth would create, so this hardly seems like a recommendation for Forth.
This is all orthogonal to whether bloat exists or is a bad thing. I think that bloat exists and is a bad thing primarily because developers are some combination of lazy, unskilled, or pressured to complete features on constant deadline. And honestly, in most cases it's probably all three, though I would guess anyone reading HN is mostly afflicted with the last.
- sklogic 11y ago> 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.
- SomeCallMeTim 11y agoValid 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.
- sklogic 11y agoHonestly, 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.
- MereInterest 11y agoHow 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.
- sklogic 11y agoIs it really that often? More than 10% of lines of code containing nested arithmetic expressions? Sorry, I find it hard to believe.
- MereInterest 11y agoIf 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.
- sklogic 11y agoNobody 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.
- Chris2048 11y agoMost 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.
- xamuel 11y agoIn 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.
- sklogic 11y agoNesting with commas is still nesting, increasing a number of contexts to deal with simultaneously.
- deleted 11y ago[deleted]
- Jtsummers 11y agoI 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.
- sklogic 11y agoI 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.
- phyllostachys 11y agoHmmm. 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...