in reply to Re: Why the Right Tool for the Job is always ...
in thread Why the Right Tool for the Job is always ...
I can't prove that I'm right about this, but one point in my favor is the relative absence of multi-(high)-language applications. While we often see Java/Perl/Python/VB mixed with C for speed-critical components, applications with equal mixes of Java and Perl, for example, are almost unheard of. Similarly, I haven't seen many projects which equally mix Perl and Python, or VB and Java.
I think one of the main reasons for this is the tools. There isn't any support for it in most development environments.
This is a really interesting point. It may just be that the current barriers against multi-language integration are so great that they outweight the possible advantages. I think Parrot may potentially offer some hope of overcoming this area. For example, I'd love to be able to use Ruby, but CPAN keeps me sticking with Perl. If I could use all of CPAN with Ruby, that'd be very interesting indeed.
As to whether learning many languages is good. I certainly won't disagree. Learning more stuff in general is basically a good thing.
My point was just that while language X may be "the right tool for the job", it may still not be the right tool for the job given the team/person/company/etc. I think this has an interesting impact on advocacy because while Perl may be the right tool for a given project (or piece of a project), advocacy may still be inappopriate because of other factors.
|
|---|