4 ms·

I wonder what is the most widely used, popular program, that has been written in Lisp? Is it Emacs? Every time I sit down to try to learn Lisp, I end up wonde

I wonder what is the most widely used, popular program, that has been written in Lisp? Is it Emacs? Every time I sit down to try to learn Lisp, I end up wondering what the hell I'll use it for. Functional programming languages seem to have flipped a bit in my mind that predisposes me to be prejudiced against Lisp .. I find it very hard to do anything actually useful with it, whereas I can pick up c++ or Lua or Python and immediately get something running. I'm not saying this is Lisps' fault, but I've been programming for 30 years and have tried many times to become a Lisp programmer.. its just never been effective.

abrax3141 7y ago
Lisp is magic. You use it to conceptualize your problem. This is most naturally done by creating a DLS for it. That is, imagine that you had a programming language that was built exactly to do exactly what you want to do. You write that down just as you imagine you would like to see it. Then all you have to do is patch in the underlying machinery. Magic!
- fma 7y ago
  I took an AI class that used Lisp. Language processing, knowledge based questions... What you can do in a few lines of Lisp code... Holy crap.
  - pjc50 7y ago
    What can you do in a few lines of Lisp that can't be done similarly in Python or Javascript? You can do amazing things in short strings of Perl or APL/J, they just tend not to be readable.
    - jhbadger 7y ago
      Macros. You can actually add new syntax and paradigms to the language in Lisp. You can't do that in Python or Javascript. Yes, you might argue that "I don't need to change my language! It's fine the way it is". And it might be -- for now. But consider -- whatever you think about the merits of object-orientation, most languages like Javascript and Python had to be especially written to support it. Lisp could add object orientation to itself without creating a new language, a Lisp++, as it were. Lisp is future-proof the way other languages aren't.
      - zmmmmm 7y ago
        The question with that though is, is creating a unique DSL for every problem you solve actually a sustainable way to program? Once you do that, every single person who works on the code needs to understand all the implicit behavior of the DSL before they can use it. And any misunderstanding they have about it comes out as bugs. Yes, maybe OO had to be specifically added to Python, Java etc., but it's one OO that everyone uses, so when I encounter it in the wild I know exactly how it works.
    - flavio81 7y ago
      >What can you do in a few lines of Lisp that can't be done similarly in Python or Javascript? To pick just an example: Anybody can create a Brainfuck (programming language) interpreter in a few lines of Python or Js code. With Common Lisp you could create a Brainfuck compiler (that compiles down to native code and thus has native code speed) in the same amount of lines of code. Or maybe shorter. A different example: The circle-ellipse problem. It is solved easily in Common Lisp (few lines of code), because the CLOS OOP system is more powerful than the OOP systems in Java, C++, Python, Javascript and many other languages.
DonaldFisk 7y ago
That's just because you're used to writing code those languages, and if they work for you for the things you want to do, that's fine. What Lisp gives me that other high level languages don't is that it's interactive and has a built-in garbage collector (like Python but unlike C++), it has symbols with values and properties, it has closures, I don't need to write methods to read or print objects, and I can add to the language. If you don't need these, you probably don't need Lisp. I use C for low level stuff (like building a virtual machine for Lisp), and C++ for machine vision (and nothing else). Their compiled code might run faster than Lisp's but for most things Lisp's fast enough, and its faster development cycle makes it easier to find more efficient algorithms. I could, I suppose, do many of the things I currently do in other high level languages, but I don't have to. The only other high level language I do need - which gives me functionality Lisp doesn't - is Prolog, which I need to implement the type system of my visual programming language. I wrote the Prolog in Lisp and can run it on the Lisp REPL, so it's really just a Lisp library.
ben509 7y ago
Speaking to why a LISP newbie finds it tough to get things done... I think most people think in imperative terms. "I want to make a type. Now, given a thing of that type, change a thing here, change a thing here, and return the thing I want." And most languages delineate a programmer's tasks clearly. For instance, in Python and Ruby, logical structure is expressed in blocks, control (mostly) transfers between statements, while calculation is performed in expressions, and these are all visually distinct. LISP's idea that all structures can be expressed as lists doesn't visually demarcate the distinct "things" a programmer is trying to compose. You can absolutely learn it, but it makes it harder. Now, since LISP does basically use an AST directly, it makes metaprogramming trivial. The beauty of extensive metaprogramming is that you can construct new languages cheaply. The curse is that you get a lot of cheaply constructed new languages. If Python wants to add an "async" keyword, they go through weeks of debate and do a long writeup on it.[1] In LISP, someone writes a few macros and, boom, new syntax. The LISP community are smart people, they recognized this and I think the standardization efforts tried to mitigate it, and a ton of thought clearly went into Scheme. But even this article doesn't get the problem. It's not "there are too many parens" but more that everything in LISP looks the same when you're new, it's a jumble of parens. Your brain isn't getting distinct markers to help learn the structures. And LISP, shares a problem with most dynamic languages that anything can kind of go anywhere. It's not as bad for others, though, because if you look at an example of Python code, you can generally see the structure and that narrows down what can fit there. Whereas LISP is always a mess of parens and keywords; yes, it's usually obvious from looking at the docs, but it's just more research you have to do to get something done.
- flavio81 7y ago
  >But even this article doesn't get the problem. It's not "there are too many parens" but more that everything in LISP looks the same when you're new, it's a jumble of parens. Your brain isn't getting distinct markers to help learn the structures. On a typical language you have "structures" you mention, like "if", "for", "switch". Lisp also has them, but they look more like function calls. The syntax has a lot of less noise. Automatic indentation helps you visualize such "structures" in an easier way. It's not any more difficult than using a language like Python or C. >And LISP, shares a problem with most dynamic languages that anything can kind of go anywhere. Not really, because Common Lisp -the major Lisp dialect- is a strongly typed language, unlike the most popular dynamic languages: Javascript, PHP and Python and Ruby (Python & Ruby being 'duck typed' for the most part). And unlike the famous weakly-typed statically-typed language: C. So no, "anything" can't go anywhere, because a type mismatch will cause a runtime error. And in CL you can correct runtime errors by modifying the source code and resuming program execution (without having to restart the complete program), so no big deal either. The most common data construct, the Lisp list, accepts any kind of data type inside, but Lisp also has structs, objects and arrays, all of which can be defined for specific data types. Note that the ANSI Common Lisp standard includes extensive support for type declarations. Not to mention that Lisp, unlike other languages (Java, C++ -- i'm looking at you guys) don't erase types at runtime. Lisp works with values (not variables) , and values are typed. Any value, in Lisp, carries its type information at runtime.

abrax3141 7y ago

Lisp is magic. You use it to conceptualize your problem. This is most naturally done by creating a DLS for it. That is, imagine that you had a programming language that was built exactly to do exactly what you want to do. You write that down just as you imagine you would like to see it. Then all you have to do is patch in the underlying machinery. Magic!

fma 7y ago
I took an AI class that used Lisp. Language processing, knowledge based questions... What you can do in a few lines of Lisp code... Holy crap.
- pjc50 7y ago
  What can you do in a few lines of Lisp that can't be done similarly in Python or Javascript? You can do amazing things in short strings of Perl or APL/J, they just tend not to be readable.
  - jhbadger 7y ago
    Macros. You can actually add new syntax and paradigms to the language in Lisp. You can't do that in Python or Javascript. Yes, you might argue that "I don't need to change my language! It's fine the way it is". And it might be -- for now. But consider -- whatever you think about the merits of object-orientation, most languages like Javascript and Python had to be especially written to support it. Lisp could add object orientation to itself without creating a new language, a Lisp++, as it were. Lisp is future-proof the way other languages aren't.
    - zmmmmm 7y ago
      The question with that though is, is creating a unique DSL for every problem you solve actually a sustainable way to program? Once you do that, every single person who works on the code needs to understand all the implicit behavior of the DSL before they can use it. And any misunderstanding they have about it comes out as bugs. Yes, maybe OO had to be specifically added to Python, Java etc., but it's one OO that everyone uses, so when I encounter it in the wild I know exactly how it works.
  - flavio81 7y ago
    >What can you do in a few lines of Lisp that can't be done similarly in Python or Javascript? To pick just an example: Anybody can create a Brainfuck (programming language) interpreter in a few lines of Python or Js code. With Common Lisp you could create a Brainfuck compiler (that compiles down to native code and thus has native code speed) in the same amount of lines of code. Or maybe shorter. A different example: The circle-ellipse problem. It is solved easily in Common Lisp (few lines of code), because the CLOS OOP system is more powerful than the OOP systems in Java, C++, Python, Javascript and many other languages.

DonaldFisk 7y ago

That's just because you're used to writing code those languages, and if they work for you for the things you want to do, that's fine. What Lisp gives me that other high level languages don't is that it's interactive and has a built-in garbage collector (like Python but unlike C++), it has symbols with values and properties, it has closures, I don't need to write methods to read or print objects, and I can add to the language. If you don't need these, you probably don't need Lisp. I use C for low level stuff (like building a virtual machine for Lisp), and C++ for machine vision (and nothing else). Their compiled code might run faster than Lisp's but for most things Lisp's fast enough, and its faster development cycle makes it easier to find more efficient algorithms. I could, I suppose, do many of the things I currently do in other high level languages, but I don't have to. The only other high level language I do need - which gives me functionality Lisp doesn't - is Prolog, which I need to implement the type system of my visual programming language. I wrote the Prolog in Lisp and can run it on the Lisp REPL, so it's really just a Lisp library.

ben509 7y ago

Speaking to why a LISP newbie finds it tough to get things done... I think most people think in imperative terms. "I want to make a type. Now, given a thing of that type, change a thing here, change a thing here, and return the thing I want." And most languages delineate a programmer's tasks clearly. For instance, in Python and Ruby, logical structure is expressed in blocks, control (mostly) transfers between statements, while calculation is performed in expressions, and these are all visually distinct. LISP's idea that all structures can be expressed as lists doesn't visually demarcate the distinct "things" a programmer is trying to compose. You can absolutely learn it, but it makes it harder. Now, since LISP does basically use an AST directly, it makes metaprogramming trivial. The beauty of extensive metaprogramming is that you can construct new languages cheaply. The curse is that you get a lot of cheaply constructed new languages. If Python wants to add an "async" keyword, they go through weeks of debate and do a long writeup on it.[1] In LISP, someone writes a few macros and, boom, new syntax. The LISP community are smart people, they recognized this and I think the standardization efforts tried to mitigate it, and a ton of thought clearly went into Scheme. But even this article doesn't get the problem. It's not "there are too many parens" but more that everything in LISP looks the same when you're new, it's a jumble of parens. Your brain isn't getting distinct markers to help learn the structures. And LISP, shares a problem with most dynamic languages that anything can kind of go anywhere. It's not as bad for others, though, because if you look at an example of Python code, you can generally see the structure and that narrows down what can fit there. Whereas LISP is always a mess of parens and keywords; yes, it's usually obvious from looking at the docs, but it's just more research you have to do to get something done.

flavio81 7y ago
>But even this article doesn't get the problem. It's not "there are too many parens" but more that everything in LISP looks the same when you're new, it's a jumble of parens. Your brain isn't getting distinct markers to help learn the structures. On a typical language you have "structures" you mention, like "if", "for", "switch". Lisp also has them, but they look more like function calls. The syntax has a lot of less noise. Automatic indentation helps you visualize such "structures" in an easier way. It's not any more difficult than using a language like Python or C. >And LISP, shares a problem with most dynamic languages that anything can kind of go anywhere. Not really, because Common Lisp -the major Lisp dialect- is a strongly typed language, unlike the most popular dynamic languages: Javascript, PHP and Python and Ruby (Python & Ruby being 'duck typed' for the most part). And unlike the famous weakly-typed statically-typed language: C. So no, "anything" can't go anywhere, because a type mismatch will cause a runtime error. And in CL you can correct runtime errors by modifying the source code and resuming program execution (without having to restart the complete program), so no big deal either. The most common data construct, the Lisp list, accepts any kind of data type inside, but Lisp also has structs, objects and arrays, all of which can be defined for specific data types. Note that the ANSI Common Lisp standard includes extensive support for type declarations. Not to mention that Lisp, unlike other languages (Java, C++ -- i'm looking at you guys) don't erase types at runtime. Lisp works with values (not variables) , and values are typed. Any value, in Lisp, carries its type information at runtime.