Why isn't lambda calculus used much (at all)?

Question

Why is pure untyped lambda calculus often described as being impossible to use?

With a suitable library of functions would it not be about the same as any other functional language?

Answer 1

Speed is not a big issue. For example, you could decide to use church numerals but optimize the implementation so numbers are represented as usual -- in a way that is completely transparent to the user. The resulting numbers would obviously perform as well as in any language -- except when people try to implement their own arithmetical operations and discover that they're not fast as the one from the implementation, or when they discover that using a builtin 7 is much faster than the corresponding lambda expression... But that points at a much worse problem. In plain lambda calculus there are only one-argument functions. This means that you're working in a very low level assembly-like language where there are no type errors since everything is just functions. In fact, if you stick with just plain lambda calculus, there are no errors at all. The analogy to machine code is very relevant here: there, you can also do whatever you want -- add two strings, and the the result would be some random number. In a lambda calculus language, send some list encoding to a numeric function, and it will happily return a (bogus) answer.

Answer 2

In theory, theory and practice are the same. In practice, they are not.

In theory it would be just another functional language. But have you considered the performance implications of actually doing math with Church numerals? Yes, you can do it. But your programs will run so slowly that they will look severely broken. A practical functional language must find ways to make a pragmatic tradeoff between providing abstractions that can be built upon, and using fast, native implementations of commonly used things.