"writing a programming language" is a rather ambiguous term. One might define a new programming language, implement one (once defined), or both.
I've implemented one twice, and defined and implemented once, and 30-so years ago. One presumes the tools needed to do this are easier to use today...
First time was a Computer Science course. We had to implement a compiler for a language that was defined by the instructor. We implemented in PL/1. (What's *that*, LOL!)
Later, I defined and implemented a new language, called VSL, or "Variation Simulation Language". I think this is a good illustration of a legitimate need for a new language. This type of usage is known today as a Domain-Specific Language, or DSL. (Though the term was not yet in use at the time.)
I was working for a company that had a product called VSA - "Variation Simulation Analysis". The had gotten rights to the product from a university professor who had implemented it on a mainframe. This had originally come out of work done at Willow Run Labratories during WWII. They had used the classic "room full of women on mechanical calculators" to do this analysis, and was certainly a contributing factor in our being able to churn-out thousands of airplanes for the war with minimal assembly difficulty.
The product has changed hands several times since then, and it still exists today, 30 years later. It's part of Siemen's Team Center Lifecycle Visualization:
http://www.plm.automation.siemens.com/en_us/products/tecnomatix/quality_mgmt/variation_analyst/
In fact, it's the most popular software used today to perform this type of analysis, and it's been used to help design just about every high-tech complex mechanical product we use, from cars to aircraft to disk drives. I have no idea of VSL is still in use "under the hood" as it's all been long-since made into visual point-and-click operation.
The problem at the time (30 years ago) was that mechanical engineers had to write models in Fortran. Fortran is cumbersome, especially when dealing with multi-dimensional arrays, and mechanical engineers don't generally write very good Fortran code. (Sorry, they are mechanical engineers, not programmers...)
So, they would write a model, then they would have to link it with a static library. (VSA was written in Fortran.) This took about 1/2 hour. (linking compiled object code took a lot longer back then - typically much longer than compiling!) Then, they would discover a mistake and try again.
What I did was a two-step process. First, I defined a simple stack-based interpreter, and implement it in Fortran. It would read a file into an array, and execute simple instructions.
Then, I defined a language specific to the task. It made it very easy to deal with the kinds of things needed for these models - points, lines, planes, assemblies, etc. - and for manipulating them, join, move, etc.
Then I wrote a compiler for VSL using C and the classic Yacc/Prep/Lex stack.
Now a program could be compiled in a short time (maybe less than a minute) and there was no need for the lengthy link step, since now a pre-compiled program could be used that just read the output from the compiler (the interpreter code) and execute it.
Programs ran quickly, because most of the time was spent in complex math-related library functions, which were all written in Fortran. The time spent in program logic (branching, loops, expressions, etc.) was minimal vs. the time spent in the math library.
Use of VSA skyrocketed after that, due to the increase in productivity - the time needed to create a model was now a small fraction of what it had been. Early uses were, for example, to move from mouting hoods using slots (and having to carefully adjust the alignment of the hood during assembly) to using simple drilled holes. Gaps around windshield glass were eliminated and trim replaced with caulking material, as the windshield opening could now be designed to be more precise. Engine pollution levels could be predicted before actually building any engines, speeding the process of complying with new emission regulations.
