Hacker News Reader

Comment by seanmcdirmid | Hacker News Reader

Lisp was based on the lambda calculus, not sure if you can get more functional than that. Common Lisp was obviously more multi paradigm, having one of the most powerful object system ever. Scala is obviously also multiparadigm, though many would rather ignore that side of the language.

Most languages are multi paradigm, even clojure is used with an object-like entity component system, while there are papers that push Haskell as the best language for imperative programming. The word is kind of meaningless when applied to languages but more meaningful when applied to code.

View on HN

It doesn't matter if the language is multi-paradigm. The most influential programming style in Common Lisp is not FP and if you'll take a look at any CLisp book, you'll be hard pressed to find any FP in it.

LISP might have been born of Lambda Calculus, but Common Lisp is no longer based on it.

Scala might be multi paradigm, but is the only language on top of the JVM where pure FP programming is made possible by a pretty good and well maintained ecosystem of libraries, see for example: https://typelevel.org/

That is not true of Common Lisp.

LISP borrowed the "lambda" word from lambda calculus (not the Greek symbol). It didn't implement the lexical scope of lambda calculus, and provided lots of semantics other than lambda-calculus-like function application right off the bat.

Let's see: lambda calculus has no representation of its own code; it is not code. In lambda calculus, there is no QUOTE. There is no CAR nor CDR to walk around the code, no EVAL.

In lambda calculus, there is no mutation: no SETQ, no RPLACA.

Pure lambda calculus has no terms other than functions (unless extended); LISP had symbols, numbers, conses right off the bat. Arrays and character strings came soon.

All in all, equating Lisp with lambda calculus is silly.

Having gone through a few CL books recently, they make sure to mention that it is _not_ a functional language, fwiw.

> Lisp was based on the lambda calculus, not sure if you can get more functional than that.

I've tried really hard (okay, for about five minutes), but couldn't find any account of the lambda calculus that includes the following features:

(0) variadic argument lists,

(1) object identities for absolutely everything,

(2) procedures that can be manipulated in ways other than applying them to arguments.

Are you really saying that all this time my understanding of the lambda calculus has been a lie?

Well, pretty sure you can give a lambda denotation of those. Just start by implementing an interpreter in lamda-calculus ;p

Sure, but that would be an object language embedded in the lambda calculus, not the lambda calculus itself.

btw, variants of the lambda calculus do exist where some values (so-called “reference cells”) are object identities. But a value cannot be a lambda abstraction and a reference cell at the same time.

Reply on news.ycombinator.com