I'd argue that before one can become a 'specialist' that you should first become a 'generalist'. I would consider myself a generalist - I'm primarily a C# - ASP.NET MVC developer.
But that doesn't stop me from writing WCF services, web services, using message queuing (MSMQ but I prefer RabbitMQ with MassTransit nowadays) or writing T4 templates or custom code generators. I generally do website design (I have worked for a branding/design company previously where I designed websites based on graphic designers' slicing) that includes your typical front-end stuff like JavaScript/CSS with some pre-processing (SASS, Less, CoffeeSCript), AJAX and web sockets.
I would consider myself a 'full-stack' engineer because I am generally responsible from writing everything from the front end to the databases and integration. I consider things like design patterns, wiring up IOC containers, applying SOLID/GRASP principles (ex. abstracting components to minimalize the need for change), managing project timelines, planning and estimates a daily ritual. All my projects use either a N-Tier or a DDD approach.
I have also toyed with a multitude of programming languages and frameworks outside of my scope of 'specialisation'. I'd hence argue that becoming a good programmer would requiring you to become good across the board (and at things outside the scope of the project - ex. I apply similar approaches to what I've learned from writing Scala/Python/Haskell).
I wouldn't consider a programming 'specialist' the same as a domain expert.
You definitely need to acquire domain knowledge to be efficient at what you do, but you shouldn't need to be considered an industry expert. I've only seen bad things happen when programmers are left to make decisions that require domain knowledge because there are no real domain experts around.