Stai toccando la differenza tra un DSL esterno (una lingua separata con la propria sintassi e semantica) e un DSL interno (un modo per progettare creativamente un'API in modo tale che utilizzarlo sembra un linguaggio diverso, anche se in realtà è ancora legato dalla sintassi e dalla semantica del linguaggio "host").
A volte sentirai anche il termine DSL incorporato per quest'ultimo (e più confuso lo vedrai abbreviato come EDSL ) e solo DSL per l'ex. Questa è fondamentalmente una differenza culturale, ad es. la comunità Ruby utilizza la terminologia DSL interna / DSL esterna, mentre la comunità Haskell utilizza la terminologia EDSL / DSL. Tuttavia, trovo il termine DSL incorporato ambiguo, perché suona più come un linguaggio incorporato in una lingua diversa, ad es. come le regex sono "incorporate" in Perl o LINQ è incorporato in C♯.
Per quanto riguarda la tua domanda in cui il confine è ... Credo che non ce ne sia uno. Ogni lingua è un'API e ogni API è una lingua. La "migliore" è un'API, più "lingua-y" si sente. Progettazione di API è design della lingua.
Questo è particolarmente vero per OO: se torni alla visione di OO di Alan Kay, è strongmente ispirato da ciò che in seguito sarebbe diventato ARPAnet e poi Internet. I computer (oggetti) che sono separati (incapsulati) gli uni dagli altri e hanno una propria memoria privata (variabili d'istanza) comunicano tra loro inviando messaggi (chiamando metodi virtuali). In effetti, ha persino usato il termine "messaging" per quello che oggi chiamiamo "virtual method call", e l'API di un oggetto è ancora chiamato il suo "protocollo", di solito in modo informale, ma in Objective-C ad esempio anche come lingua caratteristica.
Quindi, la metafora e la terminologia della rete sono profondamente radicate nel pensiero di OO. Nelle implementazioni molto iniziali di Smalltalk, non c'erano nemmeno metodi (o oggetti). C'erano flussi di messaggi che fluivano attraverso il sistema, e questi flussi sono stati analizzati, interpretati, riscritti e reindirizzati. Poi, sono emersi un paio di schemi: 1) ci sarebbero stati gruppi di "cose" strettamente correlate nel "mare dei messaggi", questi più tardi diventarono "oggetti", e 2) c'era un modello particolare in cui l'inizio di un messaggio denotava alcune serie di azioni enumerate e il resto del messaggio parametrizzava quell'azione, che in seguito divenne "metodi" e "messaggi".
Nota, come ho parlato di analisi e interpretazione dei messaggi sopra? Non sembra un'implementazione linguistica? Possiamo infatti interpretare ogni oggetto in un sistema OO come interprete per la sua lingua!
Nota, comunque, che la tua API in realtà non sembra affatto "lingua-y". Mentre dicevo che ogni API è una lingua (e viceversa), c'è ancora la questione se sia comunemente riconosciuto come tale. Se si pensa a Rake, Gemspecs, RSpec o all'API Rails Routing in Ruby, ad esempio, quando le persone li guardano, vedranno intuitivamente una lingua e solo in seguito si renderanno conto che è in realtà "solo codice Ruby". OTOH, quando guardo il tuo codice, vedo C♯, non qualcosa di diverso, quindi non si "sente" come una lingua.
Quindi tl; dr
- ciò che il tuo collega intende è un DSL interno , ciò che intendi è un DSL esterno
- non esiste un chiaro confine tra API e lingua, le buone API sono progettate come le lingue
- le lingue sono profondamente radicate nella trama di OO, gli oggetti sono essenzialmente degli interpreti