The article seems like mostly about Common Lisp, but how many of the points are applicable to rest of Lisps? (Scheme, Emacs Lisp, Janet, etc)
Why Lisp?
21–30 of 339 posts
Re: Why Lisp?
#22[deleted]
Re: Why Lisp?
#23> When you have a running program you can compile functions, redefine classes, etc. all while the program is running. You are changing the internal state of the image. This can surely be convenient in certain cases, however most of the times I find myself playing around with unit tests rather than with a single running process. Unit tests are small and fast so I don't even notice any inconvenience with the traditiona…
>Unit tests are small and fast so I don't even notice any inconvenience with the traditional compilation approach.
Depends on the programming language, how much state they need to build up, and so on. And they're still slower than just running the actual live code anyway.
Re: Why Lisp?
#24> On the other hand, Lisp code written some 30 years ago will most of the time, without issue, work on a modern Common Lisp implementation. Yeah, just like Perl. Or Latin. No one uses them, these are dead languages that belong to a museum. It can be fun to study them and you definitely should if you want to be well-educated and know the history behind the modern world, but that's it.
Arm, AMD, and Intel are using a Common Lisp application called ACL2 to formally verify their main products. Google Flights' core is written in Common Lisp. It's far from dead.
If you can enumerate some projects using it, and even more so, if you need to, then it's much closer to dead than alive.
It's like saying "The Vatican still uses latin, it's not a completely dead language".
Re: Why Lisp?
#25Earlier quoted context omitted.
Arm, AMD, and Intel are using a Common Lisp application called ACL2 to formally verify their main products. Google Flights' core is written in Common Lisp. It's far from dead.
If you can enumerate some projects using it, and even more so, if you need to, then it's much closer to dead than alive. It's like saying "The Vatican still uses latin, it's not a completely dead language".
There are many many more users of CL, I just listed some household names. If you don't hear about some technology every day, it doesn't mean it has to be "dead", there are plenty of important and "alive" technologies that you are not aware of. You just can't win this argument, if you try to prove the opposite you automatically lose, that's rather unreasonable.
Re: Why Lisp?
#26Earlier quoted context omitted.
Macros are basically the reason that people like ruby on rails. Every tool has its place.
metaprogramming in ruby carries a runtime cost. lisp macros (and rust macros) compile and so can be run without drastically decreasing Perf
I don't disagree. The post I was replying to effectively said macros are too hard to use outside of small teams.
They did have a point- it's not the kind of tool that you reach for on a whim. However, they can be fantastically useful when planned and used with discipline.
Re: Why Lisp?
#27> When you have a running program you can compile functions, redefine classes, etc. all while the program is running. You are changing the internal state of the image. This can surely be convenient in certain cases, however most of the times I find myself playing around with unit tests rather than with a single running process. Unit tests are small and fast so I don't even notice any inconvenience with the traditiona…
One never notices the inconvenience of not having something one is unaware of.
This is the biggest challenge for answering “why Lisp?” It’s different enough from the programming that most people are used to that it rises to the level of a radical novelty, with all the explanatory difficulties that entails.
In fact, it’s a defining characteristic of the radical novelty that it can only be understood experientially. And even then experience is merely necessary, but certainly not sufficient.
Re: Why Lisp?
#28> When you have a running program you can compile functions, redefine classes, etc. all while the program is running. You are changing the internal state of the image. This can surely be convenient in certain cases, however most of the times I find myself playing around with unit tests rather than with a single running process. Unit tests are small and fast so I don't even notice any inconvenience with the traditiona…
I've definitely come around to unit tests, but I think that whether they're good in all circumstances is a matter of taste. Obviously you want to have good test coverage by the time the codebase is starting to solidify- I assume there are people that would argue against that but they would be wrong.
Writing tests at more intermediary stages is not as much a matter of best practice, but I see know the appeal. At some point I started writing one-off functions to rerun the same code over and over in the REPL- that's when I realized it was time to start writing tests even if the API wasn't finalized. But full TDD is a matter of taste. There are people that like to have a really good idea of what they're getting into, and it seems like TDD works well for them. I myself have trouble. When I try to write tests first, I wind up paralyzed by making decisions without knowing the costs and benefits. That's where the REPL comes in handy for me- figuring out what shape I want my data to be, double checking edge cases faster than I could reference the documentation, and playing with new building blocks.
Re: Why Lisp?
#29> On the other hand, Lisp code written some 30 years ago will most of the time, without issue, work on a modern Common Lisp implementation. Yeah, just like Perl. Or Latin. No one uses them, these are dead languages that belong to a museum. It can be fun to study them and you definitely should if you want to be well-educated and know the history behind the modern world, but that's it.
> Yeah, just like Perl. Or Latin. No one uses them, these are dead languages that belong to a museum.
The best analogy I have for Lisp is that it is the wheelbarrow of languages. It was invented long ago and is in no way obsolete. In many ways it achieved a level of mastery of it's use domain that makes it almost impossible to think of a substitute. When you need a wheelbarrow, a dump truck will not do, and neither will a bicycle or automobile. There is a reason for this rather famous quote: "Whoever does not understand LISP, is doomed to reinvent it."
Re: Why Lisp?
#30Earlier quoted context omitted.
If you can enumerate some projects using it, and even more so, if you need to, then it's much closer to dead than alive. It's like saying "The Vatican still uses latin, it's not a completely dead language".
There are many many more users of CL, I just listed some household names. If you don't hear about some technology every day, it doesn't mean it has to be "dead", there are plenty of important and "alive" technologies that you are not aware of. You just can't win this argument, if you try to prove the opposite you automatically lose, that's rather unreasonable.
>There are many many more users of CL, I just listed some household names.
I know. But it's still admitting defeat, as they're not as many as to make its liveliness self-evident, and make giving a list of projects using the language moot.
Nobody will ask for such proof from a language whose liveliness is not in dispute, one for which the see constant mentions on social media, jobs posted, major new projects being written in them, companies using them left and right, books a-plenty being written all the time about them, meeting people who use them is trivial, and so on...
>You just can't win this argument, if you try to prove the opposite you automatically lose, that's rather unreasonable.
This "inabillity to win" using such proof though, makes sense though if one understands "language X is dead" as not some kind of absolute statement that nobody uses it, but rather as it was meant: "it's not as lively as it was, nor it is particularly popular".
"But this company uses it somewhere" doesn't really answer it. Companies use all kinds of niche stuff here and there, on legacy projects, stuff they bought, or stuff done by some small team and used because "it works, so let's keep it", but that stuff remains niche. We can find companies using Eiffel, APL, and whatever too. Does mean they're not dead-dead either, doesn't mean there's much life in them.
If it was one of the handful of "Google sanctioned official langauges" for example that stuff is written is, that would be a good argument (even if that was still just an individual company).