JSX would be an (early) example of this class of language. XML is equivalent to s-expressions. So React.js (drunkly) is just a reactive language embedded in a normal language with seamless ability to hop between them. I elaborate about this equivalence here https://www.reddit.com/r/Clojure/comments/mavg81/the_distinc... . The brilliance is they did this so smoothly that nobody noticed, and with dynamic types, and without the typed people even noticing!

The elephant in the room is Babel, which is essentially a macro processor for JavaScript.

React is not a "reactive language", and JSX is an abomination, so I'm not sure this is a rebuttal to the GP's "this sounds horrible" point.

Imagine starting a job as a closure dev and being told you have to learn a new language with substantially different semantics

Everyone is doing it already, to a large extent. Where "an API" ends and "a programming language" starts is a matter of opinion. It's a fuzzy boundary.

I think it really comes down to how well the new semantics fit the problem domain. If it's a much better fit than the alternative, it's a net win. But just because you can define new semantics, doesn't make it a good idea.

This is Nathan Marz we're talking about though; he's on the short list of people who can both accurately identify the need and create something workable to fill it. If he told me it was necessary for a particular problem domain, I (personally) would think long and hard before I disagreed.

Different semantics for different folks. For me, this sounds interesting. I'll defer judgment until I learn more.

> Actually this sounds quite horrible.

You understand the use case well enough to criticize it?

I can only guess regarding the use case. I still can make a statement that I personally do not think that the coolest part of a codebase should be a new general purpose language at its foundation. To me this reeks of not invented here syndrome, inner-platform effect and KISS "violations". IMO when you provide new tooling you want your developers be able to stand on the shoulders of giants and let them choose the fights they want to fight. Idiomatic programming is very helpful in this regard. When programming new languages with macros is idiomatic in Clojure so be it, but I doubt that.

None of the smells you mentioned are anywhere close to absolutes.

Of course, that is the nature of the concept.

I have dabbled in Clojure and Julia, and both of them support macro to make it easier to develop DSL looking syntax. I have always wondered how difficult it it to debug macro heavy code - where's other language cite 'no macro' as a feature such as Zig.

> I have always wondered how difficult it it to debug macro heavy code

It isn't much harder than regular core. `macroexpand' is your friend! Particularly when wrapped by your IDE[0] into a "macrostepper" tool, which lets you macroexpand into an overlay[1], step by step.

Ultimately, macros are just functions - if slightly peculiar ones (they receive unevaluated arguments, and their return values are treated as if they were the code at the point of invocation). You can unit-test them just like any other function.

That's not to say there aren't macros that are very tough to debug. But the problem isn't macro-heavy code, as in code containing a lot of macros. The problem are heavy macros - monstrosities with complex internal logic, expanding their inputs into large amount of code generation, hidden state, etc. Complex macros like these take skill to write[2], but they're also rare to see.

--

[0] - By which I mean Emacs, though I guess there are Clojure IDEs now too.

[1] - I.e. a read-only view replacing the code you're macroexpanding on screen.

[2] - First rule: minimize the amount of code within the actual macro definition, move all logic into functions to be called by the macro, and unit test those extensively.

In my experience with Julia it's no easier or harder than any other code. Macros tend to be pretty transparent, and it's easy to see what code they generate, although I've never had to do so. Most of the time, a library with a macro-based DSL (e.g. JuMP) has a function-based DSL underlying it that's just more verbose.

I kind of like Rust's version: macros are limited and clunky (and really clunky if you want to do anything super fancy), which means they're available, but I only end up using them when they're really necessary (like I'd be copying and pasting huge amounts of code and there's no other way to avoid doing that)

I concur. I think it's nuts when companies do this. There's another well know SaaS that basically invented their own language but I can't recall who. It's the ultimate ego food for the lead engineer imho.

what a company needs is good leadership at every level. not unique tools, and not "10x engineers".

Are you thinking of https://www.joelonsoftware.com/2006/09/01/wasabi/ perhaps?

oh yeh that's it!

a complete head case, nevertheless he's a million times more successful than I so perhaps I'm the one who's nuts.

> I think it's nuts when companies do this.

This can go either way. Yes, it can be abused. DSLs can be very useful and powerful.

In any case, I think it is better to not to rush to judgment for this particular case.

I would claim in most cases it is abused. Beside that I criticize the sentiment not the execution.

If you disagree please explain your perspective...