Ask HN: What are some examples of beautiful software?

345 points by ponderatul ↗ HN
So I've been reading Paul Graham's - Hackers and Painters. A bit late, I know. And I find his ideas fascinating. One that struck a chord with me, was the idea of taste, recognising good taste. I'd like to know examples of beautiful software and what makes it beautiful.

261 comments

[ 3.2 ms ] story [ 371 ms ] thread
Personally, I like Tarsnap and anything from the OpenBSD project. Of course, this is highly subjective, and I would not call the code 'beautiful'. However, to me, these are a few examples of code performing complex tasks written in a simple, straight-forward way that I can follow and understand.
If you like the Tarsnap code, you should read the spiped code. Tarsnap is made ugly in places by needing to work with/around the original tar code it's based on; spiped is code entirely written by me.
The most beautiful I'm aware of is Robert Strandh's SICL (https://github.com/robert-strandh/SICL). CL-PPCRE (https://github.com/edicl/cl-ppcre) is very nice as well, imo.

What makes them beautiful? They're very straight forward and clearly communicate what they're doing, and how.

And the parentheses in their language of choice softens the visual display of the code -- while the semantics of the language cause the shape of the code to communicate quite a bit about how the machine will go about executing it.

There are no surprises.

In terms of conceptual beauty, it'd be hard to beat Screamer (https://github.com/nikodemus/screamer).

What makes this beautiful? The way it makes a hairy problem seem simple and straight-forward.

wow, sicl really is a beautiful project. thanks for the pointer.
Redis is my favorite example. It's some of the easiest to read, digest, and modify source code out there.
antirez as Italian Renaissance code painter?
Beautiful software =/= beautiful code.

Beautiful software: Java Virtual Machine (the code? could be entirely un-beautiful ;)

I'm genuinely puzzled. What can be beautiful anywhere in the JVM?!?
Hot loop replacement? Dynamic devirtualization and revirtualization?
It's enterprise beautiful.
It's a really clean abstraction of a computing environment, which is as well defined and predicatable that is possible.

I tend to prefer that to performance cludges, arcane architectural hand waving, and undefined behaviour.

Some people thinks it's useless, since they do no see the benefits, as there are costs.

(There are some obvious UX-flaws, especially on the desktop, where it takes a bit to start up, and clearly failes to define a jxe file-extension for executable jars... Not to mention all the enterprise-level shit that goes on...)

> It's a really clean abstraction of a computing environment

No, it's a clumsy and leaky abstraction which was not well thought out. P-codes are a nice abstraction. AS/400 is a nice abstrction. Dozens of other, better VMs are a nice abstraction. But not a JVM, which is broken by design.

I'd never chose it as an underlying VM for anything important.

You forgot about Squeak. Now THAT is a brilliant abstraction. Provided you don't touch the outside OS, you can copy an image, bit-for-bit, to another computer that runs the Squeak VM, and it'll just work.
In terms of source code? If so my favourites to read are: LLVM and Clang. Redis. TensorFlow. Doom. Sha256k (the one Bitcoin core uses).
Drivers.

The interface between the physical world and the digital world. They are the lenses of computers as much as its magic.

The code for most drivers however, is less than beautiful. And I'd argue that it's controller firmware that is the "real" bridge between the analogue and digital.
All of the btcsuite code (btcd, btcwallet, ...)
Varnish cache.

1) Configured via a special DSL (Varnish Configuration language) that gets translated into C, compiled and loaded into the Varnish process via a .so. Perfect combination of expressiveness and speed. You can even inline raw C code in it!

2) Heavy, good use of virtual memory. Varnish allocates quite a lot of gigabytes and leaves it up to the operating system to decide what should be in RAM and what should be on disk.

3) LRU garbage collection of cached objects requires a synchronized priority queue. Varnish people transformed the decades old idea of implementing a heap in an array that every CS graduate knows and came up with a faster, paging-aware solution (http://queue.acm.org/detail.cfm?id=1814327).

Nice, but they are solving a problem that is not all that hard. For example, I'd rather see a beautiful implementation of a concurrent garbage collector (which probably doesn't exist because it is almost impossible to achieve; a purely functional programming approach doesn't even apply here). Or how about a beautiful implementation of a web browser?
"Nice, but they are solving a problem that is not all that hard."

Apparently it was hard if it took that long to get a great, clean, FOSS solution to the problem.

Well, in any case, I've never heard of a government software project being overdue because their proxy cache contained spaghetti code :)

To be clear, I'm not trying to denigrate this project in any way. I'm just saying that the complexity of the problem should be taken into account here.

I think the complexity of the problem actually speaks in favour of Varnish. The Unix philosophy of writing software is based on the principle of doing one, possibly small thing very well. And that's exactly what Varnish does: it is a reverse-proxy cache that can optionally do a bit of preprocessing on the incoming HTTP requests.

Besides, it's not trivial to write a high performance HTTP cache.

> Besides, it's not trivial to write a high performance HTTP cache.

Certainly true.

I guess that for me "beautiful code" invents some abstractions that transform a problem that initially seems dauntingly difficult into something that is easy to reason about. A proxy cache does not, for me, satisfy the first part of this premise, although I can imagine that the details of such a project take a lot of effort (hence "not trivial", but in a different way).

>I guess that for me "beautiful code" invents some abstractions that transform a problem that initially seems dauntingly difficult into something that is easy to reason about.

Well then, look no further than any RDBMS.

Seriously, for as much as people sometimes rag on the relation model, it is amazing for its power and relative simplicity.

The complexity of the problem is significant enough that there's only two verified HTTP servers I recall and a specifying/verifying a web app was considered good work. The bugs, inconsistent perfirmance, and CVE's in various caches also suggests they're not dead simple.

They're certainly easier to write than a lot of software. Their simplicity is deceptive, though, when real-world isdues come into play. Esp if result is to be beautiful.

Maybe this will change your opinion. I recalling helping rescue a government software project that was horribly behind schedule. One of the many issues being an e-learning system for a state department of education. Their CMS (Blackboard) was fronted by a forward HTTP proxy/cache/load-balancer that was misbehaving but near-impossible to debug. Details a bit hazy now but I recall it being a hairball of poorly written java. I ripped that out and replaced it with Squid and some rewrite code.

HTTP intermediate services are easy to write, but operate in a hostile and chaotic environment; they are very very hard to make reliable, performant, interoperable, secure, forgiving, and compliant. To achieve that and still have elegant code is really something so yay Varnish.

I'm a bit of a fan of the Dovecot mail server source for similar reasons (but I'm biased, having made a small contribution and got into the authors file)

Nice. I'm pretty sure that for any "a government software project being overdue because X", there is such an X... and someone on HN was there.
The government should stop hiring HN programmers, that's clearly the problem!
Concurrent garbage collectors exist. It's nothing new or special. The problem is you need read barriers which means your garbage collector ends up slowing your entire programm significantly down. For some reason Intel and AMD decided it's not worth it to add hardware acceleration for read and write barriers so end up paying a lot of $ for custom designed processors from Azul if you truly need a concurrent garbage collector.

http://www.azulsystems.com/products/vega/processor

Surprised that no one mentioned elasticsearch here. The Java code is truly one of the best I have seen in any large open source Java project.
Maybe they should put that effort into their documentation ;)
Knuth's TeX. Set the standards for documentation, reliability, portability, typography, extensibility and scripting, is well into its fourth decade and is free software.
And after those four decades, I still can't figure out how to get my figures to appear where I want them.
The trick is deciding to want them wherever tex puts them.
In this way commences typographical wisdom.
Yeah, but no.

Making a document description language purposefully turing complete is an offence that should be punishable by lashes with a fiberoptic cable.

daisydisk. oh it's smooth, harmonious colours, quintessential

edit: other comments seem to be from a source code perspective ?

Say what you like about Rails (or Ruby for that matter), but go and look at its source. It is well laid out, the commenting is extensive and descriptive, and it follows a natural flow.

The same can be said of the PostgreSQL source.

If you mean applications, Adobe Illustrator

If you mean code, Smalltalk or LISP

The Go standard library. At least two things coming together: A stripped down language, that explicitly aims to be readable and experienced programmers / authors.
I'm not sure I agree with that. JSON parsing uses panic() and recover() for some logic. And templating is more of a PoC for coroutines in Go than a properly fleshed out library. Not to mention that the AST parsing for Go is horribly designed (though you can do some cool stuff with it).
I guess, the library authors needed to learn Go themselves as they build up the stdlib.
Even if you don't think the code itself is very nice, the API is pretty well-designed.
> And templating is more of a PoC for coroutines in Go than a properly fleshed out library.

I worked with Rob on that library and that's really not the case. It was designed from the ground up to replace the existing template library which was bad in several ways. The parser (which is I think what you refer to) is just an implementation detail.

> I worked with Rob on that library and that's really not the case. It was designed from the ground up to replace the existing template library which was bad in several ways. The parser (which is I think what you refer to) is just an implementation detail.

Right, but why can't I call define custom operators? And why is there no bracketing in conditionals? It just feels clunky to me (but maybe I'm too spoiled with Jinja2). I still feel like you could allow execution of functions passed in the data argument (as long as the developer doesn't shoot themselves in the foot, it shouldn't be a security problem).

It's stuff like that which makes me feel like it was a PoC (or at least, not designed to be feature-complete). Still, it works pretty well for plenty of usecases (I use to generate config files every once in a while).

> I still feel like you could allow execution of functions passed in the data argument

I don't recally anyone asking for this before. File an issue? https://golang.org/issue/new

> It's stuff like that which makes me feel like it was a PoC (or at least, not designed to be feature-complete).

It's designed to be a useful template engine. I don't know about "feature complete", but we are still improving it. If you find it lacking then please file issues so that we can think about improving it.

Seconded. I'm not sure if this is common for other languages, but I use the Go stdlib as a reference for what good Go code should look like. And reading it often reveals little language tricks that I wasn't aware of.

Example: The Sum method of the hash.Hash interface takes a byte slice as an argument, and appends the hash to it. Why not take zero arguments and simply return a new slice? Because the authors recognized that if you're doing hashing, you probably care about performance. Appending to a supplied slice allows you to save an allocation.

The stdlib is full of little details like that, and it adds up to a really great programming experience. Go may be lacking in some respects, but it has Good Design stamped all over it.

LuaJIT. It's a cutting-edge JIT with remarkably understandable algorithms and source. Every single piece of it is well thought out. Even the asm interpreters are pretty clean and explain why they work the way they do.

Mike Pall is a demigod.

the lua vm to, the code is so small but works so well.
LuaJIT is, indeed, a genius masterwork, but it's also very intricate and complex. I'm not entirely sure anyone other than Mike Pall could understand it completely.

On the other hand Lua (The Original™) is also a beautiful bit of programming, and much more approachable. If you've ever wondered what it means when people talk about "Stack-based VMs", reading through the Lua source is an excellent way to learn more.

But... Lua is a register-based VM since like Lua 5.

Not disputing that Rio Lua is also an excellent work though. Lua 5.1 only has 38 opcodes total. A complete description of how the VM works fits on a page or so.

D'oh, my mistake. The VM is, indeed, register-based. The C API is stack-based. But yes, a very lovely bit of code all together.
Not sure if this is what you're looking for, but from the UX side, Square Cash.

Does one thing, does it well with large responsive colorful UI that still displays everything you need to know. Is minimally invasive (debit card instead of bank account verification). Uses your existing contacts, so everything "just works" by default.

Not looking for anything specifically, I'm just a junior developer and mostly in javascript. I'm just looking for traits, common elements or approaches to beautiful software. So thank you for sharing :D.
TeX and Metafont. It'd be hard to find anything even matching these gems.
Grand central dispatch is so beautifully designed. Both its API and just general use. It clicked with me the first time it got introduced and I abandoned bothering with NSOperarion
I like NSOperation. Basically because I find it nice to encapsulate tasks that are to run in another thread in their own class. Not always, of course, but if they are "long enough", I think they should stand on their own.
It's funny to read what people think are beautiful apps here.

IMHO, the most beautiful software are always games and entertainment titles... After all that is the purpose.

Office 2013? It's very useful! I use a classic menu template and got rid of the ribbon, since the functionality is the same, but in my preferred format. Beauty does not come into play with office...

I can use it for creating beautiful PowerPoint and excel spreadsheets.

Code is never 'beautiful'. It's either concise, well-written and formatted well, or it isn't.

I've evaluated what I have used over the years...

POSER 4 seems like the most beautiful app.

> Code is never 'beautiful'. It's either concise, well-written and formatted well, or it isn't.

This is not true. You may not value beauty as a characteristic of code, but there are people who do.

Also, you could say the same thing about novels. "concise, well-written and formatted well" are features of most published novels; does it mean they all are the same in terms of beauty?

Beauty is inherently subjective and relative. Personally, I find the code which form and function fit together pretty. It's the same kind of beauty I feel when reading poems. You're free to ignore such things, of course, but saying that the code can never be pretty is actually quite a bit rude to some people.

In my opinion it depends on the type of code. It's unlikely to find beauty in a run-of-the-mill CRUD app; it can be nice and neat at best. Beautiful code is possible when there's creativity involved - there should be some conceptual originality to the code in question. Of course it's not physically impossible to bury some brilliancy in a bank transaction processing script, it's just a less probable place to find one.
Turbo Pascal for DOS. Simple, compact, quick, well documented, reasonably easy to learn, and not too expensive.

I think that bloat is the enemy of beauty, so we're probably likely to find beauty in software that does a few things well.

Related:

- Things That Turbo Pascal is Smaller Than: http://prog21.dadgum.com/116.html

- A Personal History of Compilation Speed, Part 2: http://prog21.dadgum.com/47.html

Turbo Pascal 5 got me into programming. I wish people would build smaller things again.
Remember punching in 4 pages of Pascal from a PC Magazine in early 90s. I had no idea about anything, syntax, semantics... it was long and painful.
I also learned to properly program using Turbo Pascal. You might enjoy Go. I find its small language, library, and tools that I can keep in my head leave me feeling similar to how I felt using Turbo Pascal back in the day.
Or perhaps Nim: http://howistart.org/posts/nim/1 (That article btw, is itself an example of beautiful software. So short and sweet, and still manage to cover a pretty deep rabbit hole of computer science and plain fun, with it's mandelbrot-in-brainfuck-in-nim)
My personal favorite thing about TP:

  begin
    asm
      mov ax, 10h
      ...
I didn't go quite that far, but I did some insane stuff using the built-in i/o port access and the parallel printer port.
Not specifically "software" but this piece of Haskell code is the most beautiful code I've ever seen:

    quicksort [] = []
    quicksort (x:xs) = quicksort [y|y<-xs,y<x] ++ [x] ++ quicksort [y|y<-xs,y>=x]
The recursive Fibonacci definition in Haskell is far more beautiful IMO. But there's always more beautiful one-line snippets (like the regex that can tell you if a number is prime).

fibs = 0 : 1 : zipWith (+) fibs (tail fibs)

Will you still think that when you realize it isn't actually a quicksort?
It's tree sort. It does the same comparisons as quicksort, but organizes its data differently.

It's nifty, but not an especially beautiful use of Haskell.

Okasaki's Red-Black Trees rendered in Haskell are nicer, for example.