Re: What is the reason for Perl?
- From: "Eric J. Roode" <sdn.girths00869@xxxxxxxxxxx>
- Date: Mon, 12 Dec 2005 14:59:24 -0600
John Bokma <john@xxxxxxxxxxxxxxx> wrote in
news:Xns972A92C699419castleamber@xxxxxxxxxxx:
> "Eric J. Roode" <sdn.girths00869@xxxxxxxxxxx> wrote:
>
>> I've been a C programmer for 20 years, a Perl programmer for 10, and a
>> C++ programmer for 15. So I know something about the strengths and
>> weaknesses of these languages.
>>
>> C is a great language, but it's oooold.
>
> Does that matter?
Only in that it lacks some niceties that more modern languages (like
Perl, or Java, or C#) provide, such as exceptions.
>> It's very low-level. You
>> constantly have to worry about allocation, deallocation, buffer sizes,
>> aliases, and so on.
>
> No *you* don't. The people who wrote the library you use *do*.
Yes, you do. The libraries that make allocation and deallocation and
buffer sizes so transparent that you never need worry about them... are
very rare indeed. I have rarely coded in C where I didn't have to worry
about such issues.
>
>> It's a pain in the ass sometimes. The language
>> does virtually nothing for you;
>
> So you take a library. I have never seen a language doing thinking for
> me.
I'm not asking the language to do the thinking for me. I'm asking it to
do some of the grunt-work for me.
For example: You're writing a library function, which writes to a
buffer provided by the caller. The caller will typically allocate a
string (say), either on the stack or dynamically via malloc, and pass it
to your function. Wouldn't it be nice if your function could determine
how large the buffer was, so it could prevent an overrun?
In C, that's traditionally the responsibility of the top-level
caller, which means that every C programmer *does* have to worry about
allocation and buffer sizes.
>
>> and its control structures are weak.
>
> How?
C control structures:
function calls.
if/else
while
for
do...while
switch
goto
C control overrides:
return
break
continue
C's loops are unlabeled, meaning that you can only break or continue out
of the innermost one. Perl (and I think C#) allow you to break out of
more than one level at a time.
C has no exception mechanism.
C permits at most only one return value from a subroutine (of course,
this return value can be a structure).
C gives no information about the number or types of arguments passed to a
subroutine, or any information about the caller.
>
>> C++ is in some ways better than C, in some ways worse. Its OO model
>> is rather outdated; its macro and templating facilities are weak. On
>> the plus side, most things that you would need to do with
>> statically-defined structures at compile-time are in fact doable.
>> It's fairly complete. It suffers from C's requirement to nail down
>> every single type at compile- time; it's hard to make heterogeneous
>> structures.
>
> How come? I could make heterogeneous structures in C, quite easily
even.
> Are they removed from C++?
Not without copious "void *" and casting, you can't.
>> String manipulation in
>> Perl is a joy, compared to in C or C++ (or Java).
>
> How is it worse in C/C++ (or Java)?
Strings auto-extend in Perl. You cannot overrun a buffer in Perl.
Perl makes it a breeze to join strings, split them, interpolate variables
into them, perform pattern matching and replacement upon them, have
multi-line strings, read them from files, I could go on and on.
You can _do_ all of these things in C or C++, but the equivalent code is
longer and more tedious.
>
>> It also has a more
>> mature OO model than C++,
>
> Really? Based on what?
C++ is the classic "B&D" OO language. Everything must be tied down at
compile time. You have to dance with templates to get any sort of
generic data structures, and even then you have to work hard.
In Perl, you can have one class manufacture objects of another class, you
can add methods at run-time as needed, you can handle any unknown methods
via AUTOLOAD, you can tell who called you, and with what arguments, you
can examine your own hierarchy, etc. Perl provides closures; neither C
nor C++ have anything like those.
In Perl, you can write a function:
sub add_args
{
my ($arg1, $arg2) = @_;
unless (UNIVERSAL::can($arg1, 'add')) {
die "Can't add $arg1 and $arg2";
}
return $arg1->add($arg2);
}
and it will add any arguments, of any type, whether declared at compile-
time or not. The only major deficiency there is that it won't add any
built-in types. Writing such a universal function in C++ is pretty much
impossible.
>
>> and its OO (indeed even function
>> definitions) can be created or changed at run-time. On the down side,
>> it is pitifully slow
>
> It is?
Compared to C or C++? Yep.
--
Eric
`$=`;$_=\%!;($_)=/(.)/;$==++$|;($.,$/,$,,$\,$",$;,$^,$#,$~,$*,$:,@%)=(
$!=~/(.)(.).(.)(.)(.)(.)..(.)(.)(.)..(.)......(.)/,$"),$=++;$.++;$.++;
$_++;$_++;($_,$\,$,)=($~.$"."$;$/$%[$?]$_$\$,$:$%[$?]",$"&$~,$#,);$,++
;$,++;$^|=$";`$_$\$,$/$:$;$~$*$%[$?]$.$~$*${#}$%[$?]$;$\$"$^$~$*.>&$=`
.
- Follow-Ups:
- Re: What is the reason for Perl?
- From: xhoster
- Re: What is the reason for Perl?
- From: John Bokma
- Re: What is the reason for Perl?
- References:
- What is the reason for Perl?
- From: robic0
- Re: What is the reason for Perl?
- From: Eric J. Roode
- Re: What is the reason for Perl?
- From: John Bokma
- What is the reason for Perl?
- Prev by Date: Re: What is the reason for Perl?
- Next by Date: Re: %USERACL Is Empty?!
- Previous by thread: Re: What is the reason for Perl?
- Next by thread: Re: What is the reason for Perl?
- Index(es):
Relevant Pages
|
|
