Run for the hills any time anyone says, "It's our in-house developed DSL!". It's a virtual guarantee that whatever was cooked up is some sort of insanity like JDSL.
I guess also run for the hills anytime you find a place using any non-trivial amounts of Ruby, Python, TCL, Perl, Lisp, Scala, or Haskell right (all languages where embedded DSLs are rampant)?
I've worked at places that had great DSLs (both embedded and freestanding) and awful crocks that were just the right mixture of infinite funding and no accountability. The vast majority were trying to make something like database access a little nicer for their domain. Someone who doesn't want to litter their resume with the term "DSL" might even call the majority "libraries". I've certainly seen a couple that were on the level of JDSL ("Why don't we WYSIWYG build a CMS by generating XML which can expand out into PHP"), but I've also seen "writing assembler sucks! there is no C compiler for this micro! it would be way easier to write scheme ... hey look! we have a DSL for writing ECUs". In my anecdotal experience, DSLs have been the only way to stay sane in certain domains.
I've occasionally thought of using a DSL for some business logic, presumably the best way is to at least use an existing language (like Tcl) and provide business-specific verbs in it?
Don't build a DSL for a production system, period. Production quality DSLs are for academics and/or staff engineers that have enough time and resources to build and maintain them.
I don't know about you, but I have a constant backlog of features with tons of interesting problems to solve. There are places where I could build a DSL, but I am not going to because I would inevitably build something hacky and brittle that is impossible to understand and maintain (like JDSL).
I can't build new features, and increase the value of the system if my DSL is constantly breaking the system.
So don't do it. There is plenty of functionality on the .NET and Ruby platforms for me to model the concepts and objects in the domain without the need for a DSL.
I once worked for a company that used RDF for all configuration and scripting for one of its main applications.
Instead of using one of the standard methods of encoding RDF (turtle, XML, etc.) our main architect wrote his own. Specifically, he wrote an encoding based on Google Sheets. The triples were the row header, the column header, and the cell value. There were two special tables; one containing namespace aliases and one containing an index of all the tables in the spreadsheet.
To deploy, you published a Google Sheet to the web, copied the sheet key, and pasted it into a variable in the Java code's main() function (and we had a few different main classes for a few different deployment types).
Later on, he added support for encoding RDF in XLSX spreadsheets so we don't need an Internet connection to launch the app.
Let's just say that architect and I didn't get along (and he didn't get along with a good chunk of the devs either; multiple people I worked very well with quit during my time at that company largely because they couldn't get along with him).
If you want to see it, the code is open-source (some of their content is proprietary, but there's an open-source RDF store in the public repos that has the proprietary stuff removed and replaced with demo content). It forms part of the appdapter project on Assembla [0] (but only part of it; there's other random stuff in appdapter too), and there are some sample main() functions in the friendularity project on Asssembla [1] (friendularity was our repository of open-source main classes; they mostly just import stuff from other open-source projects and wrap it in a main()). Honestly, though, I didn't touch the appdapter part of the codebase when I worked there, and it's been a couple of years since I've worked there, so I don't think I can help much with running it. I think org.friendularity.bundle.demo.ccmio (or maybe org.friendularity.bundle.launcher.oglweb) is the relevant main project, but I don't remember too well, and I think some things have been refactored since we left.
While that is probably a bad idea... it does give me a potentially good idea... using google sheets for internationalization string management... so you don't have to build a custom UI.
two-column sheets.. first sheet is "default", sheet name == lang_location and overrides... column 1, except first row, is the key, column 2 is the localized value, column 3+ unused, but can provide more context information.
It really depends. In this example they used JSON to basically create a new programming language. I know a couple of projects where a DSL is used for declarative parts of the project. For example in one projects they took one or more inputs from sensor values, applied a calculation and created a new virtual sensor output. For such highly specialized tasks a DSL can be the better option.
You could try sketching out on paper or a whiteboard what control structures you would need to pull off the DSL, and then exposing those control structures as utility classes instead of a DSL.
For example, if you are building up a queue of commands to be run in sequence with a bit of preprocessing, you might create a class that exposes: `addStep`, `preprocess`, and `run`.
At least for me, the impulse to create a DSL was always a secret desire to hide implementation details from readers so that they can see the intent of the code more clearly. Really, those implementation details are critical for maintainers to understand. Otherwise a DSL's magic is likely to hurt a maintainer when their expectations are off.
Well, I am very, very cautious when I hear "DSL" and don't hear "Lisp" in the same sentence. Most languages are not powerful enough to create full DSLs that are maintainable and actually improve something.
I've worked at places that had great DSLs (both embedded and freestanding) and awful crocks that were just the right mixture of infinite funding and no accountability. The vast majority were trying to make something like database access a little nicer for their domain. Someone who doesn't want to litter their resume with the term "DSL" might even call the majority "libraries". I've certainly seen a couple that were on the level of JDSL ("Why don't we WYSIWYG build a CMS by generating XML which can expand out into PHP"), but I've also seen "writing assembler sucks! there is no C compiler for this micro! it would be way easier to write scheme ... hey look! we have a DSL for writing ECUs". In my anecdotal experience, DSLs have been the only way to stay sane in certain domains.