[Haskell-cafe] Wow Monads!

Joachim Durchholz jo at durchholz.org
Wed Apr 19 07:23:01 UTC 2017

Am 19.04.2017 um 06:24 schrieb Richard A. O'Keefe:
> Someone wrote:

That was me :-)

>>>> I think Lisp-style macros are too powerful.
> It's true that higher-order functions can do a lot of the things people used
> macros to do, and better.
> However, having said "Lisp-style macros", Lisp is a tree with many branches.
> How about Scheme-style macros?

I can't tell the difference anymore, I was going through Common Lisp 
docs at one time and through the Scheme docs at another time and don't 
remember anymore which did what. I also have to say that I didn't pick 
up all the details - I was even more averse to macros then than I am 
today, so I didn't pay too much attention.

The general finding, however, was what both were very, very heavy on 
enabling all kinds of cool and nifty features, but also very, very weak 
on making it easy to understand existing code. Essentially, each 
ecosystem with its set of macros, multiple-dispatch conventions, hook 
systems and whatnow, to the point that it is its own language that you 
have to learn.
That's essentially why I lost interest: None of what I was learning 
would enable me to actually work in any project, I'd have to add more 
time to even understand the libraries, let alone contribute.

The other realization was that these extension mechanisms could make 
code non-interoperable, and there was no easy way to find out whether 
there would be a problem or not. This would be a non-problem for 
lone-wolf or always-the-same-team we-reinvent-wheels-routinely 
scenarios, but it's a closed world that an outsider cannot get into 
without committing 100%.

Java does a lot of things badly, but it got this one right. I can easily 
integrate whatever library I want, and it "just works", there are no 
linker errors, incompatible memory layouts, and what else is making the 
reuse external C++ libraries so hard.
Nowadays, the first step in any new project is to see what libraries we 
need. Integration is usually just a configuration line in the build tool 
(you don't have build tools in Lisp so that's a downside, but the build 
tools are generally trivial when it comes to library integration; things 
get, er, "interesting" if you task the build tool with all the other 
steps in the pipeline up to and including deployment, but there it's 
that the environments are so diverse that no simple solution is possible).

>>>> Problem with that is that empowering the programmer makes it harder to be 100% sure what a given piece of code does.
> This is also true in Haskell.  Show me a piece of code golf with Arrows and
> LemurCoSprockets and such all over the place and I haven't a clue.  Total
> bewilderment.

Heh, I can subscribe to that. Even finding out what Monad does took me 
far too long.

More information about the Haskell-Cafe mailing list