I like that the author points out that trying to write a new interpreter is not a good idea. However, to call that DDD, and then to say DDD is a lie is where I would disagree. I guess one could say that it's DDD taken to some extreme, but I would just call it a poor choice as the author points out.
One thing I don't love about the book though is that it tries to demonstrate how to do DOP with Object-Oriented languages, which looks to be difficult to accomplish
It's definitely not over. I got into it professionally in 2018, and have remained employed with it at three different companies. There's turmoil around it because startups use it with great success, but then as they want to scale they have a hard time finding enough devs to throw at their new ideas.
> [Clojure] is really optimized for [\snip] data centric stuff
Not sure what this means. Stu Halloway made a comment to the effect of "all programming is ultimately data transformations". Honest question here, what programming language is NOT for data-centric stuff?
I find that when I'm working in verbose programming languages: Java, C#, it doesn't feel like all programming is data transformations, when in reality it is.
Funnyduck99 is probably mocking all the people that go into HN posts about Clojure to complain about how their team of non-Clojure programmers went to work on a Clojure project and it was a bad experience.
Interesting point. I've recently taken on a client who insists on using C# with their cloud solution. It's killing me. Though you're calling Clojure "advanced", what I'm missing is its simplicity.
What kind of differences/limitations are there when interpreting Clojurescript (nbb) as opposed to compiling it (shadow-cljs, lein, self-hosted?, other things?)?