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: 2) by bzipitidoo on Saturday September 07 2019, @11:32PM (9 children)
There is reason to focus on first order issues. Programming languages are still overly verbose and redundant, and that goes all the way down to the level of the notation, syntax, and even individual characters. For example, why are we constantly exhorted to use Proper indentation in languages that do not need it because they use curly braces? To both indent and use brackets is redundant. Most expert programming language designers are too high minded, too dismissive of this "trivial" problem. LISP is perhaps the best language for illustrating another first order problem: excessive parentheses. Lots of solutions have been proposed, but seems none have been adopted. And that's in part because experts dismiss that problem as trivial.
Picking on such rigid rules as line length limits and "no GOTOs" is beating up a strawman. As first order problems go, those are just stupid. They're not limitations of the programming languages, they're additional, imposed limitations. Proper Indentation is also self imposed, but at least that one doesn't force coders to make awkward compromises.
Experts want to focus on the tops of the structure, when the foundations are still unsettled. Certainly, the difference between a good algorithm and a bad one can outweigh all other considerations. But a cleaner programming language could do a lot to bring programming to more people. At the very least, a good, clean language could take away some of the trivial issues that incompetent programmers seize on to sow confusion, avoid facing the tough questions, and dodge the risk of being exposed as posers, frauds, and bandiers of IT lingo.
(Score: 2) by c0lo on Sunday September 08 2019, @12:10AM (1 child)
For the machine/compiler, yes.
Over the years, I had spent too many hours searching for a bug that I found in column numbers in over 150.
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 0) by Anonymous Coward on Sunday September 08 2019, @03:22AM
It is why prettyprint exists. force code on check-in thought a "standards keeper" to correct the error and the error is no more.
Been doing that since the early 80's. solved LONG AGO and FAR FAR AWAY. Biggest help was in setting up multi-lingual system. Found lots of constants directly en-code in the code. Externalize externalize externalize. Tehn all can be right.
(Score: 4, Interesting) by optotronic on Sunday September 08 2019, @01:50AM (5 children)
Think of it this way: the brackets tell the compiler where the block starts and ends, and the indent tells the humans looking at the code the same thing. While I could figure out where the blocks are without indenting, it would take a lot longer. I'm not convinced that's just because it's what I'm used to.
Sure, Python does away with brackets, but in my opinion it makes it too easy too make a block-leveling mistake. And copying/pasting code becomes much harder.
(Score: 1) by khallow on Sunday September 08 2019, @03:05AM
Even if this were truly somehow redundant, redundancy still has a huge role in computing. For example, error correcting codes deliberately introduce redundancy. Yet we consider them quite useful - because there are errors to correct (or at least notice). Similarly, here there are errors that can be caught and corrected because of attention to such details.
(Score: 0) by Anonymous Coward on Sunday September 08 2019, @05:48AM (1 child)
Python's problem is that it allows both tab and space for indentation, and when both get used, it gets messy not only visually but also for parsing. I try to pass the source through a filter that replaces all tabs with set number of spaces before editing.
(Score: 0) by Anonymous Coward on Sunday September 08 2019, @08:27AM
Specifically, Python's problem is that it allows *mixing* tabs and spaces. Using either/or is and has never been a problem except for the most petty-minded.
(Score: 0) by Anonymous Coward on Sunday September 08 2019, @08:30AM (1 child)
How does it make block-leveling mistakes easier, when it would change the operation of your code, so make their presence easier to spot?
You say that like it's a bad thing
(Score: 0) by Anonymous Coward on Sunday September 08 2019, @12:02PM
We live in an age where people copy code from web pages.
Think about that for a moment.
I do not voluntarily code in Python. It's my opinion that only a sadist could have come up with it.
This from an ex-COBOL developer should say something. Loudly.
(Score: 2) by hendrikboom on Sunday September 08 2019, @03:35AM
It's quite useful to get a compiler warning when the indentation conflicts with the brackets.
-- hendrik