Why I Program in Lisp

http://funcall.blogspot.com/2025/04/why-i-program-in-lisp.html

by ska80 • 1 year ago

286 272 1 year ago

funcall.blogspot.com

DeathArrow4• 1 year 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• 1 year ago

Recent, compared to Lisp

IsTom• 1 year 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.

User232• 1 year 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.

BalinKing2• 1 year 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....

damnitbuilds2• 1 year ago

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

until -> since

JadeNB2• 1 year 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."

mikelevins4• 1 year ago

It's perfectly good and idiomatic English, but it's an ambiguous formation and your suggested edit does clarify it.

BalinKing2• 1 year ago

Personally, I'd probably move "until recently" to the front: "Until recently, properly working lambda expressions were only available in Lisp."

argentier• 1 year ago

"properly working lambda expressions were available only in lisp until recently."

efitz• 1 year ago

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

cutler• 1 year ago

Watch Rich Hickey's early Clojure videos and be blown away.

laurent_du• 1 year ago

Got any specific suggestion?

dutchblacksmith2• 1 year ago

Lispworks has a free editition with lots of examples. Look into PAIP from Peter Norvig.

larve2• 1 year ago

Even putting the common lisp aside, PAIP is my favourite book about programming in general, by FAR. Norvig's programming style is so clear and expressive, the book touches on more "pedestrian" parts of programming: building tools / performance / debugging, but also walks you through a serious set of algorithms that are actually practical and that I use regularly (and they shape your thinking): search, pattern matching, to some extent unification, building interpreters and compilers, manipulating code as data.

It's also extremely fun, you go from building Eliza to a full pattern matcher to a planning agent to a prolog compiler.

phlakaton4• 1 year ago

Paul Graham's On Lisp is also a powerful argument to try the language, even if some of the stuff it presents is totally bonkers. :-D

https://www.paulgraham.com/onlisp.html

psb• 1 year ago

what are the bonkers parts? (just curious)

__MatrixMan__• 1 year ago

Next time you see a HN post on a lisp-centric topic, click into the comments. I'll bet you a nickel that they'll be happier than most. Instead of phrases like "dumpster fire" they're using words like "joyful".

That's why I keep rekindling my learn-lisp effort. It feels like I'm just scratching the surface re: the fun that can be had.

dutchblacksmith2• 1 year ago

Never been happier since building an Erp system in pure lisp and postgresql.

terminalbraid3• 1 year 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• 1 year ago

Common Lisp at its base is usually written in Common Lisp.

terminalbraid3• 1 year 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".

pgwhalen• 1 year ago

Isn’t this just a cheeky joke? I.e. “if Einstein is right about this whole theory of relatively thing”

volemo• 1 year ago

I believe ‘twas a joke.

russellbeattie• 1 year ago

One doesn't have to invoke Turing or Church to show all languages can do the same things.

Any code that runs on a computer (using the von Neumann architecture) boils down to just a few basic operations: Read/write data, arithmetic (add/subtract/etc.), logic (and/or/not/etc.), bit-shifting, branches and jumps. The rest is basically syntactic sugar or macros.

If your preferred programming language is a pre-compiled type-safe object oriented monster with polymorphic message passing via multi-process co-routines, or high-level interpreted purely functional archetype of computing perfection with just two reserved keywords, or even just COBOL, it's all going to break down eventually to the ops above.

terminalbraid3• 1 year ago

You can trivially devise a language that doesn't, though? Let's say I have a language that can return 0 and only 0. It cannot reproduce lisp.

Capricorn24814• 1 year ago

Sometimes, when people say one language can't do what another does, they aren't talking about outputs. Nobody is arguing that lisp programs can do arithmetic and others can't, they're arguing that there are ergonomics to lisp you can't approach in other languages.

But even so

it's all going to break down eventually to the ops above.

That's not true either. Different runtimes will break down into a completely different version of the above. C is going to boil down to a different set of instructions than Ruby. That would make Ruby incapable of doing some tasks, even with a JIT. And writing performance sensitive parts in C only proves the point.

"Any language can do anything" is something we tell juniors who have decision paralysis on what to learn. That's good for them, but it's not true. I'm not going to tell a client we're going to target a microcontroller with PHP, even if someone has technically done it.

varjag• 1 year ago

There are several Lisp implementations (including fully-fledged operating systems) which are implemented in Lisp top to bottom.

taeric• 1 year ago

This is conflating slightly different things, though? One is that you can build a program that does the same thing. The other is that you can do the same things with the language.

There are special forms in LISP, but that is a far cry from the amount of magic that can only be done in the compiler or at runtime for many languages out there.

thethimble• 1 year ago

Brainfuck is also Turing complete but that isn’t an argument that it’s a good replacement for LISP or any other language.

bitwize• 1 year ago

Yes, but sometimes doing the things Lisp can do in another language as easily and flexibly as they are done in Lisp has, as a first step, implementing Lisp in the target language.

For a famous example, see Clasp: https://github.com/clasp-developers/clasp

lukaslalinsky5• 1 year 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• 1 year 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.

troupo5• 1 year ago

Erlang is a strictly (?) a functional language,

First and foremost Erlang is a pragmatic programming language :)

mejutoco• 1 year 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• 1 year ago

This is discussing Common Lisp which is not even a mostly-functional language, and far from purely functional.

vkazanov5• 1 year 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.

mikelevins4• 1 year ago

He says Lisp, rather than Common Lisp. Sure, given the context he's writing in now, maybe he means Common Lisp, but Joe Marshall was a Lisp programmer before Common Lisp existed, so he may not mean Common Lisp specifically.

vkazanov5• 1 year ago

I had the same question until I understood one key pattern of pure functional programming. Not sure it has a name but here goes.

There is world, and there is a model of the world - your program. The point of the program, and all functions, is to interact with the model. This part, data structures and all, is pure.

The world interacts with the model through an IO layer, as in haskell.

Purity is just an enforcement of this separation.

skydhash5• 1 year ago

I thinks it the imperative shell, functional core. The shell provide the world, the core act on it, the the shell commit it at various intervals.

Functional React follows this pattern. The issue is when the programmer thinks the world is some kind of stable state that you can store results in. It’s not, the whole point is to be created anew and restart the whole computation flow. The escape hatches are the hooks. And each have a specific usage and pattern to follow to survive world recreation. Which why you should be careful with them as they are effectively world for subcomponents. So when you add to the world with hooks, interactions with the addition should stay at the same level

perrygeo3• 1 year ago

Not even the most fanatical functional programming zealots would claim that programs can be 100% functional. By definition, a program requires inputs and outputs, otherwise there is literally no reason to run it.

Functional programming simply says: separate the IO from the computation.

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.

Every useful program ever written takes inputs and produces outputs. The interesting part is what you actually do in the middle to transforms inputs -> outputs. And that can be entirely functional.

markus_zhang2• 1 year ago

separate the IO from the computation.

Can you please elaborate on this point? I read it as this web page (https://wiki.c2.com/?SeparateIoFromCalculation) describes, but I fail to see why it is a functional programming concept.

DeathArrow4• 1 year ago

Not even the most fanatical functional programming zealots would claim that programs can be 100% functional. By definition, a program requires inputs and outputs, otherwise there is literally no reason to run it.

So a program it's a function that transforms the input to the output.

DeathArrow4• 1 year ago

separate the IO from the computation.

What about managing state? I think that is an important part and it's easy to mess it.

whatnow373738• 1 year ago

The interesting part is what you actually do in the middle to transforms inputs -> outputs.

Can you actually name something? The only thing I can come up with is working with interesting algorithms or datastructures, but that kind of fundamental work is very rare in my experience. Even if you do, it's quite often a very small part of the entire project.

sync132982• 1 year ago

Every useful program ever written takes inputs and produces outputs. The interesting part is what you actually do in the middle to transforms inputs -> outputs. And that can be entirely functional.

My work needs pseudorandom numbers throughout the big middle, for example, drawing samples from probability distributions and running randomized algorithms. That's pretty messy in a FP setting, particularly when the PRNGs get generated within deeply nested libraries.

PhilipRoman• 1 year ago

There is no reason you can't use side effects in pure functional programming. You just need to provide the appropriate description of the side effect to avoid caching and force a particular evaluation order. If you have linear types, you do it by passing around opaque tokens. I'm not entirely sure how IO works in Haskell, but I think the implementation is similar. Even C compilers use a system like that internally.

mrkeen10• 1 year ago

Think of it like other features:

* Encapsulation? What's the point of having it if's perfectly sealed off from the world? Just dead-code eliminate it.

* Private? It's not really private if I can Get() to it. I want access to that variable, so why hide it from myself? Private adds nothing because I can just choose not to use that variable.

* Const? A constant variable is an oxymoron. All the programs I write change variables. If I want a variable to remain the same, I just wont update it.

Of course I don't believe in any of the framings above, but it's how arguments against FP typically sound.

Anyway, the above features are small potatoes compared to the big hammer that is functional purity: you (and the compiler) will know and agree upon whether the same input will yield the same output.

Where am I using it right now?

I'm doing some record linkage - matching old transactions with new transactions, where some details may have shifted. I say "shifted", but what really happened was that upstream decided to mutate its data in-place. If they'd had an FPer on the team, they would not have mutated shared state, and I wouldn't even need to do this work. But I digress.

Now I'm trying out Dijkstra's algorithm, to most efficiently match pairs of transactions. It's a search algorithm, which tries out different alternatives, so it can never mutate things in-place - mutating inside one alternative will silently break another alternative. I'm in C#, and was pleasantly surprised that ImmutableList etc actually exist. But I wish I didn't have to be so vigilant. I really miss Haskell doing that part of my carefulness for me.

DeathArrow4• 1 year ago

I'm in C#, and was pleasantly surprised that ImmutableList etc actually exist.

C# has introduced many functional concepts. Records, pattern matching, lambda functions, LINQ.

The only thing I am missing and will come later is discriminated unions.

Of course, F# is more fited for the job if you want a mostly functional workflow.

pfdietz2• 1 year ago

Those starred rhetorical questions initially looked to me like a critique of Lisp! Because that's how Lisp (particularly Common Lisp) works. All those things are softish. You can see unexported symbols even if you're not supposed to use them. There is no actual privacy unless you do something special like unintern then recreate a symbol.

bobbylarrybobby• 1 year ago

you (and the compiler) will know and agree upon whether the same input will yield the same output

What exactly does this mean? Haskell has plenty of non-deterministic functions — everything involving IO, for instance. I know that IO is non-deterministic, but how is that expressed within the language?

Xmd5a• 1 year ago

The boundary between the program and the rest of the system allows I/O of course. What FP does is "virtualize" I/O by representing it as data (thus it can be passed around). Then at some point these changes get "committed" to the outside. Representing I/O separately from how it is carried out allows a lot of things to be done, such as cancelling (ctrl+z) operations.

AstroBen2• 1 year ago

It's about minimizing and isolating state and side effects, not eliminating them completely

Functional core, imperative shell is a common pattern. Keep the side effects on the outside. Instead of doing side effects directly, just return a data structure that can be used to enact the side effect

zozbot234• 1 year ago

The point of functional, "sans I/O" style is to separate the definition of I/O from the rest of your logic. You're still doing I/O, but what sorts of I/O you're doing has a clear self-contained definition within your program. https://sans-io.readthedocs.io/how-to-sans-io.html

brap• 1 year ago

There are ways to handle side effects with pure functions only (it’s kind of cheating, because the actual side effects are performed by the non-pure runtime/framework that’s abstracted away, while the pure user code just defines when to perform them and how to respond to them). It’s possible, but it gets very awkward very fast. I wouldn’t use FP for any part of the code that deals with IO.

lukaslalinsky5• 1 year ago

That was the question, what would you use FP for?

hnfong• 1 year ago

I never believed any FP evangelist ever since I realized I can't even write quicksort with it *.

(* Yes, you can technically write it procedurally like a good C programmer, sure.)

larve2• 1 year ago

It's always hard to parse if people mean functional programming when bringing up Lisp. Common Lisp certainly is anything but a functional language. Sure, you have first order functions, but you in a way have that in pretty much all programming languages (including C!).

But most functions in Common Lisp do mutate things, there is an extensive OO system and the most hideous macros like LOOP.

I certainly never felt constrained writing Common Lisp.

That said, there are pretty effective patterns for dealing with IO that allow you to stay in a mostly functional / compositional flow (dare I say monads? but that sounds way more clever than it is in practice).

behnamoh• 1 year ago

It's always hard to parse if people mean functional programming when bringing up Lisp. Common Lisp certainly is anything but a functional language. Sure, you have first order functions, but you in a way have that in pretty much all programming languages (including C!).

It's less about what the language "allows" you to do and more about how the ecosystem and libraries "encourage" you to do.

jcranmer• 1 year ago

The idea of pure functional programming is that you can really go quite far if you think of your program as a pure function f(input) -> outputs with a messy impure thing that calls f and does the necessary I/O before/after that.

Batch programs are easy to fit in this model generally. A compiler is pretty clearly a pure function f(program source code) -> list of instructions, with just a very thin layer to read/write the input/output to files.

Web servers can often fit this model well too: a web server is an f(request, database snapshot) -> (response, database update). Making that work well is going to be gnarly in the impure side of things, but it's going to be quite doable for a lot of basic CRUD servers--probably every web server I've ever written (which is a lot of tiny stuff, to be fair) could be done purely functional without much issue.

Display also can be made work: it's f(input event, state) -> (display frame, new state). Building the display frame here is something like an immediate mode GUI, where instead of mutating the state of widgets, you're building the entire widget tree from scratch each time.

In many cases, the limitations of purely functional isn't that somebody somewhere has to do I/O, but rather the impracticality of faking immutability if the state is too complicated.

lukaslalinsky5• 1 year ago

I guess my point is that you actually have to write the impure code somehow and it's hard, external world has tendencies to fail, needs to be retried, coordinated with other things. You have to fake all these issues. In your web server examples, if you need to a cache layer for certain part of the data, you really can't without encoding it to the state management tooling. And this point you are writing a lot of non-functional code in order to glue it together with pure functions and maybe do some simple transformation in the middle. Is it worth it?

I have respect for OCaml, but that's mostly because it allows you to write mutable code fairly easily.

Roc codifies the world vs core split, but I'm skeptical how much of the world logic can be actually reused across multiple instances of FP applications.

timonoko• 1 year ago

OpenSCAD is such a good school of functional programming. There is no "time" or flow of execution. Or variables, scopes and environments. You are not constructing a program, but a static model which has desired properties in space and time.

diggan• 1 year ago

Whenever I hear someone talking about purely functional programming, no side effects, I wonder what kind of programs they are writing

Where have you ever heard anyone talk about side-effect free programs, outside of academic exercises? The linked post certainly isn't about 100% side-effect/state free code.

Usually, people talk about minimizing side-effects as much as possible, but since we build programs to do something, sometimes connected to the real world, it's basically impossible to build a program that is both useful and 100% side-effect free, as you wouldn't be able to print anything to the screen, or communicate with other programs.

And minimizing side-effects (and minimizing state overall) have a real impact on how easy it is to reason about the program. Being really carefully about where you mutate things, leads to most of the code being very explicit about what it's doing, and code only affects data that is close to where the code itself is, compared to intertwined state mutation, where things everywhere in the codebase can affect state anywhere.

djha-skin2• 1 year ago

I wrote a recursive descent parser in Lisp for a YAML replacement language[1]. It wasn't difficult. Lisp makes it easy to write I/O, but also easy to separate logic from I/O. This made it easy for me to write unit tests without mocking.

I also wrote a toy resource scheduler at an HTTP endpoint in Haskell[2]. Writing I/O in Haskell was a learning curve but was ultimately fine. Keeping logic separate from I/O was the easy thing to do.

1: https://github.com/djha-skin/nrdl

2: https://github.com/djha-skin/lighthouse

epgui• 1 year ago

Everyone writes real programs that have side effects. Functional programming is no different. But the side effects happen in specific ways or places, rather than all over the place.

johnnyjeans• 1 year ago

As others have said, a pure program is a useless program. The only place stuff like that has in this world is as a proof assistant.

What I will add is look up how the GHC runtime works, and the STGM. You may find it extremely interesting. I didn't "get" functional programming until I found out about how exotic efficient execution of functional programs ends up being.

yogsototh• 1 year ago

"Purely Functional Programming", I guess mostly Haskell/Purescript.

So this only really mean:

Purely Functional Programming by default.

In most programming languages you can write

"hello " + readLine()

And this would intermix pure function (string concatenation) and impure effect (asking the user to write some text). And this would work perfectly.

By doing so, the order of evaluation becomes essential.

With a pure functional programming (by default).

you must explicitely separate the part of your program doing I/O and the part of your program doing only pure computation. And this is enforced using a type system focusing on I/O. Thus the difference between Haskell default `IO` and OCamL that does not need it for example.

in Haskell you are forced by the type system to write something like:

    do 
      name <- getLine
      let s = "Hello " <> name <> "!"
      putStrLn s

you cannot mix the `getLine` directly in the middle of the concatenation operation.

But while this is a very different style of programming, I/O are just more explicit, and they "cost" more, because writing code with I/O is not as elegant, and easy to manipulate than pure code. Thus it naturally induce a way of coding that try to really makes you conscious about the part of your program that need IO and the part that you could do with only pure function.

In practice, ... yep, you endup working in a "Specific to your application domain" Monad that looks a lot like the IO Monad, but will most often contains IO.

Another option is to use a free monad for your entire program that makes you able to write in your own domain language and control its evaluation (either using IO or another system that simulates IO but is not really IO, typically for testing purpose).

lukaslalinsky5• 1 year ago

This is a good write up. Thank you for it. My experience with Haskell only comes from university and the focus there was primarily on the pure side of the code. I'll have a look at how Haskell deals with the pure/inpure split for some real-world tasks. The Lisp way of doing it just seems weird to me, too ad hoc, not really structured.

dehrmann• 1 year ago

The pragmatic approach is to see that FP's key point is statelessness and use that in your code (written in more mainstream languages) when appropriate.

krferriter2• 1 year ago

Most of the code in most programs is not the part that is doing the I/O. It's doing stuff on a set of values to transform them. It gets values from somewhere, does stuff using those values, and then outputs some values. The complicated part is not the transfer of the final byte sequence to whatever I/O interface they go to, the core behavior of the program is the stuff that happens before that.

zoky• 1 year 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• 1 year ago

Common Lisp has compilers that produce fast code.

shadowgovt4• 1 year 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• 1 year 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.

shadowgovt4• 1 year ago

Ruby and LISP have a lot of overlap. To my money, LISP is a little more predictable because the polymorphic nature of the language itself is always in your face; you know that you're always staring at a list, and you have no idea without context whether that list is being evaluated at runtime, is literal, or is the body of a macro.

Ruby has all those features but (to my personal taste) makes it less obvious that things are that wilding.

(But in both languages I get to play the game "Where the hell is this function or variable defined?" way more often than I want to. There are some advantages to languages that have a strict rule about modular encapsulation and requiring almost everything into the current context... With Rails, in particular, I find it hard to understand other people's code because I never know if a given symbol was defined in another file in the codebase, defined in a library, or magicked into being by doing string transformations on a data source... In C++, I have to rely on grep a lot to find definitions, but in Ruby on Rails not even grep is likely to find me the answer I want! Common LISP is similarly flexible with a lot of common library functions that magick new symbols into existence, but the codebases I work on in LISP aren't as large as the Ruby on Rails codebases I touch, so it bites me less).

cess112• 1 year ago

If you want something similar to Ruby but more functional, try Elixir. The similarities are superficial but might be enough to ease you in.

Haskell is weird. You can express well defined problems with relative ease and clarity, but performance can be kind of wonky and there's a lot more ceremony than your typical Lisp or Scheme or close relative of those. F# can give you a more lispish experience with a threshold about as low as Haskell, but comes with the close ties to an atrocious corporation and similar to Clojure it's not exactly a first class citizen in the environment.

Building stuff in Lisp-likes typically don't entail the double programming languages of the primary one and a second one to program the type system, in that way they're convenient in a way similar to Ruby. I like the parens and how they explicitly delimit portions that quite closely relate to the AST-step in compilation or whatever the interpreter sees, it helps with moving things around and molding the code quickly.

revskill3• 1 year ago

Programming is about coordination between tasks. Prove me wrong.

whatnow373738• 1 year 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?

revskill3• 1 year ago

Hm so your point is life is programming ?

0xTJ• 1 year 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-skin2• 1 year 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

DadBase3• 1 year 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_wizard4• 1 year 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

DadBase3• 1 year 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.

wdkrnls2• 1 year ago

R works exactly as you describe. You can type `+`(1, 2) and get 3 because in R everything that happens is a function call even if a few binary functions get special sugar so you can type 1 + 2 for them as well. The user can of course make their own of these if they wrap them in precents. For example: `%plus%` = function(a, b) { `+`(a, b)}. A few computer algebra systems languages provide even more expressivity like yacas and fricas. The later even has a type system.

eyelidlessness2• 1 year ago

How is it implicit? The open parenthesis is before the function name rather than after, but the function isn’t called without both parentheses.

If you want to use commas, you can in Lisp dialects I’m familiar with—they’re optional because they’re treated as whitespace, but nothing is stopping you if you find them more readable!

MarceColl5• 1 year ago

It's not really implicit though, the first element of a list that is evaluated is always a function. So (FUN 1 2) is an explicit function call. The problem is that it doesn't look like C-like languages, not that it's not explicit.

In theory ' just means QUOTE, it should not be overloaded (although I've mostly done Common Lisp, so no idea if in other impl that changes). Can you show an example of overloaded meaning?

bcrosby95• 1 year ago

func(a, b) is basically the same as (func a b). You're just moving the parens around. '+' is extra 'strange' because in most languages it isn't used like other functions: imagine if you had to write +(1, 2) in every C-like.

panzagl• 1 year ago

First person to ask for more parenthesis in Lisp.

zelphirkalt4• 1 year ago

Surely you mean (+ (, 1 2))

;)

Reefersleep• 1 year ago

It's not implicit in this case, it's explicit. + is the function you're calling. And there's power in having mathematical operations be functions that you can manipulate and compose like all other functions, instead of some special case of infix implicit (to me, yeah) function calling, like 1 + 2, where it's no longer similar to other functions.

owlstuffing• 1 year ago

No types barking

No thanks

codr74• 1 year ago

Common Lisp supports gradual typing and will (from my experience) do a much better job of analyzing code and pointing out errors than your typical scripting language.

tmtvl5• 1 year ago

The reason I switched from Scheme to Common Lisp was because I could say...

  (defun foo (x)
    (declare (type (Integer 0 100) x))
    (* x
       (get-some-value-from-somewhere-else)))

And then do a (describe 'foo) in the REPL to get Lisp to tell me that it wants an integer from 0 to 100.

shadowgovt4• 1 year 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_retros2• 1 year 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• 1 year ago

how is that anywhere close to a given?

worthless-trash• 1 year 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_retros2• 1 year ago

Who cares, in ten years the llm will output machine code

discmonkey• 1 year 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".

eadmund2• 1 year 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.’

kibwen2• 1 year 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()

all22• 1 year ago

The lisp is harder to read, for me. The first double paren is confusing.

    (let (bar-x (bar x))
         (quux-y (quux y)))
    (foo bar-x quux-y z)

Why is the second set of parens necessary?

The nesting makes sense to an interpreter, I'm sure, but it doesn't make sense to me.

Is each top-level set of parens a 'statement' that executes? Or does everything have to be embedded in a single list?

This is all semantics, but for my python-addled brain these are the things I get stuck on.

AdieuToLogic4• 1 year ago

One of the awesome things about LISP is it encourages a developer to think of programs as an AST[0].

One of the things that sucks about LISP is - master it and every programming language is nothing more than an AST[0].

:-D

0 - https://en.wikipedia.org/wiki/Abstract_syntax_tree

whalesalad• 1 year ago

This is the most elementary hurdle a lisp programmer will face. You do indeed become adjusted to it quite quickly. I wouldn’t let this deter you from exploring something like Clojure more deeply.

MarceColl5• 1 year ago

I think it really depends, in Common Lisp for example I don't think that's the case:

  (progn
    (do-something)
    (do-something-else)
    (do-a-third-thing))

The only case where it's a bit different and took some time for me to adjust was that adding bindings adds an indent level.

  (let ((a 12)
        (b 14))
    (do-something a)
    (do-something-else b)
    (setf b (do-third-thing a b)))

It's still mostly top-bottom, left to right. Clojure is quite a bit different, but it's not a property of lisps itself I'd say. I have a hard time coming up with examples usually so I'm open to examples of being wrong here.

fc417fc8024• 1 year ago

Your example isn't a very functional code style though so I don't know that I'd consider it to be idiomatic. Generally code written in a functional style ends up indented many layers deep. Below is a quick (and quite tame) example from one of the introductory guides for Racket. My code often ends up much deeper. Consider what it would look like if one of the cond branches contained a nested cond.

  (define (start request)
    (define a-blog
      (cond [(can-parse-post? (request-bindings request))
             (cons (parse-post (request-bindings request))
                   BLOG)]
            [else
             BLOG]))
    (render-blog-page a-blog request))

https://docs.racket-lang.org/continue/index.html

buttercraft• 1 year ago

reading from right to left, bottom to top - from inside out

I don't understand why you think this. Can you give an example?

fc417fc8024• 1 year ago

Does this example help? https://github.com/ghollisjr/cl-ana/blob/master/binary-tree/...

kazinator5• 1 year ago

  (log (sqrt (sin (* 2 pi x)))

Uhhrrr• 1 year ago

per se

pfdietz2• 1 year ago

It's easy enough to add -> (and related arrow operators) to Common Lisp as macros.

https://github.com/hipeta/arrow-macros

The common complaint that Common Lisp lacks some feature is often addressed by noting how easy it is to add that feature.

tmtvl5• 1 year ago

Besides arrow-macros there's also cl-arrows, which is basically exactly the same thing, and Serapeum also has arrow macros (though the -> macro in Serapeum is for type definitions, the Clojure-style arrow macro is hence relegated to ~>).

drob518• 1 year ago

Been programming in Lisp for a while. The parents disappear very quickly. One trick to accelerate it is to use a good editor with structural editing (e.g., paredit in Emacs or something similar). All you editing is done on balanced expressions. When you type “(“, the editor automatically inserts “)” with your cursor right in between. If you try to delete a “)”, the editor ignores you until you delete everything inside and the “(“. Basically, you start editing at the expression level, not so much at the character or even line level. You just notice the indentation/shape of the code, but you never spend time counting parentheses or trying to balance anything. Everything is balanced all the time and you just write code.

AdieuToLogic4• 1 year 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.

  Language shapes the way we think, and determines what we can think about.
  - Benjamin Lee Whorf[0]

From the comments in the post:

  Ask a C programmer to write factorial and you will likely
  get something like this (excuse the underbars, they are
  there because blogger doesn't format code in comments):

  int factorial (int x) {
      if (x == 0)
          return 1;
      else
          return x * factorial (x - 1);
  }

  And the Lisp programmer will give you:

  (defun factorial (x)
    (if (zerop x)
        1
        (* x (factorial (- x 1)))))

Let's see how we can get from the LISP version to something akin to the C version.

First, let's "modernize" the LISP version by replacing parentheses with "curly braces" and add some commas and newlines just for fun:

  {
    defun factorial { x },
    {
    if { zerop x },
      1 {
        *,
        x {
          factorial {
            - { x, 1 }
          }
        }
      }
    }
  }

This kinda looks like a JSON object. Let's make it into one and add some assumed labels while we're at it.

  {
    "defun" : {
      "factorial" : { "argument" : "x" },
      "body" : {
        "if" : { "zerop" : "x" },
        "then" : "1",
        "else" : {
          "*" : {
            "lhs" : "x",
            "rhs" : {
              "factorial" : {
                "-" : {
                  "lhs" : "x",
                  "rhs" : "1"
                }
              }
            }
          }
        }
      }
    }
  }

Now, if we replace "defun" with the return type, replace some of the curlies with parentheses, get rid of the labels we added, use infix operator notation, and not worry about it being a valid JSON object, we get:

    int
      factorial ( x )
        {
          if ( zerop ( x )  )
            1
          else
            x * factorial ( x - 1 )
        }

Reformat this a bit, add some C keywords and statement delimiters, and Bob's your uncle.

0 - https://www.goodreads.com/quotes/573737-language-shapes-the-...

db48x2• 1 year ago

Whorf was an idiot. It’s not worth quoting him.

pjmlp• 1 year ago

I know Lisp since I read the little lister around 1996, and was an XEmacs user until around 2005.

The parenthesis do really disappear, just like the hieroglyphics on C influenced languages, it is a matter of habit.

At least it was for me.

eternityforest• 1 year ago

To me any kind of deep nesting is an issue. It goes against the idea of reducing the amount of mental context window needed to understand something.

Plus, if syntax errors can easily take several minutes to fix, because if the syntax is wrong, auto format doesn't work right, and then you have to read a wall of text to find out where the missing close paren should have been.

bgitarts• 1 year ago

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

geor9e• 1 year ago

People smart enough to read and write it are rare.

Capricorn24814• 1 year 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.

tmtvl5• 1 year 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• 1 year 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.

mikedelago• 1 year ago

In my case, my boss won't let me.

grandempire5• 1 year ago

JavaScript and Python have adopted almost every feature that differentiated Lisp from other languages. So in comparison Lisp is just more academic, esoteric, and advanced.

int_19h6• 1 year ago

This is only true if you define "Lisp" as the common subset. If you look specifically at Common Lisp, neither Python nor JS come close in terms of raw power.

Rendello• 1 year ago

The only software I use that I know runs a lisp is Hacker News.

wdkrnls2• 1 year ago

When I was in high school I learned AutoCAD and I remember that back then it was scripted in LISP. I'm not sure if that is still true.

dangus• 1 year ago

It's pretty rare because when it was being originally designed the main intended use case was for bragging about the cool unique niche programming language you use on your blog posts. While it's a very good language for being able to recursively get itself onto the front page, it's not so good at conformist normie use cases.

jll29• 1 year 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

vindarel3• 1 year 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.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/

Capricorn24814• 1 year 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.

jrapdx3• 1 year ago

Of course you're right. I've written non-trivial programs in Scheme, Emacs is a good tool for it, but certainly don't know of an environment that matches the Lisp machines.

IDEs provide such environments for the most common languages but major IDEs offer meager functionality for Lisp/Scheme (and other "obscure" languages). With a concerted effort it's possible an IDE could be configured to do more for Lisp. Thing is the amount of effort required is quite large. Since AFAIK no one has taken up the challenge, we can only conclude it's not worth the time and energy to go there.

The workflow I've used for Scheme programming is pretty simple. I can keep as many Emacs windows ("frames") open as necessary with different views of one or several modules/libraries, a browser for documentation, terminals with REPL/compiler, etc. Sort of a deconstructed IDE. Likely it does take a bit more cognitive effort to work this way, but it gets the job done.

submeta• 1 year 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• 1 year 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• 1 year 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• 1 year 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• 1 year 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/bl...

fithisux• 1 year ago

"Why I Program in Lisp"

because you don't have money to waste on doctors?

Why I Program in Lisp

Related Stories