I'm very disappointed that he starts out with a diagram and "This is what ugly code looks like.", but doesn't follow it up with "This is what beautiful code looks like."
Then again, maybe that part's just in the book this excerpt is trying to sell.
Beautiful code looks like a directed, acyclic graph -- a tree with small nodes (high cohesion) and minimal dependencies (low coupling). Narrow interfaces are the last piece, but I'm not sure how you visualize that -- perhaps with the width of the edges; the narrower, the more beautiful.
Of course, "beauty" is a hard sell. What you really get with maintaining code with these "beautiful" qualities is massive productivity and choice.
Drawn as a graph, it ends up minimizing:
- Node size (think small functions and objects, not big ones)
- Degree (minimize dependencies. Also, an O(m+n) many-to-few-to-many is probably easier to reason about than an O(mn) many-to-many),
- Overall number of nodes (DRY, also, less code is generally better than more code).
Of course, the prioritization between these three is up in the air.
Came here to post the exact same thing. Was expecting to see a diagram of beautiful code after every scroll, but no avail.
Also: what does HN recommend for creating such a diagram for my code (say C# and C++ codebases)?
Not that I'm sure it is really an ok measure: I'm a heavy adept of DIY and have a ton of small utility functions which are used all over the place (mainly missing pieces in the STL). This should lead to a whole lot of extra lines in a diagram which might look like spaghetti as well.
I enjoyed reading this article. Especially at the end. A 2015 programmers is a much different beast of a 1990 programmer.
Not better or worst, but because of how fast things move this days we must be "eclectic" regarding out tools, and shape-shifters from new frameworks that pop-out every week.
The author is of course absolutly correct in every respect but I can't help thinking that he's is one of those devs who struggles terribly with programming. This type tends to give up eventually. Sometimes after years of work. His struggle to learn git is telling. Sure git is complex but it's not quite that hard for many of us. This leads to bewildered frustration with programming and a general distrust of all programs.
> This leads to bewildered frustration with programming and a general distrust of all programs.
I think this is perhaps a more honest attitude to the state of programming today than those of us who have managed to master it are willing to permit ourselves. We suffer from the sunk cost fallacy: we are tempted to imagine that the complexity we have mastered is necessary, because if it were not, then we would feel our time spent learning it had been wasted.
The problem is that everyone will need the ninja voodo stuff eventually, most often during the learning phase of git when you easily hit some of the land mines and have to revert. Like when you commit to a detached head, change branch and loose one week of work. After we switched to git at work every single one of us, without exception, did this kind of mistake at least once the first month. Aborting "rebase in progress" isn't exactly easy either if something went wrong during the merge.
No generalizing please, this is not true everyone, maybe not even for a majority of it's users. I know enough people which after having used it for months still do not really grasp it. Sure, they can sort of get around with the 5 commands they need, but anything slightly beyond that and they are lost.
Interesting article... but maybe the author should have taken a cue from programming and refactored/edited it to be more clear, concise and structured.
I found it a bit rambling without clear premise or pay off. He sounds like someone who talks about programming from the outside while never having been deeply immersed in it himself.
Then again, maybe that part's just in the book this excerpt is trying to sell.