8 ms·

It’s interesting seeing lisp try and make a comeback, I wonder if it’ll work. As one of the few programmers who has worked in CL commercially in this century,

It’s interesting seeing lisp try and make a comeback, I wonder if it’ll work. As one of the few programmers who has worked in CL commercially in this century, my general analysis is that the language has way too much rope. The code base I worked on wasn’t too clever by half, it was too clever by leaps and bounds. I’d genuinely never start a multi engineer project in Lisp ever.

kamaal 8y ago
>>As one of the few programmers who has worked in CL commercially in this century As some one new, but with active interest in Lisp, I'm genuinely curious to know the projects you've worked on.
- deleted 8y ago
  [deleted]
typon 8y ago
What do you think is the best example of this rope you're talking about? Macros? Something else?
- masukomi 8y ago
  i think the macros make life easier, and if well written make the code more maintainable by simplifying the code you're encountering most of the time. for me the "rope" was the ridiculous complexity of things like the "loop" macro. Coming from a newb (to CL) perspective and wondering "how do i use this thing" ... ugh you could probably write a small book on all the different ways to use that thing. This type of stuff was littered through the language. Instead of small focused functions that were really self explanatory, but limited in capability, you have things that are way too ... i dunno "configurable"? "modifiable"? There were also thinks akin to "method overloading" but done by a drunk person seeing how many "useful" ways they could call this one function. The core language documentation is extraordinary. Probably better than any language out there.... but I moved on to Chicken Scheme for my personal work. Life was much better afterwards.
  - flavio81 8y ago
    >for me the "rope" was the ridiculous complexity of things like the "loop" macro. You are not forced to use it. I like the LOOP macro, but there are many alternatives, which you can easily load and use. >Instead of small focused functions that were really self explanatory, but limited in capability, you have things that are way too ... i dunno "configurable"? So, for example, it looks like you would have liked to use the ITERATE lib instead of the LOOP macro.
- village-idiot 8y ago
  Macros are indeed quite the bit of rope, but they're actually not that hard to tame. The problem is that when you forget to use gen-sym (to create unique symbols at macro expansion time) it will often work, but then suddenly do really weird things in the wrong context. My main beef with CL macros is that they're quite cumbersome to write, since there's no shortcuts for things like gen-sym out of the box. This is something that later lisps like Clojure fixed, although they have to provide these fixes by default, since they lack some of the more powerful and dangerous features listed below. The worst bit of rope I ever personally saw was reader macros. These allowed you to essentially modify the grammar of the language on the fly, inserting functions into the lexer to handle unknown symbols at read time. This is exactly how the quote operator, which allows you to insert literal code without running it, works. Since this happened at run time, any reader macro you registered affected all files that were read later, and thus was build order dependent. If you wanted to use your reader macro in every file, you better load it first and hope it doesn't break any of your libraries. CLOS, the standard OOP structure of CL was also full of foot guns. It's super impressive that they managed to add an OOP system to an existing language without breaking everything, but the design was .... dangerous. CLOS has some pretty weird rules around method routing, with the methods existing outside Objects and routing be handled by argument specificity. The moment you find yourself extending classes just to win the specificity race with another method you have gone too far and it's time to turn around and go back down whatever road you came up. For the most part CLOS was fine, but you could design yourself into some really weird corners. The worst part about CLOS was the before, after, and around functions. These allowed you to add functions that wrapped your regular functions, possibly multiple times with order of execution being handled by similar specificity rules. The kicker was that every of these methods was responsible to call the magic "call-next-method" function, which continued the call chain down the stack. If an around method did not do this, the main method would never execute. It is super confusing to manually call a method, only for it to not execute or trigger your debugger, especially since you can register around methods on any method from any package. Also, CL has a very weak definition of package privacy. Any public symbol, function or otherwise, is accessed externally with the form "package:symbol". But private symbols, those not explicitly exported, can be accessed with "package::symbol". Much like ruby's much maligned "send" method, there's nothing preventing sane programmers from staying way the hell away from private methods. But just like ruby's send method, that is a mighty tempting tool to leave laying around when deadlines loom and pressure is mounting. Before I finish, a sibling comment mentioned the loop macro. This thing is absolutely insane, I personally stayed way away from it because I never really mastered it, and syntactically is didn't match anything else from CL. Here's a valid example from the "LOOP for Black Belts"[0] page. (loop for i in *random* counting (evenp i) into evens counting (oddp i) into odds summing i into total maximizing i into max minimizing i into min finally (return (list min max total evens odds))) While it sure is pretty, it's really jarring when you're working in CL. Where are the parens? How the heck does this parse? What is the runtime complexity of this thing? How do I figure out what magic keywords are available within this loop macro? It's maddening! And before you ask, no symbols like "counting" are not already functions in the lisp standard. That would be far too easy. God help you if you have a loop call that needs to be modified just enough to make using loop unfeasible. [0] http://www.gigamonkeys.com/book/loop-for-black-belts.html http://www.gigamonkeys.com/book/loop-for-black-belts.html
agumonkey 8y ago
Lisp won't come back, it's everywhere in the form of genes. A lot of practices from lisp/ml world are now mainstream in es6, python and even cpp.
- pjmlp 8y ago
  Pity that those genes are still catching up with Interlisp-D/Lisp Machines developer experience, though.
  - kamaal 8y ago
    I think most programmers today wouldn't have heard about Lisp Machines. Unless some one describes it to us, we wouldn't even know what that experience even felt like.
    - pjmlp 8y ago
      By all means, "Graphical Programming with Xerox Lisp" https://www.youtube.com/watch?v=J4F6ioMKiqw&list=PL80581C8F8E916516 https://www.youtube.com/watch?v=J4F6ioMKiqw&list=PL80581C8F8... "Symbolics Lisp Machine" https://www.youtube.com/watch?v=o4-YnLpLgtk&t=28s https://www.youtube.com/watch?v=o4-YnLpLgtk&t=28s "The Interlisp Programming Environment (1981)" https://news.ycombinator.com/item?id=5966328 https://news.ycombinator.com/item?id=5966328 "Interlisp-D Reference Manual Volume II: Environment" http://www.bitsavers.org/pdf/xerox/interlisp-d/198510_Koto/3101273_Interlisp-D_Vol_2_Environment_Oct85.pdf http://www.bitsavers.org/pdf/xerox/interlisp-d/198510_Koto/3...
      - agumonkey 8y ago
        have you used pharo ? I quite ~loved the experience, and I wonder if lisp machines were similar in the feeling that you really can mold your system real time. Or if it was different.. (more possibilities, different idioms that changed the perspective)
        pjmlp 8y ago
TeMPOraL 8y ago
As one of those few who also worked in CL commercially in this century, I disagree. The amount of rope is fine. There's just a big library and documentation problem. You can find a library for anything these days, but quite often it's only half-done, and you need to write the other half yourself. The way I see it, all the power and flexibility of CL is what keeps it alive; any other language would have died off with so little people working on the libraries. I used to not mind this that much, but recently I also started working on Clojure code, and the difference is like night and day.
- kamaal 8y ago
  Clojure has this advantage of Java Interop. So even if you didn't find native Clojure libraries, you can always find Java libraries. And you will find Java libraries for pretty much everything under the Sun. Sure they had to sacrifice a lot for that, but ultimately its worth it. Any language that has to compete and be acceptable to the larger programming community today needs libraries. So it kind of becomes a Chicken/Egg problem. I don't think anything today will ever reach the levels of Java usage. Partly because no company is likely to spend on a new language as much as Sun spent on Java. So you are pretty much well off building on their ecosystem than fight it. Having said that, TCO is the only thing I missed in Clojure compared to CL.
  - lispm 8y ago
    https://abcl.org https://abcl.org
  - TeMPOraL 8y ago
    Sort of. Java interop is an extra win for Clojure, but I really meant just the Clojure libraries. Every time I need one, it seems much more feature-complete than CL alternative. To take an example: in a project I'm working on, we're using Ring[0] at the backend + bunch of middleware, including Liberator[1]. Take a look at e.g. Liberator docs[2] and tell me, where's a CL library for just that, with so much thought that went into it? Or, in a CL project we had to implement CORS handling ourselves, whereas in Clojure we get it for free. Etc. This kind of story seems to repeat every time I need a library. In Common Lisp, you have to hope that Edi Weitz, Shinmera or Fukamachi wrote something, and that you won't have to patch much to make it work for you. In Clojure, everything I've seen so far[3] makes me expect to find solid and feature-complete libraries whenever I need something. Now to be clear, I still love working in Common Lisp. It's just that my experience with Clojure made me jealous. -- [0] - https://github.com/ring-clojure/ring https://github.com/ring-clojure/ring [1] - https://github.com/clojure-liberator/liberator https://github.com/clojure-liberator/liberator [2] - http://clojure-liberator.github.io/liberator/ http://clojure-liberator.github.io/liberator/ [3] - I've been writing Clojure for only couple of months, so this may be colored by first impressions.
sureaboutthis 8y ago
The code base you worked on has nothing to do with how good or bad Lisp is. It's only an indication of how good or bad the programmers who wrote that code base are.
ohyes 8y ago
Any language has sufficient rope if the programmer is sufficiently clever. Not hanging yourself is a convention and most languages that are more mainstream have bigger communities and more conventions (and frankly, more adults encouraging them). I have a hard time blaming the language for what are essentially organizational problems. Too many lisp people start projects doing everything with a single implementor. Therefore the convention starts out as “whatever this guy wants to do that works.” Anyone working in a bubble like that is bound to eventually create something that makes sense to the implementor, but not necessarily outside people. Which is why you need peer review when you’re writing your code. If you don’t get it, you’re gonna have problems. Maybe there is something about lisp that makes it difficult to review, but I think more likely there is something about lispers that makes them unwilling to do that particular set of work.
- TeMPOraL 8y ago
  That's the so-called Lisp Curse, though, which states: "Lisp is so powerful that problems which are technical issues in other programming languages are social issues in Lisp". http://www.winestockwebdesign.com/Essays/Lisp_Curse.html http://www.winestockwebdesign.com/Essays/Lisp_Curse.html
  - lispm 8y ago
    The main topic 'adding OO' to Lisp is a good counter example. > Now make this thought experiment interesting: Imagine adding object orientation to the C and Scheme programming languages. How was it done in Lisp? 1) various experiments and getting real work experience with 1st and 2nd generation OOP in Lisp (Flavors, Loops, CommonObjects, Object Lisp, ...) 2) various proposals for a standard OO system 3) a small group (with people from Xerox PARC, Symbolics and Lucid) working on an OO system with large amounts of user feedback -> developing a full-blown portable public domain CLOS implementation and using public mailing lists for feedback. The resulting implementation PCL (Portable Common LOOPS) was ported to more than a dozen Lisp implementations. A SPEC was written. Books were written. The result was CLOS. THE object system for Lisp. Built with the input of hundreds of developers/users. It worked great. The fear of group work in and for Lisp is massively overblown. > Why don't they make a free development system that calls to mind some of the lost glories of the LispM, even if they can't reproduce another LispM? The reason why this doesn't happen is because of the Lisp Curse. The reason is that the first systems were developed in a totally different environment: large research organizations like PARC and MIT AI Lab swimming in DARPA money employing the brightest minds of their generation. A genius like Richard Feynberg wanted to work there: '...many a visitor at Thinking Machines was shocked to see that we had a Nobel Laureate soldering circuit boards or painting walls...' http://longnow.org/essays/richard-feynman-connection-machine/ http://longnow.org/essays/richard-feynman-connection-machine... The hacker community can't replicate that in their spare time.
s_kilk 8y ago
The one that kills me, every time I look at CL, is the lack of a real Boolean type. Maybe I'm nuts, but that really isn't acceptable in this century.
- TeMPOraL 8y ago
  You have T and NIL, and you can deftype a "boolean" for yourself as a choice between T and NIL. The so-called "generalized booleans" are a design choice, and not bad choice IMO.
  - stevelosh 8y ago
    You don't have to even have to deftype it -- there's a built in boolean type: http://clhs.lisp.se/Body/t_ban.htm http://clhs.lisp.se/Body/t_ban.htm
  - s_kilk 8y ago
    Is there a way to distinguish NIL from the Empty List?
    - TeMPOraL 8y ago
      No.
      - s_kilk 8y ago
        Which means I can't accurately represent a whole bunch of data received from the environment. Hence why I find it annoying.
        kbp 8y ago
        Do you have an example of where this would be a problem for you? What can't you represent?
        flavio81 8y ago
        The empty list and NIL are the same, but you aren't forced to use lists for everything on Common Lisp. You have arrays etc etc.

kamaal 8y ago

>>As one of the few programmers who has worked in CL commercially in this century As some one new, but with active interest in Lisp, I'm genuinely curious to know the projects you've worked on.

deleted 8y ago
[deleted]

typon 8y ago

What do you think is the best example of this rope you're talking about? Macros? Something else?

masukomi 8y ago
i think the macros make life easier, and if well written make the code more maintainable by simplifying the code you're encountering most of the time. for me the "rope" was the ridiculous complexity of things like the "loop" macro. Coming from a newb (to CL) perspective and wondering "how do i use this thing" ... ugh you could probably write a small book on all the different ways to use that thing. This type of stuff was littered through the language. Instead of small focused functions that were really self explanatory, but limited in capability, you have things that are way too ... i dunno "configurable"? "modifiable"? There were also thinks akin to "method overloading" but done by a drunk person seeing how many "useful" ways they could call this one function. The core language documentation is extraordinary. Probably better than any language out there.... but I moved on to Chicken Scheme for my personal work. Life was much better afterwards.
- flavio81 8y ago
  >for me the "rope" was the ridiculous complexity of things like the "loop" macro. You are not forced to use it. I like the LOOP macro, but there are many alternatives, which you can easily load and use. >Instead of small focused functions that were really self explanatory, but limited in capability, you have things that are way too ... i dunno "configurable"? So, for example, it looks like you would have liked to use the ITERATE lib instead of the LOOP macro.
village-idiot 8y ago
Macros are indeed quite the bit of rope, but they're actually not that hard to tame. The problem is that when you forget to use gen-sym (to create unique symbols at macro expansion time) it will often work, but then suddenly do really weird things in the wrong context. My main beef with CL macros is that they're quite cumbersome to write, since there's no shortcuts for things like gen-sym out of the box. This is something that later lisps like Clojure fixed, although they have to provide these fixes by default, since they lack some of the more powerful and dangerous features listed below. The worst bit of rope I ever personally saw was reader macros. These allowed you to essentially modify the grammar of the language on the fly, inserting functions into the lexer to handle unknown symbols at read time. This is exactly how the quote operator, which allows you to insert literal code without running it, works. Since this happened at run time, any reader macro you registered affected all files that were read later, and thus was build order dependent. If you wanted to use your reader macro in every file, you better load it first and hope it doesn't break any of your libraries. CLOS, the standard OOP structure of CL was also full of foot guns. It's super impressive that they managed to add an OOP system to an existing language without breaking everything, but the design was .... dangerous. CLOS has some pretty weird rules around method routing, with the methods existing outside Objects and routing be handled by argument specificity. The moment you find yourself extending classes just to win the specificity race with another method you have gone too far and it's time to turn around and go back down whatever road you came up. For the most part CLOS was fine, but you could design yourself into some really weird corners. The worst part about CLOS was the before, after, and around functions. These allowed you to add functions that wrapped your regular functions, possibly multiple times with order of execution being handled by similar specificity rules. The kicker was that every of these methods was responsible to call the magic "call-next-method" function, which continued the call chain down the stack. If an around method did not do this, the main method would never execute. It is super confusing to manually call a method, only for it to not execute or trigger your debugger, especially since you can register around methods on any method from any package. Also, CL has a very weak definition of package privacy. Any public symbol, function or otherwise, is accessed externally with the form "package:symbol". But private symbols, those not explicitly exported, can be accessed with "package::symbol". Much like ruby's much maligned "send" method, there's nothing preventing sane programmers from staying way the hell away from private methods. But just like ruby's send method, that is a mighty tempting tool to leave laying around when deadlines loom and pressure is mounting. Before I finish, a sibling comment mentioned the loop macro. This thing is absolutely insane, I personally stayed way away from it because I never really mastered it, and syntactically is didn't match anything else from CL. Here's a valid example from the "LOOP for Black Belts"[0] page. (loop for i in *random* counting (evenp i) into evens counting (oddp i) into odds summing i into total maximizing i into max minimizing i into min finally (return (list min max total evens odds))) While it sure is pretty, it's really jarring when you're working in CL. Where are the parens? How the heck does this parse? What is the runtime complexity of this thing? How do I figure out what magic keywords are available within this loop macro? It's maddening! And before you ask, no symbols like "counting" are not already functions in the lisp standard. That would be far too easy. God help you if you have a loop call that needs to be modified just enough to make using loop unfeasible. [0] http://www.gigamonkeys.com/book/loop-for-black-belts.html http://www.gigamonkeys.com/book/loop-for-black-belts.html

agumonkey 8y ago

Lisp won't come back, it's everywhere in the form of genes. A lot of practices from lisp/ml world are now mainstream in es6, python and even cpp.

pjmlp 8y ago
Pity that those genes are still catching up with Interlisp-D/Lisp Machines developer experience, though.
- kamaal 8y ago
  I think most programmers today wouldn't have heard about Lisp Machines. Unless some one describes it to us, we wouldn't even know what that experience even felt like.
  - pjmlp 8y ago
    By all means, "Graphical Programming with Xerox Lisp" https://www.youtube.com/watch?v=J4F6ioMKiqw&list=PL80581C8F8E916516 https://www.youtube.com/watch?v=J4F6ioMKiqw&list=PL80581C8F8... "Symbolics Lisp Machine" https://www.youtube.com/watch?v=o4-YnLpLgtk&t=28s https://www.youtube.com/watch?v=o4-YnLpLgtk&t=28s "The Interlisp Programming Environment (1981)" https://news.ycombinator.com/item?id=5966328 https://news.ycombinator.com/item?id=5966328 "Interlisp-D Reference Manual Volume II: Environment" http://www.bitsavers.org/pdf/xerox/interlisp-d/198510_Koto/3101273_Interlisp-D_Vol_2_Environment_Oct85.pdf http://www.bitsavers.org/pdf/xerox/interlisp-d/198510_Koto/3...
    - agumonkey 8y ago
      have you used pharo ? I quite ~loved the experience, and I wonder if lisp machines were similar in the feeling that you really can mold your system real time. Or if it was different.. (more possibilities, different idioms that changed the perspective)
      - pjmlp 8y ago

TeMPOraL 8y ago

As one of those few who also worked in CL commercially in this century, I disagree. The amount of rope is fine. There's just a big library and documentation problem. You can find a library for anything these days, but quite often it's only half-done, and you need to write the other half yourself. The way I see it, all the power and flexibility of CL is what keeps it alive; any other language would have died off with so little people working on the libraries. I used to not mind this that much, but recently I also started working on Clojure code, and the difference is like night and day.

kamaal 8y ago
Clojure has this advantage of Java Interop. So even if you didn't find native Clojure libraries, you can always find Java libraries. And you will find Java libraries for pretty much everything under the Sun. Sure they had to sacrifice a lot for that, but ultimately its worth it. Any language that has to compete and be acceptable to the larger programming community today needs libraries. So it kind of becomes a Chicken/Egg problem. I don't think anything today will ever reach the levels of Java usage. Partly because no company is likely to spend on a new language as much as Sun spent on Java. So you are pretty much well off building on their ecosystem than fight it. Having said that, TCO is the only thing I missed in Clojure compared to CL.
- lispm 8y ago
  https://abcl.org https://abcl.org
- TeMPOraL 8y ago
  Sort of. Java interop is an extra win for Clojure, but I really meant just the Clojure libraries. Every time I need one, it seems much more feature-complete than CL alternative. To take an example: in a project I'm working on, we're using Ring[0] at the backend + bunch of middleware, including Liberator[1]. Take a look at e.g. Liberator docs[2] and tell me, where's a CL library for just that, with so much thought that went into it? Or, in a CL project we had to implement CORS handling ourselves, whereas in Clojure we get it for free. Etc. This kind of story seems to repeat every time I need a library. In Common Lisp, you have to hope that Edi Weitz, Shinmera or Fukamachi wrote something, and that you won't have to patch much to make it work for you. In Clojure, everything I've seen so far[3] makes me expect to find solid and feature-complete libraries whenever I need something. Now to be clear, I still love working in Common Lisp. It's just that my experience with Clojure made me jealous. -- [0] - https://github.com/ring-clojure/ring https://github.com/ring-clojure/ring [1] - https://github.com/clojure-liberator/liberator https://github.com/clojure-liberator/liberator [2] - http://clojure-liberator.github.io/liberator/ http://clojure-liberator.github.io/liberator/ [3] - I've been writing Clojure for only couple of months, so this may be colored by first impressions.

sureaboutthis 8y ago

The code base you worked on has nothing to do with how good or bad Lisp is. It's only an indication of how good or bad the programmers who wrote that code base are.

ohyes 8y ago

Any language has sufficient rope if the programmer is sufficiently clever. Not hanging yourself is a convention and most languages that are more mainstream have bigger communities and more conventions (and frankly, more adults encouraging them). I have a hard time blaming the language for what are essentially organizational problems. Too many lisp people start projects doing everything with a single implementor. Therefore the convention starts out as “whatever this guy wants to do that works.” Anyone working in a bubble like that is bound to eventually create something that makes sense to the implementor, but not necessarily outside people. Which is why you need peer review when you’re writing your code. If you don’t get it, you’re gonna have problems. Maybe there is something about lisp that makes it difficult to review, but I think more likely there is something about lispers that makes them unwilling to do that particular set of work.

TeMPOraL 8y ago
That's the so-called Lisp Curse, though, which states: "Lisp is so powerful that problems which are technical issues in other programming languages are social issues in Lisp". http://www.winestockwebdesign.com/Essays/Lisp_Curse.html http://www.winestockwebdesign.com/Essays/Lisp_Curse.html
- lispm 8y ago
  The main topic 'adding OO' to Lisp is a good counter example. > Now make this thought experiment interesting: Imagine adding object orientation to the C and Scheme programming languages. How was it done in Lisp? 1) various experiments and getting real work experience with 1st and 2nd generation OOP in Lisp (Flavors, Loops, CommonObjects, Object Lisp, ...) 2) various proposals for a standard OO system 3) a small group (with people from Xerox PARC, Symbolics and Lucid) working on an OO system with large amounts of user feedback -> developing a full-blown portable public domain CLOS implementation and using public mailing lists for feedback. The resulting implementation PCL (Portable Common LOOPS) was ported to more than a dozen Lisp implementations. A SPEC was written. Books were written. The result was CLOS. THE object system for Lisp. Built with the input of hundreds of developers/users. It worked great. The fear of group work in and for Lisp is massively overblown. > Why don't they make a free development system that calls to mind some of the lost glories of the LispM, even if they can't reproduce another LispM? The reason why this doesn't happen is because of the Lisp Curse. The reason is that the first systems were developed in a totally different environment: large research organizations like PARC and MIT AI Lab swimming in DARPA money employing the brightest minds of their generation. A genius like Richard Feynberg wanted to work there: '...many a visitor at Thinking Machines was shocked to see that we had a Nobel Laureate soldering circuit boards or painting walls...' http://longnow.org/essays/richard-feynman-connection-machine/ http://longnow.org/essays/richard-feynman-connection-machine... The hacker community can't replicate that in their spare time.

s_kilk 8y ago

The one that kills me, every time I look at CL, is the lack of a real Boolean type. Maybe I'm nuts, but that really isn't acceptable in this century.

TeMPOraL 8y ago
You have T and NIL, and you can deftype a "boolean" for yourself as a choice between T and NIL. The so-called "generalized booleans" are a design choice, and not bad choice IMO.
- stevelosh 8y ago
  You don't have to even have to deftype it -- there's a built in boolean type: http://clhs.lisp.se/Body/t_ban.htm http://clhs.lisp.se/Body/t_ban.htm
- s_kilk 8y ago
  Is there a way to distinguish NIL from the Empty List?
  - TeMPOraL 8y ago
    No.
    - s_kilk 8y ago
      Which means I can't accurately represent a whole bunch of data received from the environment. Hence why I find it annoying.
      - kbp 8y ago
        Do you have an example of where this would be a problem for you? What can't you represent?
      - flavio81 8y ago
        The empty list and NIL are the same, but you aren't forced to use lists for everything on Common Lisp. You have arrays etc etc.