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.
I am having trouble with this assignment. Telling an inspiring story about a beautiful design feels disingenuous. Yes, we all strive for beautiful code. But that is not what a talented young programmer needs to hear. I wish someone had instead warned me that programming is a desperate losing battle against the unconquerable complexity of code, and the treachery of requirements. Of course I wouldn’t have believed them. It seems that pragmatism and humility can only be learned the hard way. I don’t know how to explain this in a case study. War stories do not instruct, because in retrospect the mistakes seem obvious. It is hard to convey the extent of the minefield of mistakes laying in wait. In essay form, I might say something like this:
I can’t teach you how to design beautiful code, because I don’t know how myself. I may have managed to get a few things almost right, and I have seen others do some nice work, but to be honest these successes always came from trial and error. The first try was often a total mess. Truly beautiful designs typically evolve from dozens of attempts, as for example with languages and libraries. Telling you to build one and throw it away, or to study a dozen prior examples, is just to admit that there are no general principles or techniques of software design. I hope that someday we will discover such principles. But in the meantime software design is still a matter of wisdom, not knowledge, and is therefore largely unteachable.
A lesson I have learned the hard way is that we aren’t smart enough. Even the most brilliant programmers routinely make stupid mistakes. Not just typos, but basic design errors that back the code into a corner, and in retrospect should have been obvious. The human mind can not grasp the complexity of a moderately sized program, much less the monster systems we build today. This is a bitter pill to swallow, because programming attracts and rewards the intelligent, and its culture encourages intellectual arrogance. I find it immensely helpful to work on the assumption that I am too stupid to get things right. This leads me to conservatively use what has already been shown to work, to cautiously test out new ideas before committing to them, and above all to prize simplicity.
Another lesson I have learned is to distrust beauty. It seems that infatuation with a design inevitably leads to heartbreak, as overlooked ugly realities intrude. Love is blind, but computers aren’t. A long term relationship, maintaining a system for years, teaches one to appreciate more domestic virtues such as straightforwardness and conventionality. Beauty is an idealistic fantasy: what really matters is the quality of the never ending conversation between programmer and code, as each learns from and adapts to the other. Beauty is not a sufficient basis for a happy marriage.
I cannot speak for O’Reilly, but when I refer to beauty in my code, I do not refer to a visually esthetic code, or any other random feature. Beauty in code is abstract. A beautiful code is a well-designed and modular code, that expresses with clarity the purpose of the programmer. It is a code that avoids special-case handling, but is able handle all possible cases. I could probably go on.
I often found myself saying “Yach!” out loud when facing code I knew was unmaintainable and hardly usable in an evolving code.
Of course, no one can program perfectly. But no one does anything perfectly. But some program better than others, and that’s a fact.
I have had the chance of teaching new members in my team how to program. At first, their code was clearly *ugly*: It had a faulty structure, it was far from concise, and obviously it had bugs. Surprisingly, while it was very hard for them to remember all the rules of good coding (involving modularity, re-use, abstraction, generalization, etc.), they quickly grasped the concept of beauty, and could adequately tell whether a code was pretty or not, even without being able to explain exactly why.
To conclude, I do not claim that beauty is everything a programmer must know, but it is a strong concept that helps you to write a prettier, and therefor better, code.
Hear, hear!
Beauty is simplicity and low coupling. It is a sine-qua-non of trust worthy code: code that is so simple obviously has no bugs. Yes, it does take a few attempts to get right (although not 12), but so does writing good copy.
The best design for a piece of code changes as the code’s function changes. I find that coding follows the same algorithm as a priority heap: keep your code semi-tidy as you add functionality until it becomes too complex to understand, then resort/refactor/rewrite.
Awesomely written! I couldn’t agree more.
As previous comments have said here, perhaps the book talks about “beauty” as in “simplicity” — like a Zen thing. That I can understand, and would definitely recommend as something that all coders should strive for. Simple code runs faster, is easier to understand by others, and is a pinch to debug if something isn’t working right.
“Rule of thumb: if you think something is clever and sophisticated, beware: it is probably self-indulgence. †—Donald Norman
Well said… but I find that writing and maintaing a lot of code *that needs to work* *changes your idea of beauty*.
So I would consider the simplest possible code to be the most beautiful code. Code that is overly complex, intricate, or clever is ugly!
While I’ve always appreciated beautiful code, I share Jonathan’s concern about studying it too much. I think studying beauty in music and painting has led us to modern classical music and painting that the majority of us just don’t get. Beauty can be seen when it emerges, but isn’t something to strive for in isolation of a larger context. In the software world, the larger context would be the utility of the software to the end user.
Thank you for declining to contribute to Beautiful Code, and thank you for sharing your frank rebuttal.
I will go a step further.
I am incapable of writing beautiful code.
I am 23 years old and I have written code in C, C++, D, Java, JavaScript, Visual Basic 3.0 through 6.0, VB.NET, SNOBOL4, R, MATLAB, Maple, Mathematica, CL, Groovy, PHP, Python, Perl, Ruby, c shell, bourne shell, and bash. I enjoy programming. If wisdom is the only thing a programmer can rely on, then there is only one statement I can make about what code looks like: All code is ugly.
No one likes saying what they do for a living is ugly, particularly if they get a lot of enjoyment out of it. There is a psychological term for this: Cognitive Dissonance. Basically, some persuasive information contradicts what a person knows, believes and values. Programmers know code can be improved, believe that code can be made beautiful and there set beauty as a goal and a value. Yet, a survey of the world shows programmers consistently talk about how ugly code looks rather than how beautiful code looks. When you are proud of your job, it is extremely difficult to tell others you think of it as playing in mud. Instead, you want to romanticize your job to others, especially fellow programmers. Rather than be honest, you dress up your code and then make pretentious claims that adding make-up to ugly code makes it beautiful.
This essay, expanded a bit, would have been a perfect chapter for the
book.
My advisor once told me that a good researcher has to accept a certain amount of mess. This reminds me of something Matthias once said too: nothing is ever a total failure or a total success.
LOL, nicely said.
Humm… Isn’t beauty an entirely subjective notion? Who’s to say “this code is beautiful” and “that code isn’t”?
And BTW, can’t there be beautiful bugs as well?
Maybe I’ll buy this book. It looks interesting 😉
Cheers!
Speak for yourself, Z-Bo. Most developers I know can definitely tell the difference between ugliness and beauty in code. I’ve worked on fun, rewarding projects where the code was ugly, sometimes (sigh) because of me–but the project was still engaging.
But I’ve also been on fun, rewarding projects where the code was a joy to work with — where I could show it to non-programmers and they’d get it.
So I disagree with your assertion that all code is ugly. I think there’s a beautiful/ugly axis and a fun/boring axis. They’re not completely orthogonal, but they are definitely two distinct axes.
As to the original article, I think it misunderstands the intent of the book. I’m only a few chapters in, but the best examples in so far have shown where making a piece of code prettier also made it faster, or more correct, or both. Beauty would indeed be less useful if its sole purpose were to make developers say, “Ooh, purty.”
This post was the most insightful thing I’ve heard about software development for years. Thank you!
@Ian Dees
We’re not opponents on this topic, but instead complementary view-points.
Coding is fun. I enjoy coding and write code every day. However, I am incapable of writing beautiful code. I put a great deal of thought and creativity into my designs and I am proud of that effort. Yet, all code is ugly. If you do not see the ugliness, then you have not looked at or used it long enough. You might wonder how I evaluate my work. For this, I think Edsger Dijkstra says it best: “[…] all by itself, a program is no more than half a conjecture. The other half of the conjecture is the functional specification the program is supposed to satisfy. The programmer’s task is to present such complete conjectures as proven theorems.”
Authors have made similar statements to mine but encapsulated it with a nice moral. Joel Spolsky’s “The Law of Leaky Abstractions” is an alternative way to approach my view-point, but it gets the same point across. Spolsky’s moral was that programmers will need to think in two abstractions simultaneously at some point. Edward A. Lee points out in his paper “The Problem with Threads” that many people prefer a non-deterministic concurrency model, despite the fact it interferes with the programmer’s task of presenting a complete conjecture as a proven theorem. I have no nice moral. I am not being bleak – I just do not have anything profound to say – sorry.
I think that almost all code IS crap, but with the bar so low we call some code “beautiful” by comparison.
For example:
A starving man would consider my wife’s cooking the best thing he has ever eaten.
AND:
I consider an open source project to be “great!!” if it simply does (most) what it says it does without fuss. (I would not do the same for my car or any other product I bought in a retail store!)
We rate things according to their contexts. Software is 99.9% shite. It makes our jobs very difficult. Anything that is not complete crap is a gem by comparison.
I am sure that there is the 0.01% out there that is not crap. I would suggest that, apart from being mere annecdotes and not worth using as examples, they probably have (by chance) the world’s easiest requirements for the language they were written in. Lucky them…
What is your definition of beutiful code? Because your definition of pragmatic code sounds an awful lot like my definition of beutiful code.
To me, pretty and/or cute code is:
+ simple and hornest about its intent.
+ easy to change and adapt to new requirements.
And *beutiful* code is pretty/cute code that is build in such a way, that handling of fault states and corner cases are an inherent part of the overall algorithem – this in such a way that it dosn’t muddy up the implementation.
With these definitions, pretty and cute code is an hornest goal, whereas truly beutiful code might not even be possible depending on the language and what you’re trying to do – for instance, Java has yet to convince me that it is even possible to write beutiful code in that language, whereas Haskell seem to strive to make non-beutiful code result in a compiler error.
I am simply saddened to see statements such as:
‘Yet, all code is ugly. If you do not see the ugliness, then you have not looked at or used it long enough.’
in a posting that also quotes Edsger Dijkstra, who is remembered for the phrase “Beauty is our business.” and whose career was characterized by an unwavering (some would say obsessive) search for simplicity, elegance, and beauty in the design of our intellectual artifacts.
I have been programming for much longer than you have been alive, Z-Bo. I have seen many examples of beautiful code, and been fortunate enough to have written a few fragments which approach beauty. As for the assertion that I “have not looked at or used it long enough”, I suggest that when you have been doing programming as long as I have, perhaps you will blush at your youthful arrogance.
On the other hand, as someone who also enjoys music, I realize that some people are tone-deaf.
It’s great that Dijkstra is being used on both sides of the argument. My understanding is that he strongly advocated treating code as a beautiful abstraction tantamount to a mathematical theorem. But Z-Bo’s quote is wonderfully revealing. It implies that code can not be truly beautiful unless it elegantly implements a well defined specification. Such specifications rarely exist in the real world of programming. Therefore virtually all code is ugly. QED.
Kernighan’s chapter in the book is a perfect example of this: implementing Kleene algebra (AKA regular expressions). You just don’t get such mathematically precise specifications. In the real world, the code IS the spec, for better or worse. Beauty is no guide to dealing with this reality.
It is an important insight to note that it’s hard to write good code for a bad spec.
The existence of poor specifications is not so much an insurmountable barrier to great code, as a wonderful opportunity for us to make the world a better place.
The most effective way to improve the code is to improve the specification.
And structuring software around a commitment to an unchangeable imperfect specification creates a problem.
A million thanks to you! You just made me feel a lot better about the crappy code I wrote today.. 😉
> Such specifications rarely exist in the real world of programming. Therefore virtually all code is ugly. QED.
Here here!
It is all fine and well quoting mathematicians and theoretical computer scientists (I was one before entering industry!) but there are realities to our job you can’t ignore.
The 0.01% doesn’t count. The theory doesn’t count. Just being able to define it for some domain doesn’t mean its possible in the majority of cases.
Maybe most code (mine or anyone’s) _is_ ugly. But that phenomenon isn’t limited to coding. Sturgeon’s Law comes to mind here. And it doesn’t necessarily follow that, just because beauty is hard, we shouldn’t look for ways to make our code more beautiful.
I’m not sure I buy the argument that a piece of code is necessarily ugly if it solves the wrong problem or implements a poorly-defined spec. A sentence of prose can still be beautiful even if it was written by a madman.
I lean a bit toward Edwards’s sentiment above that code just happens to be a particularly concrete kind of spec. It’s possible to write pleasing specs that are also pleasing code (see the RSpec project). It’s even possible that the resulting software will delight its users.
Rare, maybe, but possible.
I am aware of the full gamut of Dijkstra’s available writings. When I took Operating Systems in college, I decided it would be fun to go back and read the original papers on operating systems design. Later on, I would read the EWDs and they influenced my decision to write a curriculum assessment of my Computer Science department. Any quote in isolation is not an accurate representation of his opinions and saying he is best remembered for a tag line is daring. Put another way, the men that everyone admire are the ones people know the least about.
Dijkstra wrote a lot about why we should be cautious of thinking of two separate concepts as the same. Wikipedia Adventurers probably have read the Separation of Concerns page which quotes him and attributes the phrase to him, but many have probably not gone as far as reading his collected works and noticing the prevalence of this concept in his writing. Here is one random EWD I clicked on just now and it effectively demonstrates this: http://www.cs.utexas.edu/users/EWD/ewd13xx/EWD1303.PDF (“My Recollections of Operating System Design”)
Maybe quoting Dijkstra was wrong, though. Fine. I will substitute in Christopher Strachey: the first rule of programming is figure out what you want to say before you figure out how to say it! (This quote was relayed by Dana Scott at the beginning of Joseph Stoy’s book “Denotational Semantics” and I trust its authenticity.) This substitution could go without limit.
So far in my life I have not lived to regret my “youthful arrogance”. I have lived to regret people with more experience leaving the wrong impression upon me which I have had to unlearn. I was trying to better myself the wrong way: I was trying to buy into others observations that did not make sense to me! Today, this strikes me as incredibly foolish. Forgive me for thinking I should stick to the observations that make sense to me. I am a dedicated worker and my experiences are valuable to me – I don’t trade them in for anecdotes about beautiful code.
Music is not simply tone (output) but also mechanism (input). I can be tone deaf but still appreciate Victor Wooten’s controlled technique or the difficulty for a violinist challenged by the worry of a misplaced finger on a particularly hard piece. Incidentally, my friends say I am tone deaf. LOL.
Why not see beauty as a sign, rather than as a goal? If the code is beautiful, be encouraged, maybe you’re going the right way. If the code is ugly, maybe you should change course.
Don’t try to make beautiful code, but recognize and appreciate it when you see it. I think the book is useful as a collection of examples, to that end.
I’m reading the book. Hmmm… Agree there is such a thing as beautiful code, but the book isn’t an easy read. For example: Chapter 2 is the Subversion guy telling us why Subversion is wonderful. As of now it seems like it will be be 30 chapters of disjointed self-praise. I’m not sure how they chose their authors. Seems to be anyone with a moderately high-profile system to their name, regardless of how ‘beautiful’ the code really was. Well, Maybe it’ll get better as I read more of it?
Beauty — at least in as far as computer code is concerned — is not just in the eye of the beholder. There are some universal characteristics then when met allow one to ascribe the term ‘beautiful’ to a piece of code. You need only look in the other direction to see that it is true: code can clearly be ugly. We have all seen examples, and if we have not, it is easy to find them on the web. Ugly is redundant, sloppy, messy, spaghetti code, that takes forever to get to the point, and that so often hides it true behavior. If we can ascribe a degree of ugliness to code, then certainly code exists at the other end of the spectrum, even if you have not been lucky enough to have seen or written it.
I don’t really have need for a proof like this, for I have been fortunate enough to have worked with code that in its sheer elegance and simplicity was outstanding. On occasion I have even manged to craft a few things myself that I felt weren’t half bad. Beautiful code does exist, but alas, in many cases it won’t ever be shared because in seeing and understanding it, you gain some of its immense value.
Paul.
I agree with Karl Fogel that this discussion would be a great appendix to the book. I also think that the book describes the process of wise people making mistakes on the way to producing something worthwhile, and I feel that these “war stories” are instructive.
“Beauty is not a sufficient basis for a happy marriage.”
Defining beauty is akin to defining intelligence, but I find my wife beautiful for more than her appearance.
“War stories do not instruct, because in retrospect the mistakes seem obvious.†On the contrary, I think that war stories can instruct, because the mistakes are obvious in retrospect. Sure they don’t convey a magic formula, but let’s not throw them out with the bathwater—as noted, there is no magic formula.
If you majored in English, the only thing you did more than writing was reading. It would be astonishing for someone to graduate with a degree in English from a western university without having read a great deal of the western “classicsâ€, and without being conversant about virtually all western “great works of literatureâ€. I think software is very, very much like literature. Yet, when I was a Computer Science student, we were always instructed to write code, and were never instructed to read code. Given that so many of us “learned to program†by reading tiny snippets of code out of programming “textbooksâ€, I am amazed that so many of us actually became proficient at it. When I landed my first internship and got exposed to a real codebase, and had to read through huge portions of it in order to figure out what was going on (both the “good code†and the “badâ€), it made me a better software developer by two or three orders of magnitude, in a very short period of time.
I don’t know how much actual source is in that book (probably close to zero), but at least it seems to give an opportunity to read about some real world designs, which I think is a good thing. Perhaps it is romanticized, but for many practitioners of the Art of Software (or those who wish to be), that isn’t a problem.
I don’t see how beauty could not be a guiding principle of coding any more than it could not be a guiding principle of producing literature. Of course, just like with literature, there is always disagreement about what makes great literature–nobody could say that Charles Dickens’ work is not considered “great literature” by “the world at large”, and yet there are also a significant number of people who do not particularly enjoy reading his books. Perhaps there is disagreement about defining “beautyâ€?
In college, I enrolled as an English major and graduated with a B.S. Mathematics/Computer Science. I am a fan of 16th/17th century English lit., so I took some upper-graduate coursework in that area. Generally, we did not study the beauty of the literature so much as how it related to the author’s life and how we could use a sampling of personal letters to provide accounts to whether the author’s writing reflected his true opinions on the subject matter. Discrepancies between the way the author lives and the way his character lives are fascinating. At some point, scholars in English thought enough conventional analysis had been done on the key figures, and turned to more unconventional deconstructionist approach that we see today, which takes into account financial standing, position in society, etc. The courses I took in English did not emphasize studying the beauty of the authors works. Instead, they emphasized the ugliness, how to juxtaposition the author’s life and literature; we tried to trap the human condition.
That being said, reading about real world designs is important. One of my favorite authors is Henry Petroski. I commonly see developers engrossed in design namedrop Christopher Alexander, author of “A Timeless Way of Building” and “A Pattern Language”. Yet, Petroski, a civil engineer, writes a lot about real world failure. In “Design Paradigms”, he discusses the events that lead to John Roebling’s masterpiece, the design of the Brooklyn Bridge. In this book, Petroski presents case studies with some useful conclusions. The two that always stick out in my mind are: (1) You cannot reliably improve a design by only looking at the weaknesses of prior designs. Your changes might undermine the strengths of those prior designs, and actually produce a worse design as a result. (2) [Engineering] that works well in-the-small, may not work so well in-the-large.
The major problem with reading about real world designs in software is that they are usually over-sexed. The people critiquing them are often also the authors, while others will hold their opinions out of respect. Petroski mentions this subtle problem in “Design Paradigms”: he did not want to use too many modern examples, because he did not want to pay disrespect to living inventors. In addition, it is not always immediately clear why a design was wrong. In reports of building failure, it can often take many years to collect all the facts and even more to write a proper summary that can be passed to younger engineers in the hopes that they do not repeat these mistakes. This same lag is seen in software. In “Effective Enterprise Java”, Ted Neward mentions the early misconceptions of object-oriented programming among C++ developers and how programming-in-the-small stifled growth in enterprise design (his opinion, take it or leave it).
EEJ is a great book filled with war stories, but the war stories by themselves have little value. My own personal experiences reflect this. One of the first programs I ever wrote, when I was about 11 years old, was a scientific calculator. It required 2 man-months and extensive debugging to get right. Over 10 years later, I read the first chapter of Miro Samek’s “Practical Statecharts in C/C++”, in which the author poses the problem of designing a bug-free calculator. Instantly, I felt a strong connection with the war story because *I had lived this exact war.*
As a general observation, war stories tend to be very vertical. They can discuss experiences with a particular aspect of design or how well a feature was implemented, but they rarely give a good portrayal of a whole problem application domain.
Golly, ya’ll are too darn smart for me, lots a big words and stuff. Anyhow, I love this quote…
“I find it immensely helpful to work on the assumption that I am too stupid to get things right. This leads me to conservatively use what has already been shown to work, to cautiously test out new ideas before committing to them, and above all to prize simplicity.”
I think beautiful code and beautiful design are being intermixed in the comments here. You could have beautiful code that implements a poor design; and vice-versa. I would say beautiful code is simple, clear, and easy to maintain. The design *can* impact that but it may not. Why does beautiful have to be so hard to attain? If you have an object that provides a specific set of functionality and the code for it works, it’s structured well, it is easy to read and/or modify then isn’t that code beautiful?
Not only can code be beautiful
It can be art, beyond artful
It could be emotional. Just needs programming that way . . .
Many years ago Donald Knuth created a ‘programming code as poetry’ competition. Though mentioned, I was disqualified because the code was not designed to compile.
Not many poets program – yet.
Art is not functional but we assume that a programming language should – function? Of course? or Off course?
Maybe MS Windows ME was an advanced art project as some suspect?
Just a stray thought . . .
“Beauty is truth, truth beauty,—that is all
Ye know on earth, and all ye need to know.”
// If you have an object that provides a specific set of functionality and the code for it works, it’s structured well, it is easy to read and/or modify then isn’t that code beautiful? //
The problem that I see here is that the whole definition of “beautiful” isn’t quantifiable in any universally-acceptable way. We know too much and too little to be able to define it. At the same time, we carry over factors from other definitions.
My wife, for example, isn’t structured well, is nearly impossible to read, and absolutely impossible to modify. Nevertheless, she is beautiful. See what I mean?
I want code that works, is maintainable, and reasonably efficient, given that we process at LEAST half-a-million customer sessions a day. That has nothing to do with beauty, and everything to do with what’s necessary to make a living from day to day. Beauty is a luxury we’re never likely to have. I’ve done 26 years of professional programming without it. I can do another 26 years without it–standing on my head if necessary.
I have seen beautiful code and do strive for it. I don’t consider it to be something visually beautiful however, it’s always abstractly beautiful. Code is always a design problem and with any design problems there are elegant solutions and non elegant solutions.
Wasn’t it Buckminister Fuller that said “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.”
interesting to see theres a whole generation of programmer passing through a phase of realisation 🙂
my biggest realisation came in the form of Sridhar Vembu’s 27th Rule of Software Development :
“I am sure most of you programmers may have experienced this: look at some code, get totally lost, curse that evil son-of-a-bitch who wrote that code, and then realize that it was something you wrote months or years ago. At that point, the narcissist among you may start to admire its beauty and elegance and brevity and style, but the more normal types may start to wonder “Should I move to another line of work?†To help you quell that inner voice, I offer my highly original 27th Rule of Software Development: All code is spaghetti, it just doesn’t taste very good when cooked by another programmer; if you cooked it, it doesn’t stay fresh for very long.
Here is a good application of the rule: when you look at sample code that alpha-geeks present with flourish, especially on internet forums where they fondly hope, against all statistical evidence, that some pretty women may be, just may be, lurking. Often the proud author would present his sample as the ultimate in brevity and style, except that you can’t make head or tail of it at first. Some of us can’t make head or tail of even at last, but that is another story.”
Ramesh Palikara is RIGHT
alpha geek code is very rarely beautiful.
I reread your sentiments about development and “code” in your manifest, and made some reflections.
Old recommendation:
First specify behavior, then implement it.
In practice:
First encode behavior, then decode it.
My new recommendation:
First implement behavior, then combine them.
A procedure is a lousy definition. You cant see “what is going on here, where is it and how do i change it”?
There are too general design principles of code! They can be inferred from examples!
Ah, beautiful code–it is code that is reusable…
Interchangeable and systemantically organized snippets that can be composed into systems…that’s beautiful.
Domain-rich code…that’s beautiful.
Code that does not hide side effects…that’s beautiful.
Subroutines and variable names that communicate their concept–their intention…that’s beautiful.
Modular code…that’s beautiful.
Code can be beautiful if your editor displays it with beautiful colors. I recommend pink for the literals, green for the classes, black for the identifiers and syntax elements and blue for the comments. By writing your code such that each of these colors shows on each page, and white space and comments are used, your code will be beautiful. My recommendation for beautiful comments and white space is to break code into groups of four lines with a comment describing what each does. Between each block put two lines of white space, and around each comment put two long comment lines of hyphens best ending at the 80th or 90th character. Each class should also have a hyphen comment line reaching 100 characters. Wrap most lines of code before the 100th character (so that the program prints beautifully too), and try to keep your methods from exceeding 20 lines of code. The reuslt you will have is beautiful code.
O yeah, coding elegantly helps too 😉
I have not yet read “Beautiful Code”, but I did read one of the chapters, which can be viewed on the authors’ webpages
How Elegant Code Evolves With Hardware: The Case Of Gaussian Elimination, Jack Dongarra and Piotr Luszczek, in Beautiful Code Leading Programmers Explain How They Think, Edited by Andy Oram and Greg Wilson, ISBN 10: 0-596-51004-7.
A pdf version of this chapter is available: http://www.netlib.org/netlib/utk/people/JackDongarra/PAPERS/beautiful-code.pdf
This is the chapter about LINPACK and LAPACK code, and how it evolved over the years. What is interesting is that the code examples that are given in that chapter are exactly the code examples that I display when I talk about how NOT to code.
We have been working for quite a while on how to better express algorithms in this domain both in text and in code, and I believe this has led to an example that even the people who have posted here may decide is beautiful.
So, what is it that I find beautiful about it: The format of the algorithm and its representation in code reflects closely the pictures that I would put on the blackboard that explain the algorithm, when I teach.
(see the front page of http://www.linearalgebrawiki.org)
Thus, the algorithm and implementation capture the knowledge that goes with the program.
The format of the algorithms also enables Dijkstra’s dream of goal oriented programming, as we show in our recent book “The Science of Programming Matrix Computations”. (Yes, this is a cheap plug for our book. However, to keep the cost down for the end consumer, we do not take any royalties, published through lulu.com, and the book as a result only costs $8.34.. See http://www.lulu.com/content/1911788 So, not only is the plug for the book cheak, so is the book itself. Can the same be said for “Beautiful Code”?)
Enjoy
[Robert – I am willing to grant that your domain is one where beautiful code is both achievable and desirable. After all, you are starting with a precise formal description of the domain – linear algebra – that has been refined for 150 years by some rather smart people. People have been implementing linear algebra algorithms for, what, 40 years? I should hope that someone is close to getting it right by now. But of course this just makes my point, for the vast bulk of programming does not have these luxuries. – Jonathan]