"Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."
You can, of course, safely drop the "C or Fortran" part.
Every program I've ever written, if it keeps getting used, maintained and expanded after ~2 years it gets it's own programming language, and therefore usually becomes turing-complete.
The most powerful abstraction one can make in an application is the ability to quickly combine large parts of the application into new functionalities, effectively implementing a programming language. Usually this starts with "macros": the ability to specify sequences to be executed in series with either fully implicit data-passing (e.g. we're always acting on this global state), and then someone points out that variables would be really good, and then you do that : local, named variables in macros. And there's your programming language.
Well, users need to extend our programs or automate repetitive mechanical tasks, at the end of the day, that's a big part of why computation is so useful. We need to customise how certain actions happen, say how a blur effect is applied to a photo, and presets don't always work. Actually I can't see how tuning some sliders to adjust a certain variable is fundamentally different from setting it via an extension language. This process of adjusting a program or extending it is as natural as cutting a pair of jeans and making it into a pair of shorts.
And this is why I like emacs so much: within it customisability and extendableness is a product of the programming paradigm, and you don't even need to allow the user explicitly. The online docs, the debugger that automatically comes up when needed, the lisp mechanisms like advices and live editing of the running program furnish a great environment where one is not confined to the application designer's decisions, and where making customisations and extensions are really approachable.
Would it be cheating to mention PowerPoint's Visual Basic support? I think your assertion could be even stronger -- every sufficiently advanced program embeds a full programming language.
"Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."
You can, of course, safely drop the "C or Fortran" part.
Every program I've ever written, if it keeps getting used, maintained and expanded after ~2 years it gets it's own programming language, and therefore usually becomes turing-complete.
The most powerful abstraction one can make in an application is the ability to quickly combine large parts of the application into new functionalities, effectively implementing a programming language. Usually this starts with "macros": the ability to specify sequences to be executed in series with either fully implicit data-passing (e.g. we're always acting on this global state), and then someone points out that variables would be really good, and then you do that : local, named variables in macros. And there's your programming language.