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.
C: anything by antirez (redis, etc...) Redis is the epitome of well written understandable C.
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.
I completely agree. It sounds like the opposite of beautiful software if you ask me. Maybe it's interesting, thought-provoking, or amusing code, but not beautiful.
Beauty comes in very different forms. Not all beautiful paintings are pleasing and peaceful fields for flowers; IMHO, something can be dark, strange, even scary, and still beautiful. E.g.: The Garden of Earthly Delights[1], or It Follows[2].
I found it beautiful because I had never thought to use the language in that way before I had seen him do it. It wasn't hard to understand once you understood. :-)
I think it's perhaps not inappropriate for Ruby; it has a community that's all about 'magic' and even 'tricky' beauty. I certainly agree there are problems with this, but I also see how this is appealing in certain contexts.
That's the one! The reason I fell in love with requests was because it was leagues better than python's own http lib. Pay attention to the way he designed he API, it's genius. Updated my comment.
TJ tends to jump mon on from one language to another.. first Ruby(when Ruby was the thing), then JS(when NodeJS became popular) and now Golang(the current "thing")
'jump' -- I doubt it was hasty. Languages have issues, why stick with one when there are plenty to choose from. Of course, I like Golang, so somewhat biased -- it just appeals to my sensibilities, perhaps it does for TJ as well.
I've not used it in recent years, but PolarSSL (now mbed TLS) was quite nice for a crypto library. It's a light, simple and clear C library.
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".
I think that list is more of an answer to the question "What are some examples of widely-used FOSS projects created by famous programmers" than it is an answer to OP's question about beautiful software.
Sorry to be a stickler, but the error handling in your method "frees" a resource even when nothing was allocated to it. Freeing a null pointer is as such an undefined behavior.
"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."
I'm seeing a lot of meanings to "beautiful" here, please, let's define what we're talking about.
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!
> 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".
You'd be surprised what people do to static language compilers. C++'s template are turing complete, after all.
Yes. I mentioned C++ templates, because I don't want to only talk about Haskell. (People make ghc do interesting things, too. And some of them are even not-so-ugly.)
I completely agree with wingerlang here, and I think the fact that the OP ends with
> ... 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.
Hi, that is exactly what I meant. The reasoning behind it is just as important as what it is your example.
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.
Adding to this, I think one should not assume beautiful software and beautiful code to be the same thing. Just like the many dimensions of beautiful, there are many dimensions of "software", only one of which is code.
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.
What if OP wanted different examples and the explanation why they are beautiful in the posters opinion? Seems like it would get more interesting submission than simply asking for "small" software.
This is a superb comment that illustrates how for a given purpose different quality factors are important. Can anyone recommend resources that try to systemise why these choices are made?
I would define it as something that evokes emotion and admiration.
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'm not a big fan of the game (love its style, but the gameplay hasn't aged well IMO - playing it for the first time in 2014 probably didn't help), but this is a really neat architecture. Thanks for the link.
My vote is for SQLite. It is very well written, incredibly well tested, and one of the simplest and most flexible tools out there. My favorite part is the extensive documentation explaining the architecture decisions they made.
And according to them, valgrind (and linux) can be qualified as beautiful piece of code[1]:
"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).
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?
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.
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)
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.
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.
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.
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.
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)
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.
"Beautiful Code: Leading Programmers Explain How They Think" is a book that attempts to to tackle this topic. "The authors think aloud as they work through their project's architecture, the tradeoffs made in its construction, and when it was important to break rules." The book has been sitting in my to-read stack forever. You might want to check it out.
Yes. IIRC, they also had a series of posts on the same topic, with columns by some well-known programmers, maybe on programming.oreilly.com or radar.oreilly.com - some years ago.
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.
Yes, there is a special kind of joy knowing that unless the underlying infrastructure has a problem you have handled all the edge cases, and it is still readable.
I also think Rust is magnificent, the way they combined manual memory management with the feel of an automatic one, all at compile time, paired with the rest of the type system; functional, compossible and flexible, is exactly the level of practical, useable innovation I would like to see more frequently.
When he says "the algorithm is given just the pixels", does that mean it's not given any information about the game itself, like the objective? How does it know how to measure it's own success?
There is an objective, but it may not be exactly as you reason about it. There's a great video that made the rounds last year about building a neural net that plays Super Mario World, that may help visualize what's going on - https://www.youtube.com/watch?v=qv6UVOQ0F44
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.
The Go standard library. At least two things coming together: A stripped down language, that explicitly aims to be readable and experienced programmers / authors.
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.
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).
> 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).
> 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.
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.
>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.
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 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.
It's having a rather half-hearted schema definition language though, and the json-encoding itself contains a few fuzzy corners, lacking important data types, and is to be honest not particulary sophisticated.
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.
JSON is not all its cracked up to be. It is useful, but I find its getting treated as some sort of magical solution to everything in the way that XML was 15 years ago.
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.
Stored without a decimal for free, seems like it'd be up to the receiver to interpret it correctly.
What if you receive it in JS?
JSON.parse(JSON.stringify(1))
> 1
Ok, so it parses an int for free too... thus my confusion.
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.
You haven't demonstrated your premise. JSON is a format for storing data, completely separate from the JavaScript language. Try validating this in a JSON validator:
{ "number" : 9007199254740993 }
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'm don't understand how JSON is better than XML, edn, toml, or yaml. They all have pros and cons, but if I had to pick one as being beautiful, it wouldn't be json!
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.
Ouch. I admire Norvig, but that's one of the most horrible pieces of code I have ever seen. I've read that page several times, I've even translated it to C# - https://github.com/mdpopescu/public/blob/master/Sudoku/Sudok... - but I still think it's incredibly ugly. I will admit that my knowledge of Python is very basic but still, if I had to maintain that code without the entire description around it, I'd give up and rewrite it.
For me, learning about functional programming and 'feeling my way' into avoiding excess local vars, paying careful attention to side effects. To be clear: I'm talking about functional style in imperative languages, not about making the jump to functional languages (which are still less widely used -- maybe because they're not 'necessary enough').
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.
This might sound crazy but I actually found the discourse source code to be a beautiful thing. When I read it I had never used ruby beyond understanding the syntax via ruby koans. And one day I wanted to learn how they manage long running tasks without blocking the rest of the web application, and so I jumped into the code using only github and github source code search. 15 minutes in I had notes which drew the entire picture of how and where sidekiq comes in and how and where emails are constructed (I was starting out by trying to understand how things like password reset emails are handled iirc). I know there must be some ugly parts in there, but I went in with no understanding of what to look for except some keywords. I came back with a pragmatic understanding of how to implement a certain workflow regardless of language or framework. This was the mark of something beautiful to me.
Knuth's TeX. Set the standards for documentation, reliability, portability, typography, extensibility and scripting, is well into its fourth decade and is free software.
The Scheme programming language. As close to the core essence of programming as an actually usable, practical programming language has ever come.
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.
I think he means R5RS. But honestly, It's missing a bit of what you need for most programming. Chicken Scheme is probably the best actual scheme on the sliding scale of elegance/power, IMHO.
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.
Werkzeug's Jinja2 templating engine written in Python.
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.
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..).
Reminds me of Maya. I had to sit down for a minute when I realize 90% of the UI is a mel Script. The core of the software is an interpreter/server for some lazy DAG. Actually I wanted to mention Maya, from its performance on piss poor[1] desktop hardware of the late 90s it was able to pull real time Rigid Body dynamics over Nurbs surface (and even pseudo Non Rigid) while staying responsive.
Blender is great, but the UI is very non-standard (for little benefit). A good program can be used by domain experts without reading the manual, something that's not possible with Blender. 3D Max, 4D Studio, and CAD apps like CATIA have a much more intuitive UI.
Yes. I've dabbled with blender a couple of times, and it's infuriating how hard it is to do simple things like rearranging palettes. Blender is different than any other software I've used, and is unique in requiring a tutorial just to understand basic stuff like how to open and save files...
The Emacs source code was always impressive to me. Much is lisp, but even the primitives (like buffer) that are written in C use macros to maintain semantic parity with the lisp code, defining macros like EQ and DEFUN. It's kind of fun to read (for me, anyway).
https://github.com/emacs-mirror/emacs/blob/master/src/buffer...
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.
I would say that not many actual implementations of software turn out to be beautiful, assuming it is above a certain threshold of complexity and it is meant for production use.
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.
SolveSpace - parametric CAD program. Single executable, well done UI, small code base, nice constraint solver, originally by a single person. It's the only OSS CAD I've found useful (QCad was second, then FreeCAD). There are also a few active developers now with major improvements on the way.
Be sure to get the latest from whitequarks repository. He's been doing (or integrating) most of the recent development including the GTK3 and native OS X ports.
"If Hemingway Wrote Javascript" (https://www.nostarch.com/hemingway, see also https://javascriptweblog.wordpress.com/2015/01/05/if-hemingw...), in which five short programs are each written in five different styles (all in Javascript). It shows how different programming styles can be used in the same language to solve the same problem. It's unlikely that you'll start writing in the style of Borges or Austen after reading this, but it is entertaining and amusing.
I learned an enormous amount about how to ship code that works on multiple platforms back in the 90s just by reading the GNU Emacs and XEmacs source code. I really owe a lot to that source code being available.
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).
Well, I think Jonathan Blow's Braid is a beautiful thing. Many in here seem to be talking about the beauty of the source code or something related, but I like a simple well executed idea that is beautiful to look at as well. No corners were cut here - I think it is a work of art.
Not working software per se, but I think there's a lot of beauty in the way Sandi Metz demos a refactoring of a thing called The Gilded Rose in this video:
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"
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 way ruby uses instance_eval. I didn't pay attention at first, I just enjoyed the beautiful interfaces. But when I saw how they use instance_eval behind the scene and how simple is, I was in awe.
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.
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.
Why do we assume that software is same as code? I wonder if graphics tools(like photoshop) were't invented as a point and click tool, but something that you would need to code instead, we would have praised some X or Y instead of Z..
This is highly opinionated. It will change from person to person, even for the same person in different times of his/her life. My answer would be that "when the planets align": Meaning the right product at the right time.
i maintain a lingering fondness for the [aurora text editor](http://www-personal.umich.edu/~knassen/aurora.html), a dos-based text editor that was, like emacs, largely written in its own scripting language. the editor was sadly closed-source and has now gone the way of most closed source stuff, but the scripted bits were open source, and they were a real pleasure to work with. again, like emacs, you could build some surprisingly non-text-editor-like things on top of it.
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.
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.
There is a few rather universal generalizations about most of these projects people find beautiful - the code has been written after throughout understanding of what one is doing and why - the domain, the first principles, the logic and the representation. And then one returns and refines (refactors) the code several times as long as one's understanding clarifies in the process of writing it down.
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.
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.
> 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.
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.