6 ms·

The Beauty of Code

63 points by cobralibre 11y ago

Mithaldu 11y ago
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.
- wellpast 11y ago
  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.
  - jowiar 11y ago
    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.
- holri 11y ago
  Beautiful code looks like muesli. Small different distinct pieces swimming independent in a interconnecting milk in a big pot.
  - mhomde 11y ago
    the smaller the bowl* the more beautiful the code * up to a point
- stinos 11y ago
  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.
phatbyte 11y ago
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.
egfx 11y ago
relevant https://twitter.com/philsturgeon/status/425697220009410560 https://twitter.com/philsturgeon/status/425697220009410560
jcoffland 11y ago
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.
- brudgers 11y ago
  Vikram Chandra is a writer. https://en.m.wikipedia.org/wiki/Vikram_Chandra_(novelist) https://en.m.wikipedia.org/wiki/Vikram_Chandra_(novelist)
- woah 11y ago
  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.
  - stinos 11y ago
    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.
  - Too 11y ago
    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.
    - icebraining 11y ago
mhomde 11y ago
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.

63 points by cobralibre 11y ago

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.

wellpast 11y ago
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.
- jowiar 11y ago
  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.
holri 11y ago
Beautiful code looks like muesli. Small different distinct pieces swimming independent in a interconnecting milk in a big pot.
- mhomde 11y ago
  the smaller the bowl* the more beautiful the code * up to a point
stinos 11y ago
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.

phatbyte 11y ago

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.

egfx 11y ago

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

jcoffland 11y ago

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.

brudgers 11y ago
Vikram Chandra is a writer. https://en.m.wikipedia.org/wiki/Vikram_Chandra_(novelist) https://en.m.wikipedia.org/wiki/Vikram_Chandra_(novelist)
woah 11y ago
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.
- stinos 11y ago
  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.
- Too 11y ago
  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.
  - icebraining 11y ago

mhomde 11y ago

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.