Hacker News new | ask | show | jobs
by ShaneWilton 3114 days ago
While I agree with you, it's important to note that the defining trait of Lisp isn't that it's a functional language.

It can be functional, just as it can be object oriented or procedural, but those labels matter less to what Lisp is than does the intense focus on things like metaprogramming, in my opinion.

1 comments

That is far from the defining trait of lisp. Probably brought about because it was easy to pass around functions in lisp. However, i find lisp is at its most powerful when you understand some of the imperative abstractions that are available to you.
Around 60 years ago, Lisp pioneered functional programming and was the only thing that supported it at all. Up until the mid-90s or so it was still far and away the most popular language that had meaningful support for closures and higher order functions. That hasn't been true anymore for about 20 years, but for a long time anyone interested in using that stuff probably learnt it from Lisp, and Lisp was probably their best bet for getting to use it.

There was always more to Lisp (I read a cute essay from the mid-60s about how to balance assignment-and-goto style programming with recursive-pure-function style programming in Lisp), but older people making that connection isn't unreasonable, or younger people who've only heard older people talk about it.

60 or so years ago, many of the main tricks of functional programming today were far too expensive in terms of memory to actually be used. So, I find this claim somewhat hard to take at face value.

More, early lisps were far more up front about their imperative abstractions. Something that we try our damnedest to hide from folks nowadays. In ways that are actually hard to fully explain. Used to, you were given an array of functions not just as a programmer, but as a user of the machine. The "side effects" of the functions were the point of them. They literally made the machine do something.

So, yes, functional has always been a defining element of lisp. I can fully support that statement. The defining element, though? I have a hard time supporting that one.

Yes, I agree. If you've ever read old Lisp code it's full of PROG and assigning variables and jumping around with gotos, McCarthy even said: "LISP also allows sequential programs written with assignment statements and go tos. Compared to the mathematically elegant recursive function definition features, the ``program feature'' looks like a hasty afterthought. This is not quite correct; the idea of having sequential programs in LISP antedates that of having recursive function definition." Mind, if you've ever read modern Lisp code, it's full of LOOP and ITER. Lisp has always been largely imperative.

As for what makes Lisp "different," I think it was true in about 1960 that it was mostly the functional support. It hasn't been for a long time, but I just think that people who don't know Lisp assuming that it is isn't completely unfounded.

> More, early lisps were far more up front about their imperative abstractions.

I will say that I have no idea how someone could look at Common Lisp and not realise it was largely an imperative language unless they had some major preconceptions going in.

My reading comprehension on first waking up was terrible. I thought we were disagreeing, but I can see you were clearly adding to my statement, not contradicting it. :)

Love that quote from McCarthy, btw. I have not seen that before. Is there more in the context of where that came from?

Not really, the way Lisp abstracts the hardware is what made projects like Thinking Machines in 1985, with StarLisp possible.

So it might not be 60 years ago, but 40 is already quite some years.

I used StarLisp on the Connection Machine 1, and it was such a good fit for using the hardware. I didn't get too much time on that project, but StarLisp let me work offline on code before getting access to the hardware.
What are you saying "not really" to? I wasn't claiming that lisp didn't allow you to use hardware.

Rather, I was claiming that most of the hallmarks of functional code in today's programs wasn't possible in older hardware. Specifically, many of the "functional data structures" that people are growing to love nowadays were decidedly not possible on so little memory.

To which I gave the example of 80's Thinking Machines as "older hardware".

I could also given Symbolics as example.

As 40 year old examples, in 20 years the use of Lisp improved a lot since the early IBM mainframes.