|
Re: C vs. Perl
by gmax (Abbot) on Oct 22, 2003 at 16:02 UTC
|
Some criticism about your code is in order.
In Perl you would write like this
In Perl I would write a one-liner.
perl -ane '$items{$F[0]} = $F[1] ;END{print "apples cost $items{apple}
+\n" if $items{apple}}' data
your code should be able to handle any number of items
But yours will only handle as may item that can fit into your system's memory. If I had really to handle "any number of items" I would use a DBMS. And still you fail to convince me that I couldn't do the same in C. With more lines of code, perhaps, but I can do it in any language I have used so far.
#here you can also get the name from the user and print the
#price.
But let's assume that there is no "apples" in your input. You would print an empty price. You should check first.
The bottom line is, you don't compare two main languages using such a trivial example and offering no alternatives, especially if your "positive" example is questionable as well.
I have coded in C for many years, and when I switched to Perl it wasn't because C wasn't up to my expectations. It's simply that Perl is easier and faster to code.
If you want to consider a more critical comparison of a specific implementation of a well established algorithm, have a look at Perl's pearls
| [reply]
[d/l]
[select] |
|
|
But yours will only handle as may item that can fit into your system's memory. If I had really to handle "any number of items" I would use a DBMS.
If you want to be pendanic, then you'll still be limited in a DBMS by your hard drive space. Now, where did I leave that piece of infinate paper tape?
----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer
:(){ :|:&};:
Note: All code is untested, unless otherwise stated
| [reply]
[d/l] |
|
|
Some criticism about your reply is in order.
And still you fail to convince me that I couldn't do the same in C.
He wasn't trying to. Read his first line again: "I was wondering how C makes certain things harder to write and perl (and similar languages) makes it easy to write."
Apparently, you agree with his premise because you said, "It's simply that Perl is easier and faster to code."
He's just wondering "why"...
The reason is that Perl was designed so that code for a problem would map more easily to the programmer's way of thinking about it and C was designed so that code for a problem would map more easily to the machine's way of executing it.
BTW, as for your one liner, how likely do you think it is that you would actually have to do that on the command line? It's far more likely that that task would be part of a larger program... in which case using -a probably wouldn't help at all.
-sauoq
"My two cents aren't worth a dime.";
| [reply] |
Re: C vs. Perl
by Abigail-II (Bishop) on Oct 22, 2003 at 16:01 UTC
|
How would you write it in C if you are also told that your code should be able to handle any number of items!
You would embed Perl into your C program.
Abigail
| [reply] |
|
|
What a devastatingly delightful suggestion!
I love it!
| [reply] |
Re: C vs. Perl
by etcshadow (Priest) on Oct 22, 2003 at 15:52 UTC
|
Uh, hello? malloc()? realloc()?
I mean, I prefer writing code in perl, too... but "you can't do this utterly simple thing in C" business is just silly.
Yeah it takes more lines of more difficult C to do the same thing, but what the hell? They're different languages. There are things better done in C for various reasons (but they can be done in Perl) and things better done in Perl (but they can be done in C).
------------
:Wq
Not an editor command: Wq
| [reply] |
|
|
I am sorry if I have confused you all. I did not say that C is bad, or it can't be done in C. I was just trying to
point out that Perl (and Java etc.) already has a lot of built in stuff and it makes life easy to write stuff. Of course, you could also do it in assembly code, but why?
I agree that you could do certain things in C for speed. I also agree if I have all the necessary
libraries (such as Vectors) I would not mind writing in C.
I was also wondering that if I have an example like this, people who are learning perl will get excited about perl!
In C, for example, if you do not know how many elements are there, you could, say, allocate 100 elements first, and then
when you reach 100, you could allocate 200 elements and then move those 100 elements to the new array!
Why do I want to do that when a language already does that for me.
I was also looking for a place for this and could not find a proper category (Please suggest one).
| [reply] |
|
|
| [reply] |
|
|
Well he said "How would you do this in C?", which could be interpretted as a rhetorical means of asserting the claim that it couldn't be done (particularly if you take his quote in context). Regardless of whether you think that he was asserting it's impossibility or just claiming that it was ridiculously hard, his statement was clearly rhetoric.
I was just answering rhetoric with rhetoric. Specifically with hyperbole. I know he wasn't claiming that it couldn't be done at all... but his claim was ridiculous none the less. The worst thing is that he picked a particularly silly example, as it could be done in a very small and simple C program.
------------
:Wq
Not an editor command: Wq
| [reply] |
|
|
Re: C vs. Perl
by dragonchild (Archbishop) on Oct 22, 2003 at 15:32 UTC
|
How would you write this in C? What about C++? Java? VB?
This isn't a tutorial, this is an advocacy. You're preaching to the choir. Present solutions in other languages if you want to write a 'vs.' node.
------
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.
| [reply] |
Re: C vs. Perl
by BUU (Prior) on Oct 22, 2003 at 16:29 UTC
|
This really isn't a comment on whether one language is better then another, but how different languages are better for different tasks. Of course, it doesn't tend to focus on how many things are done with C that might by more easily accomplished in perl (or possibly vice versa, but I can't really think of any..?). Especially with something like the example given in the parent node, which smells a lot like 'homework' and lets me rant about something I always found irritating in the C class I took. Why do they always blood assign stupid text processing programs in C?! I could write the same program in like, 3 lines of perl code, but instead it takes me 400 lines of C (Granted, a large portion of it is from writing my own linked list.. but still) it was irritating, especially after having used perl for the last year or so before I took the class. It would be nice if language classes tried to focus on their strengths, rather then weaknesses. | [reply] |
|
|
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.
| [reply] |
|
|
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.
| [reply] |
|
|
|
|
|
|
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
| [reply] |
|
|
Re: C vs. Perl
by Roger (Parson) on Oct 23, 2003 at 02:05 UTC
|
It's not fair to compare the core of C with Perl. They are not on the same level. Perl is like C with lots of handy and powerful libraries, and Perl has built-in memory management.
Ok, let's give C the additional libraries DIE, ARRAY, FILE, HASH and SPLIT, and the competition is more fair.
#include <stdio.h>
#include <DIE.h>
#include <ARRAY.h>
#include <HASH.h>
#include <SPLIT.h>
#include <FILE.h>
int main(int argc, char **argv)
{
FILE *f;
char *buf;
HASH *h = new HASH();
if ((f = fopen("data", "r")) == NULL)
DIE("unable to open file");
while(buf = READFILE(f)) {
ARRAY *ar = SPLIT(buf);
h->AddElement(ar[0], ar[1]);
free(ar);
free(buf);
}
printf("price of apple is : %s\n", h->GetElement("apple"));
fclose(f);
return(0);
}
| [reply]
[d/l] |
|
|
| [reply]
[d/l]
[select] |
|
|
I think you are missing the point. The GETPRICE module implements a specific business rule, it is not a utility module.
Yes I agree Perl and C are different, but they are really not THAT different.
| [reply] |
|
|
Excellent point, and a wonderful example. Now, I believe that these libraries do exist (in a fashion) in the Perl distribution. I'd be curious to see how one would use these libraries in a real program ...
------
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.
| [reply] |
Re: C vs. Perl
by Cody Pendant (Prior) on Oct 22, 2003 at 20:58 UTC
|
I don't get this post, because I know nothing about C whatsoever. So can someone explain what's so intractable about this problem in C?
($_='kkvvttuubbooppuuiiffssqqffssmmiibbddllffss')
=~y~b-v~a-z~s; print
| [reply]
[d/l] |
|
|
So can someone explain what's so intractable about this problem in C?
Read the OP again. He never said it couldn't be done. He said it was easier in Perl. And he's right. It seems that gmax and others thought they were disagreeing with the OP but were agreeing all along. Still, as dragonchild said, the post was really just advocating Perl, which is hardly necessary around here.
-sauoq
"My two cents aren't worth a dime.";
| [reply] |
|
|
Yes, fair enough, but I withdraw my "intractable" and rephrase -- what makes this problem so much harder in C?
It's just you all seem to be skipping over that part and saying "yes, but" whereas I'm not even at "yes".
Is it because in C you can't have an array that just gets bigger and bigger to handle all the data that you shove into it, it has to have a pre-declared size, something like that?
($_='kkvvttuubbooppuuiiffssqqffssmmiibbddllffss')
=~y~b-v~a-z~s; print
| [reply]
[d/l] |
|
|
Re: C vs. Perl
by ctilmes (Vicar) on Oct 23, 2003 at 01:43 UTC
|
| [reply] |
|
|
Perl 6 is going to be written in Perl.
No it won't. The Perl 6 grammar will be defined it its own regexes. Which will be parsed by a Perl 5 module. Which means that at least some of Perl 6 is written in itself.
Ref: State of the Onion 2003.
| [reply] |
|
|
| [reply] |
|
|
Uhhh ... no. As Elian has stated on a number of occasions (including while correcting me in this thread), Perl6 will be written in Parrot, which is written in C. The big difference that you seem to be referring to will be that Perl6 will be writeable in Perl6, whereas Perl5 cannot be written in Perl5. Still, the generic Perl6 distribution will not be written in Perl6.
------
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.
| [reply] |
