> Lee Goddard wrote:
> > if you can do it in Perl, you can do it in C,
>
> Unfortunately, not true. Perl is a very dynamic language,
> on the order of Lisp. That makes it capable of things
> compiled languages can't do. There is no "eval" in C.
>
> Of course, these languages are Turing-equivalent, so you
> really could do "eval" in C if you really, REALLY wanted
> to. But no one wants to bad enough to actually do it. :-)
Some might say you shouldn't need to do it in Perl.
Not me, of course: TMTOWTDI.
> > and as the compiled C
> > is not interpreted, and can be better optimised, it's usually faster.
>
> Yes. For the things that *can* be done in C, they will usually
> be faster. The major downside is the horrendous *programmer*
> inefficiency of writing in C instead of a high-level language
> like Perl!
To an extent, I agree. I used to agree 100%, but then I started
working Perl development contracts and saw so much very very very
bad Perl that it occured to me that a laid-back language like Perl
often leads to code so laid back it could do with some of the
formalities often imposed by project managers on huge teams of C
programmers.
It's a scale thing, for me: Perl for prototyping (and, er, scripting)
and C (or even Java) for the real work, that requires processing
speed and reliability.
Lee
