What is the reason for Perl?

Discussion in 'Perl Misc' started by robic0, Dec 12, 2005.

  1. robic0

    robic0 Guest

    Explain to me if you can why Perl is something I should use in
    replacement to say C++ and a native API....
    I say "if you can" because I'm interrested in your bullshit.
    After 2 years newbie Perl (forced on me). I know the breadth
    of it and the power boils down to package interfaced dll's
    to the os by an extroidnary amount of contributors who don't
    know when to hold off publishing, in lieu of the misguided
    fame (and down in flames) it is thought (in their heads) to
    bring.

    C++ and native API, without complex workarounds (for
    Perl language shortcomings the modules exhibit) is
    about a thousand percent more reliable and faster.

    Why should anybody invest time in a guessing game such
    as Perl. Not Perl per-say, but modules that leave you
    very short in the bottom line?

    Let the bullshit begin .........->
    robic0, Dec 12, 2005
    #1
    1. Advertising

  2. robic0

    Guest

    robic0 wrote:
    > Explain to me if you can why Perl is something I should use in
    > replacement to say C++ and a native API....


    You shouldn't. Perl is not for all people. You are apparently one of
    them. Please stop using Perl. Please stop posting to Perl news groups.

    Thanks,

    Xho

    --
    -------------------- http://NewsReader.Com/ --------------------
    Usenet Newsgroup Service $9.95/Month 30GB
    , Dec 12, 2005
    #2
    1. Advertising

  3. robic0

    robic0 Guest

    On 12 Dec 2005 01:41:32 GMT, wrote:

    >robic0 wrote:
    >You shouldn't. Perl is not for all people. You are apparently one of
    >them. Please stop using Perl. Please stop posting to Perl news groups.
    >
    >Thanks,
    >
    >Xho


    I may blow off Perl, I think I have the jist of it. Don't need to
    limit myself to Perl like you. But I won't leave people like you
    in the abyss because you have chosen to put all your eggs in a
    $10/hr proffession. Believe me I will never forget it and never
    ever stop trying to fix damaged brains as a result of the
    contentious crap that emminates from here. Errr ah, you !!
    robic0, Dec 12, 2005
    #3
  4. robic0 wrote:

    > Explain to me if you can why Perl is something I should use in
    > replacement to say C++ and a native API....
    > I say "if you can" because I'm interrested in your bullshit.


    No you're not. You're interested in trolling.

    GO AWAY.

    gtoomey
    Gregory Toomey, Dec 12, 2005
    #4
  5. robic0

    robic0 Guest

    On Mon, 12 Dec 2005 02:21:05 GMT, Gregory Toomey <>
    wrote:

    >robic0 wrote:
    >
    >> Explain to me if you can why Perl is something I should use in
    >> replacement to say C++ and a native API....
    >> I say "if you can" because I'm interrested in your bullshit.

    >
    >No you're not. You're interested in trolling.
    >
    >GO AWAY.


    Got to forums for this kind of coersion.
    Your a dickhead and a jackoff asshoe scumbag!
    Don't answer the posted question or **** you!!
    Shit somewhere else.......>
    >gtoomey
    robic0, Dec 12, 2005
    #5
  6. In article <>, robic0 wrote:

    > On Mon, 12 Dec 2005 02:21:05 GMT, Gregory Toomey <>
    > wrote:
    >
    > >robic0 wrote:
    > >
    > >> Explain to me if you can why Perl is something I should use in
    > >> replacement to say C++ and a native API....
    > >> I say "if you can" because I'm interrested in your bullshit.

    > >
    > >No you're not. You're interested in trolling.
    > >
    > >GO AWAY.

    >
    > Got to forums for this kind of coersion.
    > Your a dickhead and a jackoff asshoe scumbag!
    > Don't answer the posted question or **** you!!
    > Shit somewhere else.......>
    > >gtoomey


    Yawn. Got some marketing job sucking on a Microsoft PR person's
    whatever? Be sure they wear latex and you wear kneepads. Keep the blue
    dress, though. It matches the color of your eyes.

    Perl was a system admin tool developed by Larry Wall. Runs on lots of
    systems and has a boatload of modules of stuff others have written for
    all sorts of applications. I suspect it probably takes a lot less time
    to implement something in Perl than C++ _and_ it runs on lots more
    systems other than just Wintel.

    *plonk*

    --
    DeeDee, don't press that button! DeeDee! NO! Dee...
    Michael Vilain, Dec 12, 2005
    #6
  7. robic0 wrote in news:eek::

    > 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
    `$=`;$_=\%!;($_)=/(.)/;$==++$|;($.,$/,$,,$\,$",$;,$^,$#,$~,$*,$:,@%)=(
    $!=~/(.)(.).(.)(.)(.)(.)..(.)(.)(.)..(.)......(.)/,$"),$=++;$.++;$.++;
    $_++;$_++;($_,$\,$,)=($~.$"."$;$/$%[$?]$_$\$,$:$%[$?]",$"&$~,$#,);$,++
    ;$,++;$^|=$";`$_$\$,$/$:$;$~$*$%[$?]$.$~$*${#}$%[$?]$;$\$"$^$~$*.>&$=`
    Eric J. Roode, Dec 12, 2005
    #7
  8. robic0

    John Bokma Guest

    "Eric J. Roode" <> 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?

    > 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*.

    > 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.

    > you have to do a lot of work to get
    > anything done.


    Yup, like finding the right library. So what else is new?

    > Plus, the language has no reflection/introspection
    > capabilities at all,


    I am sure a decent C programmer can find a way :-D.

    > and its control structures are weak.


    How?

    > 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++?

    > Perl is a much higher-level language than either of the above.


    How do you measure your levels?

    > It
    > does a whole boatload of the work for you, so you don't have to worry
    > so much about allocation, buffer sizes, etc.


    You can use a library for C/C++ if it worries you.

    > String manipulation in
    > Perl is a joy, compared to in C or C++ (or Java).


    How is it worse in C/C++ (or Java)?

    > It also has a more
    > mature OO model than C++,


    Really? Based on what?

    > 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?

    > -- 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.


    Yup.

    I don't have /a/ language of preference btw. I just use the language
    that does the job right. Maybe that's why I question so many of your
    statements.

    --
    John Small Perl scripts: http://johnbokma.com/perl/
    Perl programmer available: http://castleamber.com/
    I ploink googlegroups.com :)
    John Bokma, Dec 12, 2005
    #8
  9. John Bokma <> wrote in
    news:Xns972A92C699419castleamber@130.133.1.4:

    > "Eric J. Roode" <> 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
    `$=`;$_=\%!;($_)=/(.)/;$==++$|;($.,$/,$,,$\,$",$;,$^,$#,$~,$*,$:,@%)=(
    $!=~/(.)(.).(.)(.)(.)(.)..(.)(.)(.)..(.)......(.)/,$"),$=++;$.++;$.++;
    $_++;$_++;($_,$\,$,)=($~.$"."$;$/$%[$?]$_$\$,$:$%[$?]",$"&$~,$#,);$,++
    ;$,++;$^|=$";`$_$\$,$/$:$;$~$*$%[$?]$.$~$*${#}$%[$?]$;$\$"$^$~$*.>&$=`
    Eric J. Roode, Dec 12, 2005
    #9
  10. robic0

    John Bokma Guest

    "Eric J. Roode" <> wrote:

    > John Bokma <> wrote in
    > news:Xns972A92C699419castleamber@130.133.1.4:
    >
    >> "Eric J. Roode" <> 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.

    >>> 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 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?

    > 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?

    > 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.

    >>> 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.


    goto LABEL?
    return;

    > 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. However, with both C and Perl you can use a library to make
    things easier.

    > 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.

    > C gives no information about the number


    yes it does.


    >> 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.

    >>> 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.

    > split them, interpolate
    > variables into them,


    sprintf.


    > 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.

    > You can _do_ all of these things in C or C++, but the equivalent code
    > is longer


    I doubt it.

    > and more tedious.


    I agree that a regexp in a language that requires a function to do the
    thing takes a little more work.

    >>> 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,


    Which can't be done in C++?

    > 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?

    > 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.

    >>> 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.


    "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."

    That was probably one of the few true remarks in this thread :-D.

    --
    John Small Perl scripts: http://johnbokma.com/perl/
    Perl programmer available: http://castleamber.com/
    I ploink googlegroups.com :)
    John Bokma, Dec 12, 2005
    #10
  11. robic0

    Guest

    "Eric J. Roode" <> wrote:
    > John Bokma <> wrote in
    > news:Xns972A92C699419castleamber@130.133.1.4:
    >
    > > "Eric J. Roode" <> 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
    , Dec 12, 2005
    #11
  12. John Bokma <> wrote in
    news:Xns972AA09354FA1castleamber@130.133.1.4:

    > "Eric J. Roode" <> 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
    `$=`;$_=\%!;($_)=/(.)/;$==++$|;($.,$/,$,,$\,$",$;,$^,$#,$~,$*,$:,@%)=(
    $!=~/(.)(.).(.)(.)(.)(.)..(.)(.)(.)..(.)......(.)/,$"),$=++;$.++;$.++;
    $_++;$_++;($_,$\,$,)=($~.$"."$;$/$%[$?]$_$\$,$:$%[$?]",$"&$~,$#,);$,++
    ;$,++;$^|=$";`$_$\$,$/$:$;$~$*$%[$?]$.$~$*${#}$%[$?]$;$\$"$^$~$*.>&$=`
    Eric J. Roode, Dec 12, 2005
    #12
  13. Also sprach John Bokma:
    > "Eric J. Roode" <> wrote:
    >
    >> John Bokma <> wrote in
    >> news:Xns972A92C699419castleamber@130.133.1.4:
    >>
    >>> "Eric J. Roode" <> 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);
    Tassilo v. Parseval, Dec 12, 2005
    #13
  14. John Bokma <> wrote in
    news:Xns972AA09354FA1castleamber@130.133.1.4:

    > "Eric J. Roode" <> wrote:
    >
    >> John Bokma <> 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
    `$=`;$_=\%!;($_)=/(.)/;$==++$|;($.,$/,$,,$\,$",$;,$^,$#,$~,$*,$:,@%)=(
    $!=~/(.)(.).(.)(.)(.)(.)..(.)(.)(.)..(.)......(.)/,$"),$=++;$.++;$.++;
    $_++;$_++;($_,$\,$,)=($~.$"."$;$/$%[$?]$_$\$,$:$%[$?]",$"&$~,$#,);$,++
    ;$,++;$^|=$";`$_$\$,$/$:$;$~$*$%[$?]$.$~$*${#}$%[$?]$;$\$"$^$~$*.>&$=`
    Eric J. Roode, Dec 12, 2005
    #14
  15. wrote in news:20051212172745.432$:

    > "Eric J. Roode" <> wrote:
    >> John Bokma <> 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
    `$=`;$_=\%!;($_)=/(.)/;$==++$|;($.,$/,$,,$\,$",$;,$^,$#,$~,$*,$:,@%)=(
    $!=~/(.)(.).(.)(.)(.)(.)..(.)(.)(.)..(.)......(.)/,$"),$=++;$.++;$.++;
    $_++;$_++;($_,$\,$,)=($~.$"."$;$/$%[$?]$_$\$,$:$%[$?]",$"&$~,$#,);$,++
    ;$,++;$^|=$";`$_$\$,$/$:$;$~$*$%[$?]$.$~$*${#}$%[$?]$;$\$"$^$~$*.>&$=`
    Eric J. Roode, Dec 12, 2005
    #15
  16. "Tassilo v. Parseval" <> wrote in
    news::

    > 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.


    Well said.

    --
    Eric
    `$=`;$_=\%!;($_)=/(.)/;$==++$|;($.,$/,$,,$\,$",$;,$^,$#,$~,$*,$:,@%)=(
    $!=~/(.)(.).(.)(.)(.)(.)..(.)(.)(.)..(.)......(.)/,$"),$=++;$.++;$.++;
    $_++;$_++;($_,$\,$,)=($~.$"."$;$/$%[$?]$_$\$,$:$%[$?]",$"&$~,$#,);$,++
    ;$,++;$^|=$";`$_$\$,$/$:$;$~$*$%[$?]$.$~$*${#}$%[$?]$;$\$"$^$~$*.>&$=`
    Eric J. Roode, Dec 12, 2005
    #16
  17. robic0

    John Bokma Guest

    "Eric J. Roode" <> wrote:

    > John Bokma <> wrote in
    > news:Xns972AA09354FA1castleamber@130.133.1.4:


    >> 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).


    Yup, in which case you either are going to use a library that handles it
    for you, or write your own stuff.

    However, if you just want to copy the string, you *know* you need to
    allocate a buffer of 6 chars.

    > 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.


    Of course there is, silly:

    jbokma:~$ type hello.c
    bash: type: hello.c: not found
    jbokma:~$ cat hello.c
    #include <stdlib.h>

    int main(void) {

    char buf[20];
    printf("%d\n", sizeof(buf));
    }
    jbokma:~$ gcc hello.c
    jbokma:~$ ./a.out
    20



    --
    John Small Perl scripts: http://johnbokma.com/perl/
    Perl programmer available: http://castleamber.com/
    I ploink googlegroups.com :)
    John Bokma, Dec 13, 2005
    #17
  18. robic0

    John Bokma Guest

    "Tassilo v. Parseval" <> wrote:

    > Also sprach John Bokma:


    >> 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 $@.


    Of course, and hence you're using a library that provides exception
    objects, and maybe a nice wrapper like try and catch :-D.

    > I've never seen
    > a need for more elaborate exception handling. IMO, what Perl offers
    > wrt exception handling is just what's needed.


    Yup, but you need a library to get the object throwing stuff. We don't
    disagree here ;-)

    >>> 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.


    Perl is written in C now isn't it? One could run a garbage collector in
    a thread, or check in the allocation part if there is enough garbage to
    collect.

    >> 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


    See above. There is nothing wrong with using a threading library, and
    have your own gc running in a thread, etc.

    >> 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.


    None, if one uses the right library. And if the library isn't there,
    what stops one from creating the library and use it from then on? Ages
    ago, when I got my first hash table explained in class, I wrote my own
    hash table software. I was using hashes a lot in C, until I discovered
    Perl :-D.

    >>> 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.


    Can you clarify this statement?

    >>> 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.


    let's call that try :-D

    >> 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.


    Ok.

    >>> 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.


    so, at least one fixed argument. But C does give information about the
    number.

    >>>> 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.


    You know the difference between you can't and you can?

    >>> 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?



    How is this different from going to CPAN and install yet another module
    for just one simple piece of functionality? I do this all the time, and
    I consider this a sound way to program.

    >> 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?


    Do you use each and every feature in perl everyday? If you need each and
    every future in Perl, from C, then you embed perl in C, simple.

    > 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.


    Are that *the* requirements? I only showed that a lot of statements made
    about C are wrong, or can be solved by a library.

    > 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.


    I don't know any perfect programming language, but agree with the rest
    of that paragraph.

    --
    John Small Perl scripts: http://johnbokma.com/perl/
    Perl programmer available: http://castleamber.com/
    I ploink googlegroups.com :)
    John Bokma, Dec 13, 2005
    #18
  19. John Bokma <> wrote in
    news:Xns972AB80451CFCcastleamber@130.133.1.4:

    > "Eric J. Roode" <> wrote:
    >
    >> John Bokma <> wrote in
    >> news:Xns972AA09354FA1castleamber@130.133.1.4:

    >
    >>> 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).

    >
    > Yup, in which case you either are going to use a library that handles

    it
    > for you, or write your own stuff.
    >
    > However, if you just want to copy the string, you *know* you need to
    > allocate a buffer of 6 chars.


    Right. And you have to keep track of that. Over and over, all day long.


    >> 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.

    >
    > Of course there is, silly:
    >
    > jbokma:~$ type hello.c
    > bash: type: hello.c: not found
    > jbokma:~$ cat hello.c
    > #include <stdlib.h>
    >
    > int main(void) {
    >
    > char buf[20];
    > printf("%d\n", sizeof(buf));
    > }
    > jbokma:~$ gcc hello.c
    > jbokma:~$ ./a.out
    > 20


    You didn't show me strcpy() finding out how large the buffer is; you
    showed me the calling function finding out.

    Here, fill in the blank:

    int main(void) {
    char buf[20];
    size_t len;

    printf ("buf can hold at most %d chars.\n", find_size(buf));
    }

    size_t find_size(const char *buf) {
    ???
    }

    --
    Eric
    `$=`;$_=\%!;($_)=/(.)/;$==++$|;($.,$/,$,,$\,$",$;,$^,$#,$~,$*,$:,@%)=(
    $!=~/(.)(.).(.)(.)(.)(.)..(.)(.)(.)..(.)......(.)/,$"),$=++;$.++;$.++;
    $_++;$_++;($_,$\,$,)=($~.$"."$;$/$%[$?]$_$\$,$:$%[$?]",$"&$~,$#,);$,++
    ;$,++;$^|=$";`$_$\$,$/$:$;$~$*$%[$?]$.$~$*${#}$%[$?]$;$\$"$^$~$*.>&$=`
    Eric J. Roode, Dec 13, 2005
    #19
  20. John Bokma <> wrote in
    news:Xns972ABB60F31E8castleamber@130.133.1.4:

    [paraphrased]
    > Library, library, library, library, library.


    Can you point to any of these magical libraries?


    --
    Eric
    `$=`;$_=\%!;($_)=/(.)/;$==++$|;($.,$/,$,,$\,$",$;,$^,$#,$~,$*,$:,@%)=(
    $!=~/(.)(.).(.)(.)(.)(.)..(.)(.)(.)..(.)......(.)/,$"),$=++;$.++;$.++;
    $_++;$_++;($_,$\,$,)=($~.$"."$;$/$%[$?]$_$\$,$:$%[$?]",$"&$~,$#,);$,++
    ;$,++;$^|=$";`$_$\$,$/$:$;$~$*$%[$?]$.$~$*${#}$%[$?]$;$\$"$^$~$*.>&$=`
    Eric J. Roode, Dec 13, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Weng Tianxiang

    Re: Compilation error reason???

    Weng Tianxiang, Jul 23, 2003, in forum: VHDL
    Replies:
    1
    Views:
    1,574
    Mike Treseler
    Jul 24, 2003
  2. Blake Versiga
    Replies:
    2
    Views:
    19,772
    Yan-Hong Huang[MSFT]
    Jul 9, 2003
  3. rl30
    Replies:
    1
    Views:
    624
    emachine
    Aug 15, 2003
  4. Frederik
    Replies:
    0
    Views:
    1,415
    Frederik
    Nov 25, 2003
  5. Frederik
    Replies:
    2
    Views:
    5,501
Loading...

Share This Page