Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

Re: Re: C vs. Perl

by dragonchild (Archbishop)
on Oct 22, 2003 at 17:26 UTC ( #301290=note: print w/replies, xml ) Need Help??


in reply to Re: C vs. Perl
in thread C vs. Perl

You can't do anything more easily in C as opposed to Perl. That has never been a question.

One uses C when Perl's mammoth use of resources is unacceptable. For example, when dealing with direct contact with the Linux kernel or writing device drivers or writing programs to run on very small machines (like embedded stuff). And, in many cases, I would write in Perl and use Inline::C for items I wanted to speed up.

It's all a matter of what your specs are.

------
We are the carpenters and bricklayers of the Information Age.

The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6

... strings and arrays will suffice. As they are easily available as native data types in any sane language, ... - blokhead, speaking on evolutionary algorithms

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

Replies are listed 'Best First'.
Re: Re: Re: C vs. Perl
by Elian (Parson) on Oct 22, 2003 at 19:41 UTC
    You can't do anything more easily in C as opposed to Perl. That has never been a question.
    Really? Written any high-performance gigabit ethernet drivers in perl lately? (Or, for that matter, written perl in perl lately?)

    It's not even a matter of possible. It's a matter of ease. It's easier to write device drivers in C than perl, and it's easier to write interpreters in C than perl--if it wasn't parrot and more of perl 5 would be written in perl. They aren't, because it isn't easier.

    Ease is task-dependent. You're dismissing whole realms of problems without good cause, apparently out of a dislike of C. I loathe C some days, but it's still a better language (including ease of use) for some problems than perl is, or ever will be.

      Elian - I specifically stated in a later paragraph that high-performance items should be written in C over Perl. (I make no statement about any other language in that sentence.)

      My use of the word "ease" is in the sense of "ease of initial development". Perl is the rapid-prototyping language of choice for me and most people I know. Now, if I need greater performance (for some aspect of performance) after writing the first version(s) in Perl, I will evaluate to see if porting it (or some parts) to another language, such as C, is something I feel is warranted.

      And, there are whole classes of problems for which neither C nor Perl is the best tool. For example, database queries. SQL is a much better language for querying normalized data than C or Perl. Hence, the reason why Pro*C exists and why we pass SQL to DBI instead of querying the tables in native Perl.

      As for writing interpreters in one language vs. another ... I'm going to suspect that writing the parsing portion for an interpreter is easier to do in Perl than in C, simply for the string manipulation functions. Now, having that parser do its work within a reasonable amount of time (for some value of reasonable) ... that's where it becomes a high-performance item, and another language (such as C) could be considered.

      There is also a lot more history writing a parser in C vs. Perl, so a number of the standard gotchas have been solved in C. Solutions in one language, especially ones that take advantage of extremely advanced language features, are generally not easily translatable to another language. So, one would have to rebuild all those standard solutions in Perl. (This, I suspect, is one of the reasons why more parsers are not written in languages other than C, even if there may be other reasons to do so.)

      (Please note that I have never written anything more than a toy parser. It would definitely be something interesting to do.)

      ------
      We are the carpenters and bricklayers of the Information Age.

      The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6

      ... strings and arrays will suffice. As they are easily available as native data types in any sane language, ... - blokhead, speaking on evolutionary algorithms

      Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

        I specifically stated in a later paragraph that high-performance items should be written in C over Perl. (I make no statement about any other language in that sentence.)
        You were specifically talking performance in that chunk of caveat. I wasn't necessarily--I was talking about ease. There are things that are easier in C than in perl, even when performance requirements are factored out.

        Also, as to this:

        As for writing interpreters in one language vs. another ... I'm going to suspect that writing the parsing portion for an interpreter is easier to do in Perl than in C, simply for the string manipulation functions.
        That turns out not to be the case. There are a number of styles of parsing that are easier in C than they are in Perl both as hand-rolled parsers and taking the language as a target for a parser generator.

        I'll reiterate--you may think that perl is easier than C in all cases, but that turns out not to be the case.

Re: C vs. Perl
by Abigail-II (Bishop) on Oct 22, 2003 at 20:32 UTC
    You can't do anything more easily in C as opposed to Perl. That has never been a question.
    Oh, sure you can. Ever tried locking *part* of a file? Quite a standard operation, but I don't think it's even documented how you do it in Perl.

    Abigail

      I haven't found it in the core documentation, but there is a recipe in "Perl Cookbook" (recipe 7.25 in the second edition) called "lockarea" that dooes just this. It's not very portable (and isn't easier than its C counterpart), but works on Berkley-ish systems.

      The Cookbook says, "This program, while included with Perl...". I didn't find it in the latest sources when looking for "lockarea". Does anyone else know where it is in the source, or when it was depricated if it's not there?

      -- dug

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (4)
As of 2021-09-27 17:40 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?