Ask HN: What are some examples of beautiful software?
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 ] threadWhat 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.
Beautiful software: Java Virtual Machine (the code? could be entirely un-beautiful ;)
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...)
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.
The interface between the physical world and the digital world. They are the lenses of computers as much as its magic.
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).
Apparently it was hard if it took that long to get a great, clean, FOSS solution to the problem.
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.
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).
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.
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.
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)
http://www.azulsystems.com/products/vega/processor
http://www.aosabook.org/en/index.html
Making a document description language purposefully turing complete is an offence that should be punishable by lashes with a fiberoptic cable.
edit: other comments seem to be from a source code perspective ?
The same can be said of the PostgreSQL source.
If you mean code, Smalltalk or LISP
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 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.
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.
Mike Pall is a demigod.
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.
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.
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.
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.
POSER 4 seems like the most beautiful app.
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.
[1]: http://www.cse.unsw.edu.au/~billw/cs9414/notes/prolog/path-t...
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.
- 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
fibs = 0 : 1 : zipWith (+) fibs (tail fibs)
It's nifty, but not an especially beautiful use of Haskell.
Okasaki's Red-Black Trees rendered in Haskell are nicer, for example.