My interpretation... the author is arguing against creating a new Domain Specific Language when you could just use the host language.

I haven't understood that but then again I don't really understand what the post is about.

I would agree if so with the caveats that it's all fine unless the host language lacks a lot of semantic features that the DSL will add.

Then again, I don't understand the blog post. Is it about programmable programming language?

this is the blogpost version of "could have been an email" :D thanks.

I prefer books worth reading

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.

Also I assume that the author is equating DDD with Data-Oriented Programming. Here's a good book on the topic: https://www.manning.com/books/data-oriented-programming?ar=t...

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

You're assuming wrong, they are not talking about data-oriented programming.

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.

I'm not sure about that. Python was a good 20 years old when it became mainstream

> [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.

With data I mean information, knowledge representation etc.

Not real time video games and other graphics intensive stuff. Not device drivers, embedded and hardware specific stuff. Not bits/bytes level of programming…

There are more, but you get the gist.

Clojure is fantastic for business applications, DSLs, information processing, web development and so on.

The application space is huge, but it’s not meant for everything.

I see what you mean. Well answered. I think there needs to be a fix for this... like make Clojure first class for bits/bytes levels of programming. :)

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.

No I genuinely don't like clojure because I just finished my first clojure class, it was also my first functional language and it was online and i am bad at learning online so thats why.

Sounds like any functional language would have disappointed in that case?

yup thats what i said

I hope you get an opportunity to explore it (FP, whether Clojure or otherwise) in a more conducive environment. It sounds like this wasn’t the best learning environment for you, and that’s totally valid, but there’s a lot of good stuff to learn if you’re in an environment that suits you.

LPT: While learning Clojure, the following (almost always true) mental-model help me massively at "getting" Clojure.

"It's Maps All the Day Down"

Spend a lot of time, just learning how you (CRUD) map contents.

There will be enough time to tackle the other cases/tech (atoms, protocols etc) but until you get good at maps don't get bogged down by the other cool stuff.

"It's Maps All the Day Down"

In reality - its actually Trees all the way down. But, because you don't have proper structures in Clojure, one uses Maps when one should actually be using Trees.

Lol talk about missing "the forest for the trees".

That’s a much more interesting comment than the top level one. People generally care about learning experiences and explicitly subjective statements.

too easy and too fun.

Also, to anyone interested in this problem, look for the Worse is Better paper

> It's really not a language for big team.

Not my experience, but you do need senior devs who are good at Clojure to be reviewing and helping the juniors

> if I had a tough day, my clj code will look like rubbish

This may not be a reflection of the language

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.

Maybe a better classification would be "amazing languages" vs "good enough ubiquitous languages" :)