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

tinjaw · « **on:** August 07, 2007, 01:27 PM »

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.

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

read article
-Jonathan Edwards

Eóin · « **Reply #1 on:** August 07, 2007, 06:12 PM »

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.

Lashiec · « **Reply #2 on:** August 07, 2007, 06:21 PM »

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.

f0dder · « **Reply #3 on:** August 07, 2007, 07:10 PM »

A beautiful piece of code is... something that makes me smile at it's beauty.

It can be the terse elegance of something kernighan or ritchie have written, it can be C++ code that really is self-documenting, etc.

mouser · « **Reply #4 on:** August 08, 2007, 08:29 AM »

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

app103 · « **Reply #5 on:** August 08, 2007, 08:40 AM »

I never understood what the definition of elegant/beautiful code is. And so far nobody has been able to supply a definition that I can wrap my mind around.

Would anyone like to take a crack at enlightening me?

mouser · « **Reply #6 on:** August 08, 2007, 08:46 AM »

Beautiful Code - http://www.amazon.co...actice/dp/0596510047

Chapter 1, A Regular Expression Matcher, by Brian Kernighan, shows how deep insight into a language and a problem can lead to a concise and elegant solution.
Chapter 2, Subversion's Delta Editor: Interface as Ontology, by Karl Fogel, starts with a well-chosen abstraction and demonstrates its unifying effects on the system's further development.
Chapter 3, The Most Beautiful Code I Never Wrote, by Jon Bentley, suggests how to measure a procedure without actually executing it.
Chapter 4, Finding Things, by Tim Bray, draws together many strands in Computer Science in an exploration of a problem that is fundamental to many computing tasks.
Chapter 5, Correct, Beautiful, Fast (In That Order): Lessons From Designing XML Verifiers, by Elliotte Rusty Harold, reconciles the often conflicting goals of thoroughness and good performance.
Chapter 6, Framework for Integrated Test: Beauty through Fragility, by Michael Feathers, presents an example that breaks the rules and achieves its own elegant solution.
Chapter 7, Beautiful Tests, by Alberto Savoia, shows how a broad, creative approach to testing can not only eliminate bugs but turn you into a better programmer.
Chapter 8, On-the-Fly Code Generation for Image Processing, by Charles Petzold, drops down a level to improve performance while maintaining portability.
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.

app103 · « **Reply #7 on:** August 08, 2007, 10:38 PM »

That didn't help any, at all. Is there a simple definition of what qualifies as beautiful/elegant code? Or what it is normally thought of as? Something?

The ugliest stuff is easily recognizable as being ugly...but I don't know beautiful/elegant when I see it. Most likely because I can't define it.

mouser · « **Reply #8 on:** August 09, 2007, 12:00 AM »

There is no simple definition -- it might be easier to define it simply as being the opposite of ugly/messy/confusing code.

So beautiful/elegant code is code that is very readable, very understandable, and nicely organized into pieces that are efficient and easy to modify, extend, and test.

Lashiec · « **Reply #9 on:** August 09, 2007, 09:29 AM »

Also, beauty is in the eye of the beholder

mrainey · « **Reply #10 on:** August 09, 2007, 09:37 AM »

Is "beautiful code" the same thing as "elegant code"?

mouser · « **Reply #11 on:** August 09, 2007, 09:45 AM »

Is "beautiful code" the same thing as "elegant code"?

yes.

app103 · « **Reply #12 on:** August 09, 2007, 01:11 PM »

Thank you. I am glad someone has finally given me an answer that makes sense and doesn't confuse me more.

jgpaiva · « **Reply #13 on:** August 09, 2007, 02:21 PM »

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

Eóin · « **Reply #14 on:** August 09, 2007, 07:07 PM »

You gotta be careful though, good code is not necessarily beautiful. Beautiful is only a subset of good code!

Ehtyar · « **Reply #15 on:** August 09, 2007, 07:54 PM »

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.

Ehtyar.

f0dder · « **Reply #16 on:** August 10, 2007, 05:11 AM »

I just ordered "Beautiful Code" after mouser pasted the TOC - it's been some months since I've had my last Amazon fix

Ehtyar: I hope JoTo's friend doesn't code like that, but that linebreaks/indentation went AWOL in the process of sending the code...

Ehtyar · « **Reply #17 on:** August 10, 2007, 07:42 AM »

Yeah, bunch of crlfs floating around in cyber space. I hope my docs don't catch them, that would look awful

Ehtyar.

Darwin · « **Reply #18 on:** August 16, 2007, 06:24 PM »

I just finished reading (the highlights of) this thread...

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?!

tinjaw · « **Reply #19 on:** August 17, 2007, 07:55 AM »

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.

mrainey · « **Reply #20 on:** August 17, 2007, 08:34 AM »

simple, clean and does what it's supposed to do

That's about the best I can hope for - "Joe Six-Pack" programming.