[usrbinbash]

Good. I'll chalk that up as one of the positive effects LLMs have on the software development environment (god knows there are few enough).

DSL proliferation is a problem. I know this is not something many people care to hear, and I symphasize with that. Smart people are drawn to complexity and elegance, smart people like building solutions, and DSLs are complex and elegant solutions. I get it.

Problem is: Too many solutions create complexity, and complexity is the eternal enemy of [Grug][1]

Not every other problem domain needs its own language, and existing languages are designed to be adapted for many different problem domains. If LLMs help to stifle the wild growth of at least some DSLs that would otherwise be, then I am reasonably okay with that.

[1]: https://grugbrain.dev

[nothrabannosir]

This feels like survivorship bias. Many of those older tools seem like they were once fancy new DSLs. We just respect them now as established, because they've been around for so long. But for every one thousand awkward DSLs that didn't make it, one new tool emerged which lifts software development to a new level.

Would you say the same about a parallel universe where LLMs were introduced in 1960?

[usrbinbash]

> Many of those older tools seem like they were once fancy new DSLs.

I think no one ever called Python or C or Rust, or Java or Go a "domain specific language".

> We just respect them now as established, because they've been around for so long.

No, we "respect" them because they are general purpose languages that you can do anything with.

> But for every one thousand awkward DSLs that didn't make it, one new tool emerged which lifts software development to a new level.

Please, do list some DSLs that managed to "lift software development to a new level". And again: A General Purpose Language is not a DSL.

[nothrabannosir]

I wasn’t talking about gp languages at all. I’m not the one to whom you need to repeat that ;)

- Makefiles

- regular expressions

- m4

- awk

- sed commands

- jinja templates

- jq

- nix

I have a love-hate relationship with many of these but I sure am happy that they tried. Whatever sucks about them is improved by an even better language, not by regressing to just using general purpose languages everywhere.

PS I put awk in there because you’re not the boss of me. It’s a dsl for text manipulation which happens to be Turing complete. If you write any serious program in awk that isn’t some form of text manipulation, it will make the front page of HN, that’s how rare that is. And to TFA’s point: awk excels at the niche for which it was developed—in a world where LLMs came before awk, it would be very hard to get awk off the ground. That is a net loss. That is the point of TFA.

You’re not wrong about the cost. But you’re wrong about the benefit.

[usrbinbash]

I think we're talking past each other. You may notice that I haven't condemned DSL in general. I condemn coming up with a DSL when using GP-Language would suffice as the easier solution.

And not to put too fine a point on it, but I have seen many awk scripts, elaborate sed-constructs (I refuse to call them scripts) and jq expressions, that would have been a lot simpler, easier to understand, and easier to maintain, if someone had just sat down and rewrote them in Python, or even in Go. They have their uses, but when people start developing what can be called a small application in a DSL that happens to be turing complete, they should just use a real programming language.

The same goes for many of Makefiles btw., some of which resemble an exceprt from the Necronomicon more than they do build instructions.

And btw. "survivorship bias" doesn't fit what's happening here at all, because the only reason we still use sed, or awk, is that they proved useful for a long time, where many other DSL did not.