That second link is pretty good as a rant, but I don't find it very good as an argument.
The whole argument about macros as a replacement for "static higher order programming," which is supposedly better than "dynamic higher order programming," which evidently nobody needs, was lost on me. He also seems to be saying, though, that "dynamic higher order programming" does not include closures, so I really don't know what it is. If a closure is anything, it is certainly a function created at runtime.
He also seems to say a function composition operator is obviously bad, without any justification. I guess if justification were required, it wouldn't be obvious. I don't see the clear advantage of carrying around a data structure with multiple functions and a third function that composes them, versus just using a compose operator. I suppose it's a little more opaque, but that is often a good thing (a kind of encapsulation).
"Of course, it may be slightly easier to optimize the result of dynamic code generation"
But maybe it's a lot easier? Can we get a huge speedup, or just a little one? I have no idea, because he doesn't say, and it's not even clear if he knows.
"Whatever problem we are solving by constructing h(x), it is probably better solved by a macro, which would perform the same composition statically."
I highly doubt any serious Lisp programmer agrees with this statement. Dynamically constructing functions at runtime is an extremely common lisp (pun unintended, but fortuitous) technique.
I have not programmed in Haskell, but reading this gives me no legitimate reasons to think it is a bad language, let alone an indictment on CS research.
Without having read his other posts it wouldn't be quite as obvious, but the author of the second link (at least in his blog persona of 'Mencius Moldbug') is legitimately insane.
His writings are crafted to shock the hell out of any socialized person, no matter their world-view. He actively despises representative democracy, functional bureaucracies, and anyone advocating policy (the state department, the NYT, NGOs, etc.). You could denounce him as a fascist libertarian, but neither of those groups would have any idea what to do with him either.
Unfortunately you'll have to read several hundred thousand words of blog-essays to even begin to understand him (and you thought Yegge was a bloviator!).
He's not insane. He's an anarchist.(Or seem to be one)
You would do well to understand an anarcho-capitalist's position regarding the incentive of government insitutions versus market based insitutions. Than it become less shocking to read his work because well, you understood where he's coming from.
As for me, I am an anarcho-capitalist myself so I am not shocked. Figures.
After reading most of his archives, I'm still trying to decide whether he's insane, or if he's sane and it's everyone else who is insane. More and more I'm thinking the latter. Perhaps I need to disconnect myself from the internet for a while :-)
The whole argument about macros as a replacement for "static higher order programming," which is supposedly better than "dynamic higher order programming," which evidently nobody needs, was lost on me. He also seems to be saying, though, that "dynamic higher order programming" does not include closures, so I really don't know what it is. If a closure is anything, it is certainly a function created at runtime.
He also seems to say a function composition operator is obviously bad, without any justification. I guess if justification were required, it wouldn't be obvious. I don't see the clear advantage of carrying around a data structure with multiple functions and a third function that composes them, versus just using a compose operator. I suppose it's a little more opaque, but that is often a good thing (a kind of encapsulation).
"Of course, it may be slightly easier to optimize the result of dynamic code generation"
But maybe it's a lot easier? Can we get a huge speedup, or just a little one? I have no idea, because he doesn't say, and it's not even clear if he knows.
"Whatever problem we are solving by constructing h(x), it is probably better solved by a macro, which would perform the same composition statically."
I highly doubt any serious Lisp programmer agrees with this statement. Dynamically constructing functions at runtime is an extremely common lisp (pun unintended, but fortuitous) technique.
I have not programmed in Haskell, but reading this gives me no legitimate reasons to think it is a bad language, let alone an indictment on CS research.