[russellbeattie]

One doesn't have to invoke Turing or Church to show all languages can do the same things.

Any code that runs on a computer (using the von Neumann architecture) boils down to just a few basic operations: Read/write data, arithmetic (add/subtract/etc.), logic (and/or/not/etc.), bit-shifting, branches and jumps. The rest is basically syntactic sugar or macros.

If your preferred programming language is a pre-compiled type-safe object oriented monster with polymorphic message passing via multi-process co-routines, or high-level interpreted purely functional archetype of computing perfection with just two reserved keywords, or even just COBOL, it's all going to break down eventually to the ops above.

[Capricorn2481]

Sometimes, when people say one language can't do what another does, they aren't talking about outputs. Nobody is arguing that lisp programs can do arithmetic and others can't, they're arguing that there are ergonomics to lisp you can't approach in other languages.

But even so

> it's all going to break down eventually to the ops above.

That's not true either. Different runtimes will break down into a completely different version of the above. C is going to boil down to a different set of instructions than Ruby. That would make Ruby incapable of doing some tasks, even with a JIT. And writing performance sensitive parts in C only proves the point.

"Any language can do anything" is something we tell juniors who have decision paralysis on what to learn. That's good for them, but it's not true. I'm not going to tell a client we're going to target a microcontroller with PHP, even if someone has technically done it.

[terminalbraid]

You can trivially devise a language that doesn't, though? Let's say I have a language that can return 0 and only 0. It cannot reproduce lisp.