John...

I am actually using this response to both respond to you, and to clarify some unpopular positions I have....


If a developer only knows or is only comfortable with one langauage, it is that langauge the developer will need to use. Is it the right language? It may or may not be? The issue here is a limitation with respect to the tools one has in his/her toolbox. In other words, if I have more than one hammer, I am more flexible than you, who has one hammer which happens to be a ball-ping hammer. When it comes to hammering in 16 penny nails in a framing operation, I can pick up my Estwing Framing Hammer and go to town. You on the other hand, will be laboring quite a bit. Will you get the job done? You probably will. I on the other hand, will get it done more efficiently.

In the case of programming, if all you know is one tool, you will perceive every problem as solveble by that one tool. Folks in this category, will over time, suffer through many inefficiencies, regardless of whether they realize it or not. Instead of expanding their toolbox, they work the hell out of the one they have. Do they get the job done? Most of the time yes. The question becomes, how much stuff did they have to work around to get something to work?

Take an ActiveX control. You have one that MUST be implemented. I know VFP and VB. First, I try it in VFP. The control does not work, either in design time or runtime. Or in a more minor case, it has just enough nits to render it unusable in VFP. Could I work around the problem? I might be able to. How many hours will it cost me? I don't know. Fortunately, I don't have to find out because I have VB in my toolbox. As it turns out, the control works fine in VB. In this case I got the job done because I not only know VB, I have accepted it and embraced it as another way to solve problems. In the end, I got the job done and the client is happy. Most importantly, I did'nt waste a lot of time spinning my wheels.

On the other side of the fence is the guy who perceives the world has solveable by only VFP. VB is discarded either because it does not have it's own data engine or because it does not implement inheritance. This person may have dabbled with VB. But, because of the reasons listed earlier, he/she discounts the thought of using the tool. This is the trap that many folks fall into. This is not in the sole domain of the VFP community. The inital responses to the guy asking the original question fall into this category. Folks either told him that VFP was best because it supported OOP, or VB was not good because it did not have a local data engine, and best of all, the person should not use SQL, they should use VFP data. All of these responses reek of the 'I know one tool, and that tool is the best tool, because it is the one I know' philosophy.

Folks need to differentiate between what the feel is better from what they know is better. If you have not worked with VB or SQL-Server in a real application, you cannot, and should not comment or offer a response. You would have no basis for conclusion. Remember, this is supposed to be a technical forum. People ask technical questions, they should get technical responses. This has been the crux of my argument.

Many folks up here should spend more time listening, and less time talking. This is not a popular point of view. And quite frankly, it should'nt be. In effect, I am telling some folks, 'Hey, you don't know what the hell you are talking about. Why don't you be quiet.' There are many posts up here I don't respond to. Why? Because I don't have a clue as to what the right answer is. I don't claim to have all of the answers. Nobody does. Walter Meester stated something up here about how MVP's can't admit when they are wrong. I think I have been lumped into that category including the general MVP bashing he was doing. Fact is, when there are times I am wrong with a post, which by the way, is not that often, I freely admit that I was wrong. Regarding MVP's, I have been one of the harshest critics of MVP's since I hold our community to a much higher standard.

I am never surprised that somebody that has far less the technical knowledge I have about VFP have the ability to answer a question that I cannot. It is a complex tool, nobody knows it all. That person, who does not contribute all that much, but if they have 1 or 2 key points about the product I don't know, that person is infinitely more valuable than many of the folks up here who continually waste bandwith the useless dribble. This is what negatively affects the signal to noise ratio.

All of that said, my argument is with those who toss tools aside because in their estimation, they don't favorably compare to their tool of choice, the one they happen to know. If they choose to do this on their own, fine. If they choose to be more inefficient, that is fine too. However, when they decide to provide technical answers to questions that would depend on them having relevant technical knowledge they otherwise, do not have, I would respectfully ask them to please, stay silent, and listen.....

So, does a developer need to know how to use every tool? No. However, a developer needs to know how to use a tool before evaluating the tools technical capabilities, and more importantly, comment on those technical capabilities in a public forum. Otherwise, folks have to sift through the volume of useless messages to get to the meaningful content.




>Hi JVP,
>
>I have to agree with Christof. You are correct about knowing which tool is best for which job, but a single individual does not have to know to develop using every tool in a solution. In fact, there are architectural and managerial anti-patterns based on this as a philosophy. In my case, I know enough VB to be dangerous. I know enough SQL Server and Oracle to put a decent database up. As to VC++, I couldn't code it if my life depended on it. I just don't have time to bring my circa-1983 C skills up-to-date. OTOH, if I'm looking at needing an interface to devices using serial comm with custom protocols, I know enough to know that I'm gonna need a C++ developer.
>
>>It is not a matter of being able to code decently in a langauge. Rather, it is a matter of whether the language you are coding in is the correct tool for the job. Also, I am all too familar with the real-world. Fact is, you should know how to use more than one tool. Being able to use just one puts some serious limitiations on what you can accomplish.