5 ms·

Lisp doesn’t really have many, if at all, super weird concepts that need months of thinking about in order to understand. Training seems like some lost art as

Lisp doesn’t really have many, if at all, super weird concepts that need months of thinking about in order to understand. Training seems like some lost art as we collectively move toward a more disposable programming ethos. Training a good programmer how to write Lisp is, what, two weeks of work? Learn how to make variables, write functions, define classes, and compile a project. That gets you 80% of the way there, and definitely gets you across the “productivity threshold”. Somehow, in the same breath, we find it okay to spend weeks agreeing on how to ship Python code, what the standard development environment is, and how a 2->3 transition of 100,000 lines of code will be accomplished.

dwohnitmok 5y ago
> Lisp doesn’t really have many, if at all, super weird concepts that need months of thinking about in order to understand. I mean Haskell advocates will say the same about Haskell (monads are really not that bad: I'd be surprised if someone on a team of experienced Haskell programmers would take more than a week to come up to speed on them. It's more the rich interplay of monads and other concepts that either rewards deeper study or is a dangerous rabbit hole depending on your perspective). In both cases it's a matter of how deep the rabbit hole goes in the concepts that the languages do offer and how much a given code base uses those concepts to their fullest potential. It's a double-edged sword. The same concepts that yield so many layers of power, expressiveness, and universality can yield frighteningly arcane codebases in the hands of advanced novices, those with "just enough knowledge to do harm." There's a reason the meme of Lisp programmers going through a phase where they want to "macro all the things" before calming down and using them more judiciously is a meme. Likewise a boring language like Go that purposefully puts abstraction ceilings has a double-edged sword whose edges cut the other way. An excellent team with good taste will be at home in whatever language they end up choosing, almost by definition. The opposite direction is a road much more fraught with danger.
- reikonomusha 5y ago
  Haskell programmers may say the same thing about Haskell, but it’s not the same thing as far as Lisp is concerned. Yes, it’s possible to concoct the weirdest stuff in Lisp, but that would probably be bad code. Some macros might take time to learn, but unlike Haskell where you need to know monads to be productive, you do not need to know how to author macros to read and write most Lisp. Languages that have these “abstraction ceilings”, as you put it, have their own danger as well—just a different danger. Namely, you’re choosing boringness of the language as a feature, in many cases requiring some multiple of additional programmers, which means some multiple of additional time spent hiring and money spent paying salaries. For some companies, money isn’t a problem, so choosing boring tech with a gazillion programmers and double-digit churn rate is just fine. Programming in Go doesn’t automatically resolve all the issues of running and maintaining a technical project. It makes one particular problem trivially solved (inconsistent code format, expressiveness going off the rails, etc.). But choices and policy around how code is contributed to, how software is documented, how architecture is developed and reviewed, how dependencies are managed and added, how code is reviewed, etc. still falls on humans to conceive and implement as agreed-upon policies. In Lisp, how code is formatted and what language features might be off-limits can also be solved by way of such policy-making. Its not theoretical either; even Google publishes a style guide on Lisp development that they follow internally, and it works fine. It’s really not as “dangerous” as everyone seems to make it out to be.
  - dwohnitmok 5y ago
    > but unlike Haskell where you need to know monads to be productive I disagree. You don't need to author monads to be productive in Haskell (and in a production codebase rarely would, the monads you use change rarely). Having written a good of deal of Lisp going out to production in the form of Clojure and a good deal of Haskell I really think monads and macros are a rather fitting analogy here. It's really the same deal. You need to know how use monads in Haskell just as you need to know how to use macros in a Lisp. Are you going to be writing a lot of your own new ones in a pre-existing production codebase? Unlikely. Are you going to be creating a couple of them here and there in a lot of the new libraries you write? Probably. Are they both things that sound really scary to outsiders but are really quite tame if you have a team surrounding you helping you out? Yeah. > It’s really not as “dangerous” as everyone seems to make it out to be. Again I don't think it's dangerous. I just think it's a weird direction to take. There are no good languages in isolation. There are only languages that are the best fits for a given team. EDIT: > Languages that have these “abstraction ceilings”, as you put it, have their own danger as well—just a different danger. Namely, you’re choosing boringness of the language as a feature, in many cases requiring some multiple of additional programmers, which means some multiple of additional time spent hiring and money spent paying salaries. For some companies, money isn’t a problem, so choosing boring tech with a gazillion programmers and double-digit churn rate is just fine. Indeed, I'm not particular champion of Go or Java (the traditional boring languages people bring up). Their very boring-ness has its own drawbacks as you say, ones that I feel acutely whenever I've worked on teams using them. But these are a series of true trade-offs, one where different situations will call with different needs. I have met plenty of people who are extremely competent Common Lisp, Haskell, Clojure, etc. programmers who have proactively chosen to go with a "boring" language for a new team (for a variety of reasons, not necessarily because the "interesting" language has sharp edges). The team (and by extension the company) precedes and determines the language, not the other way around.
    - reikonomusha 5y ago
      I do agree most Haskell programmers don’t need to be authoring monads to be productive. My take was more along the lines that monads expose an interface/API to the programmer that is used pervasively in “ordinary programming”. This interface/API is defined rather abstractly and doesn’t come equipped with “obvious”, self-evident definitions. You can get pretty far in Haskell though just sort of parroting these operators for specific class instances of interest, like IO and Maybe. This is, I claim, unlike macros where you really don’t need to know about the machinery of macros (or even of their existence) to understand and use AND, OR, DOLIST, LOOP, etc. The notion of a macro doesn’t “leak” in “ordinary programming” whereas ‘>>=‘ or ‘return’ do, even if in just type errors. (Sorry for the copious scare-quotes.)
dTal 5y ago
>Lisp doesn’t really have many, if at all, super weird concepts that need months of thinking about in order to understand. I dunno, using a DSL for linked lists as the only syntax construct is pretty radical. CAR/CDR and CONS pair dot notation must feel pretty esoteric. The concept of macros that transform the syntax tree is unusual, and knowing when to use them requires a restraint that comes only with experience. I could see it taking months if not years to fully grasp the zen of Lisp.
- ryanianian 5y ago
  Same could be said about the zen of, eg, Python though. Deep experience pays off for library/framework authors, but most practitioners don’t have daily need for __new__ or slots or...
- reikonomusha 5y ago
  Come on. (if (= x 2) (print "x is two!") (print "x is not two!")) or (defclass person () name address) will not take a professional programmer who is prepared to receive a 6-figure salary “months” to learn. We might as well call [2*x for x in range(10) if x % 2 == 0] a “DSL for constructing lists” in Python which, incidentally, also doesn’t take most paid programmers months to learn. This doesn’t even get into the zoo of syntax that languages like Python have to offer, like decorators, generator expressions, walrus operators, loop keywords (“else” in a for-loop?), etc. In my experience training both interns and new hires, getting from zero-to-first-commit is like a week. Getting on code reviews, 2-3 weeks. Feeling confident and comfortable, 4-5. Also, nobody is being paid to feel language zen. Yes, mastering Lisp or becoming anything close to an expert might take years. But being a language academic usually isn’t the goal of the working programmer.
  - westoncb 5y ago
    It seems like there would be a large space (that's sidestepped here) between learning basic syntactic differences and 'mastering' Lisp. Are there not novel concepts (outside of syntax) which programmers struggle with in that space? And does gp's comment about needing to learn 'restraint' from experience not apply to that middle space too? IME if you were diligent about only hiring very smart + intrinsically interested programmers, the kind of outcome you're describing might be realistic. But I don't see this going well if you draw from the large pool otherwise available of more paycheck-motivated programmers who may or may not have a strong grasp of conceptual underpinnings of programming languages.
jerf 5y ago
"Lisp doesn’t really have many, if at all, super weird concepts that need months of thinking about in order to understand." I don't think we can have both that and the traditional "Lisp is a great language to learn to expand your mind." "Training seems like some lost art as we collectively move toward a more disposable programming ethos." Speaking as an engineering lead, my problem is increasingly not that I have an unwillingness to train, but that I need to do something other than train; that is, I need to exploit the training to get some real work done at some point. On my team, to be a fully functional member already requires fluency in 4 general purpose programming languages, 2 devops langauges, all the misc other details needed like SQL knowledge that I could hardly even enumerate off the top of my head if I wanted to, and the associated system knowledge for half-a-dozen systems as to how they are deployed, how to fix them, etc. Bringing up a fresh college grad who happens to have zero of these could be the work of plural years already. I compare this to what was required in my first engineering job in ~1997: One programming language (VBScript), basic SQL, and "fluency" in HTML that today would be considered "basic" HTML, and with that we had everything we needed at the time. Adding things to the stack was easy to justify back then. It's harder now. If you want to add another language to the pile, I'm going to need you to have a darned good reason beyond "It's a good language" or "But I like it". 2 weeks is an absurd underestimate for obtaining Lisp fluency, by the way. Surface syntax understanding and the ability to build something someone else already built, sure, but learning the libraries, the existing code base, the other quirks (especially in a language like Lisp that is all but made out of quirks if you start using the language well), there's no way that's two weeks. It's not that I'm not open to languages, it's that even on my own personal team I can't afford to have everyone drag in whatever language they want to use for some task. It's not a coincidence that so many companies end up with the Approved Language list. Smarter companies with such a list will have a way to get specific exemptions and make it not too hard to get them for good reasons (e.g., if your list is C++ and Javascript one has a good case for adding Python for an ML or NumPy project), but if you let everyone drag in whatever language they like you'll end up with enforced fragmentation of teams and significant difficulties with bringing new developers up to speed in positions where they have to become fluent in perhaps literally 10 general purpose languages to function fully.
Zababa 5y ago
> Training seems like some lost art as we collectively move toward a more disposable programming ethos. I think you're right on that, and that is damaging for Lisp. These days most training seems to be done by external sources, for example Pluralsight, Udemy, medium articles about how to do a specific things, etc. Since those have commercial incentives, they target the biggest audiance, which is usually JavaScript, Java, Python, or something like that. On the other hand, the companies don't want to train people in a specific language, so they hire people that already know their language. That creates a positive feedback cycle that makes less used languages even less used. Same thing about open source contributions (tooling, libraries, etc). I think the insistance on Emacs may also be damaging because it's an even bigger barrier of entry.

dwohnitmok 5y ago

> Lisp doesn’t really have many, if at all, super weird concepts that need months of thinking about in order to understand. I mean Haskell advocates will say the same about Haskell (monads are really not that bad: I'd be surprised if someone on a team of experienced Haskell programmers would take more than a week to come up to speed on them. It's more the rich interplay of monads and other concepts that either rewards deeper study or is a dangerous rabbit hole depending on your perspective). In both cases it's a matter of how deep the rabbit hole goes in the concepts that the languages do offer and how much a given code base uses those concepts to their fullest potential. It's a double-edged sword. The same concepts that yield so many layers of power, expressiveness, and universality can yield frighteningly arcane codebases in the hands of advanced novices, those with "just enough knowledge to do harm." There's a reason the meme of Lisp programmers going through a phase where they want to "macro all the things" before calming down and using them more judiciously is a meme. Likewise a boring language like Go that purposefully puts abstraction ceilings has a double-edged sword whose edges cut the other way. An excellent team with good taste will be at home in whatever language they end up choosing, almost by definition. The opposite direction is a road much more fraught with danger.

reikonomusha 5y ago
Haskell programmers may say the same thing about Haskell, but it’s not the same thing as far as Lisp is concerned. Yes, it’s possible to concoct the weirdest stuff in Lisp, but that would probably be bad code. Some macros might take time to learn, but unlike Haskell where you need to know monads to be productive, you do not need to know how to author macros to read and write most Lisp. Languages that have these “abstraction ceilings”, as you put it, have their own danger as well—just a different danger. Namely, you’re choosing boringness of the language as a feature, in many cases requiring some multiple of additional programmers, which means some multiple of additional time spent hiring and money spent paying salaries. For some companies, money isn’t a problem, so choosing boring tech with a gazillion programmers and double-digit churn rate is just fine. Programming in Go doesn’t automatically resolve all the issues of running and maintaining a technical project. It makes one particular problem trivially solved (inconsistent code format, expressiveness going off the rails, etc.). But choices and policy around how code is contributed to, how software is documented, how architecture is developed and reviewed, how dependencies are managed and added, how code is reviewed, etc. still falls on humans to conceive and implement as agreed-upon policies. In Lisp, how code is formatted and what language features might be off-limits can also be solved by way of such policy-making. Its not theoretical either; even Google publishes a style guide on Lisp development that they follow internally, and it works fine. It’s really not as “dangerous” as everyone seems to make it out to be.
- dwohnitmok 5y ago
  > but unlike Haskell where you need to know monads to be productive I disagree. You don't need to author monads to be productive in Haskell (and in a production codebase rarely would, the monads you use change rarely). Having written a good of deal of Lisp going out to production in the form of Clojure and a good deal of Haskell I really think monads and macros are a rather fitting analogy here. It's really the same deal. You need to know how use monads in Haskell just as you need to know how to use macros in a Lisp. Are you going to be writing a lot of your own new ones in a pre-existing production codebase? Unlikely. Are you going to be creating a couple of them here and there in a lot of the new libraries you write? Probably. Are they both things that sound really scary to outsiders but are really quite tame if you have a team surrounding you helping you out? Yeah. > It’s really not as “dangerous” as everyone seems to make it out to be. Again I don't think it's dangerous. I just think it's a weird direction to take. There are no good languages in isolation. There are only languages that are the best fits for a given team. EDIT: > Languages that have these “abstraction ceilings”, as you put it, have their own danger as well—just a different danger. Namely, you’re choosing boringness of the language as a feature, in many cases requiring some multiple of additional programmers, which means some multiple of additional time spent hiring and money spent paying salaries. For some companies, money isn’t a problem, so choosing boring tech with a gazillion programmers and double-digit churn rate is just fine. Indeed, I'm not particular champion of Go or Java (the traditional boring languages people bring up). Their very boring-ness has its own drawbacks as you say, ones that I feel acutely whenever I've worked on teams using them. But these are a series of true trade-offs, one where different situations will call with different needs. I have met plenty of people who are extremely competent Common Lisp, Haskell, Clojure, etc. programmers who have proactively chosen to go with a "boring" language for a new team (for a variety of reasons, not necessarily because the "interesting" language has sharp edges). The team (and by extension the company) precedes and determines the language, not the other way around.
  - reikonomusha 5y ago
    I do agree most Haskell programmers don’t need to be authoring monads to be productive. My take was more along the lines that monads expose an interface/API to the programmer that is used pervasively in “ordinary programming”. This interface/API is defined rather abstractly and doesn’t come equipped with “obvious”, self-evident definitions. You can get pretty far in Haskell though just sort of parroting these operators for specific class instances of interest, like IO and Maybe. This is, I claim, unlike macros where you really don’t need to know about the machinery of macros (or even of their existence) to understand and use AND, OR, DOLIST, LOOP, etc. The notion of a macro doesn’t “leak” in “ordinary programming” whereas ‘>>=‘ or ‘return’ do, even if in just type errors. (Sorry for the copious scare-quotes.)

dTal 5y ago

>Lisp doesn’t really have many, if at all, super weird concepts that need months of thinking about in order to understand. I dunno, using a DSL for linked lists as the only syntax construct is pretty radical. CAR/CDR and CONS pair dot notation must feel pretty esoteric. The concept of macros that transform the syntax tree is unusual, and knowing when to use them requires a restraint that comes only with experience. I could see it taking months if not years to fully grasp the zen of Lisp.

ryanianian 5y ago
Same could be said about the zen of, eg, Python though. Deep experience pays off for library/framework authors, but most practitioners don’t have daily need for __new__ or slots or...
reikonomusha 5y ago
Come on. (if (= x 2) (print "x is two!") (print "x is not two!")) or (defclass person () name address) will not take a professional programmer who is prepared to receive a 6-figure salary “months” to learn. We might as well call [2*x for x in range(10) if x % 2 == 0] a “DSL for constructing lists” in Python which, incidentally, also doesn’t take most paid programmers months to learn. This doesn’t even get into the zoo of syntax that languages like Python have to offer, like decorators, generator expressions, walrus operators, loop keywords (“else” in a for-loop?), etc. In my experience training both interns and new hires, getting from zero-to-first-commit is like a week. Getting on code reviews, 2-3 weeks. Feeling confident and comfortable, 4-5. Also, nobody is being paid to feel language zen. Yes, mastering Lisp or becoming anything close to an expert might take years. But being a language academic usually isn’t the goal of the working programmer.
- westoncb 5y ago
  It seems like there would be a large space (that's sidestepped here) between learning basic syntactic differences and 'mastering' Lisp. Are there not novel concepts (outside of syntax) which programmers struggle with in that space? And does gp's comment about needing to learn 'restraint' from experience not apply to that middle space too? IME if you were diligent about only hiring very smart + intrinsically interested programmers, the kind of outcome you're describing might be realistic. But I don't see this going well if you draw from the large pool otherwise available of more paycheck-motivated programmers who may or may not have a strong grasp of conceptual underpinnings of programming languages.

jerf 5y ago

"Lisp doesn’t really have many, if at all, super weird concepts that need months of thinking about in order to understand." I don't think we can have both that and the traditional "Lisp is a great language to learn to expand your mind." "Training seems like some lost art as we collectively move toward a more disposable programming ethos." Speaking as an engineering lead, my problem is increasingly not that I have an unwillingness to train, but that I need to do something other than train; that is, I need to exploit the training to get some real work done at some point. On my team, to be a fully functional member already requires fluency in 4 general purpose programming languages, 2 devops langauges, all the misc other details needed like SQL knowledge that I could hardly even enumerate off the top of my head if I wanted to, and the associated system knowledge for half-a-dozen systems as to how they are deployed, how to fix them, etc. Bringing up a fresh college grad who happens to have zero of these could be the work of plural years already. I compare this to what was required in my first engineering job in ~1997: One programming language (VBScript), basic SQL, and "fluency" in HTML that today would be considered "basic" HTML, and with that we had everything we needed at the time. Adding things to the stack was easy to justify back then. It's harder now. If you want to add another language to the pile, I'm going to need you to have a darned good reason beyond "It's a good language" or "But I like it". 2 weeks is an absurd underestimate for obtaining Lisp fluency, by the way. Surface syntax understanding and the ability to build something someone else already built, sure, but learning the libraries, the existing code base, the other quirks (especially in a language like Lisp that is all but made out of quirks if you start using the language well), there's no way that's two weeks. It's not that I'm not open to languages, it's that even on my own personal team I can't afford to have everyone drag in whatever language they want to use for some task. It's not a coincidence that so many companies end up with the Approved Language list. Smarter companies with such a list will have a way to get specific exemptions and make it not too hard to get them for good reasons (e.g., if your list is C++ and Javascript one has a good case for adding Python for an ML or NumPy project), but if you let everyone drag in whatever language they like you'll end up with enforced fragmentation of teams and significant difficulties with bringing new developers up to speed in positions where they have to become fluent in perhaps literally 10 general purpose languages to function fully.

Zababa 5y ago

> Training seems like some lost art as we collectively move toward a more disposable programming ethos. I think you're right on that, and that is damaging for Lisp. These days most training seems to be done by external sources, for example Pluralsight, Udemy, medium articles about how to do a specific things, etc. Since those have commercial incentives, they target the biggest audiance, which is usually JavaScript, Java, Python, or something like that. On the other hand, the companies don't want to train people in a specific language, so they hire people that already know their language. That creates a positive feedback cycle that makes less used languages even less used. Same thing about open source contributions (tooling, libraries, etc). I think the insistance on Emacs may also be damaging because it's an even bigger barrier of entry.