I would also argue that for both types of DSLs, language isn’t a tool for modelling the domain, rather it is a tool for communicating it. For me, this is one of the fundamental differences between DSLs and APIs; the intention is communication of functionality rather than the definition and modelling of it.

I agree. IMHO, “Standard Procedural” is a better choice for “Idiomatic Java”.

I’m sure I can come up with something better than that…

To some degree, this reminds me of the difference between what is considered “bad” inline comments and “good” inline comments. One describes what you are doing, while the other describes why. And so, “Expressive Design” eliminates the need for even the latter category.

It’s also a bit of the hunt n’ peck style of Java: Ok, how do I do this? Now, what’s the next command I need? Now how do I create an attachment? Looks like the developer is trying to figure it out as they go along, like they’re reading it out of a Java-in-21-days book. If I were a driving instructor, I’d tell them to “Aim high in steering”.

In that sense, in my reading, the term didn’t add noise to your presentation.

I think what might be missing in the term is the crucial distinction between business idioms and Java or object oriented idioms. This would clearly separate semantics from syntax, purpose from tools and value from noise.