Forgot your password?
Programming IT Technology

Where Can I Find Beautiful Code? 371

Posted by michael
from the not-in-anything-I-write-that's-for-sure dept.
eGabriel writes "One of the benefits of free software that I haven't seen explored here is that of the opportunity to study elegant, masterful code. Besides the fact that we can all share and enjoy applications, and reuse their source code, we can also simply download the code and view it for pleasure, to learn from masters of the art. Certainly there are different criteria for determining what makes a piece of code excellent or beautiful, and I am not as interested in discussing that. If however, anyone has found a piece of free software that serves as an excellent example for study because of qualities they as programmers hold dear, I would love to read that code also and be educated thereby. Equally interesting would be code that really is bad, as long as it didn't turn into direct attacks upon the programmers involved (they can't all be gems!) Any code that shows elegant and masterful design would make for excellent reading; the language in which it is written isn't as much a concern. 'Literate' code is a bonus."
This discussion has been archived. No new comments can be posted.

Where Can I find Beautiful Code?

Comments Filter:
  • by Anonymous Coward

    Check out /usr/src on a FreeBSD system. There are countless examples of excellent code in there.

    For example, ever wonder how ping(8) works?

    $ cd /usr/src/sbin/ping
    $ ls
    Makefile ping.8 ping.c
  • by Anonymous Coward
    Tsk tsk. You forgot the "return(0);". And you didn't indent. AND you didn't check the return value of printf() (forgiveable, everyone forgets that). Is this what beauty's about? That particular snippet is ugly enough to warrent a warning in most compilers, but slashdot seems to think its worth a +1...
  • by Anonymous Coward
    Certianly not here []

  • Excellent point!

    That's something that no one has mentioned yet (that I've seen). ANY code you see can be beautiful code! A couple of months ago I got thrown back into coding C at work after being in perl for a couple of years. It went well, but I *knew* my code wasn't all that great. It worked, was readable, and relatively bug-free. But I still knew it needed some work. I read a couple of books (Programming Style or something like that?), and looked over a bunch of code that I was available. Everything from smail source to code from newsgroups.

    I learnt little bits from all these sources. A chunk of code can be bug free and crappy, but still give you good insight into how to code better. For example, I had a great routine for getting system mem/cpu info from /proc/*. Browsing through the wmsysmon code I found that (to my surprise) there is a sysinfo() call that can give me that exact information... suddenly my code is made simpler, more elegant, and more readable, as well as more bugfree thanks to one line in an obscure little applet (well, maybe not *that* obscure :).

    If the code for these programs wasn't open source, we'd have nowhere to look. There would be code around, but having a huge array of applications to look at and scoure through, makes everyone's code better.
  • by cradle (1442) on Wednesday January 24, 2001 @06:12PM (#482991) Homepage Journal
    I remember when I asked [] a similar question a few years ago. It might be informative to take a gander at it. -David
  • by AMK (3114)
    Try looking at the source for the Python interpreter (the C version; I know little about JPython). Like any sizable program it has its messy bits, but overall the organization is quite clear, the implementation leans toward the simple and straightforward instead of the weirdly optimized and obscure, and it's one of the more pleasant medium-sized programs I've worked on.

    (Where is the boundary between medium-sized and large programs, anyway? Python is roughly 150,000 lines of code, though over half of that is in the various extensions that come with the source distribution; the core interpreter itself is around 60,000 lines.)

  • though I believe you shouldn't comment every single function you create, if they are obvious, because it dilutes the value of the REAL valuable comments that explain difficult-to-understand sections.

    Agreed. I've seen comments so brain-dead it made the code HARDER to understand than if it weren't commented at all. But maybe one should still include comments of the form "I didn't comment this, it's obvious" so whoever reads the code doesn't think you got lazy?
  • You seem to think that there's some nessecary relation to programming and graphic design because they're both expressed on computers...

    Well, we are talking about beauty, no? :-)
  • I'm not quite sure about that. Konqueror isn't even close to being stable, ditto Mozilla. If you're looking for how to pull off a lot of complicated things, they would be the place to go. If you are looking for actual elegance and educational value, to say nothing of things that actually work, there are better places to look. For example, Scheme is a very simple language through which a lot of high-level, fascinating concepts can be demonstrated quite easily. I find some of the more intricate parts of Abelson & Sussman's SICP more enlightening than chugging through 10,000 lines of Konqueror, but to each his own...

  • by drix (4602) on Wednesday January 24, 2001 @06:18PM (#483003) Homepage
    Donald Knuth's Tex certainly qualifies. Not only was it written, from the ground up, by arguably the greatest computer scientist of our time, but it's so good that it's bug free. Literally, there are no bugs in it. Stop and think about what that means for a minute. Can you come up with any software program on the planet of equal size and complexity (several megs of source code - not huge, but still formidable) that can make that claim? I can't. Granted, I may be incorrect, but nevertheless I find that amazing. You can view the parts of Tex that Knuth actually wrote here []. They're written in (I think) CWEB, which is some literate programming language he has a real hard-on for. That probably means it fscking rules all, but personally I don't have the time/patience to pick it up. If you're sufficiently motivated, though, I'd imagine the Tex sources would prove very enlightening.

  • Jive sucks. Agreed. But, although I haven't looked at the sourcecode for Half-Full (or is it Glasscode?), I must say the user interface is quite unusable. To me, good code isn't just pretty to look at--it also has to be functional, and to function well. Half-full may well meet the first requirement (pretty to look at--although I simply don't know), but it fails miserably with the 2nd requirement.

    Slashcode would be an example of very functional code that does *not* look pretty. It's the flip side of the coin.

    Sorry to rain on your parade, nebby. But you need to study a little about user interface design.
  • I've never looked at TeX code, but I have this warm fuzzy thinking about how it must look. I actually haven't used TeX for quite some time, but I just always had this sense that it was done right.

    When I was using TeX, I was using xdvi as well - and that also really impressed me. Simple interface, SUPER snappy response on the gui - no animations, alpha blending, or themes...

    Click on that magnify button and zoom the window around... ahh..... does anybody write code like TeX any more?


  • Nah, try this:

    msg: .asciiz "Hello, world!\n"
    .globl main
    .ent main
    subu sp,sp,4
    sw ra,0(sp)
    la a0,msg
    jal printf
    lw ra,0(sp)
    addiu sp,sp,4
    jr ra
    .end main

    Or, why not this:

    .section ".rodata"
    msg: .asciz "Hello, world!\n"
    .section ".text"
    .global main
    .type main,#function
    save %sp,-112,%sp
    sethi %hi(msg),%o0
    or %o0,%lo(msg),%o0
    call printf, 0

    But my Sparc assembly is a little rusty, so the last one might not be entirely correct.

  • by waldoj (8229) <waldo.jaquith@org> on Wednesday January 24, 2001 @05:47PM (#483021) Homepage Journal

    God, I love Assembly.
  • It's old-style C code, but in terms of overall structure and organization it's hard to beat the original Bell Labs Unix. Now that the Lions commentary on 6th Edition Unix is generally available (Lions' Commentary on UNIX 6th Edition, with Source Code; ISBN 1-57398-013-7), you can both read the code and Lions' brilliant commentary on it. It's amazing what a few thousand lines of carefully-crafted code can do; most text editors and mail readers are larger than the original Unix kernel.

    Don't read this to learn how to program in C -- the language has grown enormously since this time, often in ways that allow for better style and consistency-checking. But do read it to see how to program with a clean, modular design and carefully thought-out organization, and probably learn more about operating systems per unit time spent than you would reading anything else.

  • by dallen (11400) on Wednesday January 24, 2001 @07:23PM (#483029) Homepage Journal
    I've seen more elegant code on [] than anywhere else. I've learned a lot there. People submit their craft, and more advanced disciples of perl comment on it and occasionally turn it into beautiful code.

    Q: What do you get when a Postmodernist joins the Mafia?

  • Though it's still pretty ugly, and apparently not as elegant, my servlet forum software [] might interest you.
  • by LawnMowerMan (13750) on Wednesday January 24, 2001 @05:52PM (#483038) Homepage
    Many have the belief that NeoMail ( is a project written in Perl which is not only excellently coded and well commented, it is also very efficient.
  • I can't help but think that it would be better code if it noted the flaws in the standard routines and either avoided them or wrapped them instead of replacing them outright.
    Bernstein wrote his software to run on a wide range of Unixoid systems, and the software performs security-sensitive tasks (mail [], Web [], and DNS [] service, for example).

    If you were in his position, how much effort would you want to spend keeping track of which routines were safe in which versions of which OSs -- particularly the closed-source Unix varieties? And if an upgrade to an OS introduces a security flaw in a routine that was previously safe, would you want to drop everything to get out a patch for that OS's users?

    In this case, having a whole package of reimplemented routines that you know are safe strikes me as the lesser evil.

  • by Fizgig (16368) on Wednesday January 24, 2001 @07:54PM (#483043)
    The best-commented code I have ever seen is Doug Lea's malloc, or dlmalloc [], the malloc used in glibc, among other places. I had no idea how a malloc would work, and I wanted to write one for my OS class, so we looked at the dlmalloc source code. MAN, that's some well-commented code! Not only does it explain what individual functions do, but it also explains each general part of the algorithm in excellent detail. And it's malloc; it better not have any bugs!
  • by mattbee (17533) <> on Thursday January 25, 2001 @12:47AM (#483047) Homepage

    People seem to be mentioning the obvious targets: Knuth, BSD etc. but I notice nobody has mentioned Dan Bernstein's [] projects, notably qmail. This guy basically didn't trust the standard C library routines for security and wrote his own string handling, file processing etc. based on a few system calls. He also splits up his programs into separate binaries as much as possible and is very, very minimalist in other ways too. The code seems quite impenetrable at first, I'm not sure beautiful is the right word, but it's certainly an education.

    Also worth a read is Sam Latinga's C++ port of the classic Mac game Maelstrom []. The actual code of the game is surprisingly small and very well-written.

    Oh, and while I think about it, the InfoZip sources [] are a real surprise too-- I mean this code is one of the most portable pieces of code you'll ever see; they're a very good example of the sort of lengths you'll need to go to in order to achieve this kind of portability, and it's still elegant in my opinion.

  • by platypus (18156) on Wednesday January 24, 2001 @06:03PM (#483049) Homepage
    I'm far away from being a linux zealot, but an real good example (IMO, YMMV etc.) is reading linux-kernel.
    L.T. and the other kernel hackers sometimes get into very interesting discussions. Lately there was a discussion where L.T. called the HP-UX sendfile implementation obviously stupid (and BSD's too, yeah, roll on ;-)).
    One of the people who answered was ... well the implementor on HP-UX himself and a very interesting discussion began.
    So, leeching on mailing lists might help - and if you're not into low-level os programming I'm sure you'll find a open source project which covers areas interesting to you (unless you're doing ERP applications or such stuff).

    "There is so much to be said in favor of modern journalism. By giving us the opinions of the uneducated it keeps us in touch with ignorance of the community."

    Oscar Wilde (1854-1900)

  • I used to work at Microsoft as a tester for Windows NT 5 (pre Windows 2000). I had read the "required reading" of "Showstopper" and was curious to see Cutler's code. I found his assembly code for NT spinlocks and it was highly commented and very elegant.

    When I was at school at the University of Washington, one my profs worked with Cutler at DEC. He said Cutler would print out his code into two piles: code and tests. My prof said the test code pile was 3x taller than the shipping code. Cutler is a huge stickler for testing your own damn code! ;)

  • I can't help but think that it would be better code if it noted the flaws in the standard routines and either avoided them or wrapped them instead of replacing them outright.

    Or perhaps he should report the supposed bugs to so they can be fixed for everyone else.
  • So it rarely has bugs. That has nothing to do with whether or not it's "beautiful."

    Perhaps, but from the kind of person Knuth is, I'm sure that it is.


  • I agree... though I believe you shouldn't comment every single function you create, if they are obvious, because it dilutes the value of the REAL valuable comments that explain difficult-to-understand sections. Like one comment in the JDK I remember:

    Reference getRef()
    /* gets the ref */

    Or something like that... who needs it?!?
  • by Dr. Tom (23206) <> on Wednesday January 24, 2001 @06:55PM (#483060) Homepage
    When I download something, the first thing I look for is comments. No matter how clever or elegant the code is, nothing 10,000 lines long can ever be so self-evident that you don't need comments.

    Especially if the algorithm is particularly clever, it can be relying on some subtlety that will be entirely missed without a good long comment. Modifying such code is dangerous.

    One of the reasons people like Knuth's approach so much is that he puts the comments first, conceptually. The code is essentially embedded in a great long comment that describes everything that's happening. The code is just there to distill the essence of the algorithm into a form a stupid machine can understand. If the machines were a bit smarter, they would be able to run the program by reading the comments and executing them!

    Code with no comments is not a sign that the author understands his code so well that he doesn't need them. It is a sign that the programmer is lazy, sloppy, and doesn't care whether or not his code is maintainable. I just can't emphasize this point enough: for Open Source projects commenting is even more important than code. A large faceless company can get away with releasing products built on hundreds of thousands of lines of uncommented code, because they have external documentation, and can afford to spend thousands of dollars training new programmers. But if you want other people to even look at your code, you have to help them understand it. People making patches to code they don't fully grok are just going to make a mess.

    Good commenting style is as difficult to develop as good coding practices (the two really go hand in hand). Mental discipline (did you ever say to yourself "I'll go back and comment it later"? Did you?), clear exposition of an algorithm (no, the code is not a clear exposition -- remember code is CODE, it's meant for a stupid machine, not an intelligent human), maintainability, etc. Comments should be written in complete sentences wherever possible. Don't comment like this:


    * this comment
    * is pretty
    * but hard to format again
    * when you change it
    Rather, write them like this:
    /* This comment is a paragraph. Any text editor can reformat this comment after you change it. */

    Not everybody uses the same tools you do. Comments should be as easy to change as possible. If they aren't, people won't do it, and the comments can get out of synch with the code, which is even worse than no comment at all.

    Languages without block quotes are very irritating in this respect.

    So don't look for beautiful CODE, look for well written prose comments. THAT program will be more stable, easier to use, more functional, and a joy to work on.

  • The sad truth is that I work with people that pretty much have that attitude. Maybe that's not what they intend, but that's the result. When I've asked how to make a change to a JavaScript parser, I was told: I had to trace through the code, so you should too. This coming from the guy who requested the change. The thing is, when I pressed him for more information, he finally explained enough that I was able to make the fix in a couple of minutes, otherwise it would have been hours.

  • by J.J. (27067) on Wednesday January 24, 2001 @06:50PM (#483071)
    The problem with reading source code is that it's a lot like art. Not art the idea, but art the thing. (Writing good code is an art (the idea) but that's not the point)

    Art is enitrely subjective. And the definition of good code is subjective. You realize this, and state that you're not interested in what defines excellent code. But we do agree that to find excellent (to you) code, you're going to have to dig through a lot of good (to others) code before you find that gem. Which leads to the next problem...

    Art takes study to fully understand. And again, excellent code takes study to fully understand. Some will say that the ability to understand code quickly is an element of excellence, but this goes back to the first point, that art is subjective. Perhaps someone else places versatile and consistent APIs across a tool set above readability. Programmers are always making trade-offs between the relative incline of the learning curve and the power of the interface. (windows vs. unix, for example)

    You can continue the analogy for a while, but these two combine to make a situation where you're going to have a tough time finding good code. You'll get tons of submissions of what excellent code is, but to make that distinction yourself, you're going to have to study each case in-depth.

    Good luck.

  • "Equally interesting would be code that really is bad, as long as it didn't turn into direct attacks upon the programmers involved (they can't all be gems!) Any code that shows elegant and masterful design "

    Some of the most "elegant and masterful design" I've ever seen is code from the obfuscated C coding competition ( []; it may often look pretty atrocious to the "untrained eye", but there are some pretty amazing examples of masterful design - and good design is something beautiful in itself, no matter how aesthetically displeasing it may be to the average Joe's eye. Huge industrial structures like, say, oil rigs, often look ugly to the general public, but I guarantee you, to the engineers who design and build such things, the people who can appreciate the achievement in building such things, they are often seen as beautiful.

    So explain to me how exactly this post is off-topic? When did /. moderation become so lousy?

  • I wasn't as impressed as you seem to be, at least not with the Quake1 source code (I can't comment on the doom source code). It certainly wasn't bad code, it was relatively well thought out, and relatively neat, but poorly commented, and the use of #define's and the plentiful use of function pointers in some cases made it pretty obscure and confusing to determine what was getting called when, and what parts of the code were supposed to do what (particularly since comments are so scarce.)

    of course, the only part I looked at though was the socket-level network code, so perhaps the other parts were better, I don't know. But I don't remember being overly impressed with the code. Not unimpressed, but not impressed either.

  • by RobertGraham (28990) on Wednesday January 24, 2001 @07:42PM (#483076) Homepage
    I wrote a piece of code in just a weekend that emulates the functionality of Carnivore. Because it was a rush job, I wouldn't call it particularly artful, but one of the "artful" things is that it compiles on Linux, Solaris/SPARC, and Windows (yes, Windows) with identical functionality but no platform-specific #ifdefs.

    The reason I think this is artful is that people tend to write code that runs only in their own platform. The fast majority of Linux code I see will not compile/run on a Solaris/SPARC system. Likewise, the Solaris/SPARC code rarely runs on Linux. Throwing Windows into the mix makes things even tougher.

    For example, one of the chief problems is that the old *(int*)p problem. If you are lucky, you simply get a byte-swapped value; if 'p' is unaligned, your program will actually crash (it's a RISC thing).

    When deal with external data structures (network protocols, binary files), most programmers think it is "elegant" to map structures on top of pointers. In reality, it is one of the most evil/ugly things you can do to code. One of the prettier pieces of code I've seen recently actually had a comment /*struct are for weenies*/ (meaning the structure-mapping process, not internal data structures). Dealing with such data one byte at a time sure look ugly to the uninitiated, but it really is the prettiest way.

    In any case, one of the reasons I'm posting this is because I don't post much open source, and therefore don't know much about what other people find ugly. I would be interested in hearing your comments about the source on Please send e-mail to

  • That's actually an example of very bad code. Besides its obvious aesthetic shortcomings, it lacks error checking, it embeds hidden and unnoted dependencies, it's not extensible, etc. Brevity is a characteristic of much great code, but brevity achieved by doing only half the job doesn't count.

  • This guy basically didn't trust the standard C library routines for security

    In this particular case the author might have had good reasons, but in general reinventing the wheel is not a mark of good code. I can't help but think that it would be better code if it noted the flaws in the standard routines and either avoided them or wrapped them instead of replacing them outright.

  • I'm actually having trouble believing that you're serious. Can anyone's view of programming really be so impossibly narrow that they can't see the obvious deficiencies in that code, and actually try to argue on its behalf? Wow. That is just totally sad.

    There are 6 places where it catches and reports errors via the "or die" construct. Did you miss that?

    No, I damn well didn't miss it; it doesn't matter. Two objections:

    • "Or die" doesn't really count as error checking. Would you like to hit an "or die" every time you mistype a response at a CLI? Every time a network server got a response it didn't understand? Every time an OS failed to recognize a piece of hardware?
    • There are more than six ways this code can fail, so six checks are not sufficient. For example, it's immediately obvious that it doesn't check for or respond appropriately to errors from accept or fork. Maybe sometimes those errors will be caught in the next "or die"; often they won't, and all you'll have is an uncontrolled program termination.

    I repeat my original statement: the code does not totally lack error checking, but it does lack error checking (relative to what should be present in good code).

    it is pretty easy to argue that it is more "extensible" than most web servers because you have to know only two things to extend it:
    • Perl.
    • 34 lines of Perl.

    It is easy to argue that, but wrong - on several levels. You left out IO::Socket, a little bit of UNIX, and a little bit of HTTP, but it doesn't matter. Your argument is a little bit like saying you need to know only one thing to become a doctor, that one thing being medicine. It's absurd.

    Even that doesn't matter, though. When it comes to extensibility, anything that requires that you modify existing code is still a level below anything that can be extended without such modification. This code is only extensible according to a definition so lax as to allow any code to be considered extensible.

    What part of "the job" did it miss?

    All of the parts that distinguish software engineering from mere screwing around. I'm not talking about functionality, I'm talking about the things that make some code that performs a function better than other code that performs the same function. This code may indeed fulfill its requirements (chiefly brevity) and do so admirably, and I do think it's pretty cool. However, as an example of "beautiful code" - the topic of this article - it totally and utterly fails. I wouldn't be surprised if even its author agrees. It's not beautiful, it's not supposed to be beautiful, that's not its purpose, and however cool it may be it has no place in a discussion of beautiful code.

  • In this case, having a whole package of reimplemented routines that you know are safe strikes me as the lesser evil.

    ...but still an evil. As I said, in this particular case the author may have had good reasons for replacing standard routines. In the grand scheme of things that might not make his code bad, but it can't really be listed among the things that make it good. The code's minimalism and modularity, which you also mention, are much more encouraging.

  • That's pretty aggressive for someone who failed to respond in a rational way to any of my questions.

    I think most people who read it would say my response was quite rational...even if they disagree with it, or find my tone offensive. That contrasts quite sharply with cid #489, which makes absolutely no attempt whatsoever to support or rebut any relevant claims. I'd love to continue this discussion, but only if you give me something deserving of a response instead of mere meta-argument.

  • I've seen more bugs introduced by gratuitous rewriting than by any other single cause. You see, there's a lot of code out there that really does mostly work, even if it's poorly designed, except for a couple of bugs. You can fix those couple of bugs - patching a bad design - or you can replace it with a new version which fixes those two bugs but introduces twenty new ones. I've seen it time and time again.

    In fact, "rewrite fever" mostly seems to afflict programmers whose egos far exceed their skills. They assume that if code is hard to understand it's because the previous author was an idiot, not because they themselves lack knowledge. They also believe that they can replace in half a day what took someone else weeks to write and debug. What usually happens is that they only realize after they've done the rewrite that the old code solved or avoided some problems they hadn't even been aware of, so they start patching the new version. The net result is new code that's every bit as messy as the old, and nowhere near as well tested.

    Better programmers prefer surgery to amputation. It takes far more skill to develop the thorough and subtle understanding of code required to fix it in place, but when possible it's preferable. Rewrites should not be attempted without knowing exactly what the new code needs to do (ideally expressed in the form of thorough regression tests), and that usually requires careful study of the old code. You just can't get around that need to understand the original, and anyone too lazy or too proud to try definitely shouldn't be allowed to write any new code.

    Yes, there is a point where a particular piece of code collapses under the weight of all the patches and workarounds and needs to be replaced outright. Amputations are sometimes necessary, but only a skilled surgeon should be allowed to make that call. Patching a bad design is often the best - and certainly the most cost-effective - way to get better code than you started with.

  • by ajs (35943)
    Gtk+ is one of the finest examples of software engineering I've ever seen. By extension, I'm including glib. Check out these documents for most of my reasoning:

    The Gtk+ FAQ []
    The gobject reference []
    Tic Tac Toe in Gtk+ []
  • by SecretAsianMan (45389) on Wednesday January 24, 2001 @11:27PM (#483098) Homepage
    as the years wore on and the few remaining bugs were fixed ... the bribe went up

    The bribe started out at one cent (for the first bug) and doubles for every new bug, I believe. Now THAT's some trust in your work!

    SecretAsianMan (54.5% Slashdot pure)
  • I had a very similar experience. It's nice to see the story behind a passion. I learned to program when I was 13 on the Apple II. A year later I got a C64 and delved deeper. My interest in amateur radio led me towards EE, so by the time I got to college, that was my major.

    I was a disillusioned kid at that point and learning EE only to go work for some part of the military industrial complex (this was the late 80's) made me like the prospect even less.

    Then one day I was talking to some comp-sci grad students about the state of the art and realized that the world of computing hadn't actually passed me by! This was an avenue that was still achievable. So I scraped some money together, bought a 386/SX-16 (without the HD at first, to save money) and taught myself to program. Shortly thereafter, I dropped out of college to pursue a career. Ten years and countless remedial books on algorithms and datastructures later, I can call myself a programmer.

    BTW, some of the most elegant code I've ever seen is the Windows NT kernel. That comment's likely to draw distain from this crowd, but the effort was led by Dave Cutler, the same guy who led the VMS crew. Dispite what people say about MS, this man's creation is a masterpiece (disregarding whatever is layered on top of it).
  • by cyrusp (65739) on Wednesday January 24, 2001 @05:58PM (#483107)
    Jargon file says it best:

    TeX has also been a noteworthy example of free, shared, but high-quality software. Knuth offers a monetary awards to anyone who found and reported bugs dating from before the 1989 code freeze; as the years wore on and the few remaining bugs were fixed (and new ones even harder to find), the bribe went up. Though well-written, TeX is so large (and so full of cutting edge technique) that it is said to have unearthed at least one bug in every Pascal system it has been compiled with.
  • by Eight Star (67539) on Wednesday January 24, 2001 @06:05PM (#483109)
    For all of those who haven't read it, or want to again, this is a good story [] about cool code, and a cool coder.
    This [] is the Google search I found it with.
    The real Eight Star misses Technocrat.
  • I'll second that recommendation. Well-written Haskell is a thing of sublime elegance. No, really. It's highly declarative (having no real notion of state - just monads, bits of state you can pass around). And its lazy evaluation enables some wonderfully elegant things, like infinite lists (no, not a function you call to get the next element - it is a list). Short examples often use combinatorial mathematics. Let's take a simple example: factorials:
    fib 0 = 0

    fib 1 = 1
    fib (n+2) = fib n + fib (n+1)
    Yes, that's the function definition of factorial. Looks a lot like the mathematical definition, don't you think? And no, it doesn't need to check for integer roll-over because integers in Haskell do that intrinsically (i.e., 32 or 64 bit til they roll over, then it goes to an arbitrary precision representation).
    Examples> fact 20

    Another classic example is an infinite list of prime numbers using a modulo sieve:
    primes :: Integral a => [a]

    primes = map head (iterate sieve [2..])
    sieve (p:xs) = [ x | x<-xs, x `rem` p /= 0 ]
    The first line is an explicit type declaration saying "primes is a list of things conforming to the class Integral." I leave the rest as an exercise in reading uncommented code :-) except to note that "[2..]" is the infinite list of numbers starting at 2 (you can do finite ones, too, like [2..20]), and [x | x<-xs, some boolean expression of x] is the list of all x such that x is an element of xs and the boolean expr is true.

    Now, just in case you think Haskell is only used for dense mathematical expressions, note that it comes with literate programming functionality built in. And the Haskell Home Page [] has some examples of some quite meaty real-world examples.

  • by amnesty (69314) on Wednesday January 24, 2001 @06:00PM (#483112) Homepage

    This really got my geeky juices excited when I saw this. One piece of source code that could compile/run unchanged into 7 different languages. Listed in the source they are: ANSI COBOL, ISO Pascal, ANSI Fortran, ANSI C (lint free), Shell script (GNU Bash, Ksh, sh), PostScript, and 8086 machine language. No matter which you use, the magical words "Hello World" will appear!

    Click here [] for the link.

  • by ndfa (71139) on Wednesday January 24, 2001 @06:16PM (#483114)
    This is in my mind some really really sexy code.
    I guess you can call is OSS, you see it in almost every Programming Language book that uses scheme or something like scheme/lisp.... to see what it does check out Y-Combinator Derivation []. So the basic idea is to be able to have a recursive func. that does not have a name.....

    (define Y
    (lambda (m)
    ((lambda (f) (m (lambda (a) ((f f) a))))
    (lambda (f) (m (lambda (a) ((f f) a)))))))

  • If the code was hard to write, I'm going to damn well make it hard to read!

  • Ok, in my rush to post, I forgot to #include <stdlib.h> and add return EXIT_SUCCESS to the end.

    Mark Duell
  • Would it be great if you were
    writing beautiful code...
    on a beautiful computer,
    while you eat beautiful nacho chips,
    and gaze longlingly out your beautiful window,
    at a beautiful butterfly,
    and a beautiful rabbit,
    playing in your beautiful yard...

    Oh, - and your drunk.

    sorry... props go to SNL and the Jack Handey deep thoughts... but this is the first thing that popped into my mind.
  • uh. to a nonperl programmer like me - that looks more like line noise than anything beatiful.

    Oh yeah? Well, The Kalevala looked like line noise to me, too; until I got my first edition copy of Crawford's 1888 translation. Now it looks like very strange poetry -- I think maybe I'll have to learn Finnish and appreciate it nearly as much as the Karelians.

    Fortunately, I don't think Babblefish has a Perl to Finnish mode, which means you won't see a version of Rick's server that looks like very strange code -- it will continue to look like line noise to you until you learn Perl, at which point its poetry will emerge from the noise.

  • its obvious aesthetic shortcomings

    That's in the eye of the beholder. To some of us, Rick's code reads like poetry or elegant math notation.

    it lacks error checking

    There are 6 places where it catches and reports errors via the "or die" construct. Did you miss that? If not, what did Rick miss?

    it embeds hidden and unnoted dependencies

    That's too vague to be considered a valid critique.

    it's not extensible

    While the purpose wasn't to write an "extensible" web server, it is pretty easy to argue that it is more "extensible" than most web servers because you have to know only two things to extend it:


    34 lines of Perl.

    brevity achieved by doing only half the job doesn't count.

    In a parsimoneous form, Rick has specified, in a high level language, the functions of a web server.

    What part of "the job" did it miss?

    Then we'll see how difficult it is to "extend" his server.

  • I'm actually having trouble believing that you're serious. Can anyone's view of programming really be so impossibly narrow that they can't see the obvious deficiencies in that code, and actually try to argue on its behalf? Wow. That is just totally sad.

    No, I damn well didn't miss it; it doesn't matter.

    "Or die" doesn't really count as error checking.

    Your argument...'s absurd.

    Even that doesn't matter, though.

    All of the parts that distinguish software engineering from mere screwing around.

    That's pretty aggressive for someone who failed to respond in a rational way to any of my questions.

  • by Baldrson (78598) on Wednesday January 24, 2001 @11:39PM (#483126) Homepage Journal

    Check out the 34 line web server [] written by Rick Klement [mailto], the best Perl programmer I've ever known, who says of it:

    I wrote this after seeing a small HTTP server that took ~650 lines of C. I thought it would be an interesting challenge to try for a ten-to-one reduction. Not only did I exceed that, but the ~650 line server did not do POST type CGI's, which mine will.

    This server (which I name 'ws') has been quite useful. I use it for CGI testing, it's much simpler launching 'ws' with all parameters given on the command line than modifying an Apache [] conf file and firing the new Apache server up.

    'ws' takes four arguments on the command line,
    ws port_number doc_tree_base cgi_tree_base cgi_location
    but they all have defaults. I usually fire it up with
    ws 80 . .
    and then fetch plain docs from machine/somedoc.html and CGI's from machine/cgi-bin/

  • if(!printf("Hi there.\n")) {
    if(puts("printf() didn't print anything!")==EOF) {
    perror("puts() didn't print \"printf() didn't print anything!\" because your screen ran out of space(?)...!");
    /* doesn't return anything, so nothing to check... finally! */

  • Eh?

    Tell that to the psychiatrists and psychologists who treated me in the psychiatric hospital where I spent the summer of 1985, when I was diagnosed with schizoaffective disorder.

    Or to my insurance company at the time, who sprung for the $10,000 treatment.

    I know it may be fashionable to claim one is manic depressive, but I can assure you it's unmistakeable in me, and it's not something I would choose. There's no Hell so deep as what I experienced in my college days.

    If you don't believe me, maybe you'll at least believe I do some good in my writings. I regularly receive emails in response to my website on Manic Depression [] from people who've experienced it - either they have it or their loved ones do - and they don't know what to do about it.

    There is a lot of information available about the illness but because of the stigma which is perpetuated by ignorant people such as yourself, not a lot of folks have the confidence in themselves to speak out about their experience publicly as I do, occasionally here on Slashdot and permanently on that website.

    I speak out in part because of my confidence in my position in my career and also my belief that speaking out on what is right is one of the most important things you can do [], even when it comes at great personal cost.

    The people who write to me tell me the fact that I speak out personally as I do makes a tremendous difference in their lives. It has happened many, many times that someone has written to me to tell me that I'm the first person they've shared the fact that they think they're mentally ill, or contemplating suicide.

    You should know that that page receives about 3,000 hits a month, and I recieve several emails a day from people looking for advice, about half of them people who have the illness and the others from people who are closely involved with a sufferer and don't know how to deal with them.

    By the way, I'm happily married. I first met my wife three years ago, and we were married in St. John's Newfoundland on July 22, 2000. We just bought our first house together, in Midcoast Maine, and moved into it last weekend.

    Michael D. Crawford
    GoingWare Inc

  • by goingware (85213) on Wednesday January 24, 2001 @07:11PM (#483132) Homepage
    I was in and out of my University physics studies a number of times, and having a generally bad time, because of a serious illness [], and at some point decided I should get out and get a programming job because I figured I'd be better at that than school.

    I didn't really know how to program, I knew a little FORTRAN, C and Basic from doing data analysis during summer jobs, and I didn't really like it all that much. I used to really have to struggle to spend several weeks writing a 500 line program, and I'm sure I'd be embarrassed if I had to look at the source code to those programs today.

    I figured I'd program for a while because it paid the rent (I was making $20k a year doing Sun administration and writing image processing software), but when I figured out what I really wanted to do for a living I'd quit programming and get a real job.

    That was in 1988. Then some consultant visited and installed GNU Emacs [] on our machines (two Sun 3/160's, one diskless, both with terminals and no workstation monitor, but with frame grabber cards and NTSC color monitors). He explained about the GNU manifesto [].

    I thought it was pretty cool but didn't see it affecting me personally in a big way. I was mostly annoyed that I had to wait up while the consultant installed the software on what was supposed to be my day off while a ladyfriend was visiting from away.

    Then my friend Jeff Keller, who went to MIT for a while and vaguely knew Richard Stallman, spent an evening with me singing the praises of Emacs. What I really wanted was VI with macros you could program to include conditional branches, and he said it had all though and much much more.

    So I learned to actually use Emacs, and soon learned that it was quite extensible, but it wasn't made too clear how to extend it. The online manual was useful mainly to people who already knew what they were doing.

    So I read the source code. One thing I was interested in doing was writing C functions that were callable from Emacs lisp as lisp functions. There are many such functions built into Emacs (usually for performance) and you can add your own. There's this big DEFUN macro that even makes the C API look like Lisp.

    I learned that and a lot more. I learned what an eloquent statement of software architecture Emacs is.

    I learned that there really was something worth my while doing in the way of software.

    I wanted to write a program like that someday. Not another big editor, but a program that would someday strike other young programmers the way Emacs struck me.

    During the course of reading the source code, one day I stayed at my terminal 24 hours straight, arising only to get coffee and use the restroom, not even eating. I only realized how much time had passed when I started to fall asleep.

    That was when I started to take programming seriously. I began to put serious effort into studying programming, and studying it deeply.

    For example I would read Knuth's The Art of Computer Programming [] on the bus on the way to work and I would stay up all night after work learning to program better on my Macintosh at home.

    For many years I selected all of my jobs based mainly on what I could learn from them.

    I've become a very skilled programmer. You can see this from my consulting business website [], my resume [] (on my resume the place where I first encountered Emacs is the Programmer job at Verde Technologies) and my programming tips pages [].

    So in a very direct and profound way I owe it all to Richard Stallman [] and Emacs.

    I still haven't written my great program yet. I don't even know what it will be. One project I've worked on peripherally is the ZooLib [] cross-platform application framework and a project I've just started up but not gotten too far with yet is the Linux Quality Database [].

    I did finally get my B.A. in Physics, from UC Santa Cruz [], but only after being out of school working at a programmer for a number of years.

    Michael D. Crawford
    GoingWare Inc

  • Check out Jive [] for an excellent example of beautiful coding in Java. There are a lot of forum software packages out there but none as complete (in terms of code design).

    I've been able to look at this code and immediately understand, admire and learn from Matt Tucker's code from day one. Makes a good read.
  • Code with no comments is not a sign that the author understands his code so well that he doesn't need them. It is a sign that the programmer is lazy, sloppy, and doesn't care whether or not his code is maintainable. I just can't emphasize this point enough: for Open Source projects commenting is even more important than code. A large faceless company can get away with releasing products built on hundreds of thousands of lines of uncommented code, because they have external documentation, and can afford to spend thousands of dollars training new programmers. But if you want other people to even look at your code, you have to help them understand it. People making patches to code they don't fully grok are just going to make a mess.

    I wholeheartedly disagree. There are a lot of people around who sing the same song about "it's all about the comments..." I feel strange whenever I hear such claims.

    First of all, if someone is supposed to maintain a piece of code, he or she has to read the code (not the comments!) and understand it. Period. In most of the cases, its even better to just forget about the comments at all. Comments won't be translated into machine code... but the source code will, and that's what's going to run in the end. It's unlikely that a programmer will adjust all the comments (if there are changes in the code) to be completely consistent all the time. You simply can't trust comments.

    Thus, the more comments a code has, the more I try to ignore them.

    Now, I'm not saying good code has no comments, I just disagree with your your claim:
    The best code has lots of comments.

    Comments won't guarantee you good code, (and of course the lack of them won't guarantee you anything either.) There is good code around with plenty of comments, but there is also great code that is nearly comment free. You can find excellent examples at Dan Bernstein [] as an example.

  • I think beautiful code is subjective like art but unlike art programming has a relatively short history. I think things that would define beautiful code could be things like originality of thought, simplicity, and efficiency as well as the more common things like is it easy to read through and does it exhibit the general consensus of how things should look at the time. I think that in time groups will begin open source "peer reviews" where people could actually vode on things like syntax, originality, simplicity, how well they perform the function for which they were intended. I'm not sure of anything out there like that right now asside from the obscufiblagh* whatever they call it.

    I think it would be neet to see a site pop up where thats all they did was take pretty code and imortalize it for study and general advancement of the "science".
  • can be found right here. []

    It's cool because it's really small.

    In fact I think it's the smallest program possible with an ELF binary. About an eight of the size of the excecutable created if you use some kind of fancy-schamcy assembler. And a 50th the size of the same program created by gcc.

    darn cool if you ask me.

  • Silly me. Dumb joke.

  • Uhm, what's wrong with reading code? It's very nice to see how someone did something. Some of the most creative and elegant constructions I've seen ANYWHERE have been in source code. It's really an underrated form of expression.
  • The appallingly bad API that Microsoft provides with their tools is a very good reason to dislike Microsoft. ...poor level of documentation... disregard for decent coding style... void pointers... so I would have to concur that Microsoft is not the place to look for good code.

    Though I agree that most MS APIs are bad I also understand why they haven't been changed. Why are we still using sprintf instead of snprintf? Compability comes to mind. We are trying to keep source level compability with other UNIXes where MS is trying to keep source level compability with other versions of Windows(TM). In addition to compability problems changes would render current knowledge on MFC etc. completely useless. I'd think that those void pointers are there for historical reasons only.

    If you still disagree think about X and xlib. Why are we still using API that doesn't have any support for alpha blending, vector graphics, decent pixmap filtering etc. features supported by hardware in current graphics chips. We don't have even anti-aliased fonts which I myself take for granted in every other OS I use these days.

    I wouldn't call MS documentation poor. Perhaps they don't give you all the documentation for free, but there good documentation for the areas MS wants the developers to know. Sure there's undocumented features that MS uses in its own software and others follow with reverse engineering. It's MS source and it's up to them what they want to tell about it to developers.

    If you don't like MS APIs or their OS don't support them. Notice that if you don't make programs for their OS you don't need to care about their API quality. What comes to coding style (I assume you mean code formating)... for example I cannot stand GNU coding "standards" - fortunately I have indent.

    The fact that MS does provide some old ugly APIs doesn't automatically suggest that MS couldn't be perfect source for look for good code. Unfortunately MS seems to keep most of it's code secret. Do you really think that company that hires every top quality coder it can get would generate only bad code?

  • Some of the most beautiful code produced in the past 20 years can be found here. []

    you can thank me later

  • by Triscuit (122259) on Wednesday January 24, 2001 @05:55PM (#483187)
    I think the question can really only be answered to applying it to a particular task.

    There are almost always good solutions to a certain task that can be considered good.

    Next thing that must be done is to define "Good Code". I'm sure everyone has their own opinion as to what good code is;

    Readable, Well Commented, Efficient Algorithm, Proper Naming Conventions, Follows Appropriate Documented methods, etc...etc...

    I'm sure there are hundreds others!

    Perhaps a question like "What defines good code" would still be only slightly more beneficial to those reading the posts.
  • Surely you mean:

    printf("%d file%scopied\n", n, &"s "[n==1]);
  • Kernel source, Apache, Samba, Gnome Bonobo, KDevelop, Mozilla, Konquerer...the big name stuff should be pretty juicy.

  • by istartedi (132515) on Wednesday January 24, 2001 @07:34PM (#483196) Journal

    Not so much the code itself, but the APIs are easy to use, they're highly portable, and very free. I wish I could say libpng, but it took a little bit too long to figure out how to make it do what I wanted. Maybe that was just me though. There was some trial and error involved. Let's hear it not only for "beautiful code" but the entire package being well designed and easy to use.

  • You'd better not say that too loud, or the "Perl is incomprehensible line noise" crowd will have fits. Of course they'd probably be happy to say that to find some of the really awful, unmaintainable garbage you should just look here [].

  • No, it's not beautyful.
    1. It is not even legal ISO (or ANSI) C, because main should return a value!
    2. It is stupid to cast the return value from printf(). It introduces more visual clutter, and serves no purpose.
    3. I think you could afford a line of whitespace between the preprocessor directive and the main function.
    4. It does nothing useful.
  • I would suggest you download Hugs [], start dabbling in Haskell [], and read the Haskell Prelude. It is relatively easy reading and contains code that is very beautyful.
  • Yeah, I'll take Function before Fasion any day...
  • bzzzt! wrong! Checking out my trusty ANSI C book

    Maybe you need to check out another C book then. Let my guess, you are using The Annotated ANSI C Standard, annotated by Herbert Schildt? This is probably the worst book ever written on the ANSI C standard. Or are you just using some other half-good book on C? I doubt you are actually using the ANSI standard, because in that case you have proven that you do not know how to read.

    If you get to the end of the main block, that is assumed to be grounds for correct correct program termination(so the compiler will helpullfy insert the return statement for you).

    No, that is not true ISO C. I think it might be true of C++, but then again, that's a completely different language. Also, the fact that some compilers will allow it, is not very interesting either, since compilers are allowed to do what ever they want when it comes to undefined behaviour, which is what this is.

  • That's not true. printf() returns an int. Casting it to void is more correct than silently throwing away the return value.

    No. It is not "more" correct. In fact, both options are legal ISO C, and therefore equally "correct". It is, however, a stylistic issue.

    And when it comes to style, opinions sometimes differ. I agree that there might theoretically exist situations were a void-cast could theoretically improve some readers understanding of a program, but I have yet to see that in practice. Anyone knows that printf() is called mainly for a side-effect. And side-effecting functions should not be a foreign concept to C programmers, as C is not exactly what I would call a pure functional language.

    Anyway, I think any C-programmer on the planet knows that printf() is called mainly for a side-effect. You do not need to tell them that with a void-cast, as little as you need to tell them that with a comment. Do you really think there is even a single programmer on the planet that think it is easier to understand your programs because you put in lots of redundant unnesseceary casts?

    Good for you. That's a matter of style. The program is not more or less beautiful or elegant because of it.

    Beautyful? Yes, Elegant? No

  • Probably one of the most groundbreaking graphics engines ever. Examining the code is like watching John Caramack think. Beautiful, Beautiful, Beautiful...!
  • If you want an example of a sweet-ass API you should check out the PGPSDK, that's just amazing. They some how managed to make a polymophic object orientated system in pure C (or course, it probably can't be extended as easily as it could be if it were C++ or java, but still).

    Really, really easy to work with.

    Amber Yuan 2k A.D
  • What's your point, exactly? Human may not be designed to think in reverse polish and to do recursion, indeed. However, humans were also designed for hunting and polygamy. They were also obviously not designed for using computer, otherwise they should have a hand with 105 fingers and another one with 3 or so.

    That thing we humans arogantly call "progress" has always been achieved by forgetting the straightforward applications of our "design" and by using our abstraction capabilities to accomplish unobvious activities. Functional programming is no exception. And it gave us Emacs.
  • So? I'm afraid I don't get it.
  • subl $8,%esp
    addl $-4,%esp

    You cheated! This code was produced by gcc with slight modifications to remove the obvious compiler generated names and directives. No beautiful hand-coded asm program can have those two lines next to each other in the source.

  • >

    > elegant c code.

    > here is my favourite gem:

    > printf("%d file%s copied\n", n, &["s"](n==1));

    Elegant ? The one that coded that did not know C.

    A less obfuscated way to get the same result is:

    printf( "%d file%s copied\n", n, "s"+(n==1) );

    Anyway, this is too a bad idea, as those constructs are not localisable. You'd better aim at something like:

    if (n==0)
    printf( LOCALIZE( "No filed copied" ) );
    else if (n==1)
    printf( LOCALIZE( "1 file copied" ) );
    printf( LOCALIZE( "%d files copied" ), n );

    for whatever definition of LOCALIZE you happend to have.

    Longer, more boring, but definitely nicer code.



  • This is the original Duff device (in pre-ANSI C). A gem, that the ANSI comitee carefully looked at and declared valid.

    Take a look at how the loop unrolling is performed. See how the loop is misplaced between the first and second case label. This is beautifull, because it have been a creative act to even think that the compiler could grok it.

    send(to, from, count)
    register short *to, *from;
    register count;
    register n=(count+7)/8;
    case 0: do{ *to = *from++;
    case 7: *to = *from++;
    case 6: *to = *from++;
    case 5: *to = *from++;
    case 4: *to = *from++;
    case 3: *to = *from++;
    case 2: *to = *from++;
    case 1: *to = *from++;
    } while(--n>0);

    See author comments at:

    (But clearly, I would not want that in production code)

    Btw, what I call beautifull code is crystal clear code. The first ncsa httpd was of that kind (imho). Anyway, beautifull code matters much less than beautifull _interfaces_.


  • by f5426 (144654) on Thursday January 25, 2001 @04:30AM (#483224)
    > I`d have used a case statement, instead of the if..else if business!

    Actaully, I first wrote it with an added if (n<0) { /* Error handling case */ } that cannot be dealt nicely in a switch. Then I removed the error test, because I felt it was pedantic to post it that way (more precisely, in real world, I would expect an "assert( n>=0 )" before the if/else)

    Btw, I generally avoid the switches because it is sometimes difficult to add new entries (it is not difficult, but it is error prone in the case where you need 'n<0', 'n==0', 'n==1' and 'n>=2', because you have to turn the whole switch into an if-else. I learnt the hard way to minimize changes to working code). Also, switches fails on non-integral types, so you need to master two idioms (one for the integral types, one for the floating point or function call decision tree, etc, etc)

    The less idioms I use, the less bugs I make, so I now only use switches when the tested value is an enumeration (because it never needs to be changed into an if/else), and where the default case is error handling or not used (so if I extend the enumeration I'll get either a warning or a run-time error, not a software that silently do something unexpected).

    It is a question of style, and you may feel better with a switch in that case.


  • Bzzzt....wrong. I've worked on more examples of god-awful COBOL code than I care to count. Crap code comes from laziness, incompetence and lack of thought about the future - the Y2K bug is an excellent example (although other platforms had their share). Good code comes from talent and I've seen plenty of well-written, and easy to mod code as well.
  • Deja vu indeed. That was the very first Slashdot article I read, when I used AOL, I thought Microsoft were merely incompetent and I had only vaguely heard of Linux. Now I wouldn't touch AOL with a bargepole, I despise MS and Linux is an interesting hobby.
  • This is a big problem for me, too. The major problem is that they tend to put the various kinds in with the food they are meant to flavor, instead of grouping them all together in a single aisles. So it is really a matter of personal preference.

    But I would suggest going over to the Mexican food aisle, because I find Tobasco to be very beautifully tasting...
    Espera un minuto...
    OH...Source, you are looking for source then! Well, never mind.

  • Here is my essay [] on this topic (which slashdot declined to publish a couple months ago).

    Chuck []
  • I had to amend one of the lesser sound card drivers to work with my card. The code for the driver was a mess, mainly due to the number of IFDEFs for different card sub-types, and little in the form of comments.

    But the worse code I saw was the UMDOS FS prior to 2.2. I needed to run this driver for an obscure reason, and attempted to try this with the 2.1 kernel. It didn't work, and I looked at the code. A mess of unexplained comments and error messages, most derived from abbreviations in a language other than English spoken by one of the original authors. No wonder it took the new maintainer over a year to get it working again.

  • Try this:

    .string "Hello, world!\n"

    .global main
    .type main,@function
    pushl $14
    pushl $msg
    pushl $1
    call write
    addl $12, %esp
    movl $0, %eax

    You see, there's no *need* to save and restore ebp if you're nice to the stack. Additionally, you could use a linux system call (via int 0x80) instead of calling libc's write function, but the use of main kind of ties us into a C infrastructure anyways and that would just break compatability on other x86 Unices.
  • The home page for polyglot is: []

    "A long time ago (1990) some people were talking about polyglot programs in rec.puzzles, these are programs that are written in several languages. We thought this sounded like fun so we wrote this [] one."

    We think it contains some pretty cool code, and most people still haven't found the hidden gems! There are two superfluous characters in the whole file (not including those used for formatting). Can anyone identify them?

    It still seems to work on most modern platforms.

    "Keep the blank lines, they are important"
    Cheers, Peter

  • by garett_spencley (193892) on Wednesday January 24, 2001 @06:29PM (#483256) Journal
    How about:

    .string "Hello, world!\n"

    .globl main

    pushl %ebp
    movl %esp,%ebp
    subl $8,%esp
    addl $-4,%esp
    pushl $14
    pushl $msg
    pushl $1
    call write
    addl $16,%esp
    xorl %eax,%eax
    jmp return

    movl %ebp,%esp
    popl %ebp


    I know it's not indented... I tried... Darn html.. Oh well...


  • by sv0f (197289) on Wednesday January 24, 2001 @07:29PM (#483258)
    Beautiful code is a subject worth contemplating, not speeding by with the standard crap answers above. Here are two quite-different places to find beautiful code:

    (1) The "Programming Pearls" books by Bentley.
    (2) "On Lisp" by Paul Graham

    Also, Here are some quotes of relevance:

    The [benefit] which rhyme has over blank, that it bounds and circumscribes the fancy. For imagination in a poet is a faculty so wild and lawless, that, like an high-ranging spaniel, it must have clogs tied to it, lest it outrun the judgment. -- John Dryden

    The central task of a natural science is to make the wonderful commonplace: to show that complexity, correctly viewed, is only a mask for simplicity; to find pattern hidden in apparent chaos. - Herb Simon

    The mathematician's patterns, like the painter's or poet's, must be beautiful; the ideas, like the colours or the words, must fit together in a harmonious way. Beauty is the first test; there is no permanent place in the world for ugly mathematics...It may be very hard to define mathematical beauty, but that is just as true of beauty of any kind -- we may not know quite what we mean by a beautiful poem, but that does not prevent is from recognizing one when we read it. -- G. H. Hardy

    Joseph LaGrange..."believed that a mathematician has not thoroughly understood his own work till he has made it so clear that he can go out and explain it effectively to the first man he meets on the street." -- E. T. Bell

    When judging a physical theory, I ask myself wether I would have made the Universe in that way had I been God. -- Einstein

    Beauty is the proper conforminty of the parts to one another and to the whole. - Hesienberg

    There is no excellent beauty that hath not some strangeness in the proportion! - Francis Bacon

    Simplex sigillum veri - The simple is the seal of the true. And Pulchritudo splendor veritatis - Beauty is the splendour of truth. - S. Chandrasekhar

    The Scientist does not study nature because it is useful to do so. He studies it because he takes pleasure in it; and he takes pleasure in it because it is beautiful. If nature were not beautiful, it would not be worth knowing and life would not be worth living... I mean the intimate beauty which comes from the harmonious order of its parts. -- Poincare

    My work always tried to unite the true with the beautiful; but when I had to choose one or another, I usually chose the beautiful. -- Hermann Weyl

    Beauty is truth, truth beauty - that is all Ye know on earth, And all ye need to know. -- Keats

    There are some great men of science whose charm consists in having said the first word on a subject, in having introduced some new idea which has proved fruitful; there are others whose charm consists perhaps in having said the last word on a subject, and who have reduced the subject to logical consistency and clearness. -- J. J. Thomson

    Do you know we're sitting on 4 million pounds of fuel, one nuclear weapon, and a thing that has 270,000 moving parts built by the lowest bidder? Makes you feel good, doesn't it? -- Steve Buscemi ("Rockhound") in "Armageddon."
  • Take a look at "Lions' Commentary on UNIX 6th Edition" by John Lions. It's an older text, but it's beautifully coded. Although this is a great text for OS programming, if not the standard, it can also server as a good reference for style and design. It's written by the guy that invented C, so you know it's going to be good. :)

  • Nope, session timeouts sure didn't, the way I discovered it was when someone's url showed up in my logs. I went to it and got right in.

    The fact it's fixed doesn't matter to me though: if they missed something THIS basic, what else are they missing?


  • by happystink (204158) on Wednesday January 24, 2001 @06:15PM (#483270)
    wow, they must have really cleaned it up from a few months ago then, cause back then it had a security flaw so super-basic that it showed that they didn't really understand a single thing about web security, and I decided at that point to never use it, who knows what else they were forgetting. (the flaw was that if someone clicked a link on an incoming message, and the url of that message got passed to your referrer log, you could go to that url and you'd be intheir mail, with full access to their mailbox. The worst example of session-tracking I have ever seen).


  • by TheVet (205479) on Wednesday January 24, 2001 @07:27PM (#483272) Homepage
    From the Jargon Files: Mel's full name is Mel Kaye. He is refered to in the LGP-30 manual as "Mel Kaye of Royal McBee who did the bulk of the programming [...] of the ACT 1 system".
  • by blamario (227479) on Wednesday January 24, 2001 @06:14PM (#483285)
    Gosh, this is really a hard question as you can see from the apparent lack of enthusiastic answers. If only you asked where can you find BAD, AWFUL code I can guarantee there would be a lot more links. I mean, there are movements devoted to producing as bad code as possible. Take a look at Obfuscated C Code Contest []. You can learn from negative examples as well, and they are much easier to find.
  • by slugo (243955) on Wednesday January 24, 2001 @06:11PM (#483294) I had fun intalling this on freebsd and getting it to run. You can open the code and make mods to the mud and enjoy playing your mods. Apply the patches from the ftp site. Others can come in and enjoy your mods. I learned alot about C programming from modifying this software and had fun playing with the mods I created. For instance, mod the software to have Puff roam around town instead of hanging out in Limbo. RO mud did this. Is it still around?
  • by eulevik (258261) on Wednesday January 24, 2001 @06:11PM (#483301)
    The source code to id software's doom and quake is the nicest real-world code that I have seen. Knuth's TeX, especially in book form, is also worthwhile.
  • I'm inclined to disagree. Code can be an art form, and if you dont agree you probably arn't a programmer. I wish I could write code decent enough to post under the 'beautiful' subject here, and I would tend to respect those who can...

Simplicity does not precede complexity, but follows it.