21 ms·

Why Lisp?

244 points by mepian 3y ago

littlemeat 3y ago
[flagged]
- taeric 3y ago
  Code is difficult outside of small teams. Period. Libraries, macros, annotations, build systems...
  - deleted 3y ago
    [deleted]
- zdragnar 3y ago
  Macros are basically the reason that people like ruby on rails. Every tool has its place.
  - cultofmetatron 3y ago
    metaprogramming in ruby carries a runtime cost. lisp macros (and rust macros) compile and so can be run without drastically decreasing Perf
    - zdragnar 3y ago
      I don't disagree. The post I was replying to effectively said macros are too hard to use outside of small teams. They did have a point- it's not the kind of tool that you reach for on a whim. However, they can be fantastically useful when planned and used with discipline.
phant0mas 3y ago
John and Pierre are two of the smartest lisp programmers out there!
- deleted 3y ago
  [deleted]
- jackdaniel 3y ago
  That's a very far-fetched assertion.
zabzonk 3y ago
> and then they say "this language is Turing complete and therefore should be able to do anything you want it to do." i'm pretty sure that no designers of modern languages would say anything as naive as that. > sible in Lisp was the implementation of an object oriented programming system without having to change the compiler! haven't people done that using C? > This meant that all code written in Python 2 could not be leveraged in Python 3 not all python 2 code could be directly "leveraged", but it certainly could be translated, and has been. don't get me wrong - i like lisp, but this article would not convince me if i was thinking of coming to it as a newbie.
- medo-bear 3y ago
  > not all python 2 code could be directly "leveraged", but it certainly could be translated, and has been translating is an effort. running lisp code thats 30 years old is mostly a matter of pressing play > don't get me wrong - i like lisp, but this article would not convince me if i was thinking of coming to it as a newbie given that this is more of a "tweet" than an article i think you missed the point
  - zabzonk 3y ago
    > given that this is more of a "tweet" than an article i think you missed the point this wasn't posted on twitter. but if you mean it was short and of poor content, then i agree with you.
    - medo-bear 3y ago
      i mean it was probably never meant to be rich in content in the way as to convince users to learn lisp
cynicalsecurity 3y ago
> On the other hand, Lisp code written some 30 years ago will most of the time, without issue, work on a modern Common Lisp implementation. Yeah, just like Perl. Or Latin. No one uses them, these are dead languages that belong to a museum. It can be fun to study them and you definitely should if you want to be well-educated and know the history behind the modern world, but that's it.
- surfpel 3y ago
  The irony of this comment is that HN is written in Lisp.
  - munch117 3y ago
    I thought HN was written in Arc. I don't think the interoperability between Common Lisp implementations extends to Arc.
    - robocat 3y ago
      https://github.com/wting/hackernews/blob/master/news.arc https://github.com/wting/hackernews/blob/master/news.arc Out of date, but you can read the ARC code as HN was 11 years ago.
- mepian 3y ago
  Arm, AMD, and Intel are using a Common Lisp application called ACL2 to formally verify their main products. Google Flights' core is written in Common Lisp. It's far from dead.
  - coldtea 3y ago
    If you can enumerate some projects using it, and even more so, if you need to, then it's much closer to dead than alive. It's like saying "The Vatican still uses latin, it's not a completely dead language".
    - 3y ago
Hirrolot 3y ago
> When you have a running program you can compile functions, redefine classes, etc. all while the program is running. You are changing the internal state of the image. This can surely be convenient in certain cases, however most of the times I find myself playing around with unit tests rather than with a single running process. Unit tests are small and fast so I don't even notice any inconvenience with the traditional compilation approach.
- jgoodhcg 3y ago
  I work with clojure and test driven development is not nearly as productive as repl driven development imo.
  - marcosdumay 3y ago
    I'll have to agree here, with the caveat that this applies to functional code. For side-effect heavy code, a repl is not nearly as productive as good tests and a debugger. (What is interesting is that people tend not to test or check manually their code's side effects, so a repl is the best option for almost all the debugging that people actually do.)
    - jgoodhcg 3y ago
      I worked in Kotlin and Java for awhile and the closest thing I had to a repl was stopping the debugger and running arbitrary single lines of code in the context I paused. It was awful compared to the clojure repl.
  - ravi-delia 3y ago
    There's a place for both even with a REPL I think. Sometimes when I'm tracking a bug down or writing a new function against an old one, I find that I'm writing little one-off functions or worse, replicating a function body line by line in a let block to simulate arguments. Once I opened up a project and realized I wanted one of them, but it was lost when the REPL closed. I literally got as far as opening another file to stow these little utilities before I realized I had reinvented bargain-bin testing. My dream is still to come up with some ergonomic way of blending the two. I want to have tests written, but swap out the thing they test live in the REPL. Or register new one-off tests from the REPL for things I don't think will be useful once things are set in stone. I've heard one of the several billion testing frameworks for common lisp does something like this, but I haven't checked it out yet.
BaculumMeumEst 3y ago
i cant even install this program on my system because of common lisp’s insane dependency management so count me as unconvinced
- fn-mote 3y ago
  > this program What program are you talking about? The article is about Common Lisp, but perhaps you are talking about the Portacle setup mentioned in the article? Or is this just a general snipe at CL? Is it a problem to use QuickLisp [1]? Or are you talking about deeper problems. I think you could have something useful to say here, but I don't think that post conveys it. [1] https://www.quicklisp.org/beta/ https://www.quicklisp.org/beta/
  - ravi-delia 3y ago
    The company make a browser, Nyxt. I assume OP is talking about that. Works OK on every system I use, but who knows
- kagevf 3y ago
  If you’re referring to Nyxt, I’ve been using guix to install it, and it takes care of all the dependencies, including getting them right so that connecting to Nyxt’s swank server can be done from emacs.
  - BaculumMeumEst 3y ago
    it's doable, on linux systems i don't mind doing that. but on my mac i don't want to use all that disk space, particularly for a for-funsies web browser (although i really do like the browser). and for other programs, if CL CFFI bindings don't build on your platform then nix or guix can't save you sucks because i love lisp but CL is just not good for program distribution
    - kagevf 3y ago
      In the off-chance you're not aware, their download page has links for macOS - https://nyxt.atlas.engineer/download https://nyxt.atlas.engineer/download One each for docker and MacPorts.
lfc07 3y ago
Well said. LISP has longevity.
eimrine 3y ago
The article seems like mostly about Common Lisp, but how many of the points are applicable to rest of Lisps? (Scheme, Emacs Lisp, Janet, etc)
- ravi-delia 3y ago
  Somewhat! The authors talk about the longevity of CL, which is less a fact about lisp than an accident of history. Janet, for instance, is obviously quite new. Elisp is quite old, but I wouldn't use it for non-emacs development. Schemes are old, and while there are lots of one-off schemes which seem to be educational projects for their developers there are also lots of very old and battle-tested dialects (Chicken scheme comes to mind, Racket is old-ish and backed by its use in education). The interactivity is fairly universal. Scheme in its smallest nuts and bolts doesn't care that much about interactivity, giving eval but no other real support for a REPL, but due to cultural effects pretty much every specific scheme is very interactive. I've seen complaints about every specific lisp I've ever used that it's not a real lisp because it doesn't support [extremely specific interactive option user integrated into their workflow in '93 and can't live without], but everything the authors talked about is likely to be present in just about every lisp.
- behnamoh 3y ago
  Janet is not a Lisp, it uses parentheses though.
  - eimrine 3y ago
    I have pg's list of nine Lisp ideas [1]. What of these are missing in Janet? My guess is that only 9th one but I would like to understand Lisp (any) vs Janet point. [1] www.paulgraham.com/diff.html
    - lispm 3y ago
      LISP originally came in an implementation (LISP I) and LISP is short for List Processor. Janet looks like a really great language&implementation, but it is not similar to that specific List Processor, for example given that it does not use linked lists at its core.
deleted 3y ago
[deleted]
7thaccount 3y ago
After learning Python, I wanted to take the next step and find what was better. I looked into a lot of languages reading books on Haskell and Lisp and many others. At least for my use cases (desktop scripting, numerical work... etc) I didn't find Lisp to be superior. Most of what I actually needed to do could be done simpler in Python. Python's REPL isn't near as good as CL, but it's good enough. Then the batteries included was huge. So practically any task I could whip something up pretty quick. There are definitely some areas where Lisp is obviously superior to Python such as performance of plain code or things such as grammarly that would've likely been harder in python. I just think for the vast majority of programmers, enough good parts were pulled from lisp.
- linguae 3y ago
  As a Lisp fan who sometimes codes in Scheme and Common Lisp whenever I get the chance, I agree with you. The gap has certainly narrowed in the past 20 or so years between Lisp and widely-used programming languages. In addition, the rise of statically-typed functional programming languages like OCaml and Haskell provide another alternative for those who love functional programming but want Hindley-Milner types. I still think Lisp, whether in the form of Scheme or Common Lisp (I haven’t tried Clojure), is quite enlightening due to the immense flexibility these languages provide. However, I’m reminded of the rationale of MIT’s decision back in 2009 to move away from SICP and Scheme in the intro CS course in favor of Python: the vast majority of developers aren’t building new ecosystems from the ground up, but are instead reliant on an ecosystem of libraries. Lisps are wonderful for creating whole worlds due to the powerful tools they provide. I’m currently working on a side project where Lisp’s flexibility comes in handy. But if I’m effectively gluing together APIs to build a solution (and this is not an insult), then do I need macros, MOP, multiple dispatch, and homoiconicity? Thus, many programmers do not need the full power of Lisp to get their jobs done. There’s also the fact that languages like Python and JavaScript have a lot more commercial and community backing than Scheme and Common Lisp. If I’m writing something complex like a DBMS or web browser, then Common Lisp would be one of my first choices. However, if I’m writing a machine learning application or a web application, then I’ll most likely reach for Python or JavaScript, respectively, due to the library ecosystems.
dreamcompiler 3y ago
A point the authors didn't make is that Common Lisp compilers are quite fast compared to e.g. C++ compilers. So even in rare cases where you do need to recompile everything, the cycle time is short. CCL's compiler is lightning-fast. I can recompile an entire system in CCL almost as fast as I can load the compiled object code. SBCL's compiler is slower (while often generating faster code because it does more work at compile time), but it's still much faster than a typical C++ compiler.
- pjmlp 3y ago
  This is the most relevant part that Python misses out from Lisp. There is PyPy, and apparently Mojo will change the world, but still not something to rely on like on Lisps. I guess there is always Julia.
- sva_ 3y ago
  Comparing it to C++ compilers... does Lisp have zero-cost abstractions?
  - phoe-krk 3y ago
    It does, in form of a sane macro system with the full language available for use at compilation time - something that C++ never had and still doesn't have. No, consteval and constexpr aren't equivalent. No, CPP is not a sane macro system. No, don't even get me started about templates.
    - foldr 3y ago
      Portable CL is missing some key features for making zero cost abstractions such as unboxed arrays of structs.
      - phoe-krk 3y ago
        Yes. That's a consequence of language design - unboxed arrays of structs mean no object identity, which means that operators like SETF and EQ no longer have their invariants satisfied when performing assignment to such arrays.
implements 3y ago
I’ve worked through chapter one of SICP, and whereas I can admire the purity and kind of ‘belly feel’ how good Lisp can be it’s really painful translating expressions into pre-fix and having to do all the iteration using recursion.
- easeout 3y ago
  You do get used to the syntax, at which point returning to languages that are prefix here, infix there, statements one way, expressions another, can wrinkle your nose a bit. But syntactic patterns are a question of emphasis; they establish a grain to go with. Lisp's syntax is so uniform as to have no grain. That puts more responsibility on you in exchange for high level flexibility—you can do things the way you want, and a creative method won't be against the grain like it might be in another language. As for the recursion part, that's more true of Scheme, and it serves SICP's purpose of explaining that iterative and recursive processes can each be generated by recursive code. Common Lisp and friends do have iterative options for loops. But you will probably work in aggregate list operators more than touching a loop yourself.
- erichocean 3y ago
  FWIW, that's 100% true and virtually everyone experiences it. It completely goes away, so much so that it's almost impossible to remember emotionally how difficult it once was. I can promise you won't struggle with it for more than a few weeks (at most) of daily use. Source: someone who switched to Clojure recently, is loving it, and finds the syntax/iteration no longer on the list of things I even think or worry about.
submeta 3y ago
Appreciating what Lisp is capable of doing (think macros), and having worked through SICP some twenty years ago, and after having tried to make a deep dive in CL and Emacs Lisp two years ago, I come to the conclusion that there is no silver bullet in Lisp-land. Python is a good enough Lisp, as Peter Norvig has concluded. And it’s got all batteries included. Ain‘t nothing it can’t do. Building websites, doing maths, automating, except building compilers and OSes. But Lisp won’t compete in that field anyway. Programming languages are there to express ideas and solve problems. I can think of more elegant ways to express ideas (functional languages for instance), but Python is an excellent ecosystem for solving problems.
- shaunxcode 3y ago
  The true killer feature of lisp is s-expressions and the structural editing affordances they provide. “If I can’t slurp and barf, I don’t want to be part of your revolution.” ~Emma Goldman(ish)
- dunefox 3y ago
  > But Lisp won’t compete in that field anyway. I wouldn't say that. https://coalton-lang.github.io/20211010-introducing-coalton/ https://coalton-lang.github.io/20211010-introducing-coalton/
- ryukafalz 3y ago
  > Python is a good enough Lisp, as Peter Norvig has concluded. And it’s got all batteries included. Ain‘t nothing it can’t do. I almost agree, but Python fails in one area, which happens to be my current area of interest. It doesn't have sufficiently strict encapsulation to support object capabilities[0] at the language level. JavaScript, on the other hand, does[1] - so you don't necessarily need Lisp for this, but I do enjoy the parentheses. :) [0] http://habitatchronicles.com/2017/05/what-are-capabilities/ http://habitatchronicles.com/2017/05/what-are-capabilities/ [1] https://medium.com/agoric/pola-would-have-prevented-the-event-stream-incident-45653ecbda99 https://medium.com/agoric/pola-would-have-prevented-the-even...
  - hajile 3y ago
alain94040 3y ago
This thread may be as good as any to ask: the code I write has to deal with a huge amount of state. To summarize, my code receives millions of "change commands", which update state in memory. Data structures are hash tables, lists, etc. And some commands, once in a while, are queries like "how many of these are there now, of what does this element now point to?". I guess I'm describing some kind of custom in-memory database engine. Anyway, I'm confused as to how the purity of Lisp functions would or would not prevent me from writing this code? Is this a use case that is bad for Lisp, or am missing something?
- MathMonkeyMan 3y ago
  Lisp is not pure, in general. cons is "functional" because lists, if treated immutably, are functional. There's still setq (set! in Scheme), though, and operations on hash tables, arrays, and sets are typically mutating.
- acdw 3y ago
  so Lisp is actually not a pure language, like, at all. Emacs is often written about as a big hairy ball of state and Lisp itself can be as imperative or statefule as you want. So while I don't know much about what you're designing, Lisp wouldn't be necessarily a bad choice.
- ravi-delia 3y ago
  Lisp functions are generally not pure! Common lisp, the language this article is mostly talking about, is very comfortable with state. CL, like most lisps, often encourages a functional style- everything is an expression, and usually you'll return data structures even if you mutate them. But big hash tables and arrays are definately in common lisp's wheelhouse. Even Clojure, which is largely pure when dealing only with itself, has full support for diving into the messy practicalities of mutation on the JVM.
- WinLychee 3y ago
  As far as FP langugages go, LISP is very much a free-for-all. It can be pure if you want it to be, or stateful and imperative if you prefer. Nothing is really enforced like for example in Haskell. For your use-case a mutable reference behind some type of synchronized accessor would probably suffice. If you want to get fancy you could design the system in such a way that any point in time could be replayed or rewound to, since you have the commands and the initial state. Some ideas to look into: [1] https://github.com/acid-state/acid-state https://github.com/acid-state/acid-state [2] https://docs.datomic.com/pro/getting-started/brief-overview.html https://docs.datomic.com/pro/getting-started/brief-overview.... [3] https://www.martinfowler.com/bliki/CQRS.html https://www.martinfowler.com/bliki/CQRS.html
dehrmann 3y ago
> The developers of Lisp give you the full powers that they had to develop the language. So someone joining the project doesn't just have to learn Lisp, they have to learn Inhouse Lisp? And the abstractions provided by modern languages are woefully incomplete? > Lisp code written some 30 years ago will most of the time, without issue, work on a modern Common Lisp implementation You could say the same about Java and 20 years.
- submeta 3y ago
  > You could say the same about Java and 20 years. Or even COBOL and 40 or 50 years. What does that even prove. Edit: Typo
- Hirrolot 3y ago
  > So someone joining the project doesn't just have to learn Lisp, they have to learn Inhouse Lisp? I think this tends to hold true for all complex systems past certain point. Especially web frameworks. They just tend to circumvent the language so much (via macros, type system, etc.) so it's no longer like a bare language that was before. But I appreciate your point that macros can add cognitive burden in many cases where less powerful (and more easily understandable) mechanisms would suffice.
- deleted 3y ago
  [deleted]
- akira2501 3y ago
  > they have to learn Inhouse Lisp? Is this much different from selecting a particular vendor deployment stack, such as react native, or a particular GUI toolkit such as Qt? So.. now I don't just have to know C++ I have to know C++/Qt, or not just JavaScript but JavaScript/React?
  - dehrmann 3y ago
    Qt and React have been used for years by lots of people, so there's a lot of knowledge out there about them, their designs are more general-purpose and refined, and you're likely to have encountered them before.
tiffanyh 3y ago
Reminder, HN is built/runs-on a dialect of Lisp (Arc). On a single server. On a single core.
- Hammershaft 3y ago
  genuinely amazing, is there a writeup on this?
  - tiffanyh 3y ago
    I’ve never seen a full blown write up. but dang references it in a handful of comments he’s posted.
  - bjoli 3y ago
    Is it? HN is mostly static content. Ten years ago I wrote a simple web application using twister (python) that did well over a thousand requests per second. If we count just handling requests (and not churning out much data or doing anything fun processing) japronto for python claims to handle something like 1.2 million req/s on a single thread.
    - hajile 3y ago
      The most frequently access parts of the site are always in flux with users constantly adding, removing, and editing content. I don’t know how you could statically generate that. At most, you could memoize the parts of the page that haven’t changed yet and return them without a complete lookup, but keeping that in synch with a database is not an easy problem.
      - nkjnlknlk 3y ago
        HN doesn't have that much traffic so it's easier than you might think!
      - bjoli 3y ago
        You could regenerate the start page every 5s and comment pages whenever you need (new, edited or deleted comments) or every request if there has been more than 30s since it was last updated. That would leave the serving to some of the applications being good at that (varnish?). Finding the right heuristic regarding page regeneration might take some tweaking, but the amount of generating you have to do is small enough not to bother any single threaded program.
vindarel 3y ago
They link to "these years in Lisp" from 2018, here's 2022 in review: https://lisp-journey.gitlab.io/blog/these-years-in-common-lisp-2022-in-review/ https://lisp-journey.gitlab.io/blog/these-years-in-common-li...
iloveCS 3y ago
the fact that there are repeated statements like "why X" where X = some language, points to rationalization more than reality; if the language is really so good, there won't be any need for a "why" articles on it. I haven't seen a repeated series of "Why C#" or "Why Go" or "Why Swift" articles. I also think Lisp is way overrated. Swift is based on Miranda which is based on Hope which borrows heavily from SML...There's nothing Swift can't do better that Lisp can.
- mepian 3y ago
  Pretty sure Microsoft's marketing department actively pushed C# at least, there was no need for grassroots advocacy in this case.
- pluijzer 3y ago
  I do not agree. I do not have time to familiarize myself with every language in existence to such a level that their strengths become obvious to me. It is perfectly reasonable for a expert in a language to write an article on why to use it.
- JonChesterfield 3y ago
  Different languages are better and worse at different things. It's a really complicated design space. There probably are some which are better than others on every axis, but generally making one better at some things makes it worse at others.
- jabradoodle 3y ago
  I have seen those articles, also note, each of those languages is the product of and has the backing of giant corporations.
- ravi-delia 3y ago
  There was a straight decade where HN was covered, nay choked, by "Why Go" articles. This ended under two years ago. Swift doesn't get the same coverage, but pretty clearly falls into roughly the same category for everyone but Apple UI developers
- pjmlp 3y ago
leethomas 3y ago
I like lisps syntactically. The only thing stopping me from using it more frequently is the lack of static typing. I wasn't always a stickler for static typing, but I've spent a lot of time working with Scala and TS and the main advantage for me is ease of refactoring and avoiding NPEs. EDIT: What I'm continuously evaluating for myself is Clojure specifically
- readthenotes1 3y ago
  "I like lisps syntactically" and yet, not a single parentheses in your text. Disappointed.
  - kdmccormick 3y ago
    ((syntactically like) I lisps)
- hajile 3y ago
  Check out Coalton.
  - dataangel 3y ago
    Coalton static typing doesn't actually work, there's an issue filed that it breaks as soon as you do any mutation.
    - medo-bear 3y ago
      i guess you need to learn more about static typing
    - reikonomusha 3y ago
      It is not true that "any mutation" causes issues. In fact, most idiomatic usage of mutation is problem-free and completely sound. One can find out more about polymorphic mutation as a "counterexample" to Hindley-Milner type inference on Wikipedia [1]. It's a well-studied problem with space of solutions. Purity, weak references, the value restriction, etc. are all ways of dealing with this shortcoming of Hindley-Milner. Interestingly, one of the first proposed solutions to this problem was suggested by Wright in the journal "LISP and Symbolic Computation" [2]. [1] https://en.wikipedia.org/wiki/Value_restriction#A_Counter_Example_to_Type_Safety https://en.wikipedia.org/wiki/Value_restriction#A_Counter_Ex... [2] https://link.springer.com/article/10.1007/BF01018828 https://link.springer.com/article/10.1007/BF01018828
pdimitar 3y ago
I can gloss over LISP's lack of static strong typing and if I force myself a bit, I can also ignore it not producing small efficient native binaries... but the lack of (semi-)transparent concurrency / parallelism is my deal-breaker. Multicore CPUs are a fact for life for a long time now. Where is the stuff like Erlang/Elixir's green threads or Golang's goroutines/channels and Rust's async runtimes workers/channels, and OCaml 5.0's recent multicore runtime (and the emerging libraries around it)? People have been quick to point out various old-school multithreading libraries in the past but as a guy who was working with `pthreads` almost instantly after he started his career 21+ years ago... yeah, nope, I want the higher-level stuff. I want to solve problems and not invent a new async orchestration runtime for every project I work on. If LISP is so fantastic why isn't there a serious effort to make it multicore-friendly? Where's the transparent concurrency and parallelism? The actor runtime? The [stateful] effect handlers? --- Believe it or not, I understand the value of inventing your own DSL and that solving business problems with it is much easier compared to coding it in another programming language but (a) nobody wants to pay me for that because that way I make myself irreplaceable and business is extremely against this and (b) that solution might end up being non-extendable, rigid and a dead-end. So it's a high-risk endeavor in more ways than one. So OK, LISP is awesome. I tried it, liked it, couldn't find a way to make money with it. I suspect many other programmers are in my boat. If you want more adoption then do the grunt work and bring it to 2023. Give us an HTTP (1.x & 2.0) and WebSockets libraries, give us an actor runtime (or a goroutine-like one), maybe an optional type checker -- and I am sure the community can very easily pick it up afterwards and lift it up to big heights. No? Then it remains a niche curiosity. Enlightenment does not have to always go hand-in-hand with being a spartan. I want libraries.
- jabradoodle 3y ago
  There are staticly typed and gradually typed lisps. Clojure also has a similar concurrency to go with channels.
  - Blackthorn 3y ago
    Clojure's core.async channel concurrency is nothing like go's. You need to wrap your concurrent block in a macro so it can code walk to find explicit blocking points. That means these points need to be marked, and can't be in already compiled functions. That's an enormous limitation. Compare to go's which just works, no caveat.
hughw 3y ago
I can do all of that in Blub.
eterevsky 3y ago
Isn't Lisp 5-20 times slower than C/C++/Rust (https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/sbcl-gcc.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...)? Performance is important for a browser.
- lisper 3y ago
  It depends on how you write the code and the compiler you use, but Lisp can be as fast as if not faster than C. But the main thing is that in Lisp it's easy to turn the dial between speed and other things you might want to optimize for like safety and debugability. Making C code memory safe is a lot of work at best, and actually impossible at worst.
  - eterevsky 3y ago
    You could write safe-ish C++ and Rust that is both readable and fast. Could you point me to some benchmarks of Lisp being comparable to C? Also, unless I am mistaken, Common Lisp doesn't have strong types. How can you make either fast or safe language without compiler knowing the types?
    - armitron 3y ago
      You are mistaken, CL is strongly typed.
      - eterevsky 3y ago
        Wikipedia says that it is optionally typed. Is it not so?
        armitron 3y ago
        I don't see "optionally typed" anywhere in here: https://en.wikipedia.org/wiki/Common_Lisp https://en.wikipedia.org/wiki/Common_Lisp I do see "Typing Discipline: Dynamic, strong"
      - 3y ago
Paul-Craft 3y ago
Here's a question the article doesn't answer: why Common Lisp? I.e. why not Scheme? Scheme is a plenty powerful language these days with all the libraries it has available. Granted, it doesn't have history going back to the 1950s, but it does date back to the 1970s. There are also multiple implementations, each with its own set of strengths. And there are some solid standards written for the language that have good implementations. It seems to have all the exact same features they're saying make CL a good choice (e.g. it's hard for me to imagine that a language older than most working programmers doesn't have "longevity" or "staying power.") Besides, if you click through to https://stevelosh.com/blog/2018/08/a-road-to-common-lisp/#s8-ugliness https://stevelosh.com/blog/2018/08/a-road-to-common-lisp/#s8... (linked in the article), it shows a picture of the index of CLtL, where the entry for 'kludges' spans the entire book lol!
- xmcqdpt2 3y ago
  I recently decided to try a scheme and did not find any that had supported Windows as a first class platform, so that's one limitation. By comparison SBCL just runs on Windows without any difficulties.
  - jhgb 3y ago
    I believe that Chez should support Windows very well, even to the extent of supporting COM calls.
  - kerkeslager 3y ago
    Racket has supported Windows since I tried it out in high school, which was a long, long time ago. The thing with Schemes is that you can implement one in an afternoon, and you can probably add some neato feature in the same afternoon, so there are a ton of Schemes out there. But you can't build community, ecosystem of libraries, platform support, etc. that you would want for a language you're going to use in production. Racket has been around for a long time, is used in various production systems, and has a solid community. It actually has the best standard library I know of for writing desktop GUIs, which might not be much of a claim to fame in 2023, but makes it super useful for writing small desktop tools. It definitely does some things better than others, like any language, but I think I'd be comfortable committing to it for a production project any day, which is more than I can say for any other Scheme.
pmarreck 3y ago
Elixir is like a LISP with pure functions, only immutable values all the way down (which gets you a guarantee you wouldn't have otherwise in languages where this is optional), actor concurrency, pattern-matching, actual readable syntax, and of course macros (which do the same thing LISP macros do- Accept and output an AST value that happens at the compilation step- the only difference being LISP homoiconicity). It singlehandedly ended my Haskell envy, my LISP envy and my Erlang envy, while essentially killing off what remained of my Ruby romance. I just wish I could 1) compile it directly to a single binary (so I still have some Rust and Go envy), 2) run it 100% in the browser (so I still have some Clojure envy via ClojureScript), 3) talk to ML stuff as well as Python can (although Elixir Nx and Livebooks are coming along!)
- erichocean 3y ago
  Clojure does all three: 1) Native, compiled binaries with GraalVM. 2) ClojureScript (already mentioned) for the browser. 3) For ML, Clojure in the last 2-3 years has built a really great internal ecosystem but it hardly matters because libpython-clj exists so you can run NumPy, PyTorth, etc. from Clojure. Getting data in and out of Python land is just as easy as Java-interop. The reverse also works (calling out to Clojure from an arbitrary Python interpreter). Plus a few other things you didn't mention: 4) ClojErl is Clojure on BEAM. You have full access to Erlang libraries (e.g OTP) and 98% of Clojure, missing only things that don't make sense on BEAM. 5) Write native iOS/Android apps with either React Native or Flutter (via ClojureDart). Develop them interactively just like you do browser stuff with ClojureScript. 6) Clojure now makes a great scripting platform with Babushka, which has completed replaced Node.js/Python/Bash for that use case for me. 6) Datomic/Datalog, there's still nothing like it after 10 years and in the last two weeks, it's Apache 2-licensed free to use and deploy. Elixir/Erlang are really impressive, but being BEAM-only is a serious limitation. Clojure is a bit more practical (and I still get to run Clojure-on-BEAM when that makes sense).
  - pmarreck 3y ago
    How did they make Babashka (it’s apparently spelled that way) instantly start? Do they pre-warm a Java thread in the background? Do math errors still dump Java stack traces in Clojure? That and the lack of syntax once ruled it out for me.
ibiza 3y ago
The "other editors" link[1] is welcome. I've never liked the implicit Emacs requirement associated w/ Lisp envs. The list includes Vim, NeoVim, & even IntelliJ!? Good stuff. 1. https://lispcookbook.github.io/cl-cookbook/editor-support.html https://lispcookbook.github.io/cl-cookbook/editor-support.ht...
eviks 3y ago
> The Lisp designers do not assume what syntax, features or functions will be necessary in the future. The developers of Lisp give you the full powers that they had to develop the language. Isn't that ~ abdicating responsibility for language design?
- hajile 3y ago
  Definitely not. Guy Steele was involved in the specs for C, JS, Fortran, scheme, Common Lisp, and Java (among others). He gave a must-watch talk about Java called “Growing a Language”. https://youtu.be/_ahvzDzKdB0 https://youtu.be/_ahvzDzKdB0 He makes a great case that a language must be able to deal with future problems and ideas the original designers didn’t or couldn’t foresee. He seems to have been one of the voices pushing for stuff like generics so users could design libraries that would feel more native. And of course, I can’t mention him here without quoting his statement about Java: > We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp. A goal of Common Lisp was giving all the tools future programmers might need to create new tools. As a result, you’d be hard-pressed to come up with a language feature that hasn’t been ported to CL at some time.
  - eviks 3y ago
    Thanks, will check the talk later.
- rgherdt 3y ago
  May I quote the first sentences from Scheme's R7RS standard that relates to this topic: "Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary. Scheme demonstrates that a very small number of rules for forming expressions, with no restrictions on how they are composed, suffice to form a practical and efficient programming language that is flexible enough to support most of the major programming paradigms in use today."
kazinator 3y ago
> Future proof is a term thrown around a lot in the tech industry. This is the TXR Lisp interactive listener of TXR 286. Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for cheatsheet. Truly future-proof systems are rare; future-resistant ones are everywhere. 1> _

Why Lisp?

244 points by mepian 3y ago

littlemeat 3y ago

[flagged]

taeric 3y ago
Code is difficult outside of small teams. Period. Libraries, macros, annotations, build systems...
- deleted 3y ago
  [deleted]
zdragnar 3y ago
Macros are basically the reason that people like ruby on rails. Every tool has its place.
- cultofmetatron 3y ago
  metaprogramming in ruby carries a runtime cost. lisp macros (and rust macros) compile and so can be run without drastically decreasing Perf
  - zdragnar 3y ago
    I don't disagree. The post I was replying to effectively said macros are too hard to use outside of small teams. They did have a point- it's not the kind of tool that you reach for on a whim. However, they can be fantastically useful when planned and used with discipline.

phant0mas 3y ago

John and Pierre are two of the smartest lisp programmers out there!

deleted 3y ago
[deleted]
jackdaniel 3y ago
That's a very far-fetched assertion.

zabzonk 3y ago

> and then they say "this language is Turing complete and therefore should be able to do anything you want it to do." i'm pretty sure that no designers of modern languages would say anything as naive as that. > sible in Lisp was the implementation of an object oriented programming system without having to change the compiler! haven't people done that using C? > This meant that all code written in Python 2 could not be leveraged in Python 3 not all python 2 code could be directly "leveraged", but it certainly could be translated, and has been. don't get me wrong - i like lisp, but this article would not convince me if i was thinking of coming to it as a newbie.

medo-bear 3y ago
> not all python 2 code could be directly "leveraged", but it certainly could be translated, and has been translating is an effort. running lisp code thats 30 years old is mostly a matter of pressing play > don't get me wrong - i like lisp, but this article would not convince me if i was thinking of coming to it as a newbie given that this is more of a "tweet" than an article i think you missed the point
- zabzonk 3y ago
  > given that this is more of a "tweet" than an article i think you missed the point this wasn't posted on twitter. but if you mean it was short and of poor content, then i agree with you.
  - medo-bear 3y ago
    i mean it was probably never meant to be rich in content in the way as to convince users to learn lisp

cynicalsecurity 3y ago

> On the other hand, Lisp code written some 30 years ago will most of the time, without issue, work on a modern Common Lisp implementation. Yeah, just like Perl. Or Latin. No one uses them, these are dead languages that belong to a museum. It can be fun to study them and you definitely should if you want to be well-educated and know the history behind the modern world, but that's it.

surfpel 3y ago
The irony of this comment is that HN is written in Lisp.
- munch117 3y ago
  I thought HN was written in Arc. I don't think the interoperability between Common Lisp implementations extends to Arc.
  - robocat 3y ago
    https://github.com/wting/hackernews/blob/master/news.arc https://github.com/wting/hackernews/blob/master/news.arc Out of date, but you can read the ARC code as HN was 11 years ago.
mepian 3y ago
Arm, AMD, and Intel are using a Common Lisp application called ACL2 to formally verify their main products. Google Flights' core is written in Common Lisp. It's far from dead.
- coldtea 3y ago
  If you can enumerate some projects using it, and even more so, if you need to, then it's much closer to dead than alive. It's like saying "The Vatican still uses latin, it's not a completely dead language".
  - 3y ago

Hirrolot 3y ago

> When you have a running program you can compile functions, redefine classes, etc. all while the program is running. You are changing the internal state of the image. This can surely be convenient in certain cases, however most of the times I find myself playing around with unit tests rather than with a single running process. Unit tests are small and fast so I don't even notice any inconvenience with the traditional compilation approach.

jgoodhcg 3y ago
I work with clojure and test driven development is not nearly as productive as repl driven development imo.
- marcosdumay 3y ago
  I'll have to agree here, with the caveat that this applies to functional code. For side-effect heavy code, a repl is not nearly as productive as good tests and a debugger. (What is interesting is that people tend not to test or check manually their code's side effects, so a repl is the best option for almost all the debugging that people actually do.)
  - jgoodhcg 3y ago
    I worked in Kotlin and Java for awhile and the closest thing I had to a repl was stopping the debugger and running arbitrary single lines of code in the context I paused. It was awful compared to the clojure repl.
- ravi-delia 3y ago
  There's a place for both even with a REPL I think. Sometimes when I'm tracking a bug down or writing a new function against an old one, I find that I'm writing little one-off functions or worse, replicating a function body line by line in a let block to simulate arguments. Once I opened up a project and realized I wanted one of them, but it was lost when the REPL closed. I literally got as far as opening another file to stow these little utilities before I realized I had reinvented bargain-bin testing. My dream is still to come up with some ergonomic way of blending the two. I want to have tests written, but swap out the thing they test live in the REPL. Or register new one-off tests from the REPL for things I don't think will be useful once things are set in stone. I've heard one of the several billion testing frameworks for common lisp does something like this, but I haven't checked it out yet.

BaculumMeumEst 3y ago

i cant even install this program on my system because of common lisp’s insane dependency management so count me as unconvinced

fn-mote 3y ago
> this program What program are you talking about? The article is about Common Lisp, but perhaps you are talking about the Portacle setup mentioned in the article? Or is this just a general snipe at CL? Is it a problem to use QuickLisp [1]? Or are you talking about deeper problems. I think you could have something useful to say here, but I don't think that post conveys it. [1] https://www.quicklisp.org/beta/ https://www.quicklisp.org/beta/
- ravi-delia 3y ago
  The company make a browser, Nyxt. I assume OP is talking about that. Works OK on every system I use, but who knows
kagevf 3y ago
If you’re referring to Nyxt, I’ve been using guix to install it, and it takes care of all the dependencies, including getting them right so that connecting to Nyxt’s swank server can be done from emacs.
- BaculumMeumEst 3y ago
  it's doable, on linux systems i don't mind doing that. but on my mac i don't want to use all that disk space, particularly for a for-funsies web browser (although i really do like the browser). and for other programs, if CL CFFI bindings don't build on your platform then nix or guix can't save you sucks because i love lisp but CL is just not good for program distribution
  - kagevf 3y ago
    In the off-chance you're not aware, their download page has links for macOS - https://nyxt.atlas.engineer/download https://nyxt.atlas.engineer/download One each for docker and MacPorts.

lfc07 3y ago

Well said. LISP has longevity.

eimrine 3y ago

The article seems like mostly about Common Lisp, but how many of the points are applicable to rest of Lisps? (Scheme, Emacs Lisp, Janet, etc)

ravi-delia 3y ago
Somewhat! The authors talk about the longevity of CL, which is less a fact about lisp than an accident of history. Janet, for instance, is obviously quite new. Elisp is quite old, but I wouldn't use it for non-emacs development. Schemes are old, and while there are lots of one-off schemes which seem to be educational projects for their developers there are also lots of very old and battle-tested dialects (Chicken scheme comes to mind, Racket is old-ish and backed by its use in education). The interactivity is fairly universal. Scheme in its smallest nuts and bolts doesn't care that much about interactivity, giving eval but no other real support for a REPL, but due to cultural effects pretty much every specific scheme is very interactive. I've seen complaints about every specific lisp I've ever used that it's not a real lisp because it doesn't support [extremely specific interactive option user integrated into their workflow in '93 and can't live without], but everything the authors talked about is likely to be present in just about every lisp.
behnamoh 3y ago
Janet is not a Lisp, it uses parentheses though.
- eimrine 3y ago
  I have pg's list of nine Lisp ideas [1]. What of these are missing in Janet? My guess is that only 9th one but I would like to understand Lisp (any) vs Janet point. [1] www.paulgraham.com/diff.html
  - lispm 3y ago
    LISP originally came in an implementation (LISP I) and LISP is short for List Processor. Janet looks like a really great language&implementation, but it is not similar to that specific List Processor, for example given that it does not use linked lists at its core.

deleted 3y ago

[deleted]

7thaccount 3y ago

After learning Python, I wanted to take the next step and find what was better. I looked into a lot of languages reading books on Haskell and Lisp and many others. At least for my use cases (desktop scripting, numerical work... etc) I didn't find Lisp to be superior. Most of what I actually needed to do could be done simpler in Python. Python's REPL isn't near as good as CL, but it's good enough. Then the batteries included was huge. So practically any task I could whip something up pretty quick. There are definitely some areas where Lisp is obviously superior to Python such as performance of plain code or things such as grammarly that would've likely been harder in python. I just think for the vast majority of programmers, enough good parts were pulled from lisp.

linguae 3y ago
As a Lisp fan who sometimes codes in Scheme and Common Lisp whenever I get the chance, I agree with you. The gap has certainly narrowed in the past 20 or so years between Lisp and widely-used programming languages. In addition, the rise of statically-typed functional programming languages like OCaml and Haskell provide another alternative for those who love functional programming but want Hindley-Milner types. I still think Lisp, whether in the form of Scheme or Common Lisp (I haven’t tried Clojure), is quite enlightening due to the immense flexibility these languages provide. However, I’m reminded of the rationale of MIT’s decision back in 2009 to move away from SICP and Scheme in the intro CS course in favor of Python: the vast majority of developers aren’t building new ecosystems from the ground up, but are instead reliant on an ecosystem of libraries. Lisps are wonderful for creating whole worlds due to the powerful tools they provide. I’m currently working on a side project where Lisp’s flexibility comes in handy. But if I’m effectively gluing together APIs to build a solution (and this is not an insult), then do I need macros, MOP, multiple dispatch, and homoiconicity? Thus, many programmers do not need the full power of Lisp to get their jobs done. There’s also the fact that languages like Python and JavaScript have a lot more commercial and community backing than Scheme and Common Lisp. If I’m writing something complex like a DBMS or web browser, then Common Lisp would be one of my first choices. However, if I’m writing a machine learning application or a web application, then I’ll most likely reach for Python or JavaScript, respectively, due to the library ecosystems.

dreamcompiler 3y ago

A point the authors didn't make is that Common Lisp compilers are quite fast compared to e.g. C++ compilers. So even in rare cases where you do need to recompile everything, the cycle time is short. CCL's compiler is lightning-fast. I can recompile an entire system in CCL almost as fast as I can load the compiled object code. SBCL's compiler is slower (while often generating faster code because it does more work at compile time), but it's still much faster than a typical C++ compiler.

pjmlp 3y ago
This is the most relevant part that Python misses out from Lisp. There is PyPy, and apparently Mojo will change the world, but still not something to rely on like on Lisps. I guess there is always Julia.
sva_ 3y ago
Comparing it to C++ compilers... does Lisp have zero-cost abstractions?
- phoe-krk 3y ago
  It does, in form of a sane macro system with the full language available for use at compilation time - something that C++ never had and still doesn't have. No, consteval and constexpr aren't equivalent. No, CPP is not a sane macro system. No, don't even get me started about templates.
  - foldr 3y ago
    Portable CL is missing some key features for making zero cost abstractions such as unboxed arrays of structs.
    - phoe-krk 3y ago
      Yes. That's a consequence of language design - unboxed arrays of structs mean no object identity, which means that operators like SETF and EQ no longer have their invariants satisfied when performing assignment to such arrays.

implements 3y ago

I’ve worked through chapter one of SICP, and whereas I can admire the purity and kind of ‘belly feel’ how good Lisp can be it’s really painful translating expressions into pre-fix and having to do all the iteration using recursion.

easeout 3y ago
You do get used to the syntax, at which point returning to languages that are prefix here, infix there, statements one way, expressions another, can wrinkle your nose a bit. But syntactic patterns are a question of emphasis; they establish a grain to go with. Lisp's syntax is so uniform as to have no grain. That puts more responsibility on you in exchange for high level flexibility—you can do things the way you want, and a creative method won't be against the grain like it might be in another language. As for the recursion part, that's more true of Scheme, and it serves SICP's purpose of explaining that iterative and recursive processes can each be generated by recursive code. Common Lisp and friends do have iterative options for loops. But you will probably work in aggregate list operators more than touching a loop yourself.
erichocean 3y ago
FWIW, that's 100% true and virtually everyone experiences it. It completely goes away, so much so that it's almost impossible to remember emotionally how difficult it once was. I can promise you won't struggle with it for more than a few weeks (at most) of daily use. Source: someone who switched to Clojure recently, is loving it, and finds the syntax/iteration no longer on the list of things I even think or worry about.

submeta 3y ago

Appreciating what Lisp is capable of doing (think macros), and having worked through SICP some twenty years ago, and after having tried to make a deep dive in CL and Emacs Lisp two years ago, I come to the conclusion that there is no silver bullet in Lisp-land. Python is a good enough Lisp, as Peter Norvig has concluded. And it’s got all batteries included. Ain‘t nothing it can’t do. Building websites, doing maths, automating, except building compilers and OSes. But Lisp won’t compete in that field anyway. Programming languages are there to express ideas and solve problems. I can think of more elegant ways to express ideas (functional languages for instance), but Python is an excellent ecosystem for solving problems.

shaunxcode 3y ago
The true killer feature of lisp is s-expressions and the structural editing affordances they provide. “If I can’t slurp and barf, I don’t want to be part of your revolution.” ~Emma Goldman(ish)
dunefox 3y ago
> But Lisp won’t compete in that field anyway. I wouldn't say that. https://coalton-lang.github.io/20211010-introducing-coalton/ https://coalton-lang.github.io/20211010-introducing-coalton/
ryukafalz 3y ago
> Python is a good enough Lisp, as Peter Norvig has concluded. And it’s got all batteries included. Ain‘t nothing it can’t do. I almost agree, but Python fails in one area, which happens to be my current area of interest. It doesn't have sufficiently strict encapsulation to support object capabilities[0] at the language level. JavaScript, on the other hand, does[1] - so you don't necessarily need Lisp for this, but I do enjoy the parentheses. :) [0] http://habitatchronicles.com/2017/05/what-are-capabilities/ http://habitatchronicles.com/2017/05/what-are-capabilities/ [1] https://medium.com/agoric/pola-would-have-prevented-the-event-stream-incident-45653ecbda99 https://medium.com/agoric/pola-would-have-prevented-the-even...
- hajile 3y ago

alain94040 3y ago

This thread may be as good as any to ask: the code I write has to deal with a huge amount of state. To summarize, my code receives millions of "change commands", which update state in memory. Data structures are hash tables, lists, etc. And some commands, once in a while, are queries like "how many of these are there now, of what does this element now point to?". I guess I'm describing some kind of custom in-memory database engine. Anyway, I'm confused as to how the purity of Lisp functions would or would not prevent me from writing this code? Is this a use case that is bad for Lisp, or am missing something?

MathMonkeyMan 3y ago
Lisp is not pure, in general. cons is "functional" because lists, if treated immutably, are functional. There's still setq (set! in Scheme), though, and operations on hash tables, arrays, and sets are typically mutating.
acdw 3y ago
so Lisp is actually not a pure language, like, at all. Emacs is often written about as a big hairy ball of state and Lisp itself can be as imperative or statefule as you want. So while I don't know much about what you're designing, Lisp wouldn't be necessarily a bad choice.
ravi-delia 3y ago
Lisp functions are generally not pure! Common lisp, the language this article is mostly talking about, is very comfortable with state. CL, like most lisps, often encourages a functional style- everything is an expression, and usually you'll return data structures even if you mutate them. But big hash tables and arrays are definately in common lisp's wheelhouse. Even Clojure, which is largely pure when dealing only with itself, has full support for diving into the messy practicalities of mutation on the JVM.
WinLychee 3y ago
As far as FP langugages go, LISP is very much a free-for-all. It can be pure if you want it to be, or stateful and imperative if you prefer. Nothing is really enforced like for example in Haskell. For your use-case a mutable reference behind some type of synchronized accessor would probably suffice. If you want to get fancy you could design the system in such a way that any point in time could be replayed or rewound to, since you have the commands and the initial state. Some ideas to look into: [1] https://github.com/acid-state/acid-state https://github.com/acid-state/acid-state [2] https://docs.datomic.com/pro/getting-started/brief-overview.html https://docs.datomic.com/pro/getting-started/brief-overview.... [3] https://www.martinfowler.com/bliki/CQRS.html https://www.martinfowler.com/bliki/CQRS.html

dehrmann 3y ago

> The developers of Lisp give you the full powers that they had to develop the language. So someone joining the project doesn't just have to learn Lisp, they have to learn Inhouse Lisp? And the abstractions provided by modern languages are woefully incomplete? > Lisp code written some 30 years ago will most of the time, without issue, work on a modern Common Lisp implementation You could say the same about Java and 20 years.

submeta 3y ago
> You could say the same about Java and 20 years. Or even COBOL and 40 or 50 years. What does that even prove. Edit: Typo
Hirrolot 3y ago
> So someone joining the project doesn't just have to learn Lisp, they have to learn Inhouse Lisp? I think this tends to hold true for all complex systems past certain point. Especially web frameworks. They just tend to circumvent the language so much (via macros, type system, etc.) so it's no longer like a bare language that was before. But I appreciate your point that macros can add cognitive burden in many cases where less powerful (and more easily understandable) mechanisms would suffice.
deleted 3y ago
[deleted]
akira2501 3y ago
> they have to learn Inhouse Lisp? Is this much different from selecting a particular vendor deployment stack, such as react native, or a particular GUI toolkit such as Qt? So.. now I don't just have to know C++ I have to know C++/Qt, or not just JavaScript but JavaScript/React?
- dehrmann 3y ago
  Qt and React have been used for years by lots of people, so there's a lot of knowledge out there about them, their designs are more general-purpose and refined, and you're likely to have encountered them before.

tiffanyh 3y ago

Reminder, HN is built/runs-on a dialect of Lisp (Arc). On a single server. On a single core.

Hammershaft 3y ago
genuinely amazing, is there a writeup on this?
- tiffanyh 3y ago
  I’ve never seen a full blown write up. but dang references it in a handful of comments he’s posted.
- bjoli 3y ago
  Is it? HN is mostly static content. Ten years ago I wrote a simple web application using twister (python) that did well over a thousand requests per second. If we count just handling requests (and not churning out much data or doing anything fun processing) japronto for python claims to handle something like 1.2 million req/s on a single thread.
  - hajile 3y ago
    The most frequently access parts of the site are always in flux with users constantly adding, removing, and editing content. I don’t know how you could statically generate that. At most, you could memoize the parts of the page that haven’t changed yet and return them without a complete lookup, but keeping that in synch with a database is not an easy problem.
    - nkjnlknlk 3y ago
      HN doesn't have that much traffic so it's easier than you might think!
    - bjoli 3y ago
      You could regenerate the start page every 5s and comment pages whenever you need (new, edited or deleted comments) or every request if there has been more than 30s since it was last updated. That would leave the serving to some of the applications being good at that (varnish?). Finding the right heuristic regarding page regeneration might take some tweaking, but the amount of generating you have to do is small enough not to bother any single threaded program.

vindarel 3y ago

They link to "these years in Lisp" from 2018, here's 2022 in review: https://lisp-journey.gitlab.io/blog/these-years-in-common-lisp-2022-in-review/ https://lisp-journey.gitlab.io/blog/these-years-in-common-li...

iloveCS 3y ago

the fact that there are repeated statements like "why X" where X = some language, points to rationalization more than reality; if the language is really so good, there won't be any need for a "why" articles on it. I haven't seen a repeated series of "Why C#" or "Why Go" or "Why Swift" articles. I also think Lisp is way overrated. Swift is based on Miranda which is based on Hope which borrows heavily from SML...There's nothing Swift can't do better that Lisp can.

mepian 3y ago
Pretty sure Microsoft's marketing department actively pushed C# at least, there was no need for grassroots advocacy in this case.
pluijzer 3y ago
I do not agree. I do not have time to familiarize myself with every language in existence to such a level that their strengths become obvious to me. It is perfectly reasonable for a expert in a language to write an article on why to use it.
JonChesterfield 3y ago
Different languages are better and worse at different things. It's a really complicated design space. There probably are some which are better than others on every axis, but generally making one better at some things makes it worse at others.
jabradoodle 3y ago
I have seen those articles, also note, each of those languages is the product of and has the backing of giant corporations.
ravi-delia 3y ago
There was a straight decade where HN was covered, nay choked, by "Why Go" articles. This ended under two years ago. Swift doesn't get the same coverage, but pretty clearly falls into roughly the same category for everyone but Apple UI developers
pjmlp 3y ago

leethomas 3y ago

I like lisps syntactically. The only thing stopping me from using it more frequently is the lack of static typing. I wasn't always a stickler for static typing, but I've spent a lot of time working with Scala and TS and the main advantage for me is ease of refactoring and avoiding NPEs. EDIT: What I'm continuously evaluating for myself is Clojure specifically

readthenotes1 3y ago
"I like lisps syntactically" and yet, not a single parentheses in your text. Disappointed.
- kdmccormick 3y ago
  ((syntactically like) I lisps)
hajile 3y ago
Check out Coalton.
- dataangel 3y ago
  Coalton static typing doesn't actually work, there's an issue filed that it breaks as soon as you do any mutation.
  - medo-bear 3y ago
    i guess you need to learn more about static typing
  - reikonomusha 3y ago
    It is not true that "any mutation" causes issues. In fact, most idiomatic usage of mutation is problem-free and completely sound. One can find out more about polymorphic mutation as a "counterexample" to Hindley-Milner type inference on Wikipedia [1]. It's a well-studied problem with space of solutions. Purity, weak references, the value restriction, etc. are all ways of dealing with this shortcoming of Hindley-Milner. Interestingly, one of the first proposed solutions to this problem was suggested by Wright in the journal "LISP and Symbolic Computation" [2]. [1] https://en.wikipedia.org/wiki/Value_restriction#A_Counter_Example_to_Type_Safety https://en.wikipedia.org/wiki/Value_restriction#A_Counter_Ex... [2] https://link.springer.com/article/10.1007/BF01018828 https://link.springer.com/article/10.1007/BF01018828

pdimitar 3y ago

I can gloss over LISP's lack of static strong typing and if I force myself a bit, I can also ignore it not producing small efficient native binaries... but the lack of (semi-)transparent concurrency / parallelism is my deal-breaker. Multicore CPUs are a fact for life for a long time now. Where is the stuff like Erlang/Elixir's green threads or Golang's goroutines/channels and Rust's async runtimes workers/channels, and OCaml 5.0's recent multicore runtime (and the emerging libraries around it)? People have been quick to point out various old-school multithreading libraries in the past but as a guy who was working with `pthreads` almost instantly after he started his career 21+ years ago... yeah, nope, I want the higher-level stuff. I want to solve problems and not invent a new async orchestration runtime for every project I work on. If LISP is so fantastic why isn't there a serious effort to make it multicore-friendly? Where's the transparent concurrency and parallelism? The actor runtime? The [stateful] effect handlers? --- Believe it or not, I understand the value of inventing your own DSL and that solving business problems with it is much easier compared to coding it in another programming language but (a) nobody wants to pay me for that because that way I make myself irreplaceable and business is extremely against this and (b) that solution might end up being non-extendable, rigid and a dead-end. So it's a high-risk endeavor in more ways than one. So OK, LISP is awesome. I tried it, liked it, couldn't find a way to make money with it. I suspect many other programmers are in my boat. If you want more adoption then do the grunt work and bring it to 2023. Give us an HTTP (1.x & 2.0) and WebSockets libraries, give us an actor runtime (or a goroutine-like one), maybe an optional type checker -- and I am sure the community can very easily pick it up afterwards and lift it up to big heights. No? Then it remains a niche curiosity. Enlightenment does not have to always go hand-in-hand with being a spartan. I want libraries.

jabradoodle 3y ago
There are staticly typed and gradually typed lisps. Clojure also has a similar concurrency to go with channels.
- Blackthorn 3y ago
  Clojure's core.async channel concurrency is nothing like go's. You need to wrap your concurrent block in a macro so it can code walk to find explicit blocking points. That means these points need to be marked, and can't be in already compiled functions. That's an enormous limitation. Compare to go's which just works, no caveat.

hughw 3y ago

I can do all of that in Blub.

eterevsky 3y ago

Isn't Lisp 5-20 times slower than C/C++/Rust (https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/sbcl-gcc.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...)? Performance is important for a browser.

lisper 3y ago
It depends on how you write the code and the compiler you use, but Lisp can be as fast as if not faster than C. But the main thing is that in Lisp it's easy to turn the dial between speed and other things you might want to optimize for like safety and debugability. Making C code memory safe is a lot of work at best, and actually impossible at worst.
- eterevsky 3y ago
  You could write safe-ish C++ and Rust that is both readable and fast. Could you point me to some benchmarks of Lisp being comparable to C? Also, unless I am mistaken, Common Lisp doesn't have strong types. How can you make either fast or safe language without compiler knowing the types?
  - armitron 3y ago
    You are mistaken, CL is strongly typed.
    - eterevsky 3y ago
      Wikipedia says that it is optionally typed. Is it not so?
      - armitron 3y ago
        I don't see "optionally typed" anywhere in here: https://en.wikipedia.org/wiki/Common_Lisp https://en.wikipedia.org/wiki/Common_Lisp I do see "Typing Discipline: Dynamic, strong"
    - 3y ago

Paul-Craft 3y ago

Here's a question the article doesn't answer: why Common Lisp? I.e. why not Scheme? Scheme is a plenty powerful language these days with all the libraries it has available. Granted, it doesn't have history going back to the 1950s, but it does date back to the 1970s. There are also multiple implementations, each with its own set of strengths. And there are some solid standards written for the language that have good implementations. It seems to have all the exact same features they're saying make CL a good choice (e.g. it's hard for me to imagine that a language older than most working programmers doesn't have "longevity" or "staying power.") Besides, if you click through to https://stevelosh.com/blog/2018/08/a-road-to-common-lisp/#s8-ugliness https://stevelosh.com/blog/2018/08/a-road-to-common-lisp/#s8... (linked in the article), it shows a picture of the index of CLtL, where the entry for 'kludges' spans the entire book lol!

xmcqdpt2 3y ago
I recently decided to try a scheme and did not find any that had supported Windows as a first class platform, so that's one limitation. By comparison SBCL just runs on Windows without any difficulties.
- jhgb 3y ago
  I believe that Chez should support Windows very well, even to the extent of supporting COM calls.
- kerkeslager 3y ago
  Racket has supported Windows since I tried it out in high school, which was a long, long time ago. The thing with Schemes is that you can implement one in an afternoon, and you can probably add some neato feature in the same afternoon, so there are a ton of Schemes out there. But you can't build community, ecosystem of libraries, platform support, etc. that you would want for a language you're going to use in production. Racket has been around for a long time, is used in various production systems, and has a solid community. It actually has the best standard library I know of for writing desktop GUIs, which might not be much of a claim to fame in 2023, but makes it super useful for writing small desktop tools. It definitely does some things better than others, like any language, but I think I'd be comfortable committing to it for a production project any day, which is more than I can say for any other Scheme.

pmarreck 3y ago

Elixir is like a LISP with pure functions, only immutable values all the way down (which gets you a guarantee you wouldn't have otherwise in languages where this is optional), actor concurrency, pattern-matching, actual readable syntax, and of course macros (which do the same thing LISP macros do- Accept and output an AST value that happens at the compilation step- the only difference being LISP homoiconicity). It singlehandedly ended my Haskell envy, my LISP envy and my Erlang envy, while essentially killing off what remained of my Ruby romance. I just wish I could 1) compile it directly to a single binary (so I still have some Rust and Go envy), 2) run it 100% in the browser (so I still have some Clojure envy via ClojureScript), 3) talk to ML stuff as well as Python can (although Elixir Nx and Livebooks are coming along!)

erichocean 3y ago
Clojure does all three: 1) Native, compiled binaries with GraalVM. 2) ClojureScript (already mentioned) for the browser. 3) For ML, Clojure in the last 2-3 years has built a really great internal ecosystem but it hardly matters because libpython-clj exists so you can run NumPy, PyTorth, etc. from Clojure. Getting data in and out of Python land is just as easy as Java-interop. The reverse also works (calling out to Clojure from an arbitrary Python interpreter). Plus a few other things you didn't mention: 4) ClojErl is Clojure on BEAM. You have full access to Erlang libraries (e.g OTP) and 98% of Clojure, missing only things that don't make sense on BEAM. 5) Write native iOS/Android apps with either React Native or Flutter (via ClojureDart). Develop them interactively just like you do browser stuff with ClojureScript. 6) Clojure now makes a great scripting platform with Babushka, which has completed replaced Node.js/Python/Bash for that use case for me. 6) Datomic/Datalog, there's still nothing like it after 10 years and in the last two weeks, it's Apache 2-licensed free to use and deploy. Elixir/Erlang are really impressive, but being BEAM-only is a serious limitation. Clojure is a bit more practical (and I still get to run Clojure-on-BEAM when that makes sense).
- pmarreck 3y ago
  How did they make Babashka (it’s apparently spelled that way) instantly start? Do they pre-warm a Java thread in the background? Do math errors still dump Java stack traces in Clojure? That and the lack of syntax once ruled it out for me.

ibiza 3y ago

The "other editors" link[1] is welcome. I've never liked the implicit Emacs requirement associated w/ Lisp envs. The list includes Vim, NeoVim, & even IntelliJ!? Good stuff. 1. https://lispcookbook.github.io/cl-cookbook/editor-support.html https://lispcookbook.github.io/cl-cookbook/editor-support.ht...

eviks 3y ago

> The Lisp designers do not assume what syntax, features or functions will be necessary in the future. The developers of Lisp give you the full powers that they had to develop the language. Isn't that ~ abdicating responsibility for language design?

hajile 3y ago
Definitely not. Guy Steele was involved in the specs for C, JS, Fortran, scheme, Common Lisp, and Java (among others). He gave a must-watch talk about Java called “Growing a Language”. https://youtu.be/_ahvzDzKdB0 https://youtu.be/_ahvzDzKdB0 He makes a great case that a language must be able to deal with future problems and ideas the original designers didn’t or couldn’t foresee. He seems to have been one of the voices pushing for stuff like generics so users could design libraries that would feel more native. And of course, I can’t mention him here without quoting his statement about Java: > We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp. A goal of Common Lisp was giving all the tools future programmers might need to create new tools. As a result, you’d be hard-pressed to come up with a language feature that hasn’t been ported to CL at some time.
- eviks 3y ago
  Thanks, will check the talk later.
rgherdt 3y ago
May I quote the first sentences from Scheme's R7RS standard that relates to this topic: "Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary. Scheme demonstrates that a very small number of rules for forming expressions, with no restrictions on how they are composed, suffice to form a practical and efficient programming language that is flexible enough to support most of the major programming paradigms in use today."

kazinator 3y ago

> Future proof is a term thrown around a lot in the tech industry. This is the TXR Lisp interactive listener of TXR 286. Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for cheatsheet. Truly future-proof systems are rare; future-resistant ones are everywhere. 1> _