7 ms·

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 s

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.)
  - dwohnitmok 5y ago
    > 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. Nah you do need to know about them, otherwise you won't understand a bunch of weird errors in your program (e.g. hmmmm... why does (reduce or my-collection) blow up?). I agree you don't need to know much about them. Really a novice Lisp programmer just needs to know, "don't use macros in anything that isn't a first-order construct, otherwise just treat it like a normal function," and that'll get them pretty far. But that's, as you say, really just the same difficulty as "sort of parroting these operators for specific class instances of interest, like IO and Maybe." And to understand one more level further down is really easy in both cases if you have any amount of hand-holding by an experienced mentor.
    - bjoli 5y ago
      if you have an error with macros you can just expand them. Very few macros expand to more than 5-10 lines (loop being an exception).
      - dwohnitmok 5y ago
        Yes if you have problems with macros there are ways of debugging them. My point (in reply to reikonomusha) was simply that you do need to know about "the machinery of macros" and certainly their existence to do day-to-day programming in a Lisp.
lmm 5y ago
> 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. You need to know what the macros a given codebase uses do if you want to work in that codebase. This is actually a worse situation than in Haskell, where if you're comfortable with monads in general you can probably be productive in a given codebase without knowing about the specifics of the monads that codebase is using.
- reikonomusha 5y ago
  It’s not “actually” a worse situation except in some pathological academic sense. The point of a macro is to make some idea clearer to understand by way of syntax. If it’s not doing that, it’s probably a bad macro.
  - lmm 5y ago
    If you restrict yourself to a reasonable-to-understand subset of possible macros - such as those that could be expressed as monads in Haskell - then a reader that knows that you've so restricted yourself can work in your codebase without understanding all your macros (as long as you don't have any bugs in your macro implementations). But in that case why use a language with macros?
    - aidenn0 5y ago
      You can teach someone to use the built-in loop macro without using the term "macro." It's far more hairy and complicated then any non built-in macro you will encounter in the wild. Literally the only time I worry about macro vs special operator vs function is when doing higher order programming, which is less common in lisp than Haskell
      - lmm 5y ago
        You can teach someone to use a fixed set of macros. But again, in that case why use a language with macro features? If you're never going to use a non-built-in macro with the complexity of the built-in macros, why does the language need this complex macro system rather than a set of built-in keywords and a simpler extension system?

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.)
- dwohnitmok 5y ago
  > 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. Nah you do need to know about them, otherwise you won't understand a bunch of weird errors in your program (e.g. hmmmm... why does (reduce or my-collection) blow up?). I agree you don't need to know much about them. Really a novice Lisp programmer just needs to know, "don't use macros in anything that isn't a first-order construct, otherwise just treat it like a normal function," and that'll get them pretty far. But that's, as you say, really just the same difficulty as "sort of parroting these operators for specific class instances of interest, like IO and Maybe." And to understand one more level further down is really easy in both cases if you have any amount of hand-holding by an experienced mentor.
  - bjoli 5y ago
    if you have an error with macros you can just expand them. Very few macros expand to more than 5-10 lines (loop being an exception).
    - dwohnitmok 5y ago
      Yes if you have problems with macros there are ways of debugging them. My point (in reply to reikonomusha) was simply that you do need to know about "the machinery of macros" and certainly their existence to do day-to-day programming in a Lisp.

lmm 5y ago

> 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. You need to know what the macros a given codebase uses do if you want to work in that codebase. This is actually a worse situation than in Haskell, where if you're comfortable with monads in general you can probably be productive in a given codebase without knowing about the specifics of the monads that codebase is using.

reikonomusha 5y ago
It’s not “actually” a worse situation except in some pathological academic sense. The point of a macro is to make some idea clearer to understand by way of syntax. If it’s not doing that, it’s probably a bad macro.
- lmm 5y ago
  If you restrict yourself to a reasonable-to-understand subset of possible macros - such as those that could be expressed as monads in Haskell - then a reader that knows that you've so restricted yourself can work in your codebase without understanding all your macros (as long as you don't have any bugs in your macro implementations). But in that case why use a language with macros?
  - aidenn0 5y ago
    You can teach someone to use the built-in loop macro without using the term "macro." It's far more hairy and complicated then any non built-in macro you will encounter in the wild. Literally the only time I worry about macro vs special operator vs function is when doing higher order programming, which is less common in lisp than Haskell
    - lmm 5y ago
      You can teach someone to use a fixed set of macros. But again, in that case why use a language with macro features? If you're never going to use a non-built-in macro with the complexity of the built-in macros, why does the language need this complex macro system rather than a set of built-in keywords and a simpler extension system?