3 ms·

> 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 productio

> 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.

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.