Hacker News new | past | comments | ask | show | jobs | submit login

I understand the author origin point: To an extent, you cannot simplify an already complex domain problem with code. However, this has nothing to do with Spaghetti code. You could have one 1500 lines function that is not spaghetti code. It's hard to imagine, but it's possible. Similarly you can definitely have a bunch of functions, classes etc. that are spaghetti code, even if they are 3 lines each. Spaghetti is about the order in which you make your calls, the convoluteness of your loop etc.

I think the only point of the article is "Don't try to retro engineer the logic behind a complex domain that you do not master".

Yes - spaghetti code adds a dimension of complexity that is distinct from mere size, and in fact spaghetti code might be smaller than the same algorithm written as structured code (by the way, large blocks of structured code can be imagined by thinking of taking good code and inlining all the functions, with variable renaming to avoid clashes.)

It is fortunate that it is possible to show, via Turing completeness, that spaghetti code cannot compute anything that structured code cannot, for if not, we would still have programmers insisting (as some did, in response to 'Goto Considered Harmful') that spaghetti code is sometimes necessary.

> I think the only point of the article is "Don't try to retro engineer the logic behind a complex domain that you do not master".

AKA Chesterton's Fence:


I agree with the first of what you're saying but just wanted to add to others: Structured Code was a software engineer paradigm that didn't just mean "well organized" aka structured well; it was about specific constructs and conventions. Just as Functional Programming isn't just about having functions or being functional as in useful.

Also, I always think Turing Completeness is a red herring in conversations about Software Engineering. Turing Completeness is such a low bar, that it hardly factors into most conversations about the expression problem. It's most notable when the goal is to actively restrict completeness.

It's kinda like starting a conversation about birds and first establishing they have mass.


Structured programming, in the specific sense that we are both talking about, was such an influential paradigm that most programmers today, other than those using assembler, haven't seen anything else. Maybe that is why the author of this article seems to think 'spaghetti code' simply means large functions.

And I'm just pointing out that in this particular case, Turing completeness was very useful in decisively stopping what would have otherwise been an unending and inconclusive argument, and, regardless of whether or not it can justifiably be called a low bar, it was good enough in this case. Furthermore, It does the same in many other cases: for example, in the question of whether there are ISAs that are more computationally powerful than others. It seems to be, or at least have been, very useful in computer science even if it does not have much relevance to everyday coding, and it may not seem much of a big deal because the questions that it has solved are no longer (or never became) problems.

Huh. I made the comment about Turing Completeness being "low-bar" from the perspective of Turing tarpits [0] or NAND universality (which needs memory/flip-flops). It seems to be easy enough that languages like Brainfuck can be Turing complete with a handful of elements. So much so that C++ templates or extended regexs seem to accidentally be found to be Turning Complete.

[0]: https://en.wikipedia.org/wiki/Turing_tarpit

> In any Turing complete language, it is possible to write any computer program, so in a very rigorous sense nearly all programming languages are equally capable.

You seem to have more history on the matter than I do, so let me ask a question instead trying to defend that idea. Why did anyone think Structured Programming wouldn't be? They must have had reasons to suspect it. I also don't know much of the history of Structured Programming apart from "Goto Considered Harmful", so pointers would be great.

I don't think those programmers, who claimed that structured code was insufficient, had thought about it in those terms. They were probably proud of their skills and the programs they wrote, and tried to defend it as the right way to do things, as it seemed obvious to them, from their experience, that it was.

There's no reason to write a 1500 line function in any language that supports functions as first class objects. Those lines could all be broken down and split into separate functions to give the parent function more semantic meaning.

I'll take John Carmack's practical advice over yours, especially since you appear to misusing the term "first-class function" to just mean function.

You don't need to create function calls just to add comments.


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact