Musings
I've been blogging off and on for awhile now. Perhaps that is best, as I prefer to only post when I have something I feel is interesting to say. However, it has only been recently that I've gotten the itch to post about things I actually do for a living. Namely, software development.
I've been creating software for commercial use for over 20 years now, and I'm still learning new things. In fact, it is only recently that I've taken the time to learn some of the 'newer' programming languages, like PHP, Python and Ruby. That's given me a chance to muse on both the practical and philosophical aspects of creating software applications and tools. When I make the distinction between tools and applications, I'm not doing it lightly. Tool building is a vastly different process from creating applications. That's true of creating a house, a car or a computer program. Tool builders are an odd subclass of the group.
In the past, people who built houses often made their own tools for the job. The reason was simple, they knew what they needed to get the job done, and it was rare that anyone else was making tools to sell to other builders. The same can be said for the early days of software development, although it is still somewhat true. Most developers today don't want or need to know how to build a compiler, or why one compiler is better than another.
I'm not really interested in the debates over languages any longer. The issue for me has long become finding the right tool to get the job done. That's all any of us should be concerned with. Of course, there are some people who still get very attached to a particular tool. I'm planning on addressing that particular issue in the very near future.
What I've really become interested in lately is what I call "classes of problems." You've heard the old saying that if the only tool you have is a hammer, every problem looks like a nail. The same can be said for computers and programming languages. The computer is well designed for solving certain classes of problems. However, it is unclear if the machine we call a "general computing device" is really designed to solve all classes of problems. In fact, it is beginning to appear more and more likely this is not the case. What kinds of problems can we solve with today's computers? What kind of problems are difficult to solve, and what kinds are insoluble?
That last question is the interesting one. Do we have classes of problems that computers cannot solve because the problems cannot be solved, or because the design of the modern computer cannot solve it?
I hope to address that question with my postings. I don't hope to answer the question, however. I'll be satisfied if I can simply stimulate the creative juices enough that we can start to imagine some solutions in the distant future.
I've been blogging off and on for awhile now. Perhaps that is best, as I prefer to only post when I have something I feel is interesting to say. However, it has only been recently that I've gotten the itch to post about things I actually do for a living. Namely, software development.
I've been creating software for commercial use for over 20 years now, and I'm still learning new things. In fact, it is only recently that I've taken the time to learn some of the 'newer' programming languages, like PHP, Python and Ruby. That's given me a chance to muse on both the practical and philosophical aspects of creating software applications and tools. When I make the distinction between tools and applications, I'm not doing it lightly. Tool building is a vastly different process from creating applications. That's true of creating a house, a car or a computer program. Tool builders are an odd subclass of the group.
In the past, people who built houses often made their own tools for the job. The reason was simple, they knew what they needed to get the job done, and it was rare that anyone else was making tools to sell to other builders. The same can be said for the early days of software development, although it is still somewhat true. Most developers today don't want or need to know how to build a compiler, or why one compiler is better than another.
I'm not really interested in the debates over languages any longer. The issue for me has long become finding the right tool to get the job done. That's all any of us should be concerned with. Of course, there are some people who still get very attached to a particular tool. I'm planning on addressing that particular issue in the very near future.
What I've really become interested in lately is what I call "classes of problems." You've heard the old saying that if the only tool you have is a hammer, every problem looks like a nail. The same can be said for computers and programming languages. The computer is well designed for solving certain classes of problems. However, it is unclear if the machine we call a "general computing device" is really designed to solve all classes of problems. In fact, it is beginning to appear more and more likely this is not the case. What kinds of problems can we solve with today's computers? What kind of problems are difficult to solve, and what kinds are insoluble?
That last question is the interesting one. Do we have classes of problems that computers cannot solve because the problems cannot be solved, or because the design of the modern computer cannot solve it?
I hope to address that question with my postings. I don't hope to answer the question, however. I'll be satisfied if I can simply stimulate the creative juices enough that we can start to imagine some solutions in the distant future.
posted by Steve Martin at 11:55 AM
0 Comments:
Post a Comment
<< Home