7 ms·

If Lisp is so great

33 points by molteanu 3y ago

PaulHoule 3y ago
I’d argue modern languages have taken many of the attributes of LISP, not least the garbage collector, development tools, higher-order functions, etc. The difference is that other languages use parsing technology based on Chomsky’s grammar whereas blub languages like Lisp can’t see the value in it. But I’d say if you are programming in Java or Python you are most of the way to LISP from Pascal or C. For that matter, Common Lisp had what was probably the first modern language specification, that, as much as it pretended to be machine independent, was carefully designed to be implementable on the 32-bit microprocessors that were then coming online. There was a time when I thought Java was the first programming language to be specified by adults but know I know they were following in the footsteps of Common Lisp.
- metaxy2 3y ago
  Raku has metaprogramming and an almost unprecedented amount of syntax... and an insanely slow implementation. Although they're chipping away at the speed thing.
  - PaulHoule 3y ago
    Metaprogramming will struggle to go mainstream. It's the way you shrink a 50,000 line program down to 1,500 lines that nobody can understand but the author. I absolutely love doing it and I think I could hand the code off to somebody and have them make small changes in the DSL code but if they have to change something in the implementation to extend the DSL all bets are off. After all these years we still don't have macro assemblers as good as what the IBM 360 had even though we now have architectures that have enough registers that it would be reasonable to pass a register name as an argument to a macro like you could do in IBM Macro Assembler.
  - lizmat 3y ago
    When was the last time you checked performance? :-)
    - metaxy2 3y ago
      I actually did make a quick search to see if I was blowing hot air, and found this blog post that shows a bunch of benchmarks over time with a fairly typical Raku/Perl flavored text processing task, and it was taking 0.23s for the July 2022 release vs. 0.59s in Jan 2016 [1]. So that's a pretty impressive improvement--3x over 6 years--but I remember Raku being numbers like 4x or 5x slower than Python on benchmarks from the last few years, so by my very sloppy math it's still got to speed up by at least 2x or 3x to go to match Python. It's also possible that there has been a ton of speedup in the last year-and-a-half since that benchmark, or it's not representative, but that's where I got the idea from. [1] https://blogs.perl.org/users/sylvain_colinet/2023/01/benchmarking-rakudo-releases-is-raku-still-slow.html https://blogs.perl.org/users/sylvain_colinet/2023/01/benchma...
  - librasteve 3y ago
    Like most scripting languages (e.g. Python), execution speed was not the top priority - in fact, like Python, most heavy lifting can be / is done by modules that are written in native C code, or Rust or similar via the C FFI / Inline::Perl interfaces. To your point, I recently measured the compile time of this raku module... # speed (2020) # use Physics::Measure :ALL; ...13s first-, 2.8s pre- compiled # speed (2024) # use Physics::Measure :ALL; ...4.4s first-, 0.9s pre- compiled ... so about a 3x speed up in the last 4 years. Also raku has no GIL and has good support for hyper / race so can get a lot out of your 32 cores (if you want speed). Another raku module to mention (Dan::Polars) connects to the Rust Polars library via FFI (thus getting Rust level execution speed since Polars a lot faster than Python Pandas via the underling Apache Arrow data structures) ... this takes about 2s for the raku to compile and about 15s for the rust cargo stack to compile ...
- ParetoOptimal 3y ago
  > I’d argue modern languages have taken many of the attributes of LISP, not least the garbage collector, development tools, higher-order functions, etc. Having features of a given language don't make something a full or even partial replacement for that language. "It's not what languages do, it's what they shepherd you to" - https://nibblestew.blogspot.com/2020/03/its-not-what-programming-languages-do.html https://nibblestew.blogspot.com/2020/03/its-not-what-program...
- jj999 3y ago
  > blub languages like Lisp I see what you did[0] here. 0: https://wiki.c2.com/?BlubParadox https://wiki.c2.com/?BlubParadox
- agumonkey 3y ago
  And to me the parsing aspect of lisp is key. It means the language won't resort to external tooling to improve. Most of the programming world defaults to increasing the number of things you need in order to do more, while lispers seemed to like absorption of concepts as the main strategy (see Steele: growing a language talk IIRC).
  - PaulHoule 3y ago
    And you wind up overloading a small number of syntax constructions for an endlessly expanding number of uses and soon you're in a twisty maze of parenthesis that all look alike. Look at how HP calculators got trashed by TI. I'd grant that parser generators still suck, people still act like you're crazy when you say you want to be able to write one grammar and automatically generate not just a parser but an unparser. (I could do amazing stuff with Sphinx if only it supported RST output as well as schemaless RST.) CASE tools in the 1990 could parse code, let you edit it in a GUI, and make a clean edit to the code (not mess up comments, whitespace, and the ordering of things which is only significant to your version control tools) like a professional programmer would. That's still like something that fell off a UFO. You should totally be able to compose two grammars. I ought to be able to stick a SQL query right into the middle of program in Java or any other language and have it parsed to an AST. If parser generators were sane I could add unless(X) { Y } to a language like Java and add a method that rewrites it to if(!X) { Y } and it shouldn't be more than 50 lines of code including imports and ceremony, just a patch to the grammar (AST objects ought to be code generated from the grammar) a simple rewriting function and telling the system where to find the grammar patch and the new function. Parsing Expression Grammars are a step in the right direction but for a PEG parser to be really revolutionary it needs a few features I've yet to see in one, in particular there has to be some easy way to specify operator precedence either numerically or with a set of statements like Closer(*,+) I am mostly disappointed w/ the PEG parser in Python because it falls short of revolutionary promises but you always get "fooled again" with parsing because people care about how fast their compilers are to the exclusion of almost everything else.
    - agumonkey 3y ago
      The twisty maze of parens I never understand. (And the fact that TI won is probably, imho, only vaguely to syntax, kids barely use calcs anyway, and I'd argue that if you'd show them RPL immense programming surface, lists, vectors, lambdas, they'd use it more than the usual fix function graphing calc) I never had a chance to see proper CASE tools, my education started in 2000.. java/uml took the light and the few environments I saw were very very subpar (post IBM, eclipse based, rational suite). The grammar composition is still a big open problem, I think Lawrence Tratt tried to attack it (maybe this https://soft-dev.org/pubs/pdf/diekmann_tratt__parsing_composed_grammars_with_language_boxes.pdf https://soft-dev.org/pubs/pdf/diekmann_tratt__parsing_compos... ?) but concluded it was still fragile/difficult.
mapreduce 3y ago
I'm afraid that most people would just read the title and start completing the title with whatever ideas they have about why Lisp is not mainstream. I read the whole article and its a lot of words to simply say: There are a lot of factors at play. It could be a mix of those factors. Beyond that the article does not seem to give any specific insights. It provides many loose analogies to show how something good might not be not mainstream in other walks of life. But it does not go on to elaborate what it is specifically about Lisp. So I guess I am trying to say I don't know what to do with this article. The talking points are all common sense. And there's nothing specific about Lisp I can learn from this article.
- aredox 3y ago
  This article is not about lisp. It is about values and judgement.
- countWSS 3y ago
  The main factors are alien syntax and extremely deep abstraction levels, leading to cryptic/dense code like APL but with nested lists instead of arrays.
- ptx 3y ago
  I'm not even sure all the points are common sense. Is he saying that English is better than Chinese? Or that using a different kind of keyboard for Chinese would be better? Or that the author believes that only English uses the Latin alphabet? What point is he trying to make about golden crowns and Caesar having nothing to conquer? That using Lisp would be pointless if everyone used Lisp because it's only useful for gloating about using the best language?
jampekka 3y ago
[flagged]
- pfdietz 3y ago
  [flagged]
peterisdirsa 3y ago
No static typing...
- Zambyte 3y ago
  Optional static typing. Always strongly typed.
  - erik_seaberg 3y ago
    We tend to hope so, but CLHS is full of stuff like “the consequences are undefined if the value of the declared variable is not of the declared type” which gives a lot of leeway for generating code that blows up horribly.
- wiml 3y ago
  I've been meaning to give Coalton a try: https://coalton-lang.github.io/20211010-introducing-coalton/ https://coalton-lang.github.io/20211010-introducing-coalton/ (found via a previous HN post)
- a-french-anon 3y ago
  (Talking about CL) Isn't gradual typing with a typed standard library enough? Because that's kind of what SBCL provides. Anyway, some other reasons: * Baby ducks who can't get over the parentheses (which quickly become invisible to the eye, you read Lisp via its indentation). * Baby ducks who can't get over too weird/big differences from C/C++/C#/Java/etc... like CL's compilation model. * ML typing being /the/ fad these days. * Low-level fetishism. I know a lot about this, since I've had my own C weenie phase (you know, the kind to spit on GC by principle) as a young university student, before turning smug lisp weenie ten years later; Tcl was actually my gateway drug into useful homoiconicity. * Some hard technical limitations: * No user accessible parametric deftype. * No recursive deftype (so no typed lists/trees). * Gimped hash tables (untyped, lacking literals thus read/write transparency). * CLOS being bolted on instead of truly integrated in the language; would need a JIT and something like https://github.com/marcoheisig/fast-generic-functions on system classes to go fast enough, Julia kinda does this (but it hurts my eyes). * Lack of LSP; no, SLIME/Sly isn't the same, as you're lacking lexical information that allows to complete/rename stuff. * And hundreds of other rust spots sometimes fixed by extensions (e.g. gray streams, extensible sequences) or libraries (loop -> iterate, trivia), very often crutches in look and feel.
__MatrixMan__ 3y ago
I keep trying to dedicate time to getting comfortable with lisp, and it hasn't happened yet. So I just live vicariously through posts about lisps. One thing that stands out about them is that they're all so happy. Try it. Search up a HN post about a Lisp. They'll be using words like "joyful". So my theory is that while lisp may have plenty of technical merits, part of why it's so great is that it's typically being used by people who are having fun. That's not to say that it would perform poorly if used under duress, but maybe there's some wisdom in not putting that experience that you enjoy anywhere near drudgery, lest it become contaminated.
- cogman10 3y ago
  Here's what my company experienced with lisp. We had a small group (~20 devs all together) that decided they wanted to do a lot with clojure. So they started several projects throughout the company and, for the most part, they all very much enjoyed using clojure. However, as those projects shifted into maintenance mode and that group moved on to greener pastures, we were left with a bunch of projects that were inscrutable. The big issue we ran into is that lisp LOVES to give programmers the ability to metaprogram and programmers love metaprogramming. However, when it comes to maintaining a metaprogrammed monster... that's basically just learning a new language used by nobody but this single project. The end result was that people dreaded taking charge of lisp projects. They were hard to ramp up on. Hard to maintain. And they had really strange and hard to diagnose bugs. We've since spent the money rewriting most of the projects in java. I believe there are 2 that were simply too big and complex to do such rewrites against. My takeaway is that lisp is much like perl. When you know what you are doing it can be a lot of fun, but heaven help the person that has to later read what you wrote.
  - Viliam1234 3y ago
    > programmers love metaprogramming and (many of them) hate writing documentation. > that's basically just learning a new language used by nobody but this single project and there is no source to learn the language from. other than the "self-documenting" code, which often isn't. I am not opposed to using abstraction. Sometimes abstractions are powerful. But the more abstract you go, the more effort you need to spend to make sure you communicated it properly to the rest of the team -- including its future members.
cmiller1 3y ago
What a long and meandering post just to say "sometimes practical and theoretical needs are different"
deleted 3y ago
[deleted]
amarshall 3y ago
> their querty keyboards Is this an unintentional misspelling, or an intentional one? That it’s italicized makes me think it’s an intentional reference or joke—if so, what is it?
- molteanu 3y ago
  Unintentional. Fixed.
agentultra 3y ago
Also related: https://www.youtube.com/watch?v=QyJZzq0v7Z4 https://www.youtube.com/watch?v=QyJZzq0v7Z4 Network effects likely explain a big part of it. Many of the "popular" languages today aren't necessarily great languages and adopted for their technical merits. Often they were the only language available on an exclusive platform everyone wanted to develop software on. Other times it was because folks wanted to write a particular kind of application and there just happened to be this framework in this weird language that made the task easy. We probably have more programming languages now than ever before but I think the market for new languages in the mainstream is relatively static. It shifts... but very slowly.
JonChesterfield 3y ago
Reluctant to say this in the current climate of "yay static typing" but I am starting to find some things easier to express in SML than in scheme. The type driven pattern matching is a really big thing. Currently liking lisp for exploratory programming and ML for precise communication of fully formed ideas to the machine. Anyone happen to know a lisp/ML pair that target the same VM/IR for seamless interop between the two? (in this context ML is metalanguage, ideally StandardML, though ocaml/miranda/haskell are the same sort of idea)
- kagevf 3y ago
  What about Coalton?
moomin 3y ago
It's quite an entertaining rant, but the scattergun approach means that it's one of those things where it's impossible to address the points made because there's so many. But to just look at the first paragraph: "There is only so much space available in a city." Is there a limited number of possible LISP practitioners in the world? Looking at the broader point: yes, there are a lot of factors to take into account, but perhaps we should be looking at the factors that specifically involve LISP.
- molteanu 3y ago
  Well, yes, and the discussion about the "factors that specifically involve LISP" has been going on since forever with no end in sight. So maybe there a at least some extra forces involved here. Who knows. I'm just exploring.
zellyn 3y ago
Is there a modern, non-JVM lisp that cleanly threads types through the expressions? I'm thinking like Haskell or Roc, where the type definitions are optional, but can be written down for clarity. Lisp was by far my favorite language in college, but these days the idea of sloshing around in all those untyped s-expressions just gives me the willies.
deleted 3y ago
[deleted]
countWSS 3y ago
A curious counter-example to 'metaprogramming is essential' is Zig that explicitly rejects macros and "abstraction towers", there is no operator overloading or OOP methods.
samsquire 3y ago
LISP is postorder evaluation order of a tree. We can go further and more mind expansive than this! The future I am trying to design is a language where traversal order is arbitrarily repetitive and arbitrary and corecursive and has term rewriting traversals. I think algorithms are just reified traversal evaluation orders and joins - of algebra and mathematics.
myaccountonhn 3y ago
I enjoyed the article, I wish the author put up an RSS feed so it’s possible to follow and read new articles as they are published
PaulHoule 3y ago
If you look at the examples https://en.wikipedia.org/wiki/Paradigms_of_AI_Programming https://en.wikipedia.org/wiki/Paradigms_of_AI_Programming I'd say that these would be a struggle to implement in FORTRAN or BASIC, possible in C or C++, easy in Python, and (for me) joyful in Java. One of the most important features is having hashtables in the standard library which the last two languages have but the first four don't.
deleted 3y ago
[deleted]
kugurerdem 3y ago
I actually really liked the rhetoric made in the essay. The only problem is that the title may imply that this essay is about Lisp, while it's more about the ambiguity that are caused by words like "best". The key takeaway of the essay is that: When someone questions why something supposed to be "best" isn't widely used, the answer is not solely technical. It also have sociological, philosophical, economic, and political aspects.
- molteanu 3y ago
  Indeed, it is. And yes, Lisp is only marginally relevant to the point beeing made. It's just that the question "if X is the best why hasn't it won" and similar variants of it spring up so often around Lisp and are not quite resolved or even close to being resolved. The essay is thus attacking the question form a different angle. Thanks for the kind words.
librasteve 3y ago
Raku (www.raku.org) does a surprisingly good impression of Lisp: (sub (:&is-even = (sub (\n) {([or] ([==] 0, n), (is-odd (pred n:)))}), :&is-odd = (sub (\n) {([and] (not ([==] 0, n)), (is-even (pred n:)))})) {is-odd 11})() https://www.codesections.com/blog/raku-lisp-impression/ https://www.codesections.com/blog/raku-lisp-impression/
fulafel 3y ago
"If X is so great, whe aren't everyone using it" implies that programming languages exist in some kind of well working marketplace of ideas where the best on their own merits win out. But it's not like that at all.

33 points by molteanu 3y ago

I’d argue modern languages have taken many of the attributes of LISP, not least the garbage collector, development tools, higher-order functions, etc. The difference is that other languages use parsing technology based on Chomsky’s grammar whereas blub languages like Lisp can’t see the value in it. But I’d say if you are programming in Java or Python you are most of the way to LISP from Pascal or C. For that matter, Common Lisp had what was probably the first modern language specification, that, as much as it pretended to be machine independent, was carefully designed to be implementable on the 32-bit microprocessors that were then coming online. There was a time when I thought Java was the first programming language to be specified by adults but know I know they were following in the footsteps of Common Lisp.

metaxy2 3y ago
Raku has metaprogramming and an almost unprecedented amount of syntax... and an insanely slow implementation. Although they're chipping away at the speed thing.
- PaulHoule 3y ago
  Metaprogramming will struggle to go mainstream. It's the way you shrink a 50,000 line program down to 1,500 lines that nobody can understand but the author. I absolutely love doing it and I think I could hand the code off to somebody and have them make small changes in the DSL code but if they have to change something in the implementation to extend the DSL all bets are off. After all these years we still don't have macro assemblers as good as what the IBM 360 had even though we now have architectures that have enough registers that it would be reasonable to pass a register name as an argument to a macro like you could do in IBM Macro Assembler.
- lizmat 3y ago
  When was the last time you checked performance? :-)
  - metaxy2 3y ago
    I actually did make a quick search to see if I was blowing hot air, and found this blog post that shows a bunch of benchmarks over time with a fairly typical Raku/Perl flavored text processing task, and it was taking 0.23s for the July 2022 release vs. 0.59s in Jan 2016 [1]. So that's a pretty impressive improvement--3x over 6 years--but I remember Raku being numbers like 4x or 5x slower than Python on benchmarks from the last few years, so by my very sloppy math it's still got to speed up by at least 2x or 3x to go to match Python. It's also possible that there has been a ton of speedup in the last year-and-a-half since that benchmark, or it's not representative, but that's where I got the idea from. [1] https://blogs.perl.org/users/sylvain_colinet/2023/01/benchmarking-rakudo-releases-is-raku-still-slow.html https://blogs.perl.org/users/sylvain_colinet/2023/01/benchma...
- librasteve 3y ago
  Like most scripting languages (e.g. Python), execution speed was not the top priority - in fact, like Python, most heavy lifting can be / is done by modules that are written in native C code, or Rust or similar via the C FFI / Inline::Perl interfaces. To your point, I recently measured the compile time of this raku module... # speed (2020) # use Physics::Measure :ALL; ...13s first-, 2.8s pre- compiled # speed (2024) # use Physics::Measure :ALL; ...4.4s first-, 0.9s pre- compiled ... so about a 3x speed up in the last 4 years. Also raku has no GIL and has good support for hyper / race so can get a lot out of your 32 cores (if you want speed). Another raku module to mention (Dan::Polars) connects to the Rust Polars library via FFI (thus getting Rust level execution speed since Polars a lot faster than Python Pandas via the underling Apache Arrow data structures) ... this takes about 2s for the raku to compile and about 15s for the rust cargo stack to compile ...
ParetoOptimal 3y ago
> I’d argue modern languages have taken many of the attributes of LISP, not least the garbage collector, development tools, higher-order functions, etc. Having features of a given language don't make something a full or even partial replacement for that language. "It's not what languages do, it's what they shepherd you to" - https://nibblestew.blogspot.com/2020/03/its-not-what-programming-languages-do.html https://nibblestew.blogspot.com/2020/03/its-not-what-program...
jj999 3y ago
> blub languages like Lisp I see what you did[0] here. 0: https://wiki.c2.com/?BlubParadox https://wiki.c2.com/?BlubParadox
agumonkey 3y ago
And to me the parsing aspect of lisp is key. It means the language won't resort to external tooling to improve. Most of the programming world defaults to increasing the number of things you need in order to do more, while lispers seemed to like absorption of concepts as the main strategy (see Steele: growing a language talk IIRC).
- PaulHoule 3y ago
  And you wind up overloading a small number of syntax constructions for an endlessly expanding number of uses and soon you're in a twisty maze of parenthesis that all look alike. Look at how HP calculators got trashed by TI. I'd grant that parser generators still suck, people still act like you're crazy when you say you want to be able to write one grammar and automatically generate not just a parser but an unparser. (I could do amazing stuff with Sphinx if only it supported RST output as well as schemaless RST.) CASE tools in the 1990 could parse code, let you edit it in a GUI, and make a clean edit to the code (not mess up comments, whitespace, and the ordering of things which is only significant to your version control tools) like a professional programmer would. That's still like something that fell off a UFO. You should totally be able to compose two grammars. I ought to be able to stick a SQL query right into the middle of program in Java or any other language and have it parsed to an AST. If parser generators were sane I could add unless(X) { Y } to a language like Java and add a method that rewrites it to if(!X) { Y } and it shouldn't be more than 50 lines of code including imports and ceremony, just a patch to the grammar (AST objects ought to be code generated from the grammar) a simple rewriting function and telling the system where to find the grammar patch and the new function. Parsing Expression Grammars are a step in the right direction but for a PEG parser to be really revolutionary it needs a few features I've yet to see in one, in particular there has to be some easy way to specify operator precedence either numerically or with a set of statements like Closer(*,+) I am mostly disappointed w/ the PEG parser in Python because it falls short of revolutionary promises but you always get "fooled again" with parsing because people care about how fast their compilers are to the exclusion of almost everything else.
  - agumonkey 3y ago
    The twisty maze of parens I never understand. (And the fact that TI won is probably, imho, only vaguely to syntax, kids barely use calcs anyway, and I'd argue that if you'd show them RPL immense programming surface, lists, vectors, lambdas, they'd use it more than the usual fix function graphing calc) I never had a chance to see proper CASE tools, my education started in 2000.. java/uml took the light and the few environments I saw were very very subpar (post IBM, eclipse based, rational suite). The grammar composition is still a big open problem, I think Lawrence Tratt tried to attack it (maybe this https://soft-dev.org/pubs/pdf/diekmann_tratt__parsing_composed_grammars_with_language_boxes.pdf https://soft-dev.org/pubs/pdf/diekmann_tratt__parsing_compos... ?) but concluded it was still fragile/difficult.

mapreduce 3y ago

I'm afraid that most people would just read the title and start completing the title with whatever ideas they have about why Lisp is not mainstream. I read the whole article and its a lot of words to simply say: There are a lot of factors at play. It could be a mix of those factors. Beyond that the article does not seem to give any specific insights. It provides many loose analogies to show how something good might not be not mainstream in other walks of life. But it does not go on to elaborate what it is specifically about Lisp. So I guess I am trying to say I don't know what to do with this article. The talking points are all common sense. And there's nothing specific about Lisp I can learn from this article.

aredox 3y ago
This article is not about lisp. It is about values and judgement.
countWSS 3y ago
The main factors are alien syntax and extremely deep abstraction levels, leading to cryptic/dense code like APL but with nested lists instead of arrays.
ptx 3y ago
I'm not even sure all the points are common sense. Is he saying that English is better than Chinese? Or that using a different kind of keyboard for Chinese would be better? Or that the author believes that only English uses the Latin alphabet? What point is he trying to make about golden crowns and Caesar having nothing to conquer? That using Lisp would be pointless if everyone used Lisp because it's only useful for gloating about using the best language?

jampekka 3y ago

[flagged]

pfdietz 3y ago
[flagged]

peterisdirsa 3y ago

No static typing...

Zambyte 3y ago
Optional static typing. Always strongly typed.
- erik_seaberg 3y ago
  We tend to hope so, but CLHS is full of stuff like “the consequences are undefined if the value of the declared variable is not of the declared type” which gives a lot of leeway for generating code that blows up horribly.
wiml 3y ago
I've been meaning to give Coalton a try: https://coalton-lang.github.io/20211010-introducing-coalton/ https://coalton-lang.github.io/20211010-introducing-coalton/ (found via a previous HN post)
a-french-anon 3y ago
(Talking about CL) Isn't gradual typing with a typed standard library enough? Because that's kind of what SBCL provides. Anyway, some other reasons: * Baby ducks who can't get over the parentheses (which quickly become invisible to the eye, you read Lisp via its indentation). * Baby ducks who can't get over too weird/big differences from C/C++/C#/Java/etc... like CL's compilation model. * ML typing being /the/ fad these days. * Low-level fetishism. I know a lot about this, since I've had my own C weenie phase (you know, the kind to spit on GC by principle) as a young university student, before turning smug lisp weenie ten years later; Tcl was actually my gateway drug into useful homoiconicity. * Some hard technical limitations: * No user accessible parametric deftype. * No recursive deftype (so no typed lists/trees). * Gimped hash tables (untyped, lacking literals thus read/write transparency). * CLOS being bolted on instead of truly integrated in the language; would need a JIT and something like https://github.com/marcoheisig/fast-generic-functions on system classes to go fast enough, Julia kinda does this (but it hurts my eyes). * Lack of LSP; no, SLIME/Sly isn't the same, as you're lacking lexical information that allows to complete/rename stuff. * And hundreds of other rust spots sometimes fixed by extensions (e.g. gray streams, extensible sequences) or libraries (loop -> iterate, trivia), very often crutches in look and feel.

__MatrixMan__ 3y ago

I keep trying to dedicate time to getting comfortable with lisp, and it hasn't happened yet. So I just live vicariously through posts about lisps. One thing that stands out about them is that they're all so happy. Try it. Search up a HN post about a Lisp. They'll be using words like "joyful". So my theory is that while lisp may have plenty of technical merits, part of why it's so great is that it's typically being used by people who are having fun. That's not to say that it would perform poorly if used under duress, but maybe there's some wisdom in not putting that experience that you enjoy anywhere near drudgery, lest it become contaminated.

cogman10 3y ago
Here's what my company experienced with lisp. We had a small group (~20 devs all together) that decided they wanted to do a lot with clojure. So they started several projects throughout the company and, for the most part, they all very much enjoyed using clojure. However, as those projects shifted into maintenance mode and that group moved on to greener pastures, we were left with a bunch of projects that were inscrutable. The big issue we ran into is that lisp LOVES to give programmers the ability to metaprogram and programmers love metaprogramming. However, when it comes to maintaining a metaprogrammed monster... that's basically just learning a new language used by nobody but this single project. The end result was that people dreaded taking charge of lisp projects. They were hard to ramp up on. Hard to maintain. And they had really strange and hard to diagnose bugs. We've since spent the money rewriting most of the projects in java. I believe there are 2 that were simply too big and complex to do such rewrites against. My takeaway is that lisp is much like perl. When you know what you are doing it can be a lot of fun, but heaven help the person that has to later read what you wrote.
- Viliam1234 3y ago
  > programmers love metaprogramming and (many of them) hate writing documentation. > that's basically just learning a new language used by nobody but this single project and there is no source to learn the language from. other than the "self-documenting" code, which often isn't. I am not opposed to using abstraction. Sometimes abstractions are powerful. But the more abstract you go, the more effort you need to spend to make sure you communicated it properly to the rest of the team -- including its future members.

cmiller1 3y ago

What a long and meandering post just to say "sometimes practical and theoretical needs are different"

deleted 3y ago

[deleted]

amarshall 3y ago

> their querty keyboards Is this an unintentional misspelling, or an intentional one? That it’s italicized makes me think it’s an intentional reference or joke—if so, what is it?

molteanu 3y ago
Unintentional. Fixed.

agentultra 3y ago

Also related: https://www.youtube.com/watch?v=QyJZzq0v7Z4 https://www.youtube.com/watch?v=QyJZzq0v7Z4 Network effects likely explain a big part of it. Many of the "popular" languages today aren't necessarily great languages and adopted for their technical merits. Often they were the only language available on an exclusive platform everyone wanted to develop software on. Other times it was because folks wanted to write a particular kind of application and there just happened to be this framework in this weird language that made the task easy. We probably have more programming languages now than ever before but I think the market for new languages in the mainstream is relatively static. It shifts... but very slowly.

JonChesterfield 3y ago

Reluctant to say this in the current climate of "yay static typing" but I am starting to find some things easier to express in SML than in scheme. The type driven pattern matching is a really big thing. Currently liking lisp for exploratory programming and ML for precise communication of fully formed ideas to the machine. Anyone happen to know a lisp/ML pair that target the same VM/IR for seamless interop between the two? (in this context ML is metalanguage, ideally StandardML, though ocaml/miranda/haskell are the same sort of idea)

kagevf 3y ago
What about Coalton?

moomin 3y ago

It's quite an entertaining rant, but the scattergun approach means that it's one of those things where it's impossible to address the points made because there's so many. But to just look at the first paragraph: "There is only so much space available in a city." Is there a limited number of possible LISP practitioners in the world? Looking at the broader point: yes, there are a lot of factors to take into account, but perhaps we should be looking at the factors that specifically involve LISP.

molteanu 3y ago
Well, yes, and the discussion about the "factors that specifically involve LISP" has been going on since forever with no end in sight. So maybe there a at least some extra forces involved here. Who knows. I'm just exploring.

zellyn 3y ago

Is there a modern, non-JVM lisp that cleanly threads types through the expressions? I'm thinking like Haskell or Roc, where the type definitions are optional, but can be written down for clarity. Lisp was by far my favorite language in college, but these days the idea of sloshing around in all those untyped s-expressions just gives me the willies.

deleted 3y ago

[deleted]

countWSS 3y ago

A curious counter-example to 'metaprogramming is essential' is Zig that explicitly rejects macros and "abstraction towers", there is no operator overloading or OOP methods.

samsquire 3y ago

LISP is postorder evaluation order of a tree. We can go further and more mind expansive than this! The future I am trying to design is a language where traversal order is arbitrarily repetitive and arbitrary and corecursive and has term rewriting traversals. I think algorithms are just reified traversal evaluation orders and joins - of algebra and mathematics.

myaccountonhn 3y ago

I enjoyed the article, I wish the author put up an RSS feed so it’s possible to follow and read new articles as they are published

PaulHoule 3y ago

If you look at the examples https://en.wikipedia.org/wiki/Paradigms_of_AI_Programming https://en.wikipedia.org/wiki/Paradigms_of_AI_Programming I'd say that these would be a struggle to implement in FORTRAN or BASIC, possible in C or C++, easy in Python, and (for me) joyful in Java. One of the most important features is having hashtables in the standard library which the last two languages have but the first four don't.

deleted 3y ago

[deleted]

kugurerdem 3y ago

I actually really liked the rhetoric made in the essay. The only problem is that the title may imply that this essay is about Lisp, while it's more about the ambiguity that are caused by words like "best". The key takeaway of the essay is that: When someone questions why something supposed to be "best" isn't widely used, the answer is not solely technical. It also have sociological, philosophical, economic, and political aspects.

molteanu 3y ago
Indeed, it is. And yes, Lisp is only marginally relevant to the point beeing made. It's just that the question "if X is the best why hasn't it won" and similar variants of it spring up so often around Lisp and are not quite resolved or even close to being resolved. The essay is thus attacking the question form a different angle. Thanks for the kind words.

librasteve 3y ago

Raku (www.raku.org) does a surprisingly good impression of Lisp: (sub (:&is-even = (sub (\n) {([or] ([==] 0, n), (is-odd (pred n:)))}), :&is-odd = (sub (\n) {([and] (not ([==] 0, n)), (is-even (pred n:)))})) {is-odd 11})() https://www.codesections.com/blog/raku-lisp-impression/ https://www.codesections.com/blog/raku-lisp-impression/

fulafel 3y ago

"If X is so great, whe aren't everyone using it" implies that programming languages exist in some kind of well working marketplace of ideas where the best on their own merits win out. But it's not like that at all.