4 ms·

These are terrible answers to the question "Why Lisp?" (to which the most obvious answer would be "For what?"). 1) Good ideas? Yes, it did, but many modern lan

by hvs 14y ago

These are terrible answers to the question "Why Lisp?" (to which the most obvious answer would be "For what?"). 1) Good ideas? Yes, it did, but many modern languages implement them so it is no longer a reason to use Lisp. Macros? There are numerous arguments on both sides about whether those are good or bad. Needless to say, not enough to justify using Lisp. 2) Your "extension to the language" is my "wtf is this developer doing here?" Consistent syntax is part of what makes a language intelligible to many different people. I don't want to be a human parser to understand code. 3) Thrust/weight... ?. OK, I think your point is that there is little syntax to understand. Unfortunately, that means that context needs to be parsed by the developer because there are few "road signs" that tell me what is going on without reading the whole chunk of code in detail. Finally, I'm not sure what this is in response to (other than it being the eternal question that burns in the hearts of all men) but if it is an argument for using Lisp on a project, it would be better directed at what Lisp has that makes it good for production work in a modern environment. However, in that way, I don't think it is much better than many of the other languages today.

rayiner 14y ago
Re: "for what" I would say that the best answer would be: for rapid development of technically complex programs with small, highly-skilled teams. Re: 1) Many modern languages do implement some Lisp features, but none do so as well as Lisp. I have yet to see a language that mixes functional programming, an elegant and intuitive standard library, meta-programming, and high performance native code incremental compilation in one development environment. E.g. Javascript is full of bizarre quirks and bad semantics, and its REPLs aren't up to snuff yet, even though it has native-code compilers that are up to snuff. Nothing does meta-programming as well as Lisp. LINQ, Caml4p, etc, are ugly hacks compared to Lisp macros which are baked into the compilation pipeline by design. Re: 2) I think you are mistaken in assuming that programmers using other languages don't extend the language. They do, they just do it with external, ad-hoc tools. A great example is LLVM's tblgen utility, which generates native assembler backends from table descriptions. It has its own grammar, own parser, own set of bugs. You can do this stuff in Lisp within the language. When I was still learning the language, I put together a table-driven assembler for x86-64 in about two weeks (http://code.google.com/p/amd64-asm/source/browse/#svn%2Ftrunk http://code.google.com/p/amd64-asm/source/browse/#svn%2Ftrun...). It uses macros to take instruction descriptions and generate encoding functions which are then compiled to native code by the Lisp compiler. It's simple, it uses the parser built into the language, you can't ever forget to run the external tool, and it's totally integrated into the development environment. One hotkey sequence expands the macro and shows you the result right in your editor. An error in a macro is debuggable with the integrated debugger just like any other code (compare to C++ templates, which are basically impossible to debug except through trial and error). Literally no other metaprogramming feature comes close to Emacs+SLIME+SBCL. Re: 3) Lisp doesn't have "less context." It just uses words for context rather than syntax. In C, you see curly braces and you know you have a block. In Lisp, you see the word "progn" and you know you have a block. Lisp is, to a degree, a language for people who think verbally rather than symbolically. The signals are all there--it's just that the signals are words. Lisp is the only language I've ever used (to be fair, I haven't really used Haskell) where I don't feel like the language/development environment is the bottleneck. It's the only one where I don't lose my train of thought trying to remember to remember the idiosyncratic way someone ordered the parameters to an API call, or because I'm stuck writing a few dozen lines of boiler-plate. It and Python are the only language I've used where API's have sensible defaults (Java is absolutely terrible for this) and I'd dare call the standard library "tastefully designed."
- joe_the_user 14y ago
  I'm interested in Lisp but haven't done much. an elegant and intuitive standard library Now that actually seems like one of the points of hesitation. Lisp is actually notorious for not having a lot of accessible libraries, to paraphrase "The Bipolar Lisp Programmer". http://www.lambdassociates.org/blog/bipolar.htm http://www.lambdassociates.org/blog/bipolar.htm I mean, Lisp may have managed to get a bare standard library after many, many years but the odds of you finding X algorithm implemented in Lisp on the web is, in my experience, low compared to c++, java or python. Lisp sounds like perhaps the strongest possible tool to "hack your way through the wildness". One can do amazing things "right out of the box" (as your example show). Unfortunately, it also seems like it winds up mostly being only that, rather than being a tool for building large systems interfacing with many people and other systems (that might not be a bad thing but its worth mentioning if you mention libraries).
  - betterunix 14y ago
    I assume you are talking about Common Lisp; Clojure clearly does not suffer any issues with library availability, since it can utilize and interact with any Java class. That being said, most of the CL implementations I know of have some sort of FFI that can be used to invoke functions written in at least one other language. Finding a C implementation or library is not so hard for most things; using the FFI is a bit painful sometimes, although grovelling tools can help. Also, where it counts, there certainly are Common Lisp libraries -- XML, SQL databases, GUI, distributed/parallel programming, various mathematics, etc. all come to mind.
  - Derbasti 14y ago
    Are you maybe using 'standard library' and 'available libraries' interchangeably? Ruby and Java and C-iods for example have very limited standard libraries, but their respective ecosystems provide a great number of additional libraries. Python is the odd one because it basically comes with loads of additional libraries preinstalled. Lua on the other hand has a tiny standard library and a relatively small number of available libraries for it. I would say that CLs or Schemes standard libraries are actually quite comprehensive, but they don't have that many available libraries.
deleted 14y ago
[deleted]
betterunix 14y ago
I don't think writing extensions to the language is necessarily bad, nor is that necessarily limited to a single developer goofing around with the code. Let's put it this way: if your program needs to do a bit of linear algebra, would you rather have an embedded language for that, or have a bunch of classes and functions flying around that perform those operations? There is a certain threshold beyond which an extension to the language makes code more maintainable, not less, even when a new member is added to the team.
- rayiner 14y ago
  I think the problem is that people assume that extending the language means that everyone writes their own "for loop." Lisp programmers generally have enough taste not to do that, and if they do it's something more like writing the "iterate" package, which you can control with team policy. Generally, though, where macros come in is in defining things that would otherwise involve a lot of boiler plate code. E.g. SBCL uses a DSL built on macros to make it easier to write reuasble backends.
chimeracoder 14y ago
> Macros? There are numerous arguments on both sides about whether those are good or bad. Every argument I've ever heard about macros falls into one of two categories: 1. Concerns about overuse, which says nothing about correctly used macros - any tool can be overused or used incorrectly. 2. Complaints about macro systems from heteroiconic languages like C++ - these two concepts are similar in name only. Lisp macros have nothing to do with macros in any other language, and they provide freedom that is literally unavailable in any other[1], as explained well in this description: http://lists.warhead.org.uk/pipermail/iwe/2005-July/000130.html http://lists.warhead.org.uk/pipermail/iwe/2005-July/000130.h... [1] Yes, yes, Turing-completeness, so nothing is stopping you from writing your own parser from scratch. But the whole point is that Lisp doesn't require you to go through all of that - and secondarily, even if you did, parsing sexprs is so easy, you've finished before you've even started.
- randomchars 14y ago
  Thank you for that link. This is the first explanation of macros I've seen that actually shows some use cases.
- kenko 14y ago
  "they provide freedom that is literally unavailable in any other" There have been lots of arguments on LtU about this. You can go very, very far with either laziness or lightweight closures. Laziness didn't go all the way with Haskell, whence Template Haskell; I don't know enough about Smalltalk to know if they've managed to get by with extremely (syntactically) lightweight closures.
- hvs 14y ago
  1. True. My concern after years of development both in and out of corporate environments is that any tool available will be misused if given the chance. The goal is to minimize the damage as much as possible. If I could be surrounded by the cream of the crop at all times, that'd be great, but I'm not and most developers aren't. 2. I'm aware of this as well. I developed in Lisp for two years. Lisp macros are not comparable to C macros. I also didn't say they were all bad, just that there are arguments to be had about their utility. For example, OOP in Lisp has been described many times as a "leaky abstraction". In my opinion, it just plain sucks. It gets the job done, but I always feel dirty afterwards. It shows the power of macros and Lisp, but it also shows the limitations of not changing your language to support a little syntactic sugar. BTW, I know it's not apparent from my post, but I actually like Lisp, I just don't think it is the answer to any question that is being posed right now.

by hvs 14y ago

rayiner 14y ago

Re: "for what" I would say that the best answer would be: for rapid development of technically complex programs with small, highly-skilled teams. Re: 1) Many modern languages do implement some Lisp features, but none do so as well as Lisp. I have yet to see a language that mixes functional programming, an elegant and intuitive standard library, meta-programming, and high performance native code incremental compilation in one development environment. E.g. Javascript is full of bizarre quirks and bad semantics, and its REPLs aren't up to snuff yet, even though it has native-code compilers that are up to snuff. Nothing does meta-programming as well as Lisp. LINQ, Caml4p, etc, are ugly hacks compared to Lisp macros which are baked into the compilation pipeline by design. Re: 2) I think you are mistaken in assuming that programmers using other languages don't extend the language. They do, they just do it with external, ad-hoc tools. A great example is LLVM's tblgen utility, which generates native assembler backends from table descriptions. It has its own grammar, own parser, own set of bugs. You can do this stuff in Lisp within the language. When I was still learning the language, I put together a table-driven assembler for x86-64 in about two weeks (http://code.google.com/p/amd64-asm/source/browse/#svn%2Ftrunk http://code.google.com/p/amd64-asm/source/browse/#svn%2Ftrun...). It uses macros to take instruction descriptions and generate encoding functions which are then compiled to native code by the Lisp compiler. It's simple, it uses the parser built into the language, you can't ever forget to run the external tool, and it's totally integrated into the development environment. One hotkey sequence expands the macro and shows you the result right in your editor. An error in a macro is debuggable with the integrated debugger just like any other code (compare to C++ templates, which are basically impossible to debug except through trial and error). Literally no other metaprogramming feature comes close to Emacs+SLIME+SBCL. Re: 3) Lisp doesn't have "less context." It just uses words for context rather than syntax. In C, you see curly braces and you know you have a block. In Lisp, you see the word "progn" and you know you have a block. Lisp is, to a degree, a language for people who think verbally rather than symbolically. The signals are all there--it's just that the signals are words. Lisp is the only language I've ever used (to be fair, I haven't really used Haskell) where I don't feel like the language/development environment is the bottleneck. It's the only one where I don't lose my train of thought trying to remember to remember the idiosyncratic way someone ordered the parameters to an API call, or because I'm stuck writing a few dozen lines of boiler-plate. It and Python are the only language I've used where API's have sensible defaults (Java is absolutely terrible for this) and I'd dare call the standard library "tastefully designed."

joe_the_user 14y ago
I'm interested in Lisp but haven't done much. an elegant and intuitive standard library Now that actually seems like one of the points of hesitation. Lisp is actually notorious for not having a lot of accessible libraries, to paraphrase "The Bipolar Lisp Programmer". http://www.lambdassociates.org/blog/bipolar.htm http://www.lambdassociates.org/blog/bipolar.htm I mean, Lisp may have managed to get a bare standard library after many, many years but the odds of you finding X algorithm implemented in Lisp on the web is, in my experience, low compared to c++, java or python. Lisp sounds like perhaps the strongest possible tool to "hack your way through the wildness". One can do amazing things "right out of the box" (as your example show). Unfortunately, it also seems like it winds up mostly being only that, rather than being a tool for building large systems interfacing with many people and other systems (that might not be a bad thing but its worth mentioning if you mention libraries).
- betterunix 14y ago
  I assume you are talking about Common Lisp; Clojure clearly does not suffer any issues with library availability, since it can utilize and interact with any Java class. That being said, most of the CL implementations I know of have some sort of FFI that can be used to invoke functions written in at least one other language. Finding a C implementation or library is not so hard for most things; using the FFI is a bit painful sometimes, although grovelling tools can help. Also, where it counts, there certainly are Common Lisp libraries -- XML, SQL databases, GUI, distributed/parallel programming, various mathematics, etc. all come to mind.
- Derbasti 14y ago
  Are you maybe using 'standard library' and 'available libraries' interchangeably? Ruby and Java and C-iods for example have very limited standard libraries, but their respective ecosystems provide a great number of additional libraries. Python is the odd one because it basically comes with loads of additional libraries preinstalled. Lua on the other hand has a tiny standard library and a relatively small number of available libraries for it. I would say that CLs or Schemes standard libraries are actually quite comprehensive, but they don't have that many available libraries.

deleted 14y ago

[deleted]

betterunix 14y ago

I don't think writing extensions to the language is necessarily bad, nor is that necessarily limited to a single developer goofing around with the code. Let's put it this way: if your program needs to do a bit of linear algebra, would you rather have an embedded language for that, or have a bunch of classes and functions flying around that perform those operations? There is a certain threshold beyond which an extension to the language makes code more maintainable, not less, even when a new member is added to the team.

rayiner 14y ago
I think the problem is that people assume that extending the language means that everyone writes their own "for loop." Lisp programmers generally have enough taste not to do that, and if they do it's something more like writing the "iterate" package, which you can control with team policy. Generally, though, where macros come in is in defining things that would otherwise involve a lot of boiler plate code. E.g. SBCL uses a DSL built on macros to make it easier to write reuasble backends.

chimeracoder 14y ago

> Macros? There are numerous arguments on both sides about whether those are good or bad. Every argument I've ever heard about macros falls into one of two categories: 1. Concerns about overuse, which says nothing about correctly used macros - any tool can be overused or used incorrectly. 2. Complaints about macro systems from heteroiconic languages like C++ - these two concepts are similar in name only. Lisp macros have nothing to do with macros in any other language, and they provide freedom that is literally unavailable in any other[1], as explained well in this description: http://lists.warhead.org.uk/pipermail/iwe/2005-July/000130.html http://lists.warhead.org.uk/pipermail/iwe/2005-July/000130.h... [1] Yes, yes, Turing-completeness, so nothing is stopping you from writing your own parser from scratch. But the whole point is that Lisp doesn't require you to go through all of that - and secondarily, even if you did, parsing sexprs is so easy, you've finished before you've even started.

randomchars 14y ago
Thank you for that link. This is the first explanation of macros I've seen that actually shows some use cases.
kenko 14y ago
"they provide freedom that is literally unavailable in any other" There have been lots of arguments on LtU about this. You can go very, very far with either laziness or lightweight closures. Laziness didn't go all the way with Haskell, whence Template Haskell; I don't know enough about Smalltalk to know if they've managed to get by with extremely (syntactically) lightweight closures.
hvs 14y ago
1. True. My concern after years of development both in and out of corporate environments is that any tool available will be misused if given the chance. The goal is to minimize the damage as much as possible. If I could be surrounded by the cream of the crop at all times, that'd be great, but I'm not and most developers aren't. 2. I'm aware of this as well. I developed in Lisp for two years. Lisp macros are not comparable to C macros. I also didn't say they were all bad, just that there are arguments to be had about their utility. For example, OOP in Lisp has been described many times as a "leaky abstraction". In my opinion, it just plain sucks. It gets the job done, but I always feel dirty afterwards. It shows the power of macros and Lisp, but it also shows the limitations of not changing your language to support a little syntactic sugar. BTW, I know it's not apparent from my post, but I actually like Lisp, I just don't think it is the answer to any question that is being posed right now.