“Investing a large amount of resources into creating a tool or language to simplify a particular problem never makes much economic sense precisely because the problems that exist today are never the problems that exist tommorow [sic].” — ocean
No. This is just completely wrong.
In the first place, I’d just like to ask why we have all of this mind numbing unceasing tech churn? Evidently there is some economic sense to this whole language/tool creation thing. I mean… even the obvious examples like Java, VB, Erlang, XML, NAnt, SubVersion, etc. should settle this. To be a software developer is to be in a constant state of assessing and evaluating tools. This is about as “mucky” a problem as they come, and where there’s muck there’s brass… so there’s an entire industry striving to meet this need.
But maybe I’m taking ocean’s remarks out of context here. Let’s blur our vision for a second and pretend that all the holy wars and competing tool sets have gone away. All we’re left with is just a typical man on the street developer trying to keep up with a huge number of change requests and bug reports. Here’s a snippet from a random job posting:
“Creating web application ordering systems for many different clients (each client has a unique ordering process) -All new development work is in C#, dozens of existing applications are in Visual Basic .NET -Candidate must be able to switch between languages without issue.”
What are we going to tell the guy that ends up with that job? “Hey, we can’t wait to have you here. We’ve got so much to do. But look man, we know we’ve got 50 web pages running here that have a lot of the same code, but don’t even think of making a code library to share between all of the projects. We tried that once and it just didn’t work.”
Are we going to look over the guy’s shoulder and randomly pipe in and say, “Hey… stop that. We decided last year that refactoring was a waste of time. Take all of those carefully named subroutines and pack them all back into one giant procedure like we had it before.”
Are we going to cry “foul” if he starts coding up a macro for his text editor?
I suppose we should fire him if he starts working up framework or a templating system to use as a basis for all of his “store” projects. And if he even toys with the idea of a human readable custom scripting language for handling certain triggers or events we should go ahead and just burn him at the stake.
Shoot, to be consistent, let’s ban OOP. A sufficiently sophisticated object model starts to look like a language anyway… let’s outlaw the use of the .Net framework as far as we can.
Okay. Alright. We’re not going to do any of that stuff. We’re not going to just randomly start banning the nuts and bolts of basic software development. Of course there’s an entire strata of developers that will never develop their own object model to solve a problem– even though they spend all day poking around in other people’s object models. There’s an even larger strata of developers that will never make up their own language to solve a problem– even though they might need to learn a dozen just to work a lame web project. But just because we aren’t comfortable with metalinguistic abstraction, it doesn’t mean we need to shoot down anybody that wants to explore its possibilities. And at some point, there were folks that had some computing problems and then wrote C and awk in order to get around them– so by definition, a new language/tool has to be the right answer sooner or later.
But if you look back at that job posting and think about it… that’s almost exactly the same problem that Paul Graham solved back in the eighties working on what became Yahoo Store. It’s ten years or more and we’ve still got pretty much the same sorts of problems. And if you’re in the business of solving a certain class of problems, you’ll want more of them, too. Why not invest in developing tools/frameworks/languages that can help you manage more problems with less effort? Why not continue investing in those tools so that you can expand the scope of the problems that you consider trivial? If you insist on working crappy development projects, you’re sure to get away with it for a time. But somewhere, someone is working on the tools that will make most of your painstakingly crafted custom solutions irrelevant. They are doing everything they can to make it easy for the people that write your paycheck to ditch you and move to their system.