16 ms·

Why I Program in Lisp

286 points by ska80 1y ago

DeathArrow 1y ago
>It's less of a big deal these days, but properly working lambda expressions were only available in Lisp until recently. I think Haskell and ML had lambda expressions since like 1990.
- imgabe 1y ago
  Recent, compared to Lisp
  - IsTom 1y ago
    Number of programmers that are in workforce that started before Standard ML (1983) is tiny and this argument would be relevant only to them.
    - mikelevins 1y ago
      The author of the referenced post is one of them, though.
- User23 1y ago
  The word “properly” is not only working hard here, but perhaps pointing to deeper concepts. In particular, it implies a coherent design around scope and extent. And, much more indirectly, it points to time. EVAL-WHEN has finally made a bit of a stir outside Lisp.
  - BalinKing 1y ago
    Does this imply that lambda expressions in Haskell and ML don't have a "coherent design around scope and extent"? This is quite a claim, to be honest....
    - User23 1y ago
      No, it doesn’t imply that. There are plenty of more popular languages that don’t though.
damnitbuilds 1y ago
"properly working lambda expressions were only available in Lisp until recently." until -> since
- JadeNB 1y ago
  > "properly working lambda expressions were only available in Lisp until recently." > until -> since I think "only since recently" is not standard English, but, even if it were, I think it would change the intended meaning to say that they were not available in Lisp until recently, the opposite of what was intended. I find it clearer to move the "only": "were available only in Lisp until recently."
  - mikelevins 1y ago
    It's perfectly good and idiomatic English, but it's an ambiguous formation and your suggested edit does clarify it.
    - JadeNB 1y ago
      I agree that "properly working lambda expressions were only available in Lisp until recently" is perfectly idiomatic, but easily misunderstood, English. I believe that the suggested fix "properly working lambda expressions were only available in Lisp since recently," which is what I was responding to, is not idiomatic. Claims about what is and isn't idiomatic aren't really subject to definitive proof either way, but it doesn't matter, because the suggester now agrees that it is not what was meant (https://news.ycombinator.com/item?id=43653723 https://news.ycombinator.com/item?id=43653723).
      - mikelevins 1y ago
        To be clear, the construction I’m endorsing is: "were available only in Lisp until recently", which is the construction that my editors typically proposed for similarly ambiguous deployments of "only". The ambiguity in the original placement is that it could be interpreted as only available as opposed to available and also something else. My editors always wanted it to be clear exactly what the "only" constrains.
efitz 1y ago
This is the first article I’ve ever read that made me want to go learn Lisp.
- cutler 1y ago
  Watch Rich Hickey's early Clojure videos and be blown away.
  - laurent_du 1y ago
    Got any specific suggestion?
    - spicybbq 1y ago
      "Simple Made Easy" is pretty popular, there is a transcription with slides: https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/SimpleMadeEasy.md https://github.com/matthiasn/talk-transcripts/blob/master/Hi...
      - filoeleven 1y ago
        I like "Clojure, Made Simple" even more. https://www.youtube.com/watch?v=028LZLUB24s https://www.youtube.com/watch?v=028LZLUB24s Someone helpfully pulled out this chunk, which is a good illustration of why data is better than functions, a key driver of Clojure's design. https://www.youtube.com/watch?v=aSEQfqNYNAc https://www.youtube.com/watch?v=aSEQfqNYNAc
    - cess11 1y ago
      It's tangentially relevant, but I've enjoyed this one, about hammock driven programming. https://www.youtube.com/watch?v=f84n5oFoZBc https://www.youtube.com/watch?v=f84n5oFoZBc
- dutchblacksmith 1y ago
  Lispworks has a free editition with lots of examples. Look into PAIP from Peter Norvig.
terminalbraid 1y ago
> Other general purpose languages are more popular and ultimately can do everything that Lisp can (if Church and Turing are correct). I find these types of comments extremely odd and I very much support lisp and lisp-likes (I'm a particular fan of clojure). I can only see adding the parenthetical qualifier as a strange bias of throwing some kind of doubt into other languages which is unwarranted considering lisp at its base is usually implemented in those "other general purpose languages". If you can implement lisp in a particular language then that particular language can de facto do (at least!) everything lisp can do.
- zachbeane 1y ago
  Common Lisp at its base is usually written in Common Lisp.
  - terminalbraid 1y ago
    I'm sure you are aware there is ultimately a chicken and egg problem here. Even given the case you presented, it doesn't invalidate the point that if it can implement lisp it must be able to do everything lisp can do. In fact given lisp's simplicity, I'd be hard pressed to call a language that couldn't implement lisp "general purpose".
    - greydius 1y ago
      "You're a very clever man, Mr. James, and that's a very good question," replied the little old lady, "but I have an answer to it. And it's this: The first turtle stands on the back of a second, far larger, turtle, who stands directly under him." "But what does this second turtle stand on?" persisted James patiently. To this, the little old lady crowed triumphantly, "It's no use, Mr. James—it's turtles all the way down."
    - grandempire 1y ago
      > I'm sure you are aware there is ultimately a chicken and egg problem here. You should learn more about compilers. There is a really cool idea waiting for you.
coolThingsFirst 1y ago
[flagged]
lukaslalinsky 1y ago
Whenever I hear someone talking about purely functional programming, no side effects, I wonder what kind of programs they are writing. Pretty much anything I've written over the last 30 years, the main purpose was to do I/O, it doesn't matter whether it's disk, network, or display. And that's where the most complications come from, these devices you are communicating with have quirks that need you need to deal with. Purely functional programming is very nice in theory, but how far can you actually get away with it?
- throw0101d 1y ago
  > Pretty much anything I've written over the last 30 years, the main purpose was to do I/O, it doesn't matter whether it's disk, network, or display. Erlang is a strictly (?) a functional language, and the reason why it was invented was to do network-y stuff in the telco space. So I'm not sure why I/O and functional programming would be opposed to each other like you imply.
  - troupo 1y ago
    > Erlang is a strictly (?) a functional language, First and foremost Erlang is a pragmatic programming language :)
- mejutoco 1y ago
  Any useful program has side-effects. IMHO the point is to isolate the part of the code that has the side-effects as much as possible, and keep the rest purely functionsl. That makes it easier to debug, test, and create good abstractions. Long term it is a very good approach.
- fulafel 1y ago
  This is discussing Common Lisp which is not even a mostly-functional language, and far from purely functional.
  - vkazanov 1y ago
    Somehow haskell and friends shifted the discussion around functional programming to pure vs non-pure! I am pretty sure it started with functions as first order objects as differentiator in schemes, lisps and ml family languages. Thus functional, but that's just a guess.
zoky 1y ago
I’m not really familiar with Lisp, but from glancing at this article it seems like all of these are really good arguments for programming in Ruby (my language of choice). Easily predictable syntax, simple substitution between variables and method calls, dynamic typing that provides ad hoc polymorphism… these are all prominent features of Ruby that are much clunkier in Python, JavaScript, or really any other commonly used language that I can think of. Lisp is on my list of languages to learn someday, but I’ve already tried to pick up Haskell, and while I did enjoy it and have nothing but respect for the language, I ultimately abandoned it because it was just too time-consuming for me to use on a day-to-day basis. Although I definitely got something out of learning to program in a purely functional language, and in fact feel like learning Haskell made me a much better Ruby programmer.
- rjsw 1y ago
  Common Lisp has compilers that produce fast code.
  - shadowgovt 1y ago
    On this topic: My absolute favorite Common Lisp special operator is `(the`. Usage, `(the value-type form`, as in `(the integer (do-a-bunch-of-math))`. At first glance, it looks like your strong-typing tool. And it can be. You can build a static analyzer that will match, as best it can, the type of the form to the value-type and throw errors if they don't match. It can also be a runtime check; the runtime is allowed to treat `the` as an assert and throw an error if there's a mismatch. But what the spec actually says is that it's a special operator that does nothing but return the evaluation of the form if the form's value is of the right type and the behavior is undefined otherwise. So relative to, say, C++, it's a clean entrypoint for undefined behavior; it signals to a Lisp compiler or interpreter "Hey, the programmer allows you to do shenanigans here to make the code go faster. Throw away the runtime type identifier, re-represent the data in a faster bit-pattern, slam this value into functions without runtime checks, assume particular optimizations will succeed, paint it red to make it go fasta... Just, go nuts."
- hxegon 1y ago
  I have about 6 years of ruby experience and if you're saying that ruby has "easily predictable syntax"... You really should try lisp. I liked clojure a lot coming from ruby because it has a lot of nice ergonomics other lisps lack. I think youd get a lot out of it.
revskill 1y ago
Programming is about coordination between tasks. Prove me wrong.
- whatnow37373 1y ago
  It doesn't have to be wrong to be irrelevant. Many things can be viewed as coordination problems. All of life can be viewed as being about coordination between tasks. But I want to engage in good faith and assume you have some way of making this productive. What angle are you going for?
  - revskill 1y ago
    Hm so your point is life is programming ?
    - whatnow37373 1y ago
      Isn't that obvious? :) I do wonder what happens if one of the tasks to be coordinated is "programming"?
      - nocman 1y ago
        that's metaprogramming :D
      - revskill 1y ago
        No. It's deep philosophy on software design.
- deleted 1y ago
  [deleted]
0xTJ 1y ago
I've never programmed in a Lisp, but I'd love to learn, it feels like one of those languages like Perl that are just good to know. I do have a job where getting better with SKILL would be useful.
djha-skin 1y ago
I agree with some statements OP makes but not others. Ultimately, I write in lisp because it's fun to write in Lisp due to its expressive power, ease of refactoring, and the Lisp Discord[1]. > Lisp is easier to remember, I don't feel this way. I'm always consulting the HyperSpec or googling the function names. It's the same as any other dynamically typed language, such as Python, this way to me. > has fewer limitations and hoops you have to jump through, Lisp as a language has incredibly powerful features find nowhere else, but there are plenty of hoops. The CLOS truly feels like a superpower. That said, there is a huge dearth of libraries. So in that sense, there's usually lots of hoops to jump through to write an app. It's just I like jumping through them because I like writing code as a hobby. So fewer limitations, more hoops (supporting libraries I feel the need to write). > has lower “friction” between my thoughts and my program, Unfortunately I often think in Python or Bash because those are my day job languages, so there's often friction between how I think and what I need to write. Also AI is allegedly bad at lisp due to reduced training corpus. Copilot works, sorta. > is easily customizable, Yup, that's its defining feature. Easy to add to the language with macros. This can be very bad, but also very good, depending on its use. It can be very worth it both to implementer and user to add to the language as part of a library if documented well and done right, or it can make code hard to read or use. It must be used with care. > and, frankly, more fun. This is the true reason I actually use Lisp. I don't know why. I think it's because it's really fun to write it. There are no limitations. It's super expressive. The article goes into the substitution principle, and this makes it easy to refactor. It just feels good having a REPL that makes it easy to try new ideas and a syntax that makes refactoring a piece of cake. The Lisp Discord[1] has some of the best programmers on the planet in it, all easy to talk to, with many channels spanning a wide range of programming interests. It just feels good to do lisp. 1: https://discord.gg/HsxkkvQ https://discord.gg/HsxkkvQ
DadBase 1y ago
Had a PalmPilot taped to a modem that did our auth. Lisp made the glue code feel like play. No types barking, no ceremony—just `(lambda (x) (tinker x))`. We didn’t debug, we conversed. Swapped thoughts with the REPL like it was an old friend.
- no_wizard 1y ago
  Though these are minor complaints, there is a couple things I'd like to change about a Lisp language. One is its the implicit function calls. For example, you'll usually see calls like this: `(+ 1 2)` which translates to 1 + 2, but I would find it more clear if it was `(+(1,2))` where you have a certain explicitness to it. It doesn't stop me from using Lisp languages (Racket is fun, and I been investigating Clojure) but it took way too long for the implicit function stuff to grok in my brain. My other complain is how the character `'` can have overloaded meaning, though I'm not entirely sure if this is implementation dependent or not
  - DadBase 1y ago
    First time I saw (+ 1 2), I thought it was a typo. Spent an hour trying to “fix” it into (1 + 2). My professor let me. Then he pointed at the REPL and said, “That’s not math—it’s music.” Never forgot that. The '? That’s the silent note.
    - no_wizard 1y ago
      It's due to Polish notation[0] as far as I understand it. This is how that notation for mathematics works. I suppose my suggestion would break those semantics. [0]: https://en.wikipedia.org/wiki/Polish_notation https://en.wikipedia.org/wiki/Polish_notation
      - DadBase 1y ago
        Aye, Polish notation sure. But what he gave me wasn’t a lecture, it was a spell. Syntax mattered less than rhythm. Parens weren’t fences, they were measures. The REPL didn’t care if I understood. It played anyway.
shadowgovt 1y ago
The most impressive thing, to me, about LISP is how the very, very small distance between the abstract syntax tree and the textual representation of the program allows for some very powerful extensions to the language with relatively little change. Take default values for function arguments. In most languages, that's a careful consideration of the nuances of the parser, how the various symbols nest and prioritize, whether a given symbol might have been co-opted for another purpose... In LISP, it's "You know how you can have a list of symbols that are the arguments for the function? Some of those symbols can be lists now, and if they are, the first element is the symbolic argument name and the second element is a default value."
i_love_retros 1y ago
Given that code is mostly written by LLMs now (or will be soon) isn't it better to just use the best language that fits these requirements: - LLM well trained on it. - Easy for human team to review. - Meets performance requirements. Prob not lisp?
- elllg 1y ago
  how is that anywhere close to a given?
- worthless-trash 1y ago
  Llm content is trained in popularity. If we use that as a metric there will never be any improvements or changes again.
  - i_love_retros 1y ago
    Who cares, in ten years the llm will output machine code
- deleted 1y ago
  [deleted]
discmonkey 1y ago
Good article. Funnily enough the throw away line "I don't see parentheses anymore". Is my greatest deterrent with lisp. It's not the parens persay, it's the fact that I'm used to reading up to down and left to right. Lisp without something like the clojure macro ->, means that I am reading from right to left, bottom to top - from inside out. If i programmed enough in lisp I think my brain would adjust to this, but it's almost like I can't full appreciate the language because it reads in the "wrong order".
- eadmund 1y ago
  > It's not the parens persay, it's the fact that I'm used to reading up to down and left to right. Lisp without something like the clojure macro ->, means that I am reading from right to left, bottom to top - from inside out. I’m not certain how true that really is. This: foo(bar(x), quux(y), z); looks pretty much identical to: (foo (bar x) (quux y) z) And of course if you want to assign them all to variables: int bar_x = bar(x); char quux_y = quux(y); return foo(bar_x, quux_y, z); is pretty much the same as: (let ((bar-x (bar x)) (quux-y (quux y))) (foo bar-x quux-y z)) FWIW, ‘per se’ comes from the Latin for ‘by itself.’
  - kibwen 1y ago
    The tragedy of Lisp is that postfix-esque method notation just plain looks better, especially for people with the expectation of reading left-to-right. let bar_x = x.bar() let quux_y = y.quux() return (bar_x, quux_y, z).foo()
    - tmtvl 1y ago
      De gustibus non disputandum est, I personally find the C++/Java/Rust/... style postfix notation (foo.bar()) to be appalling.
      - kazinator 1y ago
        TXR Lisp has this notation, combined with Lisp parethesis placement. Tather than obj.f(a, b). we have obj.(f a b). 1> (defstruct dog () (:method bark (self) (put-line "Woof!"))) #<struct-type dog> 2> (let ((d (new dog))) d.(bark)) Woof! t The dot notation is more restricted than in mainstream languages, and has a strict correspondence to underlying Lisp syntax, with read-print consistency. 3> '(qref a b c (d) e f) a.b.c.(d).e.f Cannot have a number in there; that won't go to dot notation: 4> '(qref a b 3 (d) e f) (qref a b 3 (d) e f) Chains of dot method calls work, by the way: 1> (defstruct circular () val (:method next (self) self)) #<struct-type circular> 2> (new circular val 42) #S(circular val 42) 3> *2.(next).(next).(next).(next).val 42 There must not be whitespace around the dot, though; you simply canot split this across lines. In other words: *2.(next) .(next) ;; nope! .(next) ;; what did I say? The "null safe" dot is .? The following check obj for nil; if so, they yield nil rather than trying to access the object or call a method: obj.?slot obj.?(method arg ...)
bgitarts 1y ago
Always read from experienced developers praising lisps, but why is it so rare in production applications?
- geor9e 1y ago
  People smart enough to read and write it are rare.
  - Capricorn2481 1y ago
    Is it about intelligence or just not being used to/having time for learning a different paradigm? I personally have used LISP a lot. It was a little rough at first, but I got it. Despite having used a lot of languages, it felt like learning programming again. I don't think there's something special about me that allowed me to grok it. And if that were the case, that's a horrible quality in a language. They're not supposed to be difficult to use.
    - noisy_boy 1y ago
      I think it allows very clever stuff, which I don't think is done routinely, but that's what gets talked about. I try to write clean functional style code in other languages which in my book means separation of things that have side effects and things that don't. I don't think I'll have difficulty writing standard stuff in Lisp with that approach. Just because it allows intricate wizardry doesn't mean it is inherently hard to get/use. I think the bigger issue would be ecosystem and shortage of talent pool.
  - tmtvl 1y ago
    I have hardly any issues reading and writing CL and I am so stupid even bags of bricks take pity on me. Intelligence is not a factor here.
- gpcz 1y ago
  Looking for a nice, solid, well-documented library to do something is difficult for most stuff. There are some real gems out there, but usually you end up having to roll your own thing. And Lisp generally encourages rolling your own thing.
curtisszmania 1y ago
[dead]
jll29 1y ago
As much as I sympathize with this post and similar ones, and as much I personally like functional thinking, LISP environments are not nearly as advanced anymore as they used to be. Which Common LISP or Scheme environment (that runs on, say Ubuntu Linux on a typical machine from today) gets even close to the past's LISP machines, for example? And which could compete with IntelliJ IDEA or PyCharm or Microsoft Code? https://ssw.jku.at/General/Staff/PF/genera-screenshots.html https://ssw.jku.at/General/Staff/PF/genera-screenshots.html
- vindarel 1y ago
  Common Lisp can compete with Python no problem, that's what matters to me. You get: - truly interactive development (never wait for something to restart, resume bugs from any stack frame after you fixed them), - self-contained binaries (easy deployment, my web app with all the dependencies, HTML and CSS is ±35MB) - useful compile-time warnings and errors, a keystroke away, for Haskell levels see Coalton (so better than Python), - fast programs compiled to machine code, - no GIL - connect to, inspect or update running programs (Slime/Swank), - good debugging tools (interactive debugger, trace, stepper, watcher (on some impls)…) - stable language and libraries (although the implementations improve), - CLOS and MOP, - etc - good editor support: Emacs, Vim, Atom/Pulsar (SLIMA), VScode (ALIVE), Jetbrains (SLT), Jupyter kernel, Lem, and more: https://lispcookbook.github.io/cl-cookbook/editor-support.html https://lispcookbook.github.io/cl-cookbook/editor-support.ht... What we might not get: - advanced refactoring tools -also because we need them less, thanks to the REPL and language features (macros, multiple return values…). --- For a lisp machine of yesterday running on Ubuntu or the browser: https://interlisp.org/ https://interlisp.org/
  - Capricorn2481 1y ago
    > self-contained binaries But Lispworks is the only one that makes actual tree-shaken binaries, whereas SBCL just throws everything in a pot and makes it executable, right? > good editor support: Emacs, Vim, Atom/Pulsar (SLIMA), VScode (ALIVE) I can't speak for those other editors, but my experience with Alive has been pretty bad. I can't imagine anyone recommending it has used it. It doesn't do what slime does, and because of that, you're forced to use Emacs. Calva for Clojure, however, is very good. I don't know why it can't be this way for CL.
submeta 1y ago
> Lisp's dreaded Cambridge Polish notation is uniform and universal. I don't have to remember whether a form takes curly braces or square brackets or what the operator precedency is or some weird punctuated syntax that was invented for no good reason. It is (operator operands ...) for everything. Nothing to remember. I basically stopped noticing the parenthesis 40 years ago. I can indent how I please. Well, that might be true for Scheme, but not for CL. There are endless forms for loops. I will never remember all of them. Or even a fraction of it. Going through Guy Steel’s CL book, I tend to think that I have a hard time remembering most of the forms, functions, and their signatures.
p0w3n3d 1y ago
Terry Pratchett's quote in one of his books (in fact I think this is a running gag, and appeared in multiple books): Five exclamation marks, a sure sign of an insane mind That's what I think about five closing parentheses too... But tbh I am also jealous, because I can't program in lisp at all
dramm 1y ago
Surely one of the the main reason to program in Lisp (and Haskell, and ???) is so you can write blog posts about doing so :-) (I do really like Lisp).
smckk 1y ago
Could a not-too trivial example like the difference between a Java sudoko solver and a lisp version with all the bells and whistles of FP such as functions as data and return values, recursion and macros be used to illustrate the benefits?
- tikotus 1y ago
  Here's one in Clojure using its core.logic library. I'd say it's pretty neat. You can do something similar in something like Prolog, but a Java implementation would look very different. https://github.com/sideshowcoder/core-logic-sudoku-solver/blob/master/src/solve_my_sudoku/core.clj https://github.com/sideshowcoder/core-logic-sudoku-solver/bl...
prakashrj 1y ago
[dead]
fithisux 1y ago
"Why I Program in Lisp" because you don't have money to waste on doctors?

286 points by ska80 1y ago

>It's less of a big deal these days, but properly working lambda expressions were only available in Lisp until recently. I think Haskell and ML had lambda expressions since like 1990.

imgabe 1y ago
Recent, compared to Lisp
- IsTom 1y ago
  Number of programmers that are in workforce that started before Standard ML (1983) is tiny and this argument would be relevant only to them.
  - mikelevins 1y ago
    The author of the referenced post is one of them, though.
User23 1y ago
The word “properly” is not only working hard here, but perhaps pointing to deeper concepts. In particular, it implies a coherent design around scope and extent. And, much more indirectly, it points to time. EVAL-WHEN has finally made a bit of a stir outside Lisp.
- BalinKing 1y ago
  Does this imply that lambda expressions in Haskell and ML don't have a "coherent design around scope and extent"? This is quite a claim, to be honest....
  - User23 1y ago
    No, it doesn’t imply that. There are plenty of more popular languages that don’t though.

damnitbuilds 1y ago

"properly working lambda expressions were only available in Lisp until recently." until -> since

JadeNB 1y ago
> "properly working lambda expressions were only available in Lisp until recently." > until -> since I think "only since recently" is not standard English, but, even if it were, I think it would change the intended meaning to say that they were not available in Lisp until recently, the opposite of what was intended. I find it clearer to move the "only": "were available only in Lisp until recently."
- mikelevins 1y ago
  It's perfectly good and idiomatic English, but it's an ambiguous formation and your suggested edit does clarify it.
  - JadeNB 1y ago
    I agree that "properly working lambda expressions were only available in Lisp until recently" is perfectly idiomatic, but easily misunderstood, English. I believe that the suggested fix "properly working lambda expressions were only available in Lisp since recently," which is what I was responding to, is not idiomatic. Claims about what is and isn't idiomatic aren't really subject to definitive proof either way, but it doesn't matter, because the suggester now agrees that it is not what was meant (https://news.ycombinator.com/item?id=43653723 https://news.ycombinator.com/item?id=43653723).
    - mikelevins 1y ago
      To be clear, the construction I’m endorsing is: "were available only in Lisp until recently", which is the construction that my editors typically proposed for similarly ambiguous deployments of "only". The ambiguity in the original placement is that it could be interpreted as only available as opposed to available and also something else. My editors always wanted it to be clear exactly what the "only" constrains.

efitz 1y ago

This is the first article I’ve ever read that made me want to go learn Lisp.

cutler 1y ago
Watch Rich Hickey's early Clojure videos and be blown away.
- laurent_du 1y ago
  Got any specific suggestion?
  - spicybbq 1y ago
    "Simple Made Easy" is pretty popular, there is a transcription with slides: https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/SimpleMadeEasy.md https://github.com/matthiasn/talk-transcripts/blob/master/Hi...
    - filoeleven 1y ago
      I like "Clojure, Made Simple" even more. https://www.youtube.com/watch?v=028LZLUB24s https://www.youtube.com/watch?v=028LZLUB24s Someone helpfully pulled out this chunk, which is a good illustration of why data is better than functions, a key driver of Clojure's design. https://www.youtube.com/watch?v=aSEQfqNYNAc https://www.youtube.com/watch?v=aSEQfqNYNAc
  - cess11 1y ago
    It's tangentially relevant, but I've enjoyed this one, about hammock driven programming. https://www.youtube.com/watch?v=f84n5oFoZBc https://www.youtube.com/watch?v=f84n5oFoZBc
dutchblacksmith 1y ago
Lispworks has a free editition with lots of examples. Look into PAIP from Peter Norvig.

terminalbraid 1y ago

> Other general purpose languages are more popular and ultimately can do everything that Lisp can (if Church and Turing are correct). I find these types of comments extremely odd and I very much support lisp and lisp-likes (I'm a particular fan of clojure). I can only see adding the parenthetical qualifier as a strange bias of throwing some kind of doubt into other languages which is unwarranted considering lisp at its base is usually implemented in those "other general purpose languages". If you can implement lisp in a particular language then that particular language can de facto do (at least!) everything lisp can do.

zachbeane 1y ago
Common Lisp at its base is usually written in Common Lisp.
- terminalbraid 1y ago
  I'm sure you are aware there is ultimately a chicken and egg problem here. Even given the case you presented, it doesn't invalidate the point that if it can implement lisp it must be able to do everything lisp can do. In fact given lisp's simplicity, I'd be hard pressed to call a language that couldn't implement lisp "general purpose".
  - greydius 1y ago
    "You're a very clever man, Mr. James, and that's a very good question," replied the little old lady, "but I have an answer to it. And it's this: The first turtle stands on the back of a second, far larger, turtle, who stands directly under him." "But what does this second turtle stand on?" persisted James patiently. To this, the little old lady crowed triumphantly, "It's no use, Mr. James—it's turtles all the way down."
  - grandempire 1y ago
    > I'm sure you are aware there is ultimately a chicken and egg problem here. You should learn more about compilers. There is a really cool idea waiting for you.

coolThingsFirst 1y ago

[flagged]

lukaslalinsky 1y ago

Whenever I hear someone talking about purely functional programming, no side effects, I wonder what kind of programs they are writing. Pretty much anything I've written over the last 30 years, the main purpose was to do I/O, it doesn't matter whether it's disk, network, or display. And that's where the most complications come from, these devices you are communicating with have quirks that need you need to deal with. Purely functional programming is very nice in theory, but how far can you actually get away with it?

throw0101d 1y ago
> Pretty much anything I've written over the last 30 years, the main purpose was to do I/O, it doesn't matter whether it's disk, network, or display. Erlang is a strictly (?) a functional language, and the reason why it was invented was to do network-y stuff in the telco space. So I'm not sure why I/O and functional programming would be opposed to each other like you imply.
- troupo 1y ago
  > Erlang is a strictly (?) a functional language, First and foremost Erlang is a pragmatic programming language :)
mejutoco 1y ago
Any useful program has side-effects. IMHO the point is to isolate the part of the code that has the side-effects as much as possible, and keep the rest purely functionsl. That makes it easier to debug, test, and create good abstractions. Long term it is a very good approach.
fulafel 1y ago
This is discussing Common Lisp which is not even a mostly-functional language, and far from purely functional.
- vkazanov 1y ago
  Somehow haskell and friends shifted the discussion around functional programming to pure vs non-pure! I am pretty sure it started with functions as first order objects as differentiator in schemes, lisps and ml family languages. Thus functional, but that's just a guess.

zoky 1y ago

I’m not really familiar with Lisp, but from glancing at this article it seems like all of these are really good arguments for programming in Ruby (my language of choice). Easily predictable syntax, simple substitution between variables and method calls, dynamic typing that provides ad hoc polymorphism… these are all prominent features of Ruby that are much clunkier in Python, JavaScript, or really any other commonly used language that I can think of. Lisp is on my list of languages to learn someday, but I’ve already tried to pick up Haskell, and while I did enjoy it and have nothing but respect for the language, I ultimately abandoned it because it was just too time-consuming for me to use on a day-to-day basis. Although I definitely got something out of learning to program in a purely functional language, and in fact feel like learning Haskell made me a much better Ruby programmer.

rjsw 1y ago
Common Lisp has compilers that produce fast code.
- shadowgovt 1y ago
  On this topic: My absolute favorite Common Lisp special operator is `(the`. Usage, `(the value-type form`, as in `(the integer (do-a-bunch-of-math))`. At first glance, it looks like your strong-typing tool. And it can be. You can build a static analyzer that will match, as best it can, the type of the form to the value-type and throw errors if they don't match. It can also be a runtime check; the runtime is allowed to treat `the` as an assert and throw an error if there's a mismatch. But what the spec actually says is that it's a special operator that does nothing but return the evaluation of the form if the form's value is of the right type and the behavior is undefined otherwise. So relative to, say, C++, it's a clean entrypoint for undefined behavior; it signals to a Lisp compiler or interpreter "Hey, the programmer allows you to do shenanigans here to make the code go faster. Throw away the runtime type identifier, re-represent the data in a faster bit-pattern, slam this value into functions without runtime checks, assume particular optimizations will succeed, paint it red to make it go fasta... Just, go nuts."
hxegon 1y ago
I have about 6 years of ruby experience and if you're saying that ruby has "easily predictable syntax"... You really should try lisp. I liked clojure a lot coming from ruby because it has a lot of nice ergonomics other lisps lack. I think youd get a lot out of it.

revskill 1y ago

Programming is about coordination between tasks. Prove me wrong.

whatnow37373 1y ago
It doesn't have to be wrong to be irrelevant. Many things can be viewed as coordination problems. All of life can be viewed as being about coordination between tasks. But I want to engage in good faith and assume you have some way of making this productive. What angle are you going for?
- revskill 1y ago
  Hm so your point is life is programming ?
  - whatnow37373 1y ago
    Isn't that obvious? :) I do wonder what happens if one of the tasks to be coordinated is "programming"?
    - nocman 1y ago
      that's metaprogramming :D
    - revskill 1y ago
      No. It's deep philosophy on software design.
deleted 1y ago
[deleted]

0xTJ 1y ago

I've never programmed in a Lisp, but I'd love to learn, it feels like one of those languages like Perl that are just good to know. I do have a job where getting better with SKILL would be useful.

djha-skin 1y ago

I agree with some statements OP makes but not others. Ultimately, I write in lisp because it's fun to write in Lisp due to its expressive power, ease of refactoring, and the Lisp Discord[1]. > Lisp is easier to remember, I don't feel this way. I'm always consulting the HyperSpec or googling the function names. It's the same as any other dynamically typed language, such as Python, this way to me. > has fewer limitations and hoops you have to jump through, Lisp as a language has incredibly powerful features find nowhere else, but there are plenty of hoops. The CLOS truly feels like a superpower. That said, there is a huge dearth of libraries. So in that sense, there's usually lots of hoops to jump through to write an app. It's just I like jumping through them because I like writing code as a hobby. So fewer limitations, more hoops (supporting libraries I feel the need to write). > has lower “friction” between my thoughts and my program, Unfortunately I often think in Python or Bash because those are my day job languages, so there's often friction between how I think and what I need to write. Also AI is allegedly bad at lisp due to reduced training corpus. Copilot works, sorta. > is easily customizable, Yup, that's its defining feature. Easy to add to the language with macros. This can be very bad, but also very good, depending on its use. It can be very worth it both to implementer and user to add to the language as part of a library if documented well and done right, or it can make code hard to read or use. It must be used with care. > and, frankly, more fun. This is the true reason I actually use Lisp. I don't know why. I think it's because it's really fun to write it. There are no limitations. It's super expressive. The article goes into the substitution principle, and this makes it easy to refactor. It just feels good having a REPL that makes it easy to try new ideas and a syntax that makes refactoring a piece of cake. The Lisp Discord[1] has some of the best programmers on the planet in it, all easy to talk to, with many channels spanning a wide range of programming interests. It just feels good to do lisp. 1: https://discord.gg/HsxkkvQ https://discord.gg/HsxkkvQ

DadBase 1y ago

Had a PalmPilot taped to a modem that did our auth. Lisp made the glue code feel like play. No types barking, no ceremony—just `(lambda (x) (tinker x))`. We didn’t debug, we conversed. Swapped thoughts with the REPL like it was an old friend.

no_wizard 1y ago
Though these are minor complaints, there is a couple things I'd like to change about a Lisp language. One is its the implicit function calls. For example, you'll usually see calls like this: `(+ 1 2)` which translates to 1 + 2, but I would find it more clear if it was `(+(1,2))` where you have a certain explicitness to it. It doesn't stop me from using Lisp languages (Racket is fun, and I been investigating Clojure) but it took way too long for the implicit function stuff to grok in my brain. My other complain is how the character `'` can have overloaded meaning, though I'm not entirely sure if this is implementation dependent or not
- DadBase 1y ago
  First time I saw (+ 1 2), I thought it was a typo. Spent an hour trying to “fix” it into (1 + 2). My professor let me. Then he pointed at the REPL and said, “That’s not math—it’s music.” Never forgot that. The '? That’s the silent note.
  - no_wizard 1y ago
    It's due to Polish notation[0] as far as I understand it. This is how that notation for mathematics works. I suppose my suggestion would break those semantics. [0]: https://en.wikipedia.org/wiki/Polish_notation https://en.wikipedia.org/wiki/Polish_notation
    - DadBase 1y ago
      Aye, Polish notation sure. But what he gave me wasn’t a lecture, it was a spell. Syntax mattered less than rhythm. Parens weren’t fences, they were measures. The REPL didn’t care if I understood. It played anyway.

shadowgovt 1y ago

The most impressive thing, to me, about LISP is how the very, very small distance between the abstract syntax tree and the textual representation of the program allows for some very powerful extensions to the language with relatively little change. Take default values for function arguments. In most languages, that's a careful consideration of the nuances of the parser, how the various symbols nest and prioritize, whether a given symbol might have been co-opted for another purpose... In LISP, it's "You know how you can have a list of symbols that are the arguments for the function? Some of those symbols can be lists now, and if they are, the first element is the symbolic argument name and the second element is a default value."

i_love_retros 1y ago

Given that code is mostly written by LLMs now (or will be soon) isn't it better to just use the best language that fits these requirements: - LLM well trained on it. - Easy for human team to review. - Meets performance requirements. Prob not lisp?

elllg 1y ago
how is that anywhere close to a given?
worthless-trash 1y ago
Llm content is trained in popularity. If we use that as a metric there will never be any improvements or changes again.
- i_love_retros 1y ago
  Who cares, in ten years the llm will output machine code
deleted 1y ago
[deleted]

discmonkey 1y ago

Good article. Funnily enough the throw away line "I don't see parentheses anymore". Is my greatest deterrent with lisp. It's not the parens persay, it's the fact that I'm used to reading up to down and left to right. Lisp without something like the clojure macro ->, means that I am reading from right to left, bottom to top - from inside out. If i programmed enough in lisp I think my brain would adjust to this, but it's almost like I can't full appreciate the language because it reads in the "wrong order".

eadmund 1y ago
> It's not the parens persay, it's the fact that I'm used to reading up to down and left to right. Lisp without something like the clojure macro ->, means that I am reading from right to left, bottom to top - from inside out. I’m not certain how true that really is. This: foo(bar(x), quux(y), z); looks pretty much identical to: (foo (bar x) (quux y) z) And of course if you want to assign them all to variables: int bar_x = bar(x); char quux_y = quux(y); return foo(bar_x, quux_y, z); is pretty much the same as: (let ((bar-x (bar x)) (quux-y (quux y))) (foo bar-x quux-y z)) FWIW, ‘per se’ comes from the Latin for ‘by itself.’
- kibwen 1y ago
  The tragedy of Lisp is that postfix-esque method notation just plain looks better, especially for people with the expectation of reading left-to-right. let bar_x = x.bar() let quux_y = y.quux() return (bar_x, quux_y, z).foo()
  - tmtvl 1y ago
    De gustibus non disputandum est, I personally find the C++/Java/Rust/... style postfix notation (foo.bar()) to be appalling.
    - kazinator 1y ago
      TXR Lisp has this notation, combined with Lisp parethesis placement. Tather than obj.f(a, b). we have obj.(f a b). 1> (defstruct dog () (:method bark (self) (put-line "Woof!"))) #<struct-type dog> 2> (let ((d (new dog))) d.(bark)) Woof! t The dot notation is more restricted than in mainstream languages, and has a strict correspondence to underlying Lisp syntax, with read-print consistency. 3> '(qref a b c (d) e f) a.b.c.(d).e.f Cannot have a number in there; that won't go to dot notation: 4> '(qref a b 3 (d) e f) (qref a b 3 (d) e f) Chains of dot method calls work, by the way: 1> (defstruct circular () val (:method next (self) self)) #<struct-type circular> 2> (new circular val 42) #S(circular val 42) 3> *2.(next).(next).(next).(next).val 42 There must not be whitespace around the dot, though; you simply canot split this across lines. In other words: *2.(next) .(next) ;; nope! .(next) ;; what did I say? The "null safe" dot is .? The following check obj for nil; if so, they yield nil rather than trying to access the object or call a method: obj.?slot obj.?(method arg ...)

bgitarts 1y ago

Always read from experienced developers praising lisps, but why is it so rare in production applications?

geor9e 1y ago
People smart enough to read and write it are rare.
- Capricorn2481 1y ago
  Is it about intelligence or just not being used to/having time for learning a different paradigm? I personally have used LISP a lot. It was a little rough at first, but I got it. Despite having used a lot of languages, it felt like learning programming again. I don't think there's something special about me that allowed me to grok it. And if that were the case, that's a horrible quality in a language. They're not supposed to be difficult to use.
  - noisy_boy 1y ago
    I think it allows very clever stuff, which I don't think is done routinely, but that's what gets talked about. I try to write clean functional style code in other languages which in my book means separation of things that have side effects and things that don't. I don't think I'll have difficulty writing standard stuff in Lisp with that approach. Just because it allows intricate wizardry doesn't mean it is inherently hard to get/use. I think the bigger issue would be ecosystem and shortage of talent pool.
- tmtvl 1y ago
  I have hardly any issues reading and writing CL and I am so stupid even bags of bricks take pity on me. Intelligence is not a factor here.
gpcz 1y ago
Looking for a nice, solid, well-documented library to do something is difficult for most stuff. There are some real gems out there, but usually you end up having to roll your own thing. And Lisp generally encourages rolling your own thing.

curtisszmania 1y ago

[dead]

jll29 1y ago

As much as I sympathize with this post and similar ones, and as much I personally like functional thinking, LISP environments are not nearly as advanced anymore as they used to be. Which Common LISP or Scheme environment (that runs on, say Ubuntu Linux on a typical machine from today) gets even close to the past's LISP machines, for example? And which could compete with IntelliJ IDEA or PyCharm or Microsoft Code? https://ssw.jku.at/General/Staff/PF/genera-screenshots.html https://ssw.jku.at/General/Staff/PF/genera-screenshots.html

vindarel 1y ago
Common Lisp can compete with Python no problem, that's what matters to me. You get: - truly interactive development (never wait for something to restart, resume bugs from any stack frame after you fixed them), - self-contained binaries (easy deployment, my web app with all the dependencies, HTML and CSS is ±35MB) - useful compile-time warnings and errors, a keystroke away, for Haskell levels see Coalton (so better than Python), - fast programs compiled to machine code, - no GIL - connect to, inspect or update running programs (Slime/Swank), - good debugging tools (interactive debugger, trace, stepper, watcher (on some impls)…) - stable language and libraries (although the implementations improve), - CLOS and MOP, - etc - good editor support: Emacs, Vim, Atom/Pulsar (SLIMA), VScode (ALIVE), Jetbrains (SLT), Jupyter kernel, Lem, and more: https://lispcookbook.github.io/cl-cookbook/editor-support.html https://lispcookbook.github.io/cl-cookbook/editor-support.ht... What we might not get: - advanced refactoring tools -also because we need them less, thanks to the REPL and language features (macros, multiple return values…). --- For a lisp machine of yesterday running on Ubuntu or the browser: https://interlisp.org/ https://interlisp.org/
- Capricorn2481 1y ago
  > self-contained binaries But Lispworks is the only one that makes actual tree-shaken binaries, whereas SBCL just throws everything in a pot and makes it executable, right? > good editor support: Emacs, Vim, Atom/Pulsar (SLIMA), VScode (ALIVE) I can't speak for those other editors, but my experience with Alive has been pretty bad. I can't imagine anyone recommending it has used it. It doesn't do what slime does, and because of that, you're forced to use Emacs. Calva for Clojure, however, is very good. I don't know why it can't be this way for CL.

submeta 1y ago

> Lisp's dreaded Cambridge Polish notation is uniform and universal. I don't have to remember whether a form takes curly braces or square brackets or what the operator precedency is or some weird punctuated syntax that was invented for no good reason. It is (operator operands ...) for everything. Nothing to remember. I basically stopped noticing the parenthesis 40 years ago. I can indent how I please. Well, that might be true for Scheme, but not for CL. There are endless forms for loops. I will never remember all of them. Or even a fraction of it. Going through Guy Steel’s CL book, I tend to think that I have a hard time remembering most of the forms, functions, and their signatures.

p0w3n3d 1y ago

Terry Pratchett's quote in one of his books (in fact I think this is a running gag, and appeared in multiple books): Five exclamation marks, a sure sign of an insane mind That's what I think about five closing parentheses too... But tbh I am also jealous, because I can't program in lisp at all

dramm 1y ago

Surely one of the the main reason to program in Lisp (and Haskell, and ???) is so you can write blog posts about doing so :-) (I do really like Lisp).

smckk 1y ago

Could a not-too trivial example like the difference between a Java sudoko solver and a lisp version with all the bells and whistles of FP such as functions as data and return values, recursion and macros be used to illustrate the benefits?

tikotus 1y ago
Here's one in Clojure using its core.logic library. I'd say it's pretty neat. You can do something similar in something like Prolog, but a Java implementation would look very different. https://github.com/sideshowcoder/core-logic-sudoku-solver/blob/master/src/solve_my_sudoku/core.clj https://github.com/sideshowcoder/core-logic-sudoku-solver/bl...

prakashrj 1y ago

[dead]

fithisux 1y ago

"Why I Program in Lisp" because you don't have money to waste on doctors?