Ruby: anything written by _why (if you can find the source) He once gave a whole presentation on the splat operator and it's bizarre uses that gave me goosebumps. A true artist. The code twists and contorts ruby in unimaginable ways.
JS: anything written by TJ hollwaychuck (express, mocha, etc...) Express is so simple but powerful, when you read the source you can't help but wonder where the rest of the code is.
Python: anything written by Kenneth Reitz (Requests, legit, records...) This guy can lay down some serious Python and gets things done. He writes the batteries that python should have had included.
[1] https://en.wikipedia.org/wiki/The_Garden_of_Earthly_Delights [2] http://www.imdb.com/title/tt3235888/
Also these people didn't become "famous" for their Instagram selfies.
The first file I opened has 3 gotos but maybe it's pure randomness... ;p
void foo() {
int* foo = malloc(...)
if (foo == NULL) goto err_foo;
int* bar = malloc(...)
if (bar == NULL) goto err_bar;
/* code */
err_bar:
free(bar);
err_foo:
free(foo);
}
"The free function causes the space pointed to by ptr to be deallocated, that is, made available for further allocation. If ptr is a null pointer, no action occurs."
Beautiful APIs and clean code. It is easy to contribute to their projects.
Not directly code, but the "Beyond pep 8" talk at PyCon 2015 by Raymond Hettinger is quite nice (https://www.youtube.com/watch?v=wf-BqAjZb8M). It gives interesting tips on how to separate "business logic" (the high level problem you try to solve) from the "purely technical stuff".
Does "beautiful" means "the code is clean"? If so, the Quake source code is "beautiful", while Duke3D Build engine is "ugly".
Does "beaufitul" means "the code is clever"? If so, gcc, ffmpeg and ODE are "beautiful", and Google's Ninja is "tasteless".
Does "beautiful" means "the code is modular" (I mean "open-closed" here)? If so, VLC is "beautiful", and everything monolithic is "ugly" (gcc, Linux, systemd, LLVM, ...).
Does "beautiful" means "the software performs flawlessly"? If so, the Duke3D Build engine, Quake's engine, and Portal's physics engine are "beautiful", while VLC is "ugly".
Does "beautiful" means "the software embodies a clever concept"? If so, "grep" and "xargs" are "beautiful", and the Windows Batch interpreter is "ugly".
Does "beautiful" means "the software is easy to use"? If so, the Windows calculator is "beautiful", while Mathematica and vim are "ugly".
Does "beautiful" means "the software can be twisted in lots of interesting ways"? If so, dynamic language interpreters are "beautiful", while static language compilers are "ugly".
My point is, any piece of software can be seen as "beautiful" or "ugly".
We have meaningful objective attributes at our disposal, like "simple", "clever", "fit", "robust", "fast", "small", "user friendly"... let's use them!
> ... and what makes it beautiful.
makes this clear. It's a subjective question deliberately looking to elicit subjective answers, with the point of interest being the individual justifications behind those answers.
However, despite my disagreement with your sentiment (calling for a more objective question), you did actually answer the question as well. Thanks for the list.
Paul Graham says in Hacker's and Painters that “... If there is such a thing as beauty, we need to be able to recognize it. We need good taste to make good things. Instead of treating beauty as an airy abstraction, to be either blathered about or avoided depending on how one feels about airy abstractions, let's try considering it as a practical question: how do you make good stuff?”
So I'm really looking for patterns here. 'Clean code' seems to be a characteristic of beautiful software. Another one seems to be ' code is clever ' from what I see.
That's all I'm doing here, finding some patterns. So if I would've asked what are some example of beautiful software ( where beautiful means 'clean code') I might've gotten a more focused set of responses, but then I would've missed out on the other dimensions of beautiful.
Beautiful software should solve a problem. It should fit in like a cog to empower humans to do lot more things or do things which were harder to do before.
Beautiful software includes a lot more things than just code or how code is written.
You'd be surprised what people do to static language compilers. C++'s template are turing complete, after all.
To be honest the time I did that it actually helped, which I guess goes to show how elegant C++ templates aren't....
Edit: Grammar.
It can be something that makes you calm, angry, disgusted. The more so, the better. Javascript and Windows are great examples of this.
Almost always you'd sit there and wonder why anyone would go to the lengths to build this. Lengths can mean that they went to the effort of simplifying a complicated thing or even making a complicated thing absurdly complicated.
E.g. I see beauty in the Sydney Opera House, not only because of its form, but because they managed to build a grand opera house in one of the least culturally sophisticated cities in the world. There's just something completely out of place about the Sydney Opera House and that's what makes it so beautiful. Most people think the characteristic roof symbolizes sails, but it's actually an orange peel. It's like a clever prank.
When you go back to the Hackers and Painters essay - PG tries to associate the two together. Beautiful hacks are like shortcuts that work. Almost always a great hack does something dumb, but is very effective.
The game itself has an amazingly beautiful vector style. The engine is remarkably tiny, 20kb. I decided years ago if I ever find time to build a game I'd like to architect it like "Another World".
I agree the quality of SQLite is very high, but is it just devotion to details or aesthetic?
"Valgrind is perhaps the most amazing and useful developer tool in the world. Valgrind is a simulator - it simulates an x86 running a Linux binary. (Ports of Valgrind for platforms other than Linux are in development, but as of this writing, Valgrind only works reliably on Linux, which in the opinion of the SQLite developers means that Linux should be the preferred platform for all software development.) As Valgrind runs a Linux binary, it looks for all kinds of interesting errors such as array overruns, reading from uninitialized memory, stack overflows, memory leaks, and so forth. Valgrind finds problems that can easily slip through all of the other tests run against SQLite. And, when Valgrind does find an error, it can dump the developer directly into a symbolic debugger at the exact point where the error occur, to facilitate a quick fix." [1] https://www.sqlite.org/testing.html
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)
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.
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
begin
asm
mov ax, 10h
...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.
The idea of collapsing a volume manager and file system into one was very innovative and led to substantially more functionality with less code (although some called it a "rampant layering violation" ).
ZFS is a joy to use, dead simple, and arguably the most robust file system out there.
https://sites.google.com/a/deepmind.com/dqn/
If you haven't seen the video it's remarkable:
There's also a great snippet in the currently-ongoing AlphaGo videos that explains that when AlphaGo plays in ways that you may not expect, it's because it's strictly worried about _winning_ (even by the slimmest margin) with the greatest probability, and not necessarily by winning handily, like a human might.
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.
At the time I had never heard of Binary Space Partition Trees. Beautiful concept for a monument of a game.
http://fabiensanglard.net/doomIphone/doomClassicRenderer.php
It's very rare in a programming language that I can click through to the implementation of a function and actually understand the code I get through the wall of error checking and coercion and OOP gobbledygook to even make sense of what I'm looking at.
But I've never had this problem in Haskell or Clojure. Haskell because that awesome type system makes most of that boilerplate unnecessary, and Clojure because for good or ill, the priority seems to be on clarity of code and letting the Java type system kind of catch a lot of the obvious errors.
Racket, on the other hand, much as I love it, when I go looking at it's internals most of the time it's practically unintelligible to me.
This is one of the reasons Racket never appealed to me. R5RS and R7RS are so simple that you can write most of the interpreter in about a page of code in the language. Although if you read SICP, you already know that :-).
Racket and R6RS, OTOH, are full to the brim with complex systems that all interact in a manner that's hard to wrap your head around. Custodians, Contracts, OOP, Delimited Continuations, all there by default... It's just too much. I also dislike syntax-case, but that's more of a personal issue than anything else.
I'd even prefer Common Lisp. Sure, it's about the same size at least, but it's not trying to make you use 5 paradigms at once. Sure, you COULD, but you don't HAVE to. But then, I suppose that is what lisp is about.
The way it displays and organizes complex data, better than other standards like CSV or XML. Or the things that use tables.
When I first started programming, I had two favorite ways of storing data - INI and arrays. INI for its elegant key/value style. Arrays were just natural because of the way computers think.
I spent months trying to mold these two things together; how would you actually store key-value things within an array? Do you make an array of pointers that lead to key-value objects? (I used C)
JSON is just this beautiful thing that lets you store data however you want. It's beautiful because it doesn't get in the way. Not only that, but it's a data structure you can understand just by looking at it; you'd have to squint to understand raw XML or a SQL table.
On the other hand, it's readable, good enough for most tasks, not overly complex, and it's nicer than XML. That is not a small acomplishment.
Still... I am waiting for ASN.2 ... All good features and ideas from ASN.1 without everything bad, which is rather much too :-)
One good idea from ANS.1 is "criticality", how important a future extension to a protocol is, which means that older participants can still handle newer messages, if they contain no "critical" extensions.
Another good thing is that the encoding is detached from the schema representation, which is too good for people to appreciate. You can use the same schema to send XML, BER (original simple tag-value binary format), PER (no unneccesary bytes are sent), or plain strings. (No JSON yet - at least in the standard)
In that way, it's possible to select encoders that suits the mission. Send human-readable data when size/speed/consistency does not matter, and packed super efficient messages when sending from a space probe. Same schema.
ASN.1 is ugly as hell though, and clearly designed by committee.
What if I want to store integers?
Not floats.
Integers.
I don't know why you guys are having trouble with this. \s
> JSON.stringify(1)
"1"
What if you receive it in JS?
JSON.parse(JSON.stringify(1))
> 1
Regardless, you can still override anything it does considering the second argument to both `JSON.parse()` and `JSON.stringify()` allows you to provide your own function for handling the logic as you see fit.
JSON doesn't support integers for example on my 64bit system it can't support INT_MAX as a value and anything greater then 9007199254740993 might just come out as wrong.
It's absolutely valid JSON. What you're seeing happen is that the JavaScript language parses the Numeric Literal 9007199254740993 to a value of the Number type, and this value does not accurately represent the intended number. This is a feature of JavaScript, not JSON.
You can see the JSON spec here: http://json.org It does not talk about number size or type - simply that a number is a series of digits(and other symbols).
The JSON library for JavaScript has an inherent limitation when parsing JSON formatted numbers, because it tries to represent them as the Number type, and the Number type cannot represent large numbers. It is absolutely possible to write a JSON parsing library that parses JSON numbers into strings(example - http://php.net/manual/en/function.json-decode.php with the JSON_BIGINT_AS_STRING option). This does not change what kind of numbers JSON supports(any decimal).
I have had to configure various pieces of software in JSON and its a PITA (compared to doing the same sort of thing in Python, or most configuration files actually). Its picky about what quotes you use. Its picky about leaving trailing commas in arrays. Its not particularly readable (compared to YAML or XML). It only has one numerical type.
It's clearly explained code that's shorter than you would have thought. Norvig showcases his expertise in manipulating both the basic data structure of the Python language, and a deep understanding of the underlying problem and methods for solving it.
I'm not saying my code is particularly readable to anyone but me, but functional style is something that 'clicked' when I fell into it.
Making a document description language purposefully turing complete is an offence that should be punishable by lashes with a fiberoptic cable.
LLVM. Being able to fully represent general code in a simple, well-defined, readable text-based format is a far bigger achievement than you would think until you look at what it took to do it.
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.
In OpenGenera, everything displayed on the screen is typed and can be retrieved as an s-expression (like in a web browser):
I happened to dig into its source code for something and eventually found myself amazed at how the entire base is beautifully laid out. It's no nowhere near being naive. It's almost a simple programming language implemented in python. A compiler of sorts with its own abstract syntax tree and stuff. Yet the code is very readable, straight forward and just taught me how to write good python.
[edit] corrected typo.
Also, Jinja2 and Werkzeug aren't coupled - you can use practically any Python templating lib with it as Werkzeug is just a WSGI library (+ and of course something else..).
And they happen to share the author.
https://github.com/ztellman/aleph
https://github.com/ztellman/automat
In terms of his ideas, watch "Always be composing":
https://www.youtube.com/watch?v=3oQTSP4FngY
And he offers some great thoughts about queues and backpressure in "Everything will flow":
the ideas were stolen from the Wizards talk
http://ocw.mit.edu/courses/electrical-engineering-and-comput...
- Starts in a sec.
- API is the program, the GUI just an interface.
- Free but very professional
- Shortcuts are ergonomic.[1] Pentium 2 350 with a NV3 ~gpu.
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.
On the other hand, the ideas, algorithms, or the protocols on which software is based often seem beautiful, elegant, or brilliant, at least to me.
A few examples I can think of are: Google PageRank algorithm, Bitcoin's protocol and the block chain, the TCP network protocol, the BitTorrent protocol, Dijkstra’s algorithm, etc.
I respectfully disagree. Many of the elements of tcp are very complicated, and more or less of a hack. Compose them all together, and it's a hugely complex and arguably ugly (if utilitarian) standard.
RINA is a beautiful new redesign of the networking stack wherein "computer networking is just inter-process communication."
https://en.m.wikipedia.org/wiki/Recursive_InterNetwork_Archi...
[1]: http://www.cse.unsw.edu.au/~billw/cs9414/notes/prolog/path-t...
Amazing source.
https://github.com/Hypsurus/skod/blob/master/src/skod.c#L290
Also, at least some functions should be static.
_cla means "command line arguments", not obvious.
Useless comments: https://github.com/Hypsurus/skod/blob/master/src/skod.c#L273
All those MAX_STR and strcat's make me wonder about security: https://github.com/Hypsurus/skod/blob/master/src/ftp.c#L14
Amazing read: https://github.com/Hypsurus/skod/blob/master/src/ftp.c#L22
No enum again: https://github.com/Hypsurus/skod/blob/master/src/utils.c#L14
Even without much documentation, you can go through and read it while understanding what is happening.
quicksort [] = []
quicksort (x:xs) = quicksort [y|y<-xs,y<x] ++ [x] ++ quicksort [y|y<-xs,y>=x]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.
https://en.wikipedia.org/wiki/Hashlife
My implementations in Literate CoffeeScript:
And JavaScript:
(winner of the 20th International Obfuscated C Code Contest)
Nevertheless once you run it, you will have a sweet surprise.
Here is what the author said about it (and code in general):
"It’s an art form, like any other art form… I would spend time rewriting whole sections of code to make them more cleanly organized, more clear. I’m a firm believer that the best way to prevent bugs is to make it so that you can read through the code and understand exactly what it’s doing"
The same can be said of the PostgreSQL source.
[1]: http://www.fmod.org/ [2]: https://github.com/fmod/ue4integration/blob/master/FMODStudi...
http://www.eurogamer.net/articles/2016-03-03-a-big-interview...
and
Just read through the design, it's very simple and extremely modular. It learns the lessons from previous related systems and applies them in the new system.
Beautiful software should make simple things simple, and hard things possible. Git leans strongly toward the latter, to the detriment of the former.
I need version control software that's mostly like a shovel and maybe sometimes like a backhoe. Git is like one of these:
http://earthfirstjournal.org/newswire/wp-content/uploads/sit...
So far this is as much documentation I have needed. http://danielkummer.github.io/git-flow-cheatsheet/
0: http://lucumr.pocoo.org/2015/2/17/ui-and-hidden-consistency/
Take a look at the rasterizer, for example: http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree...
This book might help.
H&P is great, by the way. It was that book and "Cathedral & The Bazaar" that made me quit a Microsoft-only job and go open-source.
The interface between the physical world and the digital world. They are the lenses of computers as much as its magic.
It has every feature but takes 5 minutes to learn. And it (mostly) seems to do the most reasonable thing every time you do anything.
(plus: there is a working free model and a really useful paid upgrade.)
A tiny self-interpreting compiler and virtual machine. The beauty is in how amazingly minimal and yet functional it is.
http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-...
1. a. whitney 2. ioccc.org winners (djb, etc.)
what makes [some] software beautiful?
the ugliness of other software.
most software is large, slow, complicated and bug-ridden.
this makes small, fast, clean software written by competent programmers "beautiful".
taste varies. what is too terse and "obfuscated" to some is pleasingly succinct and manageable to others.
right now there's another post about yann lecun on the front page. he once wrote a lisp-like interpreter that compiles to C called "lush". of all the lisps i have tried i think it's one of the more "beautiful" ones in it's design.
edit: other comments seem to be from a source code perspective ?
If you mean code, Smalltalk or LISP
[0] https://github.com/baskerville/bspwm
[1] https://github.com/baskerville/sxhkdI think part of it has to do with the fact that sqlalchemy isn't by any means a small library and has a lot of elbow grease put into it.
It isn't some ornate stained glass window, it's bullet proof glass.
shameless fanboy here
Jumping right into IDE to solve a problem is a way to end up with bullshit, like to write down the contents of undeveloped and undisciplined mind.
"My code is my documentation", or auto-generated "documentation" is bullshit for the same reasons.
nginx/src/core/*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.