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.