4 ms·

Any language has sufficient rope if the programmer is sufficiently clever. Not hanging yourself is a convention and most languages that are more mainstream hav

by 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.
  - kamaal 8y ago
    The sad part in all this is, many people like me will never see how Lisp Machines worked, what it mean't to use and how the overall experience was. This is really like some one describing Ice Cream to a person who never tasted it ever.
    - lispm 8y ago
      Common Lisp was developed to have that language power outside of those.
      - TeMPOraL 8y ago
        From what I understand, having never experienced those machines first-hand, that's just half of the equation. The tooling & larger ecosystem is missing.
    - rjsw 8y ago
      There are emulators for all of the different families of Lisp Machines that will run on modern computers.
    - Jach 8y ago
      Similarly there is lots of source code that we'll never see, some of it Lisp even. What beauties might they contain, especially if someone wrote a Fabien-style black book to bring forth the interesting bits? The solution is to be sad, in the same way we can be sad about the loss of the library of Alexandria, and move on, creating new works of beauty. As brought up above though, it's very hard to do this in your spare time... Few are lucky enough to hack with CL professionally, and I would wager even fewer still of those are any less free than other companies' employees of business needs coming first and forcing some terrible choices in the development cycle. Still, there can be beauty in the system, and CL is very much a systems-oriented language... (https://www.dreamsongs.com/Files/Incommensurability.pdf https://www.dreamsongs.com/Files/Incommensurability.pdf describes it as more of a programming system than a programming language, even.)
      - 8y ago
- flavio81 8y ago
  >That's the so-called Lisp Curse, Which, IMO, is mostly bollocks. See: CLOS, Quicklisp, Clack/Lack, ASDF, etc.
village-idiot 8y ago
Not every language gives you the ability to modify the syntax of the language at run-time[0]. I am sympathetic to the argument that one can write both crappy and quality code in any language, but I am also convinced that certain language structures increase or decrease the odds of a code base being maintainable, all else being held equal. Lisp brings a lot of power to the table along with relatively weak code organization constructs. A great example of this is the concept of package privacy, something that can be ignored in CL by using a double colon instead of a single colon. Sure, ideally experienced engineers would not abuse this, but that sure is a dangerous tool to leave around when deadlines are looming. My personal favorite WTF from CL was the :around methods from CLOS. These allowed you to wrap a function with other functions, possibly from a completely different place in your code base, and handle any setup/teardown as needed. We typically used them for database transactions, along with the ability to catch exceptions and trigger a DB rollback. The catch was that every single around method had to call the magic (call-next-function) function, otherwise the main function would not be called. Wondering why in the hell the function you just called isn't actually executing is quite a brainfuck, especially when it was caused by a bug in a completely different package. CL + Emacs was truly great though, best editor to language integration I've ever seen, period. [0] https://letoverlambda.com/index.cl/guest/chap4.html https://letoverlambda.com/index.cl/guest/chap4.html
- Jach 8y ago
  I also like the idea that languages impact code being maintainable. It's part of why I want to work in more dynamic languages again. My day job is mostly Java. Apart from your macro complaints (though some older devs have expressed similar complaints to me when faced with excited younger devs being a bit irresponsible with the new syntax of Java 8), I see the same things you're criticizing in Java. Java has public/private/protected/package-scope, but you can get around it trivially with reflection. (Java 9 I think "fixed" this, but you can override it at startup time.) Personally I'm in favor of Python's "we're all adults here" philosophy. Proxy patterns are common in large Java code bases, and various other things inspired by aspect-oriented programming. I've never thought to blame the language though because someone forgot to call (or decided not to call, e.g. because it got too smart with a cache) child.method() on the real object it is wrapping.

by ohyes 8y ago

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.
- kamaal 8y ago
  The sad part in all this is, many people like me will never see how Lisp Machines worked, what it mean't to use and how the overall experience was. This is really like some one describing Ice Cream to a person who never tasted it ever.
  - lispm 8y ago
    Common Lisp was developed to have that language power outside of those.
    - TeMPOraL 8y ago
      From what I understand, having never experienced those machines first-hand, that's just half of the equation. The tooling & larger ecosystem is missing.
  - rjsw 8y ago
    There are emulators for all of the different families of Lisp Machines that will run on modern computers.
  - Jach 8y ago
    Similarly there is lots of source code that we'll never see, some of it Lisp even. What beauties might they contain, especially if someone wrote a Fabien-style black book to bring forth the interesting bits? The solution is to be sad, in the same way we can be sad about the loss of the library of Alexandria, and move on, creating new works of beauty. As brought up above though, it's very hard to do this in your spare time... Few are lucky enough to hack with CL professionally, and I would wager even fewer still of those are any less free than other companies' employees of business needs coming first and forcing some terrible choices in the development cycle. Still, there can be beauty in the system, and CL is very much a systems-oriented language... (https://www.dreamsongs.com/Files/Incommensurability.pdf https://www.dreamsongs.com/Files/Incommensurability.pdf describes it as more of a programming system than a programming language, even.)
    - 8y ago
flavio81 8y ago
>That's the so-called Lisp Curse, Which, IMO, is mostly bollocks. See: CLOS, Quicklisp, Clack/Lack, ASDF, etc.

village-idiot 8y ago

Not every language gives you the ability to modify the syntax of the language at run-time[0]. I am sympathetic to the argument that one can write both crappy and quality code in any language, but I am also convinced that certain language structures increase or decrease the odds of a code base being maintainable, all else being held equal. Lisp brings a lot of power to the table along with relatively weak code organization constructs. A great example of this is the concept of package privacy, something that can be ignored in CL by using a double colon instead of a single colon. Sure, ideally experienced engineers would not abuse this, but that sure is a dangerous tool to leave around when deadlines are looming. My personal favorite WTF from CL was the :around methods from CLOS. These allowed you to wrap a function with other functions, possibly from a completely different place in your code base, and handle any setup/teardown as needed. We typically used them for database transactions, along with the ability to catch exceptions and trigger a DB rollback. The catch was that every single around method had to call the magic (call-next-function) function, otherwise the main function would not be called. Wondering why in the hell the function you just called isn't actually executing is quite a brainfuck, especially when it was caused by a bug in a completely different package. CL + Emacs was truly great though, best editor to language integration I've ever seen, period. [0] https://letoverlambda.com/index.cl/guest/chap4.html https://letoverlambda.com/index.cl/guest/chap4.html

Jach 8y ago
I also like the idea that languages impact code being maintainable. It's part of why I want to work in more dynamic languages again. My day job is mostly Java. Apart from your macro complaints (though some older devs have expressed similar complaints to me when faced with excited younger devs being a bit irresponsible with the new syntax of Java 8), I see the same things you're criticizing in Java. Java has public/private/protected/package-scope, but you can get around it trivially with reflection. (Java 9 I think "fixed" this, but you can override it at startup time.) Personally I'm in favor of Python's "we're all adults here" philosophy. Proxy patterns are common in large Java code bases, and various other things inspired by aspect-oriented programming. I've never thought to blame the language though because someone forgot to call (or decided not to call, e.g. because it got too smart with a cache) child.method() on the real object it is wrapping.