SoylentNews is people
SoylentNews
Arthur T Knackerbracket has found the following story:
In March 2008, Paul Graham of Y Combinator wrote an essay called "How to Disagree." In the article he defines a hierarchy to gauge the quality of one's disagreement with another person's argument, a measure which ranges from name-calling at worst, to refutation of the central point at best.
I think a similar hierarchy can be defined to gauge the quality of architectural thinking and discourse of software engineers. I have noticed that most entry-level programmers focus their attention and criticisms on first-order issues such as code style, naming conventions, source code and repository layout, etc. They neglect or are unaware of higher-order concerns that can make a bigger impact on reducing the complexity of their systems. Even experienced programmers seem to suffer from this myopia.
If we're to build the systems of the future, I think we must set our sights above first-order issues. To afford the time to do so, we may need to reconsider, or even abandon, some concerns and practices that currently constitute much of what we call software engineering. Here I propose a hierarchy of concerns, ordered by the degree to which they reduce system complexity from lowest to highest.
I use the word "fixations" to denote those concerns that programmers often argue about which generate more heat than light. Some examples include code style, line length limits, repository layout, unit test coverage, avoidance of GOTO, and other "best practices," but this list is merely suggestive. Fixations are self-imposed constraints that prematurely restrict the set of possible implementations (set A) to a subset of implementations that are comfortable to the engineers who impose them (set B). Rarely, if ever, is it demonstrated that the set of optimal solutions (set C) is a subset of B.
Fixations are often adopted to solve problems that the team does not have, and may never have. There are cases where a GOTO is the perfect choice -- even Dijkstra admitted as much -- but many teams will flatly reject code that includes even one GOTO because "GOTO can make the code hard to read." Yes, we've all read Dijkstra's paper and understand the problems of excess GOTOs, but the question is not whether a tool used in excess causes problems, but rather whether the use of the tool in this particular case has in fact created a problem.
The worst thing about fixations is that they generate work that does nothing to reduce the complexity of the business problem. They become a continuing source of puzzles for engineers to solve. The complexity compounds when the satisfaction of one self-imposed constraint conflicts with that of another. For example, line-length limits often conflict with indentation rules, so programmers spend time searching for the least-ugly compromise. I have seen a mob programming group of 6 engineers spend 45 minutes fixing these exact problems to satisfy their linter. This is waste.
There are reasonable arguments to support the myriad views surrounding these kinds of concerns, but that's precisely the problem. If you can go either way on a particular issue, it can't matter that much. It would be a better use of time to not worry about it at all by increasing our fortitude toward trivialities. One heuristic we might use to recognize fixations is this: Before you offer a criticism in your next code review, ask yourself, "would I still be as concerned about this if the entire program fit on a half-page?" If the answer is "no", then use the energy you would expend on criticism to figure out how to make the program shorter.
[...] Looking back, we see that the hierarchy defined above moves from first-order, everyday programming concerns, to higher-order architectural concerns. Even more interesting, as we move up the hierarchy, aspects of the problem domain that were explicit at the lowest level become more and more implicit as we move up the hierarchy.
(Score: 1, Insightful) by Anonymous Coward on Saturday September 07 2019, @08:55PM (4 children)
Kind of hard to be afraid of goto if you first learned assembler. All those different jmp mnemonics are just jumps (absolute or conditional).
That's what your compiler ends up emitting, so it's much ado about nothing.
As for lint, I only worry about bellybutton, pocket, and dryer lint. And with advances in fabrics, I haven't seen bellybutton lint since at least the 90s.
I like that my programming style is significantly different that I can tell when someone else has changed something, or I can point out that I didn't write that section because it's not my style. Style let us catch one co-worker who was spending his time plagerizing code, would just check it out at the beginnong of the day, then check it back in with no changes. We could all tell the various workers he swiped code from at a glance once we started looking for it.
Mind you, in the future, humans probably won't be writing code at one point. Either our artifical intelligence progeny will be doing it (along with everything else), or we'll have destroyed all the infrastructure necessary for a technological society to function.
From our perspective, it's probably a loss either way. At least the folks with their noses buried in their phones on Facebook probably won't notice ...
(Score: -1, Offtopic) by Anonymous Coward on Saturday September 07 2019, @09:52PM
(Score: 1) by anubi on Saturday September 07 2019, @10:03PM
All too many times, GOTO has left me with the weirdest bugs in the stack.
If the language supports subroutines, a GOTO in the wrong place can net you a helluva lot of debuggin'.
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
(Score: 0, Troll) by Anonymous Coward on Saturday September 07 2019, @10:32PM (1 child)
You are as dumb/naive as the dumb piece's author. The GOTO was desecrated from the perspective of structured programming, where complex programs are built out of blocks and modules, where there is explicit entry/exit point so that we can better grasp how the whole thing flows. If anything, learning assembly ( which ever kinds of chips) would make you appreciate more why higher level languages discourage GOTOs.
(Score: 0) by Anonymous Coward on Sunday September 08 2019, @03:14AM
FALSE - Please learn your craft.
A "return" in middle of a code is just as bad.
A "goto end" is clear and better at documenting the intention.
Now a "goto X", where is X is not even in the code segment... that person should be "shot".
A "goto" and can keep code clean and structured, specially helpful is case and turning logic, but only if tuaght to use them correctly. Problem no one teaches the right use, just "Only fucking morons use them!".