At Goldman, this was the precise approach in the group I worked in. Create a DSL that prices equity derivatives. Create a DSL that handles bond math. Create a DSL that lets junior traders whip up custom swing UIs of their exposures.
One big problem with this approach is what happens when you get hit by a truck ? The programmers you hire to replace you don't want to learn your DSL, nor want to write code in some custom DSL. Its not a transferable skill. I cannot put a bullet point in my resume saying - I wrote bond math code in GS custom DSL. What would that even mean ? Maybe I just invoked some routine and it did all the bond math for me, so what specific skill did I learn other than memorizing your DSL's syntactical conventions ?
So this sort of approach doesn't work for anybody in the long run, except the DSL creator who can justifiably be very proud of accomplishing a shitload of tasks using 2 lines of a custom DSL.
You worked with bond math -- that's what goes on the resume. It doesn't matter a lot whether it was a custom DSL or a custom library in a common language. Nobody trusts your resume anyway. It just has to start the conversation in the right direction.
Whether it's good for the organization is situational. Wherever you go, new hires have to learn the codebase before they can be really effective. It helps if it uses common tools and languages, but it also helps if it is well-factored. If using a custom DSL results in much better-factored code, it can be a net win.
There are so many languages out there. It's hard to get a job by leveraging your skill in the small subset you know without passing up a lot of opportunities involving the ones you don't.
