{"id":76365,"date":"2014-09-05T17:12:53","date_gmt":"2014-09-05T21:12:53","guid":{"rendered":"https:\/\/www.theparisreview.org\/blog\/?p=76365"},"modified":"2014-09-05T20:10:26","modified_gmt":"2014-09-06T00:10:26","slug":"the-beauty-of-code","status":"publish","type":"post","link":"https:\/\/www.theparisreview.org\/blog\/2014\/09\/05\/the-beauty-of-code\/","title":{"rendered":"The Beauty of Code"},"content":{"rendered":"
\"1\"<\/a>

Dependency diagram (Image via TheDailyWTF)<\/p><\/div>\n

This is what ugly code looks like. This is a dependency diagram\u2014a graphic representation of interdependence or coupling (the black lines) between software components (the gray dots) within a program. A high degree of interdependence means that changing one component inside the program could lead to cascading changes in all the other connected components, and in turn to changes in their dependencies, and so on. Programs with this kind of structure are brittle, and hard to understand and fix. This dependency program was submitted anonymously to TheDailyWTF.com, where working programmers share \u201cCurious Perversions in Information Technology\u201d as they work. The exhibits at TheDailyWTF are often embodiments of stupidity, of miasmic dumbness perpetrated by the squadrons of sub-Mort programmers putting together the software that runs businesses across the globe. But, as often, high-flying \u201centerprise architects\u201d and consultants put together systems that produce dependency diagrams that look like this renowned TheDailyWTF exhibit. A user commented, \u201cI found something just like that blocking the drain once.\u201d<\/p>\n

If that knot of tangled hair provokes disgust, what kind of code garners admiration? In the anthology Beautiful Code<\/em>, the contribution from the creator of the popular programming language Ruby, Yukihiro \u201cMatz\u201d Matsumoto, is an essay titled \u201cTreating Code as an Essay.\u201d Matz writes:<\/p>\n

\n

Judging the attributes of computer code is not simply a matter of aesthetics. Instead, computer programs are judged according to how well they execute their intended tasks. In other words, \u201cbeautiful code\u201d is not an abstract virtue that exists independent of its programmers\u2019 efforts. Rather, beautiful code is really meant to help the programmer be happy and productive. This is the metric I use to evaluate the beauty of a program.<\/p>\n<\/blockquote>\n

He goes on to list the virtues of good code: brevity; reusability (\u201cnever write the same thing twice\u201d); familiarity (Ruby is an \u201cextremely conservative programming language\u201d that does not use \u201cinnovative control structures\u201d but \u201csticks to traditional control structures programmers are familiar with\u201d); simplicity; flexibility (which Matz defines as \u201cfreedom from enforcement of tools,\u201d so programmers aren\u2019t forced to work in a certain way by the tools or languages they use); and, finally, balance: \u201cNo element by itself will ensure a beautiful program. When balanced together and kept in mind from the very beginning, each element will work harmoniously with the others to create beautiful code.\u201d<\/p>\n

So, beautiful code is lucid, it is easy to read and understand; its organization, its shape, its architecture reveals intent as much as its declarative syntax does. Each small part is coherent, singular in its purpose, and although all these small sections fit together like the pieces of a complex mosaic, they come apart easily when one element needs to be changed or replaced. All this leads to the happiness of the programmer, who must understand it, change it, extend it. This longing for architectural coherence leads to comparisons of code with music, which is often described as the most mathematical of the arts. There is, in fact, an anecdotal but fairly generalized belief among American programmers that there is a high correlation between coding and music-making, that many coders are musicians. A similar claim is made about mathematicians and music. These connections seem culturally encoded to me, specific to America\u2014I\u2019ve never heard of Indian programmers or mathematicians having a special affinity for music, apart from some being passionate listeners. Still, the code-and-music analogy is illuminating in that both practices prize harmonious pattern-making and abhor cacophony, a loss of clarity and structure. The snarl in the dependency diagram above may strike the civilian as a pretty picture, with its swirl of lines and punctuating sparks of gray; to the programmer, it is an abomination because it speaks of incoherence, incomprehensibility, unpredictability, sticky seams of connection that prevent swift diagnosis and make excision and replacement all but impossible.<\/p>\n

With his emphasis on programmer happiness, Matz makes explicit his allegiance to Donald Knuth\u2019s literate programming. He writes:<\/p>\n

\n

Programs share some attributes with essays. For essays, the most important question readers ask is, \u201cWhat is it about?\u201d For programs, the main question is, \u201cWhat does it do?\u201d In fact, the purpose should be sufficiently clear that neither question ever needs to be uttered \u2026 Both essays and lines of code are meant\u2014before all else\u2014to be read and understood by human beings.<\/p>\n<\/blockquote>\n

The trouble of course is that as software programs grow bigger and more complex, the code they comprise tends to become unreadable and incomprehensible to human beings. Programmers like to point out that if each line of code, or even each logical statement (which may spread to more than one physical line), is understood to be a component, software systems are the most complicated things that humans have ever built: the Lucent 5ESS switch, used in telephone exchanges, derives its functionality from a hundred million lines of code; the 2008 Fedora 9 distribution of Linux comprises over two hundred million lines of code. No temple, no cathedral has ever contained as many moving parts. So if you\u2019ve ever written code, you understand in your bones the truth of Donald Knuth\u2019s assertion, \u201cSoftware is hard. It\u2019s harder than anything else I\u2019ve ever had to do.\u201d If you\u2019ve ever written code, the fact that so much software works so much of the time can seem profoundly miraculous.<\/p>\n

* * *<\/p>\n

The International Obfuscated C Code Contest annually awards recognition to the writer of \u201cthe most Obscure\/Obfuscated C program\u201d\u2014 that is, to the person who can produce the most incomprehensible working code in the language C. The stated pedagogical aim of the contest is \u201cto show the importance of programming style, in an ironic way.\u201d But it has always seemed to me that confronting unfathomable code is the programming equivalent of staring at the abject, of slowing down to peer into the carnage of a car wreck. This is the reason that programmers expend time and effort in designing esoteric, purposely difficult computer languages like the infamous \u201cbrainfuck\u201d\u2014that really is its official name, with the lowercase b<\/em>\u2014which was created as an exercise in writing the smallest possible compiler (240 bytes) that could run on the Amiga operating system. \u201cHello, world!\u201d in brainfuck is:<\/p>\n

\n

++++++++++[>+++++++>++++++++++>+++<<<-]>++.>+.+++++++ ..+++.>++.<<+++++++++++++++.>.+++.——.——–.>+.<\/p>\n<\/blockquote>\n

Brainfuck is a \u201cTuring tarpit,\u201d which is to say it is a very small language in which you can write any program that you could write in C or Java; but attempting to do so would, well, fuck your brain, and therefore the delectable frisson of terror the code above induces in discerning code cognoscenti. brainfuck is venerable and famous, but my favorite esoteric language is Malbolge, which was designed solely to be the most outrageously difficult language to program in. It is named, appropriately, after the eighth circle of hell in Dante\u2019s Inferno, Malebolge (\u201cEvil ditches,\u201d reserved for frauds). In the language Malbolge, the result of any instruction depends on where it is located in memory, which effectively means that what specific code does changes with every run. Code and data are very hard to reuse, and the constructs to control program flow are almost nonexistent. Malbolge inverts the sacred commandments of literate programming, and is so impenetrable that it took two years after the language was first released for the first working program to appear, and that program was not written by a human, but generated by a computerized search program that examined the space of all possible Malbolge programs and winnowed out one possibility. \u201cHello, world!\u201d in Malbolge is:<\/p>\n

\n

(=<`$9]7<5YXz7wT.3,+O\/o’K%$H”‘~D|#z@b=`{^Lx8%$Xmrkpohm- kNi;gsedcba`_^]\\[ZYXWVUTSRQPONMLKJIHGFEDCBA@?>=<;:9876543s+O<oLm<\/p>\n<\/blockquote>\n

And yet, this snippet doesn\u2019t convey the true, titillating evil of Malbolge, which changes and quakes like quicksand. To contemplate Malbolge is to stare into the abyss in which machines speak their own tongues, indifferent to the human gaze; the programmer thereafter knows the pathos of her situation, and recognizes the costs of sacrilege. The coder\u2019s quest is for functionality\u2014\u201call computer programs are designed to accomplish some kind of task\u201d\u2014and the extension and maintenance of that functionality demands clarity and legibility. Illegibility, incomprehensibility\u2014that way madness lies.<\/p>\n

* * *<\/p>\n

Programmers work doggedly toward correctness, but the sheer size and complexity of software ensures that bugs lurk within. A bug is, of course, a flaw or fault in a program that produces unexpected results. In 1986, the award-winning researcher and academic Jon Bentley published a book that is now widely regarded as a classic, Programming Pearls<\/em>. One of the algorithms he implemented was for binary search, a method of finding a value in a sorted array, which was first published in 1946. In 2006, decades after the publication of Bentley\u2019s book\u2014by which time his particular implementation had been copied and used many thousands of times\u2014one of his erstwhile students, Joshua Bloch, discovered that under certain conditions this technique could manifest a bug.\u00a0Bloch published his finding under a justly panic-raising headline, \u201cExtra, Extra\u2014Read All About It: Nearly All Binary Searches and Mergesorts are Broken.\u201d He wrote:<\/p>\n

\n

The general lesson that I take away from this bug is humility: It is hard to write even the smallest piece of code correctly, and our whole world runs on big, complex pieces of code.<\/p>\n

Careful design is great. Testing is great. Formal methods are great. Code reviews are great. Static analysis is great. But none of these things alone are sufficient to eliminate bugs: They will always be with us. A bug can exist for half a century despite our best efforts to exterminate it.<\/p>\n<\/blockquote>\n

That software algorithms are now running our whole world means that software faults or errors can send us down the wrong highway, injure or kill people, and cause disasters. Every programmer is familiar with the most infamous bugs: the French Ariane 5 rocket that went off course and self-destructed forty seconds after liftoff because of an error in converting between representations of number values; the Therac-25 radiation therapy machine that reacted to a combination of operator input and a \u201ccounter overflow by delivering doses of radiation a hundred times more intense than required, resulting in the agonizing deaths of five people and injuries to many others; the \u201cFlash Crash\u201d of 2010, when the Dow Jones suddenly plunged a thousand points and recovered just as suddenly, apparently as a result of automatic trading programs reacting to a single large trade.<\/p>\n

These are the notorious bugs, but there are bugs in every piece of software that you use today. A professional \u201ccyber warrior,\u201d whose job it is to find and exploit bugs for the U.S. government, recently estimated that \u201cmost of the software written in the world has a bug every three to five lines of code.\u201d These bugs may not kill you, but they cause your system to freeze, they corrupt your data, and they expose your computers to hackers. The next great hope for more stable, bug-free software is functional programming, which is actually the oldest paradigm in computing\u2014it uses the algebraic techniques of function evaluation used by the creators of the first computers. In functional programming, all computation is expressed as the evaluation of expressions; the radical simplicity of thinking about programming as only giving input to functions that produce outputs promotes legibility and predictability. There is again the same fervent proselytizing about functional programming that I remember from the early days of object-oriented programming, the same conviction that this time we\u2019ve discovered the magic key to the kingdom. Functional languages like Clojure conjure up the clean symmetries of mathematics, and hold forth the promise of escape from all the jugaadu<\/em> work-arounds that turn so much code into a gunky, biological-seeming mess. In general, though, programmers are now skeptical of the notion that there\u2019s any silver bullet for complexity. The programmer and popular blogger Steve Yegge, in his foreword to a book called The Joy of Clojure<\/em>, describes the language as a \u201cminor miracle\u201d and \u201can astoundingly high-quality language \u2026 the best I\u2019ve ever seen,\u201d but he also notes that it is \u201cfashionable,\u201d and that<\/p>\n

\n

our industry, the global programming community, is fashion-driven to a degree that would embarrass haute couture designers from New York to Paris … Fashion dictates the programming languages people study in school, the languages employers hire for, the languages that get to be in books on shelves. A naive outsider might wonder if the quality of a language matters a little, just a teeny bit at least, but in the real world fashion trumps all.<\/p>\n<\/blockquote>\n

In respect to programming languages and techniques, the programming industry has now been through many cycles of faith and disillusionment, and many of its members have acquired a sharp, necessary cynicism. \u201cHype Cycle\u201d\u2014a phrase coined by the analysts at Gartner, Inc.\u2014adroitly captures the up-and-down fortunes of many a tech fad.<\/p>\n

\"10\"<\/a>

Gartner, Inc.\u2019s Hype Cycle (Jeremy Kemp, via Wikimedia Commons)<\/p><\/div>\n

The tools and processes used to manage all this complexity engender another layer of complexity. All but the simplest programs must be written by teams of programmers, each working on a small portion of the system. Of course these people must be managed, housed, provided with equipment, but also their product\u2014the code itself\u2014must be distributed, shared, saved from overwriting or deletion, integrated, and tested.<\/p>\n

Entire industries have grown around these necessities. Software tools for building software\u2014particularly Integrated Development Environments, applications used to write applications\u2014are some of the most complex programs being built today. They make the programmer\u2019s job easier, but the programmer must learn how to use them, must educate herself in their idiosyncrasies and the work-arounds for their faults. This is not a trivial task. For example, every programmer needs to use a revision control system to track changes and easily branch and merge versions of code. The best-regarded revision control system today is Git, created by Linus Torvalds (and named, incidentally, after his famous cantankerousness). Git\u2019s interface is command-line driven and famously UNIX-y and complex, and for the newbie its inner workings are mysterious. In response to a blog post titled \u201cGit Is Simpler Than You Think,\u201d an irritated Reddit commenter remarked, \u201cYes, also a nuclear submarine is simpler than you think \u2026 once you learn how it works.\u201d I made three separate attempts to learn how Git worked myself, gave up, was frustrated enough by other revision control systems to return, and finally had to read a 265-page book to acquire enough competence to use the thing. Git is immensely powerful and nimble, and I enjoy using it, but maneuvering it felt\u2014at least initially\u2014like a life achievement of sorts.<\/p>\n

You may have to use a dozen tools and websites to handle the various logistical aspects of software development, and soon the triumph starts to wear a little thin. Add another dozen software libraries and frameworks that you may use internally in your programs\u2014again, each one comes bristling with its own eccentricities, bugs, and books\u2014and weariness sets in. Each tool and preconstructed library solves a problem that you must otherwise solve yourself, but each solution is a separate body of knowledge you must maintain. A user named jdietrich wrote in a discussion on Hacker News:<\/p>\n

\n

My biggest gripe with modern programming is the sheer volume of arbitrary stuff I need to know. My current project has so far required me to know about Python, Django, Google App Engine and its datastore, XHTML, CSS, JQuery, Javascript, JSON, and a clutch of XML schema, APIs and the like \u2026<\/p>\n

Back in ye olden days, most programming tasks I performed felt quite natural and painless, just a quiet little chat between me and the compiler. Sometimes longwinded, sometimes repetitive, but I just sat and thought and typed and software happened. The work I do these days feels more like being a dogsbody at the tower of babel. I just don\u2019t seem to feel fluent in anything much any more.<\/p>\n<\/blockquote>\n

And every year, the new technologies arrive in a cloud of acronyms and cute names: MongoDB, HTML5, PaaS, CoffeeScript, TPL, Rx. One must keep up. On programmers.stackexchange.com, one hapless coder wrote:<\/p>\n

\n

I was humbled at a job interview yesterday almost to the point of a beat-down and realized that although I know what I know, my skills are pretty old and I\u2019m getting to where I don\u2019t know what I don\u2019t know, which for a tech guy is a bad thing.<\/p>\n

I don\u2019t know if I can keep current just doing my day to day job, so I need to make sure I at least know what\u2019s out there.<\/p>\n

Are there well known blogs I should be keeping up with for software development?<\/p>\n<\/blockquote>\n

\"51O+fvG3zBL._SY344_BO1,204,203,200_\"<\/a>The best\u2014or at least the most ambitious\u2014programmers read blogs and books, attend conferences to keep up with the state of the art, learn a new language every year or two. When you begin programming, one of the attractions is the certainty that you will never run out of things to learn. But after a few years of working in a corporate cubicle under exploitive managers, after one deadline too many, after family and age and a tiring body, learning the ins and outs of the latest library can feel like another desperate sprint on a nonstop treadmill. There is a reigning cult of overwork in the industry\u2014the legend of the rock-star programmer usually has him coding sixteen hours a day, while simultaneously contributing to open-source projects, blogging, conferencing, and somehow managing to run a start-up\u2014and this ideal has led many an aspirant to burn out, complete with techie thousand-yard-stare, clinical depression, outbursts of anger, and total disinterest in programming. This trough of disillusionment is so deep that for many, the only way to emerge from it is to leave the industry altogether, which rewards a few with fame and dazzling amounts of money, but treats the many as disposable cogs in its software production machine. The endless cycle of idea and action, endless invention, endless experiment, all this knowledge of motion takes its toll, leaves behind a trail of casualties.<\/p>\n

This essay is an excerpt from\u00a0<\/em>Geek Sublime: The Beauty of Code, the Code of Beauty<\/a>,\u00a0 \u00a9 2014 Vikram Chandra. Reprinted with the permission of Graywolf Press.<\/em><\/p>\n

Vikram Chandra is the author of three highly acclaimed works of fiction, most recently <\/em>Sacred Games, which won the Hutch Crossword Award for Fiction in 2006. Chandra lives in Oakland and teaches at the University of California, Berkeley.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

This is what ugly code looks like. This is a dependency diagram\u2014a graphic representation of interdependence or coupling (the black lines) between software components (the gray dots) within a program. A high degree of interdependence means that changing one component inside the program could lead to cascading changes in all the other connected components, and […]<\/p>\n","protected":false},"author":745,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[684],"tags":[15208,15205,15202,15207,15206,15204,687,15203,224],"class_list":["post-76365","post","type-post","status-publish","format-standard","hentry","category-on-language","tag-beautiful-code","tag-brainfuck","tag-coding","tag-dependency-diagram","tag-donald-knuth","tag-git","tag-language","tag-programming","tag-technology"],"acf":[],"yoast_head":"\nThe Beauty of Code<\/title>\n<meta name=\"description\" content=\"An excerpt from Vikram Chandra\u2019s \u201cGeek Sublime: The Beauty of Code, the Code of Beauty.\u201d\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.theparisreview.org\/blog\/2014\/09\/05\/the-beauty-of-code\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"The Beauty of Code by Vikram Chandra\" \/>\n<meta property=\"og:description\" content=\"September 5, 2014 \u2013 This is what ugly code looks like. This is a dependency diagram\u2014a graphic representation of interdependence or coupling (the black lines) between software\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.theparisreview.org\/blog\/2014\/09\/05\/the-beauty-of-code\/\" \/>\n<meta property=\"og:site_name\" content=\"The Paris Review\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/parisreview\/\" \/>\n<meta property=\"article:published_time\" content=\"2014-09-05T21:12:53+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2014-09-06T00:10:26+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.theparisreview.org\/blog\/wp-content\/uploads\/2014\/09\/1.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"1149\" \/>\n\t<meta property=\"og:image:height\" content=\"647\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"Vikram Chandra\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@parisreview\" \/>\n<meta name=\"twitter:site\" content=\"@parisreview\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Vikram Chandra\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"16 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/www.theparisreview.org\/blog\/2014\/09\/05\/the-beauty-of-code\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.theparisreview.org\/blog\/2014\/09\/05\/the-beauty-of-code\/\"},\"author\":{\"name\":\"Vikram Chandra\",\"@id\":\"https:\/\/www.theparisreview.org\/blog\/#\/schema\/person\/ea9b45866a0cfa99483ec0aa9c3cac4f\"},\"headline\":\"The Beauty of Code\",\"datePublished\":\"2014-09-05T21:12:53+00:00\",\"dateModified\":\"2014-09-06T00:10:26+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.theparisreview.org\/blog\/2014\/09\/05\/the-beauty-of-code\/\"},\"wordCount\":3116,\"commentCount\":20,\"publisher\":{\"@id\":\"https:\/\/www.theparisreview.org\/blog\/#organization\"},\"image\":{\"@id\":\"https:\/\/www.theparisreview.org\/blog\/2014\/09\/05\/the-beauty-of-code\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.theparisreview.org\/blog\/wp-content\/uploads\/2014\/09\/1.jpg\",\"keywords\":[\"beautiful code\",\"brainfuck\",\"coding\",\"dependency diagram\",\"Donald Knuth\",\"Git\",\"language\",\"programming\",\"technology\"],\"articleSection\":[\"On Language\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.theparisreview.org\/blog\/2014\/09\/05\/the-beauty-of-code\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.theparisreview.org\/blog\/2014\/09\/05\/the-beauty-of-code\/\",\"url\":\"https:\/\/www.theparisreview.org\/blog\/2014\/09\/05\/the-beauty-of-code\/\",\"name\":\"The Beauty of Code\",\"isPartOf\":{\"@id\":\"https:\/\/www.theparisreview.org\/blog\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/www.theparisreview.org\/blog\/2014\/09\/05\/the-beauty-of-code\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/www.theparisreview.org\/blog\/2014\/09\/05\/the-beauty-of-code\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.theparisreview.org\/blog\/wp-content\/uploads\/2014\/09\/1.jpg\",\"datePublished\":\"2014-09-05T21:12:53+00:00\",\"dateModified\":\"2014-09-06T00:10:26+00:00\",\"description\":\"An excerpt from Vikram Chandra\u2019s \u201cGeek Sublime: The Beauty of Code, the Code of Beauty.\u201d\",\"breadcrumb\":{\"@id\":\"https:\/\/www.theparisreview.org\/blog\/2014\/09\/05\/the-beauty-of-code\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.theparisreview.org\/blog\/2014\/09\/05\/the-beauty-of-code\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.theparisreview.org\/blog\/2014\/09\/05\/the-beauty-of-code\/#primaryimage\",\"url\":\"https:\/\/www.theparisreview.org\/blog\/wp-content\/uploads\/2014\/09\/1.jpg\",\"contentUrl\":\"https:\/\/www.theparisreview.org\/blog\/wp-content\/uploads\/2014\/09\/1.jpg\"},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.theparisreview.org\/blog\/2014\/09\/05\/the-beauty-of-code\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/www.theparisreview.org\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"The Beauty of Code\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.theparisreview.org\/blog\/#website\",\"url\":\"https:\/\/www.theparisreview.org\/blog\/\",\"name\":\"The Paris Review\",\"description\":\"The best prose, interviews, poetry, and art. Since 1953.\",\"publisher\":{\"@id\":\"https:\/\/www.theparisreview.org\/blog\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/www.theparisreview.org\/blog\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/www.theparisreview.org\/blog\/#organization\",\"name\":\"The Paris Review\",\"url\":\"https:\/\/www.theparisreview.org\/blog\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.theparisreview.org\/blog\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/www.theparisreview.org\/blog\/wp-content\/uploads\/2025\/04\/tpr-hadada-roundell-logo-square.png\",\"contentUrl\":\"https:\/\/www.theparisreview.org\/blog\/wp-content\/uploads\/2025\/04\/tpr-hadada-roundell-logo-square.png\",\"width\":696,\"height\":696,\"caption\":\"The Paris Review\"},\"image\":{\"@id\":\"https:\/\/www.theparisreview.org\/blog\/#\/schema\/logo\/image\/\"},\"sameAs\":[\"https:\/\/www.facebook.com\/parisreview\/\",\"https:\/\/x.com\/parisreview\",\"https:\/\/www.instagram.com\/parisreview\"]},{\"@type\":\"Person\",\"@id\":\"https:\/\/www.theparisreview.org\/blog\/#\/schema\/person\/ea9b45866a0cfa99483ec0aa9c3cac4f\",\"name\":\"Vikram Chandra\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.theparisreview.org\/blog\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/6d54bf227b323cd4ba8e77b9f304c2f7136273cd0f9410bf150c43dbe88413e7?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/6d54bf227b323cd4ba8e77b9f304c2f7136273cd0f9410bf150c43dbe88413e7?s=96&d=mm&r=g\",\"caption\":\"Vikram Chandra\"},\"url\":\"https:\/\/www.theparisreview.org\/blog\/author\/vchandra\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"The Beauty of Code","description":"An excerpt from Vikram Chandra\u2019s \u201cGeek Sublime: The Beauty of Code, the Code of Beauty.\u201d","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.theparisreview.org\/blog\/2014\/09\/05\/the-beauty-of-code\/","og_locale":"en_US","og_type":"article","og_title":"The Beauty of Code by Vikram Chandra","og_description":"September 5, 2014 \u2013 This is what ugly code looks like. This is a dependency diagram\u2014a graphic representation of interdependence or coupling (the black lines) between software","og_url":"https:\/\/www.theparisreview.org\/blog\/2014\/09\/05\/the-beauty-of-code\/","og_site_name":"The Paris Review","article_publisher":"https:\/\/www.facebook.com\/parisreview\/","article_published_time":"2014-09-05T21:12:53+00:00","article_modified_time":"2014-09-06T00:10:26+00:00","og_image":[{"width":1149,"height":647,"url":"https:\/\/www.theparisreview.org\/blog\/wp-content\/uploads\/2014\/09\/1.jpg","type":"image\/jpeg"}],"author":"Vikram Chandra","twitter_card":"summary_large_image","twitter_creator":"@parisreview","twitter_site":"@parisreview","twitter_misc":{"Written by":"Vikram Chandra","Est. reading time":"16 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.theparisreview.org\/blog\/2014\/09\/05\/the-beauty-of-code\/#article","isPartOf":{"@id":"https:\/\/www.theparisreview.org\/blog\/2014\/09\/05\/the-beauty-of-code\/"},"author":{"name":"Vikram Chandra","@id":"https:\/\/www.theparisreview.org\/blog\/#\/schema\/person\/ea9b45866a0cfa99483ec0aa9c3cac4f"},"headline":"The Beauty of Code","datePublished":"2014-09-05T21:12:53+00:00","dateModified":"2014-09-06T00:10:26+00:00","mainEntityOfPage":{"@id":"https:\/\/www.theparisreview.org\/blog\/2014\/09\/05\/the-beauty-of-code\/"},"wordCount":3116,"commentCount":20,"publisher":{"@id":"https:\/\/www.theparisreview.org\/blog\/#organization"},"image":{"@id":"https:\/\/www.theparisreview.org\/blog\/2014\/09\/05\/the-beauty-of-code\/#primaryimage"},"thumbnailUrl":"https:\/\/www.theparisreview.org\/blog\/wp-content\/uploads\/2014\/09\/1.jpg","keywords":["beautiful code","brainfuck","coding","dependency diagram","Donald Knuth","Git","language","programming","technology"],"articleSection":["On Language"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.theparisreview.org\/blog\/2014\/09\/05\/the-beauty-of-code\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.theparisreview.org\/blog\/2014\/09\/05\/the-beauty-of-code\/","url":"https:\/\/www.theparisreview.org\/blog\/2014\/09\/05\/the-beauty-of-code\/","name":"The Beauty of Code","isPartOf":{"@id":"https:\/\/www.theparisreview.org\/blog\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.theparisreview.org\/blog\/2014\/09\/05\/the-beauty-of-code\/#primaryimage"},"image":{"@id":"https:\/\/www.theparisreview.org\/blog\/2014\/09\/05\/the-beauty-of-code\/#primaryimage"},"thumbnailUrl":"https:\/\/www.theparisreview.org\/blog\/wp-content\/uploads\/2014\/09\/1.jpg","datePublished":"2014-09-05T21:12:53+00:00","dateModified":"2014-09-06T00:10:26+00:00","description":"An excerpt from Vikram Chandra\u2019s \u201cGeek Sublime: The Beauty of Code, the Code of Beauty.\u201d","breadcrumb":{"@id":"https:\/\/www.theparisreview.org\/blog\/2014\/09\/05\/the-beauty-of-code\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.theparisreview.org\/blog\/2014\/09\/05\/the-beauty-of-code\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.theparisreview.org\/blog\/2014\/09\/05\/the-beauty-of-code\/#primaryimage","url":"https:\/\/www.theparisreview.org\/blog\/wp-content\/uploads\/2014\/09\/1.jpg","contentUrl":"https:\/\/www.theparisreview.org\/blog\/wp-content\/uploads\/2014\/09\/1.jpg"},{"@type":"BreadcrumbList","@id":"https:\/\/www.theparisreview.org\/blog\/2014\/09\/05\/the-beauty-of-code\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.theparisreview.org\/blog\/"},{"@type":"ListItem","position":2,"name":"The Beauty of Code"}]},{"@type":"WebSite","@id":"https:\/\/www.theparisreview.org\/blog\/#website","url":"https:\/\/www.theparisreview.org\/blog\/","name":"The Paris Review","description":"The best prose, interviews, poetry, and art. Since 1953.","publisher":{"@id":"https:\/\/www.theparisreview.org\/blog\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.theparisreview.org\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/www.theparisreview.org\/blog\/#organization","name":"The Paris Review","url":"https:\/\/www.theparisreview.org\/blog\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.theparisreview.org\/blog\/#\/schema\/logo\/image\/","url":"https:\/\/www.theparisreview.org\/blog\/wp-content\/uploads\/2025\/04\/tpr-hadada-roundell-logo-square.png","contentUrl":"https:\/\/www.theparisreview.org\/blog\/wp-content\/uploads\/2025\/04\/tpr-hadada-roundell-logo-square.png","width":696,"height":696,"caption":"The Paris Review"},"image":{"@id":"https:\/\/www.theparisreview.org\/blog\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/www.facebook.com\/parisreview\/","https:\/\/x.com\/parisreview","https:\/\/www.instagram.com\/parisreview"]},{"@type":"Person","@id":"https:\/\/www.theparisreview.org\/blog\/#\/schema\/person\/ea9b45866a0cfa99483ec0aa9c3cac4f","name":"Vikram Chandra","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.theparisreview.org\/blog\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/6d54bf227b323cd4ba8e77b9f304c2f7136273cd0f9410bf150c43dbe88413e7?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/6d54bf227b323cd4ba8e77b9f304c2f7136273cd0f9410bf150c43dbe88413e7?s=96&d=mm&r=g","caption":"Vikram Chandra"},"url":"https:\/\/www.theparisreview.org\/blog\/author\/vchandra\/"}]}},"_links":{"self":[{"href":"https:\/\/www.theparisreview.org\/blog\/wp-json\/wp\/v2\/posts\/76365","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.theparisreview.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.theparisreview.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.theparisreview.org\/blog\/wp-json\/wp\/v2\/users\/745"}],"replies":[{"embeddable":true,"href":"https:\/\/www.theparisreview.org\/blog\/wp-json\/wp\/v2\/comments?post=76365"}],"version-history":[{"count":11,"href":"https:\/\/www.theparisreview.org\/blog\/wp-json\/wp\/v2\/posts\/76365\/revisions"}],"predecessor-version":[{"id":76392,"href":"https:\/\/www.theparisreview.org\/blog\/wp-json\/wp\/v2\/posts\/76365\/revisions\/76392"}],"wp:attachment":[{"href":"https:\/\/www.theparisreview.org\/blog\/wp-json\/wp\/v2\/media?parent=76365"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.theparisreview.org\/blog\/wp-json\/wp\/v2\/categories?post=76365"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.theparisreview.org\/blog\/wp-json\/wp\/v2\/tags?post=76365"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}