In computer humor, a write-only language is a programming language with syntax (or semantics) sufficiently dense and bizarre that any routine of significant size is too difficult to understand by other programmers and cannot be safely edited. Likewise, write-only code is source code so arcane, complex, or ill-structured that it cannot be reliably modified or even comprehended by anyone with the possible exception of the author.
A more rarely used term is read-only language, which refers to systems with so many boundary conditions that the code can only be written through constant experimentation and not from first principles. The resulting code is perfectly readable by other programmers, but any attempt to duplicate it in another context will fail. The canonical example of a read-only language is AppleScript.
Write-only language is also referred to as line noise, suggesting that the code looks like spurious characters from signal noise in the communication line. In such a language it would be more difficult to read, understand, and modify existing source code than to start over and rewrite it from scratch.
Languages that are often derided as write-only include APL, DDT, older versions of BASIC, Perl, Forth, TECO, Mathematica and regular expression syntax used in various languages. Attributes that these languages have in common include a large set of operators and a syntax which permits (or encourages) the writing of very dense code. It is also a common feature of esoteric programming languages that strive to have obfuscated code, such as INTERCAL.
AppleScript has been described as a read-only language due to considerable implementation differences between different programs on the Macintosh platform. In theory, AppleScript is a simple language with considerable syntactic sugar that makes code easy to read and write. However, the core of the system, especially the system known as "chunking" and the objects it works on, has to be implemented within the third-party applications that support scripting. This support was not easy to add, and applications picked and chose which portions of the chunking system to implement. This led to essentially random support within applications.
Programmers writing a script could not determine in advance which features would be supported and which would not. Instead, they had to experiment to find a string of operations that would complete successfully. The resulting code was perfectly readable by other programmers, although the original meaning of the code might be lost. For instance, the code
set the textStyle of characters 1 to 7 to bold is clear enough, but the original intent of the code might have been to
set the textStyle of the first word to bold, but the
word operator was not implemented in that application. Attempting to use the same or similar code with another application was almost sure to fail, as the set of supported features would be different. The working pattern could only be determined through further experimentation, and might look entirely different than the original solution.
- Spaghetti code
- Write-only memory
- International Obfuscated C Code Contest
- There's more than one way to do it, a motto of the Perl programming language