5 ms·

> Few people are excited about both monads and macros; only one person that I know comes to mind. I don’t understand what the article is trying to convey. Ever

> Few people are excited about both monads and macros; only one person that I know comes to mind. I don’t understand what the article is trying to convey. Everyone in the PL community know about monads and macros but they are tools and people are rarely excited about tools. The article seems to have a strong Haskell user bias. For example, both using macro and monads is very common in Ocaml. JaneStreet, the company which uses Ocaml the most, uses both extensively. Ocaml provides advanced macro functionalities (called ppx rewriters) and let-binding overloading to make writing monadic code easier. There is no opposition between these two functionalities.

maxiepoo 5y ago
Exactly, Haskell's "do" notation is essentially defined as a built-in macro, so if you ever want to use "do" notation in a language that doesn't have it built-in you will need to use macros. (Let-binding overloading is essentially do notation in case that's not clear)
- tromp 5y ago
  do is more syntactic sugar for >>= (monadic bind) than macro. E.g. do s <- readLine "Enter name:" putStr $ "Hello, " ++ s reduces to readLine "Enter name:" >>= (\s -> putStr $ "Hello, " ++ s) But I agree you can use macros to implement syntactic sugar.
- marcosdumay 5y ago
  Macros are way more powerful than binding, for both the best and the worst. Yes, you can use macros to add do-notation to a language. But you can also use macros to add things like type checks and new conditional statements. You can't add those with do-notation.
- whateveracct 5y ago
  "do" is also no longer hard-coded. There are multiple language extensions that allow you to change what it desugars to, which is really cool.
avgcorrection 5y ago
> I don’t understand what the article is trying to convey. Lispers are from Mars and Haskellers are from Venus. That’s it.
isaacimagine 5y ago
As a compiler engineer, I get excited about tools. I think it's important to use mathematical foundations in a way that is both intuitive and transparent to the end user. Aside from monads and macros, OCaml remains a great example in this area because of its support for type inference and type annotations; on the surface, the code you write is mostly 'untyped,' save for at function boundaries and data definitions. Much how like monads and macros ultimately compile, so will correct typed and untyped code. I'm not sure how clear I'm being, but in essence: tools should be as lispy on the surface as possible (for ease of prototyping), while being built on haskelly* foundations (for correctness). There is no one silver bullet, it's about finding the right balance for the issue at hand: and as a tool, you should leave that decision to your end-users. *I use lisp and haskell to mirror the article, but this is true of any tool, imperative or functional, language or otherwise.
- Zababa 5y ago
  Speaking about OCaml too, OCaml throws away the types after the typechecking, so in a way you could even argue that the types themselves are a form of macros over the untyped lambda form, which sounds pretty close to Lisp. The dichotomy of Lisp and Haskell is a false one. Maybe the dichotomy would be better as "static" vs "dynamic", but about the language/runtime, not the typing. For example, in Lisp, you have REPL-driven development, where you know errors will happen but you can easily correct them, while in Haskell you try to minimize the errors with the help of the compiler and once the system is done you usually have to recompile it.
  - isaacimagine 5y ago
    To that end, there are type systems in some languages (turnstile in racket comes to mind) that are implemented entirely using macros. Turnstile isn't enough to model certain type systems (for reasons too complex to reasonably cover here), but it's interesting to see that types-as-macros-over-the-untyped-lambda-form has been done to a reasonable degree of success.
Zababa 5y ago
> Everyone in the PL community know about monads and macros but they are tools and people are rarely excited about tools. I don't think that's true at all. Considering how much we hear about monads and macros compared to how much they are actually used, people are excited about them. People are excited about their tools, as they should be. There's this narrative that some people push on Hacker News that we are all some kind of cool rational engineers and that we don't act like other humans. This is absolutely wrong. People get emotional about tools all the time. This is this excitement that drives progress. Someone got excited about error messages, and now there is an industry-wide movement to improve them. This could have been done decades ago, but it wasn't because people just learned to live with their shitty tools. While in the day to day life of a project you need people capable of doing the less-exciting stuff, usually at the beginning of something you need people excited to give birth to it.
- WastingMyTime89 5y ago
  > Considering how much we hear about monads and macros compared to how much they are actually used That’s users. That’s not what I meant by the PL community. I was talking about people actually working on PL. Monads and macros are both old news and not particularly exciting. I know they regularly crop up on HN. I find that a bit sad because actually exciting things happening in PL like effect systems rarely do.
  - Zababa 5y ago
    That's fair. I've seen a few mentions of Koka and OCaml 5.0 is going to have effects, though both are relatively niche. I was expecting to hear more about linear types too, I feel like one or two years ago (relatively) lots of people were talking about them, but I haven't seen much coming out of it.
  - auggierose 5y ago
    I've been hearing about effect systems for a long time (decades ?) as well. I don't find them exciting at all. You kind of counter your own argument ...

maxiepoo 5y ago

Exactly, Haskell's "do" notation is essentially defined as a built-in macro, so if you ever want to use "do" notation in a language that doesn't have it built-in you will need to use macros. (Let-binding overloading is essentially do notation in case that's not clear)

tromp 5y ago
do is more syntactic sugar for >>= (monadic bind) than macro. E.g. do s <- readLine "Enter name:" putStr $ "Hello, " ++ s reduces to readLine "Enter name:" >>= (\s -> putStr $ "Hello, " ++ s) But I agree you can use macros to implement syntactic sugar.
marcosdumay 5y ago
Macros are way more powerful than binding, for both the best and the worst. Yes, you can use macros to add do-notation to a language. But you can also use macros to add things like type checks and new conditional statements. You can't add those with do-notation.
whateveracct 5y ago
"do" is also no longer hard-coded. There are multiple language extensions that allow you to change what it desugars to, which is really cool.

avgcorrection 5y ago

> I don’t understand what the article is trying to convey. Lispers are from Mars and Haskellers are from Venus. That’s it.

isaacimagine 5y ago

As a compiler engineer, I get excited about tools. I think it's important to use mathematical foundations in a way that is both intuitive and transparent to the end user. Aside from monads and macros, OCaml remains a great example in this area because of its support for type inference and type annotations; on the surface, the code you write is mostly 'untyped,' save for at function boundaries and data definitions. Much how like monads and macros ultimately compile, so will correct typed and untyped code. I'm not sure how clear I'm being, but in essence: tools should be as lispy on the surface as possible (for ease of prototyping), while being built on haskelly* foundations (for correctness). There is no one silver bullet, it's about finding the right balance for the issue at hand: and as a tool, you should leave that decision to your end-users. *I use lisp and haskell to mirror the article, but this is true of any tool, imperative or functional, language or otherwise.

Zababa 5y ago
Speaking about OCaml too, OCaml throws away the types after the typechecking, so in a way you could even argue that the types themselves are a form of macros over the untyped lambda form, which sounds pretty close to Lisp. The dichotomy of Lisp and Haskell is a false one. Maybe the dichotomy would be better as "static" vs "dynamic", but about the language/runtime, not the typing. For example, in Lisp, you have REPL-driven development, where you know errors will happen but you can easily correct them, while in Haskell you try to minimize the errors with the help of the compiler and once the system is done you usually have to recompile it.
- isaacimagine 5y ago
  To that end, there are type systems in some languages (turnstile in racket comes to mind) that are implemented entirely using macros. Turnstile isn't enough to model certain type systems (for reasons too complex to reasonably cover here), but it's interesting to see that types-as-macros-over-the-untyped-lambda-form has been done to a reasonable degree of success.

Zababa 5y ago

> Everyone in the PL community know about monads and macros but they are tools and people are rarely excited about tools. I don't think that's true at all. Considering how much we hear about monads and macros compared to how much they are actually used, people are excited about them. People are excited about their tools, as they should be. There's this narrative that some people push on Hacker News that we are all some kind of cool rational engineers and that we don't act like other humans. This is absolutely wrong. People get emotional about tools all the time. This is this excitement that drives progress. Someone got excited about error messages, and now there is an industry-wide movement to improve them. This could have been done decades ago, but it wasn't because people just learned to live with their shitty tools. While in the day to day life of a project you need people capable of doing the less-exciting stuff, usually at the beginning of something you need people excited to give birth to it.

WastingMyTime89 5y ago
> Considering how much we hear about monads and macros compared to how much they are actually used That’s users. That’s not what I meant by the PL community. I was talking about people actually working on PL. Monads and macros are both old news and not particularly exciting. I know they regularly crop up on HN. I find that a bit sad because actually exciting things happening in PL like effect systems rarely do.
- Zababa 5y ago
  That's fair. I've seen a few mentions of Koka and OCaml 5.0 is going to have effects, though both are relatively niche. I was expecting to hear more about linear types too, I feel like one or two years ago (relatively) lots of people were talking about them, but I haven't seen much coming out of it.
- auggierose 5y ago
  I've been hearing about effect systems for a long time (decades ?) as well. I don't find them exciting at all. You kind of counter your own argument ...