Back in the late 70's, NRL hired my company (SofTech) to figure out why software for its AN/UYS-1 signal processing computer was so expensive and so bad. I was technical director of the DC office and project lead. We discovered that the acoustical engineers specified the software by drawing data flow diagrams where the nodes were mostly a standard set of operations like "FFT," "Bandpass Filter," etc. Those diagrams would be given to a roomfull of programmers who would laborously convert them into sequential SPL/1 or CMS-2 code by essentially ripping the functionality apart and re-assembling it in a "crystal clock architecture."

My big idea seems pretty obvious now, but was radical then: create an engine that will run the dataflow diagrams. We wrote a parser to convert the diagrams into an internal form and an interpreter to run it on the UYS-1. Worked like a charm; we took a diagram that (ahem) IBM had spent several tens of millions of 1970's dollars converting into code and got it running in about a month with five programmers. Believe it or don't, our implementation was slightly faster. Long story short, the Navy specified that the next generation of signal processors, the AN/UYS-2, be designed (by Bell Labs) as a dataflow engine at the hardware level. That machine and that architecture are still in use today.

So that's an example where a highly-specialized programming language was the right solution, if you're willing to call dataflow diagrams a programming language. Note, though, that we eliminated the programmers.