Knowledge and Traps

It seems to be the case more and more that, in a programming context, people go the knowledge route versus thinking about the actual processes involved just a bit more. Quantity over quality perhaps? But then, its exceedingly easy to get carried away and miss the big picture so to speak when it comes to these sorts of things.

A great deal of people notice these things in retrospect but then of course its somewhat too late. As before though, one benefits from well documented processes. The author makes note that there is more to be gained from notes that detail the processes rather than the steps to the solution. And what isn't better in drafts? The first attempt at anything, even pattern recognition algorithms should provide valuable insights to the process.

It seems to be difficult to program in a general sort of way. That is. with thought processes in mind. Most programming goals are mundane in that they lack much usefulness outside of a specific application. This tailor-made approach, however, might have its place with the compartmentalized view of the mind in some disciplines. The idea of modularization in computing and the mind seem somehow similar.

So, with this, one should ultimately be able to improve programs that attempt to do things we can do with some thought about ourselves. I'm not personally sure how much thought is given to this while people think about different algorithms to use. It only makes sense that everyone that produces code should think about it. The machine's strengths are somewhat obvious when compared to us, I think. So the idea seems to be to use the machine's positive characteristics and imprint our own methods on it – even if only partially. Now heres the question of usefulness with expert systems versus those who are not knowledge based. Is the question actually “Which is better: to know vast amounts or to be able to learn?”