Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Re: Why the Right Tool for the Job is always ...

by adrianh (Chancellor)
on Nov 24, 2002 at 01:15 UTC ( #215455=note: print w/ replies, xml ) Need Help??


in reply to Why the Right Tool for the Job is always ...

I totally agree with their being a "right tool for the person/team". Bringing a new language to an existing codebase, especially one where the developers are unfamiliar with it, is hard. It will often be the wrong decision and this does have implications for language advocacy.

However... :-)

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.

I worked for several years both coding with, and helping develop, a programming environment called Poplog. It had a single IDE that allowed you to develop in Pop-11 (which you won't have heard of :-), Common LISP, ML and Prolog. All the languages compiled down to the same stack based VM, so it was really easy to write code in multiple languages - and many Poplog users did.

Because they were all running on the same VM it was trivial for Prolog code to call Lisp code that called Prolog code again, that then called some Pop-11 code, etc.

The ability to merge languages like this is a very different experience from calling an external library in another language.

That said, want to use Bob's Prolog expert system shell with your Common Lisp stats package, with a UI developed using Pop-11's PropSheet library - bish bosh done. Darn handy.

I don't agree that "basically all high-level languages are equivalent". I really do think that some languages are better for some tasks. Text processing is easier in Perl. Multi-platform UIs are easier in Java. Writing code that manipulates code is easier in Scheme... and so on. Some of this is because of the available libraries rather than fundamental language differences - but that doesn't make it any less true.

I don't want to write 100 lines of perl when I could write 10 lines of Prolog (I still miss Prolog occasionally :-). Equally, I don't want to write 100 lines of Prolog where I could write 10 lines of Perl.

One of the things I'm finding interesting in the development of Parrot is that you're seeing lots of languages other than Perl being implemented. I can see support for multiple languages being a natural extension of Perl's TMTOWTDI attitude.

Coding in multiple languages is hard. Finding a development team that is comfortable with developing in multiple languages is hard. Hopefully this will not be true forever and people can start taking advantage of the best points in all languages.

(I'm about to digress and have a little rant... people interested in the original topic please leave now. :-)


Personally, I find a lot of language advocacy disturbing. I find a great deal of it consisting of inaccurate abuse rather than reasoned argument.

I've lost track of the languages I've learned in my career as a programmer. Every one (even BASIC :-) has made me a better developer. Each has brought some new angle or perspective on how I look at problems. Each one has been slightly better at some task or another.

One of the things I look for when hiring coders is the number of languages they've coded in. In my experience, the more languages the better. Instead of seeing how to solve a problem in Perl (or C++, or whatever) - they look at how to solve the problem.

Perl's a great language and I love it dearly. I do the majority of my professional development work in Perl. But it isn't the best thing for every task in every situation. Neither is Java. Neither is C++. There is no silver bullet.

I find a lot of new developers coming out of school or university only knowing language X (where X is usually one of Java or C++). They see everything in terms of that language. Every problem is interpreted through that languages advantages and limitations. I love introducing C++ only coders to CLOS or Eiffle and see the rapid expansion of horizons pop their eardrums :-)

Anyway... I've started mixing metaphors so I'll should probably stop now... We now return you to your original programming.


Comment on Re: Why the Right Tool for the Job is always ...
Re: Re: Why the Right Tool for the Job is always ...
by Anonymous Monk on Nov 24, 2002 at 17:36 UTC

    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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://215455]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (12)
As of 2014-12-18 07:45 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (44 votes), past polls