[26650] in Perl-Users-Digest
Perl-Users Digest, Issue: 8757 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Dec 12 18:05:32 2005
Date: Mon, 12 Dec 2005 15:05:05 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 12 Dec 2005 Volume: 10 Number: 8757
Today's topics:
Re: Can device drivers be written in Perl? <emschwar@pobox.com>
Can one use local to temporarily close STDERR? <socyl@987jk.com.invalid>
Compile-time variable declaration (was Re: FAQ 2.11 Per <sdn.girths00869@zoemail.net>
Correcting details for a CPAN module. <ian.stuart@ed.ac.uk>
Re: What is the reason for Perl? <sdn.girths00869@zoemail.net>
Re: What is the reason for Perl? <sdn.girths00869@zoemail.net>
Re: What is the reason for Perl? xhoster@gmail.com
Re: What is the reason for Perl? <sdn.girths00869@zoemail.net>
Re: What is the reason for Perl? <tassilo.von.parseval@rwth-aachen.de>
Re: What is the reason for Perl? <sdn.girths00869@zoemail.net>
Re: What is the reason for Perl? <sdn.girths00869@zoemail.net>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 12 Dec 2005 14:52:59 -0700
From: Eric Schwartz <emschwar@pobox.com>
Subject: Re: Can device drivers be written in Perl?
Message-Id: <etoy82qnft0.fsf@wilson.emschwar>
Gregory Toomey <nobody@bigpond.com> writes:
> robic0 wrote:
>> ???????
> No. You have obviously never written a device driver.
Amusingly enough, http://www.circlemud.org/~jelson/software/fusd/ is a
project to allow Linux device drivers to be written in userspace. I
don't know any technical reason those couldn't be written in Perl,
though you'd almost certainly have to write an XS wrapper for the fusd
library.
-=Eric
------------------------------
Date: Mon, 12 Dec 2005 22:46:16 +0000 (UTC)
From: kj <socyl@987jk.com.invalid>
Subject: Can one use local to temporarily close STDERR?
Message-Id: <dnkujo$6cr$1@reader2.panix.com>
I would like to know whether it is possible to use localization to
*temporarily* close a global handle, e.g. STDERR. The following
doesn't work (all three messages appear on the screen):
warn "before closing\n";
{
local *STDERR;
# close STDERR;
warn "should be closed\n";
}
warn "still here\n";
If I explicitly close STDERR right after the local statement, then
only the first message gets printed.
Of course, I can achieve the desired effect (namely, selectively
silencing the second message) if I explicitly save and later restore
STDERR:
use Fatal qw( open close );
warn "before closing\n";
{
open my $save, '>&', *STDERR;
close STDERR;
warn "should be closed\n";
open STDERR, '>&', $save;
}
warn "still here\n";
...but I'm curious if there's a way to achieve the same effect without
doing this.
Thanks!
kj
--
NOTE: In my address everything before the first period is backwards;
and the last period, and everything after it, should be discarded.
------------------------------
Date: Mon, 12 Dec 2005 13:29:16 -0600
From: "Eric J. Roode" <sdn.girths00869@zoemail.net>
Subject: Compile-time variable declaration (was Re: FAQ 2.11 Perl Books)
Message-Id: <Xns972A93A70B889sdn.comcast@216.196.97.136>
anno4000@lublin.zrz.tu-berlin.de (Anno Siegel) wrote in news:dnd9mv$o1i$1
@mamenchi.zrz.TU-Berlin.DE:
> Eric J. Roode <sdn.girths00869@zoemail.net> wrote in comp.lang.perl.misc:
>> -----BEGIN xxx SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> anno4000@lublin.zrz.tu-berlin.de (Anno Siegel) wrote in
>> news:dnc2lj$o6$1@mamenchi.zrz.TU-Berlin.DE:
>
> [...]
>
>> > That would allow users to say, for instance
>> >
>> > my @NAMES;
>> > use Readonly \ @names => qw( Ida Otto Erich);
>> >
>> > and have the assignment happen at compile time.
I made that change, and it works. But it does not work with the
following syntax:
use Readonly \my @names => qw(Ida Otto Erich);
and I can't figure out why. From inside Readonly's import(),
everything looks fine, but back at the main program, @names is
undefined.
--
Eric
`$=`;$_=\%!;($_)=/(.)/;$==++$|;($.,$/,$,,$\,$",$;,$^,$#,$~,$*,$:,@%)=(
$!=~/(.)(.).(.)(.)(.)(.)..(.)(.)(.)..(.)......(.)/,$"),$=++;$.++;$.++;
$_++;$_++;($_,$\,$,)=($~.$"."$;$/$%[$?]$_$\$,$:$%[$?]",$"&$~,$#,);$,++
;$,++;$^|=$";`$_$\$,$/$:$;$~$*$%[$?]$.$~$*${#}$%[$?]$;$\$"$^$~$*.>&$=`
------------------------------
Date: Mon, 12 Dec 2005 22:59:42 +0000
From: Ian Stuart <ian.stuart@ed.ac.uk>
Subject: Correcting details for a CPAN module.
Message-Id: <439e00db$0$63087$ed2e19e4@ptn-nntp-reader04.plus.net>
I've recently uploaded a package into CPAN
(MathML::Entities::Approximate), and it appears in search.cpan.org -
however the details are incomplete:
There is a link to the pod, and my CPAN ID.
All the other packages have a short description on the first line, and
then a second line with several items: a link to a page detailing the
package, then the date of the file and the name of the maintainer
(linked to a page of further details)
Is there some file in my distribution file that I set these, or does
CPAN automagically extract these itself?
--
Ian, Perl Laghu
------------------------------
Date: Mon, 12 Dec 2005 13:41:59 -0600
From: "Eric J. Roode" <sdn.girths00869@zoemail.net>
Subject: Re: What is the reason for Perl?
Message-Id: <Xns972A95D2C782Esdn.comcast@216.196.97.136>
robic0 wrote in news:ohkpp15b78vlhrpb8bcag801jd78ed0pb1@4ax.com:
> Explain to me if you can why Perl is something I should use in
> replacement to say C++ and a native API....
C++ and Perl have their own strengths and weaknesses. Perl is great at a
lot of things C++ isn't. And vice-versa.
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. It's very low-level. You
constantly have to worry about allocation, deallocation, buffer sizes,
aliases, and so on. It's a pain in the ass sometimes. The language does
virtually nothing for you; you have to do a lot of work to get anything
done. Plus, the language has no reflection/introspection capabilities at
all, and its control structures are weak.
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.
Perl is a much higher-level language than either of the above. It does a
whole boatload of the work for you, so you don't have to worry so much
about allocation, buffer sizes, etc. String manipulation in Perl is a
joy, compared to in C or C++ (or Java). It also has a more mature OO
model than C++, and its OO (indeed even function definitions) can be
created or changed at run-time. On the down side, it is pitifully slow
-- mostly because it's doing all that work for you behind the scenes.
Perl is my language of preference, just because it allows me to get more
work done in a given amount of time. For most of the things I do
(database stuff, mostly), Perl's slowness just doesn't matter much.
--
Eric
`$=`;$_=\%!;($_)=/(.)/;$==++$|;($.,$/,$,,$\,$",$;,$^,$#,$~,$*,$:,@%)=(
$!=~/(.)(.).(.)(.)(.)(.)..(.)(.)(.)..(.)......(.)/,$"),$=++;$.++;$.++;
$_++;$_++;($_,$\,$,)=($~.$"."$;$/$%[$?]$_$\$,$:$%[$?]",$"&$~,$#,);$,++
;$,++;$^|=$";`$_$\$,$/$:$;$~$*$%[$?]$.$~$*${#}$%[$?]$;$\$"$^$~$*.>&$=`
------------------------------
Date: Mon, 12 Dec 2005 14:59:24 -0600
From: "Eric J. Roode" <sdn.girths00869@zoemail.net>
Subject: Re: What is the reason for Perl?
Message-Id: <Xns972AA30AFA4C7sdn.comcast@216.196.97.136>
John Bokma <john@castleamber.com> wrote in
news:Xns972A92C699419castleamber@130.133.1.4:
> "Eric J. Roode" <sdn.girths00869@zoemail.net> 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
`$=`;$_=\%!;($_)=/(.)/;$==++$|;($.,$/,$,,$\,$",$;,$^,$#,$~,$*,$:,@%)=(
$!=~/(.)(.).(.)(.)(.)(.)..(.)(.)(.)..(.)......(.)/,$"),$=++;$.++;$.++;
$_++;$_++;($_,$\,$,)=($~.$"."$;$/$%[$?]$_$\$,$:$%[$?]",$"&$~,$#,);$,++
;$,++;$^|=$";`$_$\$,$/$:$;$~$*$%[$?]$.$~$*${#}$%[$?]$;$\$"$^$~$*.>&$=`
------------------------------
Date: 12 Dec 2005 22:27:45 GMT
From: xhoster@gmail.com
Subject: Re: What is the reason for Perl?
Message-Id: <20051212172745.432$r0@newsreader.com>
"Eric J. Roode" <sdn.girths00869@zoemail.net> wrote:
> John Bokma <john@castleamber.com> wrote in
> news:Xns972A92C699419castleamber@130.133.1.4:
>
> > "Eric J. Roode" <sdn.girths00869@zoemail.net> 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.
But do those niceties have anything to do with C's age? It seems to me
like C is a still-widely-used close-to-the-metal language not because it is
old, but because we need a close-to-the-metal language and C is good at
being that.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Mon, 12 Dec 2005 16:48:25 -0600
From: "Eric J. Roode" <sdn.girths00869@zoemail.net>
Subject: Re: What is the reason for Perl?
Message-Id: <Xns972AB570F3620sdn.comcast@216.196.97.136>
John Bokma <john@castleamber.com> wrote in
news:Xns972AA09354FA1castleamber@130.133.1.4:
> "Eric J. Roode" <sdn.girths00869@zoemail.net> wrote:
>
>> 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,
>
> If it's a string, you could check for \0 now couldn't you? And if you
> want to use something else, what's the problem of wrapping it all nice
> into a library?
char buf[80];
strcpy (buf, "hello");
After this call, buf[5] is '\0'. Before that call, all of the elements of
buf are uninitialized; possibly they're all '\0', possibly they're all
random garbage.
Checking for '\0' tells you how long the string is (5 characters), but
doesn't tell you how long the allocated buffer is (80 bytes).
char buf[4];
strcpy (buf, "hello");
strcpy() can't tell that you're trying to stuff too much data into the
buffer. There simply is no way.
--
Eric
`$=`;$_=\%!;($_)=/(.)/;$==++$|;($.,$/,$,,$\,$",$;,$^,$#,$~,$*,$:,@%)=(
$!=~/(.)(.).(.)(.)(.)(.)..(.)(.)(.)..(.)......(.)/,$"),$=++;$.++;$.++;
$_++;$_++;($_,$\,$,)=($~.$"."$;$/$%[$?]$_$\$,$:$%[$?]",$"&$~,$#,);$,++
;$,++;$^|=$";`$_$\$,$/$:$;$~$*$%[$?]$.$~$*${#}$%[$?]$;$\$"$^$~$*.>&$=`
------------------------------
Date: Mon, 12 Dec 2005 23:56:06 +0100
From: "Tassilo v. Parseval" <tassilo.von.parseval@rwth-aachen.de>
Subject: Re: What is the reason for Perl?
Message-Id: <406dg9F18ka7gU1@news.dfncis.de>
Also sprach John Bokma:
> "Eric J. Roode" <sdn.girths00869@zoemail.net> wrote:
>
>> John Bokma <john@castleamber.com> wrote in
>> news:Xns972A92C699419castleamber@130.133.1.4:
>>
>>> "Eric J. Roode" <sdn.girths00869@zoemail.net> 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.
>
> Isn't there one (or even more) library that makes exceptions available
> in C?
>
> Also, even though some people consider die wrapped in an eval an
> exception, it can't be compared with exception handling with classes. If
> you want that in Perl: library.
die() can throw exception objects which end up in $@. I've never seen a
need for more elaborate exception handling. IMO, what Perl offers wrt
exception handling is just what's needed.
>>>> 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.
>
> Odd, even in "my time" they were available IIRC, and that was quite some
> time ago. Or if all else fails, you can write yourself a nice one.
I don't know any major library where you wouldn't have to worry about
deallocation. Things like garbage-collection cannot easily be done at
library-level.
>> I have rarely coded in C where I didn't have to
>> worry about such issues.
>
> I rarely had issues with it :-)
>
>>> 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.
>
> If it's not in the language, use a library. Why do you understand this
> simple concept with Perl, but not with C?
There's a limit of what libraries can do. The aforementioned automatic
deallocation of memory is beyond a library unless this library has
control functions/macros similar to ENTER/LEAVE in the perl API. And
those have to be put in explicitely by a programmer to have any effect.
This is very different from a real garbage-collector.
>> 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,
>
> If it's a string, you could check for \0 now couldn't you? And if you
> want to use something else, what's the problem of wrapping it all nice
> into a library?
I can't remember Eric stating that it is impossible. Of course you can
do it. The question is: How much time does a programmer spend with such
meanial tasks.
>> 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.
>
> Unless you use a library that worries about this.
There can be no library that worries about this in a satisfactory way.
>> Perl (and I think C#) allow you to break
>> out of more than one level at a time.
>>
>> C has no exception mechanism.
>
> nor does Perl for that matter, eval and die is not that different from
> longjmp.
They are different in that longjmp requires some additional work by a
programmer. First and foremost, an environment has to be created before
you may longjmp back to it. Futhermore, there are some portability
issues to be aware of, most notably with the signal context.
Nothing of that applies to Perl's die/eval.
>> C permits at most only one return value from a subroutine (of course,
>> this return value can be a structure).
>
> How does that differ from Perl? You mistake syntax sugar for what
> actually is happening.
Multiple return values are not syntactic sugar. They are an intrinsic
feature of Perl implemented on top of a dynamic stack that C does not
have.
>> C gives no information about the number
>
> yes it does.
Portably? I doubt it. Specifically, there is no way to write a C
function that expects zero or more arguments. At least one argument has
to be there for variadic function parameters.
>>> 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.
>
> So you can.
Of course, this totally defies the concept of type safety.
>>>> 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.
>
> Aren't there libraries that do *exactly* the same for C / C++?
>
>> Perl makes it a breeze to join strings,
>
> such a library might have a join, a split.
It might have, but it might just have not. What do you do then? Install
another library just to get the ability to split strings?
Incidentally, there is a sort-of-split in the libc, strtok. It's
broken beyond repair.
>> split them, interpolate
>> variables into them,
>
> sprintf.
That's a joy considering that sprintf expects a buffer large enough to
hold the result. sprintf() is infamous for its ability to create
buffer-overruns when used carelessly.
>> perform pattern matching and replacement upon
>> them,
>
> libraries
>
>> have multi-line strings, read them from files, I could go on and
>> on.
>
> Yup, all this can be found in libraries for C, C++, Java, etc.
How many libraries do you think would be required in C to have every
feature, that comes built into perl, available through one convenient
function call? And how many do you think you can install on one given
platform at the same time? Sure, for every problem a C library may
exist. But it's questionable if this library will work across dozens of
different UNIX flavours, Windows and those countless other platforms.
>> You can _do_ all of these things in C or C++, but the equivalent code
>> is longer
>
> I doubt it.
I don't.
>> 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.
>
> The question is: do you need those all the time? Moreover, the things
> you do with, for example closures, are those not work arounds (now and
> then) for limitations Perl has, but say C++ not?
Closures aren't work-arounds. They are a feature first introduced by
functional languages that many found so cool that at least the better
scripting languages support them nowadays. Perl without closures would
no longer be Perl. They are so great that MJD dedicated a whole book to
them, and rightly so.
Having said the above, I still consider C to be one of the few truely
perfect languages. It is precisely the lack of certain features that
makes it so appealing. Naturally, when I need those missing features,
I'd always chose Perl over C, or any language that has them. But many
tasks don't require more than its fairly basic set of concepts.
Tassilo
--
use bigint;
$n=71423350343770280161397026330337371139054411854220053437565440;
$m=-8,;;$_=$n&(0xff)<<$m,,$_>>=$m,,print+chr,,while(($m+=8)<=200);
------------------------------
Date: Mon, 12 Dec 2005 17:03:35 -0600
From: "Eric J. Roode" <sdn.girths00869@zoemail.net>
Subject: Re: What is the reason for Perl?
Message-Id: <Xns972AB807A6563sdn.comcast@216.196.97.136>
John Bokma <john@castleamber.com> wrote in
news:Xns972AA09354FA1castleamber@130.133.1.4:
> "Eric J. Roode" <sdn.girths00869@zoemail.net> wrote:
>
>> John Bokma <john@castleamber.com> wrote in
>> news:Xns972A92C699419castleamber@130.133.1.4:
>>
[...]
>> Only in that it lacks some niceties that more modern languages (like
>> Perl, or Java, or C#) provide, such as exceptions.
>
> Isn't there one (or even more) library that makes exceptions available
> in C?
Not that I've seen. I don't see how it could be implemented. Of course,
I may be missing something.
>> C's loops are unlabeled, meaning that you can only break or continue
>> out of the innermost one.
>
> goto LABEL?
> return;
You can do anything with goto. Doesn't mean it's a lovely control
structure.
>>
>> C has no exception mechanism.
>
> nor does Perl for that matter, eval and die is not that different from
> longjmp. However, with both C and Perl you can use a library to make
> things easier.
eval and die are tons different from setjmp/longjump.
>
>> C gives no information about the number
>
> yes it does.
No, it doesn't.
>> Strings auto-extend in Perl. You cannot overrun a buffer in Perl.
>
> Aren't there libraries that do *exactly* the same for C / C++?
Dunno. Can you point to one that does so for C?
>
>> Perl makes it a breeze to join strings,
>
> such a library might have a join, a split.
>
>> split them, interpolate
>> variables into them,
>
> sprintf.
Sure, sprintf exists. You can't tell me it's a simple or easy to use as,
say $foo = "$bar $baz{a}{b} $quux[5]";
>> perform pattern matching and replacement upon
>> them,
>
> libraries
>
>> have multi-line strings, read them from files, I could go on and
>> on.
>
> Yup, all this can be found in libraries for C, C++, Java, etc.
No library can make C or C++ support multi-line strings. Try this in C:
strcpy (var, "This string has
a newline in it");
or:
strcpy (var, <<END_OF_STRING);
...
END_OF_STRING
>> You can _do_ all of these things in C or C++, but the equivalent code
>> is longer
>
> I doubt it.
Then you don't know what you're talking about.
>> 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.
>
> The question is: do you need those all the time? Moreover, the things
> you do with, for example closures, are those not work arounds (now and
> then) for limitations Perl has, but say C++ not?
Do you need those all the time? Of course not. I don't need wire
strippers all the time, but they're in my toolkit, and using a knife to
strip insulation off a wire is tedious and dangerous.
I don't see how closures are a workaround for limitations perl has,
except possibly in the sense of information hiding. Closures are
probably never necessary, but they make a bunch of problems easier to
solve. There have been times when I've wished for a closure in C.
>> 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.
>
> No it isn't. Just create your own Universal class, and let everything
> that adds inherit from it.
That only works if all of the libraries (including those from other
vendors) that you are using inherit from _your_ Universal class, which of
course they don't. In Perl, polymorphism simply requires that methods
have the same name. In C++, it requires that they have the same
ancestor.
C++'s solution is not *wrong* (nor is Perl's *right*); they're just
*different*. I happen to prefer Perl's, and have used it to good effect.
C++'s is more limited, however.
--
Eric
`$=`;$_=\%!;($_)=/(.)/;$==++$|;($.,$/,$,,$\,$",$;,$^,$#,$~,$*,$:,@%)=(
$!=~/(.)(.).(.)(.)(.)(.)..(.)(.)(.)..(.)......(.)/,$"),$=++;$.++;$.++;
$_++;$_++;($_,$\,$,)=($~.$"."$;$/$%[$?]$_$\$,$:$%[$?]",$"&$~,$#,);$,++
;$,++;$^|=$";`$_$\$,$/$:$;$~$*$%[$?]$.$~$*${#}$%[$?]$;$\$"$^$~$*.>&$=`
------------------------------
Date: Mon, 12 Dec 2005 17:04:44 -0600
From: "Eric J. Roode" <sdn.girths00869@zoemail.net>
Subject: Re: What is the reason for Perl?
Message-Id: <Xns972AB839D9BC6sdn.comcast@216.196.97.136>
xhoster@gmail.com wrote in news:20051212172745.432$r0@newsreader.com:
> "Eric J. Roode" <sdn.girths00869@zoemail.net> wrote:
>> John Bokma <john@castleamber.com> wrote in
>> news:Xns972A92C699419castleamber@130.133.1.4:
[...]
>> >> 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.
>
> But do those niceties have anything to do with C's age? It seems to
> me like C is a still-widely-used close-to-the-metal language not
> because it is old, but because we need a close-to-the-metal language
> and C is good at being that.
Ah, but wouldn't it be great to have a nice, fast, close-to-the-metal
language that did implement some modern niceties? That would rule. :-)
--
Eric
`$=`;$_=\%!;($_)=/(.)/;$==++$|;($.,$/,$,,$\,$",$;,$^,$#,$~,$*,$:,@%)=(
$!=~/(.)(.).(.)(.)(.)(.)..(.)(.)(.)..(.)......(.)/,$"),$=++;$.++;$.++;
$_++;$_++;($_,$\,$,)=($~.$"."$;$/$%[$?]$_$\$,$:$%[$?]",$"&$~,$#,);$,++
;$,++;$^|=$";`$_$\$,$/$:$;$~$*$%[$?]$.$~$*${#}$%[$?]$;$\$"$^$~$*.>&$=`
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 8757
***************************************
