Chris Seifert wrote:What sort of justification can a programmer provide to their company that a DSL is in order? What sort of problems cry out for a DSL? What would be some of the things that an average programmer would get out of spending time with your book? What should we try to use the book for?
Terence Parr wrote:
Unfortunately, I have bad tendinitis from writing software for 30 years. I began writing the book by first implementing a DSL that was extremely terse in order to reduce the keystrokes I needed to write the book. ... So, in summary, think DSL when you see or feel repeated pain
Burk Hufnagel wrote:I get the idea that DSLs can make programmers more productive, but I still don't see where the balance point is. If I write something difficult/tedious and need it in another place, I make a function out of it so I can reuse it. If there's a lot of related code then it becomes a library or API. When should it become a language?
David Newton wrote:It also depends on what your definition of a DSL is; some DSLs are just fluent APIs..
David Newton wrote:That's what I'm saying--some DSLs are just fluent APIs. In languages that support "natural"-looking DSLs it's not always obvious it's "just" API calls, although most would let you add the verbosity that would make it obvious.
Terence Parr wrote:To use an API you must use a language, typically a general-purpose programming language. So, in my view, using a library wouldn't really be using a DSL, though you can often make the method call syntax looks sort of like the target domain: a = b.plus(c).
Keith Flo wrote:The bottom line is ... I need to check out your book!
I will suppress my every urge. But not this shameless plug:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koophttps://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton