Sunday, December 16, 2007

On Practicality and Tool-Making

A comment on my last post on design and programming languages spawned the following.

Q: Are you implementing some of your ideas?

A: It's always in the back of my mind to design and implement my dream programming language. This blog is in part my outlet for ideas that come streaming into my mind about programming languages. In fact, it's my only outlet. The more specialized you get, the fewer and fewer people you can find who consciously value your field; most people don't even know it exists. Consequently, I would just love to have someone to bounce ideas between who actually has a clue of what I'm talking about.

That said, I'm not actively working on something at the moment, and I think that warrants an explanation.

Back when I started programming, I primarily liked to make things that were useful on a day-to-day basis. In making such things, I started to see patterns and got the idea of making tools to make creating them easier and quicker. That eventually led me to programming languages, the medium of expression of all software. As a result, I spent practically my entire undergraduate career studying type-theory and compilers.

To this day, I am more convinced than ever that PL design is one of the most important things to {software as we know it}.

However, given all that, tool-making can be a huge side-track. Because like all things, there is a pattern of pattern-discovery and tool-making.
  1. You use the tools you have to solve a problem.
  2. You discover patterns in the use of those tools.
  3. You make new tools that eliminate those patterns.
  4. You return to step 1 with your new tools.
But if you're like me and see patterns everywhere, you could end up spending most of your time in step 3, not step 1. Especially when you see patterns in the tool-making process and start to recurse on sub-goals. And if your ultimate goal is to solve your original problem, there's something wrong.

The bottom line is that hard work — sometimes an obscene amount of it — pays off if it's focused on your goal. And the whole tool-making branch only makes sense towards your bottom-line if {the amount of work spent making your tool} plus {the amount of work it takes to accomplish your goal with the tool} is less than {the amount of work it would take without the tool}. This simple accounting formula has told me that making compilers and new programming languages is just not worth it given my goals. The cost of making a compiler and all the tools necessary to be productive with a new language is just so high that it dominates the inequality.

This can be frustrating, especially for someone who wants to create something beautiful.

But it is a matter of practicality.

Now, this may seem like an elaborate excuse to not work on something hard and important. But to me, it is the reason why I should work on other hard and important things.

I'm not trying to discourage anyone from working on compilers or designing new programming languages. On the contrary. If your goal is to make the best programming language in the history of programming languages — a so-called hundred-year language — then by all means, work on that! Seriously, please do; we are all in need.

All I'm really saying is that everything has an opportunity cost, and you should evaluate everything in terms of your goal, whatever that may be. Sometimes that means putting aside your own desires, like the desire to make a tool. But in the end, it's worth it.

1 comment:

Luke said...

I would just love to have someone to bounce ideas between who actually has a clue of what I'm talking about.

Greetings. :-D I have many thoughts that are fairly esoteric in nature; one of the just happens to be on programming language design. I am always interested in talking about this sort of stuff.

The cost of making a compiler and all the tools necessary to be productive with a new language is just so high that it dominates the inequality.

It all depends on how many use your tool. While it might not be economical if only you use it, things change if millions or perhaps just thousands use it. Especially if others reciprocate with their own tools. I guess this is what the open source movement is about, although I think they could stand to do a lot better. For example, there seems to be little interest in a true integrated IDE, as your last post describes.

Anyway, feel free to ping me at labreuer@gmail.com for any discussion of such things. I also have some of my own ideas, such as forums, on which I would especially like feedback. I'm not a huge fan of any existing medium for intensely discussing ideas (like those you have brought up), if the goal is to produce output that can be efficiently consumed by others. I wish I could easily peruse discussions of other people's experience writing compilers, debates about them, etc. Unfortunately, this is hard to do, both to find good discussions, and to burn through all the cruft, whether it be trolling, quoting of irrelevant text, or something else.