Ask HN: Why is everyone here so obsessed with Lisp?
I see like 2-3 posts a day about Lisp. What's so good about it?
107 comments
Many comments mention the merits of Lisp. That's all well and good, but I think they miss the largely historical reasons that Lisp is so popular here:
Paul Graham wrote Ansi Common Lisp and On Lisp. Both are great books and were used in university courses in the 90s and 00s.
Paul Graham cofounded a startup called Viaweb, implemented in Lisp, that sold to Yahoo.
Paul Graham wrote a bunch of essays about tech startups at paulgraham.com. These essays frequently extolled the virtues of Lisp and other high level languages, citing it as a major factor in Viaweb's success.
Paul Graham, in his essays, strongly encouraged skilled, motivated programmers to build startups instead of working at large companies.
Paul Graham created Y Combinator, betting his time and money on the growth of startups that he predicted and promoted, popularizing startup incubators in the process.
Paul Graham created Startup News when Reddit started going mainstream, predating the existence of subreddits. Startup News provided a real-world application to inform the design and development of Arc, a Lisp language.
Paul Graham renamed Startup News to Hacker News. And here we are.
===
As someone who has been here for 12½ years, I view the Lisp sentiment as echoes of HN's past, inextricably linked to the Lisp enthusiasm of HN's founder: Paul Graham.
While I agree with many comments here that Lisp is a language worth learning, I think they miss the mark as to why Lisp continues to come up on Hacker News. The majority of the original Startup News members were Lisp enthusiasts.
Paul Graham wrote Ansi Common Lisp and On Lisp. Both are great books and were used in university courses in the 90s and 00s.
Paul Graham cofounded a startup called Viaweb, implemented in Lisp, that sold to Yahoo.
Paul Graham wrote a bunch of essays about tech startups at paulgraham.com. These essays frequently extolled the virtues of Lisp and other high level languages, citing it as a major factor in Viaweb's success.
Paul Graham, in his essays, strongly encouraged skilled, motivated programmers to build startups instead of working at large companies.
Paul Graham created Y Combinator, betting his time and money on the growth of startups that he predicted and promoted, popularizing startup incubators in the process.
Paul Graham created Startup News when Reddit started going mainstream, predating the existence of subreddits. Startup News provided a real-world application to inform the design and development of Arc, a Lisp language.
Paul Graham renamed Startup News to Hacker News. And here we are.
===
As someone who has been here for 12½ years, I view the Lisp sentiment as echoes of HN's past, inextricably linked to the Lisp enthusiasm of HN's founder: Paul Graham.
While I agree with many comments here that Lisp is a language worth learning, I think they miss the mark as to why Lisp continues to come up on Hacker News. The majority of the original Startup News members were Lisp enthusiasts.
It's elegant. It's (relatively) easy to write a basic parser. LISP code is readily expressible in the same basic data structures provided in the language so you get meta programming almost for free and thus extending LISP is (relatively) easy too. Whereas C feels like an abstract machine language, LISP feels like an abstract 'mathematical computation' language. It's, like all languages, a different way of thinking about computation in the same way that human languages also seem to be (at least marginally) different ways of representing or expressing thought.
And once you've come to appreciate it, jokes like "HAVE YOU READ YOUR SICP TODAY?" will be funny to you.
In terms of 'getting shit done', it's not so 'good', not that one can't get shit done with LISP, but that it's not necessary nor, given all likely real world constraints, particularly that much of, if at all, an advantage relative to other (families of) languages.
It's also historically important so there's a benefit in knowing about it and being familiar with it too. And knowing the history helps understand why people still love it, even as a lot of what was once unique or special about it can be found much more widely.
And once you've come to appreciate it, jokes like "HAVE YOU READ YOUR SICP TODAY?" will be funny to you.
In terms of 'getting shit done', it's not so 'good', not that one can't get shit done with LISP, but that it's not necessary nor, given all likely real world constraints, particularly that much of, if at all, an advantage relative to other (families of) languages.
It's also historically important so there's a benefit in knowing about it and being familiar with it too. And knowing the history helps understand why people still love it, even as a lot of what was once unique or special about it can be found much more widely.
Lisp is very valuable in the concepts which it teaches; expression trees and their inherent parallelism, functions without side-effects, structured data definition, lazy evaluation.
I've been programming for about 30 years, and did a fair bit of scheme, then lisp early on. I no longer use it, and it's not a great modern language for a lot of internet or IO stuff, but as a data transformation language, few are its equal. I still apply what I learned from lisp to write better code in Java, Go, Python. It puts you into a mindset of using composition of simple functions and data structures, which will generally lead to better code in any language.
I've been programming for about 30 years, and did a fair bit of scheme, then lisp early on. I no longer use it, and it's not a great modern language for a lot of internet or IO stuff, but as a data transformation language, few are its equal. I still apply what I learned from lisp to write better code in Java, Go, Python. It puts you into a mindset of using composition of simple functions and data structures, which will generally lead to better code in any language.
> it's not a great modern language for a lot of internet or IO stuff
I think Clojure is a great language for internet stuff and possibly great even for IO stuff too, depending on what you mean by that. The LISP-iness is probably better for the former but builtin Java interop probably goes a long way towards being pretty-good for the latter.
What exactly were you thinking-of by "IO stuff"? Graphics? Embedded systems programming? I'd think Clojure could be just as good as Java or Python for all of those, tho existing libraries aren't going to be quite as good as C/C++, and Go will probably be better-performing generally.
And there are (because of course there are) LISPs for real-time embedded systems programming:
- [nakkaya/ferret: Ferret is a free software lisp implementation for real time embedded control systems.](https://github.com/nakkaya/ferret)
I think Clojure is a great language for internet stuff and possibly great even for IO stuff too, depending on what you mean by that. The LISP-iness is probably better for the former but builtin Java interop probably goes a long way towards being pretty-good for the latter.
What exactly were you thinking-of by "IO stuff"? Graphics? Embedded systems programming? I'd think Clojure could be just as good as Java or Python for all of those, tho existing libraries aren't going to be quite as good as C/C++, and Go will probably be better-performing generally.
And there are (because of course there are) LISPs for real-time embedded systems programming:
- [nakkaya/ferret: Ferret is a free software lisp implementation for real time embedded control systems.](https://github.com/nakkaya/ferret)
Lisp is like the Latin of programming languages. Powerful, archaic, well-thought, elegant, venerable.
In what way is Latin powerful, compared to other languages? Or elegant?
I've had to learn a little Latin, because it's the root of half the English language, and I would not describe it this way at all. It's overly complex and arbitrary. The https://en.wikipedia.org/wiki/Latin_spelling_and_pronunciati... article is full of tables of exceptions. Over its lifetime, they not only couldn't agree on pronunciation, but whether it had lower-case letters, whether to put spaces between words, or which direction to write it.
C is Latin. It's revered because of its age and the the works written in it. It was in the right place at the right time. Half the world who came after tried to make their own improved version, and those improved versions are the languages that are actually popular today.
What spoken language is powerful and elegant? When I was in college, a friend was taking a language (I think it was Swahili but don't quote me on that) that was so simple students learned all of the grammar in the first semester. Everything after that was just learning vocabulary and getting comfortable with it. Turkish has a completely 1:1 mapping of letters to sounds, and perfectly regular conjugation. Korean also has an extremely consistent writing system. Any of those seem more Lisp-like to me than Latin.
I've had to learn a little Latin, because it's the root of half the English language, and I would not describe it this way at all. It's overly complex and arbitrary. The https://en.wikipedia.org/wiki/Latin_spelling_and_pronunciati... article is full of tables of exceptions. Over its lifetime, they not only couldn't agree on pronunciation, but whether it had lower-case letters, whether to put spaces between words, or which direction to write it.
C is Latin. It's revered because of its age and the the works written in it. It was in the right place at the right time. Half the world who came after tried to make their own improved version, and those improved versions are the languages that are actually popular today.
What spoken language is powerful and elegant? When I was in college, a friend was taking a language (I think it was Swahili but don't quote me on that) that was so simple students learned all of the grammar in the first semester. Everything after that was just learning vocabulary and getting comfortable with it. Turkish has a completely 1:1 mapping of letters to sounds, and perfectly regular conjugation. Korean also has an extremely consistent writing system. Any of those seem more Lisp-like to me than Latin.
> a language that was so simple students learned all of the grammar in the first semester.
Natural languages tend to be similar in complexity, which tends to increase to the bounds placed by a child's ability to learn. Languages with simpler grammar often have eg. more complex phonetic systems. For instance, mandarin is "simple" in that it doesn't have conjugations or tenses, but it's complex in that it has tones. Likewise, Turkish has vowel harmony.
> Korean also has an extremely consistent writing system.
Not only that, but the gylphs actually represent the mouth movements necessary to make the sounds. It's like that because Hangul is a relatively new writing system that was designed with discoveries in linguistics in mind, unlike English and French that have things like vestigial spellings (eg. "through"). So I'd say that Korean would be like an up-and-coming like, uh... Rust. Of course, writing systems aren't really part of a language itself: you can write any language in IPA.
Natural languages tend to be similar in complexity, which tends to increase to the bounds placed by a child's ability to learn. Languages with simpler grammar often have eg. more complex phonetic systems. For instance, mandarin is "simple" in that it doesn't have conjugations or tenses, but it's complex in that it has tones. Likewise, Turkish has vowel harmony.
> Korean also has an extremely consistent writing system.
Not only that, but the gylphs actually represent the mouth movements necessary to make the sounds. It's like that because Hangul is a relatively new writing system that was designed with discoveries in linguistics in mind, unlike English and French that have things like vestigial spellings (eg. "through"). So I'd say that Korean would be like an up-and-coming like, uh... Rust. Of course, writing systems aren't really part of a language itself: you can write any language in IPA.
Here is a powerful and elegant human language:
https://en.wikipedia.org/wiki/Esperanto
(although it should be said that its power is mostly hypothetical until it becomes widely used, which may be never)
I understand sanskrit is elegant and simple, and of course ancient, perhaps that would be a better analogy
I'd say Lisp is like Ancient Greek to Latin's C.
I think the general consensus is that it's great for "getting big shit done" – in other words, it's hard to beat for creating large, complex programs, but relatively crap for scripting or smaller tasks. I'm still kind of amazed how difficult it is to create a Lisp program that isn't hundreds of MB in size.
I created TXR/TXR Lisp to be great for scripting or smaller tasks. It has a small footprint and is free of annoying dependencies, yet feature-rich.
http://nongnu.org/txr
I released version 223 today, which marks the tenth anniversary, since the project's August, 2009 start.
http://nongnu.org/txr
I released version 223 today, which marks the tenth anniversary, since the project's August, 2009 start.
Most of the Schemes (Chicken, Gambit / Gerbil, Chez, Racket at least) have a way of distributing executables that are small.
I’ve used Chicken in the past to create static binaries that were on the order of hundreds of kilobytes.
I’ve used Chicken in the past to create static binaries that were on the order of hundreds of kilobytes.
> I'm still kind of amazed how difficult it is to create a Lisp program that isn't hundreds of MB in size.
That's not true IME. No doubt SBCL binaries are large, but they start around 70 Mb and grow from there. The growth depends partly on how many shared libraries are loaded when the image is created. Commercial Lisps are supposed to be better, but I haven't used them so I can't really say.
For smaller tasks SBCL (and possibly others) support scripting using a "shebang line" of "#!/usr/bin/sbcl --script".
That's not true IME. No doubt SBCL binaries are large, but they start around 70 Mb and grow from there. The growth depends partly on how many shared libraries are loaded when the image is created. Commercial Lisps are supposed to be better, but I haven't used them so I can't really say.
For smaller tasks SBCL (and possibly others) support scripting using a "shebang line" of "#!/usr/bin/sbcl --script".
Sure, I'm not saying these things can't be done, just that you get the distinct feeling that it isn't how Lisp was made to work. I might have been exaggerating about size, but 70 Mb is pretty damn big for a program that might not do all that much! I haven't ever used commercial Lisps, either.
A GUI-based 64bit 'hello world' application with LispWorks on the Mac is around 13MB in disk size.
A mocl application might start around 1 MB. But that's an unusual whole-lisp-program-to-c compiler.
A mocl application might start around 1 MB. But that's an unusual whole-lisp-program-to-c compiler.
It's dynamically typed, so, heh, that is definitely not the general consensus.
Extending Lisp can be hard work. Take an existing Common Lisp implementation and give, say, support for continuations.
Adding the necessary syntax will not be hard, however, whereas in a in a different kind of language framework, that part will have difficulties also.
What will also be easier in Lisp is for downstream users to manage the change. For instance, maybe some code relying on the new feature can work fine with some hack that just fakes some the semantics. That can be disguised under compatible syntax.
Adding the necessary syntax will not be hard, however, whereas in a in a different kind of language framework, that part will have difficulties also.
What will also be easier in Lisp is for downstream users to manage the change. For instance, maybe some code relying on the new feature can work fine with some hack that just fakes some the semantics. That can be disguised under compatible syntax.
Part of the reason is Paul Graham's essay about his experience using Lisp at a startup: http://www.paulgraham.com/avg.html
To add further clarification, Paul Graham was one of the founders of YC and built Hacker News in a LISP dialect named Arc (See https://news.ycombinator.com/item?id=9270478 for more information).
...and wrote a couple of classical common lisp books. He has obviously contributed a lot to HN’s culture.
I personally found out about both reddit and HN by means of deeping further into lisp in the internet, beyond his “ANSI Common Lisp” book which I used in university.
I personally found out about both reddit and HN by means of deeping further into lisp in the internet, beyond his “ANSI Common Lisp” book which I used in university.
That essay sent me down the functional language paradigm. I never did a lot of lisp but have done a lot of Haskell since.
I don’t get to do near as much these days, but the lessons I’ve learned have made me a better developer for sure.
Type safety and pure functions make debugging and refactoring an entirely different beast
I don’t get to do near as much these days, but the lessons I’ve learned have made me a better developer for sure.
Type safety and pure functions make debugging and refactoring an entirely different beast
And HN was (or still is?) written in Lisp
Still is, as far as I know. Technically ARC, which is a descendant and in the same family.
I am not a programmer by profession, so I can chose my own poison. Scheme is just too much fun! I never liked python,ruby,c# etc. What scheme gave me was a smallish set of well-chosen primitives that compose well. Simple syntax together with macros so that I can abstract away any boilerplate that any eventual language designer forgot to foresee in a way superior to any other language. Lisp macros really are superior. I know enough haskell to know that "we don't need macros because we have typeclasses/an expressive typesystem/template haskell" is only a half true.
Guile scheme is my scheme of choice. Not the fastest scheme (that would be chez), but it is a bliss to write things in.
I have this idea that if you are a "programming language searcher" that can never really be satisfied with what they have you either end up in the ml camp or in the lisp camp. I myself would love a lisp/ml lovechild, which is why I am following hackett closely!
Guile scheme is my scheme of choice. Not the fastest scheme (that would be chez), but it is a bliss to write things in.
I have this idea that if you are a "programming language searcher" that can never really be satisfied with what they have you either end up in the ml camp or in the lisp camp. I myself would love a lisp/ml lovechild, which is why I am following hackett closely!
To save others a search:
Haskell-like Lisp in Racket https://github.com/lexi-lambda/hackett
Haskell-like Lisp in Racket https://github.com/lexi-lambda/hackett
One thing not mentioned in the current set of responses is the REPL style and interactive coding style that you can have with a LISP that is different than what a traditional compiled language gives you in the edit-compile-run-edit loop or a dynamic language gives you in the edit-run-edit loop. When you are using a REPL you can poke and push at any part of the system like a debugger but the system is still alive. Without that interactive nature sometimes you end up doing print/debugger work to understand some quirk of a datastructure but in a LISP/REPL it's plainly visible and you don't have to think about it.
If it's integrated with an editor you can load functions or different versions of the function and see how each work with live data, you can slurp new data in, and all sorts of flexible dynamic things that let you find the program you want (which always helps when using third-party or unfamiliar code). This is more a feature of all kinds of REPL languages and not wholly specific to LISPs.
One of the basis of a LISP/Scheme language is that it is constructed of very few basic primitives that are assembled into a greater system and that greater system is part of your program instead of being things you don't touch (like libc), and you are (generally) welcome to touch them, alias them, or manipulate them to help your goal and program. This allows things like being able to temporarily hook a function call to add some debug information and then unhook a function call via a REPL and carry on. I find that pointing to people to r5rs https://schemers.org/Documents/Standards/R5RS/HTML/ and focusing on sections 4, 5, and 6 help show off how little is required to describe the basics of the language.
If it's integrated with an editor you can load functions or different versions of the function and see how each work with live data, you can slurp new data in, and all sorts of flexible dynamic things that let you find the program you want (which always helps when using third-party or unfamiliar code). This is more a feature of all kinds of REPL languages and not wholly specific to LISPs.
One of the basis of a LISP/Scheme language is that it is constructed of very few basic primitives that are assembled into a greater system and that greater system is part of your program instead of being things you don't touch (like libc), and you are (generally) welcome to touch them, alias them, or manipulate them to help your goal and program. This allows things like being able to temporarily hook a function call to add some debug information and then unhook a function call via a REPL and carry on. I find that pointing to people to r5rs https://schemers.org/Documents/Standards/R5RS/HTML/ and focusing on sections 4, 5, and 6 help show off how little is required to describe the basics of the language.
1. Novelty. We get bored easily at our jobs, and Lisp is different (but not Haskell different), so we're naturally pulled towards learning about it.
2. Nostalgia. A lot of people here have enjoyed Lisps for years or even decades (myself included) and we have a natural bias towards preferring Lisp-based blogs or articles or projects, partly in the hopes that something is new in the land of Lisp (it never is).
3. Chain effect. When one topic comes up that's very interesting, people often want to know more about that topic or similar topics. People who want more points are eager to submit related links.
4. Propaganda. Some people have bought into a certain Lisp full-scale, and really want to help spread it in the industry. There's even a full-time job title for this called "evangelist".
2. Nostalgia. A lot of people here have enjoyed Lisps for years or even decades (myself included) and we have a natural bias towards preferring Lisp-based blogs or articles or projects, partly in the hopes that something is new in the land of Lisp (it never is).
3. Chain effect. When one topic comes up that's very interesting, people often want to know more about that topic or similar topics. People who want more points are eager to submit related links.
4. Propaganda. Some people have bought into a certain Lisp full-scale, and really want to help spread it in the industry. There's even a full-time job title for this called "evangelist".
I'm not a Lisp programmer, and I probably never will be, but I respect the language and here's why:
As Alan Kay said, Lisp is the "Maxwell’s equations of software" https://queue.acm.org/detail.cfm?id=1039523
> These were “Maxwell’s Equations of Software!” This is the whole world of programming in a few lines that I can put my hand over.
It's elegant.
As Alan Kay said, Lisp is the "Maxwell’s equations of software" https://queue.acm.org/detail.cfm?id=1039523
> These were “Maxwell’s Equations of Software!” This is the whole world of programming in a few lines that I can put my hand over.
It's elegant.
Didn't he say that of the code for a particular Lisp interpreter/REPL?
I think it was page 13: http://www.softwarepreservation.org/projects/LISP/book/LISP%...
I personally am not a big lisper, but know others who are. It's not as cool among young people, but there's a certain segment of those, mostly over 50, who will swear by lisp and build some pretty cool things in it.
1. It's got a minimal core and is easy to implement. This means it runs in many places.
2. Very, very easy to extend due to its treating code as data. You can assemble your own language on top of the base you're given with macros. This is why it's often recommended for building your first compiler. By the time you've written a lisp program, you're basically writing in a different dialect.
I think some people also use it for a challenge, or to make themselves think. It's very different from your normal C programming, or OO, or even other functional languages (even though it influenced many of them). There's a certain family of languages such as lisp, scheme, ocaml, ml, etc. which seem to appeal to those with a more academic bent and so some interesting stuff can be written in them.
1. It's got a minimal core and is easy to implement. This means it runs in many places.
2. Very, very easy to extend due to its treating code as data. You can assemble your own language on top of the base you're given with macros. This is why it's often recommended for building your first compiler. By the time you've written a lisp program, you're basically writing in a different dialect.
I think some people also use it for a challenge, or to make themselves think. It's very different from your normal C programming, or OO, or even other functional languages (even though it influenced many of them). There's a certain family of languages such as lisp, scheme, ocaml, ml, etc. which seem to appeal to those with a more academic bent and so some interesting stuff can be written in them.
Lisp is the red pill to programming. A mind-blowing out-of-the-box experience. An alien technology. -- Lisp has a so called "no turning back point", true lispers cannot bear other dialects after experiencing it. From scientists in underground military bases to rich tech VCs: everyone obeys Lisp here..
Loved your "red pill" analogy.
Although I don't use Lisp in my daily programming, I do tinker with it when exploring new concepts. Basically I find that any abstraction can be quickly, not necessarily efficiently, implemented using Lisp. The absence of syntactic and even semantic constraints allows novel ideas to be tested which would be too awkward in more "conventional" languages.
As it has been said, many advanced systems contain an incomplete, faulty implementation of Lisp. So cutting to the chase, simply use your favourite Lisp system and hack away.
Although I don't use Lisp in my daily programming, I do tinker with it when exploring new concepts. Basically I find that any abstraction can be quickly, not necessarily efficiently, implemented using Lisp. The absence of syntactic and even semantic constraints allows novel ideas to be tested which would be too awkward in more "conventional" languages.
As it has been said, many advanced systems contain an incomplete, faulty implementation of Lisp. So cutting to the chase, simply use your favourite Lisp system and hack away.
https://youtu.be/HM1Zb3xmvMc is a song about Lisp
A song that's a bit gentler on the ears: https://www.youtube.com/watch?v=5-OjTPj7K54
>Lisp has a so called "no turning back point", true lispers cannot bear other dialects after experiencing it.
I can relate to that feeling.
I can relate to that feeling.
Ooh man this thread will be very interesting.
It would help to get a better idea of your current context with regards to programming. What’s your experience so far? That will help frame the discussion.
It would help to get a better idea of your current context with regards to programming. What’s your experience so far? That will help frame the discussion.
I'm a software engineer that mostly works on the front end of things, but from school and various jobs I have experience in:
C, C++, Python, C#, Java.
Mostly object oriented (distributed systems and game dev), and some embedded development.
Mostly object oriented (distributed systems and game dev), and some embedded development.
JavaScript is, probably somewhat surprisingly, a pretty LISP-y language, tho without the parentheses.
Lispy in the "processing lists" is easy and natural sense, but not in the more powerful "homoiconicity=code is data and data is code" sense.
When people say that, they mostly just mean that it has lexical closures, I think.
You're right about the 'homoiconicity' but there's more LISP-iness to JavaScript beyond just "processing lists" too.
For others curious about this possible connection, here's Douglas Crockford on the LISPiness of JavaScript.
The Little JavaScripter https://www.crockford.com/little.html
The Little JavaScripter https://www.crockford.com/little.html
Because as a language it has some nice properties that make it conceptually easy to do otherwise complex.
The sad truth is that beside that, it’s severely lacking in real-world-usable libraries, there are a number of implementations with none of them gaining a majority share if users and, last but not the least, a kind of distance from the operating system that make it non-obvious to reason about the usual stuff (“ports” instead fo file descriptors, vm memory dump to disk as a form of binary executable generation, etc etc).
So lisp has some cool things but will never likely become a mainstream language, hence the perpetual hype.
The sad truth is that beside that, it’s severely lacking in real-world-usable libraries, there are a number of implementations with none of them gaining a majority share if users and, last but not the least, a kind of distance from the operating system that make it non-obvious to reason about the usual stuff (“ports” instead fo file descriptors, vm memory dump to disk as a form of binary executable generation, etc etc).
So lisp has some cool things but will never likely become a mainstream language, hence the perpetual hype.
>there are a number of implementations with none of them gaining a majority share
SBCL has the majority share. But it doesn't matter, since ANSI Common Lisp is a standard and my code runs on many CL implementations with no changes.
>a kind of distance from the operating system
Citation needed. A bit puzzling to say that when some CL implementations have fantastically easy FFI features (CCL, ECL, CLISP).
>“ports” instead fo file descriptors
We don't have this. Streams are streams, like in any other typical language. File paths are represented by... Pathnames (data type).
>vm memory dump to disk as a form of binary executable generation
1. The dump is part of the generated executable
2. Now compare to most dynamically typed languages: they can't generate an executable nor compile to machine lang.
3. "Memory dump to disk as a form of binary executable" is only true of the Common Lisp implementations that are able to save the image. ECL, for example, doesn't do that. It compiles to C and C gets compiled to Exe.
4. Being able to save and restore images is one of the best features of CL (and Smalltalk as well)
>So lisp has some cool things but will never likely become a mainstream language
You need to review your history, since Lisp was a mainstream language in the past. To put an example, it was #3 in the TIOBE index for 1989, #5 for 1994.
SBCL has the majority share. But it doesn't matter, since ANSI Common Lisp is a standard and my code runs on many CL implementations with no changes.
>a kind of distance from the operating system
Citation needed. A bit puzzling to say that when some CL implementations have fantastically easy FFI features (CCL, ECL, CLISP).
>“ports” instead fo file descriptors
We don't have this. Streams are streams, like in any other typical language. File paths are represented by... Pathnames (data type).
>vm memory dump to disk as a form of binary executable generation
1. The dump is part of the generated executable
2. Now compare to most dynamically typed languages: they can't generate an executable nor compile to machine lang.
3. "Memory dump to disk as a form of binary executable" is only true of the Common Lisp implementations that are able to save the image. ECL, for example, doesn't do that. It compiles to C and C gets compiled to Exe.
4. Being able to save and restore images is one of the best features of CL (and Smalltalk as well)
>So lisp has some cool things but will never likely become a mainstream language
You need to review your history, since Lisp was a mainstream language in the past. To put an example, it was #3 in the TIOBE index for 1989, #5 for 1994.
Do you mean majority share between CL implementations or Lisp like languages?
If the former, I don't have the exact numbers but SBCL is practically the de facto standard with about ~80% of library pulls from QuickLisp.
If the former, I don't have the exact numbers but SBCL is practically the de facto standard with about ~80% of library pulls from QuickLisp.
Here's some previous discussion: https://news.ycombinator.com/item?id=2839742
Very simple answer: Nobody is obsessed with Lisp, but Lisp is just better. And almost every "new" idea or feature was prototyped in Lisp already several years ago. Most languages haven't caught up to the most basic Lisp features yet. e.g dump the running state to disc (with all loaded shared libs, open files,...), and restart from there later.
What's so good about it? See the relevant Lisp FAQ's. E.g. https://lisp-lang.org/ It is compiled and memory safe. Dynamic but fast. Trivial to parse, code as data. Readable macros. Huge stdlib. The first ANSI standardized language.
What's so good about it? See the relevant Lisp FAQ's. E.g. https://lisp-lang.org/ It is compiled and memory safe. Dynamic but fast. Trivial to parse, code as data. Readable macros. Huge stdlib. The first ANSI standardized language.
> The first ANSI standardized language.
Not quite; the "ANSI first" in relation to Lisp is supposedly that CLOS is the first ANSI standard object system, which makes Common Lisp the first ANSI standard OOP language.
Of course there were plenty of ANSI languages before 1994!
Not quite; the "ANSI first" in relation to Lisp is supposedly that CLOS is the first ANSI standard object system, which makes Common Lisp the first ANSI standard OOP language.
Of course there were plenty of ANSI languages before 1994!
You are right.
Cobol 1974, Pascal 1983, C 1990, Fortran 1992, ...
Lisp is the light saber of languages : an elegant weapon for a more (mumble) age. Blasters and death stars are more effective.
Nobody builds anything important with it, but it feels more pure to build toys with it than more practical languages. Some people make big toys.
Nobody is expected to understand anybody else's code, so you can indulge any kind of whim, and it is easy to make any whim work well enough. Meanwhile, the mathematical bedrock of computation outcrops more frequently, so that programs can resemble theorems if you like that.
Nobody builds anything important with it, but it feels more pure to build toys with it than more practical languages. Some people make big toys.
Nobody is expected to understand anybody else's code, so you can indulge any kind of whim, and it is easy to make any whim work well enough. Meanwhile, the mathematical bedrock of computation outcrops more frequently, so that programs can resemble theorems if you like that.
"Nobody builds anything important with it, but it feels more pure to build toys with it than more practical languages."
The company I just joined has 99% of their software written in Clojure. Backend is Clojure, front end is ClojureScript. Their software is kind of important to running day to day operations.“Nobody” is a bit extreme, don't you think? There are a lot of people building things with Lisp and you're dismissing their work out of hand.
Just one example of a powerful software product written in Lisp: http://maxima.sourceforge.net/
(my contribution to this work is a graphical frontend, also written in Lisp: https://flathub.org/apps/details/com.dhsdevelopments.Climaxi...)
Just one example of a powerful software product written in Lisp: http://maxima.sourceforge.net/
(my contribution to this work is a graphical frontend, also written in Lisp: https://flathub.org/apps/details/com.dhsdevelopments.Climaxi...)
"Nobody" in the sense that no numbers are rational. You can name lots of them, many of them your best friends, but the probability that a number chosen at random, in any interval, is rational is exactly zero.
> Lisp is a programmable programming language.
— John Foderaro, CACM, September 1991
Often times programming languages are designed with a particular use case in mind. (E.g. JS: web, Perl: scripting, Erlang: telephony, etc.) LISP was made to think about computation, and it acts well as a programming language work with programming.
One of the goals of Racket (a dialect of LISP) is to make it easy to create your own languages.
> Racket is the second best programming language in the world—the first best one is the one you build in Racket.
Often times programming languages are designed with a particular use case in mind. (E.g. JS: web, Perl: scripting, Erlang: telephony, etc.) LISP was made to think about computation, and it acts well as a programming language work with programming.
One of the goals of Racket (a dialect of LISP) is to make it easy to create your own languages.
> Racket is the second best programming language in the world—the first best one is the one you build in Racket.
Try writing some larger programs in a modern Lisp.
Lisp causes you to think in different ways. It allows for metaprogramming in ways other languages don't allow. It is endlessly reconfigurable.
Lisp causes you to think in different ways. It allows for metaprogramming in ways other languages don't allow. It is endlessly reconfigurable.
> modern Lisp.
I've never heard this before. Modern C++ sure, but I thought most of the "modernization" in lisp was done in descendant languages (i.e. racket).
I've never heard this before. Modern C++ sure, but I thought most of the "modernization" in lisp was done in descendant languages (i.e. racket).
> I thought most of the "modernization" in lisp was done in descendant languages
One core feature of any Lisp dialect is that you can extend the language using Lisp.
Thus, you don't need to "change" the language spec or write a new compiler to extend (and thus modernize) the language.
One core feature of any Lisp dialect is that you can extend the language using Lisp.
Thus, you don't need to "change" the language spec or write a new compiler to extend (and thus modernize) the language.
I'm not sure there's anything now that 'LISP' could refer to beyond the family of languages, of which Clojure, Common Lisp, and even Scheme are all 'modern' dialects.
Because we are computer scientists, and Lisp allows for the specification of abstract concepts directly and efficiently without syntax getting in the way.
See also: Forth.
See also: Forth.
someone has to have some sense of taste, rather than be fashionistas.
e.g. I see more than 2-3 posts a day about non-lisps. What's so good about those?
e.g. I see more than 2-3 posts a day about non-lisps. What's so good about those?
Lisp is a really marvelous way to code. It's the hacker's language - a language you can hack around with by using macros to define your own DSLs, structures and ideas. It takes some getting your head around but the basic core of it is quite simple (compare to Haskell that has so many ideas you need to learn).
For context, I'm a C++ and Python developer in my day job. I've been writing code for about 20 years and create a lot of small projects based on my interests (simple games, 2d/3d graphics, automation, web services, algorithm exploration, etc.). In the past I would use C++, Python, Ada, Haskell, and Ruby for those projects, as well as briefly looking at OCaml, Prolog, Mercury, Dylan, Nim, and some others.
For the past few years I've been using Common Lisp (almost) exclusively for these projects, and even some scripting at work. I have a couple projects in QuickLisp (a latitude/longitude <-> UTM converter and an STL file reader), I help maintain st-json (though I've only merged one changeset ;-), and I've written bindings to Blend2D and ZBar (both on GitHub but not in QuickLisp yet).
For me, Lisp hits a sweet spot between high level features, performance, and interactive development that I haven't found in any other language.
Here are some things I like about it:
* Interactive development
The Common Lisp mode for Emacs is fantastic. There's a REPL in the editor and it's super easy to send code back and forth. It's very convenient to play with a function as you're writing it - it's like an interactive unit test. When the function's working, the test code can be copy/pasted from the REPL into the unit tests.
Code navigation is also great. Alt-. will jump to the source code for the function under the cursor, and since SBCL and all of the libraries I use are open source, it works for everything, even things that would be language keywords in other languages.
Other languges have REPLs, but Lisp emphasizes it much more than the others. Haskell and Python have REPLs (ghci and Idle) but it's rare for software written in them to include a REPL, shipping Lisp software will often have a REPL available - I can connect to the StumpWM REPL, for example.
* The syntax
Some people get hung up on the parenthesis, but I like them. The syntax is consistent, it's easy to indent, it's easy to navigate in the editor, and there aren't punctuation marks all over the place.
* High level with good cross-platform performance
I'm too lazy to post evidence right now, but IME unoptimized Common Lisp is 15-20x faster than Python using the same algorithm, and maybe 1/2 - 1/10 the speed of C or C++.
With simple optimizations (adding type/function type declarations, etc.) the Lisp code can be 30-50x faster than Python, and near the speed of C++. Usually the optimized Lisp is almost exactly the same as the slower code, but has a few type declarations and (declare (optimize (speed 3))) added in.
* Libraries and Community
The CL community is pretty small, and most libraries are created by people scratching their own itch. They're not always perfect, but they'll usually get the job done. If not, most maintainers are happy to get pull requests. I personally like that, but it may not work for people who want "off the shelf", supported libraries that work in every situation.
I've found the community generally helpful and easy to work with. Getting libraries added to QuickLisp is quick and easy.
Interfacing with C code is really easy. For small libraries or a function or two using CFFI is dead simple. For larger projects cl-autowrap can wrap whole libraries easily - it uses llvm and clang to autogenerate the entire binding.
* Lots of books and references available
Lots of smart people (Guy Steele, Paul Graham, Peter Norvig, etc.) have used and written about Lisp, and there are some really unique and interesting books about it. "The Art of the Metaobject Protocol" and "Let Over Lambda" are two examples that really ighlight what makes Lisp unique.
For the past few years I've been using Common Lisp (almost) exclusively for these projects, and even some scripting at work. I have a couple projects in QuickLisp (a latitude/longitude <-> UTM converter and an STL file reader), I help maintain st-json (though I've only merged one changeset ;-), and I've written bindings to Blend2D and ZBar (both on GitHub but not in QuickLisp yet).
For me, Lisp hits a sweet spot between high level features, performance, and interactive development that I haven't found in any other language.
Here are some things I like about it:
* Interactive development
The Common Lisp mode for Emacs is fantastic. There's a REPL in the editor and it's super easy to send code back and forth. It's very convenient to play with a function as you're writing it - it's like an interactive unit test. When the function's working, the test code can be copy/pasted from the REPL into the unit tests.
Code navigation is also great. Alt-. will jump to the source code for the function under the cursor, and since SBCL and all of the libraries I use are open source, it works for everything, even things that would be language keywords in other languages.
Other languges have REPLs, but Lisp emphasizes it much more than the others. Haskell and Python have REPLs (ghci and Idle) but it's rare for software written in them to include a REPL, shipping Lisp software will often have a REPL available - I can connect to the StumpWM REPL, for example.
* The syntax
Some people get hung up on the parenthesis, but I like them. The syntax is consistent, it's easy to indent, it's easy to navigate in the editor, and there aren't punctuation marks all over the place.
* High level with good cross-platform performance
I'm too lazy to post evidence right now, but IME unoptimized Common Lisp is 15-20x faster than Python using the same algorithm, and maybe 1/2 - 1/10 the speed of C or C++.
With simple optimizations (adding type/function type declarations, etc.) the Lisp code can be 30-50x faster than Python, and near the speed of C++. Usually the optimized Lisp is almost exactly the same as the slower code, but has a few type declarations and (declare (optimize (speed 3))) added in.
* Libraries and Community
The CL community is pretty small, and most libraries are created by people scratching their own itch. They're not always perfect, but they'll usually get the job done. If not, most maintainers are happy to get pull requests. I personally like that, but it may not work for people who want "off the shelf", supported libraries that work in every situation.
I've found the community generally helpful and easy to work with. Getting libraries added to QuickLisp is quick and easy.
Interfacing with C code is really easy. For small libraries or a function or two using CFFI is dead simple. For larger projects cl-autowrap can wrap whole libraries easily - it uses llvm and clang to autogenerate the entire binding.
* Lots of books and references available
Lots of smart people (Guy Steele, Paul Graham, Peter Norvig, etc.) have used and written about Lisp, and there are some really unique and interesting books about it. "The Art of the Metaobject Protocol" and "Let Over Lambda" are two examples that really ighlight what makes Lisp unique.
Because LISP (in general, in fact every dialect has its own flaws and candies and there still is space for improvement) is an almost-perfect language. It has just one flaw - it's unreadable without rainbow parentheses.
- you can make your own domain specific language in Lisp (e.g. imagine that you want to create a custom 'for' statement, or some kind of a new pattern matching operator)
- you can easily write programs that edit themselves
- you can easily write programs that edit themselves
I see both of those things a lot. The problem is if you aren't already familiar with those idea, the statements mean literally nothing. They basically don't make sense.
These examples aren't so far out there. DSLs exist in other languages. Statements exist in other languages. A programmer who has never used macros can imagine being able to create these, even if they have no idea what exactly that would look like in a Lisp program.
That issue is also true of any game-changing technology you haven't used yet. If you hadn't used a personal computer, we could enumerate the features and advantages, but you probably wouldn't be able to truly appreciate it until you used one yourself.
That issue is also true of any game-changing technology you haven't used yet. If you hadn't used a personal computer, we could enumerate the features and advantages, but you probably wouldn't be able to truly appreciate it until you used one yourself.
They're also rarely useful things to do in regular software development.
I wonder if we struggle needlessly though in "regular software development" - and entire jobs or teams exist because we didn't find the right way to express things in a language. OTOH you could create lisp code that is so unique and weird in it's semantics that it's hard for a new team member to get onboard. But I've seen that done in C# too which allows you to have code that writes code at runtime (not as elegantly though!).
Yeah, writing your own language and self-modifying code can give you a lot of leverage, but usually they also make the code so much harder for other people to pick up that it's not worth it.
The idea is that all LISP code is data that is easily altered, essentially https://en.wikipedia.org/wiki/Abstract_syntax_tree encapsulated in parens.
LISP syntax is uniform,everything(functions,data,argument lists) is nested lists of lists like (list(list(list))), so that allows altering specific places "in-the-list"(place 1,2,3...) as form of meta-programming,
where normal syntax FOR( A IN B) would be written roughly as (for a b) where for is used as a function taking 'a' and 'b' as parameters, but in this form(where 'for' is just the first element of the list) you can have functions that "alter-the-list" by example (replace-first-list-element (for a b) replacement-part) returns (replacement-part a b).
LISP syntax is uniform,everything(functions,data,argument lists) is nested lists of lists like (list(list(list))), so that allows altering specific places "in-the-list"(place 1,2,3...) as form of meta-programming,
where normal syntax FOR( A IN B) would be written roughly as (for a b) where for is used as a function taking 'a' and 'b' as parameters, but in this form(where 'for' is just the first element of the list) you can have functions that "alter-the-list" by example (replace-first-list-element (for a b) replacement-part) returns (replacement-part a b).
What is the second bullet point referring to?
Lisp syntax in a nutshell is:
On top of that everything is a function, including if statements, assignment, and even how you define a new function. So factorial in lisp is:
"(" {function} [" " {argument}...] ")"
"'(" [{item} [" " {item}...]] ")"
On top of that everything is a function, including if statements, assignment, and even how you define a new function. So factorial in lisp is:
(defun factorial (x)
(if (<= x 0)
1
(* x (factorial (- x 1)))
) )
Second point sounds like a nightmare
> you can easily write programs that edit themselves
Hah! I can do that too:
Hah! I can do that too:
#!/usr/bin/env python3
#
# script.py
# Copyright 2019 pgcj_poster
print('Hello World')
with open('script.py', 'w') as f:
f.write(f.read().replace('Hello World', 'Goodbye World'))
You should use '__file__' for increased generality.
Note that you can also import a module and refer to its location on disk as 'module.__file__'. I may or may not have used this to modify a few core python modules in place.
Note that you can also import a module and refer to its location on disk as 'module.__file__'. I may or may not have used this to modify a few core python modules in place.
Have you tried it, just a beginner tutorial or something? But if you do, please use an editor that puts paired parens in for you automatically, otherwise there's a risk of thinking that it is painful.
I tried it years ago, but I think I had too little experience to understand the use case back then. I hadn't ever done any functional programming at that point so it kind of went over my head.
I still hate Haskell. But maybe I would like Lisp? A lot of people here seem to love it so that's why I made this thread :)
I still hate Haskell. But maybe I would like Lisp? A lot of people here seem to love it so that's why I made this thread :)
OK I'll have a go, but others will be able to do a better job than me!
Yes, you might like lisp and I definitely think it's worth trying. You often hear people saying "lisp has no syntax" and that's one of the main things about lisp. I think a good first step is to understand what people mean by that. You know the way a compiler or interpreter, after tokenizing and parsing, transforms code into an intermediate data structure representation called an "abstract syntax tree"? What they mean is that lisp is like jumping straight in at the AST stage. You're literally programming with data structures, instead of programming with syntax that gets turned into data structures. People find that a very rewarding intellectual/mental experience. It really teaches you that the words "statement" and "expression" mean different things. And it shows you a way of programming without a lot of "state" -- just expressions feeding into other expressions, without as much use of "local variables". More deeply, this is directly connected with formal ideas in mid-20th century theoretical computer science (in particular the "lambda calculus") about the minimal programming constructs needed to create a Turing complete language. In lisp it leads also to very powerful and somewhat mind-bending "macros" -- since code is data structure, you can very naturally write code to transform code, so the "final" code that is executed is partially the product of an initial execution phase where code is just working on code creating other code.
Having no syntax (or minimal, languages like clojure introduce a bit with square and smooth parens etc) means you basically just write expressions grouped by smooth parens. It's very beautiful and minimal experience to write. Just, seriously, do it with an editor/IDE that inserts paired parens for you, it promises to be a great experience with that, but without it a lot of people just give up saying why do they have to keep writing so many parens, which is missing the point entirely -- The parens are the fabric of the program!
Yes, you might like lisp and I definitely think it's worth trying. You often hear people saying "lisp has no syntax" and that's one of the main things about lisp. I think a good first step is to understand what people mean by that. You know the way a compiler or interpreter, after tokenizing and parsing, transforms code into an intermediate data structure representation called an "abstract syntax tree"? What they mean is that lisp is like jumping straight in at the AST stage. You're literally programming with data structures, instead of programming with syntax that gets turned into data structures. People find that a very rewarding intellectual/mental experience. It really teaches you that the words "statement" and "expression" mean different things. And it shows you a way of programming without a lot of "state" -- just expressions feeding into other expressions, without as much use of "local variables". More deeply, this is directly connected with formal ideas in mid-20th century theoretical computer science (in particular the "lambda calculus") about the minimal programming constructs needed to create a Turing complete language. In lisp it leads also to very powerful and somewhat mind-bending "macros" -- since code is data structure, you can very naturally write code to transform code, so the "final" code that is executed is partially the product of an initial execution phase where code is just working on code creating other code.
Having no syntax (or minimal, languages like clojure introduce a bit with square and smooth parens etc) means you basically just write expressions grouped by smooth parens. It's very beautiful and minimal experience to write. Just, seriously, do it with an editor/IDE that inserts paired parens for you, it promises to be a great experience with that, but without it a lot of people just give up saying why do they have to keep writing so many parens, which is missing the point entirely -- The parens are the fabric of the program!
Check out https://xkcd.com/224/ . Many of us Lispers go through this phase where the universe appears to crystallize around Lisp concepts. Like Forth or APL and other languages built around a unifying theory there is a conceptual elegance which is mind-opening. Eventually most of us come back down to Earth but it is a fun ride.
There is also a mystique around the powers of Lisp. I do believe it is a massively expressive and powerful language in the hands of a master. But part of it is historical. During the heyday of Lisp it was the language of choice for the best hackers in the land and certainly was vastly more powerful for individuals/small groups than the existing alternatives. Today that talent base is just spread across so many other choices.
There is also a mystique around the powers of Lisp. I do believe it is a massively expressive and powerful language in the hands of a master. But part of it is historical. During the heyday of Lisp it was the language of choice for the best hackers in the land and certainly was vastly more powerful for individuals/small groups than the existing alternatives. Today that talent base is just spread across so many other choices.
Obsessed in bashing it? ;)
Really though, the majority of comments I have seen in every Lisp thread is about Lisp not giving you any advantages over the mainstream languages for "real world business apps", a common example mentioned is reddit switching to Python from Lisp. Also that stuff like the language ecosystem is more important.
Really though, the majority of comments I have seen in every Lisp thread is about Lisp not giving you any advantages over the mainstream languages for "real world business apps", a common example mentioned is reddit switching to Python from Lisp. Also that stuff like the language ecosystem is more important.
Well we software developers have the right of a culture of our own, just like plane pilots like to talk endlessly about old war birds, and fly gliders.
For me, Lisp is akin to a Concorde or a P-51, it is not the aircraft of choice today but helped to shape everything that came next.
For me, Lisp is akin to a Concorde or a P-51, it is not the aircraft of choice today but helped to shape everything that came next.
HN should start supporting TeX so people can argue in math instead.
Wait, no one's mentioned the automatic garbage collecting?
(L)ets (I)nsert (S)ome (P)arantheses :-)
I like LISP since it was an eye-opener for me long ago, showing the essence of computer sciences (i.e. tail recursion, functional programming, immutable data structures, terseness vs. understandability).
I like LISP since it was an eye-opener for me long ago, showing the essence of computer sciences (i.e. tail recursion, functional programming, immutable data structures, terseness vs. understandability).
Most of the data structures in ANSI Lisp are mutable, as are variable bindings and global function bindings. Support for tail recursion is a quality-of-implementation issue. There is excellent support for procedural programming: the language constructs are strictly evaluated and many key language constructs evaluate a body of zero or more forms (called an "implicit progn"), all but the last of which have to have side-effects for that to make sense. There are constructs for iteration over a single instance of the loop variables, and control transfer features: a form of goto within a labeled block called a tagbody, as well as dynamic non-local control transfers that support the condition handling system. Functional programming is possible by confining to a very small language subset (sometimes called "Pure Lisp").
I don’t know if anybody is obsessed with Lisp though.
I am
Obsessed? Or you just like it. I think obsession is a bit too strong in this context. I also pretty much like Lisp even though I cannot use it day to day because everybody else works in Java, Python, Go and most developers do not consider any of the Lisp languages production ready.
It's a great excuse to claim a label of 'programming genius' without having to explain why you haven't written anything useful or groundbreaking.