Author
Topic: Is Beautiful Code A Succubus (Read 7456 times)

I purchased the book Beautiful Code the other day and it sits on my read-when-you-want-to-read-about-code-instead-of-coding-and-not-feel-guilty stack. Jon Udell pointed me to an interesting blog article on rejecting the notion.

Quote from: Jonathan Edwards

{ 2007 08 02 }Beautiful Code

O’Reilly just published Beautiful Code. I was invited to contribute, but I just could not go along with the premise. I disagree that beauty is a guiding principle of programming. Here is how I responded.

Ah but doesn't it all depend on your idea of what beautiful code really is

For me beautiful code is the small chunks of self contained code that do something simple, but do it very well. Of course what I consider beautiful today could look very ugly tomorrow, but that's ok, beauty is never stationary- not in life and not code.

Well, the first thing you must do to write beautiful code is to make it readable. That is, take advantage of tabs and indenting, separate code sections like loops from other more mundane, like definitions or repetitive single-line orders... I've been messing with lots of code that essentially looked like a text brick, including that wrote by teachers. And then, starting with that you extrapolate, breaking everything into independent chunks of code, that are easy to understand by themselves, using properly named variables, constants, functions and all the usual suspects... Maybe you don't get beautiful code (I think the concepts clash a bit) but at least you'll get something attractive and easy to read and understand for other people, including yourself.

I'm not sure the article really disagrees with the notion as it suggests it does. Seems to me he's really saying that you can't expect not to get your hands dirty when you work in the real world. Fair enough, but I do believe that striving for elegant/beautiful code is an important principle in coding. If it looks ugly, chances are very good that you are doing something in a way you know could be improved.

This quote comes to mind:"When I am working on a problem I never think about beauty. I only think about how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -- Buckminster Fuller

Chapter 9, Top-Down Operator Precedence, by Douglas Crockford, revives an almost forgotten parsing technique and shows its new relevance to the popular JavaScript language.

Chapter 10, The Quest for an Accelerated Population Count, by Henry S. Warren, Jr., reveals the impact that some clever algorithms can have on even a seemingly simple problem.

Chapter 11, Secure Communication: The Technology of Freedom, by Ashish Gulhati, discusses the directed evolution of a secure messaging application that was designed to make sophisticated but often confusing cryptographic technology intuitively accessible to users.

Chapter 12, Growing Beautiful Code in BioPerl, by Lincoln Stein, shows how the combination of a flexible language and a custom-designed module can make it easy for people with modest programming skills to create powerful visualizations for their data.

Chapter 13, The Design of the Gene Sorter, by Jim Kent, combines simple building blocks to produce a robust and valuable tool for gene researchers.

Chapter 14, How Elegant Code Evolves With Hardware: The Case Of Gaussian Elimination, by Jack Dongarra and Piotr Luszczek, surveys the history of LINPACK and related major software packages, to show how assumptions must constantly be re-evaluated in the face of new computing architectures.

Chapter 15, The Long-Term Benefits of Beautiful Design, by Adam Kolawa, explains how attention to good design principles many decades ago helped CERN's widely used mathematical library (the predecessor of LINPACK) stand the test of time.

Chapter 16, The Linux Kernel Driver Model: The Benefits of Working Together, by Greg Kroah-Hartman, explains how many efforts by different collaborators to solve different problems led to the successful evolution of a complex, multithreaded system.

Chapter 17, Another Level of Indirection, by Diomidis Spinellis, shows how the flexibility and maintainability of the FreeBSD kernel is promoted by abstracting operations done in common by many drivers and filesystem modules.

Chapter 18, Python's Dictionary Implementation: Being All Things to All People, by Andrew Kuchling, explains how a careful design combined with accommodations for a few special cases allows a language feature to support many different uses.

Chapter 19, Multi-Dimensional Iterators in NumPy, by Travis E. Oliphant, takes you through the design steps that succeed in hiding complexity under a simple interface.

Chapter 20, A Highly Reliable Enterprise System for NASA's Mars Rover Mission, by Ronald Mak, uses industry standards, best practices, and Java technologies to meet the requirements of a NASA expedition where reliability cannot be in doubt.

Chapter 21, ERP5: Designing for Maximum Adaptability, by Rogerio Atem de Carvalho and Rafael Monnerat, shows how a powerful ERP system can be developed with free software tools and a flexible architecture.

Chapter 22, A Spoonful of Sewage, by Bryan Cantrill, lets the reader accompany the author through a hair-raising bug scare and a clever solution that violated expectations.

Chapter 23, Distributed Programming with MapReduce, by Jeff Dean and Sanjay Ghemawat, describes a system that provides an easy-to-use programming abstraction for large-scale distributed data processing at Google that automatically handles many difficult aspects of distributed computation, including automatic parallelization, load balancing, and failure handling.

Chapter 24, Beautiful Concurrency, by Simon Peyton Jones, removes much of the difficulty of parallel program through Software Transactional Memory, demonstrated here using Haskell.

Chapter 25, Syntactic Abstraction: The syntax-case Expander, by Kent Dybvig, shows how macros-a key feature of many languages and systems-can be protected in Scheme from producing erroneous output.

Chapter 26, Labor-Saving Architecture: An Object-Oriented Framework for Networked Software, by William Otte and Douglas C. Schmidt, applies a range of standard object-oriented design techniques, such as patterns and frameworks, to distributed logging to keep the system flexible and modular.

Chapter 27, Integrating Business Partners the RESTful Way, by Andrew Patzer, demonstrates a designer's respect for his programmers by matching the design of a B2B web service to its requirements.

Chapter 28, Beautiful Debugging, by Andreas Zeller, shows how a disciplined approach to validating code can reduce the time it takes to track down errors.

Chapter 29, Treating Code as an Essay, by Yukihiro Matsumoto, lays out some challenging principles that drove his design of the Ruby programming language, and that, by extension, will help produce better software in general.

Chapter 30, When a Button Is All That Connects You to the World, by Arun Mehta, takes you on a tour through the astounding interface design choices involved in a text editing system that allow people with severe motor disabilities, like Professor Stephen Hawking, to communicate via a computer.

Chapter 31, Emacspeak: The Complete Audio Desktop, by TV Raman, shows how Lisp's advice facility can be used with Emacs to address a general need-generating rich spoken output-that cuts across all aspects of the Emacs environment, without modifying the underlying source code of a large software system.

Chapter 32, Code in Motion, by Laura Wingerd and Christopher Seiwald, lists some simple rules that have unexpectedly strong impacts on programming accuracy.

Chapter 33, Writing Programs for "The Book," by Brian Hayes, explores the frustrations of solving a seemingly simple problem in computational geometry, and its surprising resolution.

According to my teachers, good code follows several aspects:- readability: a glance at the code can give you a general idea of the behaviour of the program)- self-describing names (variables and functions): a += temp3; isn't good code - traceability: when you look at a function, you can have some idea of where it's used- following of norms (depending on company/language, the indentation/names of variables can change)- small, self-describing functions: each function should only be responsible for one part of the program- disconnected components: so that you can replace components without affecting the others <- this is directly related to OO programming. using setters and getters is a better idea then accessing directly to the contents of other objects- organized code: the program should be read in the source file from top to bottom of the source

This is all i can remember from the top of my head. I'm sure others could add a more complete answer

Joto said something to me last night on the IRC channel that, to me, represents the practical importance of aesthetically pleasing code (of course i also believe that beautiful is just good all by itself ).He had a friend who had a php script, and it had an error that needed fixing. His friend could not find this error, and asked for his help. When Joto received the code, his friend had his code all bunched up on single lines to the edge of the page (much as you might format a document in word). Joto found, that after properly formatting and indenting the code, that his friend had left a command outside of a loop, when it would have been within. It would have been an extremely simple mistake to pick up had the code been formatted properly from the beginning.I am of the opinion that clean code is just as important as any other aspect of good programming.

My own (nocoder, mind you) defniition of beautiful code would be code that is simple, clean and does what it's supposed to do. I guess I'm trying to say that it should be very efficient and functional. But what do I know?!

"Some people have a way with words, other people,... oh... have not way" - Steve Martin

To me, defining beautiful code is like defining porn; you can't define it but you know it when you see it. Beautiful code is probably easy to read, but it need not be. It will invoke similar feelings to those experienced when admiring the best work of a universally acclaimed virtuoso. It's foundations will be new and innovative, but appear obvious in hindsight. The application of the actual source code will most likely be specific, but the essence of its structure will be universally beneficial. It will be something that needs to be experienced to be truly appreciated.