The Beauty of Code | Hacker News Reader

The Beauty of Code

theparisreview.org

63 pointscobralibre17 comments

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.

Beautiful code looks like muesli. Small different distinct pieces swimming independent in a interconnecting milk in a big pot.

the smaller the bowl* the more beautiful the code

* up to a point

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.

This is specially true in the JS world.

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.

Vikram Chandra is a writer.

https://en.m.wikipedia.org/wiki/Vikram_Chandra_(novelist)

Git is pretty easy to learn, mostly you'll only ever use about 5 commands. There's the ninja voodoo stuff, but you can look the up on stack overflow.

Git is pretty easy to learn

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.

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.

Like when you commit to a detached head, change branch and loose one week of work.

Git doesn't lose your commits that easily; they're still there, you just need to find them: http://gitready.com/intermediate/2009/02/09/reflog-your-safe...

I know you don't loose the commits but the initial feeling is that you do. My point was that to get them back you must use the ninja voodo tricks.

> 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.

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.

Clarity of writing follows clarity of thought.

relevant https://twitter.com/philsturgeon/status/425697220009410560

Reply on news.ycombinator.com