Interesting discussion; plus I learnt a new word - "huzpah". One of the reasons for the limited influence of Perl might indeed be poor programmers - those who call /bin/grep from their scripts, 'use' modules they don't use, only vaguely know of 'my', have never heard of CPAN and whose outpourings couldn't possibly run under a 'strict' or 'warnings' pragma.
The resulting code, when it does run, tends to be very delicate and not given to change, except by the magician who wrote it. This leaves junior managers with a bad taste in the mouth, and the language gets blacklisted along with the culprit. Gabor Szabo wrote: > The reason might be that Perl does not have high profile guy keren wrote: > b. the name 'scripting languages' put those languages in a nische. this > marketing automatically excludes their use for writing "real programs". I agree; this might be the other reason, for this bias is deeply inculcated. The last time I was given to design a new solution, I chose C over Perl primarily because the latter had never been used in that environment for a "real" job, but only for quick one-time fixes, or for antiquated scripts to handle non-core tasks. If things had gone awry, the first suspect would have been the 'novel' language. guy keren wrote: > when students go "out there" - all they know is that they want to work in "java". or in > "C++". even telling them you work in C reduces their enthusiasm. i am > quite sure i would have reacted the same way when i was fresh. Perhaps University courses should have in a middle semester (say fourth or fifth) a comparative programming language study. Choose a few programming tasks: 1. one eminently suited for number crunching (like finding primes), 2. one that access input files and an input database and creates a report 3. one that supports a remote access monitoring system Break up the class into groups, giving each group the choice of not only the task but also a certain language (Perl, C/C++, Cobol, Python and Java). Let each group document their experience in terms of compilation errors, rewrites, availability of libraries, documentation and IDEs, ease of coding, stability and performance. The groups should then present their findings and let each other review their code. Might this not suggest that the approach depends upon the task, and the choice of a particular language upon factors such as whether performance is critical, or how often changes might be expected etc.. Elizabeth Sterling wrote: > So we should all stop preaching to the choir, and start talking to the people who > actually make the decisions. True :) But some in the choir eventually might, indeed must, at a later point make their way to the pulpit, i.e. some programmers become managers, with the passage of time. Sincerely, Srikanth Madani, lately a lurker ____________________________________________________________________________________ Get your own web address. Have a HUGE year through Yahoo! Small Business. http://smallbusiness.yahoo.com/domains/?p=BESTDEAL _______________________________________________ Perl mailing list [email protected] http://perl.org.il/mailman/listinfo/perl
