Re: What is the reason for Perl?
- From: "Tassilo v. Parseval" <tassilo.von.parseval@xxxxxxxxxxxxxx>
- Date: Mon, 12 Dec 2005 23:56:06 +0100
Also sprach John Bokma:
> "Eric J. Roode" <sdn.girths00869@xxxxxxxxxxx> wrote:
>
>> 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.
>
> 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);
.
- Follow-Ups:
- Re: What is the reason for Perl?
- From: John Bokma
- Re: What is the reason for Perl?
- From: Eric J. Roode
- 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
- 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: Correcting details for a CPAN module.
- Previous by thread: Re: What is the reason for Perl?
- Next by thread: Re: What is the reason for Perl?
- Index(es):
Relevant Pages
|
|
