But text files are easy to generate, easy to edit, and simple to read. What alternatives are there which remain language and tool agnostic?

I can make a file format as tool-agnostic as you like, if it doesn't actually have to have any features.

Being tool-agnostic is a feature. The most important feature.

If there are other known features that are more important, they would have taken off by now.

I try to, but that's beside the point. What passes for 'easy to understand' when you move past 'flat text files as a representation of code' and how is it better?

Good naming practice. Either pull each line of non-trivial code out into it's own method, or assign the output of the code to a variable that tells you what it's doing.

If you find yourself repeating an assignment, pull it out into a function and remove the duplication.

Rinse and repeat until everything in the file is assigned to a descriptive function or variable. Doing this with someone else's code gives you a feel for how to do it with your own.

This a total non sequitur. What does this have to do with alternatives file formats for code?

What do alternative file formats for code have to do with readability?

At the moment I can open up source code in almost any language up in any text editor. It just has to know the encoding and vomit out characters I can comprehend and get the line breaks right. I can print it out and have a hard copy which represents what was written by the programmer. Send it and receive it by email and read it.

Code which can be represented as plaintext is versatile and portable and, more importantly, has its comprehensibility decoupled from any specific company, or project or group providing the necessary tools to make it human-readable. If an alternative file format isn't natively human-readable then it is by my definition less readable regardless of the standards put into writing the code itself.

> Because we're stuck in a tyranny of flat text files as a representation of code.

Their simplicity is also a strength. That richer file format will at some point be written in a text file.

Take a look: http://jsfiddle.net/7qZVQ/ Code wrapped in a json formatted meta-wrapper.

I am the founder of Crudzilla Software (see profile for link) a web dev platform.

We use jsr-223 which allows scripting engines for other languages to be integrated into the jvm. What we did was create a file format that serves as a meta-wrapper around pieces of code, we call this wrapper a "crud".

This turns out to be quite powerful as it allows the code to have additional instructions associated with it. For instance input validation, security and configuration can be specified along with the code they apply to.

There's nothing wrong with text files.

Although Smalltalk imaging systems are an interesting alternative.

We're trying to address that in the flow-based programming community: http://bergie.iki.fi/blog/noflo-kickstarter-launch/

Freeing code from the constraints of text files would allow different ways to interact with it. Visual programming, REPLs, etc, could work more smoothly in the same workflow as a traditional text editor.