6 ms·

On the other hand, these talented people chose Lisp over other options. Maybe their talent is also what let them recognize the value of Lisp, and that they woul

On the other hand, these talented people chose Lisp over other options. Maybe their talent is also what let them recognize the value of Lisp, and that they would have a much harder time solving those problems with anything else.

lisper 7y ago
I'm the author of the OP so I can speak to this with some authority: I discovered Lisp very early in my career and I stuck with it mainly because I'm lazy. I can get things done in Lisp with 1/10th the effort it would take in any other language, and it just steams my clams to have to do extra work when I know there's a better way.
- westoncb 7y ago
  > I can get things done in Lisp with 1/10th the effort it would take in any other language Should that be read as 1/10th the effort it would take you in any other language (because of your long history with lisp), or do you suppose it would apply to arbitrary other competent people? Like let's say we could make a few clones of you and start them all out on identical lives except that their early choice of language is different: one gets Haskell, another gets Forth, another Python, Ruby, etc. In this scenario you're saying you'd bet on the clone who went with Lisp being most productive?
  - lisper 7y ago
    That's a good question. The honest answer is I don't know. It's hard to do controlled experiments on this sort of thing. I can say this though: the ability to meta-abstract the language is a HUGE lever that no other language has. And one can also observe subsets of Common Lisp being continually re-invented in other languages. So CL must have gotten something right.
    - RodgerTheGreat 7y ago
      Doesn't seem that special to me. Forth has a totally different (but at least as powerful) set of mechanisms for metaprogramming. REBOL, too. And hell, these days even languages like Rust and D give programmers first-class capabilities for compile-time metaprogramming. It's disingenuous to imply that every other language is simply "reinventing Lisp". The Lisp community itself spent decades figuring out elements that are now considered basic, like lexical scope. Lisp is just a ball of mud that can absorb any idea in its vicinity, and Lisp programmers like to retcon history to make every idea theirs.
      - dreamcompiler 7y ago
        McCarthy invented conditionals. Seriously, if you've ever typed "if" into a program you owe a debt to Lisp. Likewise garbage collection. Lisp didn't absorb that; Lisp invented it. Likewise dynamic typing, first-class functions, recursion, etc etc. It's not even slightly disingenuous to imply that every other language is simply "reinventing Lisp".
        RodgerTheGreat 7y ago
        This kind of fallacious blustering is exactly what I'm talking about. "if" statements existed in FORTRAN (hell, even FLOW-MATIC), which preceded Lisp. The earliest Lisp implementations didn't have garbage collection, and while mark-and-sweep was being developed for Lisp there were other high-level peers like APL experimenting with similar ideas. Same deal for dynamic typing. First-class functions were explored in the Lambda Calculus decades before Lisp programmers applied them, and mathematics has known about recursion since antiquity. Programmers were expressing recursive algorithms in machine language in the 50s. None of this sprung fully-formed from the head of John McCarthy: Lisp borrowed from a rich preceding tradition of mathematics and computer science, and the rest of the world wasn't twiddling their thumbs while McCarthy worked on his machine-algebra system.
        dreamcompiler 7y ago
        The first Fortran had arithmetic IF. Fortran didn't get logical IF (the structured if-then-else that every language uses today) until McCarthy proposed it. Of course recursion and first-class functions were known to mathematics. But we were discussing programming languages, not mathematics. And specifically high-level languages, back when there was a lot of skepticism as to whether they were even a good idea. Fortran got there first. Lisp was second and provided the existence proof that abstract features Fortran didn't even attempt were nevertheless viable. And then it went on to become the standard language of AI. Sure, there was a lot of creativity happening back then, and Lisp didn't cause that creativity to happen. But being the second-oldest programming language and the first viable implementation of so many high-level features made Lisp a crucial development in the history of computing that's still quite relevant today.
    - deleted 7y ago
      [deleted]
    - mst 7y ago
      Possibly bizarrely, I find metaprogramming in perl to be the closest of the dynamic languages to a scheme (I'm not fluent in common lisp) - though if you can forgive the syntax ES6 with decorators is surprisingly malleable.
  - _ph_ 7y ago
    I think it is rather obvious that one is most productive in the language he or she knows best. So the question rather is, for language one knows well, what is the more productive? Also, this is a very abstract question. In reality, availability of libraries and development tools can tweak the balance for a certain task a lot. For example, I can be very productive with tcl/tk, because the whole package lets me do certain tasks very efficiently, but I wouldn't call the language "tcl" expecially productive. But overall, I think Lisp is an extremely productive language. In the last decades, a lot of modern languages have implemented a lot of Lisp features, so getting closer in productivity, without quite reaching it. Consequentely, the productivity factor depends on which langauge you compare Lisp with. But compared to languages like C++, the productivity gain is really large. For me, beyond the overall language qualities, there are two especial productivity boosters in Lisp: the ability for incremental and interactive development and to create domain specific abstractions. There are many dynamic languages, but so far I haven't seen one which as easily allows you to do interactive development. That is the ability to update single functions while your application is running. That speeds up the cycle of changing the code and testing it by orders of magnitude.
  - yogthos 7y ago
    I had around a decade professional experience with Java before I started using Clojure. Within months I was able to easily tackle problems that were daunting for me in Java using Clojure. I having used many languages during my career, I definitely find Lisps to be some of the most productive languages out there.
jeffmcmahan 7y ago
Well, and the corollary, that's why your typical engineer doesn't get it - and anyone who really insists on it is just a lunatic; adopting it would be a nightmare to the average workaday developer who just wants to have the compiler tell him/her what to do...
- yogthos 7y ago
  My team used to be a Java shop, we adopted Clojure around a decade ago and never looked back. Not really sure what this whole compiler telling the developer what to do is supposed to mean to be honest. One of the advantages of using a Lisp is that you get immediate feedback from the compiler as you're writing code via the REPL driven workflow. https://vvvvalvalval.github.io/posts/what-makes-a-good-repl.html https://vvvvalvalval.github.io/posts/what-makes-a-good-repl....

lisper 7y ago

I'm the author of the OP so I can speak to this with some authority: I discovered Lisp very early in my career and I stuck with it mainly because I'm lazy. I can get things done in Lisp with 1/10th the effort it would take in any other language, and it just steams my clams to have to do extra work when I know there's a better way.

westoncb 7y ago
> I can get things done in Lisp with 1/10th the effort it would take in any other language Should that be read as 1/10th the effort it would take you in any other language (because of your long history with lisp), or do you suppose it would apply to arbitrary other competent people? Like let's say we could make a few clones of you and start them all out on identical lives except that their early choice of language is different: one gets Haskell, another gets Forth, another Python, Ruby, etc. In this scenario you're saying you'd bet on the clone who went with Lisp being most productive?
- lisper 7y ago
  That's a good question. The honest answer is I don't know. It's hard to do controlled experiments on this sort of thing. I can say this though: the ability to meta-abstract the language is a HUGE lever that no other language has. And one can also observe subsets of Common Lisp being continually re-invented in other languages. So CL must have gotten something right.
  - RodgerTheGreat 7y ago
    Doesn't seem that special to me. Forth has a totally different (but at least as powerful) set of mechanisms for metaprogramming. REBOL, too. And hell, these days even languages like Rust and D give programmers first-class capabilities for compile-time metaprogramming. It's disingenuous to imply that every other language is simply "reinventing Lisp". The Lisp community itself spent decades figuring out elements that are now considered basic, like lexical scope. Lisp is just a ball of mud that can absorb any idea in its vicinity, and Lisp programmers like to retcon history to make every idea theirs.
    - dreamcompiler 7y ago
      McCarthy invented conditionals. Seriously, if you've ever typed "if" into a program you owe a debt to Lisp. Likewise garbage collection. Lisp didn't absorb that; Lisp invented it. Likewise dynamic typing, first-class functions, recursion, etc etc. It's not even slightly disingenuous to imply that every other language is simply "reinventing Lisp".
      - RodgerTheGreat 7y ago
        This kind of fallacious blustering is exactly what I'm talking about. "if" statements existed in FORTRAN (hell, even FLOW-MATIC), which preceded Lisp. The earliest Lisp implementations didn't have garbage collection, and while mark-and-sweep was being developed for Lisp there were other high-level peers like APL experimenting with similar ideas. Same deal for dynamic typing. First-class functions were explored in the Lambda Calculus decades before Lisp programmers applied them, and mathematics has known about recursion since antiquity. Programmers were expressing recursive algorithms in machine language in the 50s. None of this sprung fully-formed from the head of John McCarthy: Lisp borrowed from a rich preceding tradition of mathematics and computer science, and the rest of the world wasn't twiddling their thumbs while McCarthy worked on his machine-algebra system.
        dreamcompiler 7y ago
        The first Fortran had arithmetic IF. Fortran didn't get logical IF (the structured if-then-else that every language uses today) until McCarthy proposed it. Of course recursion and first-class functions were known to mathematics. But we were discussing programming languages, not mathematics. And specifically high-level languages, back when there was a lot of skepticism as to whether they were even a good idea. Fortran got there first. Lisp was second and provided the existence proof that abstract features Fortran didn't even attempt were nevertheless viable. And then it went on to become the standard language of AI. Sure, there was a lot of creativity happening back then, and Lisp didn't cause that creativity to happen. But being the second-oldest programming language and the first viable implementation of so many high-level features made Lisp a crucial development in the history of computing that's still quite relevant today.
  - deleted 7y ago
    [deleted]
  - mst 7y ago
    Possibly bizarrely, I find metaprogramming in perl to be the closest of the dynamic languages to a scheme (I'm not fluent in common lisp) - though if you can forgive the syntax ES6 with decorators is surprisingly malleable.
- _ph_ 7y ago
  I think it is rather obvious that one is most productive in the language he or she knows best. So the question rather is, for language one knows well, what is the more productive? Also, this is a very abstract question. In reality, availability of libraries and development tools can tweak the balance for a certain task a lot. For example, I can be very productive with tcl/tk, because the whole package lets me do certain tasks very efficiently, but I wouldn't call the language "tcl" expecially productive. But overall, I think Lisp is an extremely productive language. In the last decades, a lot of modern languages have implemented a lot of Lisp features, so getting closer in productivity, without quite reaching it. Consequentely, the productivity factor depends on which langauge you compare Lisp with. But compared to languages like C++, the productivity gain is really large. For me, beyond the overall language qualities, there are two especial productivity boosters in Lisp: the ability for incremental and interactive development and to create domain specific abstractions. There are many dynamic languages, but so far I haven't seen one which as easily allows you to do interactive development. That is the ability to update single functions while your application is running. That speeds up the cycle of changing the code and testing it by orders of magnitude.
- yogthos 7y ago
  I had around a decade professional experience with Java before I started using Clojure. Within months I was able to easily tackle problems that were daunting for me in Java using Clojure. I having used many languages during my career, I definitely find Lisps to be some of the most productive languages out there.

jeffmcmahan 7y ago

Well, and the corollary, that's why your typical engineer doesn't get it - and anyone who really insists on it is just a lunatic; adopting it would be a nightmare to the average workaday developer who just wants to have the compiler tell him/her what to do...

yogthos 7y ago
My team used to be a Java shop, we adopted Clojure around a decade ago and never looked back. Not really sure what this whole compiler telling the developer what to do is supposed to mean to be honest. One of the advantages of using a Lisp is that you get immediate feedback from the compiler as you're writing code via the REPL driven workflow. https://vvvvalvalval.github.io/posts/what-makes-a-good-repl.html https://vvvvalvalval.github.io/posts/what-makes-a-good-repl....