My store-code-as-a-database plan is not an original one, and it wasn’t even original years ago when I first started thinking about it - something like Apple Dylan was doing a version of it ten years ago, based no doubt on earlier work by others.
It’s amazing, however, how few people are doing it today. I’m not entirely sure why, but I think it’s a mostly a problem of inertia.
As programmers we invest an awful lot of time in learning to use our tools well. The good programmers do anyway - the lazy ones who just learn enough to enter code and compile it tend to be just as lazy when it comes to designing and implementing code, and about learning more about their craft in general; which I guess is what stops them from being good programmers in the first place.
This investment really bumps up the cost of moving to a new coding environment. It’s hard to justify switching from tool A to tool B just for one or two new features, if it means that you’re going to have to relearn a bunch of stuff that you currently feel very comfortable with. Even when those features are really cool and you can see the massive long term benefits.
And even if we are brave (foolish?) enough to switch to a new IDE/framework/language, most of us have to work with other people, who aren’t so brave, or have their eyes on other short term goals. So most of the “day job” work tends to stay being done with what we know, which of course increases the amount of time and investment in that environment, and reinforces the whole problem.
I don’t think that there are any easy solutions to this, but I guess it does illustrate that any new programming environment which goes down this path needs to do it’s best to support interoperability with existing tools (and by extension with colleagues who are still using them).
I suspect that what this means, perhaps, is that we have to start by creating an environment which acts as a kind of glue to tie together existing stuff, rather than starting from scratch.
Much as I’d like to build something which worked with a nice shiny new dynamic, reflexive, introspective, all-object language, maybe I’d be better off working out a way to wrap up C++ and Java in XML.
Much as I’d like to force everyone to use my system, perhaps I’d better figure out a way to get raw C++ files in and out of the system intact.
Much as I’d like my new tool to act as a it’s own version control system (each code block is an object in the database, so you can do seriously fine-grained version control), perhaps I’ll have more joy if I make something that just works with subversion.
Much as I’d like to make something that allowed truly collaborative programming, maybe I should just make the thing play well with SubEthaEdit!
All of this goes against the grain for me, in the sense that I have some sort of unformed idea in the back of my head of what this new system will be, and whilst I can’t quite figure out the exact shape, I know that it’s supposed to be clean and elegant, not a kludgy mess of glue on top of old tools.
Going down the interoperable route is probably more realistic though, and more achievable. If I start with stuff that already exists, I might even get something working within my lifetime…