8 ms·

I'll never understand the obsession with LISP. My guess is it just appeals to a certain type of person, sort of academic in my view. I'm not convinced that LISP

I'll never understand the obsession with LISP. My guess is it just appeals to a certain type of person, sort of academic in my view. I'm not convinced that LISP was ever the-right-thing. The author didn't express anything about LISP vs C except to assert that C was a 50% solution and LISP was better. I agree though that for practical purposes, practical solutions are just going to be more successful.

adamnemecek 2y ago
It’s a signaling mechanism to say “I went to MIT” or at the very least to say “I could have gone to MIT”.
- deleted 2y ago
  [deleted]
- djha-skin 2y ago
  I learned Racket at Brigham Young University in Utah, and Clojure, then Common Lisp on my own. I don't think it's just an MIT thing. It's in the ethos now. Lots of people know about SICP, for example.
Blackthorn 2y ago
How do you know someone knows lisp? They'll tell you. And tell you. And tell you... I like lisp for the most part, but holy shit is the enduring dialog surrounding it the absolute worst part of the whole family of languages by far. No, it doesn't have or give you superpowers. Please grow up.
- anthk 2y ago
  Do either the book on Symbolic Computation + PAIP and/or SICP, and you'll understand.
  - Blackthorn 2y ago
    Yes, I've done SICP. Lisp does not give you superpowers.
yoyohello13 2y ago
I like LISP, but I wouldn't say I'm an evangelist. Here's my 2 cents for why LISP has such a following. 1. LISP is easy to start with if you're not a programmer. There is very little syntax to get to grips with, and once you understand "everything is a list" it's super easy to expand out from there. 2. LISP really makes it easy to hack your way to a solution. With the REPL and the transparency of "code is data" model you can just start writing code and eventually get to a solution. You don't need to plan, or think about types, or deal with syntax errors. You just write your code and see it executed right there in the REPL. For my part, I love LISP when it's just me doing the coding, but once you start adding other peoples custom DSL macros or whatever the heck it becomes unwieldy. Basically, I love my LISP and hate other peoples LISP.
- turtleyacht 2y ago
  Once you get far enough to need external dependencies, do you use your work as a library in another language or rewrite it? http://www.winestockwebdesign.com/Essays/Lisp_Curse.html http://www.winestockwebdesign.com/Essays/Lisp_Curse.html
  - anthk 2y ago
    QuickLisp solves most of the issues. Quiop and closer-mop if you want a universal CLOS. Scheme is not Common Lisp, it's kinda the opposite. It comes with batteries included and MCClim is the defacto GUI for it. >Stuck with Emacs [from the URL] Well, Lem tries to be Emacs for Common Lisp, but without having to think on two Lisp languages (albeit closely related) at once. Once you have a REPL, autocomplete and some docstring looking up tool, you are god.
    - turtleyacht 2y ago
      Good point. I neglected to consider standard libraries (stdlib) at the time. If those are allowed, then a lot more can be done with one's code without reaching much farther. Thank-you.
      - 2y ago
kqr 2y ago
> I'm not convinced that LISP was ever the-right-thing. Remember that this has to be read in historical context. At the time C was invented, things like garbage collection, message-passing object-orientation, generics, rich sets of conditionals, first-class functions, etc. were brand spanking new. They were The Right Thing to do (even judged in the harsh light of hindsight), but also quite complicated to implement – so much so that the New Jersey people skipped right past most of it. Today these things are par for the course. At the time, they were the The Right Thing that made the system correct but complex, and had adoption penalties. As time passes, the bar for The Right Thing shifts, and today, it would probably not be embodied by Lisp, but maybe by something like Haskell or Rust?
- pjc50 2y ago
  > things like garbage collection, message-passing object-orientation, generics, rich sets of conditionals, first-class functions, etc. were brand spanking new. They were The Right Thing to do I quite like this view, because these things have clearly been copied everywhere such as my language of choice C#, but the one thing that nobody copied is the one that Lisp programmers rave about most: homoiconicity (brackets everywhere).
  - pjmlp 2y ago
    Lisp-2, Prolog, Dylan, Erlang, Julia, R.... Are all homoiconic without being full of parenthesis all over the place, the actual meaning is code and data being interchangeable.
    - BoingBoomTschak 2y ago
      I think following what's written in Wikipedia (https://en.wikipedia.org/wiki/Homoiconicity#Implementation_methods https://en.wikipedia.org/wiki/Homoiconicity#Implementation_m...) and only using the adjective for stuff like Lisp, Tcl, Rebol is better than diluting its meaning to the point where it applies to any language with tree-sitter bindings and a parser.
      - 2y ago
deleted 2y ago
[deleted]
pjc50 2y ago
Over the years I've developed what I call the "lefthanded scissors" analogy: people assume that everyone's mind is wired the same way and that all good programmers are good in the same way and think in the same way, but what if that's not true? What if different people have a predisposition (like lefthandedness) to prefer different tools? Then a righthanded person picks up the lefthanded scissors and deems them weird and uncomfortable. Which they are .. for the right hand of a right-handed person. Other popular examples of such taste controversy are Python's semantic whitespace, the idioyncracies of Perl, the very unusual shape of J/APL, and anyone using FORTH for non-trivial purposes. edit: https://news.ycombinator.com/item?id=41766753 https://news.ycombinator.com/item?id=41766753 comment about "other people's Lisp" reminds me, that working as a solo genius dev on your own from-scratch code and working in a team inside a large organization on legacy code are very different experiences, and the "inflexibility" of some languages can be a benefit to the latter.
- arethuza 2y ago
  I've seen Common Lisp source code that I didn't even recognise as Common Lisp because of over-enthusiastic use of reader macros... Edit: I should also mention that once I worked out how reader macros worked I went on to enthusiastically (ab)use them for my own ends...
  - blenderob 2y ago
    If there has been over-enthusiastic use of reader macros, I think we will have to admit that the over-enthusiastic developer is no longer writing Common Lisp code. Those reader macros have morphed the language into a new bespoke language. So it is then natural for a new developer to face a steep learning curve to learn that new bespoke language before they can make sense of the code. I'm not condoning overuse of macros. I'd hate to be working with such code too. I'm only stating that Common Lisp is that language that can be programmed to become a different language. They call it a "programmable programming language" for a reason.
- sceptic123 2y ago
  I would say the analogy fails because it's not about discomfort or weirdness (or taste); left-handed scissors just don't work if you try to use them right-handed. But right-handed scissors don't work if you try to use them left-handed either. So it's not about taste or preference, left handed people learn how to use right-handed scissors, but they can also use left handed scissors in a way that a right-handed person would struggle to. All that said, the analogy still works because most people don't understand why it doesn't work.
djha-skin 2y ago
In the words of "Programmers Are Also Human" YouTube channel, it's just more comfortable. REPL development, ease of refactoring, dynamic typing, good CFFI, all just adds up to a developer experience that I find to be, in a word, chill.
mattgreenrocks 2y ago
Such a weird take on HN. Lisp should be experimented with if only to appreciate the profound beauty of a small, powerful, cohesive design. It is a wholly different feeling from industry standard languages which are constantly changing. In Lisp, almost all of the language’s power is in “user space.” The ramifications for that are deep and your beliefs as to whether that is good are largely shaped by whether you believe computation is better handled by large groups of people (thus, languages should restrict users) or smaller groups of people (thus, languages should empower users). See this for more discussion: https://softwareengineering.stackexchange.com/a/237523 https://softwareengineering.stackexchange.com/a/237523
- pif 2y ago
  > languages which are constantly changing They change because they are used.
  - skribanto 2y ago
    Well the main point is that there are changes that for most languages would need a change in the compiler/interpreter itself. However in lisp those kinds of things can be done in userspace
- Blackthorn 2y ago
  Nothing about Common Lisp is small or cohesive. Some schemes, maybe.
  - anthk 2y ago
    CL it's much more cohesive than Scheme. They Schemes are barely compatibles upon themelves with ice-9's on Guile, SRFI's and whatnot.
linguae 2y ago
Keep in mind that this essay was written in the early 1990s. Today there are many programming languages available that offer features that are unavailable in C but have long been available in Lisp. This was not the case in the 1980s during the AI boom of that era. There was a large chasm between classic procedural languages (C, Fortran, Pascal, Simula) and dynamic languages (Smalltalk and Lisp). Prolog was a popular alternative to Lisp in AI circles, especially in Japan back when it was pursuing the Fifth Generation Computing Project. When looking at the language landscape in the 1980s in the context of AI, it makes sense that practitioners would gravitate toward Lisp and Prolog. Today we benefit from having a variety of languages, each with tradeoffs regarding how their expressiveness matches the problem at hand and also the strength of its ecosystem (e.g., tools, libraries, community resources, etc.). I still think Lisp has advantages, particularly when it comes to its malleability through its syntax, its macro support, and the metaobject protocol. As a Lisp fan who codes occasionally in Scheme and Common Lisp, I don’t always grab a Lisp when it’s time to code. Sometimes my language choices are predetermined by the ecosystem I’m using or by my team. I also think strongly-typed functional programming languages like Standard ML and Haskell are quite useful in some situations. I think the strength of Lisp is best seen in situations where flexibility and have malleable infrastructure is highly desirable.
kragen 2y ago
The paper was written for an audience of Lisp programmers, so the things you're talking about were sort of out of scope. I'm not going to try to convince you that Lisp and ITS really did aim at "the right thing" in a way that C and Unix didn't; you'll see that it's true if you investigate. Lisp definitely does depend on personality type. Quoting Steve Yegge's "Notes from the Mystery Machine Bus" (https://gist.github.com/cornchz/3313150 https://gist.github.com/cornchz/3313150): > Software engineering has its own political axis, ranging from conservative to liberal. (...) We regard political conservatism as an ideological belief system that is significantly (but not completely) related to motivational concerns having to do with the psychological management of uncertainty and fear. (...) Liberalism doesn't lend itself quite as conveniently to a primary root motivation. But for our purposes we can think of it as a belief system that is motivated by the desire above all else to effect change. In corporate terms, as we observed, it's about changing the world. In software terms, liberalism aims to maximize the speed of feature development, while simultaneously maximizing the flexibility of the systems being built, so that feature development never needs to slow down or be compromised. Lisp, like Perl and Forth, is an extremist "liberal" language, or family of languages. Its value system is centered on making it possible to write programs you couldn't write otherwise, rather than reducing the risk you'll screw it up. It aims at expressiveness and malleability, not safety. The "right thing" design philosophy is somewhat orthogonal to that, but it also does pervade Lisp (especially Scheme) and, for example, Haskell. As you'd expect, the New Jersey philosophy pervades C, Unix shells, and Golang. Those are also fairly liberal languages, Golang less so. But a C compiler had to fit within the confines of the PDP-11 and produce fast enough code that Ken would be willing to use it for the Unix kernel, and it was being funded as part of a word processing project, so things had to work; debuggability and performance were priorities. (And both C and Unix were guided by bad experiences with Multics and, I infer, M6 and QED.) MACLISP and Interlisp were running on much more generous hardware and expected to produce novel research, not reliable production systems. So they had strong incentives to both be "liberal" and to seek after the "right thing" instead of preferring expediency.
bbor 2y ago
It’s for the dreamers. The crazy ones among us that do not think of themselves as experts in programming machines to solve business problems, but rather novices in cajoling machines to think like humans do.
hcarvalhoalves 2y ago
See these demos for the kinds of interactive systems LISP enabled back in the day: https://www.youtube.com/watch?v=o4-YnLpLgtk https://www.youtube.com/watch?v=o4-YnLpLgtk https://www.youtube.com/watch?v=gV5obrYaogU https://www.youtube.com/watch?v=gV5obrYaogU It makes working on VSCode today look like banging rocks together, let alone 30 years ago.
- anthk 2y ago
  And today with Lem/Emacs+slime+sbcl
taeric 2y ago
LISP remains one of the only languages where manipulating the code looks exactly the same as executing it. This is often illustrated by pointing out that "eval" in lisp doesn't take in a string of characters. (https://taeric.github.io/CodeAsData.html https://taeric.github.io/CodeAsData.html is a blog I wrote on the idea a bit more.) What this often meant was that getting a feature into your LISP program was something you could do without having to hack at the compiler. Used to, people balked at how macros and such would break people's ability to step debug code. Which is still largely true, but step debugging is also sadly dead in a lot of other popular languages already.
buescher 2y ago
It's not really about lisp or even about vague reverse-snobbish ideas of "practicality" but about very specific categories of design compromises.
Jach 2y ago
It's not a perfectly reliable tell, but people who write LISP instead of Lisp generally give themselves away as knowing nothing about the language. Why not kick the tires with Common Lisp, or even Clojure, and see if you can then understand for yourself why it sparks joy in people? I'm not saying it'll spark joy in you, just that you might understand. (Do you understand Haskell's draw to certain people? Rust's?) At the very least, perhaps you'll lose your notion that it primarily appeals to academic types. Common Lisp is and always has been an industrial language. "Please don't assume Lisp is only useful for Animation and Graphics, AI, Bioinformatics, B2B and E-Commerce, Data Mining, EDA/Semiconductor applications, Expert Systems, Finance, Intelligent Agents, Knowledge Management, Mechanical CAD, Modeling and Simulation, Natural Language, Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web Authoring just because these are the only things they happened to list." --Kent Pitman
- NAHWheatCracker 2y ago
  My only personal experience writing with Lisp was Scheme, which I wrote for two weeks back in college 18 years ago, so I truly know nothing about the language. In retrospect, saying I don't understand was hyperbolic. Of course I understand that people have their preferred languages. The handful of languages I've used in my career each have their draw. My comment was meant more to question the assertion that Lisp is the-right-thing, which sounds like asserting the-right-religion.

adamnemecek 2y ago

It’s a signaling mechanism to say “I went to MIT” or at the very least to say “I could have gone to MIT”.

deleted 2y ago
[deleted]
djha-skin 2y ago
I learned Racket at Brigham Young University in Utah, and Clojure, then Common Lisp on my own. I don't think it's just an MIT thing. It's in the ethos now. Lots of people know about SICP, for example.

Blackthorn 2y ago

How do you know someone knows lisp? They'll tell you. And tell you. And tell you... I like lisp for the most part, but holy shit is the enduring dialog surrounding it the absolute worst part of the whole family of languages by far. No, it doesn't have or give you superpowers. Please grow up.

anthk 2y ago
Do either the book on Symbolic Computation + PAIP and/or SICP, and you'll understand.
- Blackthorn 2y ago
  Yes, I've done SICP. Lisp does not give you superpowers.

yoyohello13 2y ago

I like LISP, but I wouldn't say I'm an evangelist. Here's my 2 cents for why LISP has such a following. 1. LISP is easy to start with if you're not a programmer. There is very little syntax to get to grips with, and once you understand "everything is a list" it's super easy to expand out from there. 2. LISP really makes it easy to hack your way to a solution. With the REPL and the transparency of "code is data" model you can just start writing code and eventually get to a solution. You don't need to plan, or think about types, or deal with syntax errors. You just write your code and see it executed right there in the REPL. For my part, I love LISP when it's just me doing the coding, but once you start adding other peoples custom DSL macros or whatever the heck it becomes unwieldy. Basically, I love my LISP and hate other peoples LISP.

turtleyacht 2y ago
Once you get far enough to need external dependencies, do you use your work as a library in another language or rewrite it? http://www.winestockwebdesign.com/Essays/Lisp_Curse.html http://www.winestockwebdesign.com/Essays/Lisp_Curse.html
- anthk 2y ago
  QuickLisp solves most of the issues. Quiop and closer-mop if you want a universal CLOS. Scheme is not Common Lisp, it's kinda the opposite. It comes with batteries included and MCClim is the defacto GUI for it. >Stuck with Emacs [from the URL] Well, Lem tries to be Emacs for Common Lisp, but without having to think on two Lisp languages (albeit closely related) at once. Once you have a REPL, autocomplete and some docstring looking up tool, you are god.
  - turtleyacht 2y ago
    Good point. I neglected to consider standard libraries (stdlib) at the time. If those are allowed, then a lot more can be done with one's code without reaching much farther. Thank-you.
    - 2y ago

kqr 2y ago

> I'm not convinced that LISP was ever the-right-thing. Remember that this has to be read in historical context. At the time C was invented, things like garbage collection, message-passing object-orientation, generics, rich sets of conditionals, first-class functions, etc. were brand spanking new. They were The Right Thing to do (even judged in the harsh light of hindsight), but also quite complicated to implement – so much so that the New Jersey people skipped right past most of it. Today these things are par for the course. At the time, they were the The Right Thing that made the system correct but complex, and had adoption penalties. As time passes, the bar for The Right Thing shifts, and today, it would probably not be embodied by Lisp, but maybe by something like Haskell or Rust?

pjc50 2y ago
> things like garbage collection, message-passing object-orientation, generics, rich sets of conditionals, first-class functions, etc. were brand spanking new. They were The Right Thing to do I quite like this view, because these things have clearly been copied everywhere such as my language of choice C#, but the one thing that nobody copied is the one that Lisp programmers rave about most: homoiconicity (brackets everywhere).
- pjmlp 2y ago
  Lisp-2, Prolog, Dylan, Erlang, Julia, R.... Are all homoiconic without being full of parenthesis all over the place, the actual meaning is code and data being interchangeable.
  - BoingBoomTschak 2y ago
    I think following what's written in Wikipedia (https://en.wikipedia.org/wiki/Homoiconicity#Implementation_methods https://en.wikipedia.org/wiki/Homoiconicity#Implementation_m...) and only using the adjective for stuff like Lisp, Tcl, Rebol is better than diluting its meaning to the point where it applies to any language with tree-sitter bindings and a parser.
    - 2y ago

deleted 2y ago

[deleted]

pjc50 2y ago

Over the years I've developed what I call the "lefthanded scissors" analogy: people assume that everyone's mind is wired the same way and that all good programmers are good in the same way and think in the same way, but what if that's not true? What if different people have a predisposition (like lefthandedness) to prefer different tools? Then a righthanded person picks up the lefthanded scissors and deems them weird and uncomfortable. Which they are .. for the right hand of a right-handed person. Other popular examples of such taste controversy are Python's semantic whitespace, the idioyncracies of Perl, the very unusual shape of J/APL, and anyone using FORTH for non-trivial purposes. edit: https://news.ycombinator.com/item?id=41766753 https://news.ycombinator.com/item?id=41766753 comment about "other people's Lisp" reminds me, that working as a solo genius dev on your own from-scratch code and working in a team inside a large organization on legacy code are very different experiences, and the "inflexibility" of some languages can be a benefit to the latter.

arethuza 2y ago
I've seen Common Lisp source code that I didn't even recognise as Common Lisp because of over-enthusiastic use of reader macros... Edit: I should also mention that once I worked out how reader macros worked I went on to enthusiastically (ab)use them for my own ends...
- blenderob 2y ago
  If there has been over-enthusiastic use of reader macros, I think we will have to admit that the over-enthusiastic developer is no longer writing Common Lisp code. Those reader macros have morphed the language into a new bespoke language. So it is then natural for a new developer to face a steep learning curve to learn that new bespoke language before they can make sense of the code. I'm not condoning overuse of macros. I'd hate to be working with such code too. I'm only stating that Common Lisp is that language that can be programmed to become a different language. They call it a "programmable programming language" for a reason.
sceptic123 2y ago
I would say the analogy fails because it's not about discomfort or weirdness (or taste); left-handed scissors just don't work if you try to use them right-handed. But right-handed scissors don't work if you try to use them left-handed either. So it's not about taste or preference, left handed people learn how to use right-handed scissors, but they can also use left handed scissors in a way that a right-handed person would struggle to. All that said, the analogy still works because most people don't understand why it doesn't work.

djha-skin 2y ago

In the words of "Programmers Are Also Human" YouTube channel, it's just more comfortable. REPL development, ease of refactoring, dynamic typing, good CFFI, all just adds up to a developer experience that I find to be, in a word, chill.

mattgreenrocks 2y ago

Such a weird take on HN. Lisp should be experimented with if only to appreciate the profound beauty of a small, powerful, cohesive design. It is a wholly different feeling from industry standard languages which are constantly changing. In Lisp, almost all of the language’s power is in “user space.” The ramifications for that are deep and your beliefs as to whether that is good are largely shaped by whether you believe computation is better handled by large groups of people (thus, languages should restrict users) or smaller groups of people (thus, languages should empower users). See this for more discussion: https://softwareengineering.stackexchange.com/a/237523 https://softwareengineering.stackexchange.com/a/237523

pif 2y ago
> languages which are constantly changing They change because they are used.
- skribanto 2y ago
  Well the main point is that there are changes that for most languages would need a change in the compiler/interpreter itself. However in lisp those kinds of things can be done in userspace
Blackthorn 2y ago
Nothing about Common Lisp is small or cohesive. Some schemes, maybe.
- anthk 2y ago
  CL it's much more cohesive than Scheme. They Schemes are barely compatibles upon themelves with ice-9's on Guile, SRFI's and whatnot.

linguae 2y ago

Keep in mind that this essay was written in the early 1990s. Today there are many programming languages available that offer features that are unavailable in C but have long been available in Lisp. This was not the case in the 1980s during the AI boom of that era. There was a large chasm between classic procedural languages (C, Fortran, Pascal, Simula) and dynamic languages (Smalltalk and Lisp). Prolog was a popular alternative to Lisp in AI circles, especially in Japan back when it was pursuing the Fifth Generation Computing Project. When looking at the language landscape in the 1980s in the context of AI, it makes sense that practitioners would gravitate toward Lisp and Prolog. Today we benefit from having a variety of languages, each with tradeoffs regarding how their expressiveness matches the problem at hand and also the strength of its ecosystem (e.g., tools, libraries, community resources, etc.). I still think Lisp has advantages, particularly when it comes to its malleability through its syntax, its macro support, and the metaobject protocol. As a Lisp fan who codes occasionally in Scheme and Common Lisp, I don’t always grab a Lisp when it’s time to code. Sometimes my language choices are predetermined by the ecosystem I’m using or by my team. I also think strongly-typed functional programming languages like Standard ML and Haskell are quite useful in some situations. I think the strength of Lisp is best seen in situations where flexibility and have malleable infrastructure is highly desirable.

kragen 2y ago

The paper was written for an audience of Lisp programmers, so the things you're talking about were sort of out of scope. I'm not going to try to convince you that Lisp and ITS really did aim at "the right thing" in a way that C and Unix didn't; you'll see that it's true if you investigate. Lisp definitely does depend on personality type. Quoting Steve Yegge's "Notes from the Mystery Machine Bus" (https://gist.github.com/cornchz/3313150 https://gist.github.com/cornchz/3313150): > Software engineering has its own political axis, ranging from conservative to liberal. (...) We regard political conservatism as an ideological belief system that is significantly (but not completely) related to motivational concerns having to do with the psychological management of uncertainty and fear. (...) Liberalism doesn't lend itself quite as conveniently to a primary root motivation. But for our purposes we can think of it as a belief system that is motivated by the desire above all else to effect change. In corporate terms, as we observed, it's about changing the world. In software terms, liberalism aims to maximize the speed of feature development, while simultaneously maximizing the flexibility of the systems being built, so that feature development never needs to slow down or be compromised. Lisp, like Perl and Forth, is an extremist "liberal" language, or family of languages. Its value system is centered on making it possible to write programs you couldn't write otherwise, rather than reducing the risk you'll screw it up. It aims at expressiveness and malleability, not safety. The "right thing" design philosophy is somewhat orthogonal to that, but it also does pervade Lisp (especially Scheme) and, for example, Haskell. As you'd expect, the New Jersey philosophy pervades C, Unix shells, and Golang. Those are also fairly liberal languages, Golang less so. But a C compiler had to fit within the confines of the PDP-11 and produce fast enough code that Ken would be willing to use it for the Unix kernel, and it was being funded as part of a word processing project, so things had to work; debuggability and performance were priorities. (And both C and Unix were guided by bad experiences with Multics and, I infer, M6 and QED.) MACLISP and Interlisp were running on much more generous hardware and expected to produce novel research, not reliable production systems. So they had strong incentives to both be "liberal" and to seek after the "right thing" instead of preferring expediency.

bbor 2y ago

It’s for the dreamers. The crazy ones among us that do not think of themselves as experts in programming machines to solve business problems, but rather novices in cajoling machines to think like humans do.

hcarvalhoalves 2y ago

See these demos for the kinds of interactive systems LISP enabled back in the day: https://www.youtube.com/watch?v=o4-YnLpLgtk https://www.youtube.com/watch?v=o4-YnLpLgtk https://www.youtube.com/watch?v=gV5obrYaogU https://www.youtube.com/watch?v=gV5obrYaogU It makes working on VSCode today look like banging rocks together, let alone 30 years ago.

anthk 2y ago
And today with Lem/Emacs+slime+sbcl

taeric 2y ago

LISP remains one of the only languages where manipulating the code looks exactly the same as executing it. This is often illustrated by pointing out that "eval" in lisp doesn't take in a string of characters. (https://taeric.github.io/CodeAsData.html https://taeric.github.io/CodeAsData.html is a blog I wrote on the idea a bit more.) What this often meant was that getting a feature into your LISP program was something you could do without having to hack at the compiler. Used to, people balked at how macros and such would break people's ability to step debug code. Which is still largely true, but step debugging is also sadly dead in a lot of other popular languages already.

buescher 2y ago

It's not really about lisp or even about vague reverse-snobbish ideas of "practicality" but about very specific categories of design compromises.

Jach 2y ago

It's not a perfectly reliable tell, but people who write LISP instead of Lisp generally give themselves away as knowing nothing about the language. Why not kick the tires with Common Lisp, or even Clojure, and see if you can then understand for yourself why it sparks joy in people? I'm not saying it'll spark joy in you, just that you might understand. (Do you understand Haskell's draw to certain people? Rust's?) At the very least, perhaps you'll lose your notion that it primarily appeals to academic types. Common Lisp is and always has been an industrial language. "Please don't assume Lisp is only useful for Animation and Graphics, AI, Bioinformatics, B2B and E-Commerce, Data Mining, EDA/Semiconductor applications, Expert Systems, Finance, Intelligent Agents, Knowledge Management, Mechanical CAD, Modeling and Simulation, Natural Language, Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web Authoring just because these are the only things they happened to list." --Kent Pitman

NAHWheatCracker 2y ago
My only personal experience writing with Lisp was Scheme, which I wrote for two weeks back in college 18 years ago, so I truly know nothing about the language. In retrospect, saying I don't understand was hyperbolic. Of course I understand that people have their preferred languages. The handful of languages I've used in my career each have their draw. My comment was meant more to question the assertion that Lisp is the-right-thing, which sounds like asserting the-right-religion.