| Turing Tarpit |
Article Index for Turing |
Shopping Turing |
Website Links For Turing |
Information AboutTuring Tarpit |
| CATEGORIES ABOUT TURING TARPIT | |
| esoteric programming languages | |
| theory of computation | |
|
Such a language gives up certain practical goals (such as ease of coding, performance, etc.) in favor of others (e.g., proving non-computability of certain functions, illustrating basic principles of programming, providing simple bases for computational models, etc.). Thus it is of interest in theoretical Computer Science . Originally: "''54. Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy.''" -- Alan Perlis , "'' Epigrams On Programming ''" {Link without Title} . Well-known Turing tarpits include
There are two sometimes-divergent approaches with which computer scientists struggle when designing a tarpit: one may lean towards fewer instructions, or one may lean towards fewer recognized symbols. Some results of this struggle have been
The phrase ''the'' Turing tarpit is also heard occasionally in arguments between proponents of two or more different programming languages each claiming their language is better than the other(s). It refers to the tendency of participants in these discussions to attempt to encode the constructs or programming idioms of one language in another to justify claims of the form, "Anything you can do in your language, I can do in my language." When these encodings become so complex that they amount to writing an interpreter for the first language in the second, they cease to be informative (because in principle an interpreter for any Turing-complete language can be written in any other Turing-complete language) and the conversation is said to have entered the Turing tarpit. The fact that the vast majority of general-purpose programming languages are equivalent in computational power is seen by some as implying that all arguments over which of two or more languages is best are pointless. Others maintain that it only means such arguments should be confined to properties of languages that actually do vary, such as their effects on programmer efficiency or their amenability to efficient implementations. |
|
|